как работать с vagrant на windows
Vagrant — виртуализация рабочего окружения
Как и всем дотнетчикам, мне приходилось работать со стеком технологий, основанных на Windows. Но иногда я озирался вокруг и изучал то, что мне казалось интересным, пока не наткнулся я на Ruby On Rails. Все было отлично, вот только инструментарий на Windows оставлял желать лучшего.
Как вы, должно быть, знаете, Ruby On Rails предоставляет великолепные инструменты командной строки, облегчающий работу с фреймворком. Так повелось, что для Windows консоль никогда не была сильной стороной. К тому же все эти инструменты, портированные на Windows, были крайне задумчивыми. По ощущениям, на одной и той же машине, команды rails, выполненные в Windows и выполненные в Linux, но запущенной в виртуальной машине, различались в отклике в несколько раз, а порой и на порядок. А ведь при изучении, важна каждая секунда. Нужно и в rails console поиграться с написанным, и сервер запустить, увидеть свой результат, и миграцию провести, а ждать при этом не хочется.
Когда я только приступал к изучению, слышал множество мнений, что Windows плох для rails-разработчика. В основном это касалось проблем кодировок и прочей несовместимости. Все советовали либо Linux, либо Mac. Но так просто соскочить с Windows я не мог. Слишком много тут оставалось, чего не было там, поэтому решено было разобраться с виртуализацией.
Первым делом, конечно же, на ум пришло просто установить десктопную версию Linux (в качестве подопытной была выбрана… ubuntu) и работать с ней. Развернутая на весь экран гостевая ОС позволяла работать как с нативной. Но при этом терялась связь с Windows, не было никакой интеграции. Обмен файлами, что бы не заморачиваться с самбой или shared-folder в VirtualBox, был осуществлен через dropbox (спасибо вовремя подоспевшей версии 1.1 с selective sync). В общем, костыль на костыле.
Вторым этапом эволюции этого подхода было избавление от интерфейса и работа с Linux только через командную строку, а все редактирование кода перенести в Windows. В качестве подопытной был выбран серверный вариант той же убунты. Благо в таком варианте виртуальная машина в спокойном режиме потребляла от 45 мб памяти. На машине было настроено все rails-окружение. Поднят SSH сервер для доступа к командной строке. Сеть была настроена через bridged-adapter, благодаря чему я мог обращаться к ней по отдельному ip адресу, не заморачиваясь с port-forwarding. Для обмена файлами был выбран samba сервер, тогда я еще не задумывался, что VirtualBox может сама шарить папки между гостьей и хостом. Полное непонимание того, как устроена самба, омрачило все мое дальнейшее существование, пока в русской Google Group по Rails мне не указали на уже готовый рецепт.
Имя ему — Vagrant. Для самых нетерпеливых — вот минимум того, что позволит вам начать работать:
Для всех остальных чуть подробнее.
Vagrant
Vagrant позиционирует себя инструментом для виртуализации рабочего окружения. Все, что я написал выше в статье, он сделает за вас сам. Все, что вам нужно для его использования — это Ruby, Gems и VirtualBox (четвертой версии, если вы используете последнюю версию Vagrant).
Принцип его работы таков — вы инициализируете его в какой-либо папке (в дальнейшем я не буду различать папки и директории, так как Vagrant работает в разных ОС), после этого устанавливаете предустановленную версию рабочего окружения. Vagrant устанавливает ее как гостевую ОС в VirtualBox и монтирует в нее текущую папку. Далее подключаетесь к гостевой ОС через SSH клиент и работаете. Для того, что бы перенести свое окружение в другую папку, все, что вам нужно сделать — это скопировать конфигурационные файлы (Vagrantfile и другие файлы, которые вы создаете в процессе настройки)
Первым делом устанавливаете сам Vagrant. Он является простым gem-ом:
Gems тянет так же несколько зависимых джемов, для работы с виртуальной машиной, системами управления установкой ПО и некоторыми другими.
Предустановленные ОС распространяются в так называемых боксах (box). В нашем случае это будет Ubuntu Lucid (10.04) 32-bit, которую автор проекта заботливо настроил и упаковал:
Поддерживается как http протокол, так и напрямую с файловой системы. Данный урл у меня выкачивался с очень медленной скоростью, поэтому я решил его скачать burnbit торентом: burnbit.com/torrent/162482/lucid32_box
Следующим шагом будет инициализация выбранной директории (именно с этой директорией и пойдет вся дальнейшая работа). Для этого создайте директорию, которая впоследствии будет смонтирована и выполните
Эта команда создаст файл Vagrantfile, в котором будут основные настройки вашего окружения. Последний параметр автоматически добавит в этот файл опцию использования уже добавленного выше бокса.
В принципе система уже готова. Запустить ее можно используя
Выбранная директория будет монтирована как «/vagrant». Все изменения будут автоматически синхронизированы. Подключиться к системе можно через SSH через vagrant@localhost и порт 2222. Логин и пароль на вход в систему — «vagrant: vagrant». Так же vagrant автоматически может создать вам файл настроек для Putty, если вы работаете из Windows:
Port forwarding
Все хорошо, но только система открыта для внешнего мира одним SSH портом.
С помощью настроек vagrant можно заставить VirtualBox перенаправлять порты. Делается это через Vagrantfile. Для этого достаточно раскомментировать соответствующую строку:
Что позволит общаться с 80 портом через 8080. Имя должно быть уникально, но особой роли для нас не играет. Таким образом, можно перенаправить любые порты. В случае rails вам, скорее всего, понадобится порт 3000:
В принципе все готово. Хотя отдельного упоминания стоит интегрированная система provisioning.
Provisioning
Данная система позволяет декларативным способом устанавливать ПО в систему. Есть интеграция с Chef и Puppet.
Расскажу на примере Puppet и как установить с его помощью Apache.
В Puppet ПО ставится с помощью, так называемых модулей. Уже готовые модули можно взять на сайте puppetslab.com. Для начала нужно создать в нашей директории папку с модулями, обзовем ее, скажем, modules. Скачиваем модуль с апачем (http://forge.puppetlabs.com/puppetlabs/apache) распаковываем и содержимое кидаем в подпапку apache (важно, что бы внутри этой папки уже находилось содержимое модуля).
Теперь нужно указать самому Vagrant, что бы он использовал Puppet и сконфигурировал его должным образом. Для этого в файле Vagrantfile нужно указать следующее:
где «modules» — это папка, с вашими модулями.
Теперь при следующем vagrant up система сконфигурирует Puppet и он установит apache. После полной загрузки системы, если вы установили перенаправление портов, можете увидеть ответ в браузере.
Заключение
Пусть вас не пугает то, что он использует Ruby, а сам, по сути, является джемом (gem). Он может стать удобным инструментом для любых разработчиков, кому нужно виртуализированное рабочее окружение. Он работает под разными платформами и может использовать разные гостевые ОС, все только в ваших руках.
Более подробную документацию можно найти на сайте vagrantup.com. Так же советую посмотреть скринкаст, показывающий настройку рабочего LAMP окружения.
Пример использования показывает только один сценарий использования. Он лишь решает мою проблему. Удобен он будет так же и командам разработчиков, позволяя стандартизировать рабочую среду, в которую входят библиотеки, сервера, БД и т.д. Группы разработчиков на разных платформах, единожды настроив, могут работать с одним окружением.
Ускоряем процесс разработки с помощью Vagrant
Как часто вам приходится разрабатывать и запускать приложение локально и упорно искать проблемы, потому что на продакшене приложение ведёт себя не совсем так, как вы этого хотели? А как часто вам присылают тикеты для решения проблемы в приложении, хотя на самом деле проблема именно в несовместимости версий разных приложений? А как долго вам приходится ждать виртуалку, когда для запуска новой версии приложения недостаточно ресурсов локальной машины? Для нас эти вопросы были довольно больными, и мы сломали тысячи копий в спорах, стараясь решить их. Практика показывает, что одним из вариантов для решения этих проблем может стать Vagrant.
Vagrant — это что-то вроде обёртки над системой виртуализации или, если угодно — DSL. Наиболее часто используют VirtualBox, но драйвера есть и для VmWare и даже для Amazon EC2. Более подробную информацию, а так же как его установить и начать работу, можно найти на официальном сайте — www.vagrantup.com
Vagrant и тестирование окружения
У нас есть несколько собственных приложений, которые общаются между собой через шину RabbitMQ и используют такие вещи, как MongoDB и MySQL. Тестирование отдельных приложений, запускаемых в синтетической среде, далекой от реального окружения, не показывало нам поведения связки приложений в реальном окружении при обновлении какого-либо одного элемента. А изменения в окружении вообще никак не показывало, потому что QA и staging окружения были далеки от реального. Конечно, это не избавляет нас от необходимости проводить модульное тестирование.
Попробуем решить эту проблему с помощью Vagrant.
Для наглядности покажу такую схему:
В нашем случае осложнением задачи является то, что могут быть использованы Amazon EC2, Openstack или вообще VmWare ESXi, что опять не поможет отловить баги и ситуации, связанные с ними. Единственным выходом в этой ситуации я вижу использование всей этой связки, но с провайдером, отличным от VirtualBox. А из этого есть небольшой минус — заставить Vagrant работать с другими провайдерами не всегда тривиальная задача. Ну и еще, не всегда есть машинка для билдагента, которая потянет на себе N виртуалок с приложениями, которым нужно очень много ресурсов для работы.
А вся прелесть заключается в том, что у нас есть проект в репозитории, у которого есть история изменений, которые проходят review и все изменения, вплоть до установки вима, тестируются до попадания на продакшен. Ну и никто не мешает нам таким же образом проверять и внешние ресурсы, обновлять базы данных, шину и всякие фронтенды на node.js. Все зависит от фантазии и желания.
Дальше в статье будет описано, как использовать Vagrant, чтобы реализовать приведенную схему.
Запуск простого сервиса
Обычный usecase для Vagrant: поднять сервис и окружение и посмотреть, как работает мой код в этом окружении. Особенно если требуется посмотреть какую-то платфомозависимую штуку. Ну и плюс, Vagrant позволяет не разводить зоопарк на рабочей машине, не держать одновременно пачки софта и сервисов разных версий для разных потребностей и проектов.
Одна из самых приятных фич для меня — это поддержка Puppet, как в master, так и в standalone режимах. Конечно, Vagrant умеет и Chef, но мы в нашей компании используем Puppet, поэтому для меня выбор очевиден. Я буду использовать Puppet Standalone, или по-простому puppet apply.
Первым делом переходим в каталог проекта и делаем vagrant init, в результате получаем файл Vagrantfile, который содержит описание наших виртуалок. Я предпочитаю использовать один раз настроенный файл и копировать его из проекта в проект, изменяя необходимые секции и конфиги. В файле ниже Vagrantfile одной VM. Например, настроим RabbitMQ и установим Oracle Java.
Этого конфигурационного файла будет достаточно для запуска машины с обычной Ubuntu 12.04 LTS без каких-либо установленных сервисов и программ. Но я человек ленивый, и мне не хочется каждый раз руками устанавливать и настраивать софт на виртуалке, а хочется не тратить время и сразу начать гонять код или проводить какие-либо тесты.
Добавим в Vagrantfile в описание ноды секцию:
Каталог modules содержит файлы модулей, которые мы будем использовать; каталог manifests содержит манифест site-rmq.pp Puppet’а нашей виртуалки; files — каталог с файлами, которыми управляет fileserver; fileserver.conf — файл для использования fileserver и подкладывания каких-либо специфичных файлов в нашу виртуалку.
Но если мы хотим использовать сторонние модули для Puppet’a, то их нужно установить перед запуском puppet apply. Для этого я ничего лучше, чем использовать скрипт, не придумал; если есть умельцы, которые расскажут мне, как поставить модули, а потом использовать их в манифестах с помощью одного только Puppet’а, буду признателен. =)
Добавляем секцию для провизионинга виртуалки shell-скриптом:
В скрипте с репозитория ставятся git и librarian-puppet и потом с помощью librarian-puppet устанавливаются нужные нам модули. Более подробно о возможностях librarian-puppet можно найти на github: github.com/rodjek/librarian-puppet Важно установить git заранее, иначе мы не сможем использовать librarian-puppet для установки модулей с git-репозиториев. А так же пришлось сделать небольшой хак с копированием модуля для установки Java, просто в этом репозитории немного нестандартное расположение самого модуля. Но можно также использовать плагин Vagrant’a для librarian-puppet github.com/mhahn/vagrant-librarian-puppet
Теперь достаточно в каталоге нашего проекта сделать:
и подождать несколько минут, в зависимости от скорости подключения к интернету. (При первом запуске выкачается образ Ubuntu)
Теперь можно зайти в нашу виртуалку:
и проверить, например, установленную Java:
А также можно открыть WebUI RabbitMQ сервиса:
Конечно, можно поискать нужные модули и с помощью Puppet установить всё, что душе угодно. Благо коммьюнити у Puppet довольно активное и большое. А также можно написать нужный модуль самому и использовать его. Выше дан лишь пример для одного сервиса и одной машины. Их может быть несчётное множество.
Для ленивых в качестве бонуса файлики выложил на гитхаб: github.com/wl4n/vagrant-skel
Надеюсь, эта статья поможет Вам уделять больше времени изменению кода, а не настройке окружения для него, и избавит от необходимости исправлять и воспроизводить магические баги Production-environment’а.
Штампуем окна: автоматизированное развёртывание виртуальных машин Windows на Hyper-V при помощи Vagrant (часть 3)
В принципе, ничего особенного, за исключением того, что некоторые команды, включая Install-WindowsUpdate, являются модулями Boxstarter (за что мы его и любим).
Cannot add ‘disk.vhdx’. The disk is already connected to the virtual machine ‘Windows2012R2x64’’. (Virtual machine ID 35449990-E3D2-4BE1-99E5-2CAACC537097).
Это известная проблема. Пока я не смог её победить наскоком, так что буду рад, если кто-то подскажет, как её можно одолеть. Иначе остаётся ждать, пока то поправят разработчики.
Вот и всё! Теперь можно штамповать виртуальные машины в любом количестве (ну, насколько хватит ресурсов гипервизора, конечно). Если не переименовать название инстанса (а оно берётся из бокса), то в имени просто дописывается “_1”, соответственно ещё одна будет иметь в конце “_1_1” (а не “_2”): так уж написан файл import_vm.ps1.
Если что-то не получилось и не всё пошло гладко — всегда можно попробовать поработать с чужим боксом. Свой я, к сожалению, дать не могу (туда уже забиты лицензионные ключи и сертификаты), однако можно воспользоваться боксом Мэта Рока, о котором уже упоминалось в статье; благо этот бокс доступен публично из интернета, его можно добавить одной командой (по умолчанию Vagrant ищет боксы у себя в облаке):
Поднятие о нескольких машин
Что ж, в итоге мы получили поднятие ВМ по нажатию нескольких кнопок. Что же делать, когда хочется установить сразу целое окружение? Конечно, для этого понадобиться немного поскриптовать, но не обязательно сразу браться за Powershell. К счастью, конфигурационные файлы написаны на Ruby, что позволяет поднимать несколько машин за раз из одного Vagrantfile, одной командой, причём можно даже указывать несколько различных боксов в одном файле. Процедура подробно описана в документации. При должном владении языком можно творить настоящие чудеса: например, автоматически, беря из JSON файла, назначать настройки сети и имена хостов всем машинам, а также накатывать на них рецепты Chef в зависимости от роли в том же файле (например, так). Однако, это далеко выходит за рамки этой, и так уже расползшейся статьи.
Итоги
Что ж, что мы получили в результате? Систему быстрого развёртывания Windows машин в родном для них окружении, поднимающую готовую виртуалку и настраивающую её согласно нашим требованиям.
Чем это помогло конкретно нашей компании? Это значительно экономит время на поднятие новой инфраструктуры: раньше установка системы из ISO файла, настройка и обновление всего софта могла занять полдня, теперь это считанные минуты. Даже клонирование машин из шаблонов System Center обычно происходит дольше, не говоря уже о перечисленных недостатках типа наследования файлов виртуальных жёстких дисков. Также это отличный инструмент для наших разработчиков и тестировщиков, которые получили возможность быстро поднять на локальной системе (даже на рабочих станциях с Windows 8.1) какое-то тестовое окружение. Для этого я написал простую короткую инструкцию, так что им не надо вникать в детали и отвлекаться от рабочего процесса.
Что дальше? Сейчас мы ведём активную работу по анализу и документированию имеющихся окружений, чтобы потом описать их в виде рецептов Chef. Наши службы планируется устанавливать и выкатывать в виде пакетов. Это позволит автоматизировать множество процессов, избавиться от множества рутины и ошибок, связанных с человеческим фактором. В общем, то, что доктор DevOps прописал. Также в планах осваивание Packer, если понадобиться быстро готовить много разных образов. Поддержка Hyper-V и Azure в нём появилась совсем недавно, но выглядит очень многообещающей. Также в планах работа по быстрой синхронизации папок между ВМ и хостом — к сожалению, обычный шаринг работает довольно медленно для большого количества файлов и активных операциях (например, билде).
Если эта статья была полезной и тема в целом интересна — я с радостью сделаю отдельную публикацию о наших последующих победах и неудачах на этом поприще.
Как работать с vagrant на windows
Начало работы с Vagrant
Где взять VirtualBox
Vagrant полностью зависит от программы VirtualBox и использует ее для создания виртуальных образов. Основным назначением VirtualBox является полная виртуализация x86 оборудования. Это проект с открытым исходным кодом, который обеспечивает виртуализацию на профессиональном уровне и может быть использована как на серверах так и на десктопных компьютерах для построения виртуальных сред. VirtualBox доступен для Windows, Mac OS X, Linux и Solaris.
На текущий момент Vagrant поддерживает VirtualBox 4.0.x, 4.1.x и 4.2.x.
Ваше первое виртуальное окружение Vagrant
В командной строке наберите:
Эти команды необходимы для запуска виртуальной машины с помощью Vagrant. Учтите, что команды выше запускают полнофункциональную виртуальную машину на операционной системе Ubuntu 12.04LTS precise с объемом памяти по умолчанию в 512Мб.
Преимущества от использования Vagrant
Многие Web-разрабочики используют виртуальное окружение для разработки своих Web-приложений. Все большую популярность сейчас набирают облачные сервисы для построения и развертывания виртуальных окружений для продакшена и разработки, начиная от EC2, Rackspace Cloud и заканчивая более специализированными как EngineYard и Heroku. Vagrant реализует схожие принципы при создания виртуальных машин для локальной разработки и тестирования ваших приложений на рабочем компьютере. Такая организация работы повышает гибкость и продуктивность как вас так и вашей команды при разработке web-приложений.
Для развертывания и настройки виртуальных окружений Vagrant использует достаточно зарекомендовавшие себя технологии виртуализации в лице VirtualBox от Oracle и технологии автоматизированного развертывания приложений от Chef и Puppet.
Преимущества для одного разработчика
Использование однотипного окружения разработки для разных проектов расчитанных для разных версий языков программирования и фреймворков зачастую очень трудная задача. Как быть, если один проект работает на PHP4, второй на PHP 5.2.x, а третий на PHP 5.3.x или 5.4.x и его необходимо тестировать в той версии языка на которую он расчитан?
Ставить кучу разных версий языков и сервисов и загружать рабочую машину, не вариант, т.к. рано или позно ваша система начнет долго загружаться, тормозить и глючить. Еще один момент, заключается в том, что каждый из рабочих проектов работает в продакшене на сервере, где стоит определенное окружение, поэтому при разработке такого проекта надо, чтобы окружение на компьютере разработчика точно соответствовало окружению на рабочем сервере, чтобы разработчик мог быть полностью уверен в том, что у него не будет неприятных сюрпризов при развертывании своего web-приложения на рабочем сервере.
Vagrant решает эти проблемы. С помощью него вы можете создавать виртуальные машины с окружением необходимым для каждого конкретного проекта. При переключении с одного проекта на другой, вы просто парой команд останавливаете одну виртуальную машину и поднимаете другую нужную для другого проекта. Все гениально и просто!
Преимущества для команды разработчиков
В этом случае Vagrant позволяет команде создавать и использовать готовые образы виртуальных окружений для соответствующих проектов. Когда другой участник команды присоединяется к разработке другого проекта, он просто берет у своих коллег образ виртуальной машины для этого проекта и разворачивает этот образ у себя. Все, за считанные минуты разработчик получает готовое окружение и может спокойно приступать непосредственно к своей части работы.
Преимущества для компании
Если у вас крупная компания и вы работаете на крупным развивающимся проектом, то вам постоянно приходится добавлять какие-то новые компоненты в инфраструктуру приложения, например, различные системы кеширования, обработчики событий, сервера баз данных и т.д. В этом случае Vagrant предоставляет вам средство для создания и распространения готовых окружений разработки. Теперь если к вам в компанию приходит новый сотрудник то ему нет необходимости тратить массу времени на начальную настройку всей своей системы, чтобы присоединиться к разработке приложения.
Vagrantfile для Vagrant как Makefile для Make. Vagrantfile располагается в корне каждого Vagrant проекта и используется для настройки поведения самого Vagrant и виртуальных машин созданных с помощью него. Пример содержимого этого файла приведен ниже:
Как вы видите, содержимое файла это код на языке Ruby.
Настройка Vagrant проекта
Первым шагом для любого проекта Vagrant является создание корневой директории проекта и инициализация проекта:
команда vagrant init создаст файл Vagrantfile. Пока мы оставим этот файл как есть, но далее мы будем его редактировать для настройки виртуальной машины нашего проекта.
Теперь когда Vagrant настроен, давайте создадим небольшой web-проект, который будем потом использовать для демонстрации работы Vagrant. Создайте в корне Vagrant проекта (где расположен файл Vagrantfile) индексный html файл:
В принципе на этом настройка web-проекта закончена.
Образы виртуальных машин (Виртуальные боксы)
Следующим шагом после инициализации проекта, является создание базового бокса. Vagrant не создает виртуальную машину с нуля. Он импортирует базовый образ виртуальной машины и запускает его, применяя затем все необходимые настройки заданные в конфигурационном файле Vagrantfile. Это упрощает жизнь пользователям Vagrant, т.к. им не надо тратить время на настройку параметров виртуальной машины, таких как выделенная виртуальная память, объем диска, сетевые интерфейсы и пр.
Получение базового образа виртуальной машины
В самом начале статьи мы уже скачали базовый образ 32-битной системы Ubuntu 12.04LTS precise и добавили его в Vagrant. Обратите внимание, что если вы уже скачали образ, то вам не нужно повторно каждый раз его скачивать при последующем запуске. Vagrant поддерживает загрузку образов как из Интернета, так и с вашего жесткого диска. В самом начале статьи мы запустили следующую команду:
После ее выполнения Vagrant скачал образ и сохранил его в системной папке пользователя на диске. При этом этот образ был автоматически добавлен в глобальное пространство текущей установки Vagrant на вашем компьютере, т.е. теперь для всех проектов, которые вы будете создавать этот образ будет доступен для выбора при развертывании виртуального окружения. Также, каждый добавленный таким способом образ имеет уникальное имя, в данном примере, это precise32-box.
Адрес http://files.vagrantup.com/precise32.box мы использовали только один раз в самом начале, теперь подключать базовый образ мы будем из локального хранилища на жестком диске.
Удаление виртуальных боксов
Также просто как добавить, виртуальные боксы можно и удалить. Для этого используйте команду:
При этом бокс удаляется физически с диска. После этого ни одна виртуальная машина созданная ранее на основе этого бокса не сможет быть запущена.
Настройка проекта для использования нужного виртуального бокса
Теперь, когда виртуальный бокс с именем precise32-box был добавлен в Vagrant мы можем добавлять его в наши проекты. Это делается путем записи в конфигурационный файл Vagrantfile следующей строчки:
На данный момент мы произвели самую базовую настройку нашего виртуального окружения. Мы не задали переброс портов (port forwarding), свое обеспечение для окружения (provisioning) и т.д. Но даже с такой базовой настройкой у нас получилась полнофункциональная виртуальная машина. Вы можете в этом убедится набрав следующую команду vagrant up из корневой директории проекта Эта команда запустит виртуальную машину. Чтобы остановить запущенную виртуальную машину и очистить место на диске, которое она занимала, нужно выполнить команду vagrant destroy :
ВНИМАНИЕ: для пользователей Windows
Доступ к файлам проекта с виртуальной машины
Обеспечение для виртуальных боксов (Provisioning)
Настройка Chef и Vagrant
В данной статье мы воспользуемся заранее приготовленными рецептами для Chef, чтобы продемонстрировать развертывания виртуальной машины. Для этого отредактируем конфигурационный файл Vagrantfile:
Обратите внимание, что мы используем URL http://files.vagrantup.com/getting_started/cookbooks.tar.gz для загрузки набора рецептов (cookbooks) для Chef. Вместо этого вы также можете просто скопировать набор рецептов в корневую директорию нашего Vagrant-проекта и подключить их через конфиг в Vagrantfile’е. Более подробно про это можно найти в разделе ChefSolo.
После того как Vagrant завершит все необходимые действия и настройки системы, у вас будет полноценный настроенный web-сервер на виртуальной машине. Однако, пока вы еще не сможете увидеть свой web-проект на ней через браузер на вашем рабочем компьютере, т.к. мы еще не настроили проброс портов (port forwarding).
Чтобы убедится все же что наш простой сайт уже работает, вы можете подключится по ssh к виртуальной машине и в командной строке ssh-терминала набрать следующее:
Далее мы настроим проброс портов, чтобы вы могли увидеть свой сайт через браузер на своем компьютере.
Проброс портов (Port Forwarding)
Проброс портов позволяет задать номер порта на гостевой машине (в данном случае на нашей виртуальной машине), который будет доступен извне на хост машине (т.е. на нашем рабочем компьютере). Это позволит нам обращаться к web-серверу установленному на виртуальной машине из браузера на нашем рабочем компьютере.
Задание номера порта для проброса
В данном случае мы хотим пробросить порт на котором работает сервер Apache. Проброс порта настраивается в файле Vagrantfile следующим образом:
Итак, мы получили готовое для использования виртуальное окружение для нашего web-проекта. Но представьте ситуацию, что вы не один, а состоите в команде и вам надо обеспечить своих коллег такимже виртуальным окружением как и у вас. Что делать? Vagrant предоставляет для этого случая возможность создавать пакеты (packages) виртуального окружения. Эти готовые пакеты вы отдаете своим коллегам и они устанавливают их у себя на компьютере.
Далее выполните команду:
Созданный бокс можно теперь отдать другому участнику команды, чтобы он скопировал его к себе на рабочий компьютер и установил или выложить его в интернет, тогда его можно будет потом просто скачать на нужный компьютер и запустить. Бокс запускается на другом компьютере следующим образом:
После выполнения этих команд другой участник вашей команды получит готовое к работе виртуальное окружение (точную копию вашего виртуального окружения).
Остановка виртуальных боксов (Teardown)
Чтобы завершить запущенное виртуальное окружение в Vagrant существует три разных способа сделать это:
Все эти типы остановки виртуальных боксов рассмотрены далее.
При таком завершении работы не требуется дополнительное место на диске, т.к. состояние системы не сохраняется. Возобновление работы при этом длится немного дольше чем в предыдущем случае, т.к. виртуальное окружение загружается как при загрузке обычного компьютера.
Основное преимущество этого способа в том, что вы экономите до 1 Гб места на жестком диске. Но при этом возобновление работы будет самым долгим процессом, т.к. Vagrant’у придётся заново ставить весь необходимы софт из рецептов. Обычно не рекомендуется пользоваться данным способом завершения работы, если только вы не стремитесь любой ценой сэконмить место на жестком диске, что при текущих размерах современных жестких дисков крайне редкая необходимость.
Давайте предположим такую ситуацию: вы закончили работу над проектом, сдали его заказчику, получили оплату. Прошло пол года, год и вот босс говорит вам, что надо возобновить работу над проектом для этого заказчика. У вас за это время могло много чего поменяться на рабочем компьютере, вы снесли и переустановили операционную систему, обновили софт, да мало-ли что еще могло произойти?