Using salt to build and manage docker images

[cha...@konversion.ca]

Hi.

We just started using salt, and it's clearly a very powerful tool with very few limitations, if any, in its ability to manage systems.

Our use case is mostly system configuration management(like ensuring users, files, directories exist), but I'm interested in its usefulness in application deployment.

Currently, we're using docker and docker-compose to build and deploy (mostly) python applications.

We're moving towards a microservice-style architecture, so we'll have more and more such applications to deploy and manage.

So we use docker-compose to build and deploy groups of services. That works pretty well.

However, we might also start using docker stack for deployment. docker stack doesn't deal with the build process, only the deployment, and expects images for all services to already be built and available.

So I guess we would still keep using docker-compose for building our images, since I prefer using declarative yaml configuration files to a bunch of cli flags in a bash script.

But I'm also thinking about alternatives to docker-compose for that purpose(for various reasons). I'm wondering if salt could be useful in that problem domain.

So I know there are state modules like docker_image and modules like dockermod and dockerng, but they don't seem to expose all features of the docker build system. Like labels, build args(in the case of the docker_image state).

So I guess my question is, what are people's opinion about using salt for the purpose of building docker images? Are there any useful patterns I should know about, or resources someone can point me to? Or does anyone have a suggestion for a tool that better fits that purpose?

Thanks all!

[Daniel Wallace]

I would highly recommend looking into using salt states to build your docker containers.

https://blog.gtmanfred.com/docker-and-salt.html

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/52a8e634-cfcb-4777-9a8f-61d2ecd7c22f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Charles Langlois]

Thanks for the suggestion. It's definitely an interesting approach.

I can certainly see the readability advantage of salt states over Dockerfiles.

However, I'm wondering what features of Dockerfiles(and the docker build process) this approach does and does not support.

However, I'm not sure about how I feel on using salt to do what docker and Dockerfiles are meant to do, and do well.

And going that route would imply rewriting all my Dockerfiles.

Another issue is that this would make me a bit too dependent on salt for my taste right now. I'm trying to use salt where there's an unfulfilled or unsatisfied need.

I'm pretty satisfied with using Dockerfiles to describe docker images, at least for now.

What I'm looking for right now is just a declarative layer over docker build, with some features like orchestration(i.e. what to build in what order).

I think salt is certainly capable of doing the job, I'm just not sure the current docker modules are up to the task right now. I guess I could always extend them.

The difficulty of using(and developing and maintaining) a salt module is to have a feature parity with the docker engine.

You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/_j_aiHHAGXQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/CAA2%2B9hC32BN3jjwX%2BzuXWxLuvQCheKaFCNwZF9yXDY6dca6eEQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Charles Langlois

     Programmeur-analyste - Programmer Analyst

www.konversion.ca

5605 avenue de Gaspé, Suite 902

Montréal, QC, Canada - H2T 2A4