Немного о Vagrant на примере Puppet

puppet

Puppet – крайне удобная система автоматизация повседневной рутины. К нему достаточно быстро привыкаешь и вместо написания bash скрипта уже скорее напишешь модуль для puppet.

 

Естественно, после написания нового модуля или просто manifest’а его надо бы протестировать перед развертыванием в продакшене и по началу я, возможно как и все, запускал puppet agent -t с опцией –noop на каком-либо agent сервере и изучал вывод.

 

И это даже работало пока задачи были простыми, да еще и достаточно часто при деплое на новый сервер все разваливалось. По-моему первой проблемой, которую я неожиданно для себя открыл – на выданном клиенту VPS сервере с образом Debian’а и устаревшей базой deb пакетов во время apt-get install выдается куча 404 ошибок, что рушит весь процесс настройки, который у меня к этому был не готов. Вылезают и другие мелкие проблемы, поэтому тогда я решил, что пора начать делать все по-взрослому и пошел ставить Vagrant.

К Vagrant надо привыкать, как привыкаешь к git’у после длительной разработки в каком-нибудь PhpEd с простой постоянной загрузкой исходников по FTP, или к vim после того же nano – надо сначала немного помучаться.

 

В итоге я пришел примерно к такому workflow:

  1. Редактирую puppet манифесты, модули и прочее у себя локально
  2. Создаю виртуальную машину и после старта автоматически применяю к ней основной puppet манифест
  3. Смотрю все ли в порядке. Если все совсем плохо – убиваю машину, исправляю код и создаю виртуальную машину заново. Если требуются мелкие правки – произвожу их и заново применяю манифест
  4. Если весь добавленный функционал работал делают git commit у себя на локальной машине и далее при надобности git push и начинаю использовать получившийся код  в продакшене

 

Основное неудобство связано с созданием/удалением витруальных машин, копированием каким-то образом puppet файлов в виртуальную машину, запуск puppet aply. Vagrant все это прекрасно автоматизирует. Ставится достаточно просто – идем, качаем необходимый для себя пакет отсюда https://www.vagrantup.com/downloads.

Далее необходимо установить какую-либо систему виртуализации. Лично я использую VirtualBox,  чего и всем советую.  Напишу кратко, без лишних подробностей, чтобы примерно понять как это работает.

 

Создаем директорию для наших экспериментов:

mkdir ~/PuppetExp; cd ~/PuppetExp

Перед началом работы с Vagrant необходимо иницилизировать окружение в рабочей папке. Делаем это указав в качестве дистрибутива Wheezy Debian от PuppetLabs с предустановленным puppet агентом:

puppetlabs/debian-7.4-32-puppet

 

Помимо прочего данная команда создаст Vagrantfile в котором содержится описание виртуальных машин, которые необходимо создать, настройки сети, что делать с серверами после запуска (доп. настройки). Мы создадим пока всего одну VPS и подключим систему настройки (provision) puppet, которая после установки VPS автоматически просто вызывает puppet apply. Поэтому не требуется установка master’а, что нам и надо:

 

Соотвественно site.pp будет находится в ~/PuppetExp/puppet/manifests/site.pp.
Создаем необходимые директории (мы находимся в )

 

В site.pp добавляем как обычно нужный нам код. В качестве имени выше я указал development.puppetlabs.vm, его и можно использовать в node, а можно, в принципе, использовать и default, но лучше использовать сразу конкретные названия, чтобы можно было тестировать реальные манифесты, так как в реальности все не будет сложено в default.

 

Тригерами запуска настройки puppet являются вызовы:

  • vagrant up при первом запуске – когда создается (возможно еще и скачивается образ) виртуальная машина. Если виртуалка уже создана настройка по умолчанию происходить не будет. Только если специально передать флаг –provision
  • vagrant provision при работающей виртуалке
  • vagrant reload –provision. Вызывает сначала halt затем up с параметром –provision.

 

Теперь разработка ведется примерно следующим образом:

  • Поправили puppet манифест, вызывали vagrant up
  • Если у нас фатальная ошибка и что-то пошло не так делаем vagrant destroy –force && vagrant up, т.е. убиваем и создаем VPS заново
  • Если ошибка не фатальная – правим манифест и запускаем vagrant provision, что запустит работу всех настройщиков в Vagrantfile в котором у нас пока только один puppet, который, повторюсь, делает puppet apply
  • Если хочется посмотреть что конкретно сделали наши сценарии – vagrant ssh посредством автоматически созданного ssh ключа залогинит нас в виртуальную машину в которой в папке /vagrant будет находится все содержимое нашей директории ~/PuppetExp – соотвественно puppet apply можно запускать и прямо изнутри сервера
  • Если от работы надо отвлечься и хочется доделать потом – vagrant suspend отправит сервер в “спящий режим”, vagrant resume включит его назад
  • Если работа завершена – выключаем сервера vagrant halt (или даже destroy), делаем git commit и git push

 

По началу использования Vagrant может показаться каким-то излишенством и вообще предмет, тормозящий  разработку, так как изначально возникает много вопросов по тому, как добавить несколько VPS в Vangratfile, как огранизовать между ними приватную сеть. Мешает и то, что Vagrantfile использует ruby синтаксис, поэтому возникают и вопросы связанные с тем, как в ruby делается for от 1 до n. Но привыкание проходит достаточно быстро. Мне хватило двух дней, чтобы попробовать запустить различные часто встречающиеся у меня серверные окружения, сделать пару папок заготовок для различных сетапов с Vagrantfile в них. Теперь если возникает вопрос, к примеру “А что будет если к OpenVPN серверу подключиться 31-ый клиент при max-clients равном 30?” я просто делаю:

  • vagrant up
  • vagrant ssh
  • … эсперементирую …
  • vagrant destroy

Для меня даже в таком простом use-case это сильно удобнее, чем работа с GUI VirtualBox’a, ручным клонированием образов, которые мне еще надо сделать, возней с паролями, ssh-ключами и прочим.

Приятно и то, что много кто предлагает заготовки Vagrantfile для тестирования продукта. Например если хочется попробовать CoreOS  – пожалуйста, качаете их Vagrantfile в котором меняя буквально две настройки можно развернуть или сервер “все в одном” или целый кластер из +3 серверов.

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *