Глава 9. Внесение исправлений при помощи Katello

минимальными требованиями для осуществления всех практических примеров из этой главы яляется отдельный сервер CentOS с примерно 80ГБ выделенного дискового пространтсва, 2 ядра ЦПУ (виртуальных или физических) и 8 ГБ оперативной памяти. Хотя в этой главе мы будем рассматривать только некое подмножество свойств Katell, следует отметить, что Foremann, в частности (который устанавливается под katello) способен действовать в качестве сервера DHCP, сервера DNS и хоста загрузки PXE, а раз так, при неверных настройках может создавать проблемы при своём развёртывании в промышленных сетевых средах.

По этой причине вам рекомендуется выполнять все упражнения в некой изолированной сетевой среде, пригодной для тестирования. Когда приводится код Ansible, он был разработан и проверен в Ansible 2.8. Для проверок внесения исправлений из Katello вам потребуется некая виртуальная машина CentOS 7.

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

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

Применение Katello, следовательно, предоставляет определённые преимущества над использованием Pulp в отдельности, причём даже когда вы применяете его исключительно для управления исправлениями (как мы это изучим в данной главе, в разделе Внесение исправлений при помощи Katello, богатые веб GUI, CLI и API сами по себе приводят к интеграции с системами предприятия. Помимо этого, Katello (а более конкретно, Foremann, коьторый его поддерживает) предоставляет множество прочих преимуществ, таких как наличие способности динамически загружать через PXE серверы и контролировать как системы контейнеров, так и системы виртуализации, а также даже способен выступать в качестве серверов DNS и DHCP для вашей сетевой среды. На самом деле, будет справедливо сказать, что комбинация Katello/ Foremann предназначения для того чтобы пребывать в самом сердце вашей сетевой среды, хотя она и будет выполнять лишь те функции, которые вы у неё запросите, а пэтому те, у кого уже имеются инфраструктуры DNS и DHCP не должны опасаться.

Стоит также отметить что Katello также снабжён тесной интеграцией с инструментарием автоматизации Puppet. Собственно первонаяальный проект спонсировался Red Hat, а до того как они приобрели Ansible, Red Hat и Puppet обладали стратегическим альянсом, что приводило к тому что он стал чрезвычайно вовлечённым в сам проект Katello (который доступен на коммерческой основе в качестве Red Hat Satellite 6). Совершив приобретение Ansible, в то время как интеграция с Puppet всё ещё сохранеяется в Katello, поддержка интеграции с Ansible, в особенности через Ansible Tower/ AWX быстро развивалась и теперь целиком от самого пользователя зависит какой именно инструментарий автоматизации он пожелает применять.

На данном этапе заслуживает достойным упоминания почтенный программный инструментарий Spacewalk. Spacewalk это исходящая версия с открытым исходным кодом для Red Hat Satellite 5 и она всё ещё активно разрабатывается и сопровождается. Существует огромная степень совпадений между этими двумя системами с точки зрения функциональности на верхнем уровне; тем не менее, Katello/ Satellite 6 это полное переосмысление данной платформы, а потому между ними не существует чёткого пути обновления. Принимая во внимание то, что вклад Red Hat в программу Spaceworks, скорее всего, снизится, когда они откажутся от своего продукта Satellite 5, мы сосредоточимся в данной книге на Katello.

На самом деле, было бы справедливым сказать, что Katello заслуживает отдельной собственной книги, настолько богат набор его свойствю Нашей целью в данной главе является простое повышение осведомлённости о самой платформе Katello и демонстрация того насколько она сама по себе подходит к исправлениям в некой корпоративной среде. Многие дополнительные свойства, такие как PXE загрузка серверов, требуют понимания тех концепций, которые мы уже рассматривали в данной книге, а следовательно, имеется надежда, что в раз уж вы выберите Katello или Satellite 6 в качестве платформы управления своей инфраструктурой, тогда вы будете способны опираться на предоставляемую данной книгой основу и изучать дополнительные ресурсы, которые помогут вам и дальше.

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

Эта книга является практическим руководством, а потому без лишних слов давайте начнём и настроем свой собственный сервер Katello. Наряду с уже обсуждавшимися преимуществами Katello, ещё одним является собственно упаковка данного продукта. Когда мы настраивали свой сервер Pulp, имелось множество отдельных компонентов, для которых нам приходилось принимать решения (например RabbitMQ или Qpid), а затем выполнялась дополнительная настройка (скажем, транспорт SSL для MongoDB). У Katello даже больше движущих частей, чем у Pulp (раз Pulp рассматривается просто как компонент платформы Katello), а, следовательно, его установка вручную будет большой и сложной задачей.

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

Katello, как и Pulp (на момент написания этих строк) устанавливается только в вариантах Enterprise Linux 7 - а потому вновь мы будем применять самую стабильную версию CentOS 7. Необходимые для Katello требования изменяются время от времени, по мере роста самого продукта и всегда будет не лишним для себя просмотреть документацию по установке прежде чем продолжить. На момент написания этих строк самым последним стабильным выпуском была версия 3.12, а документацию по установке можно было отыскать здесь. Теперь давайте продолжим следующими шагами:

Технически говоря, Katello это модуль, который располагается поверх Foremann и предоставляет важные свойства, с которыми мы и будем работать позднее в этой главе - например, некий веб UI для системы управления репозиториями Pulp также устанавливается за сценой. Следовательно, выделяется фирменный стиль самого кода Foreman и вы обнаружите, что это название часто встречается. После входа в систему, вам должна быть представлена страница панели инструментов по умолчанию, и мы сможем приступить к настройке некоторых репозиториев для целей правки, которые мы начнём обсуждать в своём следующем разделе.

Поскольку Katello строится вокруг уже изучавшихся нами технологий, таких как Pulp, он несёт с собой те же самые ограничения, которые мы уже видели в отношении пакетов DEB. Например, хотя репозитории пакетов DEB могут запросто собираться в Katello, причём даже с импортом надлежащих общедоступных ключей GPG, получаемые в результате общедоступные репозитории не снабжаются какими бы то ни было файлами InRelease или Release.gpg, а потому обязаны быть доверенными в неявном виде для всех применяющих их хостов. Аналогично, хотя и имеется доступной полная инфраструктура управления подписками для хостов на основе RPM, состоящая из инструментария subscription-manager и собственно агента Потребителя Pulp , опять же, для хостов DEB нет таких эквивалентов, а потому их следует настраивать вручную.

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

Одним из основных привносимых Katello преимуществ по сравнению с Pulp, помимо веб интерфейса пользователя, является его понятие сред жизненного цикла. Данное свойство предполагает, что большая часть дел будут для различных целей отделять технологии сред. К примеру, ваше предприятие для разработок будет обладать средой Development, а также для проверок пакетов технологических новинок, далее некую среду Testing для проверки выпусков и, наконец, среду Production, в которой присутствуют наиболее стабильных сборок и запуска служб для потребителей и клиентов.

Теперь давайте изучим практические примеры сборок репозиториев в Katello для целей внесения исправлений.

Давайте рассмотрим применение Katello для построения репозиториев под нашу систему CentOS 7 по множеству сред жизненного цикла. Поскольку Katello поддерживает удостоверение RPM на основании ключей, наша первая задача состоит в установке необходимого ключа GPG для соответствующих RPM. Его копия свободно выгружается из проекта CentOS и может быть найден для большинства систем CentOS 7 в /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7:

По завершению нашего процесса синхронизации и создания нами сред, мы способны продолжить завершающую часть нашей настройки репозитория RPM - Content Views. В Katello некое представление содержимого это определяемое пользователем слияние различных форм содержимого, которые могут поглощаться, снабжаться контролем версий и распределяться на определённую среду. Лучше всего это пояснить конкретным примером.

Когда мы применяли Pulp сам по себе, мы создали некий репозиторий с названием centos7-07aug19. Когда мы пожелали выполнить проверку какого- то обновления днём спустя, мы далее создали какой- то второй репозиторий с названием centos7-08aug19. Хотя это и работало, и мы показали как Pulp выполняет дедупликацию пакетов и сберегает дисковое пространство при аккуратной публикации по отдельности обособленных репозиториев, вы быстро сможете найти этот механизм управления содержимым становящимся громоздким, в особенности в масштабах предприятия, с многочисленными представляющими ценность для управления средами и какими- то месяцами (или годами).

Именно здесь на помощь приходят Content Views (Представления содержимого). Хотя у нас и имеются здесь репозитории ОС CentOS 7, допустим, что мы осуществили зеркалирование одного из обновлений. Обладая Content Views, нам не требуется создавать некий новый продукт или репозиторий для проверки наших обновлений. Вместо этого надлежащий рабочий поток на неком верхнем уровне выглядит так:

Таким образом, Katello осуществляет упрощение управления множеством версий (снимков) репозиториев для различных сред, в качестве бонуса добавляя то, что соответствующая конфигурация для каждого из хостов всегда остаётся одной и той же, избавляя от потребности активной доставки сведений о новом репозитории через Ansible, как мы это делали в случае м Pulp.

Давайте проследуем этими шагами по некому примеру своей предыдущей демонстрации среды Katello:

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

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

[centos-os]
name=CentOS-os
baseurl=http://katello.example.com/pulp/repos/HandsOn/Development/CentOS7-CV/custom/CentOS7/CentOS7-os/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
 	   

Ваш базовый URL, естественно, будет иным - по крайней мере, имя вашего хоста Katello будет отличаться. Публикуемые и продвигаемые в Katello репозитории на основе RPM обычно доступны по такому пути:

http://KATELLOHOSTNAME/pulp/repos/ORGNAME/LIFECYCLENAME/CONTENTVIEWNAME/custom/PRODUCT/REPO
 	   

Здесь у нас имеется следующее:

Это превращает данный URL в полностю предсказуемый и просто развёртываемый в целевых машинах с помощью Ansible, в точности как мы это делали в своей предыдущей главе в отношении Pulp. Обратите внимание на то, что доступ к репозиториям из Katello через HTTPS потребует надлежащей настройки сертификатов SSL для подтверждения удостоверения, что выходит за рамки данной главы - вместо этого мы просто пользуемся HTTP.

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

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

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

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

Внесение посредством Katello исправлений в системы на основе DEB, подобные Ubuntu во многом аналогично процессу с RPM, с сохранением некоторых изменений в применяемом GUI и с ограничениями относительно подписывания пакетов, обсуждавшихся ранее в этой главе, в разделе Внесение исправлений при помощи Katello. Давайте быстро теперь пройдёмся по примеру для сервера Ubuntu 18.04:

Как вы можете видеть, он почти идентичен соответствующему примеру для основанного на RPM шаблона, причём с сохранением начального пути. Некая подходящая точка входа для /etc/apt/sources.list с установлением соответсвия только что созданному нами в данном примере представлению содержимого может выглядеть примерно так:

deb [trusted=yes] http://katello.example.com/pulp/deb/HandsOn/Development/Ubuntu1804-CV/custom/Ubuntu_18_04_Server/Ubuntu_18_04_base/ bionic main
 	   

Как и ранее, этот URL остаётся постоянным вне зависимости от того когда мы осуществляем синхронизацию, публикацию или представление данного представления содержимого, а потому от него требуется лишь одноразового развёртывания в целевых системах чтобы обеспечить приём ими пакетов от установленного сервера Katello. И опять, вы можете выполнять такое внесение изменений вручную посредством команд apt update и apt upgrade в сових оконечных системах, либо централизованно посредством Ansible.

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

Следует подчеркнуть, что в данной главе мы на самом деле лишь прикоснулись к тому что может выполнять Katello - однако мы надеемся что выполненная нами работа достаточно снабдит вас для того чтобы принимать обоснованное решение о том, следует ли продолжать с этой невероятно мощной и универсальной платформой в качестве части вашей архитектуры Linux.

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

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

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

Для бо́льшего понимания Katello обратитесь, пожалуйста, к официальной документации Red Hat Satellite 6, ибо он представляет собой коммерческую версию Katello и для данной платформы обычно написана вся документация - тем не менее их свойства и структура меню почти идентичны.