Microservices & Elastic Container Service (ECS)
Elastic Container Registry (ECR)
Elastic Kubernetes Service (EKS)
The course is part of this learning path
This course provides detail on the AWS Container services relevant to the Developer - Associate exam, covering ECS, ECR, and EKS
- Learn about microservices and the benefits that a microservice-based architecture or application has over a monolithic application
- Understand the difference between containers and virtual machines
- Learn how to create your own containers and run them within ECS and deploy them either serverlessly or on EC2 instances
- Understand what the Elastic Container Registry is used for and its components
- Understand what the Elastic Kubernetes Service is used for and its components
- Understand how EKS implements and deploys clusters into a VPC
- Learn how to use, control, manage and measure an EKS Kubernetes cluster deployed application
Resources referenced within this lecture:
Hello and welcome to this lecture covering the Elastic Container Registry service, known as ECR. This service links closely with the previous service discussed, the EC2 Container Service, as it provides a secure location to store and manage your docker images that can be distributed and deployed across your applications.
This is a fully managed service, and as a result, you do not need to provision any infrastructure to allow you to create this registry of docker images. This is all provisioned and managed by AWS. This service is primarily used by developers, allowing them to push, pull, and manage their library of docker images in a central and secure location.
To understand the service better, let's look at some components used. These being, registry, authorization token, repository, repository policy, and image. Let's take a look at the registry first. The ECR registry is the object that allows you to host and store your docker images in, as well as create image repositories. Within your AWS account, you will be provided with a default registry. When your registry is created, then by default, the URL for the registry is as follows:
where you'll need to replace the red text with your own information that is applicable to your account or medium. Your account will have both read and write access by default to any images you create within the registry and any repositories. Access to your registry and images can be controlled via IAM policies in addition to repository policies as well, to enforce tighter and stricter security controls. As the docker command line interface doesn't support the different AWS authentication methods that are used, then before your docker client can access your registry, It needs to be authenticated as an AWS user, which will then allow your client to both push and pull images. And this is done by using an authorization token. To begin the authorization process to allow your docker client to communicate with the default registry, you can run the get login command using the AWS CLI, as shown:
aws ecr get-login --region region --no-include-email
where the red text should be replaced with your own region. This will then produce an output response, which will be a docker login command.
docker login -u AWS -p password https://aws_account_id.dkr.ecr.region.amazonaws.com
You must then copy this command and paste it into your docker terminal which will then authenticate your client and associate a docker CLI to your default registry. This process produces an authorization token that can be used within the registry for 12 hours, at which point, you will need to re-authenticate by following the same process. The repository are objects within your registry that allow you to group together and secure different docker images. You can create multiple repositories with the registry, allowing you to organize and manage your docker images into different categories.
Using policies from both IAM and repository policies, you can assign permissions to each repository allowing specific users to perform certain actions, such as performing a push or pull IP line. As I just mentioned, you can control access to your repository and images using both IAM policies and repository policies. There are a number of different IAM managed policies to help you control access to ECR, these being the three shown on the screen.
For more information on IAM and policies, please refer to our system course here, which covers IAM and policy creation and management. Repository policies are resource-based policies, which means you need to ensure you add a principle to the policy to determine who has access and what permissions they have. It's important to be aware of that for an AWS user to gain access to the registry, they will require access to the ecr get authorization token API call. Once they have this access, repository policies can control what actions those users can perform on each of the repositories. These resource-based policies are created within ECR itself and within each other repositories that you have. Once you have configured your registry, repositories, and security controls, and authenticated your docker client with ECR, you can then begin storing your docker images in the required repositories, ready to then pull down again as and when required.
To push an image into ECR, you can use the docker push command, and to retrieve and image you can use the docker pull command. For more information on how to perform both a push and a pull of images, please see the following links.
That now brings me to the end of this lecture covering the Elastic Container Registry service. Coming up in the next lecture, I shall be looking at the Amazon Elastic Container Service for Kubernetes, known as EKS.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, and Kubernetes (CKA, CKAD, CKS).