Создание Vagrantfile

В этой странице обсуждается, как создать Vagrantfile, который можно использовать для создания новых коробок или машин. Этот контент написан специально для пользователей MariaDB.

Базовый Vagrantfile

Vagrantfile — это Ruby-файл, который инструктирует Vagrant создавать, в зависимости от того, как он выполняется, новые машины или коробки Vagrant. Вы можете рассматривать коробку как скомпилированный Vagrantfile. Она описывает тип машин Vagrant. Из коробки можно создать новые машины Vagrant. Однако, в то время как коробка легко распространяется в команде или широкой публике, Vagrantfile также может напрямую создавать одну или несколько машин Vagrant, не генерируя никакой коробки.

Вот пример простого Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "hashicorp/bionic64"
  config.vm.provider "virtualbox"
  config.vm.provision :shell, path: "bootstrap.sh"
end

Vagrant.configure("2") возвращает объект конфигурации Vagrant для новой коробки. В блоке мы будем использовать псевдоним config для ссылки на этот объект. Мы будем использовать версию 2 API Vagrant.

vm.box — это базовая коробка, которую мы будем использовать. Это Ubuntu BionicBeaver (18.04 LTS), 64-битная версия, предоставляемая HashiCorp. Схема имен коробок проста: учетная запись владельца в Vagrant Cloud, за которой следует имя коробки.

Мы используем vm.provision для указания имени файла, который будет выполнен при создании машины, для подготовки машины. bootstrap.sh — это общепринятое имя, используемое в большинстве случаев.

Чтобы создать новые машины Vagrant из Vagrantfile, перейдите в каталог, содержащий проект Vagrant, и выполните:

vagrant up

Чтобы скомпилировать Vagrantfile в коробку:

vagrant package

Эти операции могут занять время. Для предотвращения ошибок синтаксиса или определенных типов ошибок в Vagrantfile:

vagrant validate

Провайдеры

Провайдер позволяет Vagrant создавать машину Vagrant с использованием определенной технологии. Различные провайдеры могут использовать менеджер виртуальных машин (VirtualBox, VMWare, Hyper-V...), менеджер контейнеров (Docker) или удаленные хосты в облаке (AWS, Google Compute Engine...).

Некоторые провайдеры разработаны третьими сторонами. app.vagrant.com поддерживает поиск коробок, которые поддерживают наиболее важные провайдеры от третьих сторон. Чтобы узнать, как разработать новый провайдер, см. Разработка плагинов: провайдеры.

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

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

Вот пример использования провайдеров:

Vagrant.configure("2") do |config|
    config.vm.box = "hashicorp/bionic64"
    config.vm.provider "virtualbox" do |vb|
        vb.customize ["modifyvm", :id, "--memory", 1024 * 4]
    end
    config.vm.provider "vmware_fusion"
end

В этом примере мы пытаемся использовать VirtualBox для создания виртуальной машины. Мы указываем, что эта машина должна иметь 4 ГБ ОЗУ (1024М * 4). Если VirtualBox недоступен, Vagrant попытается использовать VMWare.

Этот механизм полезен по крайней мере по нескольким причинам:

• Разные пользователи могут использовать разные системы, и возможно, у них не установлены одинаковые технологии виртуализации.
• Мы можем постепенно переходить с одного провайдера на другой. В течение некоторого времени некоторые пользователи будут иметь новую технологию виртуализации, и они будут ее использовать; другие пользователи будут иметь только старую технологию, но они все равно смогут создавать машины с помощью Vagrant.

Средства подготовки

Мы можем использовать различные методы подготовки. Самый простой провайдер — shell, который позволяет запускать файл Bash для подготовки машины. Другие провайдеры позволяют настраивать машины с помощью программ автоматизации, включая Ansible, Puppet, Chef и Salt.

Чтобы узнать, как разработать новый провайдер, см. Разработка плагинов: провайдеры подготовки.

Провайдер shell

В примере выше провайдер shell выполняет bootstrap.sh внутри машины Vagrant для ее подготовки. Простой bootstrap.sh может выглядеть следующим образом:

#!/bin/bash

apt-get update
apt-get install -y 

Чтобы узнать шаги установки MariaDB на выбранной вами системе, см. раздел Получение, установка и обновление MariaDB.

Вы также можете восстановить резервную копию базы данных в новой машине Vagrant. Таким образом, вы можете иметь базу данных, необходимую для приложения, которое вы разрабатываете. Чтобы узнать, как это сделать, см. Обзор резервного копирования и восстановления. Наиболее гибкий тип резервной копии (означающий, что он работает между различными версиями MariaDB и в некоторых случаях даже между MariaDB и другими СУБД) — dump.

На машинах Linux провайдер shell использует оболочку по умолчанию. На машинах Windows он использует PowerShell.

Загрузка файлов

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

Вместо этого мы можем просто поместить необходимый нам файл в синхронизированную папку и затем скопировать его с помощью команды shell:

cp ./files/my.cnf /etc/mysql/conf.d/

Подготовка Vagrant с Ansible

Вот пример того, как подготовить машину или коробку Vagrant с помощью Ansible:

Vagrant.configure("2") do |config|
  ...
  config.vm.provision "ansible" do |ansible|
    ansible.playbook = "vagrant.yml"
  end
end

С помощью провайдера Ansible, Ansible выполняется на хост-системе и применяет книгу сценариев на гостевой системе. В этом примере он выполняет книгу сценариев с именем vagrant.yml. Провайдер Ansible Local выполняет книгу сценариев на машине Vagrant.

