Container Basics

Containers provide a standard way to package your application's code, configurations, and dependencies into a single object. Containers share an operating system that's installed on the server. They run as resource-isolated processes, and are designed to provide quick, reliable, and consistent deployments—regardless of environment. For more information about containers and their benefits, see Containers Deep Dive.

Containers rely on two features of the Linux kernel:

1. cgroups: are used to limit the resources available to a container, like CPU and memory.
2. namespaces: create a view of the operating system that is isolated to your container.

Containers offer a number of advantages for packaging, deploying, and running applications:

• Portability: Benefit from a consistent runtime environment that can run on any platform that supports the container runtime.
• Scalability: Scale applications up or down, based on demand, with lightweight and easily replicated containers.
• Consistency: Ensure that the application runs the same way in all environments with a consistent runtime environment.
• Efficiency: Use fewer resources than traditional virtual machines with lightweight containers.
• Isolation: Improve security and reliability with containers' process-level isolation, with which applications running in separate containers cannot interfere with each other, improving security and reliability.
• Agility: Reduce the time that it takes to bring new features or applications to market by quickly packaging and deploying applications.

For more information about how namespaces and control groups (cgroups) work with containers, see What are Namespaces and cgroups, and how do they work? on the NGINX blog.

In 2015, Docker and other industry leaders came together to form the Open Container Initiative (OCI). The purpose of the OCI is to create standards for container formats and runtimes. For more information about the OCI, see About the Open Container Initiative. For more information about Docker, see the Docker documentation.

Benefits of containers

1. Optimization of resource utilization: You can fit multiple, lightweight containers on a single virtual machine, and increase the efficiency and density of your resources.

2. Automation: The standard packaging and interaction with containers can make it easier to automate software development lifecycle tasks, such as building, deploying, and scaling applications.

3. Speed: Containers are quick to run. You can start, scale, or delete containers in seconds.

4. Scalability: Because containers facilitate microservices architectures, you can meet demand by using containers to scale out horizontally both quickly and efficiently.

5. Increased developer productivity: Developers can spend less time on operations and environment debugging, and spend more time on application development.

6. Code portability: Having confidence that your workload will behave consistently across environments is one of the major benefits of containers.

For more information about the benefits and use cases for using containers on AWS, see Containers at AWS.

Virtual Machines Vs Containers:

https://github.com/rajeshamdev/aws/blob/main/images/VMVsContainers.png

Docker Basics

For more information about the basic components of the Docker platform and how they work together, see Docker overview.

Docker Architecture

1. Docker daemon: The Docker daemon runs on a host and listens for API calls to manage Docker objects. For example, if you want to build an image, run a container, or create a volume, you can use the Docker command line interface (CLI) to create the request. The request will then be submitted to the Docker daemon to be managed.

2. Docker CLI: The Docker command line interface (CLI) is the client interface for interacting with Docker objects. The Docker CLI is how you issue commands to Docker to build your containers, run your containers, or stop your containers. The Docker client and daemon communicate using a REST API, over UNIX sockets or a network interface.

3. Dockerfile: A Dockerfile is a text document that contains instructions on how to build your container image. A Dockerfile includes instructions for what base layer to use (for example, whether you want to use a minimal version of Linux or use an image that has preinstalled software, such as a database engine). Other instructions include running commands in the container, or copying your application data, dependencies, and configurations into the container. For more information, see Best Practices for writing Dockerfiles.

4. Docker image: A container image is created when you run the build command from the Docker CLI and it follows the instructions in a Dockerfile. A container image is made up of a series of read-only layers, with one writable layer on top where files can be added, modified, or deleted. Each layer is created from an instruction in the Dockerfile.

5. Image registry: An image registry is a repository where you can store container images. You can store the images either publicly or privately. From the repository, images can be pulled and deployed, or used by other developers.

6. storing data in container: For more information about how to store data with Docker containers, see Managing data in Docker.

https://github.com/rajeshamdev/aws/blob/main/images/docker-architecrure.png

Dockerfile

For more information about Dockerfile instructions, see Dockerfile reference.

FROM: Defines the base image. All the instructions that follow are run in a container launched from the base image.
WORKDIR: Sets the working directory for the subsequence instructions.
ENV: Sets environment variables.
COPY: Copies files and directories into the container image.
RUN: Runs commands in the new container. This instruction commits a new layer on top of the present layer.
CMD: Sets the default command to run when the container is launched.
EXPOSE: Is used to document the containers that the port exposes.

Docker commands

For more information, see the full reference for the docker base command.

1. docker build: Builds an image from a Dockerfile. In the demonstration, we pass -t to tag the image that’s created. Example: docker build -t first-container .

2. docker image ls: List docker images.

3. docker run: Creates and starts a container. In the demonstration, we use -p to expose ports, -e to set environment variables, and -v to bind mount volumes. Example: docker run -d -p 8080:8080 --name webapp first-container

4. docker ps: view the running containers.

5. docker logs: view the logs captured from container. Example: docker logs webapp

6. docker exec: Runs a command in a running container. Example: docker exec -it <id> sh (connect to container interactively and run bash).

7. docker stop/rm: stop and remove the container. Example: docker stop webapp; docker rm webapp

---

Image registry

An image registry is a repository where you can store container images. From this registry, both DevOps tools and people can pull down container images to run, deploy, or expand on. Image registries can be public or private. Public registries are useful for providing images that can be used as base images for software development. For example, if your company provided a database engine, you could host images with the database software preinstalled on it. Your customers could then use these images as base images to expand on, which would make it easier for them to get their software up and running. Private registries are useful in situations where you don’t want to expose container images to the public, which is often the case with proprietary software.

Docker Hub: Docker Hub is a popular repository for container images. It offers a variety of sources for container images that you can use, including images from container community developers, open-source projects, and software vendors. For more information about Docker Hub, see Docker Hub.

Docker repos

Amazon ECR: Amazon Elastic Container Registry (Amazon ECR) is a private, container image registry. With Amazon ECR, you can create multiple repositories to store and share your container images. To make it easier to deploy your containerized application, Amazon ECR integrates with other AWS services—such as Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Lambda.

Amazon ECR Public: Amazon ECR also offers a highly available repository for your public images. You can create a repository for your authenticated AWS Identity and Access Management (IAM) identities to push to a public image repository. Thus, an unauthenticated user with or without an AWS account can pull from your public repository. For more information and to see a searchable list of public repositories, see the Amazon ECR Public Gallery.

AWS App Runner: AWS App Runner provides a way to run your containerized application on AWS infrastructure. You only need to supply a container image or application source to App Runner. App Runner creates all the infrastructure needed to host your application, and it also supplies you with an HTTP endpoint. App Runner serves your application with end-to-end encryption. As load increases, it will also scale within parameters that you define.

Week 1 FAQs

1. Where can I find the list of available Dockerfile instructions?

A: The Docker documentation does a good job of providing a list of instructions you can use with examples and explanations at Dockerfile reference.

1. Is there an application programming interface (API) reference for the Docker engine?

A: Yes. For more information, see Develop with Docker Engine API.

1. What is the difference between virtual machines (VMs) and containers?

A: VMs make it possible to host multiple isolated guest operating systems (OSs) on top of a host machine by virtualizing the hardware environment and sharing host resources with guest OSs. Each guest OS must have its own full guest OS. The guest OS interacts with the hypervisor, which then interacts with the host OS.

With containers, the OS is virtualized. Each container doesn’t need a full guest OS, and multiple containers on the same host can share layers where appropriate. This makes each container lightweight in nature when compared to VMs. The containers interact with the containerization engine (such as Docker) instead of with the hypervisor. That being said, you can run containers on top of VMs. So, these two technologies are not mutually exclusive. When running containers on AWS, both VMs and containers are being used together.

1. Does the data that my applications write to the writable layer persist?

A: No, any data that’s stored in the writable layer doesn’t persist when the container no longer exists. For more information, see Manage data in Docker.

1. How does persistent storage work with containers?

A: With containers, you have a few options for storing data in a persistent manner. You can use Docker volumes or bind mounts. You can also use external databases, caches, object storage, or file storage.

For more information about when and how to use volumes and bind mounts, see Manage data in Docker.

For more information about available caching and database services for persistent storage on AWS, see Best Practices – Persistent storage and Cloud Storage on AWS.

1. What’s the difference between Amazon Elastic Compute Cloud (Amazon EC2) and containers?

A: Amazon EC2 is an AWS service that provides virtual machines on demand. Containers can be hosted on top of Amazon EC2, which you will learn more about in Week 2 of the course.

1. How can I discover base images to use in my projects?

A. It’s common practice to use public base images as the starting point for containerized application development. Using the work that other developers have done can help you speed up your application development. You can find many different community images at Docker Hub and in the Amazon ECR Public Gallery.

For example, say that you need to containerize an application that uses MySQL. Instead of including the installation instructions for MySQL in your Dockerfile, you can instead start by using the MySQL public base image from Docker Hub. You could then include instructions in your Dockerfile to add any other libraries or features that are needed (such as backup tools, for example).

1. How can I scan my images for security vulnerabilities?

A: You can use many tools to scan your container images for vulnerabilities. Ideally, you would perform the scan immediately after a container is checked into a repository. Amazon Elastic Container Registry (Amazon ECR) provides built-in image scanning for vulnerabilities.

Amazon ECR offers the following scanning types:

Enhanced scanning:

Amazon ECR integrates with Amazon Inspector to provide automated, nearly continuous scanning of your repositories.

Your container images are scanned for vulnerabilities in both operating systems and programming language packages.

As new vulnerabilities appear, the scan results are updated, and Amazon Inspector notifies you by emitting an event to Amazon EventBridge.

Basic scanning:

Amazon ECR uses the Common Vulnerabilities and Exposures (CVEs) database from the open-source Clair project.

With basic scanning, you have a couple of options:

First, you can configure your repositories to scan on push.

You can also perform manual scans, and Amazon ECR will provide a list of scan findings.

For more information about Amazon ECR image scanning, see Image scanning.

For more information about open-source image-scanning tools, see 5 open source tools for container security on opensource.com.

1. Do I need to use Amazon Elastic Container Registry (Amazon ECR) to use AWS container-hosting services?

A: No. You can also use other container registry services to integrate with AWS container-hosting services (such as Docker Hub, for example). For more information, see the AWS Blog post Authenticating with Docker Hub for AWS Container Services.