Disclaimer: this post is all about introducing a few concepts, to see how to use them go to part 1.5
This will be the first post in a series about devops coming from us here at Will & Skill mainly working with django projects. The term devops is not something that is 100% defined in to one thing. But if you google around on different definitions it basically boils down to:
...establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.
Definition from wikipedia
So simply put; how you can make your life a little bit easier when developing and shipping software products?
Step 1, development
In this part I will focus on introducing some of the tools used for development, which later on in the series also will be used to deploy our app to production. The premise for this is the most simple webapp where we have a single server running the application, as well as the database and a redis instance.
One of the key parts to the devops definition is that all of our work should be done "reliably". A great way to start this journey is to make sure that ALL of our environments are provisioned (set up) in the same way. And a great tool to help us with that is Ansible!
Introducing tool no.1: Ansible
What is Ansible?
Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.
-- Ansible website
I can't find the quote right now but somewhere I believe I read that ansible is a "multi node orchestration tool" which to me sums it up pretty good.
With ansible you write what they call playbooks, playbooks is basically
.yml files where you define tasks such as:
- Install python and virtualenv
- Install postgres and create a database
etc... things that we will need in order to get started with our development.
The beautiful thing about Ansible is in the "multi platform orchestration" part. Even for the most basic project you probably have at least 3 environments, a development, a staging and a production server. With Ansible you define the playbooks once and then define hosts (servers where Ansible will ssh in and do its magic) in a special inventory file.
The tasks can of course be setup slightly differently depending on which hosts it will be run on. For instance your production environment might use SSL while your development probably don't.
Ok so we get it Ansible is great so how do we use it? Well first off we have to create a machine where we will do our development. On to the next tool:
Introducing tool no.2: Vagrant
What is Vagrant and why do I need it?
Again to create our reliable workflow we will need the same setup throughout our apps lifecycle, in the end (production) we probably wont be able to use anything else than an Ubuntu machine, so why not start right now in development?
Well I'm already on a Ubuntu machine you might say, I don't need this then? Yes you do, because poluting your local environment with different apps and dependencies is a sure way to build a shit mountain. That WILL eventually come down upon you, either the day you get a project that absolutely needs a legacy version of database x. Or lets say you just want to upgrade your local OS which leads to half of your apps dependencies breaking.
You don't want that, I don't want that. What we want is virtualization, isolation === good. Ok, great.
You can go ahead and look at the official docs to get a deeper dive in to Vagrant. But to sum it up I found a pretty nice answer by Adam Lukens on the stackexchange site superuser:
Vagrant is used to set up one or more virtual machines by: 1. Importing pre-made images (called "boxes") 2. Setting VM-specific settings (IP address, hostnames, port forwarding, memory, etc.) 3. Running provisioning software like Puppet or Chef
-- Answer by Adam Lukens on "Why should i use vagrant instead of just virtualbox"
So basically its a way to create a virtual machine which then will be provsioned by another software which in our case will of course be.... Ansible!
So If you followed along the full blogpost you're probably excited to see some code, come along to part 1.5 where the fun will begin!