This course covers the core learning objective to meet the requirements of the 'Designing Compute instances solutions in AWS - Level 1' skill
- Understand there are different Amazon EC2 compute families
- Understand the different services that provide compute resources, such as AWS Lambda compared to Amazon EC2, or the Amazon Elastic Container Service, etc
- Understand that elasticity can be achieved through AWS Auto Scaling
- Understand the purpose of AWS Elastic load balancers
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.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.