I don't necessarily want to save time, but have a well-designed setup that
saves me from having headaches / making mistakes later on. Take the
following task from my apache role:
- name: "disable SSLv2 & SSLv3"
lineinfile:
dest: !platform
Debian: /etc/apache2/mods-available/ssl.conf
Gentoo: /etc/apache2/vhosts.d/00_default_ssl_vhost.conf
RedHat: /etc/httpd/conf.d/ssl.conf
regexp: "{{ item.regexp }}"
line: "{{ item.line }}"
with_items:
- { regexp: '^\s*SSLProtocol ', line: 'SSLProtocol ALL -SSLv2 -SSLv3' }
notify:
- reload apache
tags:
- apache/setup
It's our policy to not use SSLv2 or v3. That policy is expressed in one
place (and one place only). If I had one lineinfile task for each OS
(possibly in separate files), I'd have to duplicate the policy to all those
places. If we want to disable TLS 1.0 in the future, it would have to be
changed in multiple places -- something that programmers avoid rigorously,
so why should it be different in a devops context? The thing I want to
achieve is "install Apache on a server", not "install Apache on Debian" and
"install Apache on RedHat" and "install Apache on Gentoo".
Ansible (and other cfg mgmt systems as well, I assume) imposes quite some
annoying restrictions on ops work ("it would be so much easier to just SSH
in and fix this manually"), but that's ok because it provides
reproducibility and system documentation -- and OS abstraction. To me, that
is one of the major points of using config management in the first place --
reproducibility and documentation can be achieved using shell scripts,
possibly with less effort than by using cfg mgmt.
I'd say that the OS abstraction in ops is like the database abstraction
layer in dev work. I've seen a few posts in this group which recommend
creating separate Apache roles for each distro -- to me, they all sound
like: "Database abstraction is really hard -- if your application needs to
support both MySQL and Postgres as a backend, you should create two totally
independent forks of your application, one for each database."
@Brian: I think the package module is a very good thing. For most use
cases, this is the perfect module -- for everything else one can still use
yum, apt, etc. in combination with "when: ansible_os_family == 'foobar'".
The same design could be applied to the service module: split into separate
modules so you can use all the fancy features of specific init systems if
you want/need to, but also provide an "ansible_svc_mgr" fact and a
"service" module / action plugin that work like "ansible_pkg_mgr" and the
new "package" module.
On Wednesday, June 10, 2015 at 6:34:34 PM UTC+2, Dick Davies wrote:
>
> I've seen that attempted with Puppet and it works out badly in practice.
>
> Different distros put files in different locations, use different init
> systems, have
> different conventions for 'includes', name packages differently.
>
> Having one 'magic' class that makes it easy to type a config seems like
> it'll
> save you time. until you have to debug it.
>
> On 10 June 2015 at 16:43, Christian Thiemann <[email protected]
> <javascript:>> wrote:
> > I want all my Apache installation to behave the same on all OSs -- I
> want to
> > write one logical model of how Apache should work, and all OS
> differences
> > should just be different views of that model.
> >
> > Thus, this is how my "install Apache packages" task looks like -- one
> task,
> > one data structure, thanks to some YAML magic:
> >
> > - include: install_packages.yml
> > pkgs: !platform
> > - apache::
> > Debian: apache2
> > RedHat: httpd
> > - mod_authnz_external::
> > Debian: libapache2-mod-authnz-external
> > - python-passlib:: # needed for Ansible's htpasswd module
> > Gentoo: dev-python/passlib
> > - pwauth
> > tags:
> > - apache/setup
> >
> >
> > If I had separate include files per OS, then my list of packages would
> be
> > duplicated in multiple files -- I mean the logical list of packages
> (i.e.,
> > "apache" + "mod_authnz_external" + "python's passlib"). If I have to add
> > another mod_foobar in the future, I only have to add it to one list
> instead
> > of having to remember to maintain multiple OS-dependent representations
> in
> > multiple places.
> >
> >
> > On Monday, June 8, 2015 at 7:15:59 PM UTC+2, Brian Coca wrote:
> >>
> >> @Adam,
> >>
> >> Agreed, this workaround just offsets the work of having 2 tasks to
> >> having 2 data structures and is more limited than the other version,
> >> this is one of the reasons why we do not recommend it, but it is
> >> available if people insist going down that path.
> >>
> >>
> >> --
> >> Brian Coca
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "Ansible Project" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to [email protected] <javascript:>.
> > To post to this group, send email to [email protected]
> <javascript:>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/ansible-project/c138e7cc-9bac-46c4-bf75-deca40e290f0%40googlegroups.com.
>
>
> >
> > For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/0679b1dd-7e01-462c-bd3b-5c423677c182%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
