The course is part of these learning paths
What is Compute?
Understanding the fundamentals of AWS is critical if you want to deploy services and resources within the AWS Cloud. The Compute category of services are key resources that allow you to carry out computational abilities via a series of instructions used by applications and systems. These resources cover a range of different services and features, these being:
- EC2 - Amazon Elastic Compute Cloud
- ECS - Amazon Elastic Container Service
- ECR - Amazon Elastic Container Registry
- EKS - Amazon Elastic Container Service for Kubernetes
- AWS Elastic Beanstalk
- AWS Lambda
- AWS Batch
- Amazon Lightsail
This course will provide the fundamental elements of all of these Compute services and features that will allow you to select the most appropriate service for your project and implementations. Each have their advantages by providing something of value that’s different to the others, which will all be discussed.
Topics covered within this course consist of:
- What is Compute: This lecture explains what 'Compute' is and what is meant by Compute resources and services
- Amazon Elastic Compute Cloud (EC2): This is one of the most common Compute services, as a result this will likely be the longest lecture as I want to cover a lot of elements around EC2 to ensure you are aware of how it’s put together and how it works
- Amazon ECS (EC2 Container Service): Within this lecture I will provide a high level overview of what the EC2 Container Service is and how it relates to Docker
- Amazon Elastic Container Registry: In this lecture I explain how this service links closely with ECS to provide a secure location to store and manage your docker images
- Amazon Elastic Container Service for Kubernetes (EKS): Here I look at how EKS, provides a managed service allowing you to run Kubernetes across your AWS infrastructure without having to take care of running the Kubernetes control plane
- AWS Elastic Beanstalk: This lecture will provide an overview of the service, showing how it’s used to automatically deploy applications using EC2 and a number of other AWS services.
- AWS Lambda: This lecture covers the Lambda ‘serverless’ service, where I shall explain what serverless means and how this service is used to run your own code in response to events.
- AWS Batch: Here I will provide a high level overview of this service that relates to Batch Computing
- Amazon Lightsail: Finally we will look at Amazon Lightsail, a Virtual Private Server solution used for small scale projects and use cases
If you want to learn the differences between the different Compute services, then this course is for you!
With demonstrations provided, along with links to a number of our Labs that allow you to gain hands on experience in using many of these services will give you a solid understanding of the Compute services used within AWS.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Resurces 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 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 like 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. 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. 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 mange your docker images into different categories.
Using policies from both IAM and repository policies, you can assign permissions to each repository allowing specific uses 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 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.
About the Author
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data centre and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 50+ courses relating to Cloud, most within the AWS category with a heavy focus on security and compliance
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.