Now that we're up and running with Docker in development, I wanted to share some tips that can make your life significantly easier while doing so. In no particular order...
1. Add a dockerhost entry to your hosts file
Typically you'll have to figure out your Docker VM's IP address before hitting your endpoint by running:
To avoid this, you can add a dockerhost entry to your /etc/hosts file, so you can use dockerhost as the endpoint instead:
2. Mount your current directory into the container
We often want to make changes to our code while running our containers in development, and this can be quite a hassle. The solution is to mount your current directory (.) into the container, which allows you to do live code changes on your host and see the changes in your container:
3. Use env_file to specify environment variables
Using Docker Compose's env_file directive makes it really easy to start your containers with the required environment variables:
This file should be formatted just like follows, which is conveniently the format that the Cloud 66 environment variable upload feature uses:
4. Debug your containers with docker exec
Your containers might be up and running, but sometimes they just don't act the way you'd expect them to. In this case, it's great to be able to see what's happening inside of it.
First, grab its container ID:
Now you can run docker exec inside that container to troubleshoot:
5. Use slim images for faster builds
Lots of base images on Docker Hub have a slim version, like the Ruby base image. These images have been trimmed of build-time files, often shaving several hundreds of megabytes from the image size in the process. Depending on your requirements, this may be a blessing for quicker builds and deployments.
If you're using BuildGrid to build your images, we actually apply caching so this won't make too much of a difference during build, but will definitely save disk space on your host(s).
6. Use containers as disposable development environments
Now that we're already using containers for our applications, why not use them as disposable development environments as well? This is great when you need to quickly test an issue in a specific environment, and make some changes to it without messing with your local host.
To do this, create a Dockerfile with your ideal development environment, and start that image when you need to try something out. Check out the Dockerfile Solomon Hykes uses for his devbox for inspiration.
7. Follow your Docker logs for easy troubleshooting
The docker logs directive won't follow your logs by default, but this is super easy to accomplish:
Lastly but not least, check out this cheat sheet for everything Docker! If you have any tips that have made your life easier, please do let us know :)