In half 1 of this weblog sequence, we overviewed the totally different instruments that will be used as you go up the stack from infrastructure to utility. In half 2, we provisioned the Infrastructure as Code (IaC) utilizing Terraform, Ansible, Jenkins and GitHub. On this weblog, we’ll go over tips on how to deploy Infrastructure as Code (IaC) utilizing GitOps.
GitLab defines GitOps as an operational framework that takes DevOps greatest practices – used for utility improvement akin to model management, collaboration, compliance, and CI/CD tooling – and applies them to infrastructure automation.
We are going to leverage Jenkins as our CI/CD software to construct and automate the Terraform and Ansible configurations. The code will likely be dedicated to the infra department in our GitHub repository, Cloud Native Safety SPOT ON Collection. We are going to then create a pull request to merge the infra adjustments into the primary department and ensure the merge. If you happen to keep in mind from our final episode, once we setup our multibranch pipeline in Jenkins, we set the configuration to ballot the primary department each minute, and if there have been any adjustments to set off the pipeline. Since we’re including new code to primary department, Jenkins will set off the pipeline.
The very first thing that occurs is Jenkins will try the code from our GitHub repository and add it to the Jenkins agent, on this case the Jenkins Grasp. After that it runs a “terraform get –replace“. This updates any new modules added to the configuration. Then it runs a “terraform init,” which can initialize all of the Terraform Suppliers. Lastly, “terraform apply” is run to do the deployment. This may move all of the variables from Jenkins to Terraform. The run takes about 20 minutes as a result of we’re provisioning an EKS cluster and a Safe Firewall occasion which take time to spin up. In whole, there will likely be 48 assets deployed to our AWS surroundings. We will even get output from Terraform which provides us the EKS Cluster identify and API, in addition to the EKS Employee Node and Safe Firewall Administration public IP addresses.
As soon as the construct is full, we will confirm utilizing the AWS Dashboard and Firepower Machine Supervisor. First, we’ll examine the AWS VPC Dashboard and we’ll see a brand new VPC, with 5 subnets, 2 route tables, 1 web gateway, and a pair of elastic IP addresses. Subsequent, we examine EC2 Dashboard and discover 2 cases, one for the Safe Firewall and the opposite for the EKS Employee Node. Then we go into the EKS Dashboard, and we’ll see a Kubernetes cluster with the EC2 employee node assigned to it.
Subsequent, we soar into the Firepower Machine Supervisor (FDM) to validate our NGFW (Subsequent Era Firewall) configuration. To entry the FDM we use the IP tackle generated from the Terraform output. We are going to see that the interfaces have been configured with IP addresses and safety zones, inside and exterior routes have been utilized, community and repair objects have been created, entry management record has been deployed and inbound and outbound guidelines have been configured, and community tackle translation has been assigned for the EKS node.
For detailed output of all these steps, please learn on beneath
Try the demonstration beneath:
Cisco Safe Cloud Native Safety – Half 1.2 – GitOps and CI/CD
After the code has been merged into the principle department, the Jenkins pipeline will likely be triggered.
Step 1, Jenkins checks out the code from the GitHub repository.
Step 2 prints out “Constructing Surroundings.”
Step 3 runs “terraform get –replace” which updates the modules. On this case, it updates the infrastructure module.
Step 3 run “terraform init”, which can initialize all of the suppliers.
Step 4 runs “terraform apply –auto-approve” passing all of the variables.
The run is full displaying 48 assets have been added and the outputs of the EKS API, EKS cluster identify, EKS employee public IP tackle, and the FTD Mgmt. IP tackle.
In AWS VPC Dashboard, we see a VPC named SPOT_ON_Prod.
There are 5 subnets assigned to the VPC.
There may be 1 web gateway.
There are 2 Elastic IP addresses, one assigned to the EKS employee node, and one other assigned to the FTD Mgmt. interface.
There are 2 EC2 cases, one internet hosting FTD the opposite EKS Employee Node.
There may be 1 EKS Cluster with the Employee Node EC2 occasion assigned to it.
We entry the Safe Firewall through the Firepower Machine Supervisor Mgmt IP tackle that we acquired from the Terraform output.
Beneath we see the Community Objects configured for the EKS employee node and the Service Objects for the Yelb and NGINX purposes.
Right here is the inbound entry rule that enables ANY to the EKS employee node for service ports of our apps.
This can be a static NAT so the skin world can entry the EKS node.
We’d love to listen to what you assume. Ask a query or go away a remark beneath.
And keep related with Cisco DevNet on social!