что такое секреты в openshift
Openshift — красношляпые поделки
OpenShift
1. Развертка Openshift
Требования к серверам, подготовка dns серверов, список имен серверов, требования к серверам.
Минимальные требования кратко — все сервера должны иметь минимум 16Gb Ram 2 ядра и минимум 100 гигабайт для нужд docker.
dns на базе Bind должен иметь следующую конфигурацию.
dkm — мастер, dk0 — исполняющие, ifr — инфраструктурные, bln — балансировщик, shd — nfs, dkr — управляющая нода с которой происходила конфигурация кластера, так же планировалась как отдельная нода под docker regestry.
После подключения подписки. Включение репозиториев и установка необходимых изначально пакетов.
Конфигурация хранилища докера (отдельным диском).
Установка остальных необходимых пакетов.
Создание, добавление пользователя, а также ключей.
В случае конфликта с уже используемыми подсетями — изменить адресацию по умолчанию внутри контейнеров.
Конфигурация network manager. (dns должен уметь froward во внешний мир)
Правка в случае необходимости имени машины на полное имя.
После выполненных действий перезагрузить сервера.
Подготовка управляющей ноды dkr
Отличие управляющей ноды от остальных — нет необходимости подключать docker на отдельный диск.
Также есть необходимость настройки ntp.
Также нужно добавить закрытый ключ пользователю ocp.
Зайти по ssh под пользователем ocp на все ноды.
Подготовка Inventory file и развертка кластера.
Запуск поочередно плейбуков.
Если все хорошо в конце будет примерно следующие.
Правка локального файла хост для проверки после установки работу oprenshift по веб интерфейсу.
2. Конфигурация после установки
Проверить что есть возможность видеть в web интерфейсе скрытые ранее project (openshift, например).
3. Создание и подключение PV
Создание persistent volume на сервере nfs.
Добавление pv в openshift.
Необходимо создать проект oc new-project examplpv-project.
Если проект уже создан перейти в него oc project examplpv-project. Создать yaml следующего содержания.
созданный pv будет виден в списке.
4. Создание и разворачивание проекта Red Hat Decision Manager (enterprise аналог kie-workbench)
Проверить наличие шаблонов.
Добавление шаблонов — ссылку и более полное описание можно найти
Создадим новый проект:
Добавление авторизации на сервер docker registry.redhat.io:
Импорт imagetream, создание ключей Decision Server, Decision Central.
Создание persistent volume на сервере nfs.
Добавить pv в проект:
Приложение автоматически развернется по завершению Pull образов в docker-registry.
До этого момента статус будет таким.
В случае перехода по ссылке на образ будет следующая ошибка
Необходимо изменить url загрузки образов выбрав edit yaml с registry.redhat.io на registry.access.redhat.com
Для перехода в развернутый сервис в его web интерфейс необходимо добавить в файл hosts следующие url
на на любую из infra nodes
10.19.86.25 rnd-osh-ifr-t02.test.osh myapp-rhdmcentr-rhdm72.apps.openshift.test.osh
5. Создание и разворачивание проектов AMQ (red hat active mq) и postgressql c использованием персистентных хранилищ
Создадим новый проект
Импортируем образы в случае их отсутствия.
Добавление роли сервис аккаунту.
Создание pv на сервере nfs
Создаем из шаблона
Создаем еще один PV аналогично тому как делали для MQ.
Заполняем необходимые параметры
6. Создание отдельных проектов для сервисов, шаблонов к ним, pipeline, интеграция с gitlab, gitlab regestry
Первый делом необходимо создать проект.
Первично не имея шаблона можно создать в ручную приложение.
Есть два способа.
Первый просто используя готовый образ, но тогда не будет доступна версионность образов и т.д., но в некоторых случаях будет актуально.
Прежде всего, нужно получить данные для аутентификации к registry. На примере собранного образа в Gitlab это делается вот так.
Для начала надо создать секреты по доступу к docker registry — посмотреть варианты и синтаксис.
Затем создадим секрет
Затем создадим наше приложение.
Если что-то пошло не так, и образ не тянется в свойставх приложения указать секрет к нашему regestry.
Затем добавляем необходимые переменные окружения.
Готово — контейнер живой.
Затем нажмем справа edit yaml и укажем порты.
Затем чтобы получить доступ к нашему контейнеру необходимо создать route, но создать его без сервиса невозможно, потому первым делом необходимо создать сервис.
прописываем url в hosts на своей машине смотрящим на одну из infra nodes.
прописываем url в hosts на своей машине смотрящим на одну из infra nodes.
Шаблон создается методом выгрузки в yaml по отдельности всех компонентов которые относятся к сервису.
А именно в данном случае это secrets dc Service Route.
Посмотреть все что сделано в конкретном проекте можно
Затем можно взять за основу любой шаблон для opensihft и интегрировать то что было получено для получения шаблона.
В данном случае результат будет выглядеть так:
Можно добавить сюда и secret-ы, в следующем примере рассмотрим вариант сервиса со сборкой на стороне openshift где secret-ы будут в шаблоне.
Создание проекта с полными стадиями сборки образов, простому pipeline и сборкой по Push.
Первым делом создадим новый проект.
Для начала нужно создать Buildconfig из гита (в данном случае в проекте есть три докер файла, обычный докер файл который рассчитан на docker версии 1.17 выше используя два FROM, и два отдельных dockerfile для сборки базового образа и целевого.)
Для доступа в гит если он приватный нужна авторизация. Создадим secret со следующим содержанием.
Дадим сервис аккаунту builder доступ к нашему секрету
Привяжем секрет к url git
На выходе можно получить два вот таких шаблона.
Также нам понадобится создать deploymentconfig два imagestream и для завершения развертки service и route.
Я предпочел не плодить отдельно все конфиги, а сразу делать шаблон, включающий все компоненты для сервиса. за основу взяв предыдущий шаблон для варианта без сборки.
Использовать данный шаблон для развертки можно так
Затем создадим Pipeline
После применения конфигурации Pipeline, запустив
Можно получить url для webhook в gitlab.
Секрет заменить на указанный секрет в конфиге.
Так же после применения Pipeline openshift сам начнет установку jenkins в проекте для запуска Pipeline. Первичный запуск длительный, так что необходимо подождать некоторое время.
Затем в Gitlab в нашем проекте:
Заполнить Url, secret, убрать Enable SSL verificationю И наш webhook готов.
Можно сделать тестовый push и посмотреть на ход ведения сборки
Не забудьте прописывать в host url чтобы попасть в тот же jenkins на infranode.
Так же можно посмотреть ход сборки.
P.S. Надеюсь данная статья поможет многим понять как и с чем едят openshift, разяснит многие не очевидные с первого взгляда моменты.
P.S.S. некоторые решения для решения некоторых проблем
Проблемы с запуском билда сборки и т.д.
— создать сервис аккаунт для проекта
Проблемы с подвисом проекта и не удалением его
— скрипт принудительного завершения (болезнь врожденная)
Проблемы с загрузкой образов.
Также переопределить разрешения на папку для registry на nfs. (в логах registry ошибки на запись, билд же висит на пуше).
Тестирование в Openshift: Внутреннее устройство кластера
Это продолжение серии из трех статей (первая статья, третья статья) об автоматизированном тестировании программных продуктов в Openshift Origin. В данной статье будут описаны основные объекты Openshift, а также описаны принципы работы кластера. Я осознано не делаю попытку описать все возможные объекты и их особенности, так как это очень трудоемкая задача, которая выходит за рамки данной статьи.
Кластер:
В целом работа кластера Openshift Origin не сильно отличается от других решений. Поступающие задачи распределяются по рабочим узлам на основе их загруженности, данное распределение берет на себя планировщик.
Для запуска контейнеров требуется Docker образа, которые могут быть загружены из внутреннего или внешнего регистра. Непосредственно запуск контейнеров происходит в различных контекстах безопасности (политики безопасности, которые ограничивают доступ контейнера к различным ресурсам).
По умолчанию контейнеры из разных проектов могут коммуницировать друг с другом с помощью overlay сети (выделяется одна большая подсеть, которая разбивается на более мелкие подсети для всех рабочих узлов кластера). Запущенному на рабочем узле контейнеру выделяется IP-адрес из той подсети, которая была назначена данному узлу. Сама overlay сеть построена на базе Open vSwitch, который использует VXLAN для связи между рабочими узлами.
На каждом рабочем узле запускается выделенныё экземпляр Dnsmasq, который перенаправляет все DNS запросы контейнеров на SkyDNS во внутреннюю сервисную подсеть.
Если контейнер аварийно завершил свою работу или просто не может быть проинициализирован, то задача по его развертыванию передается на другой рабочий узел.
Стоит отметить что:
SELinux не является строгим условием работы кластера. Отключение оного (не рекомендуется по соображениям безопасности) привнесет некое увелечение скорости (равно как и отключение мониторинга, кстати) при работе с контейнерами. Если SELinux мешает работе приложения в контейнере, присутствует возможность добавления исключения SELinux непосредственно на рабочем узле кластера.
По умолчанию используется LVM в качестве хранилища Docker Engine. Это далеко не самое быстрое решение, но можно использовать любой другой тип хранилища (BTRFS, например).
Стоит иметь ввиду, что название сервиса (см. Service) — это DNS имя, которое влечет за собой ограничения на длину и допустимые символы.
Чтобы сократить временные и аппаратные издержки при сборке Docker образов можно использовать так называемый «слоистый» подход (multi-stage в Docker). В данном подходе используются базовые и промежуточные образа, которые дополняют друг друга. Имеем базовый образ «centos:7» (полностью обновлен), имеем промежуточный образ «centos:7-tools» (установлены иструменты), имеем финальный образ «centos:7-app» (содержит «centos:7» и «centos:7-tools»). То есть вы можете создавать задачи сборки, которые основываются на других образах (см. BuildConfig).
Достаточно гибким решением является подход, когда существует один проект, который занимается только сборкой Docker образов с последующей «линковкой» данных образов в другие проекты (см. ImageStream). Это позволяет не плодить лишних сущностей в каждом проекте и приведет к некой унификации.
Большинству объектов в кластере можно присвоить произвольные метки, с помощью которых можно совершать массовые операции над данными объектами (удаление определенных контейнеров в проекте, например).
Стоит сразу побеспокоиться об удалении старых образов и забытых окружений. Если первое решается с помощью сборщика мусора/oadm prune, то второе требует проработки и ознакомлении всех участников с правилами совместной работы в Openshift Origin.
Любой кластер ограничен ресурсами, поэтому очень желательно организовать мониторинг хотя бы на уровне рабочих узлов (возможен мониторинг на уровне приложения в контейнере). Сделать это можно как с помощью готового решения Openshift Metrics, так и с помощью сторонних решений (Sysdig, например). При наличии метрик загруженности кластера (в целом или по проектно) можно организовать гибкую диспетчерезацию поступающих задач.
Особенно хочется отметить тот факт, что рабочие узлы могут быть динамически проинициализированы, а это значит, что вы можете расширить свой кластер Openshift Origin на существующих мощностях IaaS. То есть, во время предрелизного тестирования вы можете существенно расширить свои мощности и сократить время тестирования.
Объекты:
Project — объект является Kubernetes namespace. Верхний уровень абстракции, который содержит другие объекты. Созданные в проекте объекты не пересекаются с объектами в других проектах. На проект могут быть выставлены квоты, привилегии, метки узлов кластера и т.д. Вложенная иерархия и наследование между проектами отсутствуют, доступна «плоская» структура проектов. Существуюет несколько системных проектов (kube-system, openshift, openshift-infra), которые предназначены для нормального функционирования кластера.
Создание нового проекта:
Редактирование настроек проекта:
Pod — объект, который стал одним из решающих факторов, так как позволяет запускать произвольные команды внутри контейнера с помощью специальных хуков (и не только). Pod является основной рабочей единицей в кластере. Любой запущенный в кластере контйенер — Pod. По своей сути — группа из одного и более контейнеров, которые работают в единых для этих контейнеров namespaces (network, ipc, uts, cgroup), используют общее хранилище данных, секреты. Контейнеры, из которых состоит Pod, всегда запущены на одном узле кластера, а не распределены в одинаковых пропорциях по всем узлам (если Pod будет состоять из 10 контейнеров, все 10 будут работать на одном узле).
Secret — может являться строкой или файлом, предназначен для проброса чувствительной (хранится в открытом виде в etcd (поддержка шифрования в Kubernetes 1.7)) информации в Pod. Один Secret может содержать множество значений.
Использование Secret в BuildConfig:
ServiceAccount — специальный тип объекта, который предназначен для взаимодействия с ресурсам кластера. По своей сути является системным пользователем.
По умолчанию новый проект содержит три ServiceAccount:
Перечисленные служебные аккаунты:
Добавление прав администратора проекта ServiceAccount:
DeploymentConfig — это объект, который оперирует всё теми же Pod, но при этом привносит ряд дополнительных механизмов для управления жизненным циклом запущенных приложений, а именно:
ImageStream — по своей сути является «контейнером» для «ссылок» (ImageStreamTag), которые указывают на Docker образа или другие ImageStream.
Создание тага/ссылки на Docker образ между проектами:
Создание тага/ссылки на Docker образ, который расположен на Docker Hub:
BuildConfig — объект является сценарием того, как будет собран Docker образ и куда он будет помещен. Сборка нового образа может базироваться на других образах, за это отвечает секция «from:»
Источники сборки (то место, где размещены исходные данные для сборки):
Стратегии сборки (каким образом следует интерпретировать источник данных):
Назначение сборки (куда будет выгружен собранный образ):
Какие операции выполнит данный BuildConfig:
Service — объект, который стал одним из решающих факторов при выборе системы запуска сред, так как он позволяет гибко настраивать коммуникации между средами (что очень важно в тестировании). В случаях с использованием других систем требовались подготовительные манипуляции: выделить диапазоны IP-адресов, зарегистрировать DNS имена, осуществить проброс портов и т.д. и т.п. Service может быть объявлен до фактического развертывания приложения.
Что происходит во время публикации сервиса в проекте:
Разрешение DNS имени:
Заключение:
Все объекты кластера можно описать с помощью YAML, это, в свою очередь, дает возможность полностью автоматизировать любые процессы, которые протекают в Openshift Origin. Вся сложность в работе с кластером заключается в знании приципов работы и механизмов взаимодействия объектов. Такие рутинные операции как инициализация новых рабочих узлов берут на себя сценарии Ansible. Доступность API открывает возможность работать с кластером напрямую минуя посредников.
Прости, 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.