Ansible fulfills your requirements. Environment requires/asserts would be handle by tasks that can either be fired or can be decided to be skipped because they are already done (like apt task, it will install package only if it is not installed yet).

Ansible seems to be stable but sometimes you can find a subtle bug as it is still fairly young solution. On the bright side most bugs are fixed quickly.

It's open source and you can write your own plugins as well :)

Thanks @matixo! Even though it's a 2-day research project, I'm going to spend more time with Ansible with docker and vagrant to see how well it fits current/team's and future/mostly-my needs.

You can run many images in one container

I think you meant "you can run many containers from one image"

Nope, @kdomanski. Since I'm on MacOS, vagrant gives me the way to have a Linux container where I can run docker containers. That's my current understanding.

For me ansible has great tool https://galaxy.ansible.com/ where you can find, download and share roles.

@jaceklaskowski curious to know why Vagrant over boot2docker for investigations with docker containers on MacOS?

A few more aspects about ansible:

1. Ansible vault - let's you store data in an encrypted file which can be kept in version control system. You will only need to provide a vault password while running ansible-playbook. Useful if you need to set up some passwords for example and don't want to provide them in prompts every time
2. Roles - you can define several roles and assign the roles to hosts (based on groups in inventory). This way you can combine different roles across different hosts.
3. Using group_vars and inventories it is really easy to do the staging from development, through preproduction to production environments.

Docker is natively supported on Windows now (Windows 10 Pro, Education, and Enterprise, build 10586 and up, and Windows Server 2016) with future versions to come) and builds on top of Hyper-V. See https://docs.docker.com/engine/installation/windows/, https://www.docker.com/microsoft, and https://msdn.microsoft.com/en-us/virtualization/windowscontainers/docker/configure_docker_daemon. On Windows 10 client editions, it only supports Hyper-V containers, but on Server 2016, it'll support both Windows and Hyper-V containers (Windows containers are like Linux containers, with isolated process spaces but shared kernel; Hyper-V containers go a step further and provide host isolation with a VM).

You should probably remove SaltStack from this investigation since it was not really investigated. Based on your original requirements, all of them meet what is being requested. Chef can use "knife-ssh" https://docs.chef.io/knife_ssh.html. Salt can support doing the same by using Salt-ssh https://docs.saltstack.com/en/latest/topics/ssh/. Puppet and Chef have similar configuration for deployment as they are primarily using a DSL for writing code. Salt and Ansible are similar in that they use YAML by default for configuration. I believe Puppet and Chef are both implemented in Ruby where as Salt and Ansible are Python. When mentioning Docker, I don't know that one would necessarily have to have any of those tools as one could technically version one's Docker files with its instructions, and perhaps use Jenkins as a pipeline for both creating Docker files as well as perform deployments. One can use Vagrant with his or her provisioner of choice in the Vagrant file to call Salt, Chef, Puppet, etc to provision the image that is being created. By the statement, "Vagrant + Chef == Docker", I'm not sure if that is implying one is using this method to build Docker images or perhaps one is stating that one can autobuild instances comparable to the instructions in the Docker file. However, Packer from Hashicorp is a good tool for doing this, and I believe it supports generating Docker images as well.

agree with @hasues. I landed here assuming you have investigated Saltstack(which I am interested in).

This summary and ensuing discussion has been very helpful with conversations we're having trying to fully understand the choices, functionality and trade-offs.

Great overview of some of the tools available. For those investigating these and similar tools, it may be helpful to check out the user reviews on IT Central Station to get greater insight into real use cases and what was considered in the decision making process.

For example, one review by a SysAdmin (about VMware vRealize Automation, which isn't on this list, but was weighed up against Chef and Puppet) highlights that their decision took into account what would work across different operating systems:

"When selecting a vendor, the biggest thing for us is multi-operating system support. There is the classic divide. I'm on the Windows side. We have a Linux department also. When looking at different tools, something might be better for Linux but we have to have something that will work for both of us. We don't want to have two different tools for two operating systems. Whereas the Linux team wanted to use Puppet instead of Chef, Chef supports Windows and Linux both, better. The nice thing about VMware, aside from it being a lot more OS-agnostic, is that both teams can use the product. One product for both operating systems. That was one of the primary things. We could have a tool that runs great, but it might be a situation where, "Oh yeah, your Windows support is lame." That's the big thing for us, the interoperability between operating systems."