Про 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» готовит именно так.
    Express 42 32,42
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 31
    • +1
      Разве heat, juju и остальные не делают то же самое?
    • +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
                Спасибо за статью, давно хотел попробовать 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
                              


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

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

                            Самое читаемое