6 ms·

I was in the same position - too many distinct environments for bash/Fabric, too little time to learn Chef/Puppet/CFEngine. Ansible [1] seems like a good compro

I was in the same position - too many distinct environments for bash/Fabric, too little time to learn Chef/Puppet/CFEngine. Ansible [1] seems like a good compromise: you get the simplicity (runs over SSH) and host targeting of Fabric with the declarative nature and idempotency of the more complex tools. You can start with all-in-one "playbooks" [2], then split out tasks, handlers, Jinja2 templates, files, and variables [3]. As an aside, I think the default fail2ban config is too loose and quiet. Here's [4] an Ansible task file that configures it to be more aggressive and send notification emails. [1] http://ansible.cc/ http://ansible.cc/ [2] https://gist.github.com/dbarlett/5079802 https://gist.github.com/dbarlett/5079802 [3] https://github.com/fdavis/ansible-best-practices https://github.com/fdavis/ansible-best-practices [4] https://gist.github.com/dbarlett/5079715 https://gist.github.com/dbarlett/5079715

slurgfest 14y ago
What do you usually do with these fail2ban notifications?
gingerlime 14y ago
I'm using fabric quite frequently, and am trying to understand what makes a configuration management tools a much better choice. I'm currently using fabric for anything from bootstrap a new environment from scratch, via restoring a snapshot from backups, to pushing code updates stored on git. Perhaps I'm being really daft, but it always evades me why something as simple as sudo("apt-get install -y <name your packages>") needs to be replaced with - name: Install prerequisites for PPA management apt: pkg=$item state=present update_cache=yes with_items: - python-software-properties - software-properties-common I do use a pretty homogeneous environment, which makes things simpler, but this is a deliberate choice to avoid complexity. If I know all my hosts are e.g. debian 6, then what makes ansible/chef/puppet so much better than fabric? I'm not trying to be provocative or negative. I'm really trying to understand the supposedly big difference between what's labelled a deployment tool, and configuration management tools.
- vacri 14y ago
  that same line in puppet is "package { 'packagename': ensure => installed }". Or you can use 'latest' to keep it updated. multiple packages can be done this way if you have a lot: $prep_packages = ['package1', 'package2', 'blahblah'] package { $prep_packages: ensure => installed } You can of course use extra arguments if you need them.
- zargon 14y ago
  Deployment tools like fabric are imperative, and configuration management tools are declarative. With configuration management, you define the final state you want the server to be in, and it will do whatever is needed to get it into that state. Some or all of the parts might already be done, and it won't change the parts that are already correct (the declarative configuration is idempotent). Deployment tools just execute whatever script you hand them, and so the scripts are either more brittle (server must be in a precise state beforehand or it doesn't work right), or require more effort to duplicate the work that the configuration management software does to only make the needed changes. If your deployment scripts get complex, it's more difficult to see at a glance what the end configuration is supposed to be.
  - gingerlime 14y ago
    Thanks for the clarification. I think I get the theory a bit better now. I'm still struggling with seeing some practical examples of those differences. for example, `apt-get` is pretty much idempotent already, no? if I run `apt-get install -y <package>` x 1000 times in a loop it won't install it 1000 times... Fabric does give you the building blocks for those kind of checks elsewhere, such as `exists`, `contains`, `append` (which is supposed to also be idempotent) etc... I've designed my deployment / bootstrap scripts with fabric to take this into account. It does add a little overhead, but nothing that makes me feel I need a better tool... Maybe my deployment base is still relatively small and homogeneous. So it's true that I have to put in those checks myself, and that I don't have a very easy way to discover what state a server is at. I'll try to take another stab at one of those tools. Maybe things will sink in when I actually use them. Thanks again for explaining.
vacri 14y ago
Eh, I didn't like Ansible. Every command is done over SSH, so you don't need an agent/ssh to box and run locally, but... scripts would take much longer to execute than in puppet. We're currently using local runs of puppet, and it's easy to do dry-runs and see what fails before applying when testing. I'm not sure how Ansible gives feedback on that (I assume it must) but I find puppet pretty good about it.
- crdoconnor 14y ago
  >but... scripts would take much longer to execute than in puppet. You can bootstrap 0mq and run them over that instead. That's much faster.

slurgfest 14y ago

What do you usually do with these fail2ban notifications?

gingerlime 14y ago

I'm using fabric quite frequently, and am trying to understand what makes a configuration management tools a much better choice. I'm currently using fabric for anything from bootstrap a new environment from scratch, via restoring a snapshot from backups, to pushing code updates stored on git. Perhaps I'm being really daft, but it always evades me why something as simple as sudo("apt-get install -y <name your packages>") needs to be replaced with - name: Install prerequisites for PPA management apt: pkg=$item state=present update_cache=yes with_items: - python-software-properties - software-properties-common I do use a pretty homogeneous environment, which makes things simpler, but this is a deliberate choice to avoid complexity. If I know all my hosts are e.g. debian 6, then what makes ansible/chef/puppet so much better than fabric? I'm not trying to be provocative or negative. I'm really trying to understand the supposedly big difference between what's labelled a deployment tool, and configuration management tools.

vacri 14y ago
that same line in puppet is "package { 'packagename': ensure => installed }". Or you can use 'latest' to keep it updated. multiple packages can be done this way if you have a lot: $prep_packages = ['package1', 'package2', 'blahblah'] package { $prep_packages: ensure => installed } You can of course use extra arguments if you need them.
zargon 14y ago
Deployment tools like fabric are imperative, and configuration management tools are declarative. With configuration management, you define the final state you want the server to be in, and it will do whatever is needed to get it into that state. Some or all of the parts might already be done, and it won't change the parts that are already correct (the declarative configuration is idempotent). Deployment tools just execute whatever script you hand them, and so the scripts are either more brittle (server must be in a precise state beforehand or it doesn't work right), or require more effort to duplicate the work that the configuration management software does to only make the needed changes. If your deployment scripts get complex, it's more difficult to see at a glance what the end configuration is supposed to be.
- gingerlime 14y ago
  Thanks for the clarification. I think I get the theory a bit better now. I'm still struggling with seeing some practical examples of those differences. for example, `apt-get` is pretty much idempotent already, no? if I run `apt-get install -y <package>` x 1000 times in a loop it won't install it 1000 times... Fabric does give you the building blocks for those kind of checks elsewhere, such as `exists`, `contains`, `append` (which is supposed to also be idempotent) etc... I've designed my deployment / bootstrap scripts with fabric to take this into account. It does add a little overhead, but nothing that makes me feel I need a better tool... Maybe my deployment base is still relatively small and homogeneous. So it's true that I have to put in those checks myself, and that I don't have a very easy way to discover what state a server is at. I'll try to take another stab at one of those tools. Maybe things will sink in when I actually use them. Thanks again for explaining.

vacri 14y ago

Eh, I didn't like Ansible. Every command is done over SSH, so you don't need an agent/ssh to box and run locally, but... scripts would take much longer to execute than in puppet. We're currently using local runs of puppet, and it's easy to do dry-runs and see what fails before applying when testing. I'm not sure how Ansible gives feedback on that (I assume it must) but I find puppet pretty good about it.

crdoconnor 14y ago
>but... scripts would take much longer to execute than in puppet. You can bootstrap 0mq and run them over that instead. That's much faster.