In this article I will demonstrate how to start developing serverless web applications in Amazon Web Services (AWS). A serverless architecture allows developers to focus on their code — the complexity of building and maintaining the infrastructure necessary to run the code is removed from their view.

Design

Starfleet has asked you to create a web application that will allow fleet Captains to view their log entries. There are no servers in the future so you will have to do it with serverless!

We can achieve this with the following design:

Our front-end code will be stored in S3, served via CloudFront. A Route 53 record will be created for our example.com domain. The “back-end” code will be delivered via API Gateway with data storage in Secrets Manager and DynamoDB.

Prerequisites

Before we can deploy our design we need to setup a Route 53 zone and a wildcard AWS Certificate Mananger (ACM) certificate. Alternatively you can reuse existing resources. Ensure your certificate is a wildcard as shown below.

Serverless Framework

We will use the serverless framework CLI to build and deploy our API code. We can install it via:

$ npm install -g serverless

Next, clone the code I have developed at gitlab.com/colmmg/serverless/sls-webapp and deploy it with serverless, specifying your AWS Account ID as an argument:

$ mkdir serverless
$ cd serverless
$ git clone https://gitlab.com/colmmg/serverless/sls-webapp.git .
$ sls deploy --accountid 123456789012

Terraform

The remainder of our code will be in Terraform. You can download the binary for Terraform from terraform.io/downloads.html and unpack it anywhere on your PATH.

Now you can deploy the Terraform code I have developed at gitlab.com/colmmg/terraform/sls-webapp with:

$ mkdir terraform
$ cd terraform
$ git clone https://gitlab.com/colmmg/terraform/sls-webapp.git .
$ terraform init
$ terraform apply
var.domain
  The domain of your website.

  Enter a value: example.com
...
$ Apply complete!

Lambda@Edge

We are now ready to try our web application. Let’s see what happens when we request https://sls.example.com

Success! But… how did that work? Firstly, we requested “/” and yet we ended up at “/login/” and if we examine our S3 bucket which stores our front-end code we only see:

If our request was for “/login/” how did the “login.html” document get returned? This is where the magic of Lambda@Edge comes in. Have a look at the code at gitlab.com/colmmg/terraform/sls-webapp/blob/master/lambda-src/filter/main.py and specifically this block:

def handler(event, context):
  request = event['Records'][0]['cf']['request']
  requestedUri = request['uri']
  if requestedUri == "/":
    request['uri'] = "/home.html"
  elif requestedUri == "/login/":
    request['uri'] = "/login.html"

In the above code we update requests for “/login/” to “/login.html”. So CloudFront (which is where these Lamba@Edge functions run) requests the “login.html” from S3 and returns that to the client. If we examine our CloudWatch logs for this Lambda we can see this happening:

But… if you remember our original request was for “/” not “/login/” so how did our request become “/login/”? Again, its the Lambda@Edge function at work:

  if requestedUri == "/":
    parsedCookies = parseCookies(headers)
    if parsedCookies and 'session-id' in parsedCookies:
      sessionid = parsedCookies['session-id']
      if validSessionId(sessionid):
        return request
    redirectUrl = "https://" + headers['host'][0]['value'] + "/login/"
    response = {
      'status': '302',
      'statusDescription': 'Found',
      'headers': {
        'location': [{
          'key': 'Location',
          'value': redirectUrl
        }]
      }
    }
    return response

In this code block, the Lambda is checking the request for the presence of a session id and if none is found it responds with a redirect to the “/login/” page.

Session Management

Let’s login to the application. In gitlab.com/colmmg/terraform/sls-webapp/blob/master/secrets-manager.tf we have deployed two passwords to Secrets Manager. Try logging in with either:

Username = picard
Password = makeitso

Username = kirk
Password = KHAAAN!!!

I chose Picard 🙂 and the web application has successfully returned my logs. Now let’s dig into what happened here. Firstly, if we look at the serverless framework code at gitlab.com/colmmg/serverless/sls-webapp/blob/master/handlers/login.py we can see that after the password is checked against what is stored in Secrets Manager an item is put into the “my-serverless-website-sessions” DynamoDB table.

def setSessionId():
  global SESSION_ID
  SESSION_ID = secrets.token_urlsafe()
  try:
    dynamodb = boto3.client('dynamodb', AWS_REGION)
    epoch = epoch = datetime.datetime.utcfromtimestamp(0)
    now = datetime.datetime.utcnow()
    diff = (now - epoch).total_seconds()
    now_seconds = int(diff)
    ttl = now_seconds + 60
    dynamodb.put_item(TableName='my-serverless-website-sessions', Item={'userName':{'S':USERNAME},'session-id':{'S':SESSION_ID},'creationTime':{'N':str(now_seconds)},'ttl':{'N':str(ttl)}})
  except ClientError as err:
    return None

