что такое openshift для чайников
Используем 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 должна запуститься установка.
Прости, 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.
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 ошибки на запись, билд же висит на пуше).