1 of 75

Module 8: Introducing Containers and Container Services

AWS Academy Cloud Developing

2 of 75

Section 1: Introduction

Module 8: Introducing Containers and Container Services

3 of 75

Module objectives

At the end of this module, you should be able to do the following:

Describe the history, technology, and terminology behind containers
Differentiate containers from bare-metal servers and virtual machines (VMs)
Illustrate the components of Docker and how they interact
Identify the characteristics of a microservices architecture
Recognize the drivers for using container orchestration services and the AWS services that you can use for container management
Host a dynamic website by using Docker containers
Describe how AWS Elastic Beanstalk is used to deploy containers

3

4 of 75

Module overview

Sections

Introduction
Introducing containers
Introducing Docker containers
Using containers for microservices
Introducing AWS container services
Deploying applications with Elastic Beanstalk

Lab

Lab 1: Migrating a Web Application to Docker Containers
Lab 2: Running Containers on a Managed Service

4

Knowledge check

5 of 75

Café business requirement

5

Frank and Martha recently acquired a coffee bean supplier, and they would like to include the supplier’s inventory tracking system into the café's application infrastructure. Sofía is thinking about migrating the application database to containers to complete the integration.

6 of 75

Containers as part of developing�a cloud application

6

7 of 75

Section 2: Introducing containers

Module 8: Introducing Containers and Container Services

8 of 75

Shipping containers

Before shipping containers

Goods were shipped in a variety of vessels with no standardized weight, shape, or size.
Transporting goods was slow, inefficient, and costly.

After shipping containers

Uniformly sized shipping containers simplified loading, unloading, storing, and transferring between transport types.
Abstraction of shipment details improved efficiency, increased productivity, and reduced costs.

8

In the physical world, a container is a standardized unit of storage. Container sounds like a generic term, but its importance is clearer if you look at how containers changed the shipping industry.

Before the introduction of the modern shipping container in 1956, transporting goods from one point to another was a challenge. Goods were shipped in sacks, crates, cartons, drums, casks, barrels, and boxes of various weights, shapes, and sizes. They often were loaded by hand into whatever vessel was carrying them. The vessel wouldn’t know how much cargo it could take until all of the cargo was loaded. Transporting goods this way was slow, inefficient, and costly.

Shipping containers revolutionized the shipping industry. Their uniform size made it much more efficient to load, unload, and stack them. Containers could also be easily moved between ships, trucks, and railroad cars. In this way, containers improved efficiency, increased productivity, and reduced costs.

Source: https://www.worldshipping.org/educational-resources

This resource contains a great example of using abstraction to increase agility. Abstraction, in this sense, means that the people who are involved in shipping are further removed from the details of the transaction. This abstraction applies to the people who send the contents and those who actually facilitate the shipping itself. They don’t need to worry about whether items will fit in a given container or about the fit of the container onto various vessels. Abstraction is a way of hiding the working details of a subsystem. It separates concerns to facilitate interoperability and platform independence.

9 of 75

A container is a standardized unit of software

9

Runtime engine
Application code
System tools
System libraries

This concept can move from the physical world to the virtual world of computing platforms. Virtually, a container is a standardized unit of software designed to run quickly and reliably on any computing environment that runs the containerization platform.

Containers provide operating system (OS) virtualization so that you can run an application and its dependencies in resource-isolated processes. A container is a lightweight, standalone software package that contains everything that a software application needs to run. For example, it can contain the application code, runtime engine, system tools, system libraries, and settings. Containers can help ensure that applications deploy quickly, reliably, and consistently regardless of the deployment environment.

A single server can host several containers that all share the underlying host system’s OS kernel. These containers might be services that are part of a larger enterprise application, or they might be separate applications that run in their isolated environment.

10 of 75

Evolution of deployment models: �Bare-metal servers

10

Host server

Host OS

Libraries

Applications A, B, C

Applications compete for server resources

Library versions must be shared across applications

Inflexible hardware costs

Increasing levels of abstraction are often associated with technical maturity. The move toward containers is part of the evolution of deployment models.

In earlier phases, you had bare-metal servers. You had to build the architectural layers, such as the infrastructure and application software layers. For example, you would install an OS on top of your server hardware. Then, you would install any shared libraries on the OS, and then install the applications that use those libraries. This architecture was inefficient.

Your hardware costs are the same whether you are running at 0 percent utilization or 100 percent utilization. All of your applications must compete for the same resources, and you must keep the versions of your libraries in sync with all your applications. If one application requires an updated version of a library that is incompatible with other applications running on that host, then you run into problems.

11 of 75

Evolution of deployment models:�VMs

11

Host server

Host OS

Virtualization platform

VM

Guest OS

Libraries

Application� A

VM

Guest OS

Libraries

Application�B

VM

Guest OS

Libraries

Application� C

Isolated applications

Isolated libraries

Better resource utilization

More OS maintenance

More server space for OS

12 of 75

Evolution of deployment models: Containers

12

Host server

Host OS

Containerization platform

Shared libraries

Container

Application� A

Bins/libs

Container

Bins/libs

Application B

Container

Bins/libs

Application C

Better resource utilization

Shared OS kernel

Shared or isolated libraries

Highly portable ;�applications run identically across environments

Lightweight, efficient, and fast

13 of 75

Section 2 key takeaways

A container is a standardized unit of software that contains everything that an application needs to run.
Containers help to ensure that applications deploy quickly, reliably, and consistently regardless of the deployment environment.

13

14 of 75

Section 3: Introducing Docker containers

