Lab 1: Make new code commit, push changes and deploy to Staging and Production

In this example, we will make a simple change in updating the phone image on the homepage of our website. We will then commit our changes and push the new code to our Gitlab repository; this will automatically trigger a CI/CD pipeline.

A successful build will result in storing the Docker container artifact in a private Container Registry; this is the new stable build of NGINX Plus containing the new web application code.

The last phase of the CI/CD Pipeline will deploy the new container to our Staging Server automatically but wait for a human trigger to deploy the containers to Production. Note that we will deploy four instances (four containers) to Production to illustrate NGINX Plus as a Load Balancer in the next exercise

  1. Open the GitHub Desktop client and make sure the current repository selected is gitlabappster

    From the same screen now click the “Open in Visual Studio Code” button to start editing our appster web application code

    ../../../_images/image22.png

    Now that Visual Studio Code is open, expand the tree under gitlabappster -> etc -> nginx -> html. Once the tree has been opened, find index.html file and right click on it. A menu will open up. Select: “Reveal in File explorer” to open it up in windows explorer.

    ../../../_images/image32.png
  2. Once windows explorer has opened at the location of the file, you will see the folder with index.html listed. Go ahead and double-click index.html to open that file in a browser (Google Chrome.)

    ../../../_images/image41.png
  3. After the double-click on index.html, and opening the webpage in the web browser, you will see the current webpage displaying the Appster application with a dated iPhone 7 image. Go ahead and leave this web browser page open.

    ../../../_images/image51.png
  4. Go back to Visual Studio code editor to make edits to this file. This time, open that same index.html file (click to open it in visual studio code.)

    Once the file is open, we are now going to find and replace the current iPhone image (currently set to iphone_7.png and change it to iphone_x.png Hit Ctrl+F, which opens the find window and type in iphone_7.png. You should have two hits (just to the right of the find window).

    Search and replace all instances of iphone_7.png to iphone_x.png. Update all two instances of that image

    ../../../_images/image62.png
  5. Once you have edited index.html and replaced both instances of iphone_7.png with iphone_x.png, go ahead and save the file. You can navigate to file -> save or you can use the shortcut, CTRL+S. (NOTE: Do not change the file name. Keep it the same.)

  6. Open or switch back to the GitHub Desktop Client and see the tracked changes made.

    The GitHub Desktop Client has automatically tracked the changes that were made on index.html and is highlighting those exact changes, iphone_7.png replaced with iphone_x.png.

  7. We now can push these changes to our repository on GitLab. In the lower-left of the GitHub, Desktop Client provide a Commit title and notes before we can commit to master:

    You can see two boxes. Go ahead and type in the title field: “update index.html”.

    Additionally, you can provide notes as well, type in the notes field: “Update phone image”

    Once you fill in both boxes, click on Commit to Master and on the next screen, press Push Origin to push the new code commit to our git repository on Gitlab.

    ../../../_images/image72.png
  8. After you click on Commit to Master, you will be taken to the next page where we push our changes to our repository. Go and click push origin, which will now push our modified index.html file to our GitLab repository.

    ../../../_images/image82.png
  9. Open up the Appster repo on Gitlab, using the URI https://gitlab.f5.local/f5-demo-lab/gitlabappster or using the Appster shortcut provided. (udf/P@ssw0rd20) This is our repository, where we just pushed our modified index.html file to.

    ../../../_images/image91.png
  10. In the middle of the Appster repository, you will see the pipeline status icon next to the latest Commit SHA. When the pipeline is currently in progress, you will see an orange icon (waiting to start), blue circle (running) ), or a green check (passed). Hopefully, we don’t see a red icon, which indicates the pipeline has failed. We can click on the pipeline status icon to view the pipeline progress

    ../../../_images/image101.png
  11. After clicking on the pipeline status icon, we can view the full pipeline. As you can see, we can now see our pipeline: BUILD, TEST, PUSH, DEPLOY, and CLEANUP. This pipeline was automatically triggered after we submitted our changes to index.html (when we clicked push origin.) and we can see at a high level the stages in the pipeline progressing

    ../../../_images/image121.png

Attention

Stop: This is a good time to inspect the GitLab CI/CD Pipeline file, .gitlab-ci.yml, while waiting for the pipeline to complete.

  1. Look at the stage, deploy_staging, and compare to the stage, deploy_prod, Do you see when: manual ? This enforces a manual trigger to deploy to production!
  2. In stages deploy_staging and deploy_prod: you will see many docker commands executed as commands remotely using SSH.
  3. In both stages, deploy_staging and deploy_prod, docker login to our container registry and docker pull to Pull the updated web server image. We then run docker stop to stop our running web server container anddocker rm to delete this old container. Lastly we do a docker run to run the updated web server image. When we run multiple containers in production we can avoid an outage by performing cascading updates and use active health checks on the load balancer to avoid traffic sent to a down server.
  1. As part of our Continuous Delivery, deployment to Staging is automatic, and Production is manual: we have purposely injected a human trigger for a deployment to Production

    ../../../_images/image131.png

Note

Do not deploy to Production (play button) until code changes in staging have been validated!

  1. Browse to the server bookmarked as STAGING WEB - Appster under the “Staging Servers” bookmark folder to see the new web app code pushed to our Staging Server.

    Open the webpage in a New incognito window (Ctrl + Shift + N) to bypass browser cache and view changes.

    ../../../_images/image151.png

    After new code commit (notice the updated phone image):

    ../../../_images/image181.png

Note

Ignore the bookmarks STAGING LB - Appster and PROD LB - Appster for now - we will set this up in a later exercise.

  1. If our code changes pushed to staging are successful and the changes are validated, we can now deploy to Production:

    Under the DEPLOY stage, we have the option to deploy to Production manually. Go ahead and click on the little Play button that is on the deploy_prod stage of the pipeline. This trigger will now deploy our new Docker image to Production, with. the new code showing the updated image, iphone_x.png.

    ../../../_images/image271.png ../../../_images/image141.png
  2. If our deployment to Production is successful you would now see the new web app code now deployed on all four Production web servers; we can see that on any Web Servers bookmarked as PROD WEB - Appster-red, PROD WEB - Appster-yellow, PROD WEB - Appster-green and PROD WEB - Appster-blue under the Production Servers bookmark folder.

    ../../../_images/image161.png ../../../_images/image261.png