A neat feature of DynamoDB is Time to Live which allows you to set when an item in your table expires. DynamoDB will automatically remove the item after this time (though not immediately). You can view the table in the DynamoDB console to see existing sessions.

The login API returns the session id to the client which is then saved to a cookie and the home (“/”) page is requested. This is when the home API is invoked. In this API, we get the userName from the session id by looking up the “my-serverless-website-sessions” DynamoDB table. If an item exists we then query the “my-serverless-website-logs” DynamoDB table for this user and return the results to the client for display.

As mentioned, the TTL feature of DynamoDB does not instantly remove items after they expire so our code should really verify that a session id is still valid. This logic is not present in the sample code.

Handling Errors

Cloudfront will by default, lookup S3 for whatever the user requests. So if a user requested “/foo” then Cloudfront will try to find a key named “foo”. If not found, a rather ugly error will be displayed to the user. To avoid this, we can enable a feature of CloudFront that will respond with a custom path whenever certain error codes would be returned. This setting is enabled in the gitlab.com/colmmg/terraform/sls-webapp/blob/master/cloudfront.tf code:

resource "aws_cloudfront_distribution" "my-serverless-website" {
  ...
  custom_error_response {
    error_code         = "403"
    response_code      = "403"
    response_page_path = "/error.html"
  }

So now when errors occur we get a much prettier output:

Cleanup

If you have deployed my Terraform and serverless code to your environment you can clean it up with the following steps:

$ cd terraform
$ terraform destroy
$ cd ../serverless
$ sls remove --accountid 123456789012

Note: you might get an error when destroying the terraform stack. Lambda@Edge resources can take some time (as much as 24 hours) before they are fully removed. So you should repeat the destroy of terraform a day or two later.

Summary

That’s it! I hope this very simple example has demonstrated the capabilities of a serverless architecture.

In this article I will show how you can use AWS CodePipeline and Chef Zero to implement a blue-green continuous deployment model to automatically release changes to your EC2 hosted web application.

AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application and infrastructure updates. CodePipeline automates the build, test, and deploy phases of your release process every time there is a code change, based on the release model you define.

Chef Zero

We will use Chef to define the state of each EC2 instance that hosts our web application. At gitlab.com/colmmg/chef/codepipeline-chefzero-webapp I have created a very simple cookbook that will install Apache Tomcat and deliver some custom files to be served by the web application.

AWS CodeBuild

If you are familiar with Chef but not with AWS CodePipeline you might be curious about the buildspec.yml file in the cookbook repository.

This file is used in the build phase of our pipeline to instruct AWS CodeBuild to install Chef Workstation and package our cookbooks using Berkshelf.

AWS CodeDeploy

Another file of note is the appspec.yml file. This is used in the deploy phase of the pipeline to instruct AWS CodeDeploy how to update / install our web application code.

In this example the appspec.yml file instructs CodeDeploy to execute scripts/install.sh and it is in this file where we run Chef Zero.

Terraform Code

In order to create a pipeline in AWS CodePipeline we first need to create some prerequisite AWS resources such as an AWS CodeCommit repository to store our application code as well as the AWS CodeBuild and AWS CodeDeploy resources I mentioned earlier. Additionally, we need a running web application to actually deploy our code to. I have created some Terraform code at gitlab.com/colmmg/terraform/codepipeline-chefzero-webapp that will provision these resources for us.

$ mkdir ~/codepipeline-demo
$ cd ~/codepipeline-demo
$ git clone https://gitlab.com/colmmg/terraform/codepipeline-chefzero-webapp.git terraform
$ cd terraform
$ vi terraform.tfvars
$ terraform init
Terraform has been successfully initialized!

$ terraform apply
data.template_file.user-data: Refreshing state...

Plan: 28 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_security_group.asg: Creating...
aws_iam_role.codebuild: Creating...
Apply complete! Resources: 28 added, 0 changed, 0 destroyed.

AWS CodeCommit

An additional prerequisite step is to publish the cookbook code to the CodeCommit repository that was created by Terraform. First, ensure your working environment is configured to work with CodeCommit by refering to this document.

Now you can clone my cookbook code from GitLab.

$ cd ~/codepipeline-demo
$ git clone https://gitlab.com/colmmg/chef/codepipeline-chefzero-webapp.git colmmg-chef

Next, get the HTTPS clone URL of your CodeCommit repository from the AWS Console.

You can now push my cookbook code to your repository by running the following.

$ cd ~/codepipeline-demo
$ git clone <<YOUR_HTTPS_CLONE_URL>> chef
$ cd chef
$ cp -r ../colmmg-chef/* .
$ git add --all
$ git commit -m "Initial commit"
$ git push origin master

AWS CodePipeline Setup

We are now ready to create our pipeline! Open the CodePipeline service in the AWS Console and click to create a new pipeline.

In the first step, select the “codepipeline-chefzero-webapp” IAM role and “codepipeline-artifacts” S3 bucket.

In the source step, select AWS CodeCommit.

Choose AWS CodeBuild for the build stage.

Lastly, select AWS CodeDeploy for the deploy stage.

Review your choices in the next page and then create the pipeline. Your pipeline will automatically start.

AWS CodePipeline

Each stage of the pipeline will be executed starting with the retrieval of the cookbook code from the CodeCommit repository. The next stage is the build stage where the cookbook code is packaged. From CodePipeline you can click into each stage to view more details and if we do this for the build stage we can see the build logs.

Perhaps the most interesting stage is the deploy stage. When it starts you can click into it and will see a view like this.

From this page we can see exactly what is happening with our deployment including which instances traffic is being directed to.

The page will update as the deployment progresses.

When the deployment is complete you can test the web application by retrieving the DNS record of the application load balancer that was created by Terraform.

Success!

Continuous Deployment

Now let’s give our pipeline a proper test! Suppose the product team have asked that the background image of the web application be updated and deployed. With one commit we can fulfill this request.

$ cd ~/codepipeline-demo/chef
$ sed -i "s,div id=\"blue\",div id=\"green\",g" files/default/index.jsp
$ git commit -a -m "Updating background image"
$ git push origin master

That’s it! AWS CodePipeline will now take over and automatically deploy this change. If you make requests to the web application during deployment you will see the change being rolled out, with both the old and new image being returned until finally only the new image being displayed.

Cleanup

To remove the resources that were created in this demo, first you should manually delete any autoscaling groups that CodePipeline provisioned. They will have names starting with “CodeDeploy_codepipeline-chefzero-webapp”.

Next you can destroy the Terraform infrastructure.

$ cd ~/codepipeline-demo/chef
$ terraform destroy

Now you can manually delete the pipeline from the CodePipeline service.

As part of the creation of the pipeline, a CloudWatch events rule was created. This would have been deleted when you deleted the pipeline but the associated IAM role and policy would not have been removed. The role will have a name like “cwe-role-eu-west-1-codepipeline-chefzero-webapp”. You should remove this role and the attached policy.

Wrap-Up

This is a very simple example showing some of the capabilities of CodePipeline. It, along with CodeBuild and CodeDeploy, have other features including:

• use S3 as the source instead of CodeCommit;
• deploy to a percentage of instances at a time instead of all at once;
• deploy to Amazon Elastic Container Service (ECS) and Lambda;
• add a manual approval stage to the pipeline so a human must interact with it before a deployment can occur;
• integration with Jenkins;

I hope this article and the associated code helps you get started with these very powerful services!

Introduction

The benefits of Docker containers are well understood however, the challenges in managing the host operating system remain. AWS Fargate solves this problem.

Fargate makes it easy for you to focus on building your applications. Fargate removes the need to provision and manage servers.

By outsourcing the management of the host OS to AWS you do lose some control. You can’t login to the EC2 instance and run `docker exec`! In well-tuned applications, this should not be an issue. Your logs and metrics will be pushed to Amazon CloudWatch or some other service and there should be no need to login to a container. Perhaps for that initial period of adjusting to this new model or for the times when you can debug faster with container access you may wish to have a mechanism to login to your Fargate containers. In this article I will show how you can setup such a means.

Prerequisites

To follow this guide you will need Terraform v0.12.23. Later versions may work but the guide was tested with 0.12.23.

You will also need extensive permissions to your AWS account as we will be creating resources across many services including IAM.

Design

To demonstrate access to Fargate containers we will run a Docker container in Amazon Elastic Container Service. We will build the image for this container from its source in AWS CodeCommit via AWS CodeBuild and store the image in Amazon Elastic Container Registry. The image will be Amazon Linux 2 based with an Apache server and SSH access.

SSH ingress to the Fargate containers will be via an EC2 instance designated as our ECS jump host.

Infrastructure

Let’s first setup the infrastructure. We begin by setting up some environment variables:

$ export AWS_ACCOUNT_ID=`aws sts get-caller-identity |jq .Account |xargs`
$ export AWS_REGION=us-east-1

Next we create our Amazon S3 bucket that will store our Terraform remote state:

$ aws s3 mb s3://tf-state-$AWS_REGION-$AWS_ACCOUNT_ID --region $AWS_REGION

CodePipeline

We now deploy some foundation resources that we will need to use AWS CodePipeline. CodePipeline will glue our CodeCommit repository and CodeBuild project together to form an end-to-end pipeline.

$ git clone https://gitlab.com/colmmg/terraform/fargate-ssh/infra/codepipeline.git
$ sed -i "s,123456789012,$AWS_ACCOUNT_ID,g" backend.tf
$ terraform init
$ terraform apply

ECS

Now we deploy the baseline resources required for our use of ECS. This stack will also generate the EC2 jump host that we will use later. A security group rule will be created to allow SSH ingress to the jump host from your public IP.

$ git clone https://gitlab.com/colmmg/terraform/fargate-ssh/infra/ecs.git
$ sed -i "s,123456789012,$AWS_ACCOUNT_ID,g" backend.tf
$ echo "my-ip = \"`curl ifconfig.me`\"" >> terraform.tfvars
$ ssh-keygen -t rsa -N '' -C "ECS Key" -f ~/.ssh/ecs
$ echo "ecs-public-key = \"`cat ~/.ssh/ecs.pub`\"" >> terraform.tfvars

Before continuing you should copy the contents of the private key (~/.ssh/ecs) into the user_data.tpl file at the line “INSERT PRIVATE KEY HERE”.

Now, you can deploy this Terraform stack:

$ terraform init
$ terraform apply

Docker

We now need to deploy a CodePipeline project to build our Docker image.

$ git clone https://gitlab.com/colmmg/terraform/fargate-ssh/ecr-apache.git
$ sed -i "s,123456789012,$AWS_ACCOUNT_ID,g" backend.tf
$ terraform init
$ terraform apply

When complete, a build will be attempted but it will fail because our CodeCommit repo is empty.

The code that you need to push is at colmmg/docker/fargate-ssh but before we push this code to CodeCommit let me explain the configuration. The Dockerfile is straightforward, we are installing httpd and openssh and exposing ports 80 and 22. Our ENTRYPOINT is modified to run the entrypoint.sh script. In this script we start SSH in the background, we write the value of environment variable `SSH_PUBLIC_KEY` to the `/root/.ssh/authorized_keys` file and lastly we start httpd in the foreground. The `SSH_PUBLIC_KEY` environment variable is set in our ECS task definition which we will setup later.

Lets clone our CodeCommit repo. You may obtain the clone details from the CodeCommit console.

$ git clone codecommit::us-east-1://apache

Grab the code from colmmg/docker/fargate-ssh and copy it into your CodeCommit repo:

$ git clone https://gitlab.com/colmmg/docker/fargate-ssh.git /tmp/docker-fargate-ssh
$ cp /tmp/docker-fargate-ssh/* .
$ git add .
$ git commit -m "Initial commit"
$ git push origin master

If you return to the CodePipeline console you will see that our push has triggered a build.

Click on the build details to follow along as your image is built by CodeBuild.

ECS

We can now setup our ECS cluster and service that will run our Docker container.

$ git clone https://gitlab.com/colmmg/terraform/fargate-ssh/ecs-apache.git
$ sed -i "s,123456789012,$AWS_ACCOUNT_ID,g" backend.tf
$ terraform init
$ terraform apply

When complete you can navigate to the ECS service and after a short period of time a task will be launched which will be your running container:

EC2 Jump Host

With everything in place we can now test out our solution. From the EC2 service, find the EC2 instance that was launched earlier. It will be named `ecs-jumpbox`. SSH into this instance:

$ ssh -i ~/.ssh/ecs 31.55.145.64

Now try to ssh into your Docker container:

$ ssh root@apache.local
Last login: Sun Apr  5 16:16:38 2020 from ip-173-51-19-127.ec2.internal
-bash-4.2#

Success! If you are wondering how `apache.local` resolves to the container’s IP it is because as part of our deployments we configured ECS Service Discovery.

Conclusion

That’s it! I hope you find this guide useful!