New masterless mode for provisioning docker containers

[thedrow]

Docker is now working to decouple the builder from the container engine (See moby/moby#14298).
There's a PoC project that allows you to use client side builds using an enhanced Dockerfile called dockeramp.
We can follow the same API calls that dockeramp is performing in order to provision Docker containers from outside, that is without installing Salt inside the container.
This should work with Docker 1.8 and above as specified by dockeramp's creator.

[jfindlay]

@thedrow, I am unsure what you are asking. You want to provision docker containers with salt, but not use salt?

[thedrow]

@jfindlay Salt would run, but it would run on the host machine and not inside the container.
The purpose of this feature request is to allow Salt to replace dockerfiles with it's own syntax and mechanisms for provisioning docker containers without losing the caching capabilities of docker containers and having to install Salt inside the container.

[Diaoul]

I love Salt for it's provisioning capabilities and Docker for the isolation and caching. A mix of the both is promising.

[jfindlay]

@thedrow, thanks for having the patience to explain it to me. I also think it would be a great feature. :-)

[DanyC97]

@thedrow nice suggestion ;)

[thedrow]

@DanyC97 Thanks. I waited with this one for so long because Docker does not support it yet.

[deuscapturus]

Any movement on this? Are there examples on how you could replace or use salt within the dockerfile?

[thedrow]

@deuscapturus This is a lot of work and I'm busy with other open source projects at the moment.
If we can gather a team of developers I'd be happy to join.
Also, since feature is such a gamechanger because nobody else does this, I expect at least one SaltStack developer to be directly involved in the implementation.

[thedrow]

@jfindlay Is there an ETA on when we can start working on this?

[jfindlay]

@thedrow, I know of no time constraints. You are welcome to start on this as soon as you need. We have many extenuating obligations over dozens development activities, so I cannot promise any dedicated resources from SaltStack. If you are able to work on this though, @techhat may be your best contact.

[thedrow]

All of us always needed it but it's a huge amount of work. I don't think it's fair to drop this on an sole unpaid volunteer.
Moreover, SaltStack will use it to their advantage to mark Salt as the only Configuration Management solution that can provision docker containers correctly, with caching and all the goodies that docker provides. This is not just any feature that the community will enjoy. This can be part of a marketing strategy.
So SaltStack has a lot to gain in this case. As for me, I can keep using Dockerfiles and Rockerfiles for the more complex containers and use Salt only for orchestration.
It's a pain, but one I can live with since I'm not a DevOps Engineer. Those who migrate from VMs to containers would feel that pain more because they already have stateconf files that are tested and they work and now they have to rewrite all of them to Dockerfiles.

I really think that in this case, given that this is a huge amount of work and that SaltStack has more to gain than a single volunteer (fame, street credit etc.) this one should be on you guys.
I'm willing to help but I will not implement this on my own.

[thedrow]

If you could enable BountySource and enough people/companies donate I'd be happy to start working on it.

[thatch45]

@thedrow sorry this one took so long to get the right attention. We get a ton of feature requests and few of them get slated as feature goal projects.

I have slated this feature for the Carbon release and we will dedicate SaltStack resources to it as soon as they are freed up. I can't get it into Boron simply because it is feature frozen.

We will let you know as soon as we start here!

[thedrow]

Great! Thank you.

[terminalmage]

@thedrow I'm afraid I don't understand Go, and I'm not really sure what it is you're asking for. Can you elaborate? How would this be any different from dockerng.build? Salt can already build from the client-side. I'm also not sure why masterless is so important here, since a masterless run would just invoke the execution module, which can be done both masterless and in a normal master/minion setup.

[thatch45]

@terminalmage I think that the request here is to use salt to build/configure docker containers. So far as I can tell it would be similar to FlyingCloud: https://github.com/cookbrite/flyingcloud

[thedrow]

Yes! Exactly.
Ansible recently provided their own solution called Ansible Container. However I don't think that it uses docker's cache correctly.
It actually flattens the image automatically which may increase container deployment time.
FlyingCloud looks interesting but I'd rather have this maintained by SaltStack because it will ensure that this feature will be maintained for as long as SaltStack exists.
FlyingCloud is an open source project written by a company that may or may not abandon it since it's not their core business.
I'll look into it. It might be useful in the meanwhile.

[bbinet]

Thanks for mentionning FlyingCloud, interesting solution.

[terminalmage]

I'm still trying to understand what you need, which the dockerng state and execution module don't already do.

[thatch45]

@terminalmage move on to the next issue, we can do a video chat about it later.

[thedrow]

I want to be able to provision Docker containers using Salt states while utilizing Docker's layers cache.
Salt should run the state command inside a docker container and commit after each state run.

[thatch45]

Right, the way to do this is to make a salt-thin tarball and then copy that into the container, untar it , and then mount the states directory into the container and run salt-call against them.

[thedrow]

salt-thin cannot commit the container after each state execution from within the container. Am I missing something?
The only way to implement this is to docker exec/nsenter into the container from the host and commit after the state run has completed successfully.

[meggiebot]

PR: #34484