Как применить роль ansible к виртуальной машине

Руководство. Создание масштабируемого набора виртуальной машины или виртуальной машины из Общая коллекция образов Azure с помощью Ansible

Для выполнения примеров сборников схем из этой статьи требуется Ansible 2.9 (или последующей версии).

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

Вы узнаете, как выполнять следующие задачи:

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

Необходимые компоненты

Подписка Azure. Если у вас нет подписки Azure, создайте бесплатную учетную запись, прежде чем начинать работу.

Установите Ansible: выполните одно из указанных ниже действий.

Установите и настройте Ansible на виртуальной машине Linux.
Настройте Azure Cloud Shell и, если у вас нет доступа к виртуальной машине Linux, вы можете создать ее с помощью Ansible.

Получение примера сборников схем

Существует два способа получения полного набора с примерами сборников схем:

Скачайте папку SIG и сохраните ее на локальном компьютере.
Создайте файл для каждого раздела и скопируйте в него пример сборника схем.

Файл vars.yml содержит переменные, используемые всеми примерами сборника схем для этого учебника. Вы можете изменить файл, чтобы предоставить уникальные имена и значения.

Первый пример сборника схем 00-prerequisites.yml создает все необходимое для работы с этим учебником:

группу ресурсов, которая является логическим контейнером, где происходит развертывание ресурсов Azure и управление ими;
виртуальную сеть, подсеть, общедоступный IP-адрес и сетевую карту для виртуальной машины;
исходную виртуальную машину, используемую для создания универсального образа.

- hosts: localhost connection: local vars_files: - ./vars.yml tasks: - name: Create resource group if doesn't exist azure_rm_resourcegroup: name: ">" location: ">" - name: Create virtual network azure_rm_virtualnetwork: resource_group: ">" name: ">" address_prefixes: "10.0.0.0/16" - name: Add subnet azure_rm_subnet: resource_group: ">" name: ">" address_prefix: "10.0.1.0/24" virtual_network: ">" - name: Create public IP address azure_rm_publicipaddress: resource_group: ">" allocation_method: Static name: ">" - name: Create virtual network inteface cards for VM A and B azure_rm_networkinterface: resource_group: ">" name: ">" virtual_network: ">" subnet: ">" - name: Create VM azure_rm_virtualmachine: resource_group: ">" name: ">" admin_username: testuser admin_password: "Password1234!" vm_size: Standard_B1ms network_interfaces: ">" image: offer: UbuntuServer publisher: Canonical sku: 16.04-LTS version: latest

Запустите сборник схем с помощью команды ansible-playbook.

ansible-playbook 00-prerequisites.yml

На портале Azure проверьте группу ресурсов, которую вы указали в vars.yml , чтобы просмотреть созданную виртуальную машину и различные ресурсы.

Подготовка виртуальной машины и создание пользовательского образа

Следующий сборник схем 01a-create-generalized-image.yml обобщает исходную виртуальную машину, созданную на предыдущем шаге, а затем создает на ее основе пользовательский образ.

- hosts: localhost connection: local vars_files: - ./vars.yml tasks: - name: Generalize VM azure_rm_virtualmachine: resource_group: ">" name: ">" generalized: yes - name: Create custom image azure_rm_image: resource_group: ">" name: ">" source: ">"

Запустите сборник схем с помощью команды ansible-playbook.

ansible-playbook 01a-create-generalized-image.yml

Проверьте группу ресурсов и убедитесь, что testimagea отображается.

Создание Общей коллекции образов

Коллекция образов — это репозиторий для совместного использования образов и управления ими. Код из примера сборника схем в 02-create-shared-image-gallery.yml создает Общую коллекцию образов в группе ресурсов.

- hosts: localhost connection: local vars_files: - ./vars.yml tasks: - name: Create shared image gallery azure_rm_gallery: resource_group: ">" name: ">" location: ">" description: This is the gallery description.

Запустите сборник схем с помощью команды ansible-playbook.

ansible-playbook 02-create-shared-image-gallery.yml

Теперь в группе ресурсов можно увидеть новую коллекцию myGallery .

Создание общего образа и версии образа.

Следующий сборник схем 03a-create-shared-image-generalized.yml создает определение и версию образа.

Определение образа включает в себя: тип образа (Windows или Linux), заметки о выпуске, а также минимальные и максимальные требования к памяти. Версия образа — это версия этого образа. Коллекция, определение образа и версия образа помогают упорядочить образы в логические группы.

- hosts: localhost connection: local vars_files: - ./vars.yml tasks: - name: Create shared image azure_rm_galleryimage: resource_group: ">" gallery_name: ">" name: ">" location: ">" os_type: linux os_state: generalized identifier: publisher: myPublisherName offer: myOfferName sku: mySkuName description: Image description - name: Create or update a simple gallery image version. azure_rm_galleryimageversion: resource_group: ">" gallery_name: ">" gallery_image_name: ">" name: ">" location: ">" publishing_profile: end_of_life_date: "2020-10-01t00:00:00+00:00" exclude_from_latest: yes replica_count: 3 storage_account_type: Standard_LRS target_regions: - name: West US regional_replica_count: 1 - name: East US regional_replica_count: 2 storage_account_type: Standard_ZRS managed_image: name: ">" resource_group: ">" register: output - debug: var: output

Запустите сборник схем с помощью команды ansible-playbook.

ansible-playbook 03a-create-shared-image-generalized.yml

Теперь группа ресурсов содержит определение и версию образа для коллекции.

Создание виртуальной машины на основе универсального образа

Наконец, запустите 04a-create-vm-using-generalized-image.yml , чтобы создать виртуальную машину на основе универсального образа, созданного на предыдущем шаге.

- hosts: localhost connection: local vars_files: - ./vars.yml tasks: - name: Create VM using shared image azure_rm_virtualmachine: resource_group: ">" name: ">" vm_size: Standard_DS1_v2 admin_username: adminUser admin_password: PassWord01 managed_disk_type: Standard_LRS image: id: "/subscriptions/>/resourceGroups/>/providers/Microsoft.Compute/galleries/>/images/>/versions/>"

Запустите сборник схем с помощью команды ansible-playbook.

ansible-playbook 04a-create-vm-using-generalized-image.yml

Создание масштабируемого набора виртуальных машин на основе универсального образа

Вы также можете создать масштабируемый набор виртуальных машин на основе универсального образа. Для этого запустите 05a-create-vmss-using-generalized-image.yml .

- hosts: localhost connection: local vars_files: - ./vars.yml tasks: - name: Create a virtual machine scale set using a shared image azure_rm_virtualmachinescaleset: resource_group: ">" name: ">" vm_size: Standard_DS1_v2 admin_username: adminUser admin_password: PassWord01 capacity: 2 virtual_network_name: ">" upgrade_policy: Manual subnet_name: ">" managed_disk_type: Standard_LRS image: id: "/subscriptions/>/resourceGroups/>/providers/Microsoft.Compute/galleries/>/images/>/versions/>"

Запустите сборник схем с помощью команды ansible-playbook.

ansible-playbook 05a-create-vmss-using-generalized-image.yml

Получение информации о коллекции

Чтобы получить сведения о коллекции, определении и версии образа, запустите 06-get-info.yml .

- hosts: localhost connection: local vars_files: - ./vars.yml tasks: - name: Get Shared Image Gallery information azure_rm_gallery_info: resource_group: ">" name: ">" - name: Get shared image information azure_rm_galleryimage_info: resource_group: ">" gallery_name: ">" name: ">" - name: Get Shared Image Gallery image version information azure_rm_galleryimageversion_info: resource_group: ">" gallery_name: ">" gallery_image_name: ">" name: ">"

Запустите сборник схем с помощью команды ansible-playbook.

ansible-playbook 06-get-info.yml

Удаление общего образа

Чтобы удалить ресурсы коллекции, обратитесь к примеру сборника схем 07-delete-gallery.yml . Удалите ресурсы в обратном порядке. Начните с удаления версии образа. После удаления всех версий образа вы можете удалить определение образа. Затем вы можете удалить коллекцию.

- hosts: localhost connection: local vars_files: - ./vars.yml tasks: - name: Delete gallery image version. azure_rm_galleryimageversion: resource_group: ">" gallery_name: ">" gallery_image_name: ">" name: ">" state: absent - name: Delete gallery image azure_rm_galleryimage: resource_group: ">" gallery_name: ">" name: ">" state: absent - name: Delete a simple gallery. azure_rm_gallery: resource_group: ">" name: ">" state: absent

Запустите сборник схем с помощью команды ansible-playbook.

ansible-playbook 07-delete-gallery.yml

Очистка ресурсов

Ansible
Azure CLI
Azure PowerShell

--- - hosts: localhost tasks: - name: Deleting resource group - ">" azure_rm_resourcegroup: name: ">" state: absent register: rg - debug: var: rg

ansible-playbook delete_rg.yml --extra-vars "name="

В связи с наличием переменной register и раздела debug в сборнике схем результаты будут отображены после завершения команды.

az group delete --name

az group show --name

Remove-AzResourceGroup -Name

Get-AzResourceGroup -Name

Демонстрация Ansible функций с контрольными и тестовыми виртуальными машинами

Я создал небольшой проект, чтобы продемонстрировать некоторые возможности Ansible, новую горячность DevOps, включая виртуальные машины Vagrant для запуска Ansible и для тестирования конфигурации. Либо идти прямо к

или продолжайте читать здесь.

У этого проекта есть три вещи, представляющие интерес:

Нетривиальная конфигурация Ansible, демонстрирующая несколько полезных функций и приемов
Виртуальная машина Vagrant / VirtualBox с Ansible & co. чтобы его было легко запустить (даже в Windows)
Еще одна виртуальная машина, которая может быть использована для проверки конфигурации

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

Отказ от ответственности: я новичок в Ansible.

Немного предыстории: Ansible и Vagrant

Ansible — это инструмент devops для настройки серверов по SSH с использованием только Python. Он похож на Puppet и Chef, но вам не нужно ничего устанавливать на серверах (по сути, каждый * nix имеет Python 2.4+ и SSH, и он даже работает со старым RHEL 5.9), конфигурация по умолчанию выталкивается из элемента управления Машина вместо того, чтобы тянуть за серверы, и она имеет сильный акцент на простоту. Он менее зрелый, чем Puppet, имеет меньше плагинов и пока не поддерживает Windows, но простота, минимальные требования и модель push являются вескими причинами для его рассмотрения.

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

Продемонстрированные особенности и хитрости

Бродяга — Ansible советы по интеграции

Установите config.ssh.forward_agent = true в, ansible-vm чтобы было проще сделать доступными ваши ключи для Ansible для SSH на удаленных компьютерах. (См. «Локальное тестирование» ниже для получения более подробной информации.)

Добавьте mount_options: [‘dmode=0775′,’fmode=0664’] для монтирования каталога с конфигурацией Ansible, чтобы файл инвентаризации не казался исполняемым для Ansible.

анзибль

Общие сведения : Используйте роли, чтобы разделить конфигурацию на отдельные задачи (jboss, vagrant), используйте переменные для обработки изменений между средами и использования роли (например, порты JBoss, jboss_host_type = master|slave , env = vagrant|staging|production ). Используйте теги для обозначения части конфигурации , так что эти части могут быть выбраны и выполнены без остатка (f.ex. jboss_module , jboss_configuration , vagrant ).

Файл секретных локальных учетных данных : в конфигурацию входят переменные из файла secret_vars.yml , который добавляется в него, .gitignore чтобы он не был зарегистрирован в Git, и каждый пользователь должен создать свою собственную локальную копию на основе secret_vars.yml.example . Таким образом, конфиденциальные учетные данные никогда не покидают локальную машину.

Повторное использование через параметризованное включение и моделирование creates для get_url . Чтобы избежать необходимости сохранять загруженные архивы, я использую, stat чтобы проверить наличие файла / каталога и while пропустить, get_url если он существует. Все дело в файле включения задачи, roles/jboss/tasks/fetch-module.yml который параметризован так, чтобы его можно было повторно использовать для извлечения и распаковки трех разных модулей — смотрите roles/jboss/tasks/modules.yml .

Несколько сред — здесь vagrant и staging через два разных файла инвентаризации.

Gotchas

Если кажется, что Ansible зависает при выполнении команды, убедитесь, что команда не пытается запросить ввод данных пользователем, как в моем случае с тем, unzip что я хотел знать, что делать с существующими файлами (исправлено, если запустить его с помощью -o принудительной перезаписи их) ,

Автоматическая настройка JBoss

Конфигурация JBoss с использованием Ansible, поэтому можно автоматически применить его к серверу. Некоторые из файлов (-> шаблоны) параметризованы переменными, которые определены для f.ex. in group_vars/appservers , файл инвентаризации хоста (f.ex. vagrant ) и secret_vars.yml .

BEWARE : Копировать secret_vars.yml.example в secret_vars.yml и установить правильные учетные данные там.

анзибль

Prerequisities

(Windows: ssh, например, из установщика Putty)
VirtualBox (например, 4.3.6)
Бродяга (например, 1.4.3)
Плагин vagrant vbguest (после установки vagrant запустите vagrant plugin install vagrant-vbguest )

Как это настроено

Виртуальная машина Vagrant / VirtualBox ansible-vm имеет установленную Ansible и может использоваться для запуска ее на тестовой виртуальной машине или в стадии подготовки. Сама тестовая ВМ centos-vm может использоваться для локального тестирования изменений перед подготовкой. Как описано выше, вам нужно будет создать secret_vars.yml с секретными учетными данными.

Под Linux / Mac вы можете установить и использовать Ansible напрямую, без ansible-vm .

Кратко о Бродяге

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

Ты должен знать:

Запуск vagrant up в centos-vm или ansible-vm для создания, настройки и запуска виртуальной машины

Запустите vagrant reload после up первого запуска , если были установлены новые гостевые дополнения

Обратите внимание, что Vagrant автоматически совместно использует каталог vm как /vagrant с виртуальной машиной (и мы также предоставляем этот каталог как /Infrastructure ) и может перенаправлять порты с гостевой виртуальной машины на хост, чтобы вы могли получить доступ к службам, работающим на виртуальной машине, через locahost: которые мы часто используем centos-vm .

Структура конфигурации

Большая часть конфига находится внутри «ролей», таких как «jboss» и «vagrant», см. ./roles/ Каталог.

использование

Тестирование локально

Используйте тест CentOS VM. Чтобы разрешить выполнение ansible без пароля на тестовой ВМ, рекомендуется использовать ssh-agent, добавив к нему ключ vagrant через ssh-add ~/.vagrant.d/insecure_private_key .

Windows: используйте Git Bash и включите ssh-agent, как описано в справке GitHub, добавив в него строку ssh-add ~/.vagrant.d/insecure_private_key . Используйте тот же Bash (?) , Чтобы запустить vagrant up под ansible-vm .

Также можно запустить ansible с помощью —ask-pass или -k , пароль «vagrant».

Запустите тест centos-vm — перейдите в каталог и запустите vagrant up
Выполнить ansible-vm — перейти в каталог и запустить, vagrant up а затем vagrant ssh
В Ansible VM запустите cd /Infrastructure и запустите f.ex. ansible-playbook -vi vagrant site.yml

Примечание. ansible-vm Настройка предполагает, что IP-адрес хост-машины, видимый с виртуальной машины, равен 10.0.2.2 (протестируйте с помощью f.ex. route )

Прогон, репетиция

Ansible может попытаться предсказать некоторые изменения, которые он должен будет сделать:

 ansible-playbook -vi staging site.yml -u [--ask-sudo-pass] --check --diff

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

Внутри Infrastructure/ каталога запустите:

ansible-playbook -vi staging site.yml -u [--ask-pass] [--ask-sudo-pass] [--tags ] [--private-key=key file]

Ansible будет ssh как предоставленный пользователь для компьютеров, перечисленных в промежуточном файле («-u jakub» => «ssh jakub @ app (1 | 2) .staging.example.com»)
—ask-pass необходимо, если ssh запрашивает пароль, т.е. если вы не настроили ssh без пароля
—ask-sudo-pass (или -K ) необходимо, если ваш пользователь не имеет доступа sudo без пароля на сервере
Вы можете использовать —tags для выполнения только подмножество задач (при условии, что они были помечены); напр .: —tags newrelic,jboss_module,jboss_configuration

Глава 5. Применение Ansible для создания шаблонов виртуальных машин развёртывания

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

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

В этой главе будут рассмотрены следующие вопросы:

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

Технические требования

Данная глава предполагает что у вас имеется доступ к среде с возможностями виртуализации, запущенной под Ubuntu 18.04 LTS. Некоторые примеры также выполняются в CentOS 7. В любом из этих случаев все примеры могут выполняться либо в некой физической машине (или ноутбуке) с запущенной одной из упомянутых выше операционных систем, процедурой, которая обладает включёнными расширения виртуализации, либо в некой виртуальной машине с включённой встроенной виртуализацией.

Позднее в этой главе также применяется Ansible 2.8 и предполагается что вы уже имеете его установленным на применявшемся нами хосте.

Все обсуждаемые в этой книге примеры доступны в GitHub.

Выполнение первоначального построения

Как уже обсуждалось в Главе 4, Методологии развёртывания, будете ли вы применять традиционные платформы виртуализации, такие как Virt или VMware, либо основанный на таких облачных решениях как OpenStack или EC2 Amazon, вашей отправной точкой для любых развёртываний Linux (а следовательно и последующей автоматизации) будет некий образ шаблона.

В определённых нами в Главе 1, Построение стандартной среды работы в Linux терминах SOE, такой образ шаблона является достаточно действенным её проявлением. Обычно это некий небольшой образ виртуальной машины с программным обеспечением достаточным только для установки и выполнения настройки, который полезен почти во всех случаях развёртывания в рамках определённого предприятия. При условии что такой образ загружается чистым с неким уникальным именем хоста, ключи SSH хоста и тому подобное могут быть настроены почти сразу же с применением последующей автоматизации, как мы узнаем это из Главы 7, Управление настройками при помощи Ansible позднее в этой книге. Давайте окунёмся в сам процесс сборки, взяв за основу в качестве своей отправной точки готовый образ шаблона (предоставляемый сторонним разработчиком).

Применение готовых шаблонов образов

Для большинства платформ имеются готовыми большое число доступных для выгруки вами образов, и опять же, некоторые из них мы обсуждали в своих предыдущих главах. Для многих предприятий таких образов может быть достаточно. Тем не менее, что если вам требуется абсолютно полный контроль над определяемыми вами образами? Возможно, вы уже приспособились к новому стандарту (на момент написания этих строк бы выпущен Red Hat Enterprise Linux 8 и несомненно вскорости последует CentOS 8), и вы желаете реализовать его на ранней стадии чтобы получить опыт и проверить на рабочих нагрузках. Что если вы работаете в защищённой среде (возможно, отвечающей требованиям отрасли платёжных карт) и вам абсолютно необходимо обладать уверенностью в том как был собран ваш образ и не может быть никакого риска его компрометации?

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

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

Давайте рассмотрим некий практический пример: допустим, что для некого нового набора подразделений мы приняли решение создать некую новую SOE на основании образа сервера Fedora 30 и будем запускать его в некой инфраструктуре OpenStack:

Мы бы выгрузили необходимый образ облачного решения с официального веб сайта проекта Fedora — подробности можно найти тут, хотя сам номер версии мог измениться со временем, поскольку появился новый выпуск Fedora https://alt.fedoraproject.org/cloud// Установив верный для нашей среды облачный образ Fedora мы можем выгрузить требуемый нам образ при помощи подобной такой команды:

 $ wget https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-30-1.2.x86_64.qcow2

 $ curl https://getfedora.org/static/fedora.gpg | gpg --import

 $ wget https://alt.fedoraproject.org/en/static/checksums/Fedora-Cloud-30-1.2-x86_64-CHECKSUM $ gpg --verify-files *-CHECKSUM

Рисунок 5-1

 $ sha256sum -c *-CHECKSUM

Вы получите ошибки для всех не выгруженных вами файлов из файла *-CHECKSUM , но как вы можете обнаружить на следующем снимке экрана, выгруженный нами образ имеет соответствующую контрольную сумму и мы можем продолжать его применение:

Рисунок 5-2

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

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

Что если вам абсолютно необходимо создать собственный образ? Мы рассмотрим это в следующем разделе данной главы.

Создание ваших собственных образов виртуальных машин

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

Давайте рассмотрим сборку образа виртуальной машины CentOS 7.6 при помощи хоста сервера Ubuntu 18.04:

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

Совет

Когда для осуществления вложенной виртуализации вы пользуетесь гипервизором Vmware, вам потребуется включить поддержку code profiling (профилирования кода) для своего ЦПУ, а также включить hypervisor applications (приложения гипервизора) — иначе в этом процессе некоторые шаги могут завершиться отказом.

 $ sudo apt-get install libvirt-bin libvirt-doc libvirt-clients virtinst libguestfs-tools libosinfo-bin $ sudo gpasswd -a libvirt $ sudo gpasswd -a kvm $ logout

 $ wget http://vault.centos.org/7.6.1810/isos/x86_64/CentOS-7-x86_64-Minimal-1810.iso

Разложив это всё по своим местам, вы теперь создадите пустой дисковый образ виртуальной машины. Наилучшим форматом для этого является QCOW2 ( Quick Copy On Write ), совместимый с OpenStack и большинством облачных платформ. тем самым мы сделаем этот образ как можно более универсальным чтобы обеспечить максимально допустимую поддержку.

Для создания некого чистого образа QCOW2 с 20ГБ в своём текущем каталоге нам придётся выполнить такую команду:

 $ qemu-img create -f qcow2 centos76-soe.qcow2 20G

Обратите внимание, что доступны и прочие форматы образа. Например, если вы желаете выполнять сборку исключительно для VMware, вместо этого может оказаться более удобным применение VMDK:

 $ qemu-img create -f vmdk centos76-soe.vmdk 20G

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

Рисунок 5-3

После создания пустых образов диска приходит время установки соответствующего образа ВМ:

Для достижения этого мы воспользуемся командой virt-install , которая в целом запускает некую временную ВМ для установки ОС. Не беспокойтесь о таких параметрах как ЦПУ и память — раз их достаточно для запуска и установки ОС, всё будет нормально — они не имеют никакого отношенря к развёрнутой виртуальной машине.

Совет

Обратите внимание на параметр VNC —graphics vnc,listen=0.0.0.0 — мы будем применять его для удалённого управления своей виртуальной машиной и завершения своей установки. Вы можете выбрать и другой вариант графики, например, если вы его предпочитаете, SPICE.

 $ virt-install --virt-type kvm \ --name centos-76-soe \ --ram 1024 \ --cdrom=CentOS-7-x86_64-Minimal-1810.iso \ --disk path=/home/james/centos76-soe.qcow2,size=20,format=qcow2 \ --network network=default \ --graphics vnc,listen=0.0.0.0 \ --noautoconsole \ --os-type=linux \ --os-variant=centos7.0 \ --wait=-1

Большинство параметров поясняют себя самостоятельно, но обратите особое внимание на свою среду. Например, если вы измените или удалите свою сетевую среду default , наша предыдущая команда завершится неудачей. Аналогично убедитесь что все пути ссылаются на верные места.

	Совет
	Чтобы просмотреть полный перечень поддерживаемых параметров —os-variant запустите команду os-infoquery os .

Рисунок 5-4

 $ virt-viewer centos-76-soe

С этого момента вы устанавливаете свою операционную систему обычным способом. Как мы уже обсуждали в Главе 4, Методологии развёртывания, попытайтесь проследовать наиболее минимальную установку, какую только сможете выполнить. Не беспокойтесь слишком сильно об имене хоста по сути, так как это будет позднее частью самого процесса развёртывания; определите следующее:

Выберите наиболее подходящие для вашего местоположения KEYBOARD и LANGUAGE SUPPORT .
Выберите настройки DATE & TIME для своей страны.
Убедитесь что SOFTWARE SELECTION установлены в Minimal Install (это настройка по умолчанию).
Установите INSTALLATION DESTINATION — бедет иметься подключённым к данной ВМ лишь один виртуальный жёсткий диск при использовании нашей предыдущей команды virt-install , поэтому это просто средство его выбора.
Включите или отключите KDUMP в зависимости от ситуации.
Убедитесь что сетевая среда включена в NETWORK & HOST NAME .

Получаемый в результате экран настроек установки CentOS 7 должен выглядеть похожим на приводимый ниже снимок экрана:

Рисунок 5-5

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

Когда ваша ВМ перезагрузится после своей первоначальной установки, вы сможете обнаружить что она остановлена. Если это так, вам придётся отменить её определение при помощи утилиты virsh , а затем запустить его снова слегка изменив свою предыдущую команду virt-install , сообщая virt-install о необходимости загрузки на этот раз с имеющегося образа жёсткого диска вместо CD:

 $ virsh undefine centos-76-soe $ virt-install --virt-type kvm \ --name centos-76-soe \ --ram 1024 \ --disk path=/home/james/centos76-soe.qcow2,size=20,format=qcow2 \ --network network=default \ --graphics vnc,listen=0.0.0.0 \ --noautoconsole \ --os-type=linux \ --os-variant=centos7.0 \ --boot=hd

На данном этапе следует заметить, что большинство облачных платформ, будь то OpenStack, AWS ( Amazon Web Services ) или нечто иное, все они пользуются утилитой virt-install для осуществления начальных настроек создаваемого образа виртуальной машины прежде чем мы остановим её. Ниже перечисляются команды, необходимые для установки вручную и в своём следующем разделе мы превратим их в некую роль Ansible для установки:

 $ yum -y install epel-release $ yum -y install cloud-init cloud-utils-growpart dracut-modules-growroot

После того как вы успешно выполнили эти команды, вам по всей видимости придётся персонализировать /etc/cloud/cloud.cfg для настройки cloud-init под ту среду, в которой вы её применяете, хотя устанавливаемые по умолчанию настройки являются достойным отправным пунктом для многих сред.

Настройка cloud-init оставлена вам в качестве вашего самостоятельного упражнения, принимая во внимание широкое разнообразие платформ..

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

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

Данный процесс подготовки системы состоит в приведении некого образа в состояние готовности для его масштабного развёртывания. Следовательно, будут стёрты все уникальные параметры идентификации, чтобы создать некий чистый образ для масштабного развёртывания, а именно, такие как:

Ключи хоста SSH
Файлы истории
Настройки локального сеанса
Файлы журналов
Ссылки на MAC адреса в сетевых настройках

Наш предыдущий перечень не является исчерпывающим — существует множество элементов для очистки чтобы образ можно было бы рассматривать как действительно чистый и готовый к развёртыванию, а для объяснения этого потребуется целая глава. К нашему счастью, в наборе инструментов KVM есть две команды, выполняющие именно это:

 $ sudo virt-sysprep -a centos76-soe.qcow2 $ sudo virt-sparsify --compress centos76-soe.qcow2 centos76-soe-final.qcow2

Хотя вывод первой из приведённых команд слишком длинный чтобы уместиться в одном снимке экрана, он отображает широкий спектр задач, которые считаются необходимыми в рамках sysprep и когда вы выполняете это вручную или при помощи Ansible, данная утилита virt-sysprep снабдит вас хорошим пособием относительно задач, которые вам следует осуществлять:

Рисунок 5-6

Наконец, мы повторно разбираем образ своего диска, действенно сжимая его под эффективное сохранение. Обратите внимание, что если вы получаете какие- то предупреждения о свободном пространстве при выполнении данного инструмента (по умолчанию требуется большое пространство в /tmp — точный объём будет определяться размером образа вашего виртуального диска), вам, как правило, не следует это игнорировать, ибо имеется вероятность что данная утилита заполнит ваш раздел, а следовательно помешает правильному ходу сборки вашего хоста:

Рисунок 5-7

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

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

Применение Ansible для построения и стандартизации конкретного шаблона

На данный момент вы должны обладать базовым образом Linux для развёртывания в своём предприятии. Если вы выбрали выгрузку готового к применению шаблона (или, на самом деле, остановились на применении предоставляемого поставщиком общедоступного облака), тогда ваш образ будет очень пустым шаблоном, готовым для индивидуальных настроек. Если вы решили создать свой собственный, то, вероятно, вы уже выбрали выполнение небольшого числа персональных настроек, как выполненная нами ранее настройка cloud-init . Вы заметили, тем не менее, что мы сделали это вручную, что едва ли соответствует линии масштабируемых, повторяемых процессов, которые мы нахваливали в своих более ранних частях этой книги. Проходя данный раздел этой главы мы рассмотрим как при помощи Ansible выполнить индивидуальные настройки базового шаблона, причём вне зависимости от его происхождения.

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

Перемещение файлов в соответствующий образ
Установка пакетов
Изменение файлов настройки
Проверка полученного образа

Проходя сочетание этих примеров большинство читателей должна быть запросто способной индивидуально настроить свои собственные образы под свои требования. Давайте начнём изучать их более углублённо с рассмотрения того как передавать файлы в ранее созданный нами образ виртуальной машины с применением Ansible.

Передача файлов в заданный образ

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

Мы уже обладаем своим выгруженным/ собранным шаблоном Linux, как это было выведено в нашем предыдущем разделе данной главы.
Мы запускаем этот голый шаблон в некой виртуальной машине.
IP адресом этой виртуальной машины выступает 192.168.81.141 .
Наша виртуальная машина имеет уже настроенную учётную запись пользователя со следующими учётными сведениями:

Имя пользователя: imagebuild .
Пароль: password .
В этой учётной записи включена возможность sudo .

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

В своём примере мы создадим некий файл описи, который выглядит подобно приводимому — несомненно ваш будет другим и внесите в него персональную правку для своих образа и среды, оставляя его вам в качестве образца:

 [imagesetup] 192.168.81.141 [imagesetup:vars] ansible_user=imagebuild ansible_password=password ansible_sudo_pass=password

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

Совет

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

 $ mkdir -p roles/filecopyexample/tasks $ mkdir -p roles/filecopyexample/files

 ------------------------ Enteprise Linux Template Created with Ansible ------------------------

 pool ntp.example.com iburst maxsources 4 keyfile /etc/chrony/chrony.keys driftfile /var/lib/chrony/chrony.drift logdir /var/log/chrony maxupdateskew 100.0 rtcsync makestep 1 3

Мы намерены повсеместно копировать эти два файла на все свои удалённые серверы. Тем не менее Ansible не ограничен копирование файлов с определённого хоста Ansible — он также способен выгружать файлы с удалённого сервера напрямую в свой целевой хост:

Давайте предположим, что вашей сборке потребуется docker-compose — мы можем выгрузите его с некого внутреннего сервера или даже напрямую через Интернет когда ваша машина образа обладает таким доступом в Интернет. Допустим, мы желаем установить в свои образы docker-compose 1.18.0, тогда мы можем выдать Ansible инструкции для его выгрузки напрямую с https://github.com/docker/compose/releases/download/1.18.0/docker-compose-Linux-x86_64.
Теперь давайте соберём свою роль для повсеместного копирования двух файлов и выгрузки в свой образ docker-compose — её следует записать в roles/filecopyexample/tasks/main.yml . Самая первая часть данной роли показана в приводимом далее коде, и он служит обсуждавшееся ранее повсеместное копирование двух файлов настройки:

 --- - name: Copy new MOTD file, and backup any existing file if it exists copy: src: files/motd dest: /etc/motd owner: root group: root mode: '0644' backup: yes - name: Copy across new chrony configuration, and backup any existing file if it exists copy: src: files/chrony.conf dest: /etc/chrony.conf owner: root group: root mode: '0644' backup: yes

Эта роль далее продолжается задачей установки docker-compose в соответствующем образе ВМ:

 - name: Install docker-compose 1.18.0 get_url: url: https://github.com/docker/compose/releases/download/1.18.0/docker-compose-Linux-x86_64 dest: /usr/local/bin/docker-compose mode: 0755 owner: root group: root

Итак, наша роль теперь закончена, однако убедитесь что вы верно выполнили персональные настройки для своей среды. Например, скорее всего может быть доступной более новая версия docker-compose , а это означает изменение установленного параметра url нашего предыдущего модуля get_url .

Совет

Значение пути файла настроек chrony может изменяться в зависимости от вашей операционной системы — проверьте их перед выполнением предыдущего плейбука. Тот путь, что указан в нашем примере подходит для систем CentOS 7, подобным собранной нами ранее.

 --- - name: Run example roles hosts: all become: yes roles: - filecopyexample

Рисунок 5-8

Как мы можем увидеть, значение changed состояний сообщает нам что все наши три файла были переданы или выгружены успешно и посредством данного примера мы можем видеть что теперь имеется возможность запуска docker-compose , который был установлен в ходе исполнения этого плейбука (хотя для этого и потребуется корректная работа Docker, который мы не установили в качестве части данного примера).

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

Установка пакетов

В своём предыдущем разделе мы рассмотрели ка установить обособленные исполняемые файлы подобные docker-compose — но что если нам требуется на практике установить некие дополнительные пакеты операционной системы, которые не были установлены в нашем базовом образе? К примеру, в большинстве облачных сред невероятно полезен cloud-init , однако он не содержится в нашей минимальной установке CentOS, который мы выполнили ранее.

Издесь опять на помощь может прийти Ansible — на этот раз мы определим некую роль для установки требующихся нам пакетов. Мы повторно воспользуемся своим файлом описи из нашего предыдущего раздела и создадим новую роль с названием packageinstall аналогично тому как мы это делали ранее:

Теперь наш предыдущий образец копирования файлов будет работать во всех дистрибутивах Linux — единственное о чём нам следует помнить, это где могут обитать целевые файлы. Например, наш образ ВМ CentOS 7 будет обладать файлом настроек, chrony , установленным в /etc/chrony.conf , в то время как сервер Ubuntu 18.04 LTS будет иметь его в /etc/chrony/chrony.conf . Помимо этого небольшого изменения для значения параметра dest: в нашем модуле copy , весь код останется прежним. К сожалению, это делает установку пакета несколько более сложной.
Давайте допустим что мы хотим установить cloud-init и docker своём примере образа CentOS 7 — необходимая для этого роль может выглядеть следующим образом:

 --- - name: Install the epel-release package yum: name: epel-release state: present - name: Install cloud-init and docker yum: name: ">" state: present loop: - cloud-init - docker

Рисунок 5-9

Если вы пользуетесь другим дистрибутивом Linux, тогда вам необходимо изменять надлежащим образом и применяемый диспетчер пакетов. Например, в таких дистрибутивах как Debian или Ubuntu, которые пользуются диспетчером пакетов apt , аналогичная роль Ansible выглядела бы подобно следующему блоку кода:

 --- - name: Install cloud-init and docker apt: name: ">" state: present loop: - cloud-init - docker.io

Обратите внимание на замену с yum на apt и различные названия пакетов для службы контейнеров Docker. Во всём кроме этого данный плейбук почти идентичен.

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

Мы видоизменим свой код более ранних примеров чтобы соединить обе эти установки в одной роли Ansible:

Самая первая часть нашего кода почти идентична нашему предыдущему примеру, за исключением того что нам придётся задать соответствующий оператор when для того чтобы убедиться что мы выполняем запуск лишь дистрибутивах Linux на основании Debian или Ubuntu:

 --- - name: Install cloud-init and docker apt: name: ">" state: present loop: - cloud-init - docker.io when: ansible_distribution == 'Debian' or ansible_distribution == 'Ubuntu'

 - name: Install the epel-release package yum: name: epel-release state: present when: ansible_distribution == 'CentOS' or ansible_distribution == 'Red Hat enterprise Linux' - name: Install cloud-init and docker yum: name: ">" state: present loop: - cloud-init - docker when: ansible_distribution == 'CentOS' or ansible_distribution == 'Red Hat enterprise Linux'

И вновь обратите внимание на операторы when в каждой из задач — эти конкретные примеры мы используем для определения того следует ли запускать данные задачи в зависимости от фактов, полученных Ansible в его первоначальной части исполнения. Тем самым, если мы теперь запустим данную роль в некой системе Ubuntu, мы увидим следующее:

Рисунок 5-10

Рисунок 5-11

После того как были установлены дополнительные пакеты, часто может оказаться полезной их настройка. С своём следующем разделе мы изучим применение Ansible в изменении файлов настроек.

Изменение файлов настройки

До сих пор вся выполнявшаяся нами работа по настройке была слишком чёрно- белой — мы либо устанавливали нечто (будь то пакет или файл) , либо мы могли в равной степени просто удалять их (об этом больше в разделе, посвящённом очистке). Тем не менее, что если требуется нечто более тонкое? Ранее в этой главе, в разделе, озаглавленном Передача файлов в заданный образ, мы заменяли свой файл chrony.conf целиком на нашу собственную версию. Это, однако, может оказаться слишком брутальным — например, нам может потребоваться изменить всего одну строку в файле, а замена всего файла целиком для замены лишь одной строки — это достаточно сложно, в особенности если учесть, что данный файл настроек может быть обновлён в последующей версии пакета.

Давайте обратимся к другому распространённому требованию настройки образа операционной системы: безопасности демона SSH. По умолчанию, подобные созданной нами ранее установки CentOS 7 допускают удалённый вход в систему от имени учётной записи root. По причинам безопасности это нежелательно, а потому вопрос состоит в том, как нам обновлять соответствующую настройку демона SSH без необходимости замены её файла целиком? К счастью, Ansible обладает модулями именно для такой задачи.

Для выполнения данной задачи на подмогу нам приходит модуль lineinfile . Рассмотрим следующую роль, которую мы назовём securesshd :

 --- - name: Disable root logins over SSH lineinfile: dest: /etc/ssh/sshd_config regexp: "^PermitRootLogin" line: "PermitRootLogin no" state: present

Здесь для обработки своего файла /etc/ssh/sshd_config мы применяем модуль lineinfile . Мы запрашиваем поиск строк, начинающихся с PermitRootLogin (это избавляет нас от непредумышденного изменения строк, скрытых комментарием), а затем заменяем эту строку на PermitRootLogin no .

Давайте испробуем это для своей проверочной системы CentOS 7:

Рисунок 5-12

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

Обратите внимание, что в запущенной системе вам также потребуется перезапуск такой службы SSH чтобы ввести в действие применённые изменения; однако когда мы очистили и остановили некий образ для его последующего развёртывания, в этом нет нужды.

Средним путём между загрузкой некого файла целиком и изменением некого имеющегося является применение шаблонов. Шаблоны Jinja2 Ansible невероятно мощны и полезны когда файлы могут обладать зависящее от некого параметра переменной содержимое.

Рассмотрим снова пример более ранней настройки chrony — в данном случае мы передавали некий статический файл с жёстко закодированным адресом NTP. Это отлично когда ваше предприятие полагается на некий статичный сервер NTP (или их набор), но некоторые будут полагаться на различные серверы в зависимости от того где надлежит развернуть данный образ.

Давайте продемонстрируем это новой ролью с названием templatentp . Для этого мы определим некий каталог шаблонов в roles/templatentp/templates и поместим в него файл с нназванием chrony.conf.j2 и следующим содержимым:

 pool > iburst maxsources 4 keyfile /etc/chrony/chrony.keys driftfile /var/lib/chrony/chrony.drift logdir /var/log/chrony maxupdateskew 100.0 rtcsync makestep 1 3

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

Давайте создадим соответствующий файл роли main.yml таким образом:

 --- - name: Deploy chrony configuration template template: src: templates/chrony.conf.j2 dest: /etc/chrony.conf owner: root group: root mode: '0644' backup: yes

Заметьте насколько он похож на наш пример с copy . Наш site.yml тоже отличается лишь слегка — в нём ма задаём значение переменной с названием хоста сервера NTP. В Ansible существует множество мест в котором можно задать эту переменную и определить наилучшее место для её размещения оставлено на усмотрение самого пользователя:

 --- - name: Run example roles hosts: all become: yes vars: ntpserver: time.example.com roles: - templatentp

Наконец, мы запускаем свой плейбук и смотрим на полученные результаты:

Рисунок 5-13

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

Проверка правильности построения образа

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

Существует множество варианты выполнения этой задачи в Ansible — давайте рассмотрим некий простейший пример. Допустим, у вас имеется некий сценарий архивирования, который применяет утилиту сжатия bzip2 для упаковки файлов. Это всего лишь небольшой инструмент, но если вы полагаетесь на него для определённых целей, ваш сценарий будет прерван в случае его отсутствия. Это к тому же и уместный пример, ибо собственно минимальная установка CentOS 7 (как мы столкнулись с этим ранее) в действиельности не обладает им.

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

Тем самым, мы бы могли запросто включить в свой плейбук такую роль настроек:

 --- - name: Ensure bzip2 is installed yum: name: bzip2 state: present

При запуске этой роли в случае с не установленным bzip2 , она осуществит установку и возвратит значением результата changed . В случае если она определит что bzip2 установлен, она возвратит ok и не выполнит более никаких действий. Тем не менее, что если мы на реально желаем проверить нечто вместо выполнения какого- то действия, возможно как некий этап после сборки? Позднее в данной книге мы более подробно рассмотрим способы выполнения аудита систем, но сейчас давайте проследуем далее со своим примером с помощью Ansible.

