Контейнерные среды разработки PHP с Vagga

Это случается со всеми нами время от времени.

Мы клонируем проект, а затем пытаемся его запустить. Однако что-то не работает.

Это может быть наша версия NGINX или Apache. Возможно, что npm не делает что-то правильно. Возможно, проекту необходимо расширение, и у нас его нет, и теперь нам нужно построить расширение из исходного кода, поскольку в наших репозиториях не существует зависимости. Независимо от причины, чем сложнее установка, тем выше вероятность отказа.

Когда я впервые познакомился с Vagrant , это было похоже на небеса: наконец-то появилась возможность освободиться от недостатков Windows, не сталкиваясь с проблемами доступности, существующими в Linux.

Я был счастлив. На время. И тогда меня поразило ограничение наличия виртуальных машин в качестве среды разработки. Жесткий.

Представьте себе эту сцену: сейчас 4:30 вечера. Разработчик, работающий над системой Asterisk , покинул компанию. Что-то в логике платежей (написано на PHP с использованием устаревшего проекта PHPagi ) не работает, и вам нужно быстро это исправить. Вы и коллега призываете всех к созданию сервисно-ориентированной архитектуры, поэтому, чтобы иметь возможность создавать среду разработки, вам необходимо иметь следующее:

Экземпляр машины Asterisk, которая обрабатывает вызовы. На нем должны быть запущены Asterisk и PHP 5.5.X.
Экземпляр другой машины Asterisk, которая фактически обрабатывает платеж. Поскольку у банка, с которым вы работаете, есть политика закрытия всего доступа к своим API-интерфейсам, поступающим извне здания, это копия компьютера выше, но с другим работающим кодом на нем.
Внутренний API-интерфейс PHP, который выполняет тяжелую работу, написанный на PhalconPHP .

Итак, вы записываете вместе несколько сценариев кукол, чтобы подготовить свои ящики, вы vagrant up трем машинам и готовитесь войти в зону !

Если бы это был фильм, сцена в этот момент масштабировалась бы на ваш хост-компьютер, драматически показывая большие объемы данных, перемещающиеся со скоростью света между различными частями вашей системы, заполняя вашу память и процессор, а затем приходя в тупик. , Однако, поскольку это не фильм, достаточно сказать, что ваша машина разработки может обрабатывать один или два блока с 8 ГБ памяти в Windows, но когда появится третий компьютер, ваша среда разработки будет работать медленно. до такой степени, что вы не сможете запустить IDE.

Конечно, вы очень умны и находчивы, и знаете, как это работает. Вы бы снизили объем памяти и ЦП в своем vagrantfile , но это приводит к vagrantfile , что Asterisk жалуется на небольшой объем памяти, и когда вы вручную вызываете свою телефонную систему с программным телефоном (аналог браузера в онлайн-мире), чтобы проверить его, аудио разбивается и искажается. Вам нужно гораздо больше памяти, чем у вас уже есть, и у вас нет к ней доступа, а сейчас уже 10:30 вечера.

Так что с тобой происходит?

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

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

Что такое Вагга?

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

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

Подождите! Что не так с Docker и Docker-compose?

Docker-compose — это инструмент для настройки и создания нескольких контейнеров Docker через файл конфигурации. У меня лично нет опыта работы с Docker и Docker-compose. Однако в документации Vagga есть страница, сравнивающая Vagga и Docker . Вы можете проверить это, если вам интересно. Если у вас есть опыт использования Docker, расскажите нам о различиях и сходствах в комментариях!

Требования

Так как Homestead — это то, что мы рекомендуем здесь, в SitePoint, было бы здорово, если бы мы могли повторить эту настройку с Vagga, чтобы иметь реальный способ оценки ее простоты использования, преимуществ и недостатков. Итак, в этой статье мы рассмотрим веб-сервер (NGINX) в сочетании с PHP-fpm для обслуживания файла index.php который состоит всего из трех строк:

 <?php phpinfo ( ) ; ?>

