Что такое openshift для чайников

Тестирование в Openshift: Введение

Здравствуйте уважаемые участники ИТ сообщества. Меня зовут Олег, я работаю в компании, которая занимается разработкой ПО. Я занимаюсь ручным и автоматизированным тестированием Linux и Unix продуктов и я хотел бы поделиться положительным опытом автоматизированного тестирования в Openshift Origin.

Цели, которые я преследую:

Весь материал изложен в трёх статьях:

Примечание: хотелось бы сразу заметить, что излагаемый материал касается Openshift v3, а не Openshift v2 (когда компания Red Hat еще не начала использовать Kubernetes в качестве ядра для своих продуктов и сервисов).

Почему был выбран Openshift Origin:

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

На первоначальном этапе для развертывания и поддержки сред был организован автоматически обновляемый репозиторий Vagrant (VirtualBox), который обновляет и упаковывает различные ОС в автоматическом режиме. Это стало подспорьем не только для тестирования, но и для разработки, потому как: виртуальные машины были сконфигурированы согласно выработанным требованиям; виртуальные машины были обновлены, были предустановлены необходимые инструменты; имелись сценарии Vagrant для развертывания сложных окружений. Стоит отметить, что все среды Vagrant разворачиваются на локальных машинах участников разработки, а не в выделенном IaaS, что ожидаемо вызывало проблемы производительности рабочих станций.

Было выиграно время, стало удобнее работать, появились некий стандарт и предсказуемость, но главная проблема оставалась — долгое развертывание тестируемых сред (полная виртуализация, различные дистрибутивы Linux, дополнительные сервисы (которые участвуют в тестировании)). Развертывание тестируемых сред могло занимать десятки минут, в то время как сам тест проходил за считанные секунды. При этом количество автоматизированных тестов росло и ожидать результатов приходилось всё дольше.

Закономерным стал вопрос об организации обособленного IaaS, в котором происходили бы все задачи тестирования, но данный подход был не идеален: всё так же использовалась бы полная виртуализация, для построения IaaS требовались бы финансовые вложения на покупку аппаратного обеспечения (небольшой парк слабых рабочих станции присутствовал).

Следующим этапом стала проработка быстрого (в контексте быстродействия окружений) CI/CD c учетом новых требовании, а именно (основные, согласно приоритетам):

Я не буду утруждать читателей подробным пересказом о тернистом пути поиска подходящих продуктов, но хочу ознакомить со списком рассмотренного ПО (февраль 2016):

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

Своими словами oб Openshift Origin:

Openshift Origin — это в первую очередь Open Source платформа для разработки и публикации ПО, которая базируется на платформе оркестрации контейнеров Kubernetes. Платформа расширяет возможности Kubernetes с помощью специальных объектов и механизмов.

Кластер может быть развернут или обновлен с помощью сценариев Ansible. Внутри кластера может использоваться как встроенный так и внешний Docker регистр. Узлы кластера могут быть закреплены на основе специальных меток за отдельными проектами. Присутствует сборщик мусора и настраиваемый планировщик. Кластер может быть развернут внутри Openstack и интегрирован с ним с целью автоматического масштабирования и предоставления хранилища данных. Среды могут быть осведомлены об опубликованных сервисах и других узлах с помощью переменных окружений и DNS имен. Возможна проверка доступности сервисов через HTTP/TCP запрос и/или через выполнение команды внутри контейнера. Ресурсы кластера могут быть квотированы на уровне проектов (процессор, память, количество объектов и т.д.). Присутствует возможность мониторинга кластера на уровне контейнеров и рабочих узлов.

В качестве способа харанения данных могут выступать временные или постоянные тома, которые монтируются непосредственно в контейнеры. Backend для данных томов могут выступать: NFS, GlusterFS, OpenStack Cinder, Ceph RBD, AWS Elastic Block Store (EBS), GCE Persistent Disk и т.д. Присутствует возможность (hostPath) монтирования локального каталога того рабочего узла, на котором запущен контейнер.

По умолчанию все коммуникации осуществляются с помощью Open vSwitch, но существует поддержка других сетевых решений через систему плагинов Kubernetes. По умолчанию все среды могу коммуницировать друг с другом, но возможна изоляция на уровне проектов. Поддерживается разрешение DNS имен сервисов с помощью встроенной службы SkyDNS. Опубликованные внутри кластера сервисы могут быть доступны извне. Всю функциональность по изоляции и функциям NAT берет на себя Iptables.

Разграничение прав пользователей на основе ролей. Изоляция контейнеров с помощью SELinux (и не только). Поддержка секретов, которые используются для доступа к различным ресурсам. Все коммуникации между рабочими узлами кластера и мастером осуществляется через шифрованные соединения (создается CA, выдаются клиентские сертификаты).

Доступны интерфейсы API как для самого Openshift, так и для Kubernetes. Доступен кроссплатформенный консольный клиент. Доступен веб-интерфейс, с помощью которого пользователи могут: работать в изолированных проектах с учетом их полномочий, взаимодействовать с запущенными в кластере контейнерами, обозревать созданные объекты, отслеживать события и т.д.

Заключение:

Несмотря на обилие технологий и продуктов, которые представлены на рынке, найти подходящий инструмент достаточно сложно. Балансируя между унификацией и интеграцией процессов CI/CD, учитывая сложность сопровождения, отслеживая цепочки задействованных технологий, всё же была найдена Kubernetes, а затем и Openshift Origin. В отличии от базовой платформы оркестрации контейнерами Kubernetes, Openshift привносит необходимые элементы для удобной и эффективной работы.

Источник

Использование 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 должна запуститься установка.

Источник

Прости, 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.

Источник

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:

Источник