Разбираемся с развёртыванием CodeReady Containers на Linux

Подумываете ли вы о том, чтобы использовать Red Hat CodeReady Containers (CRC) для решения задач локальной OpenShift-разработки? Собираетесь ли устанавливать CRC на Linux? В этом материале я хочу рассказать именно об этом. Мы обсудим некоторые особенности работы CRC и поговорим о настройке контейнеров.



Тут используется система CRC версии 1.21.0, в основе которой лежит OpenShift Container Platform (OCP) версии 4.6.9. Я устанавливаю CRC на Debian 10 GNU/Linux, но нам подойдёт любой современный дистрибутив Linux — вроде Fedora или Ubuntu. CRC 1.21.0 можно установить на Linux-хосте, который удовлетворяет следующим требованиям:

• На нём установлены KVM и libvirt.
• Его сетевые настройки выполняются с использованием NetworkManager.
• Пользователь, устанавливающий CRC, имеет sudo-доступ к этому хосту.

Перед установкой CRC нужно будет загрузить tarball-дистрибутив CRC и так называемый «pull secret». «Pull secret» — это JSON-файл, который содержит аутентификационную информацию, необходимую для доступа к защищённым реестрам образов, поддерживаемым Red Hat. Если вы не являетесь клиентом Red Hat — вы можете присоединиться к Red Hat Developer Program, к программе Red Hat для разработчиков, и бесплатно загрузить этот файл. Участие в этой программе позволяет, кроме того, загрузить tarball-дистрибутив CRC. А отсюда дистрибутив можно скачать без лишних формальностей.

CRC отличается замечательной документацией, которая дополняется по мере выхода новых релизов системы.

Обзор порядка развёртывания CodeReady Containers

Если описать работу CRC в общих чертах, то окажется, что эта система создаёт виртуальную машину, на которой работает OpenShift-кластер, состоящий из одного узла. Этот узел одновременно играет и роль главного узла (master node), и роль рабочего узла (worker node). Платформа OpenShift не устанавливается при развёртывании CRC. CRC запускает OpenShift из предустановленного образа виртуальной машины. Процесс развёртывания CRC показан на следующей схеме.


Развёртывание CRC

CRC, работая на Linux-хосте, использует libvirt для создания сети, пула хранения данных и виртуальной машины CRC. Данные этой виртуальной машины хранятся на постоянной основе в томе libvirt. Это обеспечивает то, что объекты, создаваемые пользователем в OpenShift, не будут исчезать после перезагрузок CRC.

У экземпляра OpenShift имеется фиксированный набор хранилищ PersistentVolume. Пользователи могут подключать эти хранилища к подам приложений, выполняя запросы PersistentVolumeClaim (PVC). Тут поддерживаются все режимы доступа к хранилищам: ReadWriteOnce, ReadWriteMany и ReadOnlyMany. Содержимое постоянных хранилищ информации размещается на хосте, в директории /var/mnt/pv-data.

А как насчёт интегрированного реестра образов? В основе реестра образов в OpenShift лежит хранилище PersistentVolume, работа с которым организована через общедоступный маршрут default-route-openshift-image-registry.apps-crc.testing. Пользователи могут применять этот маршрут для отправки образов своих контейнеров в реестр до запуска их в OpenShift.

Последнее, на что стоит обратить внимание, анализируя вышеприведённую схему, представлено конфигурацией DNS. Зачем это нужно? CRC настраивает разрешение DNS-имён на Linux-хосте таким образом, чтобы запросы к конечным точкам api.crc.testing и *.apps-crc.testing перенаправлялись бы к экземпляру OpenShift. Программа NetworkManager, нужная для работы CRC, используется для выполнения таких настроек DNS. CRC просит NetworkManager развернуть экземпляр dnsmasq, который перенаправляет DNS-запросы для конечных точек OpenShift другому экземпляру dnsmasq, развёрнутому внутри виртуальной машины. А разрешением имён занимается именно этот второй экземпляр dnsmasq.

Настройка CodeReady Containers

В этом разделе мы поговорим о некоторых конфигурационных параметрах CRC, которые вам может понадобиться подстроить под свои нужды. По умолчанию виртуальной машине CRC даётся 4 vCPU, 8790 МиБ RAM и 31 Гиб дискового пространства. Эти значения, что зависит от конкретной ситуации, может понадобиться увеличить. Я, на своём настольном компьютере, предпочитаю увеличивать количество vCPU до 10. Сделать это можно с помощью следующей команды:

./crc config set cpus 10

Стандартный размер оперативной памяти в 8790 МиБ кажется мне достаточно скромным. Большая часть этой памяти используется компонентами OpenShift. В результате из 8790 МиБ памяти приложениям пользователя доступно лишь что-то наподобие 2 Гиб. На моём настольном компьютере достаточно много RAM. Обычно я повышаю размер памяти, доступной CRC, примерно до 46 ГиБ:

./crc config set memory 47104

Если говорить о дисковом пространстве, то, как уже было сказано, по умолчанию виртуальной машине CRC выделяется 31 ГиБ. Примерно половина этой ёмкости нам не доступна, так как она используется операционной системой Red Hat CoreOS и компонентами OpenShift. Около 16 ГиБ остаётся на нужды интегрированного реестра образов и других хранилищ информации (PVC), создаваемых для приложений. И, хотя стандартный размер дискового пространства в 31 ГиБ — это вполне прилично, я предпочитаю увеличивать этот показатель до 120 ГиБ, делая это лишь для того чтобы привести его в соответствие со стандартным дисковым пространством кластеров OCP. Обратите внимание на то, что CRC позволяет увеличивать размер дискового пространства не только при первоначальной настройке системы, но и в любое время после её установки. Для настройки размеров дискового пространства, доступного CRC, можно воспользоваться такой командой:

./crc config set disk-size 120

CRC необходим файл «pull secret» OpenShift. Я обычно указываю CRC путь к соответствующему файлу, который храню в защищённом месте домашней директории. Этот файл необходим OpenShift вне зависимости от того, как именно была произведена установка OpenShift. Тот же «pull secret», который использован для CRC, может быть применён для установки OpenShift с использованием установщика OpenShift. После того, как я загрузил нужный файл с сайта Red Hat и сохранил его по адресу ~/.mysecrets/ocp/pull-secret.json, мне нужно сообщить о его местоположении CRC:

./crc config set pull-secret-file ~/.mysecrets/ocp/pull-secret.json

И последний параметр, о котором мне хочется рассказать, это — consent-telemetry. Если заблаговременно его настроить, можно избежать вопроса Would you like to contribute anonymous usage statistics [y/N], который будет задавать CRC в процессе работы. Вот команда для настройки этого параметра:

./crc config set consent-telemetry yes

CRC сохраняет вышеописанные настройки в файле ~/.crc/crc.json. Если хотите — можете просто отредактировать этот файл. Полный список доступных конфигурационных параметров CRC можно узнать, выполнив следующую команду:

./crc config --help

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

Установка CodeReady Containers

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

./crc setup

А пока всё устанавливается — поговорим о бинарном файле CRC. Обратили ли вы внимание на то, что этот файл довольно-таки велик? В частности, его размер для CRC 1.21.0 составляет примерно 2,6 ГиБ. Почему он такой большой? Для того чтобы ответить на этот вопрос — давайте исследуем его структуру, схематическое представление которой представлено ниже.


Структура бинарного файла CRC

Бинарник CRC состоит из четырёх частей. Первая часть — это исполняемый код CRC. Вторая — это утилита admin-helper-linux, которая используется для обновления файла /etc/hosts. Третья — это исполняемый код демона crc-driver-libvirt, который реализует специфические функции виртуализации libvirt и абстрагирует детали виртуализации от ядра CRC. Четвёртая часть — это так называемый «CRC-бандл» (на схеме это crc_libvirt_4.6.9.crcbundle). Этот бандл содержит образ виртуальной машины и именно на его долю приходится большая часть размера бинарника CRC.

Теперь вернёмся к установке CRC. На начальной стадии работы команда ./crc setup извлекает все компоненты, прикреплённые к исполняемому коду CRC, и размещает их в директории ~/.crc. Встроенный в бинарник CRC-бандл представлен архивом tar.xz, который тут же распаковывается в папку ~/.crc/cache. В бандле содержатся следующие материалы:

• Файл crc-bundle-info.json несёт в себе метаданные бандла. CRC обращается к этому файлу в процессе развёртывания системы.
• Образ виртуальной машины crc.qcow2 содержит предустановленный узел OpenShift. Этот образ будет использован в качестве базы для образа диска виртуальной машины CRC.
• Временный ключ id_ecdsa_crc используется CRC для подключения к виртуальной машине по SSH на начальном этапе работы, сразу после её первого запуска. После подключения к виртуальной машине CRC генерирует новую уникальную пару SSH-ключей и добавляет их в файл машины ~core/.ssh/authorized_keys. Временный SSH-ключ удаляется из этого файла, а значит — его больше нельзя будет использовать для подключения к соответствующей виртуальной машине.
• В файле kubeadmin-password хранится пароль пользователя kubeadmin в OpenShift.
• Файл kubeconfig позволяет входить в OpenShift в виде пользователя kube:admin. Этот файл включает в себя приватный ключ, необходимый для успешного прохождения процедуры аутентификации.
• Исполняемый файл oc — это клиент oc, версия которого соответствует версии OpenShift-кластера, входящего в состав бандла.

После того, как процедура извлечения компонентов CRC завершится, директория ~/.crc будет выглядеть так:

tree --noreport .crc
.crc
├── bin
│   ├── admin-helper-linux
│   ├── crc-driver-libvirt
│   └── oc
│       └── oc -> /home/anosek/.crc/cache/crc_libvirt_4.6.9/oc
├── cache
│   ├── crc_libvirt_4.6.9
│   │   ├── crc-bundle-info.json
│   │   ├── crc.qcow2
│   │   ├── id_ecdsa_crc
│   │   ├── kubeadmin-password
│   │   ├── kubeconfig
│   │   └── oc
│   └── crc_libvirt_4.6.9.crcbundle
└── crc.json

Следующий достойный внимания шаг, выполняемый в процессе установки CRC, представляет собой настройку DNS на Linux-хосте. CRC настраивает DNS так, чтобы запросы на подключение к конечным точкам api.crc.testing и *.apps-crc.testing перенаправлялись бы к экземпляру OpenShift. Заранее известно то, что данный экземпляр OpenShift собирается открыть свои конечные точки на жёстко заданном IP-адресе 192.168.130.11. Как же CRC добивается правильного разрешения DNS-имён для конечных точек OpenShift? CRC создаёт для этого файл /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf, содержащий следующую настройку:

[main]
dns=dnsmasq

Эта настройка сообщает NetworkManager о том, что, во-первых, надо запустить экземпляр dnsmasq, а во-вторых — что надо модифицировать файл /etc/resolv.conf на компьютере так, чтобы этот экземпляр dnsmasq рассматривался бы как DNS-сервер, используемый по умолчанию. На следующем шаге CRC настраивает сервер dnsmasq, создавая конфигурационный файл /etc/NetworkManager/dnsmasq.d/crc.conf с таким содержимым:

server=/apps-crc.testing/192.168.130.11
server=/crc.testing/192.168.130.11

Благодаря этому DNS-запросы для доменов crc.testing и apps-crc.testing, а так же — для всех их поддоменов, перенаправляются к DNS-серверу 192.168.130.11. Этот DNS-сервер будет развёрнут внутри виртуальной машины CRC и будет отвечать за разрешение имён конечных точек OpenShift.

Обратите внимание на то, что вышеописанный перенаправляющий DNS-сервер создаётся только в том случае, если хост не использует для разрешения DNS-имён systemd-resolved. Если ваш хост использует systemd-resolved, это значит, что CRC настроит перенаправление с его помощью, не прибегая к запуску дополнительного перенаправляющего сервера dnsmasq.

На последнем этапе работы команды ./crc setup выполняется создание сети libvirt. Что для этого нужно? CRC создаёт libvirt-сеть с именем crc типа NAT. Единственный хост в этой сети получит IP-адрес 192.168.130.11:

virsh net-dumpxml crc
<network connections='1'>
  <name>crc</name>
  <uuid>49eee855-d342-46c3-9ed3-b8d1758814cd</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='crc' stp='on' delay='0'/>
  <mac address='52:54:00:fd:be:d0'/>
  <ip family='ipv4' address='192.168.130.1' prefix='24'>
    <dhcp>
      <host mac='52:fd:fc:07:21:82' ip='192.168.130.11'/>
    </dhcp>
  </ip>
</network>

В этой сети будет находиться виртуальная машина CRC. Этой виртуальной машине будет назначен MAC-адрес 52:fd:fc:07:21:82. Благодаря вышеприведённым настройкам этой машине назначается фиксированный IP-адрес 192.168.130.11. Оба эти адреса жёстко заданы в CRC.

Создание libvirt-сети было последним шагом установки CRC, о котором я хотел рассказать. В следующем разделе мы займёмся созданием и запуском виртуальной машины CRC.

Запуск CodeReady Containers

После того, как завершится работа команды ./crc setup, выполним следующую команду, которая позволяет создать и запустить виртуальную машину CRC:

./crc start

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

Сначала CRC запускает серию предварительных проверок, которые уже выполнялись в ходе работы команды ./crc setup. Они нужны для того чтобы удостовериться в том, что то, что имеет отношение к CRC, всё ещё находится в хорошем состоянии.

Далее CRC создаёт libvirt-пул хранения данных, называемый crc и располагающийся в директории ~/.crc/machines/crc. В этом пуле создаётся образ диска для виртуальной машины crc.qcow2 размером 120 ГиБ. Мы выбрали именно этот размер, настроив параметр disk-size в одном из предыдущих разделов. Это — так называемый «thin-provisioned-образ». Он не сразу занимает всё выделенное ему пространство, его физический размер увеличивается по мере необходимости, при записи в него данных. CRC, кроме того, поддерживает изменение размера этого образа. Если пользователь решит изменить параметр disk-size — CRC изменит образ перед запуском виртуальной машины. Описание пула хранения данных libvirt может выглядеть так, как показано ниже:

virsh pool-dumpxml crc
<pool type='dir'>
  <name>crc</name>
  <uuid>ecfe5181-6476-43a8-9ff9-a133841df011</uuid>
  <capacity unit='bytes'>1769532428288</capacity>
  <allocation unit='bytes'>1119201026048</allocation>
  <available unit='bytes'>650331402240</available>
  <sоurce>
  </sоurce>
  <target>
    <path>/home/anosek/.crc/machines/crc</path>
    <permissions>
      <mode>0755</mode>
      <owner>1000</owner>
      <group>1000</group>
    </permissions>
  </target>
</pool>

После того, как образ диска для виртуальной машины готов, CRC создаёт саму виртуальную машину и запускает её. Эта виртуальная машина носит имя crc, посмотреть её описание можно так:

virsh dumpxml crc
<domain type='kvm' id='2'>
  <name>crc</name>
  <uuid>4269a53d-0fa7-465e-9190-ab33047244ee</uuid>
  <memory unit='KiB'>46000128</memory>
  <currentMemory unit='KiB'>46000128</currentMemory>
  <vcpu placement='static'>10</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
...

  <devices>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' io='threads'/>
      <source file='/home/anosek/.crc/machines/crc/crc.qcow2' index='1'/>
      <backingStore type='file' index='2'>
        <format type='qcow2'/>
        <source file='/home/anosek/.crc/cache/crc_libvirt_4.6.9/crc.qcow2'/>
        <backingStore/>
      </backingStore>
...

</domain>

Количество vCPU и размер оперативной памяти виртуальной машины соответствуют ранее настроенным параметрам cpus и memory. Из кода описания виртуальной машины можно узнать о том, что машина базируется на образе ~/.crc/machines/crc/crc.qcow2. А этот образ, на самом деле, является лишь образом-наложением (overlay image), в основе которого лежит базовый образ ~/.crc/cache/crc_libvirt_4.6.9/crc.qcow2. В начале работы образ-наложение пуст. В него попадает то, что пишет на диск виртуальная машина CRC. Все изменения, внесённые в данные виртуальной машиной, на постоянной основе хранятся в образе-наложении, они не теряются после перезапуска машины. Это значит, что конфигурация OpenShift никуда не исчезнет в промежутке между выполнением команд ./crc stop и ./crc start.

Далее, CRC создаёт новую пару SSH-ключей, которая будет использоваться для подключения к виртуальной машине по SSH с учётной записью пользователя core. Публичный ключ из этой пары добавляется в файл ~core/.ssh/authorized_keys виртуальной машины, что и позволяет пользователю core к ней подключаться. CRC использует SSH для выполнения дальнейших настроек виртуальной машины в процессе её запуска.

Если пользователь поменял параметр disk-size, это значит, что файловая система нуждается в расширении, выполняемом для того, чтобы она охватывала бы всё доступное дисковое пространство. Это достигается путём выполнения команды xfs_growfs / внутри виртуальной машины. Как уже было сказано, по умолчанию в CRC в качестве размера диска установлен 31 ГиБ. В этот момент файловая система расширяется до 120 ГиБ, до того размера, который мы задали в ходе настройки CRC.

Теперь CRC запускает внутри виртуальной машины DNS-сервер — podman-контейнер, в котором работает dnsmasq. Этот DNS-сервер разрешает доменные имена *.apps-crc.testing, api.crc.testing и api-int.crc.testing в IP-адрес 192.168.130.11, который является адресом самой виртуальной машины. Эти доменные имена назначены широко известным конечным точкам OpenShift, то есть, соответственно — входному маршрутизатору, серверу API и точке доступа к внутреннему API. Этот DNS-сервер используется и виртуальной машиной, и Linux-хостом. Запросы хоста доходят до этого сервера благодаря перенаправляющему DNS-серверу, о котором мы говорили выше.

В процессе запуска виртуальной машины CRC добавляет в /etc/hosts Linux-хоста следующую строчку:

192.168.130.11 api.crc.testing console-openshift-console.apps-crc.testing default-route-openshift-image-registry.apps-crc.testing oauth-openshift.apps-crc.testing

Я не знаю точно — для чего это делается. Разрешение вышеупомянутых имён уже выполняется dnsmasq-сервером, который работает внутри виртуальной машины CRC. Но полагаю, что, в любом случае, полезно знать о том, что CRC пишет эти данные в /etc/hosts.

На следующем шаге запуска виртуальной машины CRC запускает службу kubelet, которая, в свою очередь, запускает службы OpenShift. Если сертификат клиента kubelet истёк в то время, пока виртуальная машина CRC была выключена, kubelet выполнит запрос на подпись сертификата (Certificate Signing Request, CSR) для получения нового сертификата. CRC выполняет проверку на наличие новых CSR и автоматически их одобряет.

На последнем шаге запуска CRC добавляет файл «pull secret» пользователя в кластер OpenShift.

Конфигурационные данные, имеющие отношение к конкретному экземпляру виртуальной машины CRC, хранятся в директории .crc/machines/crc. Взглянуть на них можно так:

tree --noreport .crc/machines
.crc/machines
└── crc
    ├── config.json
    ├── crc.qcow2
    ├── id_ecdsa
    ├── id_ecdsa.pub
    └── kubeconfig

Если сейчас вам удалось запустить собственную виртуальную машину CRC — примите поздравления!

Полезные команды CodeReady Containers

В этом разделе мне хотелось бы рассказать о нескольких командах, которые пригодятся тем, кто пользуется CRC.

Для того чтобы открыть в браузере, используемом по умолчанию, OpenShift Web Console — воспользуйтесь такой командой:

./crc console

Так можно вывести сведения об учётных данных пользователя OpenShift:

./crc console --credentials
To login as a regular user, run 'oc login -u developer -p developer https://api.crc.testing:6443'.
To login as an admin, run 'oc login -u kubeadmin -p HqC3I-wgtiB-q7qCf-KEsuK https://api.crc.testing:6443

К виртуальной машине CRC можно подключиться по SSH в виде пользователя core:

ssh -i ~/.crc/machines/crc/id_ecdsa core@api.crc.testing

У этого пользователя есть полные административные привилегии, доступные через команду sudo.

Итоги

В этом материале раскрыты вопросы развёртывания CodeReady Containers на Linux-хосте. Мы начали с рассмотрения требований к системе, на которой планируется запускать CRC. В разделе, посвящённом обзору установки CRC, мы поговорили о том, как CRC взаимодействует с libvirt для обеспечения работы виртуальной машины OpenShift. Мы, кроме того, обсудили особенности настроек DNS, выполняемых CRC. Перед тем, как переходить к запуску системы, мы рассмотрели особенности настройки CRC и предоставили в распоряжение виртуальной машины дополнительные ресурсы в размерах, превышающих те, которые используются по умолчанию. Мы подробно разобрали установку и запуск CRC. И, наконец, я рассказал о нескольких командах, которые кажутся мне полезными.

Вот моё видео, посвящённое развёртыванию CRC на Linux.

Надеюсь, вам было интересно читать мой рассказ о CodeReady Containers.

Пользуетесь ли вы Red Hat CodeReady Containers?