This tutorial explains how to manually provision an AWS EC2 virtual machine using Ansible. Before you start, you should be familiar with the following concepts:
Amazon provides a hosted Container Service for Docker called EC2 Container Service (ECS) as part of its container focused suite of services. Many of our customers seem to love the ECR (EC2 Container Registry) and ECS combination to store and run their applications. Amazon ECS can be accessed by going to your AWS Management Console, selecting EC2 Container Service from the list of Services.
In part I of this series, I demonstrated a simple scenario where we built and pushed a Docker image to ECR as part of the CI build workflow. In this blog post, I will show how you can set up deployment of the same sample application into Amazon ECS, In the last part of this series, I'll show how you can complete your Continuous Delivery pipeline with deployment into subsequent environments, promotion workflows between environments, and release management.
If you want to follow along with the step by step tutorial you can fork our sample, sign in to Shippable, and set up the CI/CD workflow as described.
Amazon provides a hosted private registry for Docker images called EC2 Container Registry (ECR) as part of its container focused suite of services. Many of our customers seem to love the ECR and ECS (EC2 Container Service) combination to store and run their applications. Amazon ECR can be accessed by going to your AWS Management Console, selecting EC2 Container Service, and clicking on Repositories in the left sidebar.
In this blog post, I will go through a simple scenario with a sample project where we enable a project for CI, build a docker image as part of the workflow, test the image, and then push it to Amazon ECR. In the next blog, we will then set up the rest of the Continuous Delivery pipeline for the sample application.
If you want to follow along with the step by step tutorial you can fork the sample used in this tutorial, sign in to Shippable, and set up the CI/CD workflow as described.
Provisioning and updating infrastructure is a the first step in setting up your development, beta, or production environments. Hasicorp's Terraform format is fast becoming very popular for this use case. We love Terraform at Shippable due to its easy declarative syntax, similar to our pipelines syntax. Other advantages are:
Infrastructure as Code: Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.
Execution Plans: Terraform has a "planning" step where it generates anexecution plan. The execution plan shows what Terraform will do when you call apply. This lets you avoid any surprises when Terraform manipulates infrastructure.
Resource Graph: Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, Terraform builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.
Change Automation: Complex changesets can be applied to your infrastructure with minimal human interaction. With the previously mentioned execution plan and resource graph, you know exactly what Terraform will change and in what order, avoiding many possible human errors.
At Shippable, we use Terraform to provision all our environments and automate the provisioning using our Pipelines feature. If you're interested in taking a look at our terraform scripts and pipelines config, we have made our repositories public so you can check them out:
Interested in trying it yourself? The following example walks you through a sample project that provisions two t2.micro instances on AWS. We've kept it simple for easy understanding, but you can also automate provisioning of complex environments as seen in our beta infra scripts above.
Everyone agrees that continuous deployment helps accelerate innovation. However, Continuous Deployment (CD) today is synonymous with fragile homegrown solutions made of disjointed tools cobbled together with thousands of lines of imperative scripts. Avi Cavale walks you through the CD maturity model and demos an end to end continuous deployment with declarative pipelines for Docker applications.