Установка

Вагга очень нова и не имеет времени и рабочей силы позади Вагранта и Докера. Вы можете увидеть это на этапах установки, описанных ниже. Я призываю вас стиснуть зубы и пройти через это; Я обещаю, что если вы привыкли использовать Vagrant, как я, награды будут удивительными.

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

Linux

Примечание : поддержка PHP и композиторов была добавлена в Vagga совсем недавно, поэтому мы будем использовать пакеты *-testing . Когда это *-testing в стабильную ветку, вы можете использовать приведенные ниже URL-адреса без суффикса *-testing .

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

Если вы используете Ubuntu 14.04 (Trusty) или выше, установить Vagga так же просто, как запустить его в своем терминале:

 curl http : / / files . zerogw . com / Vagga / Vagga - install - testing . sh | sh

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

Windows и Mac OS X

Если вы используете Windows или Mac, вам действительно нужно установить Vagrant, потому что Vagga в настоящее время работает в Linux. Это может показаться вам ироничным, основываясь на реальной истории, которую я сказал в начале этой статьи. Однако имейте в виду, что вы все еще можете использовать Vagga по указанным ниже причинам, даже если вам придется делать это внутри виртуальной машины:

Запуск разных программ одновременно (базы данных, веб-серверы, экземпляры PHP-fpm) с различной конфигурацией, не занимая огромных объемов памяти и ЦП
Быстро подготовить свои ящики, не будучи знакомым с программным обеспечением оркестровки (например, puppet или chef), или не имея дело с демонами контейнеров, такими как Docker
Документирование шагов, необходимых для создания среды разработки
Перестройка контейнеров в случае изменения зависимостей проекта (например, добавление нового пакета в ваш composer.json или изменение версии уже существующего пакета)

Вот шаги по подготовке среды для установки Vagga внутри Vagrant:

Установите Vagrant и virtualbox .
Установите плагин vagrant-Vagga , открыв командную строку и запустив vagrant plugin install Vagrant-Vagga .
Создайте новую папку для размещения вашего проекта и запустите vagrant init ubuntu/wily64 чтобы создать vagrantfile , используя ubuntu/wily64 в качестве базового образа.

Установка vagrant-Vagga добавила нового vagrant-Vagga в вашу установку Vagrant. Без этого вы не сможете использовать Vagga из-за ограничений в vboxfs , виртуальная файловая система virtualbox использует для обмена файлами между вашим хостом и гостевыми машинами (если вы не знаете, о чем я говорю, ознакомьтесь с этой статьей, чтобы получить больше фон).

Следующим шагом будет указание Vagrant запускать этого провайдера каждый раз, когда вы запускаете vagrant up для запуска своей виртуальной машины. Как? Просто откройте ваш vagrantfile , перейдите в конец и добавьте эти две строки чуть выше строки, которая читается как end :

  config . Vagga . testing = true config . vm . provision :Vagga , run : 'always'

Первая строка говорит Vagrant-Vagga установить тестовую версию Vagga. Это необходимо, потому что в настоящее время функция установки composer и PHP есть только в двоичных файлах тестирования.

Вторая строка довольно очевидна; он просто запускает провайдера Vagga, который связывает ваш каталог .Vagga с другим каталогом на виртуальной машине, предотвращая проблемы, связанные с размещением этой папки в синхронизированной папке vboxfs .

Уф! Вы закончили настройку своей виртуальной машины! Теперь вы можете запустить vagrant up чтобы вызвать среду, которую вы будете использовать для запуска контейнеров Vagga. Vagrant потребуется некоторое время, чтобы загрузить изображение коробки, так что возьмите себе чашку кофе и похлопайте себя по спине, чтобы добраться до этого — отсюда становится все проще!

Готовимся: Vagga.yaml

Так же, как у нас есть composer.json , vagrantfile , Dockerfile и подобные файлы, у нас также есть Vagga.yaml который содержит определения для контейнеров и команд.

