What is IaC

Infrastructure as Code(IaC) is a way to automate the provisioning and management of the technology stack, it translates manual tasks into reusable, robust, distributable code, and relies on practices that have been successfully used for years in software development (version control, automated testing, release tagging, continuous delivery, etc.). What you can get from it are much higher delivery speed and a significant reliability boost.

Why do you need it?

Scalability & Reliability:

You can replicate the process to scale as quickly as the code executes and resources are provisioned. A core component of IaC is to have a test after each essential step in the workflow, which will get into in the next slide.

Automation & Agility:

Reduce human error by embracing automation. Stop building things by hand. Put everything into repeatable code configuration (e.g., YAML for Ansible or HashiCorp Configuration Language (HCL). Agility comes from the ability to have multiple people committing code, submitting changes, testing, etc. in multiple places in the pipeline; all of which result in faster delivery and app deployment to meet business requirements.

Higher ROI & Lower TCO:

Invest in automation today to gain time tomorrow. To lower your TCO, IaC reduces your downtime (e.g., migrations, testing cycles, maintenance windows, outages, etc.), consolidates your application development technologies into minimum IaC orchestration tools as possible, and provides a quicker turnaround for catching mistakes through its checks and balances.

How to do it?

A Version Control System (VCS), like Git, is the crux of IaC. It provides a way for teams to easily track, merge, and revert modifications to the code base. Most hosted VCSs incorporate a CI/CD pipeline system which can be used to test your code before pushing it to a production network. A wide range of tools are available which can be used to serve the purpose. In this lab, we will use GitLab to demonstrate how to do it.

To demonstrate usage of the GitLab CI/DC pipeline system, we'll use our existing Terrraform repository.

Whenever there is a code or configuration change it's a good idea to follow this general set of steps:

1. Changes should always be made to a staging branch before they go into the control branch. (The control branch is often called main)
2. In the staging branch, make changes and commit the code/config and then open a merge request against the control branch
3. The CI pipeline is triggered to test/validate the code/config changes on your staging environment
4. Assuming the CI pipeline succeeds, the changes can be merged back to the control or main branch
5. Merging to the control branch triggers the CD pipeline to deploy the changes to your production environment

NOTE: When using NX-OS, the staging environment can be simulated using Nexus 9000v before depoloying to your production environment.

Now that you have a high level understanding of CI/CD let's build it out!