Hacker News Reader

Comment by jquast | Hacker News Reader

I believe deployments should be described as declarative data, not as imperative code.

Declarative: can first be tested, verified, dry-run, and implemented in any language. salt (my preferred CM) has yaml data files that can be analyzed and verified long before any system command occurs, for example.

Imperitive: You don't know what it does unless you run it. You don't even know if it will execute without syntax error, especially in a dynamic language like bash (posixcube) or ruby (chef, et al).

View on HN

Let's say I want to whitelist a set of IP addresses in the firewall configuration. Let's assume I know the commands to do this using firewall-cmd. Below is how I would do this with posixcube. Can you give an example with a declarative system of your choice for comparison?

  # Loop through the list of servers passed in
  for cubevar_app_server in ${cubevar_app_servers}; do
    # Get the IP address of the server
    cubevar_app_server_ip="$(dig +short ${cubevar_app_server} || cube_check_return)" || cube_check_return
    
    # Skip ourselves by comparing to our hostname
    if [ "${cubevar_app_server}" != "$(cube_hostname)" ]; then
      if ! firewall-cmd -q --zone=trusted --query-source=${cubevar_app_server_ip} ; then
        cube_echo "Adding ${cubevar_app_server}'s IP ${cubevar_app_server_ip} to trusted whitelist"
        firewall-cmd --zone=trusted --add-source=${cubevar_app_server_ip} || cube_check_return
        firewall-cmd --permanent --zone=trusted --add-source=${cubevar_app_server_ip} || cube_check_return
      fi
    fi
  done

This would be run as follows (where the -o parameter is expanded from ~/.ssh/known_hosts):

  posixcube.sh -h $TARGETSERVER -o cubevar_app_servers=*.mydomain.com -c firewall_whitelist

Generally the ip addresses would be selected by host groups (eg: all) - and if "firewall-command" was the canonical way to add rules, that'd probably be what eg Ansible would run on each platform.

An argument might be made that this would live better in a (templated or not) config file in version control - and then the action become: fill in template, push config, (re)load config.

In this case, for Ansible, you'd probably try to use command (there's also she'll, but simple is better - when possible): http://docs.ansible.com/ansible/command_module.html

I want to see a fully fleshed out example for comparison. When I find some time, I plan to take this use case as an example, implement it in all major automation frameworks, and publish the comparison.

Right, I suppose for Ansible the idiomatic approach is to write/use a plugin - like:

http://docs.ansible.com/ansible/firewalld_module.html

Expanding the white-list of ips is a matter of config/templates.

Fwiw, I do think Ansible tend to get a bit complicated because plugins tend to get a bit opaque and complicated. On the other hand, some simple special variables like "all_other_servers" to avoid manually filtering out "self" procedurally all the time is probably a good idea.

I'm not sure if I'll be able to spare the time - but I'll at least watch the github repository - perhaps I can try and help flesh out some alternative examples if you file an issue?

[ed: perhaps such things should go here?

https://github.com/myplaceonline/posixcube/issues/4 ]

Agreed. I referenced this discussion in that issue and hopefully soon I'll get around to building it (would be wonderful if you could help). Thanks for the pointers; they'll save me some time learning Ansible.

Reply on news.ycombinator.com