Настройка наших контейнеров

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

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

Создайте файл с именем Vagga.yaml в каталоге Vagga.yaml , который является корнем нашего проекта, и давайте определим первый эскиз

 containers: nginx: setup: - !Ubuntu trusty - !Install [software-properties-common] - !Sh add-apt-repository ppa:nginx/stable -y && apt-get update - !Install [nginx] php: setup: - !Ubuntu trusty - !Install [software-properties-common] - !Sh add-apt-repository ppa:ondrej/php -y && apt-get update - !Install [php7.0, php7.0-fpm] - !ComposerConfig install_runtime: false - !ComposerInstall

Прежде чем мы скажем Vagga создать эти контейнеры, давайте посмотрим, что мы включили в этот файл.

Примечание : если вы не знакомы с YAML, взгляните на эту несколько устаревшую статью под названием « Использование YAML в ваших проектах PHP» . Все, что вам нужно из этой статьи, — это как синтаксис YAML сопоставляется с типами данных PHP.

Как видно на первый взгляд, существует ключ первого уровня, называемый containers , который представляет собой массив пар ключ-значение. Ключ — это имя нашего контейнера (в данном примере это nginx и php ), а значение — это конфигурация для каждого контейнера.

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

Команды начальной загрузки: эти шаги сборки выполняются первыми и устанавливают операционную систему на контейнер. В нашем примере мы использовали шаг сборки !Ubuntu для установки предопределенной версии (14.04, AKA trusty ) в наш контейнер.
Команды распространения: это команды, которые Vagga преобразует в специфическую для распределения команду. Например, наш шаг !Install build, приведенный выше, преобразуется в команду apt-get install -y <package name> когда она запускается внутри контейнера Ubuntu.
Общие команды: это команды, которые вы можете запускать в любом дистрибутиве, который вам нравится. Это низкоуровневые команды, такие как !Sh для запуска команды с оболочкой !Download для загрузки файла в контейнер !TarInstall и !TarInstall для извлечения и установки архива tar и так далее. Мы использовали команду !Sh в Vagga.yaml выше примере Vagga.yaml для добавления PPA- ondrej/PHP nginx/stable и ondrej/PHP .

Итак, как вы, вероятно, можете сказать, чтобы настроить наши контейнеры, мы:

Установите Ubuntu Trusty
Установите software-properties-common для получения доступа к команде add-apt-repository
Добавьте nginx/stable в контейнер NGINX и ondrej/php в контейнер PHP, а затем запустите apt-get update чтобы получить список пакетов из недавно добавленных репозиториев.
Установите пакеты: nginx в контейнере NGINX и php7.0 и php7.0-fpm в контейнере php
Сконфигурируйте composer, используя !ComposerConfig чтобы не устанавливать сам пакет PHP (если вы этого не сделаете, он установит пакет php , который на момент написания статьи был версии 5.5.9), а затем сам установит composer, используя !ComposerInstall

Если вы запустите Vagga _build nginx или Vagga _build php на этом этапе, вы получите некоторые ошибки, говорящие о невозможности записи файла. Это связано с тем, что по соображениям безопасности Vagga не позволяет приложениям внутри вашего контейнера записывать данные в файловую систему, если вы явно не разрешаете записывать в некоторые каталоги. Вы можете сделать это, добавив тома.

Добавление томов

Тома — это прежде всего способ разрешить приложениям ваших контейнеров записывать в файловую систему. Каталог, в Vagga.yaml находится Vagga.yaml , автоматически добавляется в контейнер как /work (точно так же, как Vagrant добавляет каталог, содержащий vagrantfile виде /Vagrant внутри виртуальной машины), но кроме этого Vagga добавляет /tmp и /run и /run/shm как тома тоже.

Чтобы узнать и прочитать больше о различных типах томов, посетите страницу томов в документации Vagga .

