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:
docker system df
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:
docker system prune
And every type of resource can be pruned individually using:
docker container prune
docker image prune
docker volume prune
docker network prune
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:
replicas: 3 # Three containers should always be running
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
docker stack deploy
And will be ignored when running with
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:
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.
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:
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:
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:
This directory contains a file for every injected secret, so our container will have access to a file named:
And Voilà, the contents of this file is the secret!
So go ahead and upgrade to 1.13!