Hacker News Reader

Comment by matt_wulfeck | Hacker News Reader

Ansible and Salt were both huge steps forward for provisioning. However, after switching to immutable resources I've largely replaced the need for such services.

I don't mind that there's a panoply of bash scripts to configure docker builds. It's simple and it works and nearly every engineer worth anything knows how to read and write them.

A good bash script never goes out of style.

View on HN

I might be the only one that does this, but I like using ansible with docker.

I use a Dockerfile for any long running tasks like installing dependencies so I can take advantage of docker's cache. I then use ansible for fast running configuration like using a template file for filling out user specific configuration.

The biggest disadvantage to this is that you have to add ansible as a dependency in all of your containers, which stinks. I feel like it produces easier-to-read configuration.

Don't get me wrong, bash scripting is a great tool. I just try to avoid it whenever I can because I personally don't like writing bash scripts.

I think in the future there might be a best of both worlds approach if docker adds a caching api to where ansible could interact with it directly. There is also a docker connection plugin added in this release that could add some possibilities.

I don't think you're the only one. I ran saltstack with my containers for awhile, but it just created too many dependencies (as you notice yourself) and made the build process difficult.

I find that if I keep things in bash the images become more "dumb" and therefore more portable.

In lieu of a caching API you might find a package cache (apt-cacher-ng, squid, etc) will help speed up installs a lot. I found one image that was pulling down almost 5 GB with every build!

Writing ansible is faster and less error prone than a bash script. It's additionally better organized and maintainable. I use it for both immutable and manual deployments.

Writing bash scripts becomes a lot less error prone with shellcheck[1]. Syntastic for vim integrates well with it.

[1]: https://github.com/koalaman/shellcheck

True... if you suck at Bash.

Bash unequivocally sucks this is not to say it doesn't have its uses.

No, it doesn't suck more than YAML-based scripting. I write complex Bash scripts daily - if I have to write the same in, let's say, Python, it would take longer, will possibly run slower, and will definitely take longer to test. Again, Bash is a nice tool, but you need to learn it well.

how do you test bash scripts?

I've used bats[1] in the past. I also recommend the command line shellcheck[2] for linting.

[1] https://github.com/sstephenson/bats [2] https://github.com/koalaman/shellcheck

Sorry but the question is not if you suck or not at bash. The issue is that there's always someone else that DOES suck at it, in unimaginable ways, and the regular guys like you and me have to deal with it. And there, Ansible helps!

In terms of user configuration in containers, Tiller (https://github.com/markround/tiller) is very much worth a look.

I've built a few hundred lines of code Bash library, and Ansible feels like an overengineered tool now. But it's true that immutable infrastructure changes the requirements as we use Packer and Docker these days. I personally think writing Bash equivalents in YAML is crazy. The abuse of YAML these days is unbelievable. It reminds me the days when people invented XML scripting, just because it was easy to parse XML. YAML-based scripting is no different. I'm sad that Chef doesn't get as much attention as it deserves as Chef Solo is sane.

We use Ansible for basic installation of a new cloud server and Docker to deploy services on these machines. The two technologies together work just fine for us.

I actually use Ansible to build Docker containers and it works really, really well. Much nicer than Bash scripts.

Reply on news.ycombinator.com