Использование OpenShift в Azure
Применимо к: ✔️ виртуальные машины Linux ✔️ гибкие масштабируемые наборы
OpenShift — это открытая и расширяемая платформа приложений-контейнеров, которая позволяет использовать Docker и Kubernetes на предприятии.
OpenShift включает Kubernetes для оркестрации контейнеров и управления ими. Здесь добавлены инструменты для разработчиков и операций, позволяющие:
Существует несколько доступных версий OpenShift. Из этих версий только две пользователи могут использовать для развертывания в Azure: платформа контейнеров OpenShift и OKD (прежнее название OpenShift Origin).
Azure Red Hat OpenShift
Microsoft Azure Red Hat OpenShift представляет собой полностью управляемое предложение OpenShift, выполняемое в Azure. Эта служба управляется и поддерживается совместно корпорацией Майкрософт и Red Hat. Дополнительные сведения см. в документации по службе Azure Red Hat OpenShift.
Платформа контейнеров OpenShift
OpenShift Container Platform — это коммерческая версия корпоративного класса, которая разрабатывается и поддерживается компанией Red Hat. Чтобы использовать эту версию, клиенты должен приобрести необходимые права доступа к платформе OpenShift Container Platform. Кроме того, они сами устанавливают и администрируют всю инфраструктуру.
Так как клиенты являются владельцами самой платформы, они могут установить ее в локальном центре обработки данных или в общедоступном облаке (например, в Azure).
OKD — это высокоуровневый проект OpenShift с открытым кодом, который поддерживается сообществом. OKD можно установить в ОС CentOS или Red Hat Enterprise Linux (RHEL).
Используем OpenShift (пример развертывания)
Вступление
/app-root/data). Разница в том, что локальный репозиторий содержит настроечные скрипты (action_hooks, см. ниже) и файлы данных, патчи, etc. Но не само приложение целиком.
Мини-руководство иллюстрирует ряд приемов работы с OpenShift. Работа с github.com, git детально не разбирается, предполагается, что читатель уже имеет представление.
Руководство «step-by-step», основанное на реальном примере.
Перед началом
Установка на любой PaaS-хостинг(тот же Redhat Openshift) требует, соблюдения его спецификаций:
Регистрация: здесь
Установка клиента: здесь (Вы уже зарегистрированы), там же и документация, но на вся English
Не беспокойтесь об ОС работает почти везде одинаково. Да и Ваше приложение, как ни крути под RHEL 6.7.
Предложат создать домен (это поддомен 3-го уровня, ваши приложения будут иметь адрес http://myapp-mydom.rhcloud.com).
Все необходимые данные хранятся в переменных окружения вида OPENSHIFT_, справочник.
Приступаем
Приложение SalesPlatform-6.4.0, самоустанавливающийся LAMP.
Система CentOS 7.2 (но разница в деталях).
мое приложение example, Ваше — на Ваше усмотрение. (В имени могут быть только латинские буквы и цифры).
мой репозиторий на github.com https://github.com/zirf0/example, подсматривайте, если что.
Создаем «заглушку» и клонируем ее в свой домашний каталог.
$rhc app create example php-5.3 mysql-5.5
$cd example
Строго говоря нас интересуют action_hooks. Это набор скриптов для различных целей, но для нашего примера мы используем только build и deploy, вообще имена скриптов соответствуют производимому действию. Будем решать простенькую задачу:
Выкачать исходники на PaaS-хостинг.
Внести изменения (как правило, обязательно заменить переменные доступа к СУБД на встроенные OpenShift).
/.ssh/id_rsa.pub. Добавьте его согласно инструкции на github.com.
Заливаем наши труды на github.com
$git push upstream master
Развертываем приложение на PaaS Openshift:
$git push
Что эквивалентно $git push origin master.
Все, через web должна запуститься установка.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
OpenShift
Содержание
Обзор
OpenShift включает Kubernetes для оркестрации контейнеров и управления ими. Здесь добавлены инструменты для разработчиков и операций, позволяющие:
Существует несколько версий OpenShift:
Платформа контейнеров OpenShift
OpenShift Container Platform — это коммерческая версия корпоративного класса, которая разрабатывается и поддерживается компанией Red Hat. Чтобы использовать эту версию, клиенты должен приобрести необходимые права доступа к платформе OpenShift Container Platform. Кроме того, они сами устанавливают и администрируют всю инфраструктуру. Так как клиенты являются владельцами платформы, они могут установить ее в локальном центре обработки данных или в общедоступном облаке (Azure, AWS или Google).
OpenShift в Azure
OpenShift в Azure — это полностью управляемое предложение OpenShift, выполняемое в Azure. Эта служба управляется и поддерживается совместно корпорацией Майкрософт и Red Hat. Кластер будет развернут в подписку Azure клиента. В настоящий момент служба находится в закрытой предварительной версии, а в начале CY 2019 планируется выпустить общедоступную версию. Дополнительные сведения будут представлены, когда предложение будет ближе к общедоступной версии. OKD (прежнее название — OpenShift Origin); OKD — это высокоуровневый проект OpenShift с открытым кодом, который поддерживается сообществом. OKD можно установить в ОС CentOS или Red Hat Enterprise Linux (RHEL).
OpenShift Dedicated
OpenShift Dedicated — это управляемая Red Hat однотенантная (получающая доступ к другим службам в выделенной среде) OpenShift, которая использует платформу контейнеров OpenShift. Red Hat управляет всей базовой инфраструктурой (виртуальными машинами, кластером OpenShift, сетью, хранилищем и т. д.). Кластер связан только с одним клиентом и выполняется в общедоступном облаке (AWS или Google). Начальный кластер включает четыре узла приложений, и все затраты — ежегодные и оплачиваются заранее.
OpenShift Online
OpenShift Online — это мультитенантная(обращающаяся к службам в общей среде в нескольких организациях) платформа OpenShift (на базе Container Platform) под управлением Red Hat. Red Hat управляет всей базовой инфраструктурой (виртуальными машинами, кластером OpenShift, сетью и хранилищем).
Чтобы использовать эту версию, клиенты развертывают контейнеры, но при этом они не могут выбирать, на каких узлах эти контейнеры выполняются. Так как OpenShift Online — это мультитенантная среда, контейнеры могут размещаться на тех же узлах виртуальных машин, что и контейнеры других клиентов. Стоимость вычисляется из расчета на один контейнер.
Преимущества для разработчиков
Преимущества для специалистов IT-систем
Общие предварительные требования для развертывания OpenShift в Azure
При установке OpenShift используются модули playbook Ansible. Чтобы выполнить действия по установке, Ansible использует Secure Shell (SSH) для подключения ко всем узлам кластера. Когда Ansible создает SSH-подключение к удаленным узлам, нет возможности ввести пароль. Поэтому развертывание завершится сбоем, если с закрытым ключом связана парольная фраза. Так как все виртуальные машины развертываются с помощью шаблонов Azure Resource Manager, для доступа к ним используется один открытый ключ. Нужно включить соответствующий закрытый ключ в виртуальную машину, на которой также выполняются все модули playbook. Чтобы сделать это безопасно, используйте Azure Key Vault для передачи закрытого ключа в виртуальную машину. Если контейнерам требуется постоянное хранилище, вам понадобятся постоянные тома. OpenShift поддерживает виртуальные жесткие диски Azure (VHD) для этой возможности, но сначала требуется настроить Azure в качестве поставщика облачных услуг. В этой модели OpenShift выполняет следующие действия:
Чтобы эта конфигурация работала, OpenShift нужны разрешения на выполнение указанных выше задач в Azure. Это достигается с помощью субъекта-службы. Субъект-служба — это учетная запись безопасности в Azure Active Directory, которой предоставляются разрешения на доступ к ресурсам. Субъект-служба должна иметь доступ к учетным записям хранения и виртуальным машинам, входящим в состав кластера. При развертывании всех ресурсов кластера OpenShift в одной группе ресурсов субъект-служба может получить разрешения на доступ к этой группе ресурсов. В этом руководстве описывается создание артефактов, связанных с необходимыми компонентами.
Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу.
Вход в azzure
Входим в Azure с помощью команды az login и следуем инструкциям на экране или щелкаем «Попробовать», чтобы использовать Cloud Shell.
Создание группы ресурсов
Создание хранилища ключей
Создайте хранилище ключей, где будут храниться ключи SSH для кластера, с помощью команды az keyvault create. Имя хранилища ключей должно быть глобально уникальным. В следующем примере создается хранилище ключей с именем keyvault в группе ресурсов keyvaultrg:
Создание ключа SSH
Ключ SSH необходим для защиты доступа к кластеру OpenShift. Создаем пару ключей SSH с помощью команды ssh-keygen (в Linux или macOS):
Сохранение закрытого ключа SSH в Azure Key Vault
Развертывание OpenShift использует созданный ключ SSH, чтобы защитить доступ к основному кластеру OpenShift. Чтобы обеспечить для развертывания безопасное извлечение ключа SSH, следует ключ в Key Vault с помощью следующей команды:
Создание субъекта-службы
OpenShift взаимодействует с Azure, используя имя пользователя и пароль или субъект-службу. Субъект-служба Azure является удостоверением безопасности, которое можно использовать с приложениями, службами и инструментами автоматизации, такими как OpenShift. Разработчик определять разрешения на то, какие операции может выполнять субъект-служба в Azure, и управлять ими. Рекомендуется ограничить область разрешений субъекта-службы определенными группами ресурсов, а не всей подпиской. Создаем субъект-службу с помощью команды az ad sp create-for-rbac и выведем учетные данные, необходимые для OpenShift: В следующем примере создается субъект-служба, а группе ресурсов с именем openshiftrg назначаются разрешения участника. Прежде всего создаем группу ресурсов с именем openshiftrg:
Далее рассмотрим как развернуть сам кластер OpenShift.
Развертывание платформы контейнеров OpenShift в Azure
Для развертывания платформы OpenShift Container Platform в Azure можно использовать один из нескольких способов: Можно вручную развернуть необходимые компоненты инфраструктуры Azure, а затем следовать инструкциям из документации по платформе OpenShift Container Platform. Также можно использовать существующий шаблон Resource Manager, упрощающий развертывание кластера платформы OpenShift Container Platform. Другой вариант — использовать предложение Azure Marketplace. Для всех вариантов подписка Red Hat является обязательной. Во время развертывания экземпляр Red Hat Enterprise Linux регистрируется в подписке Red Hat и связывается с идентификатором пула, который содержит права доступа к платформе OpenShift Container Platform. Убедитесь, что у вас есть действительное имя пользователя, пароль и идентификатор пула диспетчера подписки Red Hat (RHSM). Можно также использовать ключ активации, идентификатор организации и идентификатор пула. Данные можно проверить, войдя на сайт https://access.redhat.com.
Развертывание платформы контейнеров OpenShift с помощью шаблона Resource Manager
Для развертывания с использованием шаблона Resource Manager используется файл параметров, в котором указываются входные параметры. Для дополнительной настройки развертывания следует создать вилку репозитория GitHub и измените нужные элементы. Например, достаточно часто возникает потребность изменить следующие параметры:
Настройка файла параметров
Разные выпуски могут иметь разные параметры, поэтому следует проверить необходимые параметры для используемой ветви.
Развертывание с помощью Azure CLI
В примере ниже кластер OpenShift и все связанные ресурсы развертываются в группу ресурсов openshiftrg с именем развертывания myOpenShiftCluster. Репозиторий GitHub ссылается непосредственно на шаблон, при этом используется локальный файл параметров с именем azuredeploy.parameters.json.
Для завершения развертывания требуется не менее 30 минут в зависимости от общего количества развертываемых узлов и настроенных параметров. После завершения развертывания в терминале отобразятся полное доменное имя DNS узла-бастиона и URL-адрес консоли OpenShift.
Развертывание платформы контейнеров OpenShift с помощью предложения Azure Marketplace
Для развертывания платформы OpenShift Container Platform в Azure проще всего использовать предложение Azure Marketplace. Это самый простой вариант, но он имеет ограниченные возможности для настройки. Предложение Marketplace включает в себя следующие параметры конфигурации: Master Nodes (Главные узлы): три главных узла, для которых можно указать тип экземпляра. Infra Nodes (Узлы Infra): три узла Infra, для которых можно указать тип экземпляра. Nodes (Узлы): здесь можно настроить число узлов (от 2 до 9) и тип экземпляров. Disk Type (Тип диска): используются Управляемые диски. Networking (Сеть): поддержка новой или существующей сети, а также пользовательского диапазона CIDR. CNS: позволяет включить CNS. Metrics (Метрики): позволяет включить метрики. Logging (Ведение журнала): позволяет включить ведение журнала. Azure Cloud Provider (Поставщик облачных служб): позволяет включить поставщик облачных служб.
Подключение к кластеру OpenShift
Очистка ресурсов
Azure Red Hat OpenShift
Служба Microsoft Azure Red Hat OpenShift позволяет развертывать полностью управляемые кластеры OpenShift.
Azure Red Hat OpenShift расширяет платформу Kubernetes. Для запуска контейнеров в рабочей среде с Kubernetes требуются дополнительные средства и ресурсы. Зачастую в их число входят необходимость использования реестров образов, управления хранением, сетевых решений, а также средств ведения журнала и мониторинга, все из которых должны иметь свою версию и быть совместно протестированы. Создание контейнерных приложений требует даже большей работы над интеграцией с ПО промежуточного слоя, платформами, базами данных и средствами CI/CD. Служба Azure Red Hat OpenShift объединяет все это в рамках одной платформы, что упрощает эксплуатацию для ИТ-отделов, предоставляя отделам по работе с приложениями только те задания, которые им нужно выполнить.
Корпорация Майкрософт и Red Hat совместно выполняют задачи разработки, администрирования и поддержки службы Azure Red Hat OpenShift, обеспечивая интегрированный процесс поддержки. На этой платформе нет виртуальных машин, которыми вам нужно управлять, и не требуется устанавливать исправления. Исправление, обновление и отслеживание главного узла, а также узлов инфраструктуры и приложений от вашего имени осуществляется компанией Red Hat и корпорацией Майкрософт. Кластеры Azure Red Hat OpenShift развертываются в подписке Azure и включаются в счет Azure.
Вы можете выбрать собственный реестр, сеть, хранилище и решения CI/CD или использовать встроенные решения для автоматического управления исходным кодом, создания контейнеров и приложений, а также их развертывания, масштабирования, управления состоянием работоспособности и многого другого. Служба Azure Red Hat OpenShift предоставляет возможности интеграции единого входа через Azure Active Directory.
Чтобы приступить к работе, выполните действия из руководства по созданию кластера Azure Red Hat OpenShift.
Доступ, безопасность и мониторинг
Для повышения безопасности и улучшения управления Azure Red Hat OpenShift позволяет выполнить интеграцию с Azure Active Directory и использовать управление доступом на основе ролей Kubernetes (Kubernetes RBAC). Также можно отслеживать работоспособность кластера и ресурсов.
Кластер и узел
Узлы Azure Red Hat OpenShift выполняются на виртуальных машинах Azure. Можно подключить хранилище к узлам и pod и обновить компоненты кластера.
Соглашение об уровне обслуживания
Azure Red Hat OpenShift предлагает соглашение об уровне обслуживания с гарантией доступности службы на уровне 99,95 %. Дополнительные сведения о соглашении об уровне обслуживания для Azure Red Hat OpenShift см. на этой странице.
Дальнейшие действия
Ознакомьтесь с необходимыми условиями для Azure Red Hat OpenShift:
Прости, OpenShift, мы недостаточно ценили тебя и принимали как должное
Этот пост написан поскольку у наших сотрудников было довольно много разговоров с клиентами о разработке приложений на Kubernetes и о специфике такой разработки на OpenShift.
Начинаем мы обычно с тезиса, что Kubernetes – это просто Kubernetes, а OpenShift – это уже Kubernetes-платформа, как Microsoft AKS или Amazon EKS. У каждой из этих платформ есть свои плюсы, ориентированные на ту или иную целевую аудиторию. И после этого разговор уже перетекает в сравнение сильных и слабых сторон конкретных платформ.
В общем, мы думали написать этот пост с выводом типа «Слушайте, да без разницы, где запускать код, на OpenShift или на AKS, на EKS, на каком-то кастомном Kubernetes, да на каком-угодно-Kubernetes (для краткости назовем его КУК) – это реально просто, и там, и там».
Затем мы планировали взять простейший «Hello World» и на его примере показать, что общего и в чем различия между КУК и Red Hat OpenShift Container Platform (далее, OCP или просто OpenShift).
Однако по ходу написания этого поста, мы поняли, что так давно и сильно привыкли использовать OpenShift, что просто не осознаем, как он вырос и превратился в потрясающую платформу, которая стала гораздо больше, чем просто Kubernetes-дистрибутив. Мы привыкли воспринимать зрелость и простоту OpenShift как должное, упуская из виду его великолепие.
В общем, пришла пора деятельного раскаяния, и сейчас мы пошагово сравним ввод в строй своего «Hello World» на КУК и на OpenShift, и сделаем это максимально объективно (ну разве что выказывая иногда личное отношение к предмету). Если вам интересно сугубо субъективное мнение по этому вопросу, то его можно прочитать здесь (EN). А в этом посте мы будем придерживаться фактов и только фактов.
Кластеры
Итак, для нашего «Hello World» нужны кластеры. Сразу скажем «нет» всяким публичным облакам, чтобы не платить за сервера, реестры, сети, передачу данных и т.д. Соответственно, мы выбираем простой одноузловой кластер на Minikube (для КУК) и Code Ready Containers (для кластера OpenShift). Оба этих варианта реально просты в установке, но потребуют довольно много ресурсов на вашем ноуте.
Сборка на КУК-е
Шаг 1 – собираем наш контейнерный образ
Начнем я с того, что развернем наш «Hello World» на minikube. Для этого потребуется:
Самый простой способ собрать наш «Hello World» в контейнерный образ – использовать расширения quarkus-maven для Docker’а, которые и проделают всю необходимую работу. С появлением Quarkus это стало действительно легко и просто: добавляете расширение container-image-docker и можете создавать образы командами maven.
И, наконец, выполняем сборку нашего образа, используя Maven. В результате наш исходный код превращается в готовый контейнерный образ, который уже можно запускать в среде исполнения контейнеров.
Вот, собственно, и всё, теперь можно запускать контейнер командой docker run, подмапив наш сервис на порт 8080, чтобы к нему можно было обращаться.
После того, как контейнерный инстанс запустился, остается только проверить командой curl, что наш сервис работает:
Итак, всё работает, и это было действительно легко и просто.
Шаг 2 – отправляем наш контейнер в репозиторий контейнерных образов
Пока что созданный нами образ хранится локально, в нашем локальном контейнерном хранилище. Если мы хотим использовать этот образ в своей среде КУК, то его надо положить в какой-то другой репозиторий. В Kubernetes нет таких функций, поэтому мы будем использовать dockerhub. Потому что, во-первых, он бесплатный, а во-вторых, (почти) все так делают.
Это тоже очень просто, и нужен здесь только аккаунт на dockerhub.
Итак, ставим dockerhub и отправляем туда наш образ.
Шаг 3 – запускаем Kubernetes
Есть много способов собрать конфигурацию kubernetes для запуска нашего «Hello World», но мы будем использовать наипростейший из них, уж такие мы люди…
Для начала запускаем кластер minikube:
Шаг 4 – развертываем наш контейнерный образ
Теперь надо преобразовать наш код и контейнерный образ в конфигурации kubernetes. Иначе говоря, нам нужен pod и deployment definition с указанием на наш контейнерный образ на dockerhub. Один из самых простых способов это сделать – запустить команду create deployment, указав на наш образ:
Этой командной мы сказали нашей КУК создать deployment configuration, которая должна содержать спецификацию pod’а для нашего контейнерного образа. Эта команда также применит эту конфигурацию к нашему кластеру minikube, и создаст deployment, который скачает наш контейнерный образ и запустит pod в кластере.
Шаг 5 – открываем доступ к нашему сервису
Теперь, когда у нас есть развернутый контейнерный образ, пора подумать, как сконфигурировать внешний доступ к этому Restful-сервису, который, собственно, и запрограммирован в нашем коде.
Тут есть много способов. Например, можно использовать команду expose, чтобы автоматически создавать соответствующие Kubernetes-компоненты, такие как services и endpoints. Собственно, так мы и сделаем, выполнив команду expose для нашего deployment-объекта:
Давайте на минутку остановимся на опции « — type» команды expose.
Когда мы делаем expose и создаем компоненты, необходимые для запуска нашего сервиса, нам, среди прочего, надо, чтобы снаружи можно было подключиться к службе hello-quarkus, которая сидит внутри нашей программно-определяемой сети. И параметр type позволяет нам создать и подключить такие вещи, как балансировщики нагрузки, чтобы маршрутизировать трафик в эту сеть.
Например, прописав type=LoadBalancer, мы автоматически инициализируем балансировщик нагрузки в публичном облаке, чтобы подключаться к нашему кластеру Kubernetes. Это, конечно, замечательно, но надо понимать, что такая конфигурация будет жестко привязана к конкретному публичному облаку и ее будет сложнее переносить между Kubernetes-инстансам в разных средах.
В нашем примере type=NodePort, то есть обращение к нашему сервису идет по IP-адресу узла и номеру порта. Такой вариант позволяет не использовать никакие публичные облака, но требует ряд дополнительных шагов. Во-первых, нужен свой балансировщик нагрузки, поэтому мы развернем в своем кластере балансирощик нагрузки NGINX.
Шаг 6 – ставим балансировщик нагрузки
У minikube есть ряд платформенных функций, облегчающих создание необходимых для доступа извне компонентов, вроде ingress-контроллеров. Minikube идет в комплекте с ingress-контроллером Nginx, и нам остается только включить его и настроить.
Теперь мы всего одной командой создам ingress-контроллер Nginx, который будет работать внутри нашего кластера minikube:
Шаг 7 – Настраиваем ingress
Теперь нам надо настроить ingress-контроллер Nginx, чтобы он воспринимал запросы hello-quarkus.
И, наконец, нам надо применить эту конфигурацию.
Поскольку мы делаем все это на своем компе, то просто добавляем IP-адрес своей ноды в файл /etc/ hosts, чтобы направлять http-запросы к нашему minikube на балансировщик нагрузки NGINX.
Всё, теперь наш сервис minikube доступен снаружи через ingress-контроллер Nginx.
Ну что, это же было легко, да? Или не очень?
Запуск на OpenShift (Code Ready Containers)
А теперь посмотрим, как это все делается на Red Hat OpenShift Container Platform (OCP).
Как в случае с minikube, мы выбираем схему с одноузловым кластером OpenShift в форме Code Ready Containers (CRC). Раньше это называлось minishift и базировалось на проекте OpenShift Origin, а теперь это CRC и построено на Red Hat’овской OpenShift Container Platform.
Здесь мы, извините, не можем сдержаться и не сказать: «OpenShift прекрасен!»
Изначально мы думали написать, что разработка на OpenShift ничем не отличается от разработки на Kubernetes. И по сути так оно и есть. Но в процессе написания этого поста мы вспомнили, сколько лишних движений приходится совершать, когда у вас нет OpenShift, и поэтому он, повторимся, прекрасен. Мы любим, когда всё делается легко, и то, как легко по сравнению с minikube наш пример развертывается и запускается на OpenShift, собственно, и подвигло нас написать этот пост.
Давайте пробежимся по процессу и посмотрим, что нам потребуется сделать.
Итак, в примере с minikube мы начинали с Docker… Стоп, нам больше не надо, чтобы на машине был установлен Docker.
И локальный git нам не нужен.
И Maven не нужен.
И не надо руками создавать контейнерный образ.
И не надо искать какой-нибудь репозиторий контейнерных образов.
И не надо устанавливать ingress-контроллер.
И конфигурировать ingress тоже не надо.
Вы поняли, да? Чтобы развернуть и запустить наше приложение на OpenShift, не нужно ничего из вышеперечисленного. А сам процесс выглядит следующим образом.
Шаг 1 – Запускаем свой кластер OpenShift
Мы используем Code Ready Containers от Red Hat, который по сути есть тот же Minikube, но только с полноценным одноузловым кластером Openshift.
Шаг 2 – Выполняем сборку и развертывание приложения в кластере OpenShift
Именно на этом шаге простота и удобство OpenShift проявляются во всей красе. Как и во всех дистрибутивах Kubernetes, у нас есть много способов запустить приложение в кластере. И, как и в случае КУК, мы специально выбираем самый наипростейший.
OpenShift всегда строился как платформа для создания и запуска контейнерных приложений. Сборка контейнеров всегда была неотъемлемой частью этой платформы, поэтому здесь есть куча дополнительных Kubernetes-ресурсов для соответствующих задач.
Мы будем использовать OpenShift’овский процесс Source 2 Image (S2I), у которого есть несколько различных способов для того, чтобы взять наш исходник (код или двоичные файлы) и превратить его в контейнерный образ, запускаемый в кластере OpenShift.
Для этого нам понадобятся две вещи:
Запустить S2I-сборку можно, как и из графической консоли OpenShift Developer, так и из командной строки. Мы воспользуемся командой new-app, указав ей, где брать builder-образ и наш исходный код.
Всё, наше приложение создано. При этом процесс S2I выполнил следующие вещи:
Если визуально отслеживать запуск S2I в консоли, то можно увидеть, как при выполнении сборки запускается build pod.
А теперь взглянем логи builder pod’а: во-первых, там видно, как maven делает свою работу и скачивает зависимости для сборки нашего java-приложения.
После того, как закончена maven-сборка, запускается сборка контейнерного образа, и затем этот собранный образ отправляется во внутренний репозиторий.
Всё, процесс сборки завершен. Теперь убедимся, что в кластере запустились pod’ы и сервисы нашего приложения.
Вот и всё. И всего одна команда. Нам остается только сделать expose этого сервиса для доступа извне.
Шаг 3 – делаем expose сервиса для доступа извне
Как и в случае КУК, на платформе OpenShift нашему «Hello World» тоже нужен роутер, чтобы направлять внешний трафик на сервис внутри кластера. В OpenShift это делает очень просто. Во-первых, в кластере по умолчанию установлен компонент маршрутизации HAProxy (его можно поменять на тот же NGINX). Во-вторых, здесь есть специальные и допускающие широкие возможности настройки ресурсы, которые называются Routes и напоминают Ingress-объекты в старом добром Kubernetes (на самом деле OpenShift’овкие Routes сильно повлияли на дизайн Ingress-объектов, которые теперь можно использовать и в OpenShift), но для нашего «Hello World», да и почти во всех остальных случаях, нам хватит стандартного Route без дополнительной настройки.
Чтобы создать для «Hello World» маршрутизируемый FQDN (да, в OpenShiift есть свой DNS для маршрутизации по именам сервисов), мы просто выполним expose для нашего сервиса:
Если посмотреть только что созданный Route, то там можно найти FQDN и другие сведения по маршрутизации:
И наконец, обращаемся к нашему сервису из браузера:
А вот теперь это было действительно легко!
Надеемся, что эта статься была для вас интересной и полезной. А найти дополнительные ресурсы, материалы и другие полезные для разработки на платформе OpenShift вещи можно на портале Red Hat Developers.
