Feature spotlight: Building Docker images

March 2, 2017

Feature spotlight: Building Docker images

With Buddy you can build your own Docker images with source code from GitHub, Bitbucket and GitLab (or Buddy) repositories. In this release we've added context path support for Docker image builds—a good opportunity to present how to automate the delivery workflow for Dockerized applications.

Docker app workflow

The workflow for the Dockerized app is defined in a dockerfile kept in the repository along the source code and looks like this:

  1. Changes to application code
  2. Unit tests
  3. Build Docker image
  4. Push Docker image to registry
  5. SSH to the application server
    • Docker pull from registry
    • Stop current Docker container
    • Start new version

Buddy lets you save time and money by automating these steps so that you can focus purely on application coding.

Location of Docker image build actionLocation of Docker image build action

Automating Docker build with Buddy

In this paragraph we'll show you how to automate build and push to registry. As a result, on every change in the repository a new version of the application image will appear in the registry. You can fork this repository and use it as template, or use your own:

  1. Create a new project in Buddy and select the repository with the application
  2. Add a new pipeline, assign it to the Master branch, and set the trigger mode to On every push
  3. Add the Docker image action and select the dockerfile and context path that will be used for building the application.

    Note: Usually the dockerfile is located in the directory in which the image is built. However, sometimes the code structure requires the dockerfile to be moved somewhere else. In this case, you need to provide the context path.

  4. Select the registry to which the image will be delivered (Docker Hub, Amazon ECR, Private)

    You can use Environment Variables to define the tag with which the image will be pushed, for example $BUDDY_EXECUTION_ID or $BUDDY_EXECUTION_REVISION. This way every execution will create a new version of the image in the registry with an adequate tag.

  5. (Optional) Depending on the host you build your image on, you may want to use different variables to define the image values. These arguments are available upon clicking More options.

Once you add the action, every push to the repository will automatically build a new Docker image and push it to the registry with no need for action. You can also run the action manually:


Adding tests before Docker build

The principle rule of Continuous Deployment is that your code is always tested before it is deployed to the production server. This also applies to the code that you use to build your images. With Buddy you can automatically test every change pushed to the repository by adding a build action before building the Docker image:

  • Add Node.js at the beginning of the pipeline and define your tests. You can install any missing dependencies in the Packages & Setup tab

When ready, make a push or run the pipeline manually and watch Buddy execute your tests.

Re-running the Docker container after the build

The application is tested and the image is built. At this moment the image is usually run on a server. This too can be handled with Buddy:

  • Add the SSH action at the end of the pipeline, provide your server details and enter these commands:

      docker pull image:tag
      docker stop containername|| true
      docker run --name containername -d image:tag

SSH action detailsSSH action details

You can use environment variables to store your credentials.

Share:

Alexander Kus

Alexander Kus

Customer Success Manager

A story-teller and conversation-lover, Alexander decided to invest his skills to help his friends at Buddy transform the cold language of patch notes into exciting narratives. Also: an avid gamer, hip-hop DJ, Liverpool FC fan, absentminded husband, and the father of two.