Виртуализация: прошлое и настоящее

Давным давно, более десяти лет назад я впервые познакомился с виртуализацией.
В качестве гипервизора тогда безоговорочно лидировал VMware Workstation (скорее всего версии 4).
Возможность запускать одновременно несколько различных ОС на одной системе, и открывающиеся при этом широкие возможности произвели очень сильное впечатление.

И с тех пор я начал создавать различные виртуальные лаборатории. Для изучения новых технологий, тестирования рискованных изменений и для поиска новых решений.
С удешевлением оперативной памяти появлялась возможность запускать всё больше и больше виртуальных машин на одном хосте, создавая интересные решения, которые повторяли реально используемые в производстве. Одновременно с этим и бизнес постепенно отказывался от физических серверов в стойках и тоже переходил на виртуализацию (арендованную либо свою собственную).
В какой-то момент количество используемых виртуальных машин у меня перевалило за четыре десятка, а к VMware добавился еще и эмулятор сетевого оборудования GNS3, который позволил добавить еще больше реалистичности и сложности в собираемые стенды.



И примерно в этот момент возникло несколько отрицательных моментов.
Во-первых подготовка с нуля любой лаборатории состоит из множества рутинных действий. Необходимо используя GUI, создать машины, выделить им ресурсы (CPU, RAM и сеть), развернуть из iso образов системы, накатить обновления, установить какой-либо софт. И если таких машин 5-6 штук или более, то времени уйдет на это немало.
Второй негативный момент - это когда лаборатория уже отработала свою задачу, новая технология или архитектура была изучена и оттестирована и в ближайшее время возвращаться к этому не потребуется. В таком случае наступает момент уничтожения лаборатории, ведь хранить 200-300 ГБ заведомо ненужных данных бессмысленно (особенно если это SSD). И тогда возникает ощущение некого сожаления, ведь потрачено много часов, реализованы разнообразные решения, и всё нужно отправить в /dev/null. А если еще когда-нибудь что-то подобное понадобиться снова? Опять придется всё собирать с нуля.

Оказалось, что избавление от этих проблем существует, а точнее есть даже два отдельных решения разработанных прицельно под каждую проблему.

Для автоматизации развертывания виртуальных машин с заданными параметрами и выделенными ресурсами можно использовать Vagrant. По сути это обертка (wrapper) над различными гипервизорами (поддерживается VirtualBox, VMware и Hyper-V), но если бы Vagrant позволял только управлять набором виртуальных машин из консоли, то пользы от него было бы немного. Основная его фича - это автоматизированное развертывание машин, которое присходит в соответствии с указанными конфиге параметрам. Конфигурационный файл всего один, и формат описания предельно читаемый. Пример для деплоя трех различных серверов можно видеть ниже.

# -*- mode: ruby -*-
# vi: set ft=ruby :

BOX1_IP = "192.168.56.101"
BOX2_IP = "192.168.56.102"
BOX3_IP = "192.168.56.103"
DOMAIN = "nip.io"
PRIVATE_KEY = "~/.ssh/id_rsa"
PUBLIC_KEY = '~/.ssh/id_rsa.pub'

Vagrant.configure("2") do |config|
  config.vm.define "srv1" do |srv1|
    srv1.vm.box = "centos/7"
    srv1.vm.hostname = BOX1_IP + '.' + DOMAIN
    srv1.vm.synced_folder ".", "/vagrant", id: "vagrant-root", disabled: true
    srv1.vm.network :private_network, ip: BOX1_IP
    srv1.ssh.insert_key = false
    srv1.ssh.private_key_path = [PRIVATE_KEY, "~/.vagrant.d/insecure_private_key"]
    srv1.vm.provision "file", source: PUBLIC_KEY, destination: "~/.ssh/authorized_keys"
    srv1.vm.provider :virtualbox do |vb|
      vb.customize ["modifyvm", :id, "--memory", 1024]
    end
  end

  config.vm.define "srv2" do |srv2|
    srv2.vm.box = "hashicorp/precise64"
    srv2.vm.hostname = BOX2_IP + '.' + DOMAIN
    srv2.vm.box_url = "ubuntu/precise64"
    srv2.vm.network :private_network, ip: BOX2_IP
    srv2.vm.network "forwarded_port", guest: 80, host: 8080
    srv2.vm.network "forwarded_port", guest: 443, host: 8443
    srv2.vm.provider :virtualbox do |vb|
      vb.customize ["modifyvm", :id, "--memory", 2048]
    end
  end

  config.vm.define "srv3" do |srv3|
    srv3.vm.box = "centos/7"
    srv3.vm.hostname = BOX3_IP + '.' + DOMAIN
    srv3.vm.network :private_network, ip: BOX3_IP
    srv3.vm.provider :virtualbox do |vb|
      vb.customize ["modifyvm", :id, "--memory", 1024]
    end
  end
end 

 Но и это было бы всё еще недостаточно, ведь например VMware позволяет создавать шаблоны, которые немного упрощают рутинные действия. Вторая особенность Vagrant - это публичный репозиторий уже собранных машин (boxes в терминологии Vagrant). В этом репозитории (https://app.vagrantup.com/boxes/search) можно найти практически все часто используемые в продакшине ОС, зачастую подготовленные самими же разработчиками дистрибутива. В итоге получается, что просто взяв конфиг и выполнив команду vagrant up через несколько минут можно получить готовое окружение. Для переноса уже не требуется копировать сотни гигабайт, и если сегодня лаборатория не нужна, а будет нужна через месяц или год, то без колебаний можно выполнять vagrant destroy.

Первая проблема решена, и сама инфраструктура может быть описана в виде кода. Но как быть с изменениями внутри самих машин? Все установленные пакеты, прописанные конфигурации и настройки будут утеряны. В этой ситуации на помощь приходят системы управления конфигурациями (software configuration management, SCM).
Их немало - Puppet, Chef, Salt и Ansible. Некоторые из них существуют с середины нулевых, некоторые появились совсем недавно. Большинство из них представляет из себя клиент-серверную архитектуру и требует обязательного наличия установленного агента на управляемых хостах. Часто так же требуется длительное изучение и вникание в дополнительные уровни абстракций, чтобы писать свои модули и роли.
Но в последнее время всё большую популярность набирает Ansible, который своим появлением изменил ситуацию среди SCM.

Эта система (https://docs.ansible.com/ansible/latest/user_guide/intro_getting_started.html) не требует для своей работы ничего кроме ssh (на самом деле для полноценной работы требуется установленный python) и являет собой пример простоты и эффективности.

Используя playbooks (рецепты или наборы конфигураций в терминологии ansible), можно задавать любые изменения и распостранять их на неограниченное количество хостов. Установить необходимые пакеты, запустить сервисы, заменить дефолтные конфиги своими, создать пользователей в системе и многое другое. Есть при таком подходе и минусы, прописывать каждое действие достаточно утомительно и занимает много времени, но зато результат выходит максимально удовлетворительный.

Таким образом применяя Vagrant и Ansible можно достичь того что виртуальные лаборатории любой сложности и размера будут представлять из себя лишь набор текстовых файлов, в которых описана как инфраструктура, так и все изменения, которые с ней необходимо выполнить. Эффективность при таком подходе непременно возрастет.