Docker

Solano CI supports your Docker-based CI workflow by allowing you to use the docker command in your build configuration.

Usage Example

You can enable the docker command in your build with a setting in your solano.yml file.

Here’s a quick example that will run tests within a docker container, as defined by a Dockerfile in the root of your repo:

system:
  docker: true

hooks:
  pre_setup: "sudo docker build -t myapp ."

tests:
  - "sudo docker run myapp bash -c /home/myapp/runtests.sh"

Your build will need to run on a Docker enabled queue. Contact support@solanolabs.com to verify your current queue is Docker enabled, or to have an additional custom queue created for you.

Docker Compose

Versions of Docker Compose are tightly coupled with the version of Docker. Currently Docker Compose version 1.5.2 is suppoorted with the expectation of version 1.6.0 also being supported once it is released.

The ci_memes-docker-compose example repository demonstrates using docker-compose to stand up a mutliple-container web application for each worker to run tests against.

Post-build Deployment

The ci_memes-docker repo contains a web app demonstrating docker pull, build, and test. Once the tests have passed, the post_build hook script deploys to Docker Hub and then AWS EC2 Container Service (ECS).

Note

Solano CI modifies or adds certain files to ruby/rails repos to better collect results from our parallel test runners (typically config/boot.rb and various config/*.yml files). If the repo root will be sent to the Docker daemon as the build context and/or be pushed to a repository, you may need to revert these changes with a command like git reset --hard $TDDIUM_CURRENT_COMMIT.

Docker Hub

Before a docker push command can be executed, a docker login must be performed. The example script requires thst $DOCKER_USER, $DOCKER_EMAIL, and $DOCKER_PASSWORD environment variables are supplied. Due to the sensitive nature of these values, it is recommended they are not stored in the repo, but are instead set with solano config:add commands.

AWS EC2 Container Service

The post_build script uses the AWS Command Line Interface (aws) to interact with ECS. This requires that the $AWS_ACCESS_KEY_ID, $AWS_SECRET_ACCESS_KEY, and $AWS_DEFAULT_REGION environment variables are set. Like the $DOCKER-* environment variables, these should be set with solano config:add.

After the newly built and tagged image is pushed to Docker Hub, the ECS portion of the script then:

1. Creates a new task definition. A .json file is created by substituting placeholders in a template, and the aws ecs register-task-definition command registers the new definition with AWS ECS. See AWS Task Definition Parameters for more information on the file specification.
2. Updates the AWS ECS service. The new revision number is retrieved from AWS, and is used in the aws ecs update-service command to update the service. A --desired-count switch can be provided to set the number of containers to start. See the AWS ECS UpdateService API doc page for more information.

AWS EC2 Container Registry

The ci_memes-ecr example repository demonstrates using AWS EC2 Container Registry (ECR) as a Docker container registry.

Notes & Limitations

• There is a limited amount of storage space for the docker graph (i.e., /var/lib/docker). If you encounter errors where docker has run out of space while building your container, please contact us.