Данная глава содержит примеры, основывающиеся на следующих технологиях:

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

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

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

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

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

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

Однако, для установок, в которых не требуется GUI (Graphical User Interface, графический интерфейс пользователя), Pulp оказывается исключительно подходящим. Давайте рассмотрим как мы можем установить его.

Как мы уже обсуждали это в Главе 1, Построение стандартной среды работы в Linux данной книги, будут встречаться случаи, в которых даже когда вы можете обладать сборкой некой стандартной операционной среды вокруг заданного дистрибутива Linux, такого как сервер Ubuntu, вам придётся делать некие исключения. Pulp именно тот случай, хотя он и способен управлять как пакетами .rpm, так и .deb (а следовательно, обрабатывать требования репозиториев для широкого разнообразия дистрибутивов Linux), он снабжён пакетами (а следовательно может быть установлен) лишь под операционные системы CentOS, Fedora и на основе RHEL. Вы всё ещё способны управлять с помощью Pulp своим штатом серверов Ubuntu - вам лишь потребуется установить его на CentOS (или иной предпочитаемый вами вариант Red Hat).

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

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

Хотя в данной главе мы будем пользоваться лишь неким подмножеством доступных в Pulp свойств, предполагается, что здесь продемонстрирован некий жизнеспособный рабочий процесс, который показывает почему именно вы можете выбрать Pulp для управления репозиториями предприятия вместо развёртывания своего собственного решения (например, копирования пакетов из ISO, как мы это делали в Главе 6, Персональные сборки с PXE загрузкой).

Основной процесс обработки репозиториев пакетов на основании RPM и на основании DEB во многом аналогичен.

Давайте начнём с с изучения того как создавать репозитории на основании RPM и управлять ими.

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

Имеющееся ядро репозиториев CentOS расщепляется надвое - прежде всего имеется сам репозиторий ОС; именно он содержит все необходимые файлы для самого последнего выпуска после точки для CentOS 7 - которым на момент написания являлся 7.6. Последний раз он обновлялся в ноябре 2018 и будет оставаться статичным вплоть до выпуска CentOS 7.7. Все обновления для данного выпуска далее содержатся в отдельном репозитории, а потому для сборки полностью рабочего зеркала CentOS 7 в нашем сервере Pulp требуется зеркалировать оба этих пути.

Давайте начнём с создания зеркала базовой операционной системы:

Теперь, покончив с этим, у вас имеется некий внутренний моментальный снимок восходящего потока репозитория ОС CentOS 7.6, определённого значением параметра --feed, который остаётся постоянным в нашем сервере Pulp даже после выхода в свет CentOS 7.7.

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

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

Выполнив это, мы далее можем применять клиента pulp-admin для инспектирования имеющихся репозиториев и величин использования диска. На данный момент мы можем увидеть, что файловая система Pulp имеет задействованными 33 ГБ, хотя не все они идут под CentOS, поскольку в этой тестовой системе имеются и иные репозитории. Через минутку этот уровень использования станет важным.

В некой корпоративной среде хорошей практикой была бы сборка или обновления тестовых систем CentOS 7 для данного снимка на 8 августа с выполнением необходимых проверок с ними чтобы обеспечить уверенность в такой сборке. Это в особенности важно в которых изменения ядра могут создавать проблемы. Раз для данной сборки была подтверждена достоверность, она превращается в соответствующий базовый уровень для всех систем CentOS 7. Основным моентом в таком сценарии является то, что все системы (в представлении что они применяют данный репозиторий Pulp) будут обладать одними и теми же версиями всех пакетов. Именно это, в сочетании с рекомендуемой автоматизацией, как мы уже не раз обсуждали это на страницах данной книги, привносит практически сопоставимую с Docker стабильность и достоверность в окружение Linux.

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

