kdevops_vagrant

kdevops_vagrant — это роль ansible, которая развертывает общий файл Vagrant kdevops в вашем проекте. Эта роль ansible копирует Vagrantfile в каталог пространства имен проекта и может по желанию запустить vagrant для вас.

Цель этой роли ansible — упростить обмен одинаковыми масштабируемыми Vagrantfile между проектами и предоставить Vagrantfile место, где участники могут его развивать и документировать.

Каталог пространства имен проекта

Каталог пространства имен проекта — это верхний уровень каталога вашего проекта, который определяет ваш проект. Например, если у вас есть проект разработки под названием kdevops, и все файлы для него хранятся в:

/home/user/devel/kdevops/

В этом случае каталог пространства имен проекта — это kdevops. По умолчанию эта роль ansible определяет ваш каталог пространства имен проекта, используя имя каталога, в котором хранится файл вашего playbook, который вызывает эту роль. Например, если ваш файл playbook хранится в:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes.yml

Вы можете переопределить данные в другом файле:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

Каталог, в котором хранится ваш файл playbook, это:

/home/user/devel/kdevops/playbooks/

Имя этого каталога — это:

/home/user/devel/kdevops/

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

Пространство имен проекта

Пространство имен проекта используется в Vagrantfile, который поставляется с этой ролью, чтобы позволить вам переопределить значения по умолчанию, используемые для vagrant, через переменные окружения. Пространство имен проекта определяется из описанного выше каталога пространства имен проекта. Например, в приведенном выше случае, где каталог проекта — это:

/home/user/devel/kdevops/

Пространство имен проекта будет определено как kdevops. Заглавная версия используется как префикс для переменных окружения, то есть KDEVOPS. Дефисы заменяются на подчеркивания, так как переменные среды не могут содержать дефисы. Так, если каталог проекта был бы:

/home/user/devel/some-cool-project/

То пространство имен проекта было бы: SOME_COOL_PROJECT.

Требования

У вас должен быть установлен vagrant.

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

• Virtualbox
• libvirt (KVM)

Поддерживаемые операционные системы:

• OS X
• Linux

Запуск libvirt от имени обычного пользователя

Мы используем роль ansible https://github.com/mcgrof/libvirt-user для предоставления возможности обычному пользователю. Ознакомьтесь с документацией там для получения подробностей.

Переопределение конфигурации узла с помощью другого файла

Лучший способ поддержать переопределение переменных, используемых в vagrant, это файл $(project)_node_override.yaml. Например, для [https://github.com/mcgrof/kdevops](проекта kdevops) вы можете переопределить данные в необязательном файле, который хранится вне git:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

Переменные окружения

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

Переменные окружения префиксируются заглавной версией пространства имен проекта, как описано выше. Давайте будем называть это ${PN_U}. Учитывая этот префикс, следующие переменные окружения изменяют способ работы Vagrantfile:

• ${PN_U}_VAGRANT_NODE_CONFIG: позволяет переопределить используемый файл конфигурации по умолчанию
• ${PN_U}_VAGRANT_PROVIDER: позволяет переопределить провайдер, используемый vagrant
• ${PN_U}_VAGRANT_LIMIT_BOXES: позволяет включить ограничение на количество коробок
• ${PN_U}_VAGRANT_LIMIT_NUM_BOXES: количество коробок для ограничения
• ${PN_U}_VAGRANT_QEMU_GROUP: переопределяет используемого пользователя qemu

Ограничение количества коробок vagrant

По умолчанию vagrant будет пытаться создать все узлы, указанные в вашем файле конфигурации узлов. Обычно это ${PN_L}_nodes.yml, где $PN_L — это строчная версия пространства имен вашего проекта, описанного выше. Например, для проекта kdevops это будет kdevops_nodes.yml.

Если вы хотите ограничить vagrant только на создание одной коробки в проекте kdevops, вы можете использовать:

export KDEVOPS_VAGRANT_LIMIT_BOXES="yes"
export KDEVOPS_VAGRANT_LIMIT_NUM_BOXES=1

Очевидно, вам следует использовать другой префикс для проектов с другими именами.

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

Объем использования ansible

kdevops как целое предназначен быть нейтральным к тому, как вы настраиваете систему, будь то виртуализированная локальная система с libvirt / Virtualbox, использование системы без посредников или облачной среды.

Поэтому существуют 3 этапа для развертывания:

• Развертывание: виртуальная / облачная / без посредников
• Настройка и установка зависимостей: добавление систем в ~/.ssh/config и установка предпочитаемых скриптов bash пользователя, .gitconfig и пакетов для разработки по выбору. Это осуществляется через роли ansible http://github.com/mcgrof/update_ssh_config_vagrant и http://github.com/mcgrof/devconfig.
• Действие: выполните свою работу, это обычно сейчас поощряется через ansible.

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

• http://github.com/mcgrof/update_ssh_config_vagrant
• http://github.com/mcgrof/devconfig

Мы сознательно не хотим расширять эту практику, и причина в том, что мы хотим, чтобы пользователи напрямую использовали ansible для последующих целей. Работа по развертыванию и настройке, установке зависимостей для разработчиков должна обрабатываться либо vagrant, terraform, либо пользователем, который настраивает системы без посредников вручную.

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

Интерпретатор Python ansible

Ansible зависит от Python на удаленных системах. Какая версия Python должна использоваться, может варьироваться, но по умолчанию ansible будет пытаться использовать старую версию интерпретатора Python, чтобы поддерживать более старые системы. Это решение не лучшее для новых систем, поэтому вам рекомендуется указывать интерпретатор. Это лучше всего настраивать в файле инвентаризации. Vagrantfile предполагает наличие файла инвентаризации с именем ../hosts, но вы можете переопределить это в конфигурации ansible следующим образом:

ansible_playbooks:
  # Если этот файл существует, вы можете переопределить любые переменные ansible там.
  # Этот файл не обязателен.
  extra_vars: "../extra_vars.yml"
  inventory: "../hosts"
  playbooks:
    - name: "../playbooks/update_ssh_config_vagrant.yml"
    - name: "../playbooks/devconfig.yml"

Ваш файл hosts может выглядеть примерно так:

[all]
newsystem1
oldsystem1
[all:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[new]
newsystem1
[new:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[old]
oldsystem1
[dev:vars]
ansible_python_interpreter =  "/usr/bin/python2"

В этом случае для группы [all] интерпретатор Python будет установлен на python3, однако последняя запись обеспечит, что старая система будет использовать python2.

Использование дополнительных переменных ansible с vagrant

Ansible имеет свою иерархию того, как переменные имеют приоритет, через либо командную строку, либо файлы роли и т. д., что документируется на [https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html](страница документации переменных playbooks ansible).

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

Поскольку kdevops состоит из единого набора ролей ansible, мы поддерживаем унифицированный способ определения переопределений для ansible. Мы делаем это, позволяя пользователю переопределять переменные ansible в корневом каталоге проекта в файле, который называется:

• extra_vars.yml

Таким образом, в проекте kdevops это будет:

/home/user/devel/kdevops/extra_vars.yml

Когда этот файл установлен, плагин vagrant ansible обеспечит передачу только этого файла ansible напрямую в командной строке через --extra-vars=@file. Префикс @ обязательный при указании файла. Вы не обязаны указывать @, мы сделаем это за вас.

Все роли ansible, используемые с kdevops, поддерживают поиск этого файла extra_vars.

Переменные роли ansible

• run_vagrant: по умолчанию равна False, если установлена в True, мы запустим Vagrant за вас.
• force_project_dir: если указано, это будет использовано как каталог, в котором мы будем искать каталог vagrant, и в конечном итоге копировать Vagrantfile. По умолчанию это установлено в пустое значение, и мы определяем ваш каталог проекта как родительский каталог, в котором находился файл playbook.

Зависимости

Нет.

Пример Playbook

Ниже приведен пример playbook, он используется в проекте kdevops, файл kdevops/playbooks/kdevops_vagrant.yml:

---
- hosts: localhost
  roles:
    - role: kdevops_vagrant

В этом конкретном случае обратите внимание, как используется localhost. Это потому, что мы подготавливаем Vagrantfile в каталоге kdevops/vagrant/ локально. Вы можете, конечно, использовать другой хост.

Дополнительная информация

Для дальнейших примеров обратитесь к одному из пользователей этой роли, проекту https://github.com/mcgrof/kdevops или проекту https://github.com/mcgrof/oscheck, откуда исходный код был взят.

Лицензия

GPLv2