FWIW; ansible-pcd ( prepare, configure, deploy ) framework

[Brice Burgess]

I'd like to share the way I organize ansible to manage infrastructure with the community.

I tend to think of infrastructure as partitioned into "systems", "services", and "applications"... and automation as "preparation", "configuration", and "deployment". This approach reduces execution times of playbooks, as it intrinsically strives to avoid the frequent execution of non-changing actions.

A long time ago before there were roles. We had no built in magical conveniences or common structure to build upon. You had to develop your own organization and flow... and in doing so I created a hodge-podge of bash scripts and playbooks around this "pcd" concept. They worked great, but really were not ansible 1.2+ compatible. I've finally gotten around to refactoring & ignoring nuisances, and now have a new "framework" (or organizational base) I'd like to share. Roles and inventory sure do make it easier!

https://github.com/iceburg-net/ansible-pcd

A couple of goals;

+ Easy interdependence - e.g. an application can depend on `services/zookeeper` which can depend on `services/smtp`. The ec2-web-1 host can depend on `systems/web-server` which depends on `services/apache` and the `applications/apache-ng-security` application you're writing.

+ Provide common tasks/vars/handlers/files/templates for convenience and to reduce redundancy

+ Remain distribution agnostic (will support RedHat + Debian distributions, maybe more)

+ Utilize the "pcd" concept. Will utilize tagging once a monolithic site.yml is built.

+ Compartmentalize sensitive information (e.g. rsa keys, ssl certs) to help keep it out of version control (ignore /private)

There's really not much there now... just an organizational base that outlines my general concept. I'll be adding services and applications as time avails.

Hope someone finds it useful && would love to see other techniques.

~ Brice

[Michael DeHaan]

I'm failing to understand how this is different from a standard playbook from looking at the above.

This is probably because you didn't check-in the "deploy" step, but I don't know.

"Easy interdependence - e.g. an application can depend on `services/zookeeper` which can depend on `services/smtp`."

This sounds like role dependencies.

"+ Compartmentalize sensitive information (e.g. rsa keys, ssl certs) to help keep it out of version control (ignore /private)"

This sounds like you should look into vault.

--
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-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/459c6617-8f79-4b7e-8c0b-1c71d13208ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jimmy Tang]

Looks interesting, please upload the deploy bits... I can somewhat see this breaking up of playbooks to be useful for large plays with lots of steps.

--
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-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/459c6617-8f79-4b7e-8c0b-1c71d13208ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

http://www.sgenomics.org/~jtang/

[Brice Burgess]

Jimmy,

Yes; I'd say ansible-pcd augments the ansible best practices recommendation ( http://docs.ansible.com/playbooks_best_practices.html ) with standards and flexible convenience components that make it easier for "me" to deal with multiple large environments.

I'm currently porting an application for deployment of [apache hosted] websites from git repositories; but am still re-working the general deploy bits.

Open to ideas of course! :)

Thanks for your interest.

~ Brice