Module 8: Introducing Containers and Container Services

15 of 75

Docker container virtualization platform

Lightweight container virtualization platform

Tools to create, store, manage, and run containers

Integration with automated build, test, and deployment pipelines

15

16 of 75

Docker container benefits

Portable runtime application environment
Application and dependencies can be packaged in a single, immutable artifact
Ability to run different application versions with different dependencies simultaneously
Faster development and deployment cycles
Better resource utilization and efficiency

16

17 of 75

Docker container components

17

Layer 1

Layer 2

Layer 3

Layer 4

Dockerfile

Plain text file that provides instructions to create a container image

Container image

Read-only template that is used to create writable containers

Container�Runnable instance of an image

Container registry�Private or public images that you can base other images on

Container layer

Thin read/write layer that is used to �make changes to the running container

Docker containers are created from read-only templates, which are called container images. Images are immutable and highly portable. You can port an image to any environment that supports Docker. Images are composed of layers.

Images are built from a Dockerfile, which is a plain text file that specifies all of the components that are included in the container. Instructions in the Dockerfile create layers in the container image.

You can create images from scratch, or you can use images that others created and published to a public or private container registry.

An image is usually based on another image, with some customization. For example, you might build an image that’s based on the Ubuntu Linux image in the registry. The image could also install a web server and your application, in addition to the essential configuration details to make your application run.

A container is a runnable instance of an image. You can create one container or several containers based on that image.

Each container has a thin, read/write layer on top of the existing image when it is instantiated. This architecture is what makes the actual process of instantiating the containers fast. Most of the actual work is read-only because of the file system layers. The read/write layer of the container enables your applications to function properly while they are running, but it’s not designed for long-term data storage. Persistent data should be stored in a volume somewhere. Consider a container as a discrete compute unit, not a storage unit.

18 of 75

Dockerfile simple example

18

# Start with the Ubuntu latest image

FROM ubuntu:latest

# Output hello world message

CMD echo "Hello World!"

19 of 75

Dockerfile example: �Start a Java application

19

# Start with open JDK version 8 image

FROM openjdk:8

# Copy the .jar file that contains your code from your system to the container

COPY /hello.jar /usr/src/hello.jar

# Call Java to run your code

CMD java –cp /usr/src/hello.jar

Org.example.App

20 of 75

Dockerfile example:�Common tasks

20

# Start with CentOS 7 image

FROM centos:7

# Update the OS and install Apache

RUN yum –y update && yum –y install httpd

# Expose port 80—the port that the web server “listens to”

EXPOSE Port 80

# Copy shell script and give it run permissions

ADD run-httpd.sh /run-httpd.sh

RUN chmod –v +x /run-httpd.sh

# Run shell script

CMD ["/run-httpd.sh"]

21 of 75

Each line of the Dockerfile adds a layer

21

# 1 Start with CentOS 7 image

FROM centos:7

# 2 Update the OS and install Apache

RUN yum –y update && yum –y install httpd

# 3 Expose port 80

EXPOSE Port 80

# 4 Copy shell script and give it run permissions

ADD run-httpd.sh /run-httpd.sh

RUN chmod –v +x /run-httpd.sh

CMD ["/run-httpd.sh"]

Image layers (read-only)

RUN yum –y update && yum –y �install httpd

EXPOSE 80

ADD run-httpd.sh /run-httpd.sh

RUN chmod –v +x /run-httpd.sh

Base: CentOS 7

1

2

3

4

22 of 75

Docker CLI commands

22

Command	Description
docker build	Build an image from a Dockerfile.
docker images	List images on the Docker host.
docker run	Launch a container from an image.
docker ps	List the running containers.
docker stop	Stop a running container.
docker start	Start a container.
docker push	Push the image to a registry.
docker tag	Tag an image.

Command	Description
docker logs	View container log output.
docker port	List container port mappings.
docker inspect	Inspect container information.
docker exec	Run a command in a container.
docker rm	Remove one or more containers.
docker rmi	Remove one or more images from the host.
docker update	Dynamically update the container configuration.
docker commit	Create a new image from a container's changes.

You can run Docker command line interface (CLI) commands from a Bash terminal to manage your Docker images and containers.

For example, you can build an image from a Dockerfile by running docker build. You can then verify your image by running docker images. To launch a container from the image, run docker run. To verify that the container is running, enter docker ps.

After you launch a container, you can interact with it in a variety of ways. To open a Bash prompt on your running container, use docker exec. You can also stop a running container (docker stop) and start it again (docker start). To view your container logs, enter docker logs. To list the port mappings for your container, run docker port. Run docker tag to tag your image and use docker push to push it to a registry.

For more information about Docker CLI commands, see https://docs.docker.com/engine/reference/commandline/cli/.

23 of 75

Example of docker build command

Build an image from a Dockerfile in the current directory, and name the image node_app

23

docker build --tag node_app .

Task

Docker command

Sending build context to Docker daemon 9.007MB

Step 1/7 : FROM node:11-alpine

11-alpine: Pulling from library/node

…

Successfully built a5886f101e12

Successfully tagged node_app:latest

Example output

24 of 75

Example of docker images command

List the images that your Docker client is aware of

24

docker images

Task

Docker command

Example output

REPOSITORY	TAG	IMAGE ID	CREATED	SIZE
<none>	node_app:latest	a5886f101e12	18 seconds ago	82.7MB

25 of 75

Example of docker run command

Create a container named node_app_1 from the image named node_app
Run in the background and print the container ID to the terminal
Publish container port 8000 to the host port 80 to make the container available to other services for HTTP