Дополнительную информацию см. в документации Ansible по использованию Vagrant и Ansible. Введение в Ansible для пользователей MariaDB см. в Ansible и MariaDB.

Подготовка Vagrant с Puppet

Чтобы подготовить машину или коробку Vagrant с помощью Puppet:

Vagrant.configure("2") do |config|
  ...
  config.vm.provision "puppet" do |puppet|
    puppet.manifests_path = "manifests"
    puppet.manifest_file = "default.pp"
  end
end

В этом примере Puppet Apply выполняется на хост-системе, и сервер Puppet не требуется. Puppet ожидает найти каталог manifests в каталоге проекта. Он ожидает, что он будет содержать default.pp, который будет использоваться в качестве точки входа. Обратите внимание, что puppet.manifests_path и puppet.manifest_file установлены по умолчанию.

Puppet необходимо установить на гостевой машине.

Для использования сервера Puppet можно использовать провайдер puppet_server.

Vagrant.configure("2") do |config|
  ...
  config.vm.provision "puppet_server" do |puppet|
    puppet.puppet_server = "puppet.example.com"
  end
end

См. провайдер Puppet Apply и провайдер Puppet Agent.

Введение в Puppet для пользователей MariaDB см. в Puppet и MariaDB.

Обмен файлами между хост- и гостевой системой

Для восстановления резервной копии в MariaDB в большинстве случаев необходимо скопировать ее с хост-системы на коробку. Также может потребоваться периодически копировать логи MariaDB с коробки на хост-систему для исследования проблем.

Каталог проекта (который содержит Vagrantfile) по умолчанию совмещается с виртуальной машиной и отображается в каталоге /vagrant (синхронизированная папка). Рекомендуется помещать туда все файлы, которые должны быть доступны на коробке при ее запуске. Эти файлы обычно должны быть под версионированием.

Синхронизированную папку можно изменить. В приведенном выше примере мы могли бы просто добавить одну строку:

config.vm.synced_folder "/host/path", "/guest/path"

Синхронизированную папку также можно отключить:

config.vm.synced_folder '.', '/vagrant', disabled: true

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

Сеть

Часто желательно, чтобы машина могла взаимодействовать с «внешним миром». Это можно сделать несколькими способами:

• Приватные сети;
• Публичные сети;
• Открытие портов на хост.

Запомните, что Vagrant не создает машины, а просит провайдер создать машины. Некоторые провайдеры поддерживают все эти методы связи, другие могут поддерживать некоторые из них или даже ни одного. Когда вы создаете Vagrantfile, который запускает машины с использованием этих функций, подразумевается, что это возможно только в том случае, если используемый провайдер поддерживает необходимые функции. Обратитесь к документации вашего провайдера, чтобы узнать, какие функции он поддерживает.

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

Приватные сети

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

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

Следующая строка показывает, как создать или присоединиться к приватной сети с именем «example», где IP-адрес этой машины назначается провайдером через DHCP:

config.vm.network 'private_network', name: 'example', type: 'dhcp'

Хотя это очень удобно для предотвращения конфликтов IP-адресов, иногда вы предпочитаете вручную назначать IP-адреса таким образом:

config.vm.network 'private_network', name: 'example', ip: '111.222.111.222'

Публичные сети

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

Чтобы позволить машине присоединиться к публичной сети:

# use provisioner DHCP:
config.vm.network "public_network", use_dhcp_assigned_default_route: true

# assign ip manually:
config.vm.network "public_network", ip: "111.222.111.222"

Для повышения безопасности, вы можете настроить шлюз:

config.vm.provision "shell", run: "always", inline: "route add default gw 111.222.111.222"

Настройка портов

Vagrant позволяет нам сопоставлять порт TCP или UDP в гостевой системе с портом TCP или UDP в хост-системе. Например, вы можете сопоставить порт виртуальной машины 3306 с портом хоста 12345. Затем вы можете подключиться к MariaDB таким образом:

mariadb -hlocalhost -P12345 -u<user> -p<password>

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

Существует несколько нюансов:

• Вы не можете сопоставить один порт хоста с несколькими гостевыми портами. Если вы хотите экспонировать порт 3306 из нескольких машин Vagrant, вам нужно будет сопоставить их с разными портами хоста. При запуске многих машин это может быть трудно поддерживать.
• Порты с номерами ниже 1024 являются привилегированными портами. Сопоставление привилегированных портов требует привилегий root.

Для экспонирования порта:

config.vm.network 'forwarded_port', guest: 3306, host: 3306

Примеры использования

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

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

Вы даже можете реализовать разные частные сети, чтобы создать среду, отражающую сложность производства. Возможно, в производстве у вас есть кластер из трех серверов MariaDB, а серверы приложений общаются с ними через прокси-слой (ProxySQL, HAProxy или MaxScale). Таким образом, приложения могут общаться с прокси, но не имеют способа напрямую обратиться к MariaDB. Итак, есть частная сеть под названием «база данных», к которой имеют доступ серверы MariaDB и прокси-серверы, и другая частная сеть под названием «приложение», к которой имеют доступ прокси-серверы и серверы приложений. Это требует, чтобы ваш провайдер поддерживал несколько частных сетей.

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

Ссылки

Репозиторий vagrant-mariadb-examples — пример Vagrantfile, который создает контейнер с MariaDB и некоторыми полезными инструментами для разработчиков.

Дополнительную информацию можно найти в документации Vagrant.

• Vagrantfile.
• Провайдеры.
• Синхронизированные папки.
• Провайдер Ansible.
• Провайдер Puppet Apply.
• Провайдер Puppet Agent.

См. также документацию Ruby.

Контент первоначально предоставлен компанией Vettabase Ltd.