In Progress
Unit 1, Lesson 1
In Progress

Docker Diff

“What did that program change?!!”

In today’s episode you’ll see how you can definitively answer this question, using a built-in feature of Docker!

Video transcript & code

The other day I was working on dockerizing a Rails project, and I found I had a need to control where Bundler was writing files. Not just the Gemfile.lock, but every file written during a bundle install run. Which meant I needed to understand all the places that Bundler might write to.

Tools like Bundler can be highly variable in the file paths they use. Because environment variables and other configuration can influence their behavior. So sometimes what you read online doesn’t match up to what you see locally. So normally answering a question like this would mean a combination of googling, reading documentation, and poking around through the filesystem.

But I was already working in Docker, which meant I had an option that would skip past all this speculation.

First, I spun up a new Docker container.

I gave it a name that I could remember.

I used the i and t flags to start an interactive terminal inside the container.

I used a docker directory mount to map in my local project directory.

I told it to base the container on a Ruby 2 image from Docker Hub.

And told it to give me a shell inside the container.

docker run --name bundletest -it -v "$(pwd):/myproject" ruby:2 /bin/bash

Then, I ran bundle install inside the container.


Once it was done installing, I exited the container.

And then I ran docker diff with the name of the container I’d just created.

docker diff bundletest

The output was a complete list of the changes Bundler made.

I could see that it added files to the user home directory.

And I could see where it added new global files.

The only thing this didn’t tell me was what changes it made to the project directory, because that was mapped in from outside. But my project directory was the one place I didn’t need any help identifying changes,

because there I could use git status.

The biggest reason I’ve started using Docker containers for almost all of my development work has to do with having a reliably reproducible environment. But there are side benefits as well, including the ability to quickly see exactly how a system’s files are modified by a program!

Happy hacking!