Если вы будете искать в Интернете или продолжать пытаться создать свои контейнеры, вы почувствуете, какие каталоги необходимы для запуска пакета. В нашем примере NGINX требует /var/lib , /var/lib/nginx , /var/log и /var/log/nginx . Точно так же PHP требует доступа к /run/php и /var/log . Давайте добавим их в наши контейнеры:

 containers: nginx: setup: - !Ubuntu trusty - !Depends runtime/nginx/default - !Install [software-properties-common] - !Sh add-apt-repository ppa:nginx/stable -y && apt-get update - !Install [nginx] volumes: /var: !Tmpfs mode: 0o766 subdirs: lib: lib/nginx: log: # default mode is 0o766 log/nginx: { mode: 0o1777 } php: setup: - !Ubuntu trusty - !Install [software-properties-common] - !Sh add-apt-repository ppa:ondrej/php -y && apt-get update - !Install [php7.0, php7.0-fpm] - !ComposerConfig install_runtime: false - !ComposerInstall volumes: /run: !Tmpfs mode: 0o766 subdirs: php: /var/log: !Tmpfs mode: 0o766

Как видите, мы добавили каталоги первого уровня в качестве томов и определили все подкаталоги в этом каталоге в разделе подкаталогов каждого тома. Когда режим установлен в родительском каталоге, все подкаталоги также наследуют его по умолчанию.

Примечание . Если вы не можете понять параметр режима каждого тома, вы можете думать о нем так: первое значение (0 или 1) — это бит Sticky , o означает значение, следующее за восьмеричным, а следующее три числа (например, 777 ) являются разрешениями.

Настройка NGINX и PHP-fpm

Как вы, вероятно, знаете, если вы когда-либо устанавливали NGINX или PHP-fpm вручную, после установки этих приложений на компьютере с Linux вы должны настроить их. Поскольку мы хотим сделать это автоматически, мы можем сами написать файл конфигурации и использовать шаг сборки !Copy чтобы вставить его в контейнер во время сборки. На этом этапе я обычно делаю следующее:

Присоединитесь к контейнеру (т.е. войдите в него), запустив Vagga _run <container name> bash . Это просто запускает bash в контейнере и позволяет вам вводить команды.
Скопируйте файл конфигурации, который я хочу отредактировать, в каталог /work , чтобы я мог получить к нему доступ на своем компьютере. Я делаю это, запустив команду типа cp nginx.conf /work . Помните, что каталог /work является общим для вашей машины и контейнера.

Итак, для настройки NGINX и PHP-fpm вам необходимо отредактировать следующие файлы:

/ И т.д. / Nginx / сайты доступное / по умолчанию
/etc/php/7.0/fpm/php-fpm.conf
/etc/php/7.0/fpm/pool.d/www.conf

Соглашение о размещении файлов конфигурации в вашем проекте, похоже, является каталогом runtime внутри вашего проекта. Перейдите в папку вашего проекта (в нашем примере vagga ) и создайте каталог runtime . Внутри него создайте каталог с именем nginx для хранения вашей конфигурации NGINX, а другой с именем php для хранения двух других файлов. Вы можете либо скопировать файлы конфигурации из своего контейнера, чтобы почувствовать процесс, либо просто скопировать и вставить следующее содержимое в каждый файл.

выполнения / Nginx / по умолчанию

В этом файле мы сообщаем NGINX прослушивать порт 8000, задаем имя сервера example.com и www.example.com и www.example.com путь к нашей корневой папке и экземпляру PHP-fpm (который будет прослушиваться на 127.0.0.1:9000 ):

Примечание : поскольку Vagga работает без привилегий root, процессы, работающие внутри контейнеров, не могут прослушивать порты ниже 1024. Это ограничение наложено операционной системой Linux.

 server { listen 8000; root /work/; index index.php index.html index.htm; server_name example.com www.example.com; location / { try_files $uri $uri/ /index.html; } error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/www; } location ~ \.php$ { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }

Среда выполнения / PHP / PHP-fpm.conf

Причина, по которой мы редактируем этот файл, заключается в том, что, поскольку Docker и Vagga контролируют процесс внутри каждой машины, они требуют, чтобы ваши приложения запускались на переднем плане, то есть они не должны быть демонами. По умолчанию PHP-fpm работает как демон, и мы редактируем конфигурацию, чтобы установить для параметра конфигурации daemonize значение no .

 daemonize = no

Другим, возможно, более чистым способом было бы просто создать файл с именем no-daemonized.conf и поместить в него одну строчку выше, затем поместить его в наш каталог runtime/php и скопировать его вместо этого.

выполнения / PHP / www.conf

Причина, по которой мы меняем этот файл, заключается в том, чтобы он слушал порт 9000 вместо создания файла сокета. Измените значение listen :

 listen = 9000

Копирование конфигурации в контейнеры

Последний шаг в создании наших контейнеров — скопировать эти файлы конфигурации в нужное место. Как вы, возможно, помните, ранее в этой статье я говорил, что Vagga перестроит ваши контейнеры, если изменятся зависимости вашего проекта. Итак, поскольку мы хотим, чтобы изменения в этих файлах конфигурации вступали в силу каждый раз, когда мы запускаем команды, нам также необходимо добавить их как зависимости с помощью команды !Depend . Вот финальная версия нашего Vagga.yaml :

 containers: nginx: setup: - !Ubuntu trusty - !Depends runtime/nginx/default - !Install [software-properties-common] - !Sh add-apt-repository ppa:nginx/stable -y && apt-get update - !Install [nginx] - !Copy source: /work/runtime/nginx/default path: /etc/nginx/sites-available/default volumes: /var: !Tmpfs mode: 0o766 subdirs: lib: lib/nginx: log: # default mode is 0o766 log/nginx: { mode: 0o1777 } php: setup: - !Ubuntu trusty - !Depends runtime/php/php-fpm.conf - !Depends runtime/php/www.conf - !Install [software-properties-common] - !Sh add-apt-repository ppa:ondrej/php -y && apt-get update - !Install [php7.0, php7.0-fpm] - !ComposerConfig install_runtime: false - !ComposerInstall - !Copy source: /work/runtime/php/php-fpm.conf path: /etc/php/7.0/fpm/php-fpm.conf - !Copy source: /work/runtime/php/www.conf path: /etc/php/7.0/fpm/pool.d/www.conf volumes: /run: !Tmpfs mode: 0o766 subdirs: php: /var/log: !Tmpfs mode: 0o766

Примечание : обратите внимание, что при копировании и исходный, и целевой путь находятся внутри контейнера. Это не похоже на Docker, где адрес источника указан внутри хоста.

Успех! Теперь вы можете запускать Vagga _build nginx и Vagga _run php для создания ваших контейнеров! Загрузка пакетов займет некоторое время, поэтому выполните процедуру grab-coffee-pat-self-on-the-back и подготовьтесь к последнему шагу: добавьте команду run чтобы связать все вместе.

команды

Команды — это то, что другие разработчики используют, чтобы использовать возможности этой новой настройки. Существует два типа команд:

Команды с тегом !Command : эти команды запускаются и просто выходят. Примерами команд этого типа являются ls , php -v и т. Д.
Команды, помеченные !Supervise : эти команды имеют несколько children элементов и будут выполнять действие (определенное их атрибутом mode ), если какая-либо из команд, которые они просматривают, завершится. Примеры этих команд включают nginx и PHP-fpm , что мы и будем использовать.

Сначала давайте добавим команду с именем php . Он передаст нужный нам файл интерпретатору PHP, установленному внутри нашего php контейнера. Добавьте это в конец вашего Vagga.yaml :

 commands: php: !Command description: passes the given parameters to the PHP interpreter container: php run: [php]

Как вы можете догадаться, description — это текст справки, который выводится, когда вы запускаете vagga без аргумента, container — это контейнер для запуска команды, а run — это команда для запуска. Если бы мы не предоставили аргумент для run в виде массива, он не принял бы аргументы и просто запустил бы php без них. Однако, предоставляя значение в виде массива, мы позволяем пользователю передавать аргументы в php, например, в файл.

