I wish there was a server provisioning "library" written in an ML-ish language.<p>The trouble with even a simple, well-made tool like Ansible is its dynamic DSL. The YAML file is essentially code, but modules like "file" and "apt" written as configuration entries give a declarative feel to it. But they are just procedures that strive to be idempotent, and its YAML file is just a series of procedure calls, sprinkled with some facility for organizing hierarchies and sharing code between them.<p>YAML the format is also not a great way to encode systems data. Thankfully Ansible has documented the gotchas with its space-indentation and need for explicit quoting in <a href="http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotchas" rel="nofollow">http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotch...</a>. But that is just an attempt to band-aid over the unsuitability of YAML for this purpose.<p>Chef's configuration on the other hand can be done in Ruby, but you're still constrained to its DSLs. The shape and structure of Chef's objects can only gleaned by reading reams of documentation, and worse, by running the cookbooks with debug statements.<p>The problem is compounded when you upgrade these tools and things stop working silently. The community solution for this unsurprisingly is unit tests. I'm still grappling with that idea.<p>But what if we could write our own provisioning code in Haskell or OCaml/Reason, with library functions that help install packages, returns errors in neat sum types which we can confidently handle and doesn't leave us to worry about the known unknowns that we haven't enumerated and handled, and a compiler with exhaustive pattern matching that helpfully tells us about all the record types and their structure within a fast edit-compile cycle, ...
A couple years ago I was working at a start-up on a team of about 3 developers. I was 20 years old and knew nothing about configuration management, but we needed it, so I bought a book ("x for devops" - trying not to advertise), and got an automation pipeline in place that got the job done.<p>Cannot stress enough to new developers how you should have one of Ansible, Puppet, etc., framework under your belt to improve your ability to build software products. I'd recommend picking one that works equally good with old legacy systems, rather then just whatever is new like Kubernetes, because it will seriously broaden your career options and make you an asset to almost every software company.<p>EDIT: to clarify, k8s can obviously be used with legacy software applications. But the idea was that if you get hired by $some_old_PHP_shop throwing Ansible into the mix may have significantly less friction then convincing whoever is in charge to start maintaining k8s clusters.
OK, have to say this is pretty cool. Reading about how to do something is good, but ephemeral. Applying what you are learning (and making mistakes and figure out what went wrong) is a far better way to learn. Kudos to the author of this tutorial.
For me the hardest part about Ansible was getting the ssh setup correct to connect to a remote machine. Having a quick browse of this tutorial I can't see much about that (maybe I missed it). That would be useful if you plan to update the tutorial.
I like how Ansible shows how sometimes technology can come full circle.<p>Ansible started as a more organized way to manage infrastructure beyond hacks and handmade scripts. As technology matured and infrastructure become more complex, the simplicity of Ansible fell short, and tools like Puppet and Chef came into scene.<p>But technology kept pushing forward, and these tools evolved to become increasingly complex until they become behemoths with towering ecosystems around them.<p>Enter containers and container orchestration. Suddenly many of the problems that configuration managers were trying to solve aren't there anymore. And suddenly Ansible simplicity, which became its weakness, has become its strength.