Mitchell Hashimoto, the guy who created Vagrant, says he just mostly uses shell scripts here:
"I think a lot of projects I start, almost all of them, they're just like, I have the standard Rails shell script I use that sets up everything for Rails, and the standard Go shell script and things like that. So, I just use shell scripts."
"Puppet? I am sorry but Puppet, chef and their ilk are horrible, who knows what state any machine is ever in at any point in time. humans will inevitably forget to ensure absent, or make an assumption about state in puppet land."
From the Ansible author:
"I know things like Packer like to walk people down a more imagey road, but you can also use config tools to describe the recipes that build your images, and that would include Ansible, Puppet, Chef, or even (if you so wished) bash."
"You can still use Chef, Puppet, CFEngine or Ansible to build your images, but as they aren't built for an immutable infrastructure workflow they tend to be more complex than necessary."
At 57 minutes
"FLORIAN: No, I mean in terms of just building infrastructure. The way we build infrastructure generally is really to make every part of it replaceable at any point. So, for example we use for Amazon, so generally use platform as a service if possible because then other people have to deal with it. So, we use Heroku for a lot of stuff. Deployment to Heroku is simple. They follow the model of immutability so everything just gets replaced at any point. So, that works really well.
On Amazon themselves, there's Packer, there's Docker, and tons of other tools coming out now that really make it very easy to build the infrastructure in a way where change is not really a problem because you just replace stuff. In our experience, any kind of Chef or any other, Chef, Puppet, or other tools where you just try to get convergent state at some point. And maybe some deployment fails on some servers, but then Chef tries to get that in a place where it is actually at the point where you expect it to be. That's really painful.
So, really building images and then starting from those images and the immutability thought, but basically it's the same that we do in software with classes and instances. You just have that class and then you instantiate 1, 15, 50 or a thousand of those machines. And the same thought process can be used for infrastructure as well. You just need to start building it in a way. And there are services and microservices that help a lot where you can replace any part of your system. You have load balancers in between where it can switch between services and between servers then. And that's something.
So, those kinds of tools, Packer, Docker, Terraform, all of the, from the Vagrant guys, from HashiCorp, they are doing great tools for that. That's really helpful. Obviously, a good continuous delivery system is as well. And I'm sure that we have all of our different opinions on which are the cool ones. But generally, yeah I think outsourcing as much as you can and focusing on the stuff that is really important and building everything in your infrastructure in a way that can be changed at any point without you noticing, without you knowing, that's really the key.
BADRI: Yeah. And the interesting thing is we do immutable environments as well but we use Chef and Puppet to bring up the immutable environment. We use base AMIs which don't contain too much. We follow Amazon's mantra of just enough OS. And then we use Chef to bring up the environment, but the environment is completely brought up from scratch each time and then we deploy your application onto it. So, there aren't any of those convergence issues that we typically deal with. So yeah, that is one thing that we follow as well. In addition to that, I think everything that Florian said is very relevant to all teams trying to do this."
blog-post-nixos-and-stateless-deployment
blog-post-why-puppet-chef-ansible-arent-good-enough
blog-post-immutable-deployments-chad-fowler
blog-post-testing-huge-postgres-backups