Чтобы проверить это, вы можете просто сделать Vagga php -v . Если вы используете Vagrant, вы можете vagrant ssh Vagga php -v на компьютер /Vagrant , Vagga php -v каталог /Vagrant и запустить Vagga php -v . Или вы можете просто запустить vagrant Vagga php -v со своего хоста за пределами вашего Vagrant box.

Наконец, мы готовы запустить наш стек NGINX и PHP. Сначала измените раздел команд внутри Vagga.yaml :

 commands: php: !Command description: passes the given parameters to the PHP interpreter container: php run: [php] run: !Supervise description: Run the NGINX and PHP stack mode: stop-on-failure children: nginx: !Command container: nginx run: nginx -g "daemon off;" php: !Command container: php environ: DATABASE_URL: postgresql://Vagga:[email protected]:5433/test run: php-fpm7.0

Как видите, мы не предоставляем значение атрибута run в виде массива, что эффективно запрещает пользователям передавать какие-либо аргументы.

Наконец, давайте запустим Vagga run (или vagrant Vagga run ) и посмотрим на результат:

 [19-Mar-2016 15:00:22] NOTICE: fpm is running, pid 3 [19-Mar-2016 15:00:22] NOTICE: ready to handle connections [19-Mar-2016 15:00:22] NOTICE: systemd monitor interval set to 10000ms

Создайте файл index.php в вашем каталоге vagga , например:

 <?php phpinfo ( ) ; ?>

Если вы этого еще не сделали, откройте ваш vagrantfile и раскомментируйте эту строку, чтобы вы могли получить доступ к вашей виртуальной машине, используя статический IP:

  config.vm.network "private_network", ip: "192.168.33.10"

Затем добавьте example.com в файл hosts на вашем хост-компьютере. В системах Unix этот файл находится в /etc/hosts , а в Windows — в C:\Windows\System32\drivers\etc\hosts . Вот как вы должны сопоставить домен example.com с 192.168.33.10 , который является IP-адресом вашей виртуальной машины:

 192.168.33.10 example.com

Теперь просто откройте ваш браузер и перейдите по example.com:8000 или www.example.com:8000 . Вы должны увидеть страницу информации PHP.

Поздравляем! Вы создали среду разработки с помощью Vagga, и теперь вы можете позволить другим пользователям запускать среду разработки в удивительно короткие сроки!

Вывод

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

Конечно, у Vagga есть свои недостатки:

Он не такой кроссплатформенный, как Docker. Сам Docker также не является кроссплатформенным, но его участники создали инструменты, которые очень легко настроить в Windows.
Процесс установки не так прост, как у конкурентов. Возможно, вам придется поработать с какой-то конфигурацией в зависимости от используемого вами дистрибутива и версии.
Одно из преимуществ Puppet, Ansible, Docker и других по сравнению с Vagga состоит в том, что для создания среды разработки и производства не требуется владеть двумя языками — вы просто создаете среду с одним синтаксисом. Существует возможность развертывания контейнеров, созданных с помощью Vagga, однако процесс еще недостаточно документирован.
Vagga, как и Docker, требует, чтобы вы знали, как установить и настроить конкретный пакет, в то время как программное обеспечение для оркестровки, такое как Puppet, имеет модули для настройки популярного программного обеспечения для вас. На ум приходят такие примеры, как NGINX , PHP и PHP-fpm .
Вы должны сделать все с нуля. Нет базовых образов для сборки, в отличие от Docker или Vagrant.

Используете ли вы другое программное обеспечение, чтобы позволить вашей команде или вашим участникам быстро раскрутить среду разработки с нуля? Считаете ли вы, что в быстро меняющемся мире сред разработки 2016 года автоматизированные способы настройки среды разработки не стоят усилий? Расскажите нам свой опыт в комментариях!