On 05/28/14 20:55, Maciej Delmanowski wrote:
> 2014-05-28 17:55 GMT+02:00 'Petros Moisiadis' via Ansible Project
> <[email protected]
> <mailto:[email protected]>>:
>
> On 05/28/14 18:17, Maciej Delmanowski wrote:
>>
>> > It is true that software that has support for include
>> directories can
>>
>> > help, but it become less helpful as you add more levels in ther
>> hierarchy
>> >
>> > For example, consider a tree like this:
>> >
>> > 'apache' role
>> > |
>> >
>> +-------------------------+-------------------------+
>> > | |
>> > |
>> > 'wsgi_app' role 'php_app' role
>> > 'passenger_app'
>> > |
>> |
>> > +-----------------------+
>> > +------------------------+
>> > | | |
>> > |
>> > 'django_app' role 'flask_app' role 'redmine_app'
>> > role 'gitlab_app' role
>> >
>> >
>> > Deploying all or a subset of the above roles on the same server
>> could be
>> > most easily done if my proposal for template encapsulation was
>> available.
>>
>> Maybe most easily, but definitely not impossible. Currently I can
>> deploy gitlab, gitlab-ci, phpmyadmin, phpipam, etherpad,
>> owncloud, all on the same server behind nginx. I don't see how
>> including templates in nginx role from other roles to make that
>> possible could help me.
>>
>
> I am sure that you can deploy all these and that you are happy
> with the result. However, I took a look at your nginx role and it
> seems you are doing exactly what I believe people could (and
> should) avoid with template encapsulation. It seems you are
> creating a "super-role" merging together what could be at least 3
> separate roles connected through dependencies: nginx, fastcgi_app,
> php_app. If you prefer that monolithic way of doing things, it's
> fine. You will be one of those who will not be excited by a
> feature like the one I propose and probably never use it.
>
>
> Actually my playbook does exactly what you suggest - 'fastcgi_app'
> role (say, gitlab), uses 'nginx' role as dependency and passes its
> configuration via hash variable. Similarly, PHP5-based role (like
> ownCloud), uses 'php5' role as a dependency to create custom php5-fpm
> pool for itself, and 'nginx' role as another dependency similarly with
> its own custom configuration passed via hash variable.
>
> Inside 'nginx' role, a server template generates server configuration
> for each "parent" role, puts it in its own file in
> /etc/nginx/sites-available/ and enables it by symlinking it to
> /etc/nginx/sites-available/.
>
> The idea behind this was to abstract nginx configuration and
> management away from gitlab and owncloud roles, so that you could
> define for example your own SSL certificates or other server-wide
> configuration in one place. I treat Ansible roles which support
> dependencies like these like blackboxes (from the perspective of a
> role that uses them as dependency) with common interface - how nginx
> configures itself shouldn't matter for gitlab. That way I could
> replace nginx with apache2 (with similar interface prepared
> beforehand) and gitlab role should be none the wiser.
>
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.
> In fact, I stumbled on a similar problem you describe just recently,
> while planning WordPress integration - you can see
> here http://codex.wordpress.org/Nginx that proper installation
> requires a lot more configuration in nginx that should be necessary to
> include in base nginx role. Because of that I'm thinking about
> creating a directory inside /etc/nginx/ where other roles could place
> their own nginx configuration (either via copy or template) and
> include it in their nginx server configuration - but not on Ansible
> level, but using nginx "include" option.
>
Since my suggestion for allowing template encapsulation between roles is
not (yet) implemented, I would encourage you to go that way and use the
nginx "include" option. However, I believe that jinja's "template
inheritance" would be more flexible than the basic "include" mechanism
provided by systems like nginx. For example, with jinja you could have a
section with some desired content when the role would be deployed
standalone, or override that section with some different (more specific)
content when the role is deployed as part of a dependency. I am not sure
if that can be done (easily and cleanly) with an ngix type of "include"
mechanism. Also, keep in mind that there are systems that they do NOT
provide such an "include" mechanism at all.
> As you can hopefully see, I don't want to create a super-role for
> nginx, but instead I want to include just enough logic and room in
> that role so that other roles could use it comfortably. It might not
> be optimal or simple, as Michael would suggest, but it's a tradeoff
> between simplicity and customization which I feel will be beneficial
> for me in the long run - instead of creating specific nginx roles for
> many servers, I'm trying to create one general and reusable one.
>
>> > I have a 'common' role that deploys /etc/hosts. In 'cluster
>> node' role
>> > luster nodes I also add lines for all nodes in the cluster. Now
>> I am
>> > using a really ugly loop around lineinfile for this that took
>> me some
>> > time before I made it place the content properly. Try to use
>> lineinfile
>> > with a relatively complex data structure and you will remember
>> my words.
>> > Instead, it would be far more easy to write an "extra_hosts"
>> block and
>> > do things in pure jinja.
>>
>> Why not deploy for example dnsmasq? I mean, using /etc/hosts for
>> DNS in a multiple host environment is so 1960...
>>
>
> Because it would be overkill for a 2 or 3 - node cluster. But you
> are missing the point. dnsmasq would still have a common
> configuration on most hosts, as well as an extra configuration
> needed for cluster nodes.
>
>
> Fair enough - I don't know what are your needs. I'm using dnsmasq on a
> laptop for 3-4 virtual machines in my development environment and I
> don't feel it's a waste of resources, but a convenience. :) I can
> define a CNAME or A in one place (in my inventory, in fact) and all
> hosts immediately know about it.
>
> As for dnsmasq configuration on hosts other than the server (I hope
> you didn't plan to install it on all your servers), it's just one line
> in /etc/resolv.conf which is managed by operating system anyway, via
> DHCP. So, no extra configuration for me.
>
> 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 [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/CAEnKK1xpOWkaxH-3sMWUhUaNdQLf-aDSJMWHikFL3ZT0XCCzNg%40mail.gmail.com
> <https://groups.google.com/d/msgid/ansible-project/CAEnKK1xpOWkaxH-3sMWUhUaNdQLf-aDSJMWHikFL3ZT0XCCzNg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> 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/53863C36.8050200%40yahoo.gr.
For more options, visit https://groups.google.com/d/optout.
