4 ms·

I've used a lot of various configuration management systems over the years - CFengine, BCFG2, Puppet and now Ansible. Two notes- 1) They all work well for the

by e1ven 13y ago

I've used a lot of various configuration management systems over the years - CFengine, BCFG2, Puppet and now Ansible. Two notes- 1) They all work well for the base cases, and make it much easier to handle hundreds of machines - Being able to say "Ensure libcurl is installed on appserver, and make sure that nagios has these plugins we wrote" is amazing. But where every system starts to break down, is when we have setups that I have a good reason for, but don't fit into the preconceived notion of how to handle things. For example, if I want to install a package from source, or if I want to manually wget a .deb from an internal server, then dpkg -i it. What's nice is that most systems allow some flexibility - You can do 90% of things in the pre-written modules, and break out to do manual commands where necessary. 2) One thing I'd really like to see, though, is a system which operated with even LESS intelligence. Rather than using YAML files, or any sort of "user-friendly" config, let me define variables and use pure Python to iterate and execute using them. I'd love to have people give me pre-written modules as classes I can call, but having that exposed in a way I can get at it with native loops, if/then, etc, would make things a lot more straight forward. for server in webservers: server.ensure_perms('/var/lib/somefile',755) if server.name in qa_servers: server.ensure_line('/etc/profile','EXPORT RUBY_ENV=QA') I know I can write modules to do this, but it'd be awesome to do away with the concept of cookbooks, and let me just write everything in a more straightforward language.

falcolas 13y ago
While pure python executions would be nice (and are possible[1]), your examples are easily represented in the yaml files as well: --- - servers: webservers - tasks - file: mode=0755 path=/var/lib/somefile ... --- - servers: qa_servers - tasks - lineinfile: dest=/etc/profile line='EXPORT RUBY_ENV=QA' state=present [1] http://www.ansibleworks.com/docs/api.html http://www.ansibleworks.com/docs/api.html [EDIT]: Dropped names from tasks to make examples clearer.
- dalore 13y ago
  To nitpick, his example is slightly different. His goes through server by server and then does the 2 lines (if they match the name). Yours does the first task on all the webservers first and then the next part on all the qa_servers. In theory should produce the same output, but if something relied on doing it the first way that would be the difference.
  - falcolas 13y ago
    True, though as you note it's a subtle difference, and in my experience not something I've had to differentiate on. If you really needed the second task to rely on the output of the prior task, you'd probably want to use conditionals - something you can do without dropping back to the API.
- ufo 13y ago
  I know you are nitpicking but the point to using a library or embedded DSL is that you can run completely arbitrary logic inside it. For example, instead of just checking servers to see if they are in the qa_servers list he might have selected the servers that have a name starting with the letter "N" or dynamically fetch a list of server names...
  - falcolas 13y ago
    With conditional execution, you can do just that. However that is not really the best way to implement the example posited by the OP.
viraptor 13y ago
> let me define variables and use pure Python to iterate and execute using them. I think you should give Salt a go. While the usual way to run it is to describe stuff using yaml-via-jinja files, you can also create the same structure using standard python modules. Or if you really don't like the declarative way, just import the existing salt states and fire them the way you described over their api.
txutxu 13y ago
Yesterday I was playing with ansible, testing to migrate my already made across years scripts. My vote for the one who puts here an elegant solution for something as simple as: ssh user@host sed -i '/FOO/ s/FOO*/BAR/' /etc/bla/bla-* And a raw: command: or shell: does not count as elegant solution for the vote. The first parts is easy, you just have to learn a new DSL because ansible ignores your .ssh/config. The sed is easy to replace to with a lineinfile: But... how can I iterate over the remote files? I don't like my solution, is not elegant: - name: Get the list of remote files raw: printf '['; printf "'%s'," /etc/sysconfig/network-scripts/ifcfg-*; printf ']' register: p - name: Apply the change to the list of files lineinfile: dest={{ item }} regexp=^NETWORKING_IPV6 line='NETWORKING_IPV6=no' with_items: p.stdout My impression in general, after my first weekend with ansible: great But I see my old script to setup a daemon in a chroot, and I see "my" ansible version... and I don't know what to tell (the ansible version just multiplies the lines, in a much more verbose way, that finally looking at it, you have to think and concentrate much more, than looking at my old and direct .sh) At the end... this is not new: ssh WORD < SCRIPT Where WORD comes from your .ssh/config definitions (the inventory) and SCRIPT is up to you to define and organize properly. But I wish users of my software where so happy first day as I'm with my ansible experience.
- txutxu 13y ago
  And other thing I've learn this weekend. The documentation is great, but there is no "a reference", you have to read 5 or 6 different (long) pages to have an overview of what the DSL is, but the only reference is for the modules, not for the core. You can search for ansible playbooks in sites like github, and... even if you will find a few which do what they say, you will find many "test" repos, and you will find that the 95% of the available code (no from ansibleworks, but by third parties) implement very poor deployments, without even following basic best practices or any security in mind. I (as final user) would like a "cpan" or "rubygems" or whatever of ansible playbooks, more extended than the ansibleworks examples. Where people could share, search, vote, download (ansible get?), etc ansible playbooks. Just suggestions.
  - mpdehaan2 13y ago
pjungwir 13y ago
If you don't mind using Ruby instead of Python, this sounds a lot like Chef. All my Chef scripts wind up using a bunch of off-the-shelf cookbooks to install Postgres, Nginx, etc., then an app-specific recipe to do the rest. A recipe is just Ruby code (augmented with Chef's "resources"), and you can run code on the server with the ruby_block or bash resource. You can also import cookbooks to define more resources (or LWRPs). If you use chef-solo, librarian-chef, and knife solo, you cut out a lot of the complexity too.
- mpdehaan2 13y ago
  Yep, Chef would be an option if you want "infrastructure as code". Ansible takes a different track because I want to get out of the practice of writing code. (Different strokes, etc -- but it's intended to be faster to write and review)
  - nivertech 13y ago
    Chef - Infrastructure as a Code Ansible - Infrastructure as a Documentation ?
bradleyland 13y ago
Have a look at Sprinkle. Sprinkle "Installers" are more or less wrappers around shell scripts, so you can write an Installer class that can do just about anything you can do in shell. https://github.com/sprinkle-tool/sprinkle https://github.com/sprinkle-tool/sprinkle
- txutxu 13y ago
  Ansible also has a "script" module: http://www.ansibleworks.com/docs/modules.html#script http://www.ansibleworks.com/docs/modules.html#script
stevekemp 13y ago
If you're keen on using pure Python then you might enjoy using fabric. It's got fewer primitives than ansible, but allows you to write your logic easily. It runs via SSH and requires no particularly special setup: http://docs.fabfile.org/en/1.8/ http://docs.fabfile.org/en/1.8/ If you're a perl lover then my own tool, Slaughter, allows you to install packages, fetch files, and make use of the large CPAN library: http://www.steve.org.uk/Software/slaughter/guide/ http://www.steve.org.uk/Software/slaughter/guide/ Both of these tools are more basic than Ansible, but also more flexible, each in their own way.
- e1ven 13y ago
  I hadn't thought about Fabric in forever - Thanks for the reminder, I'll check it out again! It looks like it might be the perfect level of abstraction/automation with a minimum of magic.
  - stevekemp 13y ago
    Although I wrote a competing tool I have to admit I do like fabric. Many of my own web-applications use it for deployment, and for that purpose it works wonderfully: * Login via SSH to upload a tarball, generated via git. * Deploy on remote machine, with a versioned path. * Reload services. Just as simple as it needs to be.

by e1ven 13y ago

falcolas 13y ago

While pure python executions would be nice (and are possible[1]), your examples are easily represented in the yaml files as well: --- - servers: webservers - tasks - file: mode=0755 path=/var/lib/somefile ... --- - servers: qa_servers - tasks - lineinfile: dest=/etc/profile line='EXPORT RUBY_ENV=QA' state=present [1] http://www.ansibleworks.com/docs/api.html http://www.ansibleworks.com/docs/api.html [EDIT]: Dropped names from tasks to make examples clearer.

dalore 13y ago
To nitpick, his example is slightly different. His goes through server by server and then does the 2 lines (if they match the name). Yours does the first task on all the webservers first and then the next part on all the qa_servers. In theory should produce the same output, but if something relied on doing it the first way that would be the difference.
- falcolas 13y ago
  True, though as you note it's a subtle difference, and in my experience not something I've had to differentiate on. If you really needed the second task to rely on the output of the prior task, you'd probably want to use conditionals - something you can do without dropping back to the API.
ufo 13y ago
I know you are nitpicking but the point to using a library or embedded DSL is that you can run completely arbitrary logic inside it. For example, instead of just checking servers to see if they are in the qa_servers list he might have selected the servers that have a name starting with the letter "N" or dynamically fetch a list of server names...
- falcolas 13y ago
  With conditional execution, you can do just that. However that is not really the best way to implement the example posited by the OP.

viraptor 13y ago

> let me define variables and use pure Python to iterate and execute using them. I think you should give Salt a go. While the usual way to run it is to describe stuff using yaml-via-jinja files, you can also create the same structure using standard python modules. Or if you really don't like the declarative way, just import the existing salt states and fire them the way you described over their api.

txutxu 13y ago

Yesterday I was playing with ansible, testing to migrate my already made across years scripts. My vote for the one who puts here an elegant solution for something as simple as: ssh user@host sed -i '/FOO/ s/FOO*/BAR/' /etc/bla/bla-* And a raw: command: or shell: does not count as elegant solution for the vote. The first parts is easy, you just have to learn a new DSL because ansible ignores your .ssh/config. The sed is easy to replace to with a lineinfile: But... how can I iterate over the remote files? I don't like my solution, is not elegant: - name: Get the list of remote files raw: printf '['; printf "'%s'," /etc/sysconfig/network-scripts/ifcfg-*; printf ']' register: p - name: Apply the change to the list of files lineinfile: dest={{ item }} regexp=^NETWORKING_IPV6 line='NETWORKING_IPV6=no' with_items: p.stdout My impression in general, after my first weekend with ansible: great But I see my old script to setup a daemon in a chroot, and I see "my" ansible version... and I don't know what to tell (the ansible version just multiplies the lines, in a much more verbose way, that finally looking at it, you have to think and concentrate much more, than looking at my old and direct .sh) At the end... this is not new: ssh WORD < SCRIPT Where WORD comes from your .ssh/config definitions (the inventory) and SCRIPT is up to you to define and organize properly. But I wish users of my software where so happy first day as I'm with my ansible experience.

txutxu 13y ago
And other thing I've learn this weekend. The documentation is great, but there is no "a reference", you have to read 5 or 6 different (long) pages to have an overview of what the DSL is, but the only reference is for the modules, not for the core. You can search for ansible playbooks in sites like github, and... even if you will find a few which do what they say, you will find many "test" repos, and you will find that the 95% of the available code (no from ansibleworks, but by third parties) implement very poor deployments, without even following basic best practices or any security in mind. I (as final user) would like a "cpan" or "rubygems" or whatever of ansible playbooks, more extended than the ansibleworks examples. Where people could share, search, vote, download (ansible get?), etc ansible playbooks. Just suggestions.
- mpdehaan2 13y ago

pjungwir 13y ago

If you don't mind using Ruby instead of Python, this sounds a lot like Chef. All my Chef scripts wind up using a bunch of off-the-shelf cookbooks to install Postgres, Nginx, etc., then an app-specific recipe to do the rest. A recipe is just Ruby code (augmented with Chef's "resources"), and you can run code on the server with the ruby_block or bash resource. You can also import cookbooks to define more resources (or LWRPs). If you use chef-solo, librarian-chef, and knife solo, you cut out a lot of the complexity too.

mpdehaan2 13y ago
Yep, Chef would be an option if you want "infrastructure as code". Ansible takes a different track because I want to get out of the practice of writing code. (Different strokes, etc -- but it's intended to be faster to write and review)
- nivertech 13y ago
  Chef - Infrastructure as a Code Ansible - Infrastructure as a Documentation ?

bradleyland 13y ago

Have a look at Sprinkle. Sprinkle "Installers" are more or less wrappers around shell scripts, so you can write an Installer class that can do just about anything you can do in shell. https://github.com/sprinkle-tool/sprinkle https://github.com/sprinkle-tool/sprinkle

txutxu 13y ago
Ansible also has a "script" module: http://www.ansibleworks.com/docs/modules.html#script http://www.ansibleworks.com/docs/modules.html#script

stevekemp 13y ago

If you're keen on using pure Python then you might enjoy using fabric. It's got fewer primitives than ansible, but allows you to write your logic easily. It runs via SSH and requires no particularly special setup: http://docs.fabfile.org/en/1.8/ http://docs.fabfile.org/en/1.8/ If you're a perl lover then my own tool, Slaughter, allows you to install packages, fetch files, and make use of the large CPAN library: http://www.steve.org.uk/Software/slaughter/guide/ http://www.steve.org.uk/Software/slaughter/guide/ Both of these tools are more basic than Ansible, but also more flexible, each in their own way.

e1ven 13y ago
I hadn't thought about Fabric in forever - Thanks for the reminder, I'll check it out again! It looks like it might be the perfect level of abstraction/automation with a minimum of magic.
- stevekemp 13y ago
  Although I wrote a competing tool I have to admit I do like fabric. Many of my own web-applications use it for deployment, and for that purpose it works wonderfully: * Login via SSH to upload a tarball, generated via git. * Deploy on remote machine, with a versioned path. * Reload services. Just as simple as it needs to be.