The Shippable Blog

Announcing CI/CD pipelines with Amazon EC2 Container Service and Amazon EC2 Container Registry

This blog is deprecated

DEPRECATED BLOG:

We have significantly updated the Shippable platform with several new features. Hence most of the content in this blog is deprecated. Checkout a similar blog of deploying your first Continuous Deployment pipeline using Docker Hub and Amazon EC2 Container Service. For the latest information, refer to our documentation and/or open a support issue, if you have questions.


Today's a big day!  We're thrilled to announce the integration of our Shippable CI/CD platform with Amazon EC2 Container Service (ECS) and the coming integration with Amazon EC2 Container Registry (ECR). With this integration, Shippable customers can easily deploy the Docker images generated from their Shippable CI processes into Amazon's services for managing and running containers.

Deploying Containers to Elastic Beanstalk, the Shippable way!  

 

 

Warning-Icon.png

DEPRECATED BLOG:

We have significantly updated the Shippable platform with several new features. Hence most of the content in this blog is deprecated. For the latest information, refer to our documentation and/or open a support issue, if you have questions.

You can also refer to our new blog on this topic: How To: Deploy your application to AWS Elastic Beanstalk (Part 1)


 

 

Last month we introduced the ability to deploy Docker containers to Amazon AWS Elastic Beanstalk (EBS) as the last step in a Shippable CI/CD pipeline.  In this article, I will walk through the steps required to set this up in Shippable and execute a deployment to EBS.

AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS.

Shippable 3.0 Breaking Changes

 

Recently, we announced significant enhancements to Shippable CI/CD, including a completely redesigned user experience and the ability to use custom images without the need for dedicated hosts. As a result of these announcements, we will be deprecating certain functionality as it exists in its current form on July 30th.

Details on the changes are as follows. Please note that each of the changes below will require action on your part to convert to the new method.

Docker applications with Google Container Registry and Shippable

     

We are very excited to announce support for Google Container Registry (GCR) integration with Shippable’s CI/CD cloud platform!

Our support for building and deploying Docker-based applications combined with Google's new private registry service make this a fantastic combination for anyone looking to accelerate their Docker development efforts.  

Many of you already use our custom workflows for Docker applications that let you quickly move from committing code changes to having validated Docker images ready to deploy.  With Google Container Registry (GCR), you can now manage those Docker images with secure, private Docker image storage on Google Cloud Platform, known for consistent uptime and security.  Additionally, GCR provides additional benefits we think you will like, such as fine grained access control, server-side encryption of images, and super fast deployment to Google Container Engine and Google Compute Engine.  Once stored in GCR, you can easily access the images from any machine for use in a variety of scenarios, including deploying to Google Compute Engine (GCE) via Google Container Engine (GKE), deploying to AWS, or pulling to local machines using the Docker command line interface.

Via this integration, we have enabled the following activities with GCR:

  • Pull private images stored on GCR to use as basis for a continuous integration (CI) run

  • Push an image to GCR resulting from a successful CI run (i.e. after building and testing a source code change)

  • Pull a private image stored on GCR to use as the base image for a Dockerfile build

The above options are available on all Shippable plans at no additional charge.

Immutable containers with version tags on Docker Hub

 Immutable containers with version tags on Docker Hub

Lately, several folks have asked us about our reasoning behind adding build numbers as the version tags for Docker Hub images. Briefly, our current flow is -

- Pull code from GitHub
- Pull image from Docker Hub (or build from a Dockerfile)
- Run CI in the container
- If CI passes and push to Docker Hub is configured in the yml or Project Settings, push image to Docker Hub with a version tag <image name>:<build number>

The question is - why don't we just tag the image with <image name>:latest? What is the value behind versioning images?