Deploying infrastructure and application stacks – Rolling Out a CI/CD Pipeline

Before we can deploy pipeline resources, we need to have the underlying infrastructure and application components available. This is mainly to ensure that inter-stack dependencies are met so that the pipeline stack to be deployed successfully:

  1. From within the IDE, we can use the CloudFormation CLI to deploy both stacks:
  2. Then, we can pass the stack’s name and AMI Id while deploying the application stack. Please note that certain resource identifiers, such as Amazon Machine Image (AMI) IDs, can only be referenced in a particular region. In this case, we have used ami-09cadf1c312a9b12e, which is available in the eu-central-1 region. So, you should use the same region when running these commands:
  3. At this point, we have deployed the application, but if you try to access the URL for the Application Load Balancer, the request will end up with a 502 Bad Gateway error. This is expected since the application code has not been deployed to the EC2 instances yet. To do so, let’s bring up the CI/CD pipeline:

We now have all the resources that we need in our AWS account to roll out application changes automatically. If you check the CodePipeline configurations at this point, you will notice an error in the Source stage, as shown in Figure 5.4:

Figure 5.4 – CodePipeline snapshot immediately after CloudFormation stack deployment

As you can see, SourceAction is marked in red because the pipeline expects some code to be present in the main branch, in the configured repository. However, the repository, as expected, is empty at this point. Let’s retrieve the HTTPS (GRC) URL for the repository andpush some code to it for the pipeline to run. The URL can be retrieved from your AWS account’s web console. Go to the CodeCommit service page and select the repository we created; the Connection steps section will lead you to the HTTPS (GRC) endpoint.

Note

To work with the CodeCommit repository, you need to create separate credentials that allow HTTPS-based access. However, we will use a mechanism to bypass this behavior by using the git-remote- codecommit plugin. This is already included in the Cloud9 IDE for youruse. This plugin reads authentication data from your environment variables.

  1. Next, we need to bootstrap our directory with some Git magic:

• Initialize a Git repository and switch to the main branch:

• Configure git remote and add files to the staging area, followed by an initial commit:

• Push the code:

As shown in Figure 5.5., soon after the code was pushed, CodePipeline picked up the change and ran the pipeline. Once the flow reaches the Deploy stage, CodeDeploy instructs its agents running inside the EC2 instances to pull code from the artifact repository and bring up the Python-based web server:

Figure 5.5 – Execution of different stages in the pipeline

The EC2 instances now start responding to incoming requests from the application load balancer, as seen in Figure 5.6:

Figure 5.6 – Response from the Application Load Balancer after the pipeline finished execution

You can also make additional modifications in the web_server.py file at this point, followed by a code push to see the deployment in action.

I hope this exercise gave you good hands-on experience working with CodePipeline.

Leave a Comment