2014-05-28 21:42 GMT+02:00 'Petros Moisiadis' via Ansible Project <
ansible-project@googlegroups.com>:
> But it seems you do have some specialized functionality embedded in your
> nginx role. For example you do fastcgi stuff. By fastcgi stuff I mean
> things such as configuration sections, structures and directives (e.g
> fastcgi_index, fastcgi_pass, etc.). I do not mean configuration data (such
> as {{ document_root }} or {{ fastcgi_script_name }}). If I could, I would
> abstract it further and put fastcgi stuff in a separate role that depends
> on nginx role. You would ask why to do that? Shouldn't the nginx know how
> to deploy fastcgi applications? Well, as you saw while planning for
> WordPress integration, sooner or later you will come across with a fastcgi
> (or php, or whatever) application A that needs different fastcgi
> configuration than the fastcgi configuration needed by a fastcgi
> application B. So you would need to abstract your fastcgi logic further.
> But this will also happen with your wsgi logic (which could also have its
> own universe with one app being deployed with modwsgi, another one with
> uwsgi, etc.), your php logic, your phusion passenger logic, etc. If you
> keep all this stuff in a single role, you will end up with a difficult to
> read and maintain project. So, I think splitting your deployment in
> multiple roles would make your life much easier. That said, I really
> appreciate the way you are thinking, as you do recognize the need for
> abstracting your basic roles, and I see that you have done what the current
> tools allow you to do for that purpose. It is just that Ansible does not
> (yet) give you a mechanism to modularize your roles in a cleaner way.
>
I know that different applications or frameworks require different
configuration. For this purpose, in my 'nginx' role I've included a way to
select which server template is used to generate nginx configuration.
Currently there's only one (
https://github.com/ginas/ginas/blob/master/playbooks/roles/ginas.nginx/templates/etc/nginx/sites-available/default.conf.j2which
is selected by default or by setting item.type: 'default'), but that
doesn't mean there couldn't be more - I plan to write separate one for
wordpress, for example.
Yes, with time, number of these templates will grow. But hopefully I will
be able to write them abstract enough that each one will be usable for many
applications. And you can even combine different files via Jinja extension
blocks - I currently don't use it in 'nginx', but you can see example in my
'apt' role which generates Debian Preseed configuration for normal and
destructive install (
https://github.com/ginas/ginas/tree/master/playbooks/roles/ginas.apt/templates/srv/www/sites/default/public/d-i/wheezy)
- files need to be in the same directory, and AFAIK using different
directories doesn't really work, but I haven't tested that extensively. I
plan to use similar mechanism in the future to build nginx server
configurations from parts (in fact my 'type' variable was planned with this
scenario in mind).
Other way around this would be to split nginx role into base and templates
and use them somehow via dependency. Problem with that is current nginx
configuration structure - you would probably want to create separate
directory for templating role, like /etc/nginx-templates/ and keep your
generated configuration there to not interfere with base nginx config files
- otherwise you could end up with chicken and egg problem where one role
requires /etc/nginx derectory which is created by a different role. Of
course Ansible could mitigate this with file: module, careful permissions
and still keeping your generated templates in non-standard directories
inside /etc/nginx/... It's a tricky question to answer, but I still feel
that adding separate mechanism in Ansible dependency functions to support
jinja extension blocks is a stretch and doesn't look too intuitive.
Maciej
--
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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAEnKK1xFiPAvLE3AG46Z7sv4QOT6zr-c22kO4XSQFzzRRn4sAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
