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:
$ boot2docker ip
192.168.59.103
To avoid this, you can add a dockerhost entry to your /etc/hosts file, so you can use dockerhost as the endpoint instead:
echo "`boot2docker ip` dockerhost" | sudo tee -a /etc/hosts
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:
# docker-compose.yml
volumes:
- .:/myapp
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:
# docker-compose.yml
env_file:
- '.env.web'
This file should be formatted just like follows, which is conveniently the format that the Cloud 66 environment variable upload feature uses:
PORT=3000
RAILS_ENV=development
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:
CONTAINER ID IMAGE
6ef13aaf1dcb cloud66/hubot:latest
Now you can run docker exec inside that container to troubleshoot:
$ docker exec -it 6ef13aaf1dcb /bin/bash
root@6ef13aaf1dcb:/myapp#
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:
docker logs 6ef13aaf1dcb -f
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 :)