Building Docker images with plain Salt

So Hackweek 14 is over. It started during the openSUSE Conference 2016 on Friday June 24 and continued all over the following week.

I had worked on integrating snapshots with Salt with Pablo just some weeks before that and I was waiting for the openSUSE Conference to get the chance to show Thomas what we had done in order to get feedback and figure out next steps.

A few days before the Conference Redhat did a press release that caught my attention: a framework to build container images with Ansible. Yes, that makes a lot of sense. My head started immediately to think all day long about the challenges to build something like that: Installing the configuration management tool without leaving it there, etc. I got curious and started poking at the README.

On one hand, it was not what I was expecting (well, at least, for a Press Release or Tech Preview). It still “generated” Dockerfiles, relied on Ansible to be installed in some way, wich was “templated” into Dockerfiles, and it was of course a new tool.

On the other hand, it was pure inspiration: I remembered why I like Salt so much. I knew that with Salt I wouldn’t need to build a “new tool”. I’d only need to write a module and connect some pieces, and that makes my feature distributed, accessible, deployable, etc. I’d not need to interact with Docker directly, but only with the Salt execution module for it. The best part: I had a Hackweek project!.

I used the chance that Thomas was at the openSUSE Conference to ask him some details about salt-thin and explain him rough ideas.

The feature went more or less like expected:

• A Docker image is basically another image, modified.
• The problem can be reduced to run a Salt state run inside of the container, modulo problems.
  • The image does not have Salt.
  • After the State run, we can’t leave Salt there.
  • The container does not have connectivity with the Salt master.
  • Pillars may be templated against grains which come from the container.

After tackling the problems one by one, you can factor some stuff out:

• If dockerng.build_sls needs to apply state on a new container and commit it, why not allow to call state on a running container?. dockerng.sls was born.
• If we are going to call state.sls and grains.items on the container, why not allow to call any module in a container?. dockerng.call was born.

On Friday I was able to give the following Lightning Talk:

The result is:

• You can build images using your own salt:// tree modules only needing Python on the base image. And yes, you can consume pillar data.
• You can execute modules on containers. Which will be interesting to see how it can be used for auditing (eg. HubbleStack).

I prepared a pull request, which had the best reception I ever got on a pull request:

There are some details to polish and I hope it can be merged soon.