Если бы мы просто пользовались исходящими репозиториями из интерента, тогда мы бы не обладали подобным контролем, а наши серверы CentOS 7 слепо брали бы при следующем запуске имеющееся исправление. Точно также, когда мы вручную обновляем зеркала репозитория сборки при помощи подобных reposync инструментов, мы бы обладали одной из двух возможностей. Во- первых, мы бы могли обновить уже имеющееся у нас зеркало, что стоило бы нам очень небольшого дискового пространства, но привнесло бы ровно те же самые проблемы, что и применение исходящих репозиториев (то есть все серверы выбирали бы самое новое исправление, как только бы запускалось их лобновление). В качестве альтернативы, мы могли бы создать второй снимок для проверки. Я подсчитал, что для зеркалирования обновлений CentOS на сревере Pulp требуется около 16 ГБ дискового пространства, а потому создание второго снимка потребует около 32 ГБ дискового пространства. С теченеим времени потребуются дополнительные снимки и ещё больше дискового пространствва, что невероятно неэффективно.

Именно тут воссияет звезда Pulp - он не только способен создавать репозитории на основе RPM и управлять ими неким действенным способом, но также осведомлён о том что не следует выгружать те пакеты, для которых уже была выполнена синхронизация и он не дублирует пакеты при их публикации - а следовательно, он очень эффективен как в смысле полосы пропускания, так и использования дисков. Благодаря этому мы способны вызывать следующий набор команд для создания нового моментального снимка обновлений CentOS 7 на 8 августа:

$ pulp-admin rpm repo create --repo-id='centos7-08aug19' --relative-url='centos7-08aug19' --feed=http://mirror.centos.org/centos/7/updates/x86_64/
$ pulp-admin rpm repo sync run --repo-id='centos7-08aug19'
$ pulp-admin rpm repo publish run --repo-id centos7-08aug19
		

Вы обнаружите сходство с теми командами, которые мы запускали ранее в этом разделе для создания снимка на 7 августа 2019 - они, по существу, идентичны, за исключением значения нового идентификатора репозитория (--repo-id) и URL (--relative-url), которые заботятся о значении даты в приращении по сравнению с предыдущей. Этот процесс запускается как и раньше, что отображено на приводимом далее снимке экрана - там показано что все пакеты выгружены и на этом этапе мало что известно о том, что происходит за сценой:

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

Отсюда мы можем увидеть, что использование диска было округлено до 34 ГБ - вероятно, мы бы обнаружили занятость значительно меньшей, когда воспользовались бы более подробным измерением. Таким образом, Pulp позволяет создавать снимки практически в том виде как нам они и требуются, причём без использования большого дискового протсранства и в то же самое время из соображений стабильности сохраняя старые до тех пор, пока не будет подтверждена надёжность новых, после чего избыточные моментальные снимки могут быть удалены.

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

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

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

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

Например, модуль pulp_repo (введённый в версии 2.3 Ansible) обладает возможностью создания и удаления репозиториев, что мы выполняли ранее в этой главе с помощью pulp-admin rpm repo create. Тем не менее, он не способен осуществлять очистку сирот, а потому команду для этого требуется вызывать при помощи модулей Ansible shell или command. Полная автоматизация через Ansible оставлена вам в качестве упражнения.

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

Перед этим, тем не менее, мы рассмотрим некоторые нюансы управления пакетами DEB в Pulp по сравнению с управлением на основании RPM.

Хотя и имеются незначительные отличия в структуре командной строки между подключаемыми модулями репозитория на основе RPM и репозитория DEB, в целом эти процессы схожи. Как и ранее, требуются некие предварительные сведения относительно самой структуры репозитория для создания действенного зеркала. В данной книге мы будем работать с сервером 18.04 LTS Ubuntu, а его множество репозиториев по умолчанию настраивается таким образом:

Имеются также и прочие репозитории, такие как backports, а дополнительно к соответствующему компоненту main (с которым мы и будем тут иметь дело), имеется широкий массив пакетов, доступных в соответствующих компонентах restricted, universe и multiverse. Более подробное обсуждение структуры репозитория Ubuntu выходит за рамки данной книги, но достаточно сказать что имеется широкий массив доступной по этой теме документации. Хорошей отправной точкой для чтения о различных репозиториях, которые вы можете пожелать зеркалировать является следующая ссылка:https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories_and_Updates.

Теперь давайте допустим, что мы обновляем некую минимальную сборку сервера 18.04 LTS Ubuntu. Для этого нас интересуют лишь пакеты из компонента main, однако нам не требуется моментальный снимок всех исправлений безопасности на данный момент времени, как мы это делали для своей сборки CentOS 7:

Стоит обратить внимание на то,что репозитории Ubuntu имеют тенденцию быть намного более крупными чем их конкуренты из CentOS, в особенности в отношении updates и security. В процессе синхронизации все пакеты временно выгружаются в /var/cache/pulp перед их архивированием в соответствующем каталоге /var/lib/pulp. Когда /var/cache/pulp пребывает в файловой системе вашего корня, существует некая опасность переполнения вашей корневой файловой системы, а раз так, может оказаться лучшим создавать для этой цели некий новый том и монтировать его в /var/cache/pulp для предотвращения ситуации с переполнением диска и остановом вашего сервера Pulp.

Подключаемый модуль DEB для Pulp снабжён теми же самыми свойствами дедупликации пакетов, что и его конкурент RPM и публикует пакеты поверх HTTPS (и опционально HTTP) точно так же. при нескольких изменениях в синтаксе самих команд мы можем действенно создавать снимки исходящих репозиториев Linux для большинства основных репозиториев, которые мы находим в корпоративных средах.

В результате выполнения данного раздела вы изучили как создавать свои собственные зеркала в Pulp как для содержимого на основании RMP,так и на основании DEB, которые могут рассматриваться как стабильные и неизменные, а следовательно представляющие исключительную основу для управления исправлениями в неком предприятии.

В своём следующем разделе этой главы мы рассмотрим как развёртывать эти репозитории в двух различных типах серверов Linux.

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

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

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

Давайте начнём с рассмотрения того как вносить правки в системы на основе RPM при помощи сочетания Ansible и Pulp.

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

Собственно процесс некой сборки CenTOS из этих репозиториев, на верхнем уровне, выполняется так:

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

[centos-os]
name=CentOS-os
baseurl=https://pulp.example.com/pulp/repos/centos76-os
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
sslverify=0

[centos-updates]
name=CentOS-updates
baseurl=https://pulp.example.com/pulp/repos/centos7-07aug19
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
sslverify=0
 	   

В этой настройке нет ничего особенно уникального - мы применяем созданный нами ранее при помощи pulp-admin свой репозиторий relative-url. Для проверки целостности пакетов мы используем GPG, совместно со значением ключа GPG RPM CentOS 7, который, как нам известно, мы уже установили в своей машине CentOS 7. Единственная регулировка, которую мы выполнили здесь по сравнению со стандартной настройкой состоит в отключении удостоверения SSL, так как наш сервер демонстрации Pulp снабжён самостоятельно подписываемым сертификатом. Конечно же, если бы мы применяли корпоративный сертификат авторизации и соответствующие сертификаты CA были бы установлены на всех машинах, тогда этой проблемы бы не существовало.

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

Давайте начнём с создания некой роли с названием pulpconfig для развёртывания верной конфигурации - tasks/main.yml, которая должна выглядеть как- то так:

---
- name: Create a directory to back up any existing REPO configuration
  file:
    path: /etc/yum.repos.d/originalconfig
    state: directory

- name: Move aside any existing REPO configuration
  shell: mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/originalconfig

- name: Copy across and populate Pulp templated config
  template:
    src: templates/centos-pulp.repo.j2
    dest: /etc/yum.repos.d/centos-pulp.repo
    owner: root
    group: wheel

- name: Clean out yum database
  shell: "yum clean all"
 	   

Идущий в комплекте шаблон templates/centos-pulp.repo.j2 должен выглядеть следующим образом:

[centos-os]
name=CentOS-os
baseurl=https://pulp.example.com/pulp/repos/{{ centos_os_relurl }}
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
sslverify=0

[centos-updates]
name=CentOS-updates
baseurl=https://pulp.example.com/pulp/repos/{{ centos_updates_relurl }}
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
sslverify=0
 	   

Обратите внимание на сделанные нами подстановки переменной в самом конце каждой из строк baseurl - это позволит нам придерживаться одного и того же шаблона (который должен быть совместным для большинства целей), но при этом менять URL репозитория со временем, приспосабливаясь к обновлениям.

Далее мы определим вторую роль специально для обновлений самого ядра - это будет очень походить на наш пример, а tasks/main.yml будет содержать следующее:

---
- name: Update the kernel
  yum:
    name: kernel
    state: latest
 	   

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

---
- name: Install Pulp repos and update kernel
  hosts: all
  become: yes
  vars:
    centos_os_relurl: "centos76-os"
    centos_updates_relurl: "centos7-07aug19"

  roles:
    - pulpconfig
    - updatekernel
 	   

Теперь, когда мы выполним это как обычно, мы обнаружим вывод схожий с таким:

До сих пор всё хорошо - значения состояний changed из предыдущего воспроизведения сообщает нам что наша новая конфигурация была успешно применена.

Теперь, как я уверен, вы заметили, что самым замечательным моментом в данном подходе является то, что, допустим, когда вы желаете проверить свой снимок репозитория 08aug19, который мы создали в своём предыдущем разделе, нам следует внести изменения в значение блока vars: из site.yml с тем, чтобы он выглядел так:

vars:
    centos_os_relurl: "centos76-os"
    centos_updates_relurl: "centos7-08aug19"
 	   

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

Таким образом, сочетание Ansible с Pulp само по себе приводит к по- настоящему стабильной инфраструктуре предприятия для управления и распространения (и даже проверки) обновлений. Тем не менее, прежде чем мы рассмотрим этот процесс в Ubuntu, вернемся на пару слов ранее. В своём предыдущем разделе мы предположили что некий пример со снимком на 08aug19 отказал при проверке, а потому подлежал удалению. Что касается серверов CentOS 7, откаты в них не столь прямолинейны как простая установка более ранних определений репозиториев и осуществление обновления, так как такое обновление выявит установленными более новые версии и не предпримет никаких действий.

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

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

Затме мы можем (если мы выбрали именно это) откатить данную транзакцию при помощи отображаемой на следующем снимке экрана команды:

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

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

На самом верхнем уровне процесс управления обновлениями Ubuntu с сервера Pulp в точности тот же самый что и тот, кторым мы управляли обновлениями на основании RPM для CentOS (с сохранением того факта, что мы не не обладаем никаким вариантом относящимся к использованию Потребителя Pulp и должны пользоваться Ansible для данного процеса обновлений).

Однако, когда мы приступаем к использованию Pulp с системой APT репозитория Ubuntu, имеется пара ограничений:

Осознавая оба этих ограничения, мы можем определить свой файл источников APT для того набора репозиториев, который мы создали ранее. Следуя примерам своего предыдущего раздела, наш файл /etc/apt/sources.list должен выглядеть как- то так:

deb [trusted=yes] http://pulp.example.com/pulp/deb/bionic-amd64-08aug19 bionic main
deb [trusted=yes] http://pulp.example.com/pulp/deb/bionic-security-amd64-08aug19 bionic-security main
deb [trusted=yes] http://pulp.example.com/pulp/deb/bionic-updates-amd64-08aug19 bionic-updates main
		

Значение строки [trusted=yes] требует игнорировать отсутствия подписей пакетов от соответствующего диспетчера пакетов APT. Сама по себе структура файла невероятно простая, а потому так же как и для примера с CentOS, мы можем создать некий файл шаблона с тем, чтобы соответствующий URL мог запоняться с помощью некой переменной:

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

Как и в случае с CentOS, когда некий новый набор пакетов не подходит для промышленного применения, Ansible делает простым восстановление предыдущей конфигурации репозитория. Тем не менее, откат пакетов в Ubuntu (и прочих дистрибутивах на основе Debian) обратно намного более требовательный к работе вручную процесс, чем тот, что мы наблюдали в своём предыдущем разделе. К счастью, имеется обильная история относительно транзакций пакетов, хранимая в /var/log/dpkg.log и в /var/log/apt/history.log*, которой можно воспользоваться для определения того, какие именно мы пакеты устанавливали и/ или обновляли и когда. Далее для установки некой конкретной версии пакетов можно применить команду apt-get с использованием синтаксиса apt-get install <packagename>=<version>. В интернете имеется множемтво решений в сценариях для данной задачи, а потому это оставляется вам для определения того какое из них лучше всего подходит для ваший потребностей и вашей среды.

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

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

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

Для более глубоких подробностей проекта Pulp и того как применять данный инструментарий, будьте добры ознакомиться с официальной документацией.