{"id":6830,"date":"2021-08-31T17:04:53","date_gmt":"2021-08-31T11:34:53","guid":{"rendered":"https:\/\/opstree.com\/blog\/\/?p=6830"},"modified":"2021-08-31T19:04:52","modified_gmt":"2021-08-31T13:34:52","slug":"provisioning-infra-and-deployments-in-aws-using-packer-terraform-and-jenkins","status":"publish","type":"post","link":"https:\/\/opstree.com\/blog\/2021\/08\/31\/provisioning-infra-and-deployments-in-aws-using-packer-terraform-and-jenkins\/","title":{"rendered":"Provisioning Infra and Deployments In AWS : Using Packer, Terraform and Jenkins"},"content":{"rendered":"\n

Why DevOps Rides on Immutable Infrastructure? The acceptance of \u201cimmutable infrastructure\u201d has emerged as a viable way to improve DevOps processes and culture. By introducing standardisation in application deployment and management, the immutable infrastructure helps, among other things, to foster a better collaborative environment among developers, operations, and other stakeholders.<\/p>\n\n\n\n

Let’s discuss a bit about Immutable Infra and the benefits which it brings to the table. Once we have a better understanding of it, we’ll really start to see the use case in our Deployments Model.<\/p>\n\n\n\n\n\n\n\n

Mutable Flow : <\/h4>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n

Immutable Flow :<\/h4>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n

The difference is, when we go immutable, we don’t want to ever upgrade in place as we do in Mutable. An immutable infrastructure<\/strong> is another infrastructure model in which servers are never modified after they\u2019re deployed. If something needs to be updated, fixed, or modified in any way, new servers built from a custom machine images with the appropriate changes are provisioned to replace the old ones. And, here comes Packer<\/strong> to create those customized machine images to fit for our need.<\/p>\n\n\n\n

Packer<\/h3>\n\n\n\n

Is an open source tool which allows us to create custom identical machine images for multiple platforms from a single source configuration. <\/p>\n\n\n\n

Packer Template Workflow :<\/h6>\n\n\n\n

Builders<\/strong>: Are responsible for creating machines and generating images from them for various platforms.<\/p>\n\n\n\n

Provisioners<\/strong>: Use builtin and third-party software to install and configure the machine image after booting.<\/p>\n\n\n\n

Post-processors<\/strong>: Are optional, and they can be used to upload artifacts, or to generate outputs of the artifacts build or generated.<\/p>\n\n\n\n

<\/p>\n\n\n\n

What’s in the Project<\/strong><\/p><\/blockquote>\n\n\n\n

In this project, we will be baking an AMI using Packer, handling configuration with Bash Script during the baking process to host a static website. We need to make sure nginx is enabled in systemctl and starts on every boot so it is ready to process immediately. And, using Terraform we gonna provision our servers, followed by software release deployment strategies to check and test our infra model.<\/p>\n\n\n\n

The essence is, we will be deploying two versions of our code with two different machine images V1 and V2 to see the purpose of Immutable Infrastructure with Re-Create deployment strategy. <\/p>\n\n\n\n

Step 1 <\/strong>: Setup Packer Template to Generate the AMI<\/strong><\/p>\n\n\n\n

In this step, we are going to create a Packer Template with the use of Builders for AWS Platform<\/strong> to create AMI, using Bash Script as Provisioners<\/strong> to configure our machine with the static website page and the restart of our Nginx Service. And, Post-processors as Manifest<\/strong> type to generate the output.json file to get our AMI ID.<\/p>\n\n\n\n

The template code can be found here<\/a>. We will be using Jenkins to build the image, the Jenkins file is kept with the code itself. And we will be getting the output.json file as a post-processing step giving us the AMI ID.<\/p>\n\n\n\n

\"\"
Packer Job Pipeline Dashboard<\/figcaption><\/figure><\/div>\n\n\n\n
\"\"
Output.json generating the build and Artifacts details<\/figcaption><\/figure><\/div>\n\n\n\n

Step 2 <\/strong>: Setup Terraform to<\/strong> Provision and Deploy our Infra using above AMI<\/strong>‘s<\/p>\n\n\n\n

In this step, we are going to create Terraform manifests to provision our Infra by creating an Application Load Balancer and, Auto-Scaling Group using Launched Template, in our case will be making use of default network system of AWS account.<\/p>\n\n\n\n

The manifest code can be found here<\/a>. The AMI ID is passed to the Launched Template using vars.tf<\/code> to provision and deploy our V1<\/strong> Application. To run this code we have another Jenkins Pipeline<\/a> job which registers the provisioned computes under the Load Balancer and their desired capacity is managed by ASG.<\/p>\n\n\n\n

\"\"
Blue Ocean View Of CD pipeline<\/figcaption><\/figure><\/div>\n\n\n\n

If we follow the Pipeline, we have deployed the Basic Infra of our V1 application which can be accessed by the endpoint provided by the Application Load Balancer.<\/p>\n\n\n\n

TADA !! Our V1 Application is Ready \ud83d\ude42<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

As we mentioned above we will be following the Re-Create Deployment Strategy which states: deployment consists of shutting down V1 then deploying V2 after V1 is turned off<\/strong>. If we follow the Continuous Delivery pipeline of deploying Infra then we will see that it asks for a manual approval of shutting down the V1 infra and deploying the V2 infra, besides V1 AMI we did created our V2 AMI as well at the same time.<\/p>\n\n\n\n

And, once we proceed with the approval of shutting down our V1 Infra, it brings the change to desired capacity of computes to zero for our ASG configuration as follows :<\/p>\n\n\n\n

stage('Bringing down V1 VMs') {\n            input {\n                message \"Shall we bring down V1 VM's?\"\n                ok \"Yes, we should.\"\n            }\n            steps {\n                sh '''\n                cd cd\/tf\n                terraform init\n                terraform validate\n                terraform plan -var='ami_id=ami-xxxxx' -var='min_capacity=0' -var='desired_capacity=0' -out myplan\n                terraform apply --auto-approve myplan\n                '''\n            }\n        }<\/pre>\n\n\n\n
Which deletes the infra of V1 and then start deploying the V2 and register these computes behind our Load Balancer which can be accessed and given O\/P as <\/p>\n\n\n\n
TADA !! V2 Application Up and Running \ud83d\ude42<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Conclusion<\/h3>\n\n\n\n
In this blog we have uncovered how Packer and Terraform can remarkably reduce the overhead of revising the pre-configured golden AMIs by the means of IAAC helping us incorporate the entire provisioning in our CI\/CD pipelines empowering the immutable infrastructures.<\/p>\n\n\n\n
Bonus : <\/strong>The way we had introduced the Re-create<\/strong> strategy over the post, we have implemented for Rolling Strategy <\/a> as well. Do give it a try and share your experience with us in the comment box. <\/p>\n\n\n\n
Till then Keep Deploying \ud83d\ude42<\/p>\n\n\n\n
  Blog Pundit:<\/strong> Adeel Ahmad<\/a> <\/strong>and Naveen Verma<\/strong><\/a><\/p>\n\n\n\n
Opstree<\/a> is an End to End DevOps solution provider<\/p>\n\n\n\n
\n
CONTACT US<\/a><\/div>\n<\/div>\n\n\n\n
Connect Us <\/strong><\/p>\n\n\n\n