The CI/CD and DevOps Blog

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.

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?

Here at Shippable we love taking customers all the way to continuous deployment. We've detailed a variety of different ways to get there in the past, and today we are going to be bringing out yet another way. Today we'll be showing you how to trigger your Shippable builds, to push your rails apps to Engine Yard.

Before going any further, there are a few pre-reqs:

• An active Engineyard account
• A working rails app on github
• An active Shippable account
• The above rails app being enabled on Shippable
• An application env already setup on Engine Yard

This week, the Shippable team had the opportunity to present 'Modern DevOps with Docker' (describing our internal transformation - see below for more) and engage with the community at ApacheCon 2015 in Austin, TX.  We saw firsthand how the thriving group of dedicated professionals in the Apache community are tackling big challenges across the full tech spectrum.  In addition, while in Austin, we had the chance to connect with the tight-knit and talented DevOps Austin community and learn from their perspectives.  It was an energizing three days.

We introduced our support for docker build a few weeks back - along with it's very own blog post - but we've had requests to support an additional workflow. Starting today, you can docker build an image post-ci. Before we go any further, EVERYTHING mentioned in blog mentioned above is a pre-req to do this. Make sure you do everything mentioned in that blog first, or your post-ci docker build won't work!

Some of you might be wondering why you'd ever want to do this. Well, post-ci building allows you to create a concise docker image that contains only what you need for deployment, and leave out anything that is only required for building/testing. After all, there really isn't a benefit to deploying your build tools to production! However, as there is no upfront way for us to know which files you’d like to put in your “prod” docker image, you must manually specify which files to include. Don't worry though, as it's a simple one-liner. We'll get that in a bit; you first need to tweak your project's settings a little bit further.