I’d love to hear how other people are pushing Ansible out to their servers using ansible. I think once there’s a solid method for this, it would be great to add to the documentation under; http://ansible.cc/docs/gettingstarted.html#getting-ansible
My scripts are below && they’re for Ubuntu. It’d be fun to see what you all use for this – please submit yours if you have a chance. I also really like things like curl [http://install.meteor.com ](http://t.co/W6YGo4we)| sh if they can be checksummed as a one-liner.
I wouldn’t call it distributed datacenter setups – more like plain-jane basic provisioning. I’ve written a collection of ansible playbooks and shell scripts to “provision” a server as a particular role (e.g. app-server, db-server, or in this case a sysop-server where ansible is used by CI [jenkins] to deploy software to app-servers). Typically this process is done via VM images (e.g. AMIs / qcow / whatever virtualbox do)… although I tend to use dedicated servers that are provisioned with a base OS install by the hosting provider. Make any sense?
Anyway – I thought it would be cool to have a “Via Ansible” section to go along with “Via PIP” and “Via RPM” in the Getting Started section of the docs; however I now realize it’s not a common use-case.
I’ve written a collection of ansible playbooks and shell scripts to “provision” a server as a particular role (e.g. app-server, db-server, or in this case a build-server where ansible is used by CI [jenkins] to deploy software to app-servers). Typically this process is done via VM images (e.g. AMIs / qcow / whatever virtualbox do)… although I tend to use dedicated servers that are provisioned with a base OS install by the hosting provider – and use ansible to make their environment consistent (e.g. jenkins ++ ansible for deployment!). Make any sense?
At one site, I use an ansible shell task with an rsync (pushing to all laptops at install time, to enable them to run ansible-pull).
At another site, I only use ansible on one host per environment, and use it as a jumphost to install software on a bunch of servers in that environment. Those "jumphosts" all need the playbooks, tasks and even some tar ball of software. It is a very restricted environment (apps team can't get access to root, there is no central NFS server (actually no NFS server at all) etc... so I just stuck everything in subversion, including ansible. It does have the advantage that if a playbook use a new module, it will have the right version of ansible in the same svn checkout.