25

docker run -d --name node_app_1 -p 8000:80 node_app

Tasks

Docker command

Example output

5ed1ea04bcb58194100f71b2e7cd0aecab182313692ed833a6a700664994785f

docker ps

CONTAINER ID	IMAGE	COMMAND	CREATED	STATUS	PORTS
5ed1ea04bcb5	node_app	"docker-entrypoint.s…"	9 seconds ago	Up 7 seconds	0.0.0.0:8000->80/tcp

This example runs the docker run command to create a container from the node_app image.

The -d (or –detach) argument specifies that it should run in the background and print the container ID.

The –name argument specifies that the container should be named node_app_1.

The -p (or –publish) argument specifies to publish container port 8000 to the host port 80. By default, when you create or run a container by using docker create or docker run, it does not publish any of its ports to the outside world. The –p tag makes a port available to services outside Docker or to Docker containers that are not connected to the container’s network. This technique creates a firewall rule, which maps a container port to a port on the Docker host to the outside world.

The visible output of this command is the container ID. You could follow this up with the docker ps command, as illustrated in this slide, to further verify that the container is running.

26 of 75

Example of docker exec command

Start an sh terminal session on a running container
List the files in the user/src/app directory
Exit the shell session on the running container

26

docker exec -it node_app_1 sh

Tasks

Docker command

Example output

/usr/src/app #

/usr/src/app # ls

�Dockerfile README.md app index.js network.template node_modules package-lock.json package.json public views

/usr/src/app # exit

27 of 75

Example of docker stop and docker rm commands

Stop the container
Remove the container

27

docker stop node_app_1 && docker rm node_app_1

Tasks

Docker command

Example output

node_app_1

28 of 75

Section 3 key takeaways

Docker containers are created from read-only templates, which are called images.
Images are built from a Dockerfile and often based on other images.
Containers are runnable instances of an image with a writable layer.
A container registry is a repository of images.
To manage your Docker images and containers, you can run Docker command line interface (CLI) commands from a Bash terminal.

28

29 of 75

Lab 8.1: Migrating a Web Application to Docker Containers

29

30 of 75

Lab: Scenario

Recently, the café owners acquired one of their favorite coffee suppliers. The acquired coffee supplier runs an inventory tracking application on an AWS account.

In this lab, you again play the role of Sofía, and you will work to migrate the application to run on containers.

30

31 of 75

Lab: Tasks

Preparing the development environment
Analyzing the existing application infrastructure
Migrating the application to a Docker container
Migrating the MySQL database to a Docker container
Testing the MySQL container with the node application
Adding the Docker images to Amazon ECR

31

32 of 75

Lab: Final product

32

AWS Cloud9 EC2 instance (being used as a container host)

EC2 instance guest OS

Bins/libs

node app

Docker engine

Docker container

Network

connectivity

Bins/libs

mysql

Docker container

33 of 75

Begin Lab 8.1: Migrating a Web Application to Docker Containers

33

~ 90 minutes

34 of 75

Lab debrief: �Key takeaways

34

35 of 75

Section 4: Using containers for microservices

Module 8: Introducing Containers and Container Services

36 of 75

Comparing monolithic�and microservice architectures

36

Storefront UI

Account service

Cart service

Shipping service

Data access service

Storefront UI (Node.js)

Account service (Node.js)

Cart service (Python)

Shipping service (Java)

Monolithic

Microservices

Database

Load balancer

Browser

Load balancer

Browser

One of the strongest factors that drive the growth of containers is the rise of microservice architectures. Microservices are an architectural and organizational approach to software development that is designed to speed up deployment cycles. The microservices approach fosters innovation and ownership, and improves the maintainability and scalability of software applications.

Consider this example of a traditional monolithic architecture. For this shopping application, all of the processes are tightly coupled. With tightly coupled processes, if one process of an application experiences a spike in demand, the entire architecture must be scaled. Adding or improving features becomes more complex as the code base grows, which limits experimentation and complicates the implementation of new ideas or technology stacks. Monolithic architectures also add risk for application availability because having many dependent and tightly coupled processes increases the impact of a single process failure.

Now, consider having the same applications run in a microservice architecture. Each service is built as an independent component that communicates by using lightweight API operations. Each service performs a single function that could support multiple applications. Because the services run independently, they can be updated, deployed, and scaled to meet the demand for specific functions of an application.

37 of 75

Microservices and containers

37

Microservices design	Container characteristics
Decentralized, evolutionary design Smart endpoints, dumb pipes	Each container uses the language and technology that are best suited for the service. Each component or system in the architecture can be isolated, and can evolve separately, instead of updating the system in a monolithic style.
Independent products, not projects	You can use containers to package all of your dependencies and libraries into a single, immutable object.
Designed for failure Disposable	You can gracefully shut down a container when something goes wrong and create a new instance. You start fast, fail fast, and release any file handlers. The development pattern is like a circuit breaker. Containers are added and removed, workloads change, and resources are temporary because they constantly change.
Development and production parity	Containers can make development, testing, and production environments consistent. This consistency facilitates DevOps, in which a containerized application that works on a developer's system will work the same way on a production system.

38 of 75

Section 5: Introducing AWS container services

Module 8: Introducing Containers and Container Services

39 of 75

Challenges of managing containers at scale

State of containers
Scheduling of starts and stops
Resources available on each server
Maximizing availability, resilience, and performance

39

