Documentation on working with custom docker images

[mc0e]

trafficstars

Clearly a lot of work has gone into the documentation, but either I've missed something important, or there's some bits that aren't covered. Maybe I just need a pointer in the right direction, or maybe more needs documenting.

The container I'm working on just now is for pulling together information from web APIs and posting notifications to an XMPP based chat server. There's a bit of scripting and the like, but also various libraries and command line tools that the container needs installed.

I've worked out a process. It may or may not be in line with how chaperone-baseimage is intended to be used. I'd like a bit of feedback on that, and also I'm hoping that posting here will help bring about some documentation so the next person won't have to pore over code as much to figure out what workflow might work.

I need to build a docker image that has various stuff installed like python libraries and command line utilities like jq. I then need a container using that image where I do script development. As far as I can tell, these need to be set up as separate working directories using chaplocal.

My current workflow is something like what follows. I'm now using the sudo-enabled version of chaperone-docker as per #3 so that's reflected in the commands below:

# Get the chaplocal script
sudo docker run -it --rm chaptest/chaperone-baseimage:latest --task get-chaplocal | sh

# Set up "discwatch-tools" working directory and use it to build a docker image of the same name
./chaplocal discwatch-tools
cd discwatch-tools/
vim Dockerfile
./build.sh discwatch-tools
cd ..

# Set up environment for working on my script using tools in discwatch-tools image
./chaplocal discwatch discwatch-tools
cd discwatch
./run.sh

This seems to work, and I can go back and forth between working on the two chaplocal environments as required. I can also build a production image from the discwatch environment. It seems a bit awkward though. It feels like what I'm doing in two environments should really be done in one. Have I missed something that would allow me to do that?

[garywiz]

You basically are doing things right. In your case, discwatch-tools is essentially an organisational "baseimage". For example, if you had many people developing different containers with similar requirements, it would make sense to have that intermediate image. We have some clients who have a "master baseimage" that is modified for their needs and is used internally.

But, in your case, collapsing them into a single image is exactly what you want, yes, and what we typically do ourselves. There are some shortcuts I'll recommend later today after I verify a few things to make sure I give you the right advice

As far as documentation, the Chaperone documentation itself is complete, and self-contained. I don't expect it to evolve that much, and Chaperone itself is quite separate and can be used for many purposes aside from these images.

So, documentation for these images is stored in the repo wiki so that it can evolve and people can contribute tips/tricks if they ever want to. But it sure needs work, I confess, as it would be good for people to know best-practices.

There is a (now dead) link on the "Introduction to Features" wiki page called "Developer Mode". I'll create a page for that today, and answer your question above, and put a note here when I do.

[garywiz]

@mc0e ... This will be a bit more work for me to document properly than I first thought. So, I'll give you the "quick docs" right here.

There are three use-cases for these containers:

1. Direct-to-production. The container infrastructure is sufficient, and all you need to do is add or modify the files in your chaplocal development directory. Your production container is built directly from the original image using build.sh .
2. Modified image. You need to add features to the image itself to support development. You continue to work within your chaplocal development directory, but build a new, enhanced image using build.sh and modify run.sh to use the newly built image. In this case, your production image and your development image are the same.
3. New baseimage. You want to distribute a controlled base-image to your development team. In this case, you distributed a modified image to your developers, and they create direct-to-production images.

Some applications can use images like alpinejava directly without modifications since everything is already there for the JDK. But, most everything else (such as your case), requires a modified image.

The simplest way to do this is:

1. Create a new working directory using chaplocal.
2. Modify build/install.sh to add infrastructure or packages needed for development.
3. Modify the IMAGE variable in run.sh and the prodimage variable in build.sh to contain the name of the new modified image. Essentially, the image you build with build.sh will be the same image you now run with run.sh, and will be derived from the original image that will be unchanged in your Dockerfile.
4. This is a good point to your directory into a new 'git' repo. This is the new basis for ongoing development.
5. Continue working by making any changes you want. Use run.sh to run the image, and build.sh to recreate the image if you've made any changes to build/install.sh.

Essentially, your discwatch-tools image is probably all you needed, and you could have modified run.sh and build.sh and just kept that as your ongoing development directory.

The problem with your scenario is that discwatch will not inherit any new changes to the base images. This may be what you want, but it might not. So, you need to consider your individual scenario, but usually, baseimage changes are desirable (security fixes, bug fixes, etc.)

Note, after looking into this, I am probably going to change the name prodimage in build.sh to be the same as in run.sh so it will make the instructions simpler when I document it.

Does this help?