Wercker has for some time provided a number of built-in steps that make it easy to build a Docker image, test it, and then push it to an image registry, all in a Wercker pipeline.
However sometimes your Wercker pipelines need to be able to access a Docker daemon directly. You might need to use the full power of the docker command, or you might need to use build tools that access the docker daemon.
We're therefore very pleased to announce that you can now give your Wercker pipelines direct access to the docker daemon.
Simply set the property docker: true in your pipeline and a Docker daemon will be provisioned exclusively for that pipeline.
build: box: alpine docker: true steps: ...
You can then use the docker command or any tool or library that requires direct access to a Docker daemon. The environment variable DOCKER_HOST will be set to the URI of the daemon.
Note that if you want to use the docker command from within your pipeline then you need to either specify a box image that has it installed or add a step to install it.
Here's an example of a simple pipeline that is configured to use direct docker access. The first step installs the docker command. The second step uses the docker command to build an image from a Dockerfile.
build: box: alpine docker: true steps: - script: name: Install docker command code: apk --no-cache add docker - script: name: Build an image from the Dockerfile code: docker build -t docker.io/myusername/myapp:latest .
Having created an image, your pipeline can then use the docker run command to start it.
- script: name: Start the image code: | docker run --rm -d -p 5000:5000 --name testcontainer \ --network=$DOCKER_NETWORK_NAME \ docker.io/myusername/myapp:latest # see my container running docker ps
Notice that the above step uses docker ps to view the newly-started container. Direct docker access gives you full access to the docker daemon; you can run any docker command you like.
There is one special networking detail that you need to be aware of. In Wercker your pipeline container runs in what Docker calls a "user-defined bridge network". This allows it to connect to other containers running in the same bridge network, using the container name as the hostname.
In the example above, the parameter --network=$DOCKER_NETWORK_NAME is used to specify that the new container will run in the same bridge network as the pipeline container. DOCKER_NETWORK_NAME is set automatically by Wercker. The parameter --name testcontainer is used to specify the container name. Together this means that subsequent steps in your pipeline can connect to the new container using testcontainer as the hostname.
Imagine that your image runs a web server which returns "Hello World" (see an example here). Now that your image is running you might follow it with a simple script step that connects to the container (using testcontainer as the hostname) and uses the curl command to verify that it returns the expected response:
- script: name: Install Curl code: apk --no-cache add curl - script: name: Test the container code: | if curlOutput=`curl -s testcontainer:5000`; then if [ "$curlOutput" == "Hello World!!" ]; then echo "Test passed: expected response" else echo "Test failed: unexpected response" exit 1 fi else echo "Test failed: container did not respond" exit 1 fi
If the tests pass you might want your pipeline to push the image to a registry such as Docker Hub so that others can use it.
- script: name: push the newly-create image to a repository code: | docker login -u myusername -p $PASSWORD docker push docker.io/myusername/myapp:latest
This is just an example of the things that you can do now that Wercker gives you direct access to the docker daemon. What you do is entirely up to you: you have the full power of docker available.
For more information on how to use direct docker access, see the product documentation.