Используете Red Hat Satellite и Red Hat Ansible Automation Platform? Начиная с Satellite 6.3, их можно интегрировать друг с другом, чтобы Dynamic Inventory в Ansible Tower подтягивал списки хостов из Satellite. Кроме того, если хосты RHEL инициализируются средствами Satellite (имеется в виду provisioning), то в этот процесс можно встроить Ansible Tower, чтобы он автоматически запускал на новых хостах сценарии конфигурирования.



В этом посте мы рассмотрим, как настроить Dynamic Inventory в Ansible Tower, чтобы он подтягивал хосты из Satellite, и на примерах покажем, как этим пользоваться. Кроме того, расскажем, как организовать автоматический вызов Ansible Tower после инициализации нового хоста из Satellite.

Хотя сами по себе решения PaaS («Платформа как сервис») не способны изменить способы индивидуального и командного взаимодействия, они часто служат катализатором организационных изменений в ответ на возросшую гибкость ИТ-технологий.



На деле максимальная отдача от инвестиций в PaaS зачастую возможна только при условии изменения организационных ролей, сфер ответственности (задач) и схем взаимоотношений. К счастью, решения PaaS, такие как OpenShift Container Platform, обладают достаточной гибкостью для того, чтобы каждая ИТ-организация могла самостоятельно определять скорость и масштабы перемен относительно вовлеченных людей и происходящих процессов.

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



И Istio вместе OpenShift и Kubernetes превращают развертывание микросервисов в дело по-настоящему скучное и предсказуемое – и это прекрасно. Об этом и о многом другом поговорим в четвертом и последнем посте из серии про Istio.

Принцип неопределенности Гейзенберга гласит, что нельзя одновременно измерить положение объекта и его скорость. Если объект движется, то у него нет местоположения. А если местоположение есть – значит у него нет скорости.



Что касается микросервисов на платформе Red Hat OpenShift (и под управлением Kubernetes), то благодаря соответствующему софту с открытым кодом они могут одновременно рапортовать как о своей производительности, так и об исправности. Старика Гейзенберга это, конечно, не опровергает, но зато устраняет неопределенность при работе с облачными приложениями. Istio позволяет легко организовать отслеживание (трассировку) и мониторинг таких приложений, чтобы держать все под контролем.

Праздники завершились, и мы возвращаемся с нашим вторым постом из серии по Istio Service Mesh.



Сегодняшняя тема – Circuit Breaker, что в переводе на русский электротехнический означает «автоматический выключатель», в просторечии – «автомат защиты». Только в Istio этот автомат отключает не коротнувшую или перегруженную цепь, а неисправные контейнеры.

Мы начинаем серию постов, в которой продемонстрируем некоторые из множества возможностей сервисной сетки Istio Service Mesh в сочетании с Red Hat OpenShift и Kubernetes.



Часть первая, сегодняшняя:

• Объясним концепцию sidecar-контейнеров Kubernetes и сформулируем лейтмотив этой серии постов: «вам не надо ничего менять в своем коде».
• Представим основополагающую вещь Istio – правила маршрутизации. На них строятся все остальные возможности Istio, поскольку именно правила позволяют направлять трафик к микросервисам, используя для этого внешние по отношению к коду сервисов файлы YAML. Также рассматриваем схему развертывания Canary Deployment. Новогодний бонус – 10 интерактивных занятий по Istio

Сегодня мы расскажем о принципах и моделях GitOps, а также о том, как эти модели реализуются на платформе OpenShift. Интерактивное руководство на эту тему доступно по ссылке.



Если вкратце, то GitOps – это набор практических методов использования pull-запросов Git для управления конфигурациями инфраструктуры и приложений. Git-репозиторий в рамках GitOps рассматривается как один единственный источник сведений о состоянии системы, причем любые изменения этого состояния полностью отслеживаются и поддаются аудиту.

В октябре 2019 года вышел OpenShift 4.2, вся суть которого продолжает курс на автоматизацию и оптимизацию работы с облачной средой.



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

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



В Red Hat OpenShift Service Mesh мы выходим за рамки традиционной маршрутизации и предлагаем компоненты для трассировки и визуализации таких запросов, чтобы сделать взаимодействие сервисов более простым и надежным. Введение специального логического уровня управления, так называемой сервисной сетки service mesh, помогает упростить подключение, контроль и оперативное управление на уровне каждого отдельного приложения, развернутого на Red Hat OpenShift, ведущей Kubernetes-платформе корпоративного класса.

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



А если что-то существует, значит в интернете про это уже есть… открытый проект! Смотрите как Open Data Hub помогает масштабировать новые технологии и избегать трудностей при их внедрении.

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



Многих привлекает идея выполнять сборку контейнерных OCI-образов в рамках Kubernetes или подобной системы. Допустим, у нас есть CI/CD, которая постоянно собирает образы, тогда что-то типа Red Hat OpenShift/Kubernetes было бы весьма полезно с точки зрения распределения нагрузки при сборке. До недавних пор большинство людей просто давали контейнерам доступ к Docker-сокету и разрешали выполнять команду docker build. Мы уже несколько лет назад показывали, что это очень небезопасно, фактически, это даже хуже, чем давать беспарольный root или sudo.

Мы давно следим за темой использования systemd в контейнерах. Еще в 2014 году наш инженер по безопасности Дэниел Уолш (Daniel Walsh) написал статью Running systemd within a Docker Container, а еще через пару лет – другую, которая называлась Running systemd in a non-privileged container, в которой он констатировал, что ситуация не очень-то и улучшилась. В частности, он писал, что «к сожалению, и два года спустя, если погуглить «Docker system», то первым делом всплывает всё та же его старая статья. Значит, пора что-то менять». Кроме того, мы уже как-то рассказывали о конфликте между разработчиками Docker и systemd.



В этой статье мы покажем, что изменилось за прошедшее время и как нам может помочь в этом вопросе Podman.

Хотя есть много хороших блогов и учебников по Podman и Buildah, пользователям Docker явно не хватает ясных и четких разъяснений на тему, как им перейти на Podman, зачем нужен Buildah и в других вопросах подобного рода.



Постараемся ответить на эти вопросы и рассказать, как безболезненно мигрировать с Docker на Podman.

Трудно уловить главное, говоря о DevOps? Мы собрали для вас яркие аналогии, ударные формулировки и советы от экспертов, которые помогут дойти до сути даже неспециалистам. В конце бонус – собственный DevOps сотрудников Red Hat.



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

Итак, состоялся официальный запуск платформы Red Hat OpenShift 4. Сегодня мы расскажем, как перейти на нее с OpenShift Container Platform 3 максимально быстро и просто.



В рамках этой статьи нас прежде всего интересуют новые кластеры OpenShift 4, использующие возможности умной и неизменной (immutable – одинаковой для всех сред развертывания) инфраструктуры на основе RHEL CoreOS и средств автоматизации. Ниже мы покажем, как перейти на OpenShift 4 без лишних проблем.

Мы все любим Ansible, но Ansible – это YAML. Для конфигурационных файлов существует масса форматов: списки значений, пары «параметр-значение», INI-файлы, YAML, JSON, XML и множество других. Однако по нескольким причинам из всех них YAML часто считается особенно трудным. В частности, несмотря на его освежающий минимализм и впечатляющие возможности для работы с иерархическими значениями, синтаксис YAML может раздражать своим Python-образными подходом к отступам.



Если вас бесит YAML, вы можете – и должны! – предпринять 10 следующих шагов, чтобы снизить свое раздражение до приемлемого уровня и полюбить YAML. Как и положено настоящему списку, наша десятка советов будет нумероваться с нуля, медитацию и духовные практики добавляем по желанию ;-)

Платформа Red Hat OpenShift Container Platform 4 позволяет поставить на поток создание хостов для развертывания контейнеров, в том числе в инфраструктуре поставщиков облачных сервисов, на платформах виртуализации или в bare-metal системах. Чтобы создать в полном смысле облачную платформу, нам пришлось взять под жесткий контроль все применяемые элементы и таким образом повысить надежность сложного процесса автоматизации.



Очевидным решением стало использование в качестве стандарта Red Hat Enterprise Linux CoreOS (разновидности Red Hat Enterprise Linux) и CRI-O, и вот почему…

Red Hat Satellite – это решение для управления системой, упрощающее развертывание, масштабирование и управление инфраструктурой Red Hat в физических, виртуальных и облачных средах. Satellite позволяет пользователям настраивать и обновлять системы для обеспечения их эффективной безопасной работы в соответствии с различными стандартами. Автоматизируя большинство задач, связанных с поддержанием работоспособности системы, Satellite помогает организациям повысить эффективность, сократить эксплуатационные расходы, и с большей готовностью отвечать на стратегические запросы бизнеса.



Хотя вы можете выполнять основные административные задачи с помощью служб Red Hat, включенных в подписку Red Hat Enterprise Linux, Red Hat Satellite добавляет широкие возможности управления всем жизненным циклом.

Сообщество Ansible постоянно радует новым контентом – плагинами и модулями – создавая и много новой работы для тех, кто занят сопровождением Ansible, поскольку новый код нужно максимально быстро интегрировать в репозитории. Уложиться в сроки получается не всегда и запуск некоторых вполне готовых к выпуску продуктов откладывается до следующей официальной версии Ansible Engine. До недавнего времени у конечного пользователя был только один способ получения нового контента Ansible – вместе с новой версией Ansible Engine.



Для устранения неудобства сообщество Ansible начало работу над более гибкими вариантами создания и получения контента.

«Облачно-ориентированные» (cloud native) или просто «облачные» приложения создаются специально для работы в облачных инфраструктурах. Обычно они строятся как набор слабо связанных микросервисов, упакованных в контейнеры, которые, в свою очередь управляются облачной платформой. Такие приложения по умолчанию готовы к сбоям, а значит надежно работают и масштабируются даже при серьезных отказах инфраструктурного уровня. Обратная сторона медали – наборы ограничений (контракты), которые облачная платформа накладывает на контейнерные приложения, чтобы иметь возможность управлять ими в автоматическом режиме.



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