AWS Partner Network (APN) Blog
New AWS Support for Commercially-Supported Docker Applications: Docker Trusted Registry and Docker Engine
The AWS cloud has been shown to be a natural complement to the flexibility that Docker containers offer organizations, and today Amazon EC2 and and Amazon ECS are very popular places to launch and run Docker containers. Customers continue to expand their container footprint and move their applications from dev to test to production, and look for enhanced support and additional product offerings as they embrace the AWS cloud as a place to run Docker containers. At DockerCon 2015 in San Francisco, we discussed work done by both teams to better support Docker on AWS for our customers, and today we take another step toward supporting those who wish to run Docker exclusively on AWS by announcing support for Docker Trusted Registry in AWS Marketplace. Customers can go from building a Docker application locally on a developer’s laptop and ship to their production Amazon Virtual Private Cloud (Amazon VPC) with just a few commands.
Like Docker Hub, Docker Trusted Registry (DTR) is a solution that allows organizations to store and manage Docker containers. However, DTR can be run as an EC2 instance, allowing complete control over how and where the registry is available and accessed from within your environment.
Configuring Your AWS Environment for Docker Trusted Registry
By running Docker Trusted Registry, organizations are able to create custom levels of access control to their Docker images. Certain components of this access control model include support for customer SSL certificates, LDAP integration to limit access to specific users, and leveraging the network access control capabilities of Amazon VPC.
Amazon VPC allows you to configure network settings and isolate cloud resources as much as necessary to meet security or compliance standards. In the case of DTR, we recommend first deciding if your registry instance should be accessible from the Internet or only from within your VPC. If the instance should be available from the Internet, you can launch the DTR instance into a public subnet. However, take care to configure the security group to only allow access from specific trusted IP ranges over ports 22 (SSH), 80 (HTTP) and SSL (443).
Please note that when DTR is launched from AWS Marketplace, the default security group is open to the world, so it’s up to you to restrict access to the IP ranges appropriate for you environment.
The other option is to place your DTR instance into a private subnet so that only resources within your network are able to access the registry. In this case, you’ll need to ensure that you have either a bastion host set up or a VPN into your VPC so you can manage the DTR instance via the web GUI.
We recommend using an Amazon Route 53 private hosted zone with Docker Trusted Registry. A private hosted zone is always queried first by instances in your VPC, and is only accessible from within your VPC- so this allows for the convenience of choosing the endpoint you will use to interact with your registry. This DNS name is what you’ll reference when pushing and pulling images from your registry, so choose something that makes sense- here we’ll use dtr.mydomain.com as an A record that points to our DTR instances IP address.
Because DTR leverages Amazon S3 for back-end storage of your Docker images, we recommend creating an IAM role that will allow your instance to communicate securely with S3. IAM roles are assigned to EC2 instances at instance launch. Here we assume that there is a dedicated bucket for our Docker images, and we can scope our IAM policy accordingly:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my_DTR_bucket",
"arn:aws:s3:::my_DTR_bucket/*"
]
}
]
}
Once you’ve decided on a VPC, how to scope access to your registry, created an IAM role, and decided on a DNS record to use, you’re ready to move forward with setting up the DTR instance itself.
Setting Up Supported Docker Environments on AWS
To begin, we’ll be using the Docker Trusted Registry “pay as you go” AMI from AWS Marketplace. This licensing model is intended to simplify the deployment experience. To further enhance the experience, Docker have included a 30-day free trial of their software. The details are provided on the product page in AWS Marketplace, which is listed here: https://thinkwithwp.com/marketplace/pp/B014VG1SIG
Once you’ve launched the AMI, you can follow the AWS and Docker Trusted Registry guide to configure the DTR instance: https://docs.docker.com/docker-trusted-registry/install/dtr-ami-byol-launch/
When launching your instance, you’ll need to choose an appropriate instance size. Docker recommends an M3.Large for initial test deployments. As your environment grows, you can use the monitoring features built into the Docker Trusted Registry web GUI to keep an eye on resource utilization and scale your instance size as needed.
Once the DTR instance is up and running, you’ll also need to launch Docker Engine instances (instances running the commercially-supported version of Docker). You can find AMIs to launch Docker Engine instances here: https://thinkwithwp.com/marketplace/pp/B014VG1R4Q
One thing to note about Docker Engine instance configuration: if you’re using a self-signed certificate, you’ll also have to configure your clients to pull the certificate from the DTR instance. This can be done using the following commands passed as a user data script:
#!/bin/bash
export DOMAIN_NAME=dtr.mydomain.com
openssl s_client -connect $DOMAIN_NAME:443 -showcerts /dev/null | openssl x509 -outform PEM | sudo tee /etc/pki/ca-trust/source/anchors/$DOMAIN_NAME.crt
sudo update-ca-trust
sudo service docker restart
This process depends on your OS, so check here for more comprehensive detail: https://docs.docker.com/docker-trusted-registry/configuration/#installing-registry-certificates-on-client-docker-daemons
Once your Docker Engine client(s) are launched, you can begin interacting with the DTR instance, pushing and pulling images to and from your own private registry from another EC2 instance within your AWS VPC, a peer VPC, or remote location connected via VPN.
From Developer Desktops Direct to the Cloud
Continuous Integration and Delivery is a critical workflow for many teams. Docker supports a number of CI/CD tools, like AWS CodePipeline and AWS CodeDeploy, and a number of deployment endpoints, like Amazon EC2 or Amazon ECS. Docker Trusted Registry can serve as the foundation of these automated workflows that can take code from a developer’s desktop, through integration and unit testing, to a staging or QA environment, and finally to production deployment.
In order to understand how to interact with DTR at the most foundational level, we’ll examine a basic Docker image workflow that can provide the baseline understanding necessary to build more complex CI/CD workflows later.
We’ll first need a client machine that is configured to interact with the DTR instance.
First, we’re going to pull a public Jenkins instance with docker pull Jenkins
Next we’ll tag the image with docker tag dtr.mydomain.com/my-jenkins
Finally, push the image to your local DTR instance docker push dtr.mydomain.com/my-jenkins
A robust and scalable CI pipeline can be built with Docker and Jenkins on AWS to take the code from your developer laptops, directly into integration testing cluster on AWS. Code pushed to a repository like Github can trigger automatic builds of containers using Jenkins, and the resulting container can be pushed to your Docker Trusted Registry instance. This container can then be tested in QA, and ultimately rolled out to production using AWS services like AWS CodeDeploy or AWS Elastic Beanstalk.
We encourage you to take a look at the new Docker commercially-supported software in AWS Marketplace today. We hope the above information gets you started, and we’d love to hear your feedback.
For additional video tutorials, resources and more at the Docker and AWS Resource Center: https://docker.com/aws