Recall the shipping container analogy. Suppose that you have one ship and a half dozen containers. Keeping track of what's being shipped on which transport, the schedule of starts and stops, and the state of the containers is manageable. However, consider what happens when you scale up the number and type of transportation methods, along with the number of containers you are working with. Scheduling and managing which are loaded, where, and when requires a lot more logistical effort.

Likewise with software containers, running one or two containers on a single host is simple. But things get complex when you move into environments where you have tens of hosts with possibly hundreds of containers. Or you might have a full production environment with hundreds of hosts and maybe thousands of containers. You now must manage an enterprise-scale, clustered environment.

You must know the state of everything in your system. For example, you need to know which containers aren't working, and which are starting and stopping. You need to know where you have enough room and memory to add new containers. Finally, you need a way to place your containers intelligently on instances to maximize availability, resilience, and performance.

40 of 75

Container orchestration platforms

Scheduling

Placement

Service integration

40

41 of 75

Amazon ECS

Fully managed container orchestration service

Scales rapidly to thousands of containers with no additional complexity
Schedules placement across managed clusters
Integrates with third-party schedulers and other AWS services

41

Amazon Elastic Container Service (Amazon ECS)

42 of 75

Amazon ECR

Fully managed container registry that you can use to easily store, run, and manage container images for applications that run on Amazon ECS

Scalable and highly available
Integrated with Amazon ECS and Docker CLI
Secure:

Encryption at rest
Integration with the AWS Identity and Access Management Service (IAM)

42

Amazon Elastic Container Registry (Amazon ECR)

Amazon ECR is a fully managed, cloud-based Docker image registry that makes it easy for you to store, manage, and deploy Docker container images. Amazon ECR integrates with Amazon ECS and the Docker CLI, which simplifies your development and production workflows. You can push your container images to Amazon ECR by using the Docker CLI from your development machine. Then, Amazon ECS can pull them directly for production deployments.

Amazon ECR reduces the need to operate your own container repositories or be concerned about scaling the underlying infrastructure. Amazon ECR hosts your images in a highly available and scalable architecture, which enables you to reliably deploy containers for your applications. Amazon ECR is also secure. Amazon ECR transfers your container images over HTTPS, and it automatically encrypts your images at rest. You can configure policies to manage permissions for each repository and restrict access to IAM users, roles, or other AWS accounts.

For more information about Amazon ECR, see the product page at https://aws.amazon.com/ecr/.

43 of 75

Amazon ECS solution architecture

43

Select the launch type

Amazon �ECS

AWS �Fargate

Amazon�EC2

Other �container �registry

Amazon �ECR

Pull the container �image from �a registry

Define your�application

Manage �your containers

The following procedure is a high-level overview of Amazon ECS.

First, container images are pulled from a registry. This registry can be Amazon ECR—which is one of many AWS services that integrate with Amazon ECS—or a third-party or private registry.

Next, you define your application. Customize the container images with the necessary code and resources, and then create the appropriate configuration files to group. Then, define your containers as short-running tasks or long-running services within Amazon ECS.

When you are ready to bring your services online, you select one of two launch types: AWS Fargate or Amazon EC2. You can mix and match the two launch types as needed within your application. The next slide highlights distinctions between these two launch types.

Finally, you can use Amazon ECS to manage your containers. Amazon ECS scales your application and manages your containers for availability.

44 of 75

Amazon ECS with Fargate�or Amazon EC2

44

Docker engines (one per OS in the cluster)

Bins/libs

App 1

Bins/libs

App 2

Bins/libs

App 3

Containers

VM guest operating systems in the Amazon ECS cluster

Container instance 1

Container instance 2

Container instance 3

AWS manages

You manage

Amazon ECS cluster backed by Fargate

Amazon ECS cluster backed by Amazon EC2

You manage

Choose Amazon EC2:

More predictable resource requirements, or the option of using reserved instances to reduce costs
Large workloads that are optimized for price
Compliance with organizational security requirements
Excess Amazon EC2 capacity

Choose Fargate:

Services subject to wide swings in demand
Large workloads that are optimized for low overhead
Small test environments
Batch workloads that run on a schedule

The Fargate launch type provides a near-serverless experience, where AWS completely manages the infrastructure that supports your containers. AWS manages the placement of your tasks on instances, and makes sure that each task has the appropriate amount of CPU and memory. With Fargate, you can focus on the tasks and the application architecture, instead of worrying about the infrastructure.

The Amazon EC2 launch type is useful when you want more control over the infrastructure that supports your tasks. When you use the Amazon EC2 launch type, you create and manage clusters of EC2 instances to support your containers. You also define the placement of containers across your cluster based on your resource needs, isolation policies, and availability requirements. You have more granular control over your environment without operating your own cluster management and configuration management systems, or worrying about scaling your management infrastructure.

For example, you can use EC2 to launch services that have more predictable resource requirements. You can use Fargate to launch other services that are subject to wide swings in demand. Regardless of the launch type that you use, Amazon ECS manages your containers for availability, and it scales your application as necessary to meet demand.

For more information about AWS Fargate, see the product page at https://aws.amazon.com/fargate/.

For more information about the Fargate and EC2 launch types, see https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html.

45 of 75

Creating an Amazon ECR repository�and pushing an image

45

# Create a repository called hello-world

> aws ecr create-repository \

--repository-name hello-world \

--region us-east-1

# Build and tag an image

> docker build -t hello-world .

> docker tag hello-world:latest aws_account_id.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest

# Authenticate Docker to your Amazon ECR registry

# You can skip the `docker login` step if you have amazon-ecr-credential-helper set up

> aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com

# Push an image to your repository

> docker push aws_account_id.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest

You can programmatically access Amazon ECR from the AWS Command Line Interface (AWS CLI) and by using the APIs. You can use the AWS CLI and APIs to create, monitor, and delete repositories and set repository permissions. You can perform these same actions in the Amazon ECR console, which you can access from the Amazon ECS console. Amazon ECR integrates with the Docker CLI, which allows you to push, pull, and tag images on your development machine.

This example shows how to create a repository that is called hello-world with Amazon ECR. The example uses Docker CLI commands to build and tag an image, and then push it into the repository. To push an image into Amazon ECR, you must first authenticate the Docker client to your Amazon ECR registry.

For more information, see the following resources:

Using Amazon ECR with the AWS CLI: https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html
Authenticating Amazon ECR Repositories for Docker CLI with Credential Helper: https://aws.amazon.com/blogs/compute/authenticating-amazon-ecr-repositories-for-docker-cli-with-credential-helper/

46 of 75

Amazon EKS

Managed service that runs Kubernetes on �the AWS Cloud

Built with the Kubernetes community
Conformant and compatible
Secure by default

46

Amazon Elastic Kubernetes Service (Amazon EKS)

Kubernetes is an open-source container management platform that you can use to deploy and manage containerized applications at scale. Kubernetes manages clusters of EC2 instances, and it runs containers on those instances with processes for deployment, maintenance, and scaling. By using Kubernetes, you can run any type of containerized application by using the same toolset on premises and in the cloud.

You can use AWS services to run Kubernetes in the cloud. These services include scalable and highly available VM infrastructure, community created service integrations, and Amazon Elastic Kubernetes Service (Amazon EKS). Amazon EKS is a managed service that runs the Kubernetes management infrastructure across multiple Availability Zones to reduce the chance of a single point of failure.

Amazon EKS is certified Kubernetes conformant, so you can use existing tools and plugins from partners and the Kubernetes community. Applications that run on any standard Kubernetes environment are fully compatible, and they can be migrated to Amazon EKS. Amazon EKS automatically sets up secure and encrypted channels to your worker nodes, which makes your infrastructure that runs on Amazon EKS secure by default. AWS actively works with the Kubernetes community by contributing to the Kubernetes code base, which helps Amazon EKS users employ AWS services and features.

For more information about Amazon EKS, see the product page at https://aws.amazon.com/eks/.

47 of 75

Amazon EKS

47

Amazon EKS

Run Kubernetes�applications

Connect to �Amazon EKS

Provision an �Amazon EKS �cluster

Amazon EC2

Deploy worker�nodes for your�Amazon EKS�cluster

Fargate

48 of 75

Section 5 key takeaways

Container orchestration services (or systems) simplify managing containers at scale.
Amazon ECS is a fully managed container orchestration service that you can use to launch containers to either Fargate or EC2 instances.
Amazon ECR is a fully managed container registry service.
Amazon EKS is a managed service that you can use to run Kubernetes in the cloud.

48

49 of 75

Section 6: Deploying applications with�Elastic Beanstalk

Module 8: Introducing Containers and Container Services

50 of 75

Elastic Beanstalk

Service for deploying and scaling web applications and services

Automatically handles deployment details like capacity provisioning, load balancing, automatic scaling, and application health monitoring
Provides a variety of platforms on which to build your applications
Use to manage all of the resources that run your application as an environment

50

AWS Elastic Beanstalk

51 of 75

Elastic Beanstalk components

51

Component	Description
Application	Logical collection of Elastic Beanstalk components. Conceptually similar to a folder.
Application version	Specific, labeled iteration of deployable code for a web application.
Environment	Collection of AWS resources that run an application version.
Environment tier	Designation of the type of application that the environment runs. Determines what resources Elastic Beanstalk provisions to support it.
Environment configuration	Collection of parameters and settings that define how an environment and its associated resources behave.
Saved configuration	Template that you can use as a starting point for creating unique environment configurations.
Platform	Combination of an OS, programming language runtime, web server, application server, and Elastic Beanstalk components. You design and target your web application to a platform.
Elastic Beanstalk CLI	CLI for Elastic Beanstalk. Provides interactive commands that simplify creating, updating, and monitoring environments from a local repository.

52 of 75

IAM permissions in Elastic Beanstalk environments

Service role

Assigned during creation
Elastic Beanstalk assumes that it uses other services on your behalf
Default service role: �aws-elasticbeanstalk-service-role

Instance profile

Assigned during creation
Applied to instances that are launched in your environment
Default instance profile: �aws-elasticbeanstalk-ec2-role

User policies

Optionally assigned
Can be attached to users or groups who create and manage Elastic Beanstalk applications and environments
Two managed user policies are available to grant either full administrative access or read-only access

52

IAM roles assigned during environment creation

The Elastic Beanstalk permissions model requires you to assign two roles when creating an environment: the service role and the instance profile.

Service role:

Elastic Beanstalk assumes the service role to use other AWS services on your behalf.

Suppose that you create an environment with the eb create command in the Elastic Beanstalk CLI. If you don't specify a service role through the �--service-role option, Elastic Beanstalk creates the default service role, aws-elasticbeanstalk-service-role. If the default service role already exists, Elastic Beanstalk uses it for the new environment.

Instance profile:

An instance profile is a container for an IAM role that can pass role information to an EC2 instance when the instance starts.

