You hear me talk about thousands of servers and never about how to get to the point where you make 10,000 servers go up. The fancy word is “provisioning”. I don’t even know what’s it supposed to mean, but for me it means “make a recipe which will make machine configured for a purpose”. As we’re talking about cloud computing and Docker, what we need is a machine that is Consul and Registrator ready. Getting to that point on multiple servers is not such a short task, but it’s repetitive. And, along comes Ansible. Over the years people realized that they want a language for specifying server configuration that is declarative, so Ansible uses YAML for that. We also need a language to describe the configuration of different services, andJinja2 offers that. On top of that, it’s Python, so it has extra plus on my scale. As you can’t just apply something on your servers and hope for the best, you need some development environment. I think Vagrant has no competition in that field, yet. Let’s see on the example of this blog how to use it. Clone, and execute vagrant up. It should download CentOS 7 box, create new virtual machine in VirtualBox and provision it with Ansible. What it does is not that important right now. Let’s start with example Ansible task:

- name: install docker
  sudo: yes
      pkg: docker
      state: latest

Yeah, it’s that simple and readable. That’s fine, but let’s dive into the details. First, there’s a site.yml file. You can see the title of Ansible playbook, hosts on which it will be run on and roles it will apply. As I have two roles but mention only one in site.yml, it means that role common is a dependency of meka. That dependency is noted in meta. There’s only one thing missing: list of servers that this playbook applies to. Vagrant will generate that list on the fly depending on the configuration inside Vagrantfile, like number of machines. Nice thing about Vagrant is that it will share directory of the repo as /vagrant inside virtual machine. Basically this means that you can code on your laptop/desktop with your favorite editor and see those changes on the same distribution that is used in production, on the same docker that is used in production. Idea is to have almost identical environment in all stages, like development, testing, pre-production, production, … It enables developers to make less bugs that are caused by differences in environments.

Ansible is such an important and easy to use tool, that I have no more words to describe it but “read all from the provision directory”. It’s simple and powerful.

previous next