как узнать версию openshift
Команда oc спешит на помощь
Если вы спец в OpenShift, то этот пост вряд ли откроет вам много нового. Но если вы только начинаете его осваивать, то он сэкономит вам массу времени и нервов. Мы попросили Хорхе Тудела Гонсалеса де Рианчо, облачного консультанта в испанском офисе Red Hat, написать несколько лайфхаков для утилиты oc.
Это крутая команда, она здорово продумана, она мощная, она гибкая, и у нее, как вы увидите, есть много скрытых возможностей, которые стоит попробовать.
1. Перво-наперво: отладка
Когда я не знаю, что происходит, или получаю непонятное сообщение об ошибке, я всегда использую флаг —loglevell, который включает запись лога в stderr. В зависимости от значения этого флага можно увидеть curl-вызовы API Rest, содержание ответов API Rest или даже более детализированную информацию.
Если, допустим, патч меняет метку сервиса на «app: hello-jorge», то это будет выглядеть так:
Да, вы правильно поняли. Команду oc можно запустить от имени другого пользователя, или, говоря на языке OCP, использовать имперсонацию. Разумеется, при наличии соответствующих прав. И для этого достаточно всего лишь использовать флаг —as.
3. Whoami
Команда oc whoami знакома, наверное, всем. Особенно флаг -t, позволяющий получить токен носителя для текущего пользователя/сеанса. Но что делать, если у вас есть токен, но вы не его владелец?
В этом случае можно войти в OpenShift с помощью этого токена, а затем выполнить команду oc whoami. Хотя, подождите, можно же сразу узнать имя владельца, просто передав токен команде oc whoami третьим аргументом без всяких флагов.
4. oc debug
Как известно, shell можно запустить прямо в работающем pod’е. Иногда бывает полезно сделать полную копию конфигурации запущенного pod’а и устранять неполадки через shell. Это так называемый метод по умолчанию.
А теперь взгляните, что позволяют сделать опции oc debug: можно запустить контейнер от имени root или любого другого пользователя; можно запустить его на выбранном узле или можно запустить в нем не shell, а другую команду.
При этом надо указывать верный dc, например:
# получаем shell внутри pod’а dc/jorge
$ oc debug dc/jorge
5. oc explain
В объектах OpenShift/Kubernetes иногда бывает огромное множество полей. В поисках примеров определений таких объектов часто приходится обращаться к документации по OCP или другим первоисточникам. Однако с тем же успехом можно использовать команду oc explain.
Эта команда выводит документацию по ресурсам и их полям, что бывает очень полезно при декларировании новых объектов OCP или в тех случаях, когда у вас нет доступа к официальной документации OCP.
Например, вот как можно получить документацию по pod’ам и описание affinity-полей:
6. Забудьте про grep, awk, cut и т. п.
Еще одна крутая фишка команды oc – это встроенные функции форматирования вывода. Про опции -o json или -o yaml знают все, но у флага -o есть и множество других опций.
Самые мощные, возможно, – это go-template и jsonpath:
json|yaml|wide|name|custom-columns=. |custom-columns-file=. |go-template=. |go-template-file=. |jsonpath=. |jsonpath-file=.
Скажем, вы хотите узнать, какой сервис, предоставляется определенным маршрутом (маршрутом docker-реестра):
Если вы хотите узнать больше про интересные возможности OpenShift, рекомендуем заглянуть в наш блог Red Hat Developer – здесь вас ждут не только статьи от наших разработчиков практически на любую тему, но и огромный каталог бесплатной литературы. А еще можно освежить в памяти наш пост о том, как развернуть Minishift на своем ноутбуке и начать жить.
Тестирование в 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 — красношляпые поделки
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 3 на OpenShift 4
Итак, состоялся официальный запуск платформы Red Hat OpenShift 4. Сегодня мы расскажем, как перейти на нее с OpenShift Container Platform 3 максимально быстро и просто.
В рамках этой статьи нас прежде всего интересуют новые кластеры OpenShift 4, использующие возможности умной и неизменной (immutable – одинаковой для всех сред развертывания) инфраструктуры на основе RHEL CoreOS и средств автоматизации. Ниже мы покажем, как перейти на OpenShift 4 без лишних проблем.
Узнать подробнее об отличиях новой версии от старой можно здесь.
Миграция кластеров с OpenShift 3 на OpenShift 4 с использованием сертифицированной платформы Red Hat Appranix
Appranix и Red Hat тщательно работали над тем, чтобы упросить миграцию кластерных ресурсов с OpenShift 3 на OpenShift 4 с помощью специального сервиса, работающего поверх Appranix Site Reliability Automation для Kubernetes.
Решение Appranix (его можно найти в Red Hat Container Catalog) позволяет создать бэкапы всех кластеров OpenShift 3 и восстановить их на OpenShift 4 всего за несколько кликов.
Чем хороша миграция с использованием Appranix для OpenShift 4
Многоуровневая отказоустойчивость (resiliency) для приложений OpenShift
После миграции с 3-й на 4-ю версию OpenShift решение Appranix можно использовать для обеспечения непрерывной отказоустойчивости приложений (Continuous App Resilience), в которой возможны три варианта. Уровень 1 устойчивости (Level 1 Resiliency) позволяет восстановить приложения без смены региона и облачного провайдера. Он может использоваться для отката приложений или восстановления после локального сбоя на уровне региона, например, в случае неудачного развертывания приложения, либо в ситуации, в которой необходимо быстро создать тестовую среду в том же регионе, но в отдельном кластере OpenShift.
Уровень 2 позволяет перенести приложения в другой регион без смены провайдера. При этом можно сохранить основную (primary) инфраструктуру данных в основном регионе, но запускать приложения в другом кластере в ином регионе. Этот вариант полезен, когда из строя выходит облачный регион или зона, либо требуется перекинуть приложения в другой регион из-за кибератаки. И наконец, Уровень 3 позволяет менять не только регион, но и облачного провайдера.
Как работает Appranix SRA
Многоуровневая отказоустойчивость приложений OpenShift в Appranix достигается за счет функционала «машины времени», автоматически создающей копии среды приложений. Чтобы задействовать этот функционал и повысить защищенность приложений, достаточно добавить в конвейер DevOps всего одну строку кода.
В инфраструктурных сервисах облачных провайдеров также возникают проблемы, поэтому возможность быстро переключиться на другого провайдера полезна во избежание зависимости от единственного поставщика услуг.
Как показано на рисунке ниже, резервные копии среды приложений могут создаваться в Appranix не только автоматически с заданной периодичностью, но и по команде из конвейера непрерывной интеграции и доставки CI/CD. При этом «машина времени» обеспечивает:
С помощью Appranix можно организовать защиту и восстановление на уровне приложений целиком для таких сценариев, как хаос-инжиниринг (chaos engineering), аварийное восстановление, защита от вымогательств и обеспечение непрерывности бизнес-процессов. Мы не будем останавливаться на этом подробно и далее рассмотрим, как использовать Appranix для миграции с OpenShift 3 на OpenShift 4.
Как выполняется миграция OpenShift 3 на OpenShift 4 с использованием Appranix Site Reliability Platform
Процесс включает три этапа:
Настраиваем OpenShift 3 и 4 Clusters для автообнаружения
Appranix считает, что у вас уже есть работающие кластеры OpenShift 3 и OpenShift 4. Если кластеров OpenShift 4 пока нет, создайте их, воспользовавшись документацией Red Hat по развертыванию OpenShift 4. Настройка основного (primary) и целевого (target) кластеров в Appranix выполняется одинаково и включает в себя всего несколько шагов.
Устанавливаем Appranix Controller Agent для обнаружения кластеров
Для обнаружения кластерных ресурсов нужен небольшой агент sidecar-контроллера. Для его развертывания достаточно скопировать и вставить соответствующую команду curl, как показано ниже. После того, как агент будет установлен в OpenShift 3 и в OpenShift 4, Appranix автоматически обнаружит все подлежащие миграции кластерные ресурсы, включая пространства имен, развертывания, pod-ы, службы, а также хосты с другими ресурсами.
Миграция больших распределенных приложений
Сейчас мы на примере разберем, как без лишних усилий перенести с OpenShift 3 на OpenShift 4 распределенное микросервисное приложение SockShop (по ссылке – подробное описание этого приложения и его микросервисной архитектуры). Как видно из рисунка ниже, архитектура SockShop содержит множество компонентов.
Appranix обнаруживает все ресурсы, для которых необходимо обеспечить защиту и миграцию на OpenShift 4, включая, PoD-ы, развертывания (deployments), сервисы и кластерные конфигурации.
OpenShift 3 с работающим приложением SockShop
Создаем политики Protection Policies для миграции
Политики можно задавать гибко в зависимости от того, как должна проводиться миграция. Например, на основе нескольких критериев или бэкап один раз в час.
Выполняем миграцию нескольких кластеров OpenShift 3 с помощью планов защиты (Protection Plans)
В зависимости от особенностей приложения или пространства имен, к кластерам OpenShift 3 можно применять политики, которые отрабатываются раз в час, раз в неделю или даже раз в месяц.
Appranix позволяет перенести на OpenShift 4 все пространства имен кластера или же только выбранные пространства.
Выполняем миграцию на OpenShift 4 в один клик
Миграция – это восстановление выбранных пространств имен на целевой кластер OpenShift 4. Эта операция выполняется в один клик. Appranix сам проделывает всю работу по сбору данных о конфигурации и ресурсах исходной среды и затем самостоятельно восстанавливает ее на платформе OpenShift 4.
Проверяем приложения после миграции на OpenShift 4
Залогиньтесь на кластер OpenShift 4, обновите проекты и проверьте, что все приложения и пространства имен в порядке. Повторите процедуру миграции для других пространств имен, создав для этого новые планы Protection Plans или изменив уже имеющиеся.
Запускаем мигрированные приложения на OpenShift 4
После миграции приложений с помощью процедуры восстановления Appranix важно не забыть настроить маршруты – они должны указывать OpenShift 4. Возможно, что, прежде чем полностью переносить продакшн с OpenShift 3, вам захочется провести тестовое восстановление. Когда на OpenShift 4 появятся несколько работающих приложений в соответствующих пространствах имен, возникнет необходимость перенести и остальные приложения с применением этого процесса.
После переноса всех пространств имен вы сможете защитить все кластеры OpenShift для непрерывного аварийного восстановления, защиты от вымогательств, обеспечения непрерывности бизнеспроцессов или для последующей миграции, поскольку Appranix Site Reliability Automation автоматически обновляется по мере выхода новых версий OpenShift.
Итого
OpenShift 4 – это большой шаг вперед, прежде всего, за счет новой неизменной архитектуры и Operator-платформенной модели для автоматизации сложных конфигураций приложений и платформ, работающих в кластерных средах. Appranix предлагает пользователям OpenShift простой и удобный способ перехода на OpenShift 4 с помощью своего облачно-ориентированного решения для аварийного восстановления приложения Site Reliability Platform.
Решение Appranix можно использовать прямо из Red Hat Container Catalog.