The instance profile is applied to the instances in your environment. The instances retrieve application versions from Amazon Simple Storage Service (Amazon S3), upload logs to Amazon S3, and perform other tasks. The tasks vary depending on the environment type and platform. In multicontainer Docker environments, the instance profile coordinates container deployments with Amazon ECS.

When you launch an environment by using the Elastic Beanstalk console or the CLI, Elastic Beanstalk creates a default instance profile, called aws-elasticbeanstalk-ec2-role. Managed policies are assigned to the role with default permissions.

Elastic Beanstalk provides three managed policies that are assigned to your environment by default. The policies consist of one for the web server tier, one for the worker tier, and one with additional permissions necessary for multicontainer Docker environments:

AWSElasticBeanstalkWebTier grants permissions to instances in your environment to upload logs to Amazon S3 and send debugging information to AWS X-Ray.
AWSElasticBeanstalkWorkerTier grants permissions for log uploads, debugging, metric publication, and worker instance tasks, including queue management, leader election, and periodic tasks.
AWSElasticBeanstalkMulticontainerDocker grants permissions for Amazon ECS to coordinate cluster tasks.

User policies:

User policies enable users to create and manage environments. Elastic Beanstalk provides managed policies for full access and read-only access:

AdministratorAccess-AWSElasticBeanstalk
AWSElasticBeanstalkReadOnly

53 of 75

Service role policy example

"Effect": "Allow",

"Action": [

"elasticloadbalancing:DescribeInstanceHealth",

"elasticloadbalancing:DescribeLoadBalancers",

"elasticloadbalancing:DescribeTargetHealth",

"ec2:DescribeInstances",

"ec2:DescribeInstanceStatus",

"ec2:GetConsoleOutput",

"ec2:AssociateAddress",

"ec2:DescribeAddresses",

"ec2:DescribeSecurityGroups",

"sqs:GetQueueAttributes",

"sqs:GetQueueUrl",

"autoscaling:DescribeAutoScalingGroups",

"autoscaling:DescribeAutoScalingInstances",

"autoscaling:DescribeScalingActivities",

"autoscaling:DescribeNotificationConfigurations",

"sns:Publish"

],

"Resource": [

"*"

]

53

AWSElasticBeanstalkEnhancedHealth

54 of 75

Elastic Beanstalk simplifies container deployment

Getting started with �Amazon ECS

Create a task definition
Create and configure a cluster including:

EC2 instances
VPC settings
IAM role definition

Create a service to run and maintain a specified number of instances of a task

Getting started with �Elastic Beanstalk

Write a Dockerrun.aws.json file and provide your zipped code
Select the platform for your language
Launch your application

54

Elastic Beanstalk uses Amazon ECS to coordinate container deployments to multicontainer Docker environments. This coordination simplifies the task of getting up and running with containers. Elastic Beanstalk takes care of Amazon ECS tasks, including cluster creation, task definition, and running tasks.

You can also continue to customize your Elastic Beanstalk environment as you experiment and learn more about working with containers. When you create an Elastic Beanstalk environment, Elastic Beanstalk provisions and configures all of the AWS resources necessary to run and support your application. In addition to configuring your environment's metadata and update behavior, you can customize these resources by providing values for configuration options.

Elastic Beanstalk uses AWS CloudFormation to launch the resources in your environment and propagate configuration changes. The resources are defined in a template that you can view in the CloudFormation console.

55 of 75

Multicontainer Docker platform

55

Elastic Beanstalk

Auto Scaling group, Amazon ECS cluster

Instance 1

Task 1-1

Instance 2

Task 1-2

app1.elasticbeanstalk.com:80

app1.elasticbeanstalk.com:9000

Elastic Load Balancing

You can use Elastic Beanstalk to create an environment where your EC2 instances run multiple Docker containers side by side.

This diagram shows an example Elastic Beanstalk environment that is configured with three Docker containers running on each EC2 instance in an Auto Scaling group.

The multicontainer Docker platform for Elastic Beanstalk requires images to be prebuilt and stored in a public or private online image repository.

When you create an environment by using the multicontainer Docker platform, Elastic Beanstalk automatically creates and configures several Amazon ECS resources. At the same time, it is building the environment to create the necessary containers on each EC2 instance.

Here are the components that Elastic Beanstalk creates:

Amazon ECS cluster: Container instances in Amazon ECS are organized into clusters. When they are used with Elastic Beanstalk, one cluster is always created for each multicontainer Docker environment.
Amazon ECS task definition: Elastic Beanstalk uses the Dockerrun.aws.json file in your project to generate the Amazon ECS task definition that configures container instances in the environment.
Amazon ECS task: Elastic Beanstalk communicates with Amazon ECS to run a task on every instance in the environment to coordinate container deployment. In a scalable environment, Elastic Beanstalk initiates a new task whenever an instance is added to the cluster. In rare cases, you might need to increase the amount of space that is reserved for containers and images.
Amazon ECS container agent: The agent runs in a Docker container on the instances in your environment. The agent polls the Amazon ECS service and waits for a task to run.
Amazon ECS data volumes: Elastic Beanstalk inserts volume definitions (in addition to the volumes that you define in Dockerrun.aws.json) into the task definition to facilitate log collection.
Elastic Beanstalk creates log volumes on the container instance, one for each container, at /var/log/containers/containername. These volumes are named awseb-logs-containername and are provided for containers to mount.

56 of 75

Dockerrun.aws.json file

{

"AWSEBDockerrunVersion": 2,

"volumes": [

{

"name": "php-app",

"host": {

"sourcePath": "/var/app/current/php-app"

}

},

{

"name": "nginx-proxy-conf",

"host": {

"sourcePath": "/var/app/current/proxy/conf.d"

}

]

…

"containerDefinitions": [

{

"name": "php-app",

"image": "php:fpm",

"environment": [

{

"name": "Container",

"value": "PHP"

}

],

"essential": true,

"memory": 128,

"mountPoints": [

{

"sourceVolume": "php-app",

"containerPath": "/var/www/html",

"readOnly": true

}

]

}

…

56

Container instances are EC2 instances that run multicontainer Docker in an Elastic Beanstalk environment. Container instances require a configuration file that is named Dockerrun.aws.json. This file is specific to Elastic Beanstalk. The file can be used alone or combined with source code and content in a source bundle to create an environment on a Docker platform.

The Dockerrun.aws.json file includes three sections:

AWSEBDockerrunVersion: Specifies the version number as the value 2 for multicontainer Docker environments.
volumes: Creates volumes from folders in the EC2 container instance or from your source bundle (deployed to /var/app/current). Mount these volumes to paths within your Docker containers by using mountPoints in the container definition.
containerDefinitions: An array of container definitions. The container definition and volumes sections of Dockerrun.aws.json use the same formatting as the corresponding sections of an Amazon ECS task definition file.

This example uses an instance with two containers. The snippet on the left illustrates the syntax for the AWSEBDockerrunVersion and volumes sections. The snippet on the right shows the continuation of the file with the containerDefinitions section. Only the first definition is shown in the snippet. For the full example, see the Elastic Beanstalk Developer Guide at https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker_v2config.html#create_deploy_docker_v2config_dockerrun.

57 of 75

Elastic Beanstalk deployment policies

All at once

Deploys the new version to each instance
Requires some downtime
Quickest deployment method

Rolling

Deploys to a batch of instances at a time
Avoids downtime
Minimizes reduced availability
Longer deployment

Rolling with batch

Launches an extra batch of instances, then performs a rolling deployment
Avoids reduced availability
Longer deployment than rolling

Traffic splitting

Launches a full set of new instances like an immutable deployment
Tests the health of the new version by using a portion of traffic while keeping the rest of the traffic served by the old version
Supports canary testing
No interruption of service if you must roll back

57

Immutable

Launches a second Auto Scaling group, and serves traffic to both old and new versions until the new instances pass health checks
Ensures that the new version always goes on new instances
Allows for quick and safe rollback
Longer deployment time

Faster

More control

Elastic Beanstalk provides several options for processing deployments, including deployment policies (all at once, rolling, rolling with additional batch, immutable, and traffic splitting). It also includes options that you can use to configure batch size and health check behavior during deployments.

Choose the method that makes the most sense for your use case. Consider how fast you can make updates compared to how much tolerance your users have for issues with a new version and downtime during updates.

All at once deployments are the fastest but require at least some downtime. Immutable deployments are the safest but require a longer deployment time.

With traffic splitting, you can test a small amount of traffic to the new version while still sending most traffic to the existing version. Then, you can automatically shift all traffic to the new version after a period if health checks are successful.

By default, your environment uses all at once deployments.

If you created the environment with the CLI and it's a scalable environment (you didn't specify the --single option), it uses rolling deployments.

For more information about these options, see the Elastic Beanstalk Developer Guide at https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html.

58 of 75

Deployment option namespaces

aws:elasticbeanstalk:command

Choose the deployment policy
Set a timeout
Choose options for size and type of batches to use
Choose whether to cancel deployment on a failed health check

aws:elasticbeanstalk:trafficsplitting

Choose the percentage of traffic to go to new instances
Choose how long to wait before continuing to shift more traffic

58

59 of 75

Example of traffic splitting�(canary testing)

59

Temporary Auto Scaling group

ELB

Auto Scaling group

v1

v2

option_settings:

aws:elasticbeanstalk:command:

DeploymentPolicy: TrafficSplitting

aws:elasticbeanstalk:trafficsplitting:

NewVersionPercent: "15"

EvaluationTime: "10"

Example deployment configurations

15%

Health checks: 10 minutes

Elastic Beanstalk

15%

v1

v2

You can use traffic-splitting deployments to perform canary testing. You direct some incoming client traffic to your new application version to verify the application's health. As soon as the application’s health is verified, you can commit to the new version and direct all traffic to it.

During a traffic-splitting deployment, Elastic Beanstalk creates a new set of instances in a separate temporary Auto Scaling group. Elastic Beanstalk instructs the load balancer to direct a certain percentage of your environment's incoming traffic (NewVersionPercent) to the new instances. The decision is based on the configuration values in the aws:elasticbeanstalk:trafficsplitting namespace of your configuration file.

Then, for the configured amount of time (EvaluationTime), Elastic Beanstalk tracks the health of the new set of instances. If all is well, Elastic Beanstalk shifts remaining traffic to the new instances and attaches them to the environment's original Auto Scaling group. They replace the old instances. Then, Elastic Beanstalk cleans up—it terminates the old instances and removes the temporary Auto Scaling group.

60 of 75

Blue/green deployments�on Elastic Beanstalk

60

Elastic Beanstalk environment (blue)

Elastic Beanstalk environment (green)

myapp.useast-1.elasticbeanstalk.com

myapp_new.useast-1.elasticbeanstalk.com

3

Swap the CNAMEs

1

Clone the environment

2

Deploy and test in the new environment

61 of 75

Section 6 key takeaways

You can use Elastic Beanstalk to manage all of the resources that run your application as an environment.
You can quickly launch a Docker multicontainer environment with Elastic Beanstalk without worrying about Amazon ECS configuration details.
Deployment options include traffic splitting and blue/green to support testing new versions.

61

62 of 75

Lab 8.2: Running Containers on a Managed Service

62

63 of 75

Lab: Scenario

Sofía has containerized the coffee suppliers application, but wants to reduce the effort to maintain the application and improve its scalability.

As noted in the previous lab, Sofía wants to move the database to a managed database service rather than running it in a container.

Based on her research, she has made these decisions:

Use AWS Elastic Beanstalk to deploy the application website.
Use Amazon Aurora Serverless for the database. Sofía must retire the container-based MySQL database and load the required user, tables, and data into an Aurora Serverless database.

63

64 of 75

Aurora Serverless

64

Amazon Aurora

Fully managed relational database engine that is compatible with MySQL and PostgreSQL

Part of the Amazon Relational Database Service�(Amazon RDS), a managed database service
Combines the performance and availability of�high-end commercial databases with the simplicity and cost-effectiveness of open-source databases
Offers Aurora Serverless, an on-demand configuration that automatically scales up or down based on traffic and shuts down when not in use

As you learned in the lab scenario, this lab uses Amazon Aurora Serverless. You learned about Amazon Aurora in the AWS Academy Cloud Foundations course. Aurora is a fully managed relational database engine that is compatible with MySQL and PostgreSQL. Aurora is part of the Amazon Relational Database Service (Amazon RDS), a managed database service.

Aurora Serverless is an on-demand automatic scaling configuration for Aurora. An Aurora Serverless database cluster scales compute capacity up and down based on your application's needs. This ability contrasts with Aurora provisioned database clusters, for which you manually manage capacity. Aurora Serverless provides a relatively simple, cost-effective option for infrequent, intermittent, or unpredictable workloads. The service is cost-effective because it automatically starts up, scales compute capacity to match your application's usage, and shuts down when it's not in use.

65 of 75

Lab: Tasks

Preparing the development environment
Configuring the subnets for Amazon RDS and Elastic Beanstalk to use
Setting up an Aurora Serverless database
Reviewing the container image
Configuring communication between the container and the database
Creating the application database objects
Seeding the database with supplier data
Reviewing the AM policy and role for Elastic Beanstalk
Creating an Elastic Beanstalk application
Configuring the API Gateway proxy

65

66 of 75

Lab: Final product

66

Public subnet 1

AWS

Cloud9

IDE

Region

VPC

ECR

Website image

Public subnet 2

Elastic Beanstalk

Classic

Load

Balancer

EC2 hosting

website image

EC2 hosting

website image

Deployment

Aurora Serverless

Data

API

67 of 75

Begin Lab 8.2: Running Containers on a Managed Service

67

~ 90 minutes

68 of 75

Lab debrief: �Key takeaways

68

69 of 75

Module wrap-up

Module 8: Introducing Containers and Container Services

70 of 75

Module summary

In summary, in this module, you learned how to do the following:

Describe the history, technology, and terminology behind containers
Differentiate containers from bare-metal servers and VMs
Illustrate the components of Docker and how they interact
Identify the characteristics of a microservices architecture
Recognize the drivers for using container orchestration services and the AWS services that you can use for container management
Host a dynamic website by using Docker containers
Describe how Elastic Beanstalk is used to deploy containers

70

71 of 75

Complete the knowledge check

71

72 of 75

Sample exam question

A cloud architect wants to migrate a web application to containers. The team does not have much experience with AWS or containers, but the architect wants to get them started quickly to be able to experiment.

Which solution would be best?

Use Elastic Beanstalk to launch a multicontainer Docker environment.
Use Amazon ECR to host Docker images that they create from scratch.
Configure EC2 instances with automatic scaling, and install Docker images on the instances.
Configure Amazon ECS with a cluster of EC2 instances that run Docker containers.

72

73 of 75

Additional resources

Blog posts

Building Container Images on Amazon ECS on AWS Fargate: �https://aws.amazon.com/blogs/containers/building-container-images-on-amazon-ecs-on-aws-fargate/
Developing Twelve-Factor Apps Using Amazon ECS and AWS Fargate: https://aws.amazon.com/blogs/containers/developing-twelve-factor-apps-using-amazon-ecs-and-aws-fargate/

Amazon ECS Workshop: https://ecsworkshop.com/

73

74 of 75

Thank you

© 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. This work may not be reproduced or redistributed, in whole or in part, without prior written permission from Amazon Web Services, Inc. Commercial copying, lending, or selling is prohibited. Corrections, feedback, or other questions? Contact us at https://support.aws.amazon.com/#/contacts/aws-training. All trademarks are the property of their owners.

75 of 75

Containers as part of developing�a cloud application

75

AWS WAF �secures API endpoint

Café employees

Refresh cache per settings

CloudFront distribution

ElastiCache �for Memcached

AWS WAF �secures website

SNS

SQS

Suppliers

Coffee inventory

updates

Lambda

Step Functions �retrieves data from RDS and posts report to S3 with presigned URL

Amazon Cognito provides token for report requests

Amazon S3�

Developers

AWS Cloud9

CloudShell

AWS CLI

SDK for Python

Console

�bucket hosts café website

Café website users

Webpage �requests

Bucket policy

DynamoDB database stores products table

API Gateway REST API

Lambda function �does database lookups

Café employees

Elastic Beanstalk

ECR hosts Docker image

EC2 instance with Docker container runs coffee supplier website

Aurora Serverless on RDS stores supplier database