Propro: Provision like a pro
Propro will always be biased to my needs for my apps and servers. It's not intended to be a magical unicorn for every use-case, I deploy Ruby apps to Ubuntu 12.04 and 14.04 x64 on Linode. I typically use Postgres, Redis, Nginx, and Ruby.
Feel free to use it as an Ansible grab-bag or starting-point if your needs differ. Also check out Ansible Galaxy for magic unicorns, there are some mighty robust/battle-hardened roles on there!
The beauty of Ansible is just how easy it is to re-use roles and tweak playbooks, don't think you're confined to what I've laid-out here. Feel free to create your own playbooks for your specific needs. Propro is really just supposed to be a starting point and collection of roles to build systems the way that I like them to be built.
Provisioning A Vagrant VM
- Copy the Vagrantfile.example and change the private IP and VM name to your liking
- Copy this repo into the
.ansible(or whatever works for you) directory of your Vagrant project, or add it as a submodule.
vagrant upthe system should build itself
- Have a beer or wine or spirit or soda or juice or water to celebrate
Provisioning A Real World VPS
Add your own
inventorydirectory, check out the
inventory_examplefor how this might look.
Add and build a VPS in your provider of choice, remember to choose Ubuntu 12.04, or 14.04 as Propro was only built against those two distributions.
prepare-vps.ymlplaybook, this adds the public keys for the GitHub users you specified in
admin_authorized_githubbersvariable and disables root login and password login.
ansible-playbook -k -u root -i inventory/hosts prepare-vps.yml
Now you can run the
site.ymlplaybook and provision your servers as the admin user that was created above since password-based auth and root-access are now disabled.
ansible-playbook -K -s -u admin -i inventory/hosts site.yml
About The Included Groups
Here is some info about the groups that are included in the example inventory file and playbook tasks, and what they aim to achieve.
Full stack servers host everything, you can think of this as your "classic" web server setup where everything is on one machine.
App servers host your Ruby application and Nginx, typically you will have a load balancer in front of your app servers. In my case I use Linode's Nodebalancer product, but you could just as easily add a play to provision an instance with HAProxy and use that as your load balancer. If you're on a VPS and they offer a load balancing product it's usually a good idea to utilize it since they are often optimized for that use-case.
Exactly the same as an app server except replace Puma with Sidekiq. There is nothing stopping you from running Sidekiq on your app servers, but if you have the cash to run your workers on separate machines it's really nice to do so.
Hosts PostgreSQL and/or Redis, data is persisted on these servers. They don't know anything about your app other than that they will accept inbound connections from your app/worker servers.
This is an aggregate group that consists of all the servers that will need to talk to the database servers. The private IPs are pulled from these machines and use to configure the firewall rules on the database machines.
These groups show you how to apply variables to ranges of machines, in this case we use them to configure public/private netmasks specific to the two providers.