Here at Codefresh we absolutely love Docker and use it every day to build and improve our platform!
So we really appreciate that Docker always makes sure to pack in some exciting features with every new version in addition to important bug/performance/stability fixes. Here are our favorites in Docker 1.13:
Figuring Out What’s Yours
There have been many times we’ve fired up our local development environments using docker-machine
only to receive the dreaded “no space left on device” and all we could do was SSH
into the Docker machine and investigate using the df
command and alike.
As part of the Docker command reorganization, we’ve been given some shiny new commands including df
. You can use df
to figure out exactly how much space every type of Docker resource takes up:
1 |
docker system df |
Example output:
Taking Back What’s Yours
Being a CI/CD platform we generate a huge number of Docker resources every day. And for us, Docker used to be a messy teenager that left a ton of garbage for our team to clean up after using cryptic and fragile shell scripts. But no more! We’ve been blessed with the prune
command to help us clean leftover containers, images, networks, and volumes:
1 |
docker system prune |
And every type of resource can be pruned individually using:
1 2 3 4 |
docker container prune docker image prune docker volume prune docker network prune |
Example output:
Composing The Swarm
Through version 1.12 and 1.13, Docker has put in great effort to revamp Swarm and make it a first class citizen in the Docker engine. On top of that, there is a shift to define compositions as “stacks.”
Bringing these two together we can now reference Swarm configurations per service in our compose file using the “deploy” keyword. This configuration allows us to control different aspects of the service, such as the restart policy, hardware resource limits, and node placement restrictions in the context of a Swarm:
1 2 3 4 5 |
deploy: replicas: 3 # Three containers should always be running restart_policy: condition: on-failure # Restart the container on failure max_attempts: 10 # But retry the restart operation 10 times only |
Note that this configuration will only apply when running the compose file using the new stack
commands:
1 |
docker stack deploy |
And will be ignored when running with docker-compose
Lightning Fast Builds
Being in the business of building code, we want things to go as smooth and quickly as possible for you the user. So if we’re able to shave a few seconds off your build time, we’ll do it!
Using the new compression switch on the build command, you can gzip the build context that’s being sent to the daemon:
1 |
docker build --compress -t repo/name . |
Compression can be a CPU-heavy operation so assuming you’ve got enough processing power on your machine to handle it (& you can bet that we do), this switch can really save you time in the long run.
Secret Swarm
Being an integration and launch platform, we sometimes have to deal with sensitive information in order for us to interact with 3rd party services.
Using the new secret management system, we can post encrypted secret information to different services in a Swarm, both on creation and on update.
First, we create a secret:
1 |
echo "SERVICE_API_KEY" | docker secret create service-api-key |
Now when we create a new service, we can provision it together with the secret information:
1 |
docker service create --name my_web_app --secret service-api-key repo/my-web-app |
So how can our service access these secrets? Simple! Docker creates a new mount point in our container at:
1 |
/run/secrets/ |
This directory contains a file for every injected secret, so our container will have access to a file named:
1 |
/run/secrets/service-api-key |
And Voilà, the contents of this file is the secret!
So go ahead and upgrade to 1.13!