Если бы вы применяли некие команды оболочки, вы бы проверили присутствие bzip2 одним из двух способов, коими являются запрос имеющейся базы данных RPM на предмет того, установлен ли такой пакет bzip2 или проверите наличие /bin/bzip2 в рассматриваемой файловой системе.

Давайте взглянем на свой самый последний пример Ansible. Модуль stat Ansible может применяться для проверки присутствия некого файла. Рассмотрим приводимый ниже код, который мы создали обычным образом в роли с названием checkbzip2 :

 --- - name: Check for the existence of bzip2 stat: path: /bin/bzip2 register: bzip2result failed_when: bzip2result.stat.exists == false - name: Display a message if bzip2 exists debug: msg: bzip2 installed.

Рисунок 5-14

Рисунок 5-15

Это вполне точное поведение и в точности то, которое мы пожелали. Ansible не просто ограничивается проверкой файлов — мы к тому же можем убедиться что в нашем файле sshd_config отсутствует рассматривавшаяся нами ранее строка PermitRootLogin no :

Мы можем осуществить это с помощью такой роли:

 --- - name: Check root login setting in sshd_config command: grep -e "^PermitRootLogin no" /etc/ssh/sshd_config register: grepresult failed_when: grepresult.rc != 0 - name: Display a message if root login is disabled debug: msg: root login disabled for SSH

Рисунок 5-16

Рисунок 5-17

И снова всё определённо. В предыдущем выводе нет никакого состояния changed — это именно так по причине применения нами модуля command , который успешно выполнил command — следовательно, всегда возвращается changed . Мы можем изменить такое поведение данной задачи при помощи условия changed_when , если вы пожелаете.

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

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

Собирая всё воедино

На протяжении данного раздела этой главы вы обратили внимание на то, что во всех своих примерах мы пользовались ролями. Естественно, когда дело доходит до сборки вашего окончательного образа, вы не желаете закончить всё запуском множества плейбуков по отдельности, как мы это делали здесь. К счастью, если бы мы соединили их все, всё что потребовалось бы для этого, так это поместить все эти роли в соответствующий подкаталог roles/ , а далее сослаться на них всех в своём плейбуке site.yml . Такой каталог roles должен бы выглядеть как- то так:

 ~/hands-on-automation/chapter05/example09/roles> tree -d . ├── checkbzip2 │ └── tasks ├── checksshdroot │ └── tasks ├── filecopyexample │ ├── files │ └── tasks ├── installbzip2 │ └── tasks ├── packageinstall │ └── tasks ├── securesshd │ └── tasks └── templatentp ├── tasks └── templates

После этого наш файл site.yml будет смотреться подобно следующему:

 --- - name: Run example roles hosts: all become: yes roles: - filecopyexample - packageinstall - templatentp - installbzip2 - securesshd - checkbzip2 - checksshdroot

Запуск этого кода остаётся в качестве упражнения читателю, ибо мы уже исполняли все составные части ранее в этой главе. Тем не менее, если всё пройдёт нормально, когда все роли будут завершены, не будет никаких состояний failed — лишь смешение changed и ok .

Когда вы пройдёте описанный в данной главе процесс сборки, скорее всего, полученный образ потребуется очистить повторно. Мы могли бы снова обратиться к команде virt-sysprep , однако и тут приходит на помощь Ansible. В своём следующем разделе мы изучим применение Ansible для очистки образов при крупномасштабном развёртывании.

Очистка построения при помощи Ansible

На данный момент вы должны обладать достаточно хорошим пониманием сборки или валидации некого базового образа и последующей его персонализации при помощи Ansible. Прежде чем мы закроем данную главу, неплохо повторить свою задачу очистки вашего готового к развёртыванию образа. Собрали ли вы некий образ с нуля, либо выгрузили уже подготовленный, когда вы его запускаете и выполняете в нём команды, будь то вручную или через Ansible, вам скорее всего пришлось загружать элементы, которые на практике нежелательно представлять при каждом развёртывании данного образа. Например, на самом ли деле вы хотите чтобы все файлы системных журналов от всех задач выполненных вами настроек и всех первичных загрузок присутствовали во всех развёртываемых отдельных виртуальных машинах? Когда вам приходится запускать все команды вручную (даже когда это была установка аутентификации при запуске Ansible), хотите ли вы чтобы эти команды присутствовали во всех развёртывания в соответствующем файле .bash_history той учётной записи, которая запускала их?

Ответом на это будет, естественно, нет. Кроме того, имеются такие файлы, которые способны вызывать проблемы при клонировании — например, дубликаты ключей SSH или особые для MAC- адреса настройки, такие как данные настроек udev . Всё это следует вычистить до того как вы будете полагать что ваш образ готов к развёртыванию.

Ansible также способен помочь и с этой задачей, хотя и рекомендуется чтобы вы применяли показанный нами ранее в этой главе инструментарий virt-sysprep , ибо он позаботится для вас обо всех этих шагах. Может иметься некая причина почему вы не пожелаете воспользоваться этим инструментарием — возможно, у вас нет доступа к нему в вашей среде, или он не собран в предпочитаемом вами дистрибутиве Linux. При таких обстоятельствах вы можете воспользоваться Ansible для окончательной очистки. Самый великолепный момент в Ansible состоит в том, что вы можете применять встроенные модули, как мы уже демонстрировали это до сих пор в данной главе, но вы в равной степени можете применять и сырые команды оболочки — это может быть в особенности полезно, когда вам необходимо выполнять по всей файловой системе операции с групповыми символами.

Ниже приводится некий образец роли, которая полагается на сырые команды оболочки для очистки образа при его подготовке к развёртыванию. Он не настолько полный как то задание, которые осуществляет virt-sysprep , но служит достойным примером того как это можно выполнять с помощью Ansible. Обратите внимание, что данный образец специфичен именно для CentOS 7 — когда применяется иная операционная система, тогда понадобится поменять пути, команды очистки базы данных пакетов и тому подобное. Следовательно, этот плейбук предоставляется пользователю во многом как некий практический пример того как следует выполнять очистку через Ansible, хотя и предполагается, что читатель двинется дальше в зависимости от своих собственных требований. Прежде всего, мы очищаем имеющуюся базу данных пакетов, так как эти сведения не следует реплицировать во все развёртывания:

 --- - name: Clean out yum cache shell: yum clean all

Затем мы продолжаем очисткой имеющихся журналов — это достигается остановкой демона регистраций, принудительной прокруткой всех журналов и последующим рекурсивным удалением содержащего их каталога:

 - name: Stop syslog shell: service rsyslog stop - name: Force log rotation shell: /sbin/logrotate -f /etc/logrotate.conf ignore_errors: yes - name: Clean out logs shell: /bin/rm -f /var/log/*-. /var/log/*.gz /var/log/*.[0-9] /var/log/**/*.gz /var/log/**/*.[0-9] - name: Truncate log files shell: truncate -s 0 /var/log/*.log - name: Truncate more logs shell: truncate -s 0 /var/log/**/*.log - name: Clear the audit log shell: /bin/cat /dev/null > /var/log/audit/audit.log - name: Clear wtmp shell: /bin/cat /dev/null > /var/log/wtmp

После этого мы вычищаем свои особенности настроек оборудования и MAC адресов, которые будут неверными при развёртывании образа ВМ:

 - name: Remove the udev persistent device rules shell: /bin/rm -f /etc/udev/rules.d/70* - name: Remove network related MAC addresses and UUID's shell: /bin/sed -i '/^\(HWADDR\|UUID\)=/d' /etc/sysconfig/network-scripts/ifcfg-*

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

 - name: Clear out /tmp shell: /bin/rm -rf /tmp/* /var/tmp/* - name: Remove user history shell: /bin/rm -f ~root/.bash_history /home/**/.bash_history - name: Remove any viminfo files shell: rm -f /root/.viminfo /home/**/.viminfo - name: Remove .ssh directories shell: rm -rf ~root/.ssh m -rf /home/**/.ssh

Наконец, мы выполняем свою окончательную задачу — в данном случае удаление имеющихся SSH ключей хоста. Обратите внимание, что после этого мы также выключаем свою ВМ — это выполняется как часть данной команды чтобы предотвратить непредумышленное создание каких- либо дополнительных сведений истории или регистрационных записей. Также обратите внимание и на условие ignore_errors , которое препятствует сбою плейбука при выполнении останова и прерывании установленного подключения SSH:

 - name: Remove SSH keys and shut down the VM (this kills SSH connection) shell: /bin/rm -f /etc/ssh/*key* && shutdown -h now ignore_errors: yes

Выполнение данного кода в некой ВМ CentOS 7 приведёт в результате к достаточно неплохо очищенному образу, однако имеются не охваченные здесь особенности. К примеру, мы выполнили очистку всех историй bash, однако если использовалась иная оболочка, имеются не вычищенными её данные. Аналогично, мы очистили сведения приложения VIM из домашнего каталога root, но не касались всех прочих приложений, которые могли применяться, а могли и нет в процессе создания данного образа. Следовательно, это оставляется вам для расширения данной роли в зависимости от требований вашей среды.

На данном этапе вы выполнили прогон всего процесса, причём повсеместно, в отношении создания, персонализации и очистки операционной системы Linux для целей SOE. Действенное использование Ansible означает, что весь процесс может быть автоматизирован, а следовательно делает для нас возможным выполнение мощного старта в направлении автоматизации на вашем предприятии и начиная с данного момента вы имеете возможность его клонирования и применения там, где только пожелаете.

Выводы

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

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

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

Вопросы

В чём состоит основная цель подготовки системы (sysprep)?
Когда вам может потребоваться применение фактов Ansible в своих ролях?
Как бы вы развёртывали некий новый файл конфигурации некого образа виртуальной машины при помощи Ansible?
Какой модуль Ansible применяется для выгрузки файла из Интернета напрямую в образ некой виртуальной машины?
Как бы вы написали некую отдельную роль Ansible, которая установит пакеты и в Ubuntu, и в CentOS?
Зачем вам желательно проверять выгружаемый вами образ ISO?
Как само применение ролей Ansible на данном этапе даёт преимущества вашей среде при её развёртывании?

Последующее чтение

Для более глубокого понимания Ansible, будьте добры ознакомиться с Mastering Ansible, Third Edition — James Freeman и Jesse Keating < Прим. пер.: рекомендуем также свой перевод этого 3 издания Полного руководства Ansible Джеймса Фримана и Джесса Китинга >.

Для получения дополнительных подробностей о применении KVM при виртуализации Linux, обратитесь, пожалуйста, к Mastering KVM Virtualization, Prasad Mukhedkar, Anil Vettathu и Humble Devassy Chirammal < Прим. пер.: рекомендуем также свой перевод отдельных глав из Виртуализация KVM, Полное руководство этих авторов , Книги рецептов виртуализации KVM Константина Иванова и Основ разработки libvirt Как настраивать и сопровождать виртуальную машину при помощи Python, В. Дэйвида Эшли >.

Как применить роль ansible к виртуальной машине

«1C-Битрикс: Виртуальная машина» – бесплатный программный продукт, готовый к немедленному использованию виртуальный сервер, полностью настроенный, протестированный и адаптированный для оптимальной работы как с продуктами «1С-Битрикс», так и с любыми PHP-приложениями. Имеется в версии для Windows и для Unix систем.

Виртуальная машина сэкономит вам время и силы на правильное развертывание и администрирование вашего сайта или внутреннего информационного ресурса на базе продуктов «1С-Битрикс».

Курс предназначен для администраторов и пользователей продуктов «1С-Битрикс», устанавливающих для ознакомления либо переносящих готовые проекты на виртуальную машину BitrixVM. Аналогичным способом можно переносить проекты с удаленного сайта на виртуальную машину, между виртуальными машинами и т.д. В курсе рассматриваются процедуры установки всех необходимых приложений для работы продукта на виртуальной машине BitrixVM.

Описание установки VMWare Player не входит в данное руководство. По всем вопросам установки этой программы обращайтесь к документации VMWare Player.

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

Баллы опыта

В конце каждого урока есть кнопка Прочитано! . При клике на неё в вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:

уроке.

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

Комментарии к урокам

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

Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

iOS
Marvin for iOS
ShortBook

Linux:
Calibre
FBReader
Cool Reader
Okular обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла – от 17.07.2023.

Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.

Как применить роль ansible к виртуальной машине

Руководство. Создание масштабируемого набора виртуальной машины или виртуальной машины из Общая коллекция образов Azure с помощью Ansible

Необходимые компоненты

Получение примера сборников схем

Подготовка виртуальной машины и создание пользовательского образа

Создание Общей коллекции образов

Создание общего образа и версии образа.

Создание виртуальной машины на основе универсального образа

Создание масштабируемого набора виртуальных машин на основе универсального образа

Получение информации о коллекции

Удаление общего образа

Очистка ресурсов

Демонстрация Ansible функций с контрольными и тестовыми виртуальными машинами

Немного предыстории: Ansible и Vagrant

Продемонстрированные особенности и хитрости

Бродяга — Ansible советы по интеграции

анзибль

Gotchas

Автоматическая настройка JBoss

анзибль

Prerequisities

Как это настроено

Кратко о Бродяге

Структура конфигурации

использование

Тестирование локально

Прогон, репетиция

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

Глава 5. Применение Ansible для создания шаблонов виртуальных машин развёртывания

Технические требования

Выполнение первоначального построения

Применение готовых шаблонов образов

Создание ваших собственных образов виртуальных машин

Применение Ansible для построения и стандартизации конкретного шаблона

Передача файлов в заданный образ

Установка пакетов

Изменение файлов настройки

Проверка правильности построения образа

Собирая всё воедино

Очистка построения при помощи Ansible

Выводы

Вопросы

Последующее чтение

Как применить роль ansible к виртуальной машине

Баллы опыта

Комментарии к урокам

Добавить комментарий Отменить ответ