Openshift *

Мы начинаем серию постов, в которой покажем, как развертывать на Red Hat OpenShift современные веб-приложения, такие как React или Angular, с помощью нового builder-образа S2I (source-to-image).



Что будет в этой серии постов:

• Часть 1: как развертывать современные веб-приложения всего за несколько шагов;
• Часть 2: как применять новый образ S2I вместе с уже имеющимся образом HTTP-сервера, например NGINX, используя цепочку сборки OpenShift для организации продакшн-развертывания;
• Часть 3: как запустить для своего приложения сервер разработки на платформе OpenShift и синхронизировать его с локальной файловой системой.

Рабочая группа OKD рада сообщить о выходе общедоступного релиза системы OKD4, которая представляет собой community-версию Red Hat OpenShift Kubernetes.



Red Hat в очередной раз подтверждает приверженность принципам open source и открытого сотрудничества с сообществами разработки Kubernetes и других облачно-ориентированных инициатив.

Если вы раньше имели дело с OpenShift, то знаете насколько трудоемко установить «с нуля» кластер OpenShift в vSphere. В основном потому, что нужно подготовить окружающую инфраструктуру. В релизе OpenShift 4.5.1 эта задача стала намного легче.

Привет, друзья!

Прошлой осенью мне по работе понадобилось протестировать решения для защиты сред контейнеризации (я работаю ИБ-инженером), но готового стенда с микросервисной архитектурой для этого не оказалось. Мотор-то мы купили, да трактор… у нас украли. Почувствовался резкий дефицит систем оркестрации контейнеров, и в воздухе запахло приключением!



Так как мои Ops коллеги всегда на острие интеграций и внедрений, денно и нощно разворачивают сложнейшие системы и вычислительные комплексы, просить их «по-быстренькому запилить кластер OpenShift» совсем не укладывалось в концепт инженерной солидарности. Поэтому я принял волевое решение — делать самому! Не без советов коллег, разумеется, ибо с Sec’ом да прибудет мудрость Ops’а.

Забегая вперед, скажу, что в итоге стенд удался и даже вполне себе работает по сей день, а мне хочется поделиться с вами полученным опытом.

Казалось бы что здесь такого? подключаем к проекту fabric8-maven-plugin и вперед: сборка, запуск приложения в OpenShift. Но когда изучал хотелось большего понимания этого процесса, а затем хотелось большего контроля и свободы над процессом сборки и развертывания приложения в OpenShift. Таким образом получился следующий сценарий и с такими особенностями.

• Сборку артефакта произвожу сам, своим инструментом (maven, gradle и др.)
• Контролирую создание Docker Image через Dockerfile
• Build и Deployment процесс в Openshift настраивается в шаблоне, т.е. любые характеристики контейнера, pod настраиваются.
• Таким образом сам процесс можно перенести во внешнюю систему сборки, развертывания
  

UPDATE: добавили ссылки на презентации и фото!

Всем привет!

Скоро новый год, а с ним долгожданные праздники, снег, елка, дед мороз и прочие радости…
Вот и мы в преддверии праздников решили подвести некоторые итоги этого насыщенного событиями года и поговорить о реальном опыте построения масштабируемых систем на Kubernetes.
Планируем 4 выступления, от архитекторов с реальным опытом внедрения kubernetes.
Будет интересно!

Мероприятие пройдет в четверг, 12 декабря, в клиентском центре IBM (Москва-сити — Пресненская набережная, 10). Собираемся в 18:30, а начало выступлений в 19:00. Участие в митапе бесплатное, количество мест ограничено. Ждем всех, кому интересно узнать о реальном опыте использования Kubernetes в построении продуктивных систем!

Доброго времени суток жители Хабра!

Сегодня хочу рассказать вам, как нам очень хотелось мониторить postgres и еще пару сущностей внутри кластера OpenShift и как мы это сделали.

На входе имели:

• Openshift
• Helm
• Prometheus

Привычка — страшная сила. Она заставляет сопротивляться изменениям, мешает развитию. Но в IT мы любим быть на переднем крае технологий, любим вызовы, любим внедрять то, что распространится по другим сферам только через несколько лет.

Мы готовы к новому и можем не дожидаться, пока будущее наступит, и придется к нему адаптироваться. Мы можем выйти навстречу, знать бы только в какую строну.

Егор Бугаенко знает, что нужно делать уже сейчас, чтобы и через 5–10 лет оставаться востребованным программистом. Его идеи, как и всегда, могут показаться спорными. Вам и не нужно безоговорочно с ними соглашаться, но задуматься, например, о pet project лишний раз не повредит. Да и в том, что программисту необходим английский язык, вряд ли могут быть разные мнения. А вот по остальным пунктам будет интересно узнать мнение сообщества в комментариях.



Дальше идет текстовая версия доклада Егора на AppsConf, но относится он не только и не столько к мобильной разработке, сколько к отрасли в целом. Егор Бугаенко основатель Zerocracy, разработчик Cactoos, Takes Framework, JCabi и других open source проектов. Написал серию книг «Elegant Objects», ведет провокационный блог и выступает с докладами, заставляющими задуматься, такими как этот.

Я хочу рассказать история, как запускали приложение в Openshift. Так же по ходу пьесы рассмотрим утилиты для управления приложением внутри Openshift. Это расшифровка выступления на kubernetes SPB meetup #3..

OpenShift

1. Развертка Openshift.
2. Конфигурация после установки.
3. Создание и подключение PV.
4. Создание и разворачивание проекта Red Hat Decision Manager (enterprise аналог kie-workbench).
5. Создание и разворачивание проектов AMQ (red hat active mq) и postgressql c использованием персистентных хранилищ.
6. Создание отдельных проектов для сервисов, шаблонов к ним, pipeline, интеграция с gitlab, gitlab regestry.

14 декабря на митапе в Санкт-Петербурге я (Артем Соковец) совместно с коллегой, Дмитрием Маркеловым, рассказывал о текущей инфраструктуре для автотестов в СберТехе. Пересказ нашего выступления — в этом посте.

Привет, Хабр! На Red Hat Summit 2018 в Сан-Франциско, мы совместно с Red Hat представили OpenShift на платформе Azure — первую полностью управляемую и простую в использовании контейнерную платформу OpenShift в виде облачного сервиса. Сегодня поговорим о ней поподробнее и расскажем, как можно получить больше инсайдов. Заглядывайте под кат!

Тотальная контейнеризация и переосмысление роли контейнеров в процессе девелопмента и развития инфраструктуры не могла не сподвигнуть главных адептов open source мира на дальнейшие свершения. Red Hat уверенно гнет свою линию, и если несколько лет назад OpenShift был всего лишь PaaS-ом, то сегодня — это нечто большее. Сам по себе OpenShift понятен, но не прост. Сделать процесс управления контейнерами и развертывания приложений как можно более безболезненным и безопасным — главная задача, которую преследует OpenShift, и стоит отметить, ребята из Red Hat преуспели в этом. Но, сам по себе OpenShift никак не приближает к заветной мечте — предоставить девелоперу, ПМу, QA инженеру окружение, где будет все. Это такой себе идеальный мир без Jira или RedMine, без нескончаемых Jenkins слейвов, незаконченных обновлений стейджинга, различных IDE, которые по разному ведут себя с разными проектами, без ручных настроек проектов на GitHub. Этот идеальный мир — проект, который Red Hat анонсировали относительно недавно, а именно в мае 2017, и имя ему openshift.io.

Здравствуйте, уважаемые участники ИТ сообщества. Данный материал является незапланированным продолжением серии статей (первая статья, вторая статья, третья статья), которые посвящены тестированию ПО в Openshift Origin. В данной статье будут рассмотрены аспекты интеграции контейнеров и виртуальных машин посредством Openshift и Openstack.

Какие цели я преследовал интегрируя Openshift с Openstack:

1. Добавить возможность запускать контейнеры и виртуальные машины в единой сети (L2, отсутствие вложенных сетей).
2. Добавить возможность использования опубликованных в Openshift сервисов виртуальными машинами.
3. Добавить возможность интеграции физического сегмента сети с сетью контейнеров/виртуальных машин.
4. Иметь возможность обоюдного разрешения FQDN для контейнеров и виртуальных машин.
5. Иметь возможность встроить процесс развертывания гибридных окружений (контейнеры, виртуальные машины) в существующий CI/CD.

Примечание: в данной статье не пойдет речи об автоматическом масштабировании кластера и предоставлении хранилищ данных.

Это заключительная часть серии из трех статей (первая статья, вторая статья), которые посвящены автоматизированному тестированию программных продуктов в Openshift Origin. В данной статье будут рассмотрены аспекты тестирования в контейнерах и особенности выстраивания CI/CD при участии таких продуктов как:

1. Openshit Origin — как система для развертывания тестовых окружений.
2. Jenkins — как инструмент непрерывной интеграции.
3. Testlink — как система управления тестами.

4. Robot Framework — как framework для написания тестов.

   
   

   Для лучшей репрезентативности я подготовил образ Vagrant, который содержит преднастроенную среду из вышеперечисленных продуктов (все перечисленные в данной статье объекты и механизмы могут быть легко проинспектированы). Чтобы повысить градус понимания материала я создал две задачи: задачу сборки, задачу тестирования. Обе задачи разбиты на этапы и детально описаны.

   
   

Это продолжение серии из трех статей (первая статья, третья статья) об автоматизированном тестировании программных продуктов в Openshift Origin. В данной статье будут описаны основные объекты Openshift, а также описаны принципы работы кластера. Я осознано не делаю попытку описать все возможные объекты и их особенности, так как это очень трудоемкая задача, которая выходит за рамки данной статьи.

Кластер:

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

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

1. Донести до русскоязычного сообщества особенности работы с Openshift Origin в контексте тестирования.
2. Рассказать о преимуществах и недостатках тестирования в контейнерах.
3. Агрегировать и актуализировать свои знания о Kubernetes/Openshift.

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

1. Тестирование в Openshift: Введение
2. Тестирование в Openshift: Внутреннее устройство кластера
3. Тестирование в Openshift: Автоматизированное тестирование

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

«Всю разработку — в контейнеры» — с этой фразы началось мое увлекательное путешествие в мир Docker. Попытки угодить требованиям разработчиков привели к выбору OpenShift Origin. Однако, завести полноценный кластер, как оказалось, задача нетривиальная. Во время постройки контейнерной инфраструктуры я пытался найти что-нибудь по теме, в том числе на Хабре, и не находил, как это ни странно. Поэтому ниже я попробую описать весь базовый процесс установки и постараюсь уберечь вас от граблей, по которым фактически гулял.

Приступим:

В этой статье я покажу, как быстро развернуть среду для сборки, тестирования и публикации приложений используя платформу OpenShift на примере PHP проекта. Использовать буду OpenShift online, но всё это же можно развернуть и на собственных серверах или в VirtualBox (есть готовая сборка). Git-сервером для хранения и версионирования кода будет Bitbucket.

Появилась необходимость создать облачный сервис и для реализации этого проекта было выбрано open source решение OpenShift. После успешного прохождения Getting Started и деплоя HelloWorld, возникли неожиданные трудности: официальная документация потребовала детального изучения для решения такой простой задачи, как поднять свой готовый контейнер, с произвольным содержанием. Пришлось немного разобраться и ниже простое готовое руководство. Подразумевается, что читатель знаком с docker, т.к. объяснений его команд в данном мануале нет.