Docker First Impressions

I’ve been spreading my technical wings a bit this week, as I’m working on a new Crucible server. I’m trying to get this spun up on a Linux server and running the app inside a Docker container. I’ve long held that I’m not a “Linux guy”, but I have been a Linux user, so I didn’t have any anxiety about taking this on from the Linux perspective.

Docker, on the other hand, is totally new to me. I have run through a few of the little Docker tutorials that are online and I’ve even done a little tutorial using nanoserver with some Windows Server Containers, but I’ve never done anything with the intent to actually use it. I spoke with a couple of our Linux devops guys at the office and started on my trek. Here are some first impressions:

  1. Getting Docker started up is easy. Their tutorials get ya going pretty well.
  2. While the tutorials are clear, the documentation is fuzzy. A lot of the examples having things like “some-image” or “your-container” or whatever in them, and while that may make sense to folks using it all the time, it is inconsistent. The terms like “image” and “container” aren’t very well-defined, and using such simple language left me confused as to which thing to use. When you look at the images on a host, you get a repository, a tag, and an image id. It feels to me that the documentation isn’t very clear as to which to use.
  3. The docker command is very nitpicky. For instance, to run an image, you need to tell it the image at the end of the command. If you put an option flag after the name of the image, the command doesn’t always give you an error, it just won’t start anything.
  4. The Dockerfile is quite nice, but it does make a lot of intermediate images along the way. It would make more sense to me to have a command like “MAKE” or something that you could put in their yourself to just tell it where you want these built, as opposed to just building one after every RUN command.
  5. It took me some effort to figure out what I could share where. The Dockerfile is a text file that you can store in source control, so mine is in BitBucket. That’s great, but only good for the initial build unless you can script out the entire build process into the file itself. If you build the image and run it, then log into the image and make changes, then commit them to the image, you then need to share your image in Docker Hub, as it’s no longer just a text file.
  6. I’m not really sure which is more efficient: doing everything in a Dockerfile and sharing that, or doing things inside the image and sharing that. It certainly “feels” more flexible to do it all inside a Dockerfile and let the build process do all the work, but if you have private stuff inside that file, you can’t really share it publicly. If you can’t share it publicly, it seems more efficient to just share your images privately and use those. For example, if I’m sharing stuff within Trek, I can just push up a bunch of versions of my image into Docker Hub and just let people get the one they need and it’s completely built. The build would be faster, too, because the scripted part is all done. Maybe just different strokes for different folks.
  7. One very obvious issue is the lack of a “depends-on” type of flag inside the Dockerfile. You can start with a starting Dockerfile and build from that, but if your image depends on the existence of another image, you can’t force that. A neat little tool called “docker-compose” was written that lets you define multiple builds within a single YML file, and there’s a depends flag there. The tool looks like it simply takes the properties you provide within the file and creates the appropriate docker commands to build them in order. This worked pretty easily for me, as it’s very similar to what is done in Azure templates or Terraform files, but I ran into a quick issue. A MySQL image I wanted to build has some additional options to provide it, and I don’t see where to apply them within the YML file. Maybe I’m just missing it.
  8. Docker networking isn’t easy.

Anyway, those are just a few of my thoughts. For now on my little project, I’ve given up on spinning up multiple images using docker-compose and I’m going to try to just use an Azure SQL database instead of the MySQL one. Hopefully I can get this Crucible container running today and mark this one off the list.

Written on May 20, 2016