Блог компании red hat

Собрали много инсайтов, мероприятий, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Узнать новое

• Как сделать флешку восстановления Windows на Linux-машине
  Легко! Для этого есть отличная и донельзя простая утилита WoeUSB. Зачем? Допустим, чтобы помочь друзьям, коллегам или родственникам

• 5 лучших медиаплейеров для Linux
  Представляем нашу подборку на разные случаи и вкусы

• Как запускать свои любимые Windows-программы на Linux?
  Для этого есть WINE опенсорсный эмулятор API, благодаря которому Windows-приложения (увы, не все) работают в нативном режиме без всяких виртуальных машин

• Резервное копирование для домашней автоматизации Home Assistant

• Практическое руководство по замыканиям в JavaScript

• 4 ИТ-специальности для тех, кто не программирует

• 3 полезных подкаста по agile

• Цифровая трансформация: 3 тенденции на 2021 год
  Коронавирус заставил организации увеличить инвестиции в ИТ и повысить приоритет программ цифровой трансформации. Эти три фактора остаются в силе и в новом году

• ИТ-лидерство: главные уроки коронавируса
  От новых подходов к планированию до прозрачности коммуникаций над чем стоит поработать руководителю как в личном, так и командном плане.

• 6 заблуждений насчет AIOps
  Algorithmic IT Operations (AIOps) еще не слышали? Разбираемся, что это такое и что с ним делать

• Edge-вычисления и IoT идеальная парочка
  Edge локализует обработку данных как можно ближе к устройствам IoT, что положительно влияет на задержки, производительность, затраты и безопасность корпоративных ИТ-систем

Скачать

• Шпаргалка по pip
  Поможет эффективно использовать pip менеджер сторонних пакетов для Python

Почитать на досуге

• Бесплатный онлайн-курс Разработка облачных приложений с микросервисной архитектурой

• Электронная книга The automated enterprise

• Методология и технологии систем интенсивной обработки данных в гибридном облаке

• 8 фраз руководителя с высоким эмоциональным интеллектом

• Архитектор решений что это за профессия?

• 6 ресурсов и 3 совета, которые помогут войти в мир Linux-контейнеров

Мероприятия:

• Виртуальный Red Hat Summit 2021, 27-28 апреля
  Бесплатная онлайн-конференция Red Hat Summit это отличный способ узнать последние новости ИТ-индустрии, задать свои вопросы техническим экспертам, услышать истории успеха непосредственно от заказчиков Red Hat и увидеть, как открытый код генерирует инновации в корпоративном секторе

• Эффективное внедрение новых сервисов для бизнеса: программно-аппаратный альянс Hitachi Vantara и Red Hat, 18 марта, 11:00
  На вебинаре руководитель группы архитекторов по решениям Red Hat и директор по технологиям Hitachi Vantara обсудят эффективное внедрение новых сервисов для бизнеса: программно-аппаратный альянс Hitachi Vantara и Red Hat. В конце вебинара вас ждет розыгрыш призов!

• Программно-определяемая инфраструктура с HPE OneView и Ansible, 25 марта, 11:00
  ...Итак, вы используете сервера HPE, управляете ими при помощи HPE OneView, но пришла пора цифровой трансформации и вам срочно нужно максимально автоматизировать вашу инфраструктуру?
  
  Наш ответ используйте Red Hat Ansible Automation Platform, а также инструменты интеграции с HPE OneView.

По прогнозам IDC, в 2024 году размер мирового рынка граничных вычислений (edge computing) достигнет $250,6 млрд, так что эта технология определенно заслуживает пристального внимания. И сегодня мы поговорим о таком ее важном аспекте, как сегментация: что это, зачем она нужна, и как реализуется.

Суть концепции edge computing физически перенести вычисления как можно ближе к конечному потребителю, чтобы предоставлять их максимально быстро и эффективно. Однако в отличие от распределенной архитектуры ЦОД, где информационный обмен между сервисами сводится к взаимодействию кластеров машин, сконцентрированных в одной локации, граничные вычисления подразумевают использование физических устройств, которые рассредоточены на обширной территории (например, банкоматы) и даже могут активно перемещаться в пространстве (складские погрузчики или беспилотные автомобили). Такое резкое увеличение парка и разнообразия устройств, образующих цифровой домен, принципиально меняет архитектурные подходы к распределенным вычислениям, см. Рис. 1.

Критическим фактором при проектировании архитектуры граничных вычислений является сегментация: физическая, логическая и на уровне данных. В edge computing очень важно, где и как именно существуют вычислительные ресурсы, образующие домен приложения. Кроме того, если в облачных вычислениях главным предметом обеспокоенности является защита данных, то в граничных вычислениях не менее важно защищать от вредоносного вторжения и сами устройства, между которыми циркулируют данные, а количество таких устройств может исчисляться не только десятками и сотнями, но и тысячами. В самом деле, вам вряд ли понравится, если хакер подключится к умной колонке в вашей гостиной и начнет прослушивать домашние разговоры? Или, не дай бог, перехватит управление электронным ассистентом в вашем автомобиле и устроит Армагеддон прямо посреди города.

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

В этой статье мы рассмотрим сегментацию граничных вычислительных сред, обсудим сопутствующие таким средам проблемы, и разберем различные подходы к сегментации: физические, логические и на уровне данных.

Проблемы на пороге

Вместе с граничными вычислениями в распределенных системах появляется ряд факторов, которые усложняют архитектурное проектирование сегментации. Если классическая среда облачных вычислений относительно однородна и состоит из дата-центров, заполненных стойками серверов x86 или мейнфреймов, которые связаны оптоволоконным Ethernet-ом и общаются по TCP/IP, то граничные вычисления выводят на арену широкий спектр устройств и коммуникационных протоколов на базе различных аппаратных архитектур и чипсетов. Одни из этих устройств, такие как банкоматы, используют стандартные процессоры x86. Другие, например, различные системы на базе микрокомпьютеров Raspberry PI, построены на архитектуре ARM. И наконец, третьи, вроде роботизированных систем или автомобилей, используют узко специализированные чипсеты.

Помимо железа взрыв разнообразия происходит и на уровне коммуникационных протоколов. Одни устройства могут напрямую подключаться Ethernet-кабелем, другие по беспроводному 802.11x, третьи через Bluetooth. И все эти устройства требуется поддерживать.

Другой важный момент обновление этих новых граничных систем. Для стандартных вычислительных устройств, таких как ноутбуки, планшеты или мобильные телефоны, обновление выполняется довольно просто, поскольку они, как правило, почти всегда доступны по сети. Но как обновить ПО на беспилотном автомобиле, который использует очень специфическое железо и протоколы, а к сети подключен отнюдь не постоянно? Это создает серьезные вызовы при проектировании ИТ-архитектуры предприятия, которые надо всесторонне учитывать. И именно поэтому в граничных вычислениях так важно тщательно прорабатывать сегментацию на физическом и логическом уровнях, а также на уровне данных.

Физическая сегментация

Физическая сегментация это про то, как разнести части распределенной архитектуры по различным физическим машинам. Как уже говорилось, в дата-центре физическая сегментация обычно сводится к размещению оборудования в серверных стойках внутри одного здания. В ситуациях, когда требуется обеспечить молниеносную связь между какими-то конкретными машинами, их надо размещать как можно ближе друг к другу. Это просто законы физики: чем меньше расстояние, тем быстрее обмен данными. Для приложений, менее требовательных в плане задержек, физическое расстояние между машинами внутри дата-центра не критично, им просто достаточно быть в одном здании.

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

Одна из таких моделей разбиения получила название туманных вычислений (fog computing) и подразумевает наличие промежуточных дата-центров и точек сбора данных, расположенных между устройствами IoT и главным центром обработки данных, см. Рис. 2.

В рамках fog-модели дата-центры зачастую выступают в роли квази-граничных устройств: они работают в частных сетях, обслуживают какую-то конкретную локацию и решают какую-то специфическую задачу.

Хорошим примером fog-архитектуры является городская система дорожных камер, которые группами подключаются к районным ЦОД в городской сети, а эти ЦОД уже подключены к главному дата-центру города. Передача данных при этом становится эффективнее, так как каждая камера подключена к fog-облаку. Однако простое перемещение данных туда и обратно имеет смысл только с точки зрения логики использования этих данных. Здесь можно добиться хорошей эффективности, если разместить критически важный программный интеллект в правильно выбранном относительно других вычислительных активов месте. И именно здесь в игру вступает сегментирование программной логики.

Сегментирование логики

Интеллект веб-приложений часто распределяется таким образом, чтобы реализовать логику пользовательского интерфейса, правила проверки и некоторых вычислительных задачи непосредственно на веб-странице или на клиентском устройстве. Вычислительная логика более сложных многоуровневых приложений, вроде покупок на сайте Amazon, реализуется в дата-центре. Во многих отношениях архитектура веб-приложений близка к традиционной архитектуре клиент-сервер.

Однако, в случае edge-вычислений веб-серверная модель сегментации логики между граничным устройством и главным дата-центром не всегда имеет смысл, особенно если граничное устройство представляет собой специализированную машину, вроде умного складского погрузчика или дорожной камеры наблюдения. Здесь сам сетевой трафик, вернее его отсутствие, может стопорить работу, например, когда погрузчик заезжает в мертвую зону и не может связаться с главным дата-центром. Поэтому выбор ответа на вопрос, где и как сегментируется логика это важное архитектурное решение.

Эмпирическое правило гласит, что на каждом физическом уровне должно присутствовать столько логики, сколько требуется для выполнения работы на этом участке. Допустим, IoT-устройство это умный складской погрузчик с геолокацией в реальном времени, который может сам находить нужный отсек на складе и забирать оттуда паллету с запрошенным товаром. В этом случае логика безопасного передвижения по складу должна быть реализована на самом погрузчике. Погрузчик не должен постоянно спрашивать сервер, как ему двигаться по складу. Кроме того, непосредственно на погрузчике должна иметься и логика его обновления. Это может быть SSH-сервер, чтобы оператор или bash-скрипт могли делать обновление. Либо это может быть подписчик системы обмена сообщениями, привязанный к расположенному в fog-облаке брокеру и получающий от него сигнал о необходимости обновить свой код и затем связывающийся с fog-сервером с помощью клиента HTTP.

Навигация по складу, выбор паллеты с нужным товаром и активное участие в обновлении своего ПО это основные функции погрузчика. А вот работа с данными клиентского заказа, к которому относится товар, к основным функциям погрузчика не относится. Поэтому соответствующая логика должна реализовываться уже в другом месте, например, на серверной миниферме на том же складе, где работает погрузчик, либо выше, где-то в частном fog-облаке, накрывающем территорию склада.

Также логично будет разграничить обработку заказов, чтобы каждый склад обрабатывал только свои заказы. Есть и следующий, более высокий уровень логики, где клиентский заказ уже отслеживаются в рамках общей картины управления цепочками поставок, и который реализуется на уровне корпоративной системы ERP, охватывающей все регионы присутствия компании, см. Рис. 3.

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

Умение сегментировать это одновременно и наука, и искусство. Важно понимать, что сегментация логики является важным аспектом проектирования архитектуры граничных вычислений и требует самого тщательного обдумывания и планирования, а также четкого понимания задач каждого элемента в архитектуре граничных вычислений.

Сегментирование на уровне данных

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

Впрочем, всегда полезно помнить, что маленькие пакеты проще передаются по сети и быстрее обрабатываются, чем большие. Преобразование данных в двоичный формат, такой как Protocol Buffers, и потоковая передача данных, такая как gRPC, обеспечивают очень быстрый обмен данными. Обратная сторона перехода на двоичные структуры данных и потоковую передачу усложнение архитектуры за счет упаковки и обработки данных. Как бы то ни было, основное правило здесь следующее: маленькие пакеты это хорошо, а потоковые данные еще лучше! Запомним это правило и вернемся к сценарию со складом и умным погрузчиком.

В этом сценарии есть три точки обмена данными: умный погрузчик, локальное частное fog-облако склада и координирующая цепочку поставок ERP-система, которая расположена в защищенном глобальном облаке.

Задача погрузчика забрать паллету с нужным товаром из складского отсека. Для этого локальное fog-облако склада отправляет погрузчику соответствующую информацию о заказе.

Причем, fog-облако отслеживает передвижения погрузчика, а также отправляет в ERP-систему данные по выполнению заказа после того, как погрузчик заберет на складе паллету с товаром и загрузит ее в грузовик для доставки клиенту.

В свою очередь, расположенная в глобальном облаке ERP отправляет складскому fog-облаку информацию по заказам, которые надо отправить клиентам. Полностью этот сценарий показан на Рис.3.

Теперь займемся сегментацией данных с учетом конечных точек.

Как происходит обмен данными в средах IoT

Начнем с погрузчика. Он, во-первых, должен отправлять в частное fog-облако свое местоположении, чтобы fog мог строить оптимальный маршрут к нужному складскому отсеку. Во-вторых, погрузчик сообщает в fog свой операционный статус, чтобы склад своевременно знал, если погрузчик вышел из строя.

Данные о местоположении и статусе очень чувствительны ко времени. Если какой-то проезд по складу оказывается заблокирован, то погрузчик должен срочно изменить свой маршрут. Или если погрузчик вдруг сломался, то заказ, который он обрабатывал, необходимо передать другому погрузчику. Погрузчик может инкапсулировать данные о местоположении, маршрутизации и состоянии в небольшие структурированные сообщения, которые непрерывным потоком передаются в складское fog-облако. Как уже говорилось, потоковые данные передаются быстро и эффективно, особенно если текст предварительно трансформируется в двоичный формат. Таким образом, сегментация данных в двоичные сообщения с потоковой пересылкой gRPC, решает поставленную задачу.

Что касается клиентского заказа, то погрузчику достаточно знать лишь ID заказа, идентификатор товара (SKU) и складской отсек, где хранится паллета с этим товаром. Эти три значения можно упаковать в очень маленькое сообщение, которое погрузчик будет получать от fog-облака. Доставку таких сообщений легко организовать с помощью типового запроса-ответа HTTP на RESTful API, а чтобы ускорить передачу информации о заказе, погрузчик и fog-облако могут общаться через двусторонний поток gRPC.

На самом деле неважно, какой транспортный метод используется в системе. Важно лишь чтобы данные, которыми обмениваются устройство IoT (в нашем случае погрузчик) и частное fog-облако, координирующее работу этого устройства на складе, сегментировались на небольшие сообщения, которые можно было отправлять и принимать очень быстро. Короче говоря, здесь прежде всего важна скорость. И именно под эту задачу и сегментируются данные.

Сегментирование данных при обмене между fog-облаком и корпоративным облаком

Сегментация данных при информационном обмене между складским fog-облаком и корпоративной системой ERP, расположенной в глобальном облаке, существенно отличается от только что рассмотренной выше, и прежде всего тем, что здесь совсем не так критичен фактор времени.

Обмен данными между устройством IoT и fog-облаком должен быть практически мгновенным, то есть измеряться миллисекундами. Обмен данными между fog-облаком и глобальной системой ERP вполне переживет задержку в секунду-две. Кроме того, системе ERP и складскому fog-облаку нужна только информация о выполнении заказа. Иначе говоря, здесь вполне возможен пакетный обмен, когда одно сообщение содержит данные сразу по нескольким заказам. В результате сообщения становятся больше, но это не страшно, поскольку на обмен информацией есть гораздо больше времени, см. рис. 4.

Обмен данными можно упростить за счет использования стандартного HTTP через RESTful API или же передавать их потоковым методом, тут уже дело личных предпочтений. Кому-то работать через REST на уровне ERP покажется намного проще, чем создавать и поддерживать механизмы кодирования-декодирования двоичных потоков данных по открытому и постоянному сетевому соединению. Интересно отметить, что наряду с сегментацией данных с учетом специфики физической среды и решаемых задач, для успешной работы организации требуется и сегментация ИТ-специалистов по профессиональным навыкам, чтобы нужные люди были на нужных местах.

Для программирования устройств IoT требуется совсем другие навыки, чем для кодирования систем ERP, особенно при работе со специализированными IoT-устройствами с проприетарными языками программирования. И организации склонны сегментировать ИТ-разработчиков соответствующим образом. Поэтому выбор используемых API-фреймворков и форматов данных в некоторой степени определяется и наличием людей с определенными квалификациями, а не только спецификой задач, которые решаются в ходе обмена данными, и особенностями физической среды, где происходит такой обмен.

Подводим итоги

Граничные вычисления это следующий большой шаг в распределенных вычислениях. Неуклонный рост интернета вещей и все более широкое распространение коммерческих веб-приложений выводит граничные вычисления в разряд главных задач проектирования и построения ИТ-архитектур.

С граничными вычислениями современное цифровое предприятие становится гораздо сильнее. Но где сила, там и ответственность. Поэтому для развития корпоративной архитектуры важно иметь хотя бы общее представление о том, какие факторы стоят за той или иной моделью сегментации граничных вычислений. В этом посте мы лишь слегка затронули эту тему, но надеемся она послужит вам хорошей отправной точкой.

Мы собрали для вас короткий дайджест полезных материалов, найденных нами в сети за последние две недели. Оставайтесь с нами станьте частью DevNation!

Начни новое:

• Бесплатная подписка на RHEL что и как
  Как зарегистрировать и активировать бесплатную подписку на Red Hat Enterprise Linux и что она дает

• Как Red Hat портировала OpenJDK на ARM64
  Инженеры Red Hat и энтузиасты open source реализовали стандартный OpenJDK для платформы AArch64.

• Обновленный static analysis в GCC 11
  Исправления и улучшения режима -fanalyzer в GNU Compiler Collection (безопасность, state tracking и другое).

• Руководство по использования кода CentOS Project
  Как мы теперь будем публиковать исходники CentOS и как вам их правильно использовать в своих проектах и продуктах

• Фонд OpenJS запустил опрос по Node.js
  Он называется 2021 Node.js User Survey и призван дать ответы на вопросы: кто и как использует Node.js, а также дать возможность высказаться по этому проекту всем желающим.

• Вебинар DevNation Tech Talk Искусство конструирования Java API
  В ходе презентации мы обсудим стандартный Java API, а также реальные примеры плохого и хорошего API, а также API идеального - насколько такое возможно.

• Справочное руководство Quarkus Cookbook (НОВИНКА)
  Как не выпасть из темы и работать продуктивнее в мире облачных приложений, используя Quarkus.

• Удаленная работа: 10 советов, как улучшить сотрудничество на удаленке
  Несоответствие ожиданиям, плохие инструменты и даже плохие манеры все это вредит сотрудничеству. Представляем лучшие практики удаленной работы, которые пригодятся как руководителям, так и всем сотрудникам.

Качай:

• Бесплатный Developer Sandbox for OpenShift
  Это ваш личный OpenShift в облаке, всего за пару минут и без какой бы то ни было инсталляции. Среда создана специально для разработчиков и включает в себя Helm-диаграммы, builder-образы Red Hat, инструменты сборки s2i, также CodeReady Workspaces, облачную IDE с веб-интерфейсом.

Мероприятия:

• Построение интеграционной архитектуры нового поколения с Red Hat Middleware, 26 февраля, 11:00
  Red Hat и официальный дистрибьютор вендора компания Axoft, приглашают вас принять участие в экспертной сессии Построение интеграционной архитектуры нового поколения с Red Hat Middleware.

• Red Hat: Обзор событий за 2020 год от MONT, 26 февраля, 11:00
  Центр компетенций Red Hat at MONT подведет итоги неоднозначного 2020 года и поговорит о планах на 2021.

• Виртуальный Red Hat Summit 2021, 27-28 апреля
  Бесплатная онлайн-конференция Red Hat Summit это отличный способ узнать последние новости ИТ-индустрии, задать свои вопросы техническим экспертам, услышать истории успеха непосредственно от заказчиков Red Hat и увидеть, как открытый код генерирует инновации в корпоративном секторе.

Начинаем 2021 год с нового дайджеста полезных материалов. Собрали много инсайтов, записей важных вебинаров, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Начни новое:

• Список опенсорсных альтернатив популярному проприетарному софту

• 5 тенденций гибридного облака, на которые стоит обратить внимание в 2021 году

  Гибридное облако становится главной моделью построения корпоративных ИТ-систем. Наши эксперты рассказывают, как изменятся сами облачные платформы, а также обсуждают дифференцированный выбор облачных сред для рабочих нагрузок, вопросы безопасности и другие темы.

  Вкратце: главный архитектор Red Hat Эмили Бренд (Emily Brand) и другие эксперты делятся советами с ИТ-руководителям.

• Удаленная работа: 3 способа взбодрить свою команду в 2021 году

  Новый Год это новая возможность подзарядить энергией вашу команду. Представляем новые методики, которые помогут стимулировать креативность, сотрудничество и вовлеченность на виртуальных рабочих местах.

  Вкратце: главный технический специалист Red Hat по работе с публичным сектором Дэвил Эгтс (David Egts) рассказывает о виртуальных комнатах отдыха и других подобных вещах.

• Удаленная работа: 5 советов, как выйти из затяжных праздников

  Не получается вернуться в рабочий ритм после новогодних каникул? Наши советы помогут сделать это осознанно и целенаправленно.

  Вкратце: ключевые слова цели и границы.

Почитать на досуге:

• Настройка Home Assistant для управления умным домом с открытым кодом

  В четвертом выпуске статей на тему домашней автоматизации рассказываем, как установить и сконфигурировать Home Assistant.

• FeatherPad текстовый редактор для Linux-терминала

  Максимум утилитарности: под рукой только необходимый функционал и ничего лишнего.

• Изучаем Bash путем написания интерактивой игры

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

  

• Как я использую пульт Stream Deck в Linux с помощью open source инструментов

• Создаем культуру DevOps на базе принципов open source

• Почему веб-разработчикам нравится текстовый редактор Brackets

• Настройка гиперконвергентной инфраструктуры с помощью инструментов open source

Скачать:

• Шпаргалка по MariaDB и MySQL

  Полезные команды для подключения к серверам, анализа данных и других ключевых операций, которые можно применять из командной строки и в составе SQL-сценариев, причем многие из них также можно задействовать через программные библиотеки.

Еще полезное:

• eЭлектронная книга Автоматизированное предприятие (The automated enterprise)

• Бесплатный онлайн-курс по основам Ansible

• Шпаргалка для разработчиков по продвинутым командам Linux

• 5 предсказаний для Kubernetes на 2021 год

• Мои 8 любимых полезных команд Linux

• 3 архитектурных соображения по использованию Kubernetes и контейнеров

• Raspberry Pi: приступая к работе

  Это руководство поможет не только выбрать правильную модель микрокомпьютера Raspberry Pi, но и регулярно обновлять на нем ОС, запускать Linux-игрушки, вносить свой вклад в работу соответствующего сообщества и делать много других вещей.

• Запускаем Kubernetes на Raspberry Pi

  Каждую главу этой электронной книги можно читать как самостоятельную единицу или как часть общего руководства по запуску Kubernetes на Raspberry Pi.

• Шпаргалка по Kubectl

  9 критически важных команд kubectl для устранения неполадок и управления при администрировании кластера Kubernetes.

• Шпаргалка по Emacs

  В Emacs огромное множество клавиатурных сокращений для быстрого вызова команд, эта шпаргалка познакомит с основными из них.

• Шпаргалка по языку программирования Си

  Краткая памятка по синтаксису языка Си, уместившаяся на двух сторонах одного листа.

• 5 опенсорсных инструментов для совместной работы

  Клиенты электронной почты, альтернатива Google Docs и другие инструменты для эффективной командной работы.

Начинаем 2021 год с нового дайджеста полезных материалов. Собрали много инсайтов, записей важных вебинаров, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Начни новое:

• Список опенсорсных альтернатив популярному проприетарному софту

• 5 тенденций гибридного облака, на которые стоит обратить внимание в 2021 году

  Гибридное облако становится главной моделью построения корпоративных ИТ-систем. Наши эксперты рассказывают, как изменятся сами облачные платформы, а также обсуждают дифференцированный выбор облачных сред для рабочих нагрузок, вопросы безопасности и другие темы.

  Вкратце: главный архитектор Red Hat Эмили Бренд (Emily Brand) и другие эксперты делятся советами с ИТ-руководителям.

• Удаленная работа: 3 способа взбодрить свою команду в 2021 году

  Новый Год это новая возможность подзарядить энергией вашу команду. Представляем новые методики, которые помогут стимулировать креативность, сотрудничество и вовлеченность на виртуальных рабочих местах.

  Вкратце: главный технический специалист Red Hat по работе с публичным сектором Дэвил Эгтс (David Egts) рассказывает о виртуальных комнатах отдыха и других подобных вещах.

• Удаленная работа: 5 советов, как выйти из затяжных праздников

  Не получается вернуться в рабочий ритм после новогодних каникул? Наши советы помогут сделать это осознанно и целенаправленно.

  Вкратце: ключевые слова цели и границы.

Почитать на досуге:

• Настройка Home Assistant для управления умным домом с открытым кодом

  В четвертом выпуске статей на тему домашней автоматизации рассказываем, как установить и сконфигурировать Home Assistant.

• FeatherPad текстовый редактор для Linux-терминала

  Максимум утилитарности: под рукой только необходимый функционал и ничего лишнего.

• Изучаем Bash путем написания интерактивной игры

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

  

• Как я использую пульт Stream Deck в Linux с помощью open source инструментов

• Создаем культуру DevOps на базе принципов open source

• Почему веб-разработчикам нравится текстовый редактор Brackets

• Настройка гиперконвергентной инфраструктуры с помощью инструментов open source

Скачать:

• Шпаргалка по MariaDB и MySQL

  Полезные команды для подключения к серверам, анализа данных и других ключевых операций, которые можно применять из командной строки и в составе SQL-сценариев, причем многие из них также можно задействовать через программные библиотеки.

Еще полезное:

• Электронная книга Автоматизированное предприятие (The automated enterprise)

• Бесплатный онлайн-курс по основам Ansible

• Шпаргалка для разработчиков по продвинутым командам Linux

• 5 предсказаний для Kubernetes на 2021 год

• Мои 8 любимых полезных команд Linux

• 3 архитектурных соображения по использованию Kubernetes и контейнеров

• Raspberry Pi: приступая к работе

  Это руководство поможет не только выбрать правильную модель микрокомпьютера Raspberry Pi, но и регулярно обновлять на нем ОС, запускать Linux-игрушки, вносить свой вклад в работу соответствующего сообщества и делать много других вещей.

• Запускаем Kubernetes на Raspberry Pi

  Каждую главу этой электронной книги можно читать как самостоятельную единицу или как часть общего руководства по запуску Kubernetes на Raspberry Pi.

• Шпаргалка по Kubectl

  9 критически важных команд kubectl для устранения неполадок и управления при администрировании кластера Kubernetes.

• Шпаргалка по Emacs

  В Emacs огромное множество клавиатурных сокращений для быстрого вызова команд, эта шпаргалка познакомит с основными из них.

• Шпаргалка по языку программирования Си

  Краткая памятка по синтаксису языка Си, уместившаяся на двух сторонах одного листа.

• 5 опенсорсных инструментов для совместной работы

  Клиенты электронной почты, альтернатива Google Docs и другие инструменты для эффективной командной работы.

Red Hat очень серьезно относится к будущему Java, остающейся самым популярным языком разработки корпоративных приложений. Почти две трети всех программистов мира относят себя к умеренным или заядлым пользователям Java, которая вот уже 18 лет подряд входит в тройку лучших языков программирования в рейтинге TIOBE. Можно смело сказать, что несмотря на небывалый выбор и доступность новых языков программирования, Java остается де-факто стандартом разработки критически важных бизнес-приложений. Мы в Red Hat считаем своим долгом поддерживать Java-разработчиков и прокладывать для них новые пути для продолжения инноваций.

Среди множества технологий, призванных сохранить роль и место Java в облачных реалиях будущего, одной из наиболее перспективных является Quarkus, фреймворк для разработки Kubernetes-нативных Java-приложений. Quarkus изначально создавался как способ оптимизировать Java для контейнерных сред, и, как результат, способен значительно повысить продуктивность разработчиков и снизить эксплуатационные расходы, превращаясь в ключевой компонент контейнерных рабочих нагрузок. Несмотря на свою молодость и бурный рост, Quarkus уже стал заметным игроком на рынке технологий разработки и задает новый формат работы программистов. Сегодня мы рады сообщить, что Quarkus теперь входит в состав Red Hat OpenShift, и это важный шаг для будущего Java как инструмента разработки современных облачных приложений.

Quarkus на Red Hat OpenShift

Quarkus и до этого уже полностью поддерживался и был доступен в рамках Red Hat Runtimes, но теперь он входит в состав и полностью интегрирован с Red Hat OpenShift, что еще больше упрощает разработку. Разработчики получают знакомые инструменты, возможность удаленной разработки на кластерах с помощью IDE, таких как CodeReady Workspaces, интеграцию с управляемыми конфигурациями, развертывание serverless-нагрузок и управление хранилищами приложений.

В состав Quarkus входят несколько компонентов для разработки и развертывания на OpenShift:

• Quarkus-расширение генерация кода для новых проектов, управление зависимостями проектов, удаленная разработка и отладка, а также простое, в один шаг, развертывание в OpenShiftPlugins для CodeReady Workspaces, включая предварительно настроенные стеки рабочих пространств разработчика, подсказки по свойствам конфигураций и автозавершение кода, снипеты для стандартных типов классов Quarkus, а также создание и развертывание кода в OpenShift непосредственно из IDE.

• Автоматическая привязка тестов исправности (health checks), подключение секретов и предоставление метрик для простой интеграции со средствами мониторинга, наподобие Prometheus

• Автоматическое развертывание контейнеризированных приложений Quarkus в качестве serverless-нагрузок OpenShift.

• Knative-развертывания в один шаг.

Также обеспечивается интеграция с Kubernetes API, включая generic API client и поддержку динамической конфигурации приложений с использованием Kubernetes ConfigMaps и Secrets.

Migration Toolkit for Applications

Мы также обновили Migration Toolkit for Applications, чтобы помочь с переносом приложения Spring Boot в Quarkus на OpenShift. Этот тулкит для консультантов, архитекторов и разработчиков помогает проанализировать Java-код или двоичные файлы с точки зрения различных вариантов трансформации (задаются в виде наборов правил) для эффективной модернизации и миграции приложений. Свежая версия Migration Toolkit for Applications сочетает правила Containerization, OpenJDK и Linux со специально разработанными и протестированными правилами для переноса кода Spring Boot в Quarkus на OpenShift, чтобы лучше учесть особенности гибридного облака.

Теперь Quarkus доступен еще большему число разработчиков, а чтобы узнать о нем больше и начать использовать, обратитесь к сайту: https://developers.redhat.com/products/quarkus/getting-started

Много работая с командами разработки, только что перешедшими на OpenShift, мы стремимся дать им рекомендации и лучшие практики для успешного создания и внедрения приложений на этой платформе. По итогам этой работы мы отобрали 14 ключевых, на наш взгляд, практик, которые можно разбить на две категории: надежность приложений и безопасность приложений. Эти категории пересекаются, поскольку чем выше надежность, тем лучше безопасность, и наоборот, а сам список лучших практик выглядит следующим образом.

Надежность приложений

В этом разделе собраны 9 передовых практик, помогающих повысить доступность и аптайм приложений, а также сделать их лучше в плане пользовательского опыта.

1. Не храните конфигурацию приложения внутри контейнера

Если контейнерный образ содержит конфигурацию для какой-то конкретной среды (Dev, QA, Prod), его не получится без изменений переносить между средами. Это плохо с точки зрения надежности процесса выпуска версий, поскольку в продакшн пойдет уже не тот образ, который тестировался на предыдущих этапах. Поэтому не держите внутри контейнера конфигурацию приложения для конкретной среды, а храните ее отдельно, например, с помощью ConfigMaps и Secrets.

2. Задавайте ресурсные требования и лимиты в определениях podа

Без должной настройки требований к ресурсам приложения могут создавать непосильную нагрузку на память и процессор. И наоборот, имея явно прописанные требования приложения к ЦП и памяти, кластер может эффективно выполнять диспетчеризацию так, чтобы предоставлять приложению запрашиваемые ресурсы.

3. Прописывайте зонды активности (liveness) и готовности (readiness) в определениях podа

С помощью этих зондов кластер может обеспечивать базовую устойчивость: перезапускать приложение, если не проходит liveness, или больше не маршрутизировать на него трафик, когда не отвечает readiness. Подробнее см. раздел Мониторинг работоспособности приложений в документации OpenShift Platform.

4. Используйте PodDisruptionBudget для защиты приложений

Иногда podы приходится убирать с узла кластера, например, при обслуживании хоста, или когда autoscaler даунсайзит кластер, отключая лишние узлы. Чтобы приложение при этом оставалось доступным, надо настроить объекты PodDistruptionBudget.

5. Правильное завершение работы podов

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

6. Один контейнер один процесс

Старайтесь, чтобы каждый процесс работал в своем собственном контейнере. Это повышает изоляцию процессов и предотвращает проблемы с маршрутизацией сигналов и появление зомби-процессов, которые иначе придется периодически вычищать. Подробнее см. разделИзбегайте нескольких процессовв документации OpenShift Platform.

7. Используйте системы мониторинга приложений и оповещения

Мониторинг приложений средствами Prometheus и Grafana помогает поддерживать нормальную работу приложений в продакшн-режиме согласно требованиям бизнеса.

8. Пусть приложения пишут свои логи в stdout/stderr

Тогда OpenShift сможет собирать и пересылать их в централизованную систему обработки (ELK, Splunk). Логи это бесценный ресурс при анализе работы приложения в продакшн-режиме. Кроме того, оповещения, генерируемые на базе содержимого логов, помогают проконтролировать, что приложение работает как задумано.

9. Изучите целесообразность применения Circuit breakers, Timeouts, Retries, Rate Limiting

Эти механизмы повышают устойчивость приложения к отказам, защищая от перегрузок (Rate Limiting, Circuit Breakers) и помогая справляться с сетевыми проблемами (Timeouts, Retries). Рассмотрите возможность применения решения OpenShift Service Mesh, которое позволяет реализовать эти функции, не трогая код приложений.

Безопасность приложений

Ниже приводятся 5 передовых и, на наш взгляд, абсолютно необходимых практик усиления безопасности приложений, которые вам обязательно надо рассмотреть к применению.

10. Используйте только доверенные контейнерные образы

Применяйте вендор-образы везде, где это возможно, поскольку они гарантировано тестируются, дорабатываются на безопасность и обеспечиваются поддержкой. Что касается community-образов, используйте наработки только тех сообществ, которым доверяете. И помните, что в публичных реестрах, вроде Docker Hub, имеются образы неизвестного происхождения не используйте их ни в коем случае!

11. Используйте последние версии базовых контейнерных образов

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

12. build-образы отдельно, runtime-образы отдельно

Build-образ содержит зависимости, которые нужны при сборке приложения, но не нужны при запуске. Поэтому создавайте отдельные runtime-образы с минимумом зависимостей, чтобы уменьшить поверхность атак, а заодно и размер образа.

13. Restricted security context constraint (SCC) везде, где только возможно

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

14. TLS для защиты коммуникаций между компонентами приложения

Компоненты приложения могут пересылать друг другу конфиденциальные данные. Если сеть, в которой работает OpenShift, не может считаться безопасной, то трафик между компонентами приложения можно защитить с помощью TLS-шифрования, а уже упомянутый OpenShift Service Mesh позволяет сделать это, не трогая код приложений.

Заключение

Итак, теперь у вас есть список из 14 лучших практик для построения более надежных и безопасных приложений OpenShift. Это хорошее начало для выработки собственного кодекса разработки для членов вашей команды. Дополнительные сведения и рекомендации можно найти в разделе Создание образов документации OpenShift.

В этом посте мы собрали советы и рекомендации, которые стоит изучить, прежде чем переносить свои приложения в сервисную сетку OpenShift Service Mesh (OSSM). Если вы никогда не сталкивались с сервисными сетками Service Mesh, то для начала можно глянуть страницу OSSM на сайте Red Hat и почитать о том, как система Istio реализована на платформе OpenShift.

Начав изучать Istio, вы скорее всего столкнетесь с приложением bookinfo, которое почти повсеместно используется в качеств наглядного пособия, или же с более продвинутым вариантом в виде приложения Travel Agency. Разбирая эти и другие примеры, вы сможете лучшее понять, как устроена mesh-сетка, и затем уже переносить в нее свои приложения

Сначала о главном

Начать стоит с официальная документация OpenShift Service Mesh 2.0 (OSSM), в ней можно найти массу полезных материалов, в том числе:

• Описание различий между OSSM и родительским СПО-проектом Istio.

• Описание, как установить OSSMи

• Протестировать ее с помощью приложения-примера bookinfo.

• Istiov1.6(архив версий).

• Kialiv1.24(архив версий).

• Jaeger1.20.

Когда дойдет до интеграции вашего приложения в mesh-сетку, надо будет копнуть поглубже и заглянуть в документацию по Istio. Также стоит ознакомиться с release notes соответствующих версий компонентов, входящих Red Hat OSSM.

Если еще не сделали это, то протестируйте свою mesh-сетку с помощью приложения-примера Bookinfo. Если все пройдет нормально, то в нее уже можно будет добавлять ваше приложение.

Первое, что надо сделать при добавлении в mesh-сетку своего приложения убедиться, что sidecarы проксей Envoy правильно внедрены в podы вашего приложения. В OSSM такое внедрение делается довольно просто и хорошо описывается в документации.

Потом воспользуйтесь примером, где описывается, как настраивать ingress-шлюз для приложения Bookinfo, и примените эту конфигурацию к своему приложению, чтобы к нему можно было получать доступ не только изнутри кластера OpenShift, но и извне.

Выбор протоколов

Важно четко понимать, как Istio определяет, какие протоколы использует ваше приложение. Для этого изучите все, что связано с Protocol Selection и app and version labelsв разделе документации Pods and Services.

В противном случае скорее всего произойдет следующий казус. Допустим, вы внедряете в свое приложение sidecarы проксей Istio, загружаете его тестовым трафиком и идёте смотреть граф Kiali. И видите там совсем не то, что ожидали (рис. ниже). Почему? Потому что Kiali и Istio не смогли правильно определить, какие протоколы используют наши сервисы, и отобразили соединения между ними как TCP, а не HTTP.

Istio должен точно знать, какой протокол используется. Если Istio не может определить протокол автоматически, то трактует трафик как обычный (plain) TCP. Если у вас какие-то другие протоколы, их надо вручную прописать в определениях служб Kubernetes Service вашего приложения. Подробнее об этом написано в документации, раздел Protocol Selection.

Чтобы вручную задать, какой протокол использует ваш сервис, надо соответствующим образом настроить объекты Kubernetes Service. В нашем случае в них по умолчанию отсутствовало значение параметра spec -> ports -> name. Если прописать "name: http" для сервисов A, B и C, то граф отобразит эти соединения как HTTP.

Kiali

Kiali это отличный инструмент для того, чтобы начать работать с OpenShift Service Mesh. Можно даже сказать, что именно на нем и надо сосредоточиться, когда вы начинаете работать с mesh-сеткой.

Kiali визуализирует метрики, генерируемые Istio, и помогает понять, что происходит в mesh-сетке. В качестве одной из первоочередных задач мы настоятельно рекомендуем изучить документацию Kiali.

Kiali не только пригодится для визуализации вашего приложения, но и поможет с созданием, проверкой и управлением конфигурациями mesh-сетки. Поначалу изучение конфигураций Istio может быть делом сложным, и Kiali тут сильно поможет.

В Kiali есть много полезных вещей, поэтому мы очень советуем изучить список ее возможностей и FAQ. Например, там есть следующие интересные вещи:

• Функции настройки и валидации

• Мастера настройки и верификация настроек

• Автоматическое внедрение sidecarов

• Функции корреляции в Kiali

Другая важная вещь умение маркировать сервисы приложения с помощью меток (label). Istio, а следовательно и Kiali, требует, чтобы маркировка велась строго определенным образом, который поначалу отнюдь не кажется очевидным, особенно когда весь ваш опыт исчерпывается работой с приложением-примером Bookinfo, где все метки уже есть и всё прекрасно работает из коробки.

Развертывания с использованием меток app и version это важно, поскольку они добавляет контекстную информацию к метрикам и телеметрии, которые собираются Istio и затем используются в Kiali и Jaeger.

Istio может показать такие связи между внутренними и внешними сервисами, о существовании которых вы даже не догадывались. Это полезно, но иногда может раздражать при просмотре графа. К счастью, с графа всегда можно убрать эти Неизвестные узлы.

Еще одна полезная вещь в Kiali это то, что она может провести проверку вашей mesh-сетки, что особенно полезно, когда вы сами создаете конфигурации.

Поначалу графы Kiali могут несколько обескураживать. Поэтому стоит изучить различные типы графов, начав с того, как генерировать графа сервиса и какие бывают функций наблюдения.

Jaeger-выборки

При первоначальном тестировании своего приложения в mesh-сетке вам, скорее всего, захочется, чтобы частота трассировки была больше 50%, желательно, 100%, чтобы отслеживать все тестовые запросы, проходящие через приложение. В этом случае Jaeger и Kiali быстрее наберут необходимые данные, а вам не придется долго ждать обновления информации.

Иначе говоря, нам надо, чтобы sample rate был равен 100% (тут есть соответствие: 10000 = 100%).

Для этого надо подредактировать объект ServiceMeshControlPlane (обычно называется basic-install) в вашем проекте Control Plane (обычно istio-system) и добавить или изменить там следующее значение:

spec: tracing:  sampling: 10000 # 100%

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

Распространение заголовков контекста трассировки

Jaeger помогает убрать одну из проблем, которая возникает при переходе на микросервисную архитектуру, но для этого все сервисы вашего приложения должны правильно распространять заголовки трассировки (trace headers).

Очень полезно отслеживать, как запросы ходят через сервисы (или даже множество сервисов) в вашей mesh-сетке. OSSM может здесь помочь за счет сбора данных в форме spanов и трасс (trace). Просмотр трасс очень помогает понять сериализацию, параллелизм и источники задержек в вашем приложении. Вкратце, span это интервал от начала выполнения единицы работы до ее завершения (например, полная отработка запроса клиент-сервер). Трасса это путь, по которому запрос проходит, двигаясь по mesh-сети, или, другими словами, по мере того, как он передается от одного сервиса вашего приложения к другому. Подробнее об этом можно и нужно почитать в документации OSSM.

Обратите внимание, что в OSSM spanы (единицы работы) автоматически генерируются средствами Istio, а вот трассы нет. Поэтому чтобы распределенные трассы (distributed traces) были полностью просматриваемыми, разработчик должен изменить код так, чтобы любые существующие trace-заголовки правильно копировались при передаче запроса между сервисами. К счастью, вы не обязаны сами генерировать эти заголовки. Если изначально их нет, то они будут автоматически сгенерированы и добавлены первым Envoy-прокси, который встретится на пути запроса (обычно это прокси на ingress-шлюзе).

Вот список заголовков для распространения:

• x-request-id

• x-b3-traceid

• x-b3-spanid

• x-b3-parentspanid

• x-b3-sampled

• x-b3-flags

• x-ot-span-context

Распространение заголовков может выполняться вручную или с использованием клиентских библиотек Jaeger, реализующих OpenTracing API.

Вот как делается ручное распространение trace-контекста на Java:

HttpHeaders upstreamHttpHeaders = new HttpHeaders();if (downstreamHttpHeaders.getHeader(headerName: "x-request-id") != null)   upstreamHttpHeaders.set("x-request-id", downstreamHttpHeaders.getHeader( headerName: "x-request-id"));

Примечание: это надо повторить для всех заголовков из списка выше.

Мастера Kiali и редактор YAML

Проверки

Ручная настройка yaml-манифестов дело утомительное, особенно если значения в одном yaml должны совпадать со значениями в другом, а еще ведь есть жесткие правила отступов. К счастью, в Kiali есть отличная функция, которая поможет при создании и проверке конфигураций.

Создание Istio-ресурсов с помощью Kiali-мастеров

Большую часть конфигураций, которые понадобятся вам в первое время, можно создать с помощью соответствующих мастеров Kiali, которые вызываются через меню Services.

YAML-редактор

Kiali имеет собственный редактор YAML для просмотра и редактирования конфигурационных ресурсов Istio напрямую, который также выявляет некорректные конфигурации.

Часто бывает так, что граф Kiali вдруг выявляет в вашем приложении неизвестные ранее (в том числе и разработчикам) коммуникационные пути. Другими словами, Kiali помогает найти и выявить все существующие пути во время тестирования вашего приложения. Это, конечно, полезно, но иногда может и раздражать. В этом случае их можно просто не отображать на графе, введя "node=unknown" в поле ввода над графом Kiali.

Уберите из кода шифрование коммуникаций

Если вы уже защитили соединения между своими сервисами и/или (скорее всего) используете TLS для внешних соединений, то при переводе приложения в mesh-сетку их надо будет в обязательном порядке выключить и переключиться на чистый HTTP без шифрования. А всем шифрованием теперь займутся Envoy-прокси.

Если ваши сервисы будут связываться с внешними сервисами по TLS, то Istio не сможет инспектировать трафик и Kiali будет отображать эти соединения только как TCP.

В общем, используйте для взаимодействия сервисов только HTTP, но не HTTPS.

Также про внешние сервисы надо поставить в известность и вашу mesh-сетку (см. ниже Настройка внешних сервисов).

Упростите код

Самое время пересмотреть код вашего приложения и убрать из него лишнее.

Одно из преимуществ Service Mesh состоит в том, что реализацию многих вещей по сервисам можно убрать из приложения и отдать на откуп платформе, что помогает разработчикам сосредоточиться на бизнес-логике и упростить код. Например, можно рассмотреть следующие доработки:

• Как сказано выше, убрать HTTPS-шифрование.

• Убрать всю логику обработки таймаутов и повторных попыток.

• Убрать все ставшие ненужными библиотеки.

• Помните, что mesh-сетка увеличивает количество пулов подключений. Если раньше два сервиса связывались напрямую, то теперь у каждого из них есть свой прокси-посредник. То есть фактически вместо одного пула подключений появляются три:

  1. От вашего первого сервиса к локальному для него sidecarу Envoy (расположены в одном и том же podе).

  2. От этого sidecarа к другому sidecarу Envoy, который обслуживает второй сервис и расположен в одном podе с этим сервисом.

  3. И наконец, от того другого sidecarа, собственно, ко второму сервису. Поэтому, возможно, стоит упростить конфигурацию, чтобы не раздувать пулы подключений. Подробнее об этом хорошо написано здесь.

Еще один плюс оптимизации кода это возможность уменьшить размер сервисов и (возможно) поднять их производительность, убрав из них те вещи, которые теперь реализуются на уровне mesh-сетки.

Объекты Service

Убедитесь, что все сервисы вашего приложения взаимодействуют друг с другом через имена объектов Kubernetes Service, а не через OpenShift Routes.

Просто проверьте, вдруг ваши разработчики используют OpenShift Routes (конечные точки ingress на кластере) для организации коммуникаций между сервисами в пределах одного кластера. Если эти сервисы должны входить в одну и ту же mesh-сетку, то разработчиков надо заставить поменять конфигурации/манифесты своих приложений, чтобы вместо конечных точек OpenShift Route использовались имена объектов Kubernetes Service.

Функции аварийного переключения (fallback)

В коде вашего приложения, возможно, потребуется поменять еще кое-что. Envoy-прокси конечно заботятся о таймаутах и повторах, чтобы межсервисные коммуникации были более надежными, но иногда сервисы падают полностью, и такие отказы можно отработать только на уровне приложения. Для этого в коде приложения надо реализовать функции аварийного переключения (fallback), чтобы оно уже само решало, как быть дальше, когда Envoy-прокси уже ничем не может помочь.

Настройка внешних сервисов

Envoy-прокси могут работать не только внутри кластера, но и отправлять трафик за его пределы, если зарегистрировать внешние сервисы в mesh-сетке.

Скорее всего, ваше приложение общается с сервисами за пределами mesh-сетки. Поскольку это внешние по отношению mesh-сетке сервисы, то толку от нее здесь не будет, да? А вот и нет. Эти внешние сервисы можно прописать в Service Mesh и использовать часть её функций и для них.

Подробнее и с примерами можно почитать об этом в документации OSSM. Есть и подробный разбор, как визуализировать внешний трафик Istio в Kiali, и как использовать TLS originationдля зашифрованного egress-трафика.

Вот некоторые из функций Istio, которые можно использовать при работе с внешними сервисами:

1. Шифрование (и простое, и Mutual TLS).

2. Таймауты и повторы.

3. Circuit breakerы.

4. Маршрутизация трафика.

Заключение

С OpenShift Service Mesh вы можете лучше понять, как устроена ваша mesh-сетка, сделать ее более просматриваемой, что, в свою очередь, помогает поднять общий уровень сложности микросервисной архитектуры. Бонусом идет возможность реализовать больше функций и возможностей на уровне самой платформе OpenShift, а не кодировать их на уровне отдельных приложений, что облегчает жизнь разработчикам. Еще один плюс реализация вещей, которые раньше казались неподъемными, например, канареечное развертывание, A/B-тестирование и т.п. Кроме того, вы получаете целостный подход к управлению микросервисными приложениями на всех своих кластерах OpenShift, что хорошо с точки зрения преемственности людей и непрерывности процессов. В конечном итоге, это поможет перейти от монолитных приложений к распределенной микросервисной архитектуре и работать в большей степени на уровне конфигураций, чем кода.

Традиционно конвейеры CI/CD строились поверх физических серверов и виртуальных машин. Контейнерные платформы, вроде Kubernetes и OpenShift, появились на этой сцене гораздо позже. Однако по мере того, как все больше и больше рабочих нагрузок переводится на платформу OpenShift, туда же движутся и конвейеры CI/CD, а конвейерные задания все чаще выполняются внутри контейнеров, работающих на кластере.

Этот пост представляет собой перевод блога нашего друга Алеса Носика, автора блога имени себя ("Helping you navigate the world of Kubernetes"). Девиз Алеса: "Software developer and architect passionate about new technologies, open-source and the DevOps culture. Making the world a better place with software".

Вы можете задать любой вопрос после прочтения Алесу в комментариях. Ну и куда без этого Алес хочет подарить за самые каверзные вопросы набор пешего туриста с картой маршрутов от Red Hat. И шляпу.

В реальном мире компании не ограничиваются одним-единственным кластером OpenShift, а имеют их сразу несколько. Почему? Чтобы запускать рабочие нагрузки как в различных публичных облаках, так и на своих собственных ИТ-мощностях. Либо если организация хранит верность какому-то одному поставщику платформ для того, чтобы эффективно работать в различных регионах мира. А иногда необходимо иметь несколько кластеров и в одном регионе, например, при наличии нескольких зон безопасности, в каждой из которых должен быть свой кластер.

Как видим, у организаций есть масса причин иметь нескольких кластеров OpenShift. Соответственно, конвейеры CI/CD должны уметь работать в таких мультикластерных системах, и ниже мы расскажем, как проектировать такие конвейеры.

CI/CD-конвейер Jenkins

Jenkins это настоящая легенда в мире CI/CD. А ведь когда-то давно он назывался Hudson, впрочем, это совсем уже древняя история. Вернемся к нашей теме и зададимся вопросом, как построить конвейер Jenkins, охватывающий сразу несколько кластеров OpenShift? При проектировании такого конвейера очень важно предусмотреть единую информационную панель, где отображались бы результаты выполнения всех заданий, задействованных в этом конвейере. Если немного подумать, то для этого надо иметь некий главный Jenkins (назовем его мастер-Jenkins), который будет связан с каждым кластером OpenShift. При выполнении конвейера мастер-Jenkins сможет запускать отдельные задания на любом из подключенных кластеров, а журналы вывода заданий будут собираться отправляться на этот мастер-Jenkins, как обычно. Если у нас есть три кластера OpenShift (Dev, Test и Prod), то схема будет выглядеть следующим образом:

Для подключения Jenkins к OpenShift есть замечательный Kubernetes-plugin, с помощью которого мастер-Jenkins сможет создавать эфемерные worker-ы на кластере. Каждому кластеру можно присвоить свою метку узла, чтобы иметь возможность запускать каждый этап конвейера на разных кластерах, просто задавая соответствующую метку. Вот как выглядит простое определение такого конвейера:

stage ('Build') {  node ("dev") {    // running on dev cluster  }}stage ('Test') {  node ("test") {    // running on test cluster  }}stage ('Prod') {  node ("prod") {    // running on prod cluster  }}

В OpenShift есть специальный шаблон для Jenkins, который можно найти в проекте openshift. Этот шаблон позволяет создать мастер-Jenkins, который преднастроен для запуска worker-podов на одном кластере. А дальше придется приложить определенные усилия, чтобы подключить этот мастер-Jenkins к другим кластерам OpenShift, и вся хитрость здесь заключается в настройке сети. Jenkins-овский worker-pod после запуска подключается к мастер-Jenkins. Поэтому нам надо, чтобы мастер-Jenkins был доступен для worker-ов, работающих на любом из наших кластеров OpenShift.

Кроме того, стоит обсудить безопасность. Если мастер-Jenkins может запускать worker-овские pod-ы на OpenShift, то значит он может запускать на этих worker-ах произвольный код. Кластер OpenShift не имеет возможности контролировать, какой код запустит Jenkins-овский worker. Определения заданий управляется Jenkins, поэтому только Jenkins-овские средства контроля доступа решают, можно ли выполнять то или иное задание на том или ином кластере.

Kubernetes-нативный конвейер Tekton

Теперь посмотрим, как организовать мультикластерный конвейер CI/CDВ с помощью Tekton. В отличие от Jenkins, Tekton это Kubernetes-нативное решение: он реализован на основе строительных блоков Kubernetes и тесно интегрирован с Kubernetes. Естественная граница Tekton это кластер. И как тут построить конвейер, который будет охватывать сразу несколько кластеров OpenShift?

Для этого можно скомпоновать схему из несколько конвейеров Tekton. Чтобы объединить несколько конвейеров в один, мы создадим задачу execute-remote-pipeline, которая будет запускать Tekton-конвейер, расположенный на удаленном кластере OpenShift. При выполнении удаленного конвейера эта задача будет подхватывать его вывод. Теперь с помощью этой задачи мы можем объединять несколько конвейеров Tekton на разных кластерах OpenShift и запускать их как один конвейер. Например, на диаграмме ниже показана композиция из трех конвейеров, где каждый из них расположен на своем кластере OpenShift (Dev, Test и Prod):

Выполнение этого конвейера начинается на кластере Dev. Конвейер Dev запустит конвейер Test, который, в свою очередь, запустит конвейер Prod. Объединенные логи можно отследить к окне терминала:

$ tkn pipeline start dev --showlogPipelinerun started: dev-run-bd5fsWaiting for logs to be available...[execute-remote-pipeline : execute-remote-pipeline-step] Logged into "https://api.cluster-affc.sandbox1480.opentlc.com:6443" as "system:serviceaccount:test-pipeline:pipeline-starter" using the token provided.[execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step] You have one project on this server: "test-pipeline"[execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step] Using project "test-pipeline".[execute-remote-pipeline : execute-remote-pipeline-step] Welcome! See 'oc help' to get started.[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] Logged into "https://api.cluster-affc.sandbox1480.opentlc.com:6443" as "system:serviceaccount:prod-pipeline:pipeline-starter" using the token provided.[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] You have one project on this server: "prod-pipeline"[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] Using project "prod-pipeline".[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] Welcome! See 'oc help' to get started.[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] [prod : prod-step] Running on prod cluster[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step]

Обратите внимание, что в этом примере показано каскадное выполнение конвейеров Tekton. Есть и способ компоновки последовательное выполнение нескольких удаленных конвейеров.

Прежде чем переходить к заключению, кратко обсудим компоновку конвейеров с точки зрения безопасности. Kubernetes-нативность Tekton означает, что все управление доступом в нем осуществляется через RBAC. Поэтому, чтобы задача, запущенная на локальном кластере (допустим, на кластере Test на нашей схеме), могла запустить конвейер на удаленном кластере (Prod), у нее должны быть соответствующие разрешения, которые задаются на удаленном кластере (Prod). Таким образом, удаленный кластер, работающий в среде более высоко уровня (Prod), может ограничивать доступ для задач, работающие в среде более низкого уровня (Test). Например, Prod может разрешать Test-у запускать только штатные продакшн-конвейеры, поэтому Test не сможет создавать новые конвейеры в кластере Prod.

Заключение

Итак, мы показали, как в Jenkins и Tekton создавать конвейеры CI/CD, охватывающие сразу несколько кластеров OpenShift, обсудив некоторые аспекты их проектирования, безопасности и реализации.

Нет нужды говорить, что контейнеризированные конвейеры будут работать одним и тем же образом на любом кластере OpenShift, неважно, расположен ли он в публичном облаке или в корпоративном дата-центре, что хорошо иллюстрирует преимущества гибридного облака.

Автор: Ales Nosek

13 мая Алес расскажет про Apache Airflow на OpenShift, и там тоже можно будет задавать вопросы, получать подарки и все такое.

• 13 мая. Вебинар про бессерверные технологии в OpenShift
  Мы начинаем серию вебинаров, посвященных OpenShift'у и его окружению.
  Первый вебинар в серии про бессерверные технологии.

• 20 мая. Вебинар OpenShift Virtualization: Виртуальные машины, контейнеры и serverless вместе, в идеальном порядке
  Третий вебинар в серии про OpenShift Virtualization.

3 мая 2021 года Red Hat выпустила первую общедоступную версию OpenShift Pipelines, облачно-ориентированной системы непрерывной интеграции на базе СПО-проекта Tekton. Решение реализует Kubernetes фреймворк CI/CD для разработки и выполнения конвейеров, в которых каждый шаг запускается в своем собственном контейнере, что позволяет масштабировать шаги независимо друг от друга. Сегодня мы вкратце рассмотрим ключевые особенности и преимущества этого решения, а также приведем список дополнительных ресурсов для дальнейшего знакомства с ней и освоения.

Но, прежде чем переходить к OpenShift Pipelines, освежим в памяти основные концепты Tekton.

Основные концепты Kubernetes-нативной CI/CD

OpenShift Pipelines дополняет Kubernetes/OpenShift соответствующими CRD (ресурсами, определяемыми пользователем) для концептов CI/CD, таких как конвейер (pipeline), задача (task), шаг (step). В результате, эти концепты становятся своими (native) инстанцируемыми их можно создавать в виде отдельных экземпляров и, как следствие, полноценно масштабировать и развертывать, а также обеспечивать их безопасность средствами Kubernetes.

Поэтому для начала вспомним, что такое концепты Tekton:

По сути, основные концепты Tekton делятся на два вида: те, что задают конвейер, и те, что запускают конвейер.

Концепты, задающие конвейер (define pipeline)

• Task повторно используемые и слабо связанные серии шагов (step), которые выполняют определенную задачу, например, сборку контейнерного образа.

• Pipeline описание конвейера и задач (Task), которые он должен выполнять.

Концепты, запускающие конвейер (run pipelines)

• TaskRun запуск и результаты выполнения экземпляра Task.

• PipelineRun запуск и результаты выполнения экземпляра конвейера, который включает в себя ряд концептов TaskRun.

Подробнее об этих концептах можно почитать в официальной документации.

Теперь разберемся, что такое OpenShift Pipelines и для чего он нужен

Что такого особенного в OpenShift Pipelines?

OpenShift Container Platform это ведущая отраслевая Kubernetes-платформа корпоративного класса, которая предоставляет разработчикам множество функций, среди которых есть и CI/CD.

OpenShift Pipelines базируется на СПО-проекте Tekton и расширяет функционал платформы OpenShift стандратными методами, что сильно облегчает жизнь разработчикам.

Установка OpenShift Pipelines через механизм Operator

OpenShift Pipelines поддерживается на уровне механизма операторов, поэтому он легко устанавливается и обновляется, и, соответственно, легко администрируется.

OpenShift Pipelines доступен на сайте OperatorHub, где представлены более 450 различных операторов для OpenShift Container Platform:

Установка OpenShift Pipelines предельно проста, и он сразу устанавливается как оператор уровня кластера, автоматически становясь доступным для всех проектов:

OpenShift Pipelines также дополняет OpenShift соответствующими CR, которые позволят добиться еще большей универсальности в плане конфигурации и интеграции с консолью OpenShift и т.д.

При появлении в OperatorHub новой версии OpenShift Pipelines, вы как администратор можете выбрать обновление до следующей версии, задав нужный канал обновления.

Развитый UI в рамках консоли OpenShift

Tekton тоже дополняет стандартную поставку OpenShift концептами CI/CD, но в нем при создании и запуске конвейеров сложно обойтись без создания YAML-кода, и этого кода требуется писать очень много, тысячи строк. Поэтому Red Hat реализовала в консоли OpenShift полноценный UI для запуска и визуализации конвейеров (как тех, что работают сейчас, так и тех, что уже отработали), а также для графического создания конвейеров. При этом все необходимые YAML-файлы создаются автоматически, без написания какого-либо кода.

Ниже показано графическое представление конвейера, который уже был выполнен на платформе OpenShift, причем прямо из него можно получить доступ к журналам и событиям всех задач этого конвейера:

При желании можно легко просмотреть полный лог выбранной задачи:

Чтобы еще больше облегчить жизнь разработчикам, OpenShift Pipelines позволяет рисовать конвейеры прямо в консоли OpenShift, поэтому вам больше не нужен черный пояс по YAML, чтобы создать свой первый конвейер Tekton:

Но если вы, как обладатель черного пояса по YAML, захотите что-то подправить, это всегда можно сделать прямо из консоли OpenShift:

Более того, OpenShift Pipelines пригодится, даже если вы решите пойти по пути чистого YAML, и предложит вам готовые примеры и снипеты кода для более быстрой разработки конвейеров YAML. Кроме того, в систему можно интегрировать ваши корпоративные снипеты, сделав их доступными всем разработчикам. Именно для этого мы и добавили специальный CRD под названием ConsoleYAMLSamples.

События как триггеры для запуска конвейеров

Хотите увязать запуск конвейеров с некими внешними событиями (в терминах Tekton это называется Trigger), например, push- или pull-запросами Github или Gitlab? Вообще не проблема, в OpenShift Pipelines это есть из коробки, причем поддерживаются различные вендоры, включая Github, Gitlab, BitBucket и т.д.

Вы просто создаете нужный триггер в UI, а OpenShift сам формирует все необходимые концепты, такие как EventListeners, TriggerTemplates (подробнее о них можно почитать в официальной документации).

Готовые повторно используемые задачи и кастомизация

OpenShift Pipelines из коробки содержит десятки готовых задач, которые можно использовать в составе конвейеров, включая задачи по клонированию кода из репозитория, сборки приложений на различных языках программирования, таких как java, dotnet core, python go, nodejs или использования инструментов сборки вроде maven, развертывания приложений и т.д. Список доступных задач можно увидеть в консоли OpenShift, раздел ClusterTasks, меню Pipelines -> Tasks:

Кроме того, этот список можно легко расширить. Для этого достаточно добавить ClusterTasks в кластер, после чего вам станут доступны сотни дополнительных задач на сайте TektonHub, который представляет собой публичный репозиторий для обмена задачами Tekton:

Интеграция с IDE

Разработчики, использующие командную строку и IDE, могут воспользоваться преимуществами Tekton CLI, расширения Tekton для Visual Studio Code и плагина Tekton для IntelliJ, чтобы взаимодействовать с конвейерами прямо из своей обычной среды разработки и создавать, запускать, просматривать и выполнять действия на кластере непосредственно из командной строки.

Полезные ресурсы

В заключение советуем посмотреть видеоверсию этой статьи на английском:

А также рекомендуем следующие ресурсы (EN):

• Запись в блоге Red Hat к выпуску первых общедоступных версий OpenShift Pipelines и OpenShift GitOps

• Cтраница продукта OpenShift Pipelines

• Документация OpenShift Pipelines

• Интерактивные руководства по работе с OpenShift Pipelines

• Демовидео от Siamak Sadeghianfar, продакт-менеджера OpenShift Pipelines

• Серия статей Guide to OpenShift Pipelines в блоге Red Hat OpenShift

Видеоролики на русском:

• Все необходимое за две минуты

• Подробно про Tekton (включая предыдущий ролик с озвучкой)

Вебинары:

• 1 июня. Red Hat Advanced Cluster Security Надежная защита облачных приложений
  На вебинаре рассмотрим инструментыRed Hat Advanced Cluster Security, необходимые для обеспечения безопасности облачных приложений. Эксперты Red Hat и BCC расскажут, как Advanced Cluster Security защищает жизненно важные приложения на протяжении всего процесса сборки, развертывания и выполнения. Устраняет слепые зоны в безопасности и сокращает время и усилия, необходимые для реализации максимального уровня безопасности, а также упрощает анализ, расследование и исправление в системе безопасности

• 17 июня.Установка и операции второго дня
  Расскажем про то, как ставитьOpenShiftс помощью Helper Node и еще немного про Day-2, а также проведеммастер-класс, на котором объясним, что стоит проделать после того, как OpenShift вошел в вашу жизнь.

• OpenShift Serverless (в записи)

• OpenShift Virtualization (в записи)

• Принципы Cloud native apps design (в записи)

• 10 уровней контейнерной безопасности(в записи)

Собрали для вас много новых инсайтов, записей важных вебинаров, книжек и шпаргалок. Прокачивайте скилы, читайте, смотрите, думайте, применяйте на практике! Станьте частью DevNation!

Узнать новое:

• 4 инструмента для Linux
  С Linux практически любая железка превращается в универсальный сервер общего доступа для файлов, аудио-, видео- и прочих ресурсов, с которыми легко и удобно работать с других платформ и устройств.

• Домашний термостат на Raspberry Pi
  Представляем проект ThermOS опенсорсная и пофиксенная альтернатива умным термостатам из коробки.

• 5 признаков того, что вы программируете на Rust
  Автор этой статьи не так давно начал писать на Rust и обнаружил, что стал по-другому относиться к некоторым вещам и словам.

• Собираем электронный календарь для всей семьи из Raspberry Pi и дисплея E Ink

• Опенсорсная программа для управления личными финансами

• Изучаем Java на примере написания классической аркады

• Осваиваем GNU Debugger

• Raspberry Pi на работе и дома: 12 проектов DIY

• 3 интересных программы-терминала для Linux

• Scrcpy: зеркалим экран Android на Рабочий стол Raspberry Pi или любого другого Linux

• 3 опенсорсных программы для создания видео-руководств

• Опенсорный инструмент визуализации многопоточных программ Python

• Как работать со значения словарей в Python

• 10 статей Женщины в хайтеке

Скачать:

• Шпаргалка по Raspberry Pi
  Как загрузить, как поставить ОС, как включить SSH и подключиться по WiFi, как установить ПО и обновить систему, а также где найти дополнительную справку и ответы на вопросы.

• Шпаргалка по Linux grep
  Постигаем секреты поиска строк в файлах с помощью регулярных выражений.

Почитать на досуге:

• Электронная книга Ansible for DevOps

  

• Бесплатный онлайн-курс RHEL Technical Overview

• Отчет Open Source в корпоративном секторе
  Спойлер 90% опрошенных компаний уже используют открытый код

• Иллюстрированное руководство по методологии 12 факторов при разработке приложения

• Один год на удаленке: 5 советов, как не тронуться умом

• Бесплатный онлайн-курс Ansible Еssentials

• Электронная книга Storage patterns for Kubernetes

• Электронная книга The automated enterprise

• 7 ошибок при поиске работы в разгар коронавируса

• 5 фактов о микросервисах, которые нужно знать ИТ-архитектору

• Приступаем к работе с PostgreSQL на Linux

Мероприятия:

• Виртуальный Red Hat Summit 2021, 27-28 апреля
  Бесплатная онлайн-конференция Red Hat Summit это отличный способ узнать последние новости ИТ-индустрии, задать свои вопросы техническим экспертам, услышать истории успеха непосредственно от заказчиков Red Hat и увидеть, как открытый код генерирует инновации в корпоративном секторе

• BCC и Red Hat: Освобождение от рутины. Как Ansible automation platform помогает решить задачи IT инфраструктуры любого уровня, 30 марта
  В ходе практической online-сессии проекта ВСС WEBINAR детально изучаем инструменты платформы Red Hat Ansible Automation, необходимые для реализации автоматизации предприятия. Также вас ждет 2 демо-сессии по оптимизации IT-инфраструктуры с помощью Ansible Automation Platform на примере настройки межсетевого экрана в среде Windows и в среде Linux

• Вебинар про решения Red Hat для SAP на IBM Power Systems, 8 апреля
  Ваш бизнес зависит от среды SAP? Она поддерживает критически важные процессы и предоставляет данные? Неэффективная среда может вызвать задержки, снизить гибкость и повысить расходы в ваших ИТ-подразделениях. Более чем 20-летний опыт инноваций позволяет компаниям Red Hat и SAP разрабатывать решения, отвечающие требованиям критически важных приложений. Red Hat Enterprise Linux это не только стабильная платформа, она дает конкретные преимущества при работе с инсталляциями SAP

Смотри в записи:

• Материалы вебинара про связку RHEL + Smart Management + Insights

• Материалы мероприятия Open Source и Red Hat на примере российских компаний

• AnsibleFest
  Два дня интереснейших докладов, демонстраций и практических занятий. Отличная возможность узнать, как разработчики, администраторы и ЛПР в сфере ИТ отвечают на вызовы перемен с помощью гибких технологий автоматизации с открытым кодом, которые позволяют перейти от того, что есть, к тому, что нужно

• J4K Conference
  Новая виртуальная конференция по Kubernetes, Java и облаку: 17 сессий с сотрудниками Red Hat, включая доклад Марка Литтла (Mark Little), главного человека в Red Hat по связующему ПО.

И вновь мы приготовили для вас много инсайтов, мероприятий, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Узнать новое:

• Делаем свой личный Флайтрадар на Raspberry Pi
  Еще понадобится недорогое USB-радио, антенна и опенсорный софт.

• Опенсорсные инструменты для управления проектами
  Открытые альтернативы Microsoft Project для профессиональной работы с большими проектами.

• Пишем 'Hello World' на WebAssembly

• Как работает файловый ввод-вывод в языке Си

• Секреты работы с историей командной строки в Linux

• Bash-сценарии: читаем данные из текстовых файлов

• Bash-сценарии: пишем данные в текстовые файлы

• Едет Podman через Podman: запускаем контейнер в контейнере

• Загружаем компьютер по сети через UEFI HTTP boot

• Как перенести Linux с BIOS-машины на UEFI

• 5 редко используемых, но полезных Linux-команд

• 6 команд OpenSSL, которые должен знать каждый сисадмин

• Синхронизируем файлы и каталоги в Linux с помощью команды rsync

Скачать:

• Шпаргалка по Linux-команде sed
  SED (Stream EDitor) это потоковый текстовый редактор, который построчно обрабатывает входной поток (файл).

• Бесплатный Developer Sandbox for OpenShift
  Это ваш личный OpenShift в облаке, всего за пару минут и без какой бы то ни было инсталляции. Среда создана специально для разработчиков и включает в себя Helm-диаграммы, builder-образы Red Hat, инструменты сборки s2i, также CodeReady Workspaces, облачную IDE с веб-интерфейсом.

Почитать на досуге:

• Бесплатный онлайн-курс Основы Essentials

• Электронная книга Storage patterns for Kubernetes

• В чем разница между GitOps и DevOps: объясняем за две минуты

• Как ИТ-архитектору говорить про облако с генеральным директором

• 15 самых востребованных ИТ-сертификатов в 2021 году

Мероприятия:

• Виртуальный Red Hat Summit 2021, 27-28 апреля
  Бесплатная онлайн-конференция Red Hat Summit это отличный способ узнать последние новости ИТ-индустрии, задать свои вопросы техническим экспертам, услышать истории успеха непосредственно от заказчиков Red Hat и увидеть, как открытый код генерирует инновации в корпоративном секторе

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

Начни новое:

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

• Учим Си, программируя простую игру
  Игра Угадай число это отличная вводная программа для изучения нового языка программирования. Сегодня напишем ее на Си.

• 3 моих любимых приложения с открытым кодом из разряда productivity
  Помогают оптимизировать рабочие agile-процессы и повысить свою продуктивность.

• 8 шпаргалок по софту Open Source, которые пригодятся в 2021 году

• 8 Kubernetes-инсайтов на 2021 год

• 3 serverless-стратегии, к которым стоит присмотреться в 2021 году

• 10 полезных статей про Ansible для новичков и не только

Скачать:

• Шпаргалка по команде Curl
  Примеры использования и синтаксис curl, включая ее использование для запроса API.

• Шпаргалка по базовым вещам Podman

• Debezium на OpenShift
  Debezium это распределенная опенсорсная платформа для отслеживания изменений в данных. Благодаря ее надежности и скорости ваши приложения смогут реагировать быстрее и никогда не пропустят события, даже если что-то пойдет на так. Наша шпаргалка поможет с развертыванием, созданием, запуском и обновление DebeziumConnector на OpenShift.
  Загрузить шпаргалку

Чем заняться на досуге:

• Бесплатный онлайн-курс Разработка облачных приложений с микросервисными архитектурами

• Что такое SRE (site reliability engineering)

• Что будет в готовящемся тренинге по установке Red Hat OpenShift Container Platform

• Разбираем, что такое edge computing

• 6-й сезон подкаста Command Line Heroes

• 13 советов, как меньше уставать на удаленке

Мероприятия:

• 28 января, DevNation: The Show
  Еженедельный часовой чат в прямом эфире. Как обычно, в программе свежие новости и интерактивная игра для участников.

• DevNation Deep Dive: Kubernetes
  Поспешите, поезд Kubernetes уже отправляется узнайте, как применять, развертывать и использовать Kubernetes для решения задач, с которые вы сталкиваетесь в облаке .

Смотри в записи:

• Вебинар DevNation Tech Talk Сборка kubectl-плагина с помощью Quarkus
  Разбираем, как с нуля спроектировать kubectl-плагин и собрать его, используя Quarkus. Также рассмотрим удобную работу с Kubernetes-кластером с использованием нативной компиляции для получения сверхбыстрых бинарников и расширений для Kubernetes-клиента.

• jconf.dev
  Бесплатная виртуальная Java-конференция прямо у вас на экране: четыре техно-трека с нашими комьюнити-экспертами по Java и облаку, 28 углубленных сессий и два потрясающих основных доклада.

• AnsibleFest
  Два дня интереснейших докладов, демонстраций и практических занятий. Отличная возможность узнать, как разработчики, администраторы и ЛПР в сфере ИТ отвечают на вызовы перемен с помощью гибких технологий автоматизации с открытым кодом, которые позволяют перейти от того, что есть, к тому, что нужно.

• J4K Conference
  Новая виртуальная конференция по Kubernetes, Java и облаку: 17 сессий с сотрудниками Red Hat, включая доклад Марка Литтла (Mark Little), главного человека в Red Hat по связующему ПО.

По-русски:

• Платформа HPE Synergy для решений Red Hat

• DeploymentConfig vs Deployment

• Император Оператор: Операторы в OpenShift и Kubernetes

• OpenShift-специфичные волшебные вещи для сборки и развертывания приложений

• Red Hat OpenShift и Machine API

Унаследованные приложения, как правило, имеют монолитную архитектуру и запускаются на одной или нескольких виртуальных машинах. Некоторые из таких систем легче поддаются модернизации, поскольку в мире контейнеров для них есть неплохие аналоги (EAP, Spring Boot и т.д.). Однако большие классические приложения на .Net, работающие под IIS на Windows-сервере, модернизировать гораздо сложнее, тем более за одну итерацию. Но благодаря OpenShift Virtualization такие ВМ-нагрузки можно импортировать в OpenShift как есть и затем контейнеризировать их поэтапно.

В OpenShift виртуальные машины являются привилегированными гражданами и имеют ровно те же возможности, что и podы, включая обращение к другим объектам и предоставление доступа к себе через конечные точки служб (service endpoints). Поэтому выполнив первичный перенос ВМ-приложения в OpenShift, его затем можно поэтапно модернизировать, а заодно и расширять функционал.

Стратегия миграции Shift and Modernize

Чтобы показать, как это делается, мы для примера возьмем приложение .Net, работающее под IIS на виртуалке Windows Server, импортируем его в OpenShift Virtualization, а затем поэтапно контейнеризуем все его логические слои. Обратите внимание, что стратегия shift and modernize подходит и для других связок операционная системасвязующее ПО.

Этап 1. Импорт ВМ в OpenShift Virtualization

Импорт ВМ в OpenShift возможен несколькими способами. Для виртуальных машин VMware можно использоватьвстроенный инструментарий миграции, который позволяет подключиться к экземпляру VSphere и напрямую импортировать эти виртуалки в OpenShift Virtualization. Для других платформ виртуализации, включая Hyper-V и Xen, можно использовать virt-v2v, чтобы конвертировать образ ВМ в формат, поддерживаемый OpenShift Virtualization, а затем импортировать этот образ, используя методы описанные здесь (EN).

Виртуальная машина запускается с помощью Yaml-конфигурации, базовый вариант которой можно найтиздесь. Этот Yaml-файл содержит определение ВМ, а также объектов service и route, плюс, некоторые функциональные конфигурации для более эффективной работы Windows-ВМ на платформе OpenShift Virtualization.

Нас интересует следующее секция:

 features: acpi: {} apic: {} hyperv: reenlightenment: {} ipi: {} synic: {} synictimer: {} spinlocks: spinlocks: 8191 reset: {} relaxed: {} vpindex: {} runtime: {} tlbflush: {} frequencies: {} vapic: {} evmcs: {} # do not use evmcs if testing with nested virt

После применения этого yaml, мы получаем доступ к графическому интерфейсу Windows UI через VNC Console, которую нам дает OpenShift Virtualization.

Кроме того, теперь у нас есть доступ к приложению через exposed route.

Этап 2. Контейнеризация UI приложения

Не всегда можно мигрировать всё сразу, особенно в случае больших приложений. Например, этому могут препятствовать зависимости от библиотек, которые есть в классическом .NET, но отсутствуют в .Net Core. В этом случае код приложения придется доработать.

И поскольку это можно делать поэтапно, мы начнем с веб-интерфейса и после того, как переведем UI-слой на .Net Core, упакуем его в контейнерный образ для OpenShift. Этот новый UI-pod будет потреблять API, которые предоставляются старым сайтом, работающем под IIS на виртуальной машине.

Приведенный ниже Dockerfile компилирует ваш код .Net Core и создает runtime-образ. Это также можно сделать через сборки S2I.

# https://hub.docker.com/_/microsoft-dotnet-coreFROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS buildWORKDIR /source# copy csproj and restore as distinct layersCOPY ./source .RUN dotnet restore# copy and publish app and librariesCOPY . .RUN dotnet publish -c release -o /app --no-restore# final stage/imageFROM mcr.microsoft.com/dotnet/core/aspnet:3.1WORKDIR /appCOPY --from=build /app .ENTRYPOINT ["dotnet", "ClientListUI.dll"]

Для сборки и отправки этого образа в реестр можно использовать podman. Затем остается только развернуть этот отвечающий за веб-интерфейс pod вместе с виртуальной машиной приложения.

Этап 3. Контейнеризация API

Вслед за UI-слоем мигрируем на .Net Core слой API и развернем его в виде отдельного podа. После чего на исходной виртуалке остается только база данных SQL Server. Соответствующим образом поправим сервис ВМ в части описания доступа:

kind: ServiceapiVersion: v1metadata: name: stage3-win2019-db-vm namespace: stage3 labels: kubevirt.io: virt-launcher kubevirt.io/domain: stage3-win2019-iis-vmspec:  ports: - protocol: TCP port: 1433 targetPort: 1433 selector: kubevirt.io: virt-launcher kubevirt.io/domain: stage3-win2019-iis-vm

Итак, теперь UI-pod нашего приложения вызывает API через service URL нашего API-podа, а тот в свою очередь использует service URL нашей виртуальной машины, чтобы делать запросы к базе данных.

Этап 4. Контейнеризация БД

Да, вы правильно поняли: миграция экземпляра MS SQL в контейнер RHEL. Лет пять назад такое и в голову бы никому не пришло, но сегодня это вполне рабочий вариант и подробнее узнать о том, как настроить и запустить MS SQL в контейнере, можно узнать здесь (EN).

После того, SQL-pod будет готов, остается настроить port forwarding, чтобы можно было работать с БД через MS SQL Management Studio или Azure Data Studio:

 oc get pod | grep sql | grep Runningsql2019-1-1-gp29h 1/1 Running 0 39h oc port-forward sql2019-1-1-gp29h 1433:1433Forwarding from 127.0.0.1:1433 -> 1433Forwarding from [::1]:1433 -> 1433Handling connection for 1433

Теперь можно переносить БД из экземпляра MS SQL на Windows-виртуалке в контейнер SQL Server. После чего, необходимо изменить строку подключения для API-podа приложения и указать в ней pod, где теперь живет ваш MS SQL.

Всё, приложение полностью, на 100% контейнеризовано, и виртуальную машину которую, мы перенесли на первом этапе, можно навсегда отключить.

Заключение

Поэтапная миграция ВМ-нагрузки по методу shift and modernize позволяет снизить технический долг, минимизировать любого рода регрессии, которые могут возникнуть входе этого процесса, ну и попутно расширить функционал приложения в рамках проводимой при такой миграции доработки кода.

Новая порция инсайтов, мероприятий, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Узнать новое:

• Anacron для более удобной работы с crontab
  Вместо того, чтобы вручную выполнять повторяющиеся задачи, позвольте Linux сделать все за Вас

• Гайд по команде git stash
  Узнайте, когда и как пользоваться командой git stash

• Быстрая конфигурация SD-карт для кластера Raspberry Pi
  Создавайте несколько SD-карт, которые сконфигурированы для кластеров Pi с помощью Cloudmesh Pi Burner.

• 3 причины использовать команду Git cherry-pick

• DevOps-руководство по документации

• 20 способов стать продуктивным и начать уважать себя

• Как разделить диск на разделы под Linux с помощью GNU Parted

Скачать:

• Шпаргалка по SQLite
  Держите под рукой полезный список распространенных команд SQLite

Почитать на досуге:

• Электронная книга: Переход на .NET Core на Red Hat Enterprise Linux
  Здесь уже скачана на Google Drive

• Безопасность в числе главных приоритетов при поддержке исследований в IT

• Бесплатный онлайн-курс: "Разработка облачных приложений с микросервисной архитектурой"

• Понять разработчика: иллюстрированное руководство по графикам

• 7 вопросов для собеседования на позицию Site Reliability Engineer (SRE)

• 5 малоизученных, но полезных команд Linux для сисадминов

Мероприятия:

• Виртуальный Red Hat Summit 2021, 27-28 апреля
  Бесплатная онлайн-конференция Red Hat Summit это отличный способ узнать последние новости ИТ-индустрии, задать свои вопросы техническим экспертам, услышать истории успеха непосредственно от заказчиков Red Hat и увидеть, как открытый код генерирует инновации в корпоративном секторе.

• Cook Your Own Cloud: OpenShift + OpenStack + немного перца! 30 апреля
  Миграция на облачную платформу тем актуальнее, чем сложнее инфраструктура и выше число изменений. Как насчет того, чтобы автоматизировать рутинные задачи и сконцентрироваться на бизнес-процессах? Мы в Red Hat знаем, как создать облачное решение для IaaS и PaaS- платформ. И мы хотим поделиться своим опытом! На вебинаре архитектор Дмитрий Алехин расскажет про связку Red Hat Openstack Platform и Red Hat Openshift Container Platform, которые позволяют осуществить стратегию открытого гибридного облака. Регистрируйтесь и приходите!

Мы знаем, как провести эти праздники максимально полезно: собрали для вас много новых инсайтов, записей важных вебинаров, книжек и шпаргалок. Прокачивайте скилы, читайте, смотрите, думайте, применяйте на практике! Станьте частью DevNation!

Узнать новое:

• 6 советов по защите Linux-сервера для начинающих
  Воспользуетесь ими, чтобы сделать свою среду Linux более безопасной.

• Играем в прикольную арифметическую игру с помощью команд Linux
  Почему бы не устроить британское телевикторину Countdown у себя дома?

• 4 способа переключения контекста в Git
  Сравниваем плюсы и минусы четырех подходов к смене бранчей в Git.

• 5 причин, по которым сисадмин должен любить systemd

• Как зариповать и каталогизировать свои аудио-CD с помощью опенсорсных инструментов

• Как сбрасывать сканы документов на Linux-машину по сети

• Балансировка нагрузки, руководство для начинающих

Скачать:

• Шпаргалка по Linux-командам для работы сетями
  Основные команды и что можно узнать с их помощью.

• Шпаргалка по GNU Screen
  В GNU Screen есть море клавиатурных команд. Часто используемые запоминаются легко, а вот за остальными приходится обращаться к экрану справки. Или их можно распечатать и держать под рукой.

Что еще интересного:

• Бесплатный онлайн-курс Основы Ansible

• Шпаргалка по Linux-командам для работы с текстом, дисками, сетями и учетными записями

• Бесплатная запись Red Hat Summit 2021

• 5 аппаратных архитектур для машинного обучения на edge-системах

• 5 признаков, что вам надо поработать над эмоциональным интеллектом

• Домашняя автоматизация: запускаем Home Assistant через Podman

Мероприятия:

• 6 мая. DevNation: The Show

Вебинары:

• 13 мая. Вебинар про бессерверные технологии в OpenShift
  Мы начинаем серию вебинаров, посвященных OpenShift'у и его окружению.

  Первый вебинар в серии про бессерверные технологии.

• 20 мая. Вебинар OpenShift Virtualization: Виртуальные машины, контейнеры и serverless вместе, в идеальном порядке
  Третий вебинар в серии про OpenShift Virtualization