8 ms·

Show HN: Interactive Ansible Tutorial

170 points by erkanerol 9y ago

collyw 9y ago
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.
- emmelaich 9y ago
  I put everything into git; the ssh-config file, the keys, the hosts file. I then wrote a wrapper (also in git) that invoked ansible with all the correct/preferred settings. Works a treat.
- lolikoisuru 9y ago
  The ssh configuration is one of the reasons I still haven't been able to move to Ansible properly. I managed to get it working somewhat without any controlmasters but I would much prefer having those, they significantly speed up making the connections when jumping through 2 hosts. Even without controlmasters when using higher parallellism than the default 5 it the ssh connections start to fail for no apparent reason. E: And another reason I would love to not use Ansible is the god awful YAML. It's a horrible choice for a tool like this.
- tokenizerrr 9y ago
  As far as I know all you have to do is configure your ~/.ssh/config properly, and then use the hostnames set there. Same as regular old OpenSSH. Just don't opt into the Paramiko control scheme, which isn't used by default except on RHEL6 anyway. You can also set ssh_args in the config file to enable ControlMaster, etc. http://docs.ansible.com/ansible/latest/intro_configuration.html#openssh-specific-settings http://docs.ansible.com/ansible/latest/intro_configuration.h...
- beefhash 9y ago
  Truly, this is the modern-day equivalent of setting up UUCP.
angarg12 9y ago
I like how Ansible shows how sometimes technology can come full circle. 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. But technology kept pushing forward, and these tools evolved to become increasingly complex until they become behemoths with towering ecosystems around them. 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.
- FooBarWidget 9y ago
  > As technology matured and infrastructure become more complex, the simplicity of Ansible fell short, and tools like Puppet and Chef came into scene. Wait what? I'm pretty sure Ansible came after Puppet and Chef, not the other way around.
  - deleted 9y ago
    [deleted]
  - oblio 9y ago
    CFEngine 1993 (for completeness) Puppet 2005 Chef 2009 Salt 2011 (also for completeness) Ansible 2012 OP's timeline is a bit off :)
    - dullgiulio 9y ago
      Before CFEngine, people used the 'm4' macro processor to generate configuration files. It was very common for sendmail ones, but also for fast replication with minimal differences.
    - liveoneggs 9y ago
      rdist 1983
  - angarg12 9y ago
jasim 9y ago
I wish there was a server provisioning "library" written in an ML-ish language. 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. 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 http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotchas http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotch.... But that is just an attempt to band-aid over the unsuitability of YAML for this purpose. 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. 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. 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, ...
- crdoconnor 9y ago
  >The YAML file is essentially code YAML is not turing complete and is hence not "code". That is a large part of what makes ansible such a powerful tool - it enforces a strict separation of concerns between the definition of server configuration and its execution and keeps one in a language that is deliberately not able to be made more complex than is needed, is thus kept readable and straightforward to maintain. By contrast, turing complete languages are veritable magnets for technical debt, which is why a bad chef playbook will always be worse than a bad ansible playbook. Haskell, being turing complete, would suffer the same issue albeit not to the same degree as ruby. >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 http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotch... http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotch.... But that is just an attempt to band-aid over the unsuitability of YAML for this purpose. YAML has a few oblique gotchas but they don't affect the fundamental suitability of it for this purpose. Once you get used to it, space indentation becomes a feature, not a bug.
sideshowb 9y ago
It's a trap, Ender, this is not a tutorial!
ffdixon1 9y ago
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.
ben_jones 9y ago
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. 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. 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.
- kkoppenhaver 9y ago
  "hired by $some_old_PHP_shop throwing Ansible into the mix" Wholeheartedly agree. Got brought on board and Ansible was the first tool I reached for (there was previously nothing like this in place). The new tech is great, but something more broad in scope that can work with different kinds of systems can really come in handy if you're not working on new tech or greenfield projects.
minusf 9y ago
https://pyinfra.readthedocs.io/ https://pyinfra.readthedocs.io/

170 points by erkanerol 9y ago

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.

emmelaich 9y ago
I put everything into git; the ssh-config file, the keys, the hosts file. I then wrote a wrapper (also in git) that invoked ansible with all the correct/preferred settings. Works a treat.
lolikoisuru 9y ago
The ssh configuration is one of the reasons I still haven't been able to move to Ansible properly. I managed to get it working somewhat without any controlmasters but I would much prefer having those, they significantly speed up making the connections when jumping through 2 hosts. Even without controlmasters when using higher parallellism than the default 5 it the ssh connections start to fail for no apparent reason. E: And another reason I would love to not use Ansible is the god awful YAML. It's a horrible choice for a tool like this.
tokenizerrr 9y ago
As far as I know all you have to do is configure your ~/.ssh/config properly, and then use the hostnames set there. Same as regular old OpenSSH. Just don't opt into the Paramiko control scheme, which isn't used by default except on RHEL6 anyway. You can also set ssh_args in the config file to enable ControlMaster, etc. http://docs.ansible.com/ansible/latest/intro_configuration.html#openssh-specific-settings http://docs.ansible.com/ansible/latest/intro_configuration.h...
beefhash 9y ago
Truly, this is the modern-day equivalent of setting up UUCP.

angarg12 9y ago

I like how Ansible shows how sometimes technology can come full circle. 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. But technology kept pushing forward, and these tools evolved to become increasingly complex until they become behemoths with towering ecosystems around them. 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.

FooBarWidget 9y ago
> As technology matured and infrastructure become more complex, the simplicity of Ansible fell short, and tools like Puppet and Chef came into scene. Wait what? I'm pretty sure Ansible came after Puppet and Chef, not the other way around.
- deleted 9y ago
  [deleted]
- oblio 9y ago
  CFEngine 1993 (for completeness) Puppet 2005 Chef 2009 Salt 2011 (also for completeness) Ansible 2012 OP's timeline is a bit off :)
  - dullgiulio 9y ago
    Before CFEngine, people used the 'm4' macro processor to generate configuration files. It was very common for sendmail ones, but also for fast replication with minimal differences.
  - liveoneggs 9y ago
    rdist 1983
- angarg12 9y ago

jasim 9y ago

I wish there was a server provisioning "library" written in an ML-ish language. 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. 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 http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotchas http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotch.... But that is just an attempt to band-aid over the unsuitability of YAML for this purpose. 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. 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. 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, ...

crdoconnor 9y ago
>The YAML file is essentially code YAML is not turing complete and is hence not "code". That is a large part of what makes ansible such a powerful tool - it enforces a strict separation of concerns between the definition of server configuration and its execution and keeps one in a language that is deliberately not able to be made more complex than is needed, is thus kept readable and straightforward to maintain. By contrast, turing complete languages are veritable magnets for technical debt, which is why a bad chef playbook will always be worse than a bad ansible playbook. Haskell, being turing complete, would suffer the same issue albeit not to the same degree as ruby. >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 http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotch... http://docs.ansible.com/ansible/latest/YAMLSyntax.html#gotch.... But that is just an attempt to band-aid over the unsuitability of YAML for this purpose. YAML has a few oblique gotchas but they don't affect the fundamental suitability of it for this purpose. Once you get used to it, space indentation becomes a feature, not a bug.

sideshowb 9y ago

It's a trap, Ender, this is not a tutorial!

ffdixon1 9y ago

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.

ben_jones 9y ago

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. 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. 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.

kkoppenhaver 9y ago
"hired by $some_old_PHP_shop throwing Ansible into the mix" Wholeheartedly agree. Got brought on board and Ansible was the first tool I reached for (there was previously nothing like this in place). The new tech is great, but something more broad in scope that can work with different kinds of systems can really come in handy if you're not working on new tech or greenfield projects.

minusf 9y ago

https://pyinfra.readthedocs.io/ https://pyinfra.readthedocs.io/