Module 3: Continuous Deployment for NGINX Plus Load Balancers
=============================================================
In this exercise, we will be using a CI/CD pipeline to deploy NGINX Plus
Load balancer.
Instead of deploying NGINX Plus as a container into our live
environments as we did in the previous exercise, we will be pushing new
NGINX configuration into a new deployment folder, the filesystem of our
NGINX Plus Virtual Machine.
Next, we create a \ `Symbolic link `__ to
point the default NGINX config directory, ``/etc/nginx`` to this new
deployment folder, ``/var/deploy/[$CI_COMMIT_SHA]``.
Lastly, we will reload NGINX with the new NGINX configuration gracefully
without dropping connections.
The \ `Commit SHA `__ is a
unique hash referring to a particular commit of code. Because we deploy
new NGINX Plus configurations in a new folder using a \ `Commit
SHA `__ as the
folder name, we can quickly revert to known NGINX configuration
consistent with the code commit in Gitlab’s git repository.
NGINX can reload a new configuration without any downtime, and without
interrupting any current connections. A soft-reconfiguration spawns a
new set of NGINX worker processes; the old ones continue to work until
completion (but do not accept new requests - all new applications are
accepted by the new set of worker processes). Live binary upgrades work
similarly. If the upgrade is successful, the old set of NGINX worker
processes are signaled to terminate, and the new set takes over. For
more information, please see: \ `Controlling NGINX `__
CI/CD flowchart
---------------
**The diagrams below depicts the workflow from code to deployment.**
Here is an overview of the entire CI/CD Pipeline
.. image:: ./images/image0.png
Here is a closer look at **steps 5 and 6**, where we use ``rsync`` to
deploy the new NGINX configuration files to live NGINX servers
.. image:: ./images/image1.png
.. Important:: Run all lab activites from the Windows JumpHost
.. toctree::
:maxdepth: 1
:glob:
lab/lab*