Hacker News Reader

Comment by codygman | Hacker News Reader

> Ansible, as an example, would abstract away the CLI commands and be very readable in very few lines.

If it's just a few lines can you give an example?

Sure:

    - name: install the latest version of Apache and MariaDB
      package:
        name:
          - httpd
          - mariadb-server
        state: latest

And the same thing in Chef:

    package %w(httpd mariadb-server)

That's an ansible task to do something, but it's not the task solved in the article, or in any of the other linked examples.

Things that you haven't done before are harder than things you do all the time, and I would've reckoned trying to do them in ansible is much harder than doing it interactively, but I'd be interested in learning.

If I find an article like this[1], how do you translate it into the artefact I would want to keep in source control? In org-babel it's this[2], so what would that look like in ansible?

[1]: https://www.digitalocean.com/community/tutorials/how-to-set-...

[2]: http://www.howardism.org/Technical/Emacs/linux-iptables.org....

Once you've done it and you've documented it, I can see how you might translate that into ansible (or chef or whatever), but that's a different thing.

Modifying iptables rules is such a common operation that all configuration management languages would support them natively.

Using an iptables module for Ansible it is straightforward to write the rules as yaml. The documentation has a clear example.

However, having used several of these languages for over a decade and realizing this is a contentious issue within the community, I would actually avoid using these tools for individual rules. What I would do is dump the rules to a file, distribute the file, and let Ansible make sure the file matches what is running (by way of a regular rule load when necessary).

The idea here is that I am already familiar with iptables rules and how to write them, and would expect any other ops-ish person to be the same. The source file matches the output, and any historical diffs will be much more straightforward to read, as there are no intermediary source formats that can change.

Also, there is one less Ansible dependency involved, and less syntax to learn (given that one can already read iptables rules).

That's pretty much what I expected; I think that's pretty common, and that's exactly what the author claims to do (use this process for discovery and learnings, then write some guff for chef once they know what they're doing).

It was common to hear that you can only automate what you do manually, but these days a lot of the underlying tasks have changed. Iptables is an absolute doddle to automate, TBH, and the entire security coverage that Iptables offered has often been superseded by security groups in AWS, sidecar proxies with service meshes, etc, so the whole paradigm has changed. What I meant about the article being quite old, is not just that the solutions are old, but the problems being solved have gone away, or should have. Ok, I did come across a client at the beginning of the year doing it the old way, but they were an Internet Exchange around since 1994, so I understood that.

I'm not sure I'm following exactly.

Are you saying that everything (or almost everything) worth automating is already automated by someone else so learning how to do new things isn't important?

> - name: install the latest version of Apache and MariaDB

That's not a name, that an intention describing comment, why isn't it called that way (or for brevity's sake, just "comment")? That might be nit-picking, but IMHO such misnomer cause unnecessary confusion and at the very least make the tool harder to learn.

That’s the name of the task you’re running.

Reply on news.ycombinator.com