Express 42
Компания
32,26
рейтинг
20 декабря 2013 в 12:54

Разное → Про Vagrant, его плагины, и другие истории из жизни бродяг

По моему мнению, большинству IT специалистов стоит использовать Vagrant. Кто не знает, что это такое – рекомендую начать с официального сайта. На Хабре так же было несколько обзоров вагранта, например Development Environment при помощи Vagrant и Chef и Создание новой виртуальной машины за одну минуту или «vagrant up!». В этой статье я более детально расскажу о «экосистеме» вагранта.

Если попробовать описать вагрант в несколько слов, то это инструмент для повторяемого создания окружения с помощью вашей любимой системы управления конфигурацией и вашей любимой системы виртуализации. И если систем виртаулизации и систем управления конфигурации существует достаточно много, то вагрант — один единственный продукт в своем роде, аналогов ему нет.

Но рассмотрим ситуацию более подробно. На данный момент вагрант поддерживает следующие системы виртуализации прямо из коробки:

  • VirtualBox — именно с его поддержки начинался вагрант.
  • VMware — для него нужен платный плагин.
  • AWS — можно делать ваши виртуальные машины сразу в облаке Амазона.

Кроме того, сторонними разработчиками написаны следующие плагины (здесь, конечно, перечислены не все):

  • Vagrant-lxc — плагин для системы контейнерной виртуализации. LXC, немного сыроват, но активно развивается.
  • Vagrant-libvirt — обещает поддерживать все системы виртуализации, которые поддерживает libvirt, а их порядка десятка.
  • Vagrant-kvm — плагин для системы виртуализации KVM.
  • Vagrant-parallels — плагин для системы виртуализации Parallels. Оказывается, под Parallels можно запускать не только Windows на Mac, но и разрабатывать инфраструктуру, более того, сотрудники из нашей компании «Экспресс 42» успешно это делают. Плагин разрабатывает сама компания Parallels, и он активно развивается.

На всякий случай наш бокс для Parallels с Ubuntu 12.04 лежит здесь.

Используя различные системы виртуализации, вагрант может стать незаменимым инструментом, который проверяет разные аспекты вашей инфраструктуры с помощью тестов в CI окружении.

После того, как вы подключили вашу систему виртуализации, необходимо определиться с системой управления конфигурацией. На данный момент поддерживаются следующие системы настройки (provisioning):

  • Shell — старые добрые shell-скрипты. В XXI веке уже не интересно.
  • Ansible — молодая, набирающая обороты, система управления конфигурацией.
  • Chef — про него, пожалуй, слышали все. Поддерживается standalone (Chef Solo) и серверная (Chef Client) версии.
  • Docker — модная в последнее время система, поддерживающая концепцию Immutable Server (о ней мы рассказывали в крайнем выпуске подкаста Devops Deflope).
  • Puppet — одна из наиболее распространенных систем управления конфигурацией. Поддерживается standalone и серверная версия.
  • Salt — система управления конфигурацией Salt Stack.

Дальше все крайне просто — вам нужен «эталонный» образ операционной системы. Можно сделать самому, это не так сложно, а можно взять готовый, например, на сайте VagrantBox.es. Наш бокс для VirtualBox с Ubuntu 12.04 лежит здесь.

Если вы все же не любите готовых решений, то есть проекты, позволяющие автоматизировать создание базовых образов. Например, VeeWee (вводная статья о нем на Хабре) и Packer. Последний сделан Митчелом Хашимото, автором вагранта. К сожалению, русскоязычных обзоров его нету, но мы обязательно напишем о нем в одной из ближайших статей.

Важно отметить, что эталонный образ ОС имеет смысл использовать одинаковый для всех ваших окружений — от девелоперского до боевого.

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

Vagrant.configure("2") do |config| 
  config.vm.define :infra do |main| 
    main.vm.box = "ubuntu12.04-chef11" 
    main.vm.hostname = "infra" 
    config.vm.network :forwarde_port, guest: 80, host: 8002 
    config.vm.network :private_network, ip: "192.168.100.13" 
    main.vm.provider :virtualbox do |vb| 
      vb.customize ["modifyvm", :id, "--memory", "2048"] 
    end 
    config.vm.provision :chef_solo do |chef| 
      chef.log_level = :info 
      chef.roles_path = "roles" 
      chef.data_bags_path = "data_bags" 
      chef.add_role "base" 
      chef.add_role "zabbix-db" 
      chef.add_role "zabbix-server" 
      chef.add_role "graylog2" 
    end 
  end 
 
config.vm.define :vm1 do |main| 
    main.vm.box = "ubuntu12.04-chef11" 
    main.vm.hostname = "vm1" 
    config.vm.network :forwarded_port, guest: 80, host: 8001 
    config.vm.network :private_network, ip: "192.168.100.14" 
    main.vm.provider :virtualbox do |vb| 
      vb.customize ["modifyvm", :id, "--memory", "2048"] 
    end 
    config.vm.provision :chef_solo do |chef| 
      chef.log_level = :info 
      chef.roles_path = "roles" 
      chef.data_bags_path = "data_bags" 
      chef.add_role "base" 
      chef.add_role "zabbix-client" 
      chef.add_role "projectname" 
    end 
  end 
end 


С подобным файлом конфигурации можно подымать виртуальный машины по отдельности, например, vagrant up infra или vagrant up vm1.

Здесь статью можно было бы закончить, но, помимо всего прочего, к вагранту существует множество плагинов, которые расширяют и дополняют его функциональность. Список наиболее известных плагинов есть в вики вагранта. Вот наиболее интересные из них, на мой взгляд.

  • Vagrant-cachier — кэширует запросы к репозитариям различных менеджеров пакетов (deb, rpm), что позволяет поднимать машинки гораздо быстрее.
  • Vagrant-librarian-chef — интеграция вагранта и librarian-chef. Более подробно прочитать о том, зачем нужен librarian-chef можно в нашей статье.
  • Vagrant-berkshelf — интеграция вагранта и Berkshelf (аналог librarian-chef).
  • Sahara — этот плагин позволяет делать «срезы» вашей виртуальной машины, чтобы можно было легко откатиться назад.

Вагрант помогает повторяемым образом подготавливать окружение ваших проектов. Вагрант позволяет начинать интеграцию с самой ранней стадии — со стадии разработки. Я глубоко убежден, что только так и можно «готовить» инфраструктуру. Но сейчас мало кто так готовит. А «Экспресс 42» готовит именно так.
Автор: @evtuhovich
Express 42
рейтинг 32,26
Компания прекратила активность на сайте

Комментарии (31)

  • +1
    Разве heat, juju и остальные не делают то же самое?
    • +2
      Я посмотрел на juju и heat — это скорее такая смесь шефа и вагранта. И они, скорее, для продакшен использования, в то время как вагрант больше предназначен для разработки/тестирования (и этому сильно помогает поддержка virtualbox, который запускается на всех системах).
    • 0
      А на heat можно ссылочку?

      juju сильно на ubuntu сейчас завязана.
  • +1
    Спасибо за статью, как раз начал изучение вопроса. Если по статье, то, наверное, стоит добавить ссылку на rove.io
  • 0
    Иван, всё это очень интересно, но ощущение, что статьь незакончена. Много вопросов остаётся. Например, возможно ли в этом окружении использовать не chef, а sprinkle или puppet например?
    • 0
      Кстати да, хотелось бы услышать, в чем основные различия chef, puppet и sprinkle (и может быть, чего-то еще, чего я не знаю). Где и когда применять каждый из этих инструментов? Если есть Vagrant, то зачем нам Docker?

      Был бы рад прочесть развернутые ответы в комментах, а лучше, в новых постах.
      • 0
        У нас есть только опыт использования chef, зато многолетний. Другие системы «в среднем» ничем не отличаются, так что это больше дело вкуса.

        Про Docker мы расскажем подробнее попозже.
      • 0
        Если есть Vagrant, то зачем нам Docker?

        Docker представляет менее абстрактный и более производительный слой.
        Вот здесь описывают неясный момент docker-the-missing-tutorial
    • +1
      Там же в статье есть список всех систем управления конфигурацией, там и chef, puppet, salt, ansible и другие. docs.vagrantup.com/v2/provisioning/index.html
  • +4
    Расскажите на DevOPS meetup-е о полезных практиках использования данных плагинов? Особенно интересны примеры использования Sahara.

    Добавлю, пожалуй пару слов.
    Я использую chef-zero (https://github.com/andrewgross/vagrant-chef-zero) вместо chef-solo, что дает мне почти полноценный chef-server, хранящий все в памяти, со всеми вытекающими:
    — схожесть с production env, где мы также используем chef-server;
    — большая гибкость в тестировании;
    — высокая скорость переустановки chef-zero в случае необходимости

    Также я использовал с вагрантом плагин для berkshelf (https://github.com/berkshelf/vagrant-berkshelf), но ввиду медленной скорости загрузки кукбуков и некоторых ограничений при тестировании, перешел на загрузку кукбуков с локальной файловой системы в chef-zero в обход berkshelf-а.
    • 0
      Да, надо было добавить про chef-zero, вылетел из головы. Спасибо, что напомнили.
  • +2
    Напомню еще про свою статью: Быстрое развертывание среды разработки, вполне подходит для начала.
    • +1
      О, привет, Акжан :-)
  • +1
    Спасибо за статью, давно хотел попробовать Vagrant с Ansible и lxc/kvm. После знакомства с Docker будет интересно посмотреть на плагин Sahara. Хочу заметить, что статья действительно выглядит слегка незаконченной. Могли бы побольше описать свои сложные юз-кейсы, раз уж заявлены «другие истории из жизни бродяг».
    • 0
      Я могу ответить на вопросы здесь, если они возникнут.
  • 0
    что понимается под средой разработки? Могу ли я с использованием vagrant получить окружение с уже установленным набором девелоперских пакетов для сборки проекта? Могу ли я прозрачно использовать IDE которую я захочу с развернутым окружением, и не будет ли это тормозить из за remote desktop? и из за того что это виртуалка?
    • 0
      Да, все это можно сделать с помощью вагранта. Как быстро это будет работать — зависит от вашей машины и вашего проекта. Есть люди, которые уже разрабатывают в среде, созданной вагрантом.
      • 0
        core i7, 8gb RAM время сборки буста увелилилось в раз X, вместо 10 минут наверно часа полтора собиралось. Я так и не понял в чем был косяк.

        А еще установка чего угодно из реп занимала минут 15 (и дело было не только в торможении сети)

        host: ubuntu 13.04
        vagrant: redhat (версию не помню).
  • 0
    На самом деле очень интересная тема. Я сейчас как раз пытаюсь надоумить кастомера внедрить что-нибудь подобное дабы сделать их legacy систему более тестируемой. Не подскажете, поддерживает ли он windows оси и требуются какие-либо дополнительные затраты на покупку лицензий?
    • 0
      Лицензия требуется только если вы используете VmWare и его плагин к вагранту, больше ничего не лицензируется. Сам вагрант на винде прекрасно работает, есть даже msi инсталяшка. Если хотите запускать windows в качестве гостевой системы, то этот проект github.com/WinRb/vagrant-windows вам пригодится.
      • 0
        Отлично! Жаль, что по гостевым системам нет поддержки XP и 2003.
        • 0
          Я, кстати, не уверен, что нет, но мы виндовсом не занимаемся, поэтому сложно сказать наверняка.
  • +1
    Berkshelf это не аналог либрариана. Также не могу не посоветовать обратить внимание на плагины:

    gem «vagrant-omnibus», github: «schisamo/vagrant-omnibus» — установка шефа при провижененге на вирт. машину
    gem «vagrant-butcher», github: «cassianoleal/vagrant-butcher» — удаление клиента и ноды с сервера шефа при destroy в вагранте
    gem «vagrant-ohai», github: «avishai-ish-shalom/vagrant-ohai» — назначение ip интерфейса eth1 в качестве главного для node[:ipaddress]

    Кстати, смысл пакера немного не в том, про что вы написали, а именно — подготовка большого количества образов с разными системами и более-мение одинаковыми параметрами.
    И еще хочу заметить, что при описании вагранта непростительно не упоминать про дефолтный файл, который лежит в ~/.vagrant.d/Vagrantfile
  • 0
    > Berkshelf это не аналог либрариана

    Не совсем понимаю ваше утверждение. Возьмите Cheffile и Berksfile и «найдите десять отличий». С точностью до хранения кукбуков и названия команда — они делают одно и то же.

    Да, vagrant-buthcer стоило упомянуть, согласен.

    Насчет пакера — это также спорный вопрос, я бы не был так категоричен.

    ~/.vagrant.d/Vagrantfile этим файлом в нашей команде никто не пользовался. Может быть потому, что то, чего нет в системе контроля версий — для команды не существует.
    • +1
      Ну собственно и смысл что этого файла для комманды не существует.
      Про berks — смысл разработки в berks-style — команда berks apply, которая лочит энвайрменты.
      • +1
        Смысл этих двух инструментов в управлении зависимости кукбуков и повторяемости у разных людей, так что по сути это аналоги. Но отличия безусловно есть. Мы не используем berks потому, что у нас несколько другой подход, мы для разных окружений используем разные chef серверы.
      • 0
        osminog ниже верно ответил, для нас этой разницы практически не существует, мы лочим энвайрменты с помощью разных шеф-серверов для разных окружений.
  • +1
    Иван, расскажи про скорость работы с вагрантом при вашем подходе и плагинах. Какая стадия сколько по времени занимает (vagrant up, provision, etc.).
    Можно на примере создания/редактирования любого кукбука.
    • 0
      С чистой машинки начинал (после vagrant destroy) на текущем проекте у одного из наших клиентов

      $ time vagrant up --no-provision
      Bringing machine 'virool' up with 'virtualbox' provider...
      vagrant up --no-provision  6,89s user 4,09s system 26% cpu 41,142 total
      


      А потом провижн

      $ time vagrant provision
      [skip]
      vagrant provision  4,24s user 1,81s system 2% cpu 4:06,95 total
      


      Понятно, что в следующие разы быстрее :-)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное