Представьте, что вы разрабатываете приложение, причем, на своем ноутбуке, где рабочее окружение имеет определенную конфигурацию. Приложение полагается на эту конфигурацию и зависит от определенных файлов на вашем компьютере. У других разработчиков конфигурация может слегка отличаться. Кроме того, в вашей организации есть тестовые и промышленные среды со своими конфигурациями и наборами файлов. Вам хотелось бы как можно точнее эмулировать эти среды у себя, но совершенно не хочется воспроизводить сложные и тяжелые сервера на своей машине. Как же сделать так, чтобы приложение работало во всех средах, прошло контроль качества и попало в продакшн, не сталкиваясь по дороге с массой проблем, требующих постоянной доработки кода?
Ответ: использовать контейнеры. Вместе с вашим приложением контейнер содержит в себе все необходимые конфигурации (и файлы), поэтому его можно легко переносить из среды разработки в среду тестирования, а затем в промышленную среду, не опасаясь никаких побочных эффектов. Кризис устранен, все в выигрыше.
Это, конечно, упрощенный пример, но Linux-контейнеры действительно позволяют успешно справляться с множеством проблем, связанных с переносимостью, настраиваемостью и изоляцией приложений. Будь то локальная ИТ-инфраструктура, облако или гибридное решение на их основе, контейнеры эффективно справляются со своей задачей. Разумеется, помимо собственно контейнеров, важен и выбор правильной контейнерной платформы.
Linux-контейнер – это набор процессов, изолированный от остальной операционной системы и запускаемый с отдельного образа, который содержит все файлы, необходимые для их работы. Образ содержит все зависимости приложения и поэтому может легко переноситься из среды разработки в среду тестирования, а затем в промышленную среду.
И да, и нет. Поможет разобраться такой подход:
Что это значит? Прежде всего, то, что для одновременной работы нескольких операционных систем на одном гипервизоре (программе, которая реализует виртуализацию), требуется больше системных ресурсов, чем для аналогичной конфигурации на основе контейнеров. Ресурсы, как правило, не безграничны, поэтому, чем меньше «весят» ваши приложения, тем плотнее их можно разместить на серверах. Все Linux-контейнеры, работающие на компьютере, используют одну и ту же операционную систему, поэтому ваши приложений и сервисы остаются легковесными и работают в параллельном режиме, не тормозя друг друга.
Прародителем контейнеров можно считать технологию FreeBSD Jail, который появился в 2000 году. Он позволяет создавать внутри одной операционной системы FreeBSD несколько независимых систем, работающих на ее же ядре, так называемых «тюремных камер» (jails). Камеры задумывались как изолированные среды, которые администратор может безопасно предоставлять внутренним пользователям или внешним клиентам. Поскольку камера строится на основе вызова chroot и представляет собой виртуальную среду со своими файлами, сетью и пользователями, процессы не могут выйти за пределы камеры и повредить основную ОС. Однако в силу конструктивных ограничений механизм Jail все же не обеспечивает полной изоляции процессов, и со временем появились способы «побега» из камеры.
Но сама идея была многообещающей, и уже в 2001 году на платформе Linux появился проект VServer, созданный, по словам его основателя, Жака Гелинаса (Jacques Gélinas), для того, чтобы запускать «несколько стандартных Linux-серверов на одной машине с высокой степенью независимости и безопасности». Таким образом, в Linux появился фундамент для реализации параллельно работающих пользовательских сред, и постепенно стало вырисовываться то, что мы сегодня называем контейнерами.
Крупным и быстрым шагом на пути к изоляции стала интеграция уже имеющихся технологий. В частности, механизма cgroups, действующего на уровне ядра Linux и ограничивающего использование системных ресурсов процессом или группой процессов, с системой инициализации systemd, отвечающей за создание пользовательского пространства и запуск процессов. Объединение этих механизмов, изначально созданных для того, чтобы повысить общую управляемость в Linux, позволило значительно лучше контролировать изолированные процессы и заложило основу для успешного разделения сред.
Следующая веха в истории контейнеров связана с развитием пространств имен пользователей (User namespaces), «позволяющих разделить присвоенные процессу идентификаторы пользователя и группы внутри и вне пространства имен. В контексте контейнеров это означает, что пользователи и группы могут иметь привилегии на выполнение определенных операций внутри контейнера, но не за его пределами». Это похоже на концепцию Jail, но более безопасно за счет дополнительной изоляции процессов.
Затем появилась система виртуализации Linux Containers project (LXC), которая предложила ряд крайне востребованных инструментов, шаблонов, библиотек и средств языковой поддержки, резко упростив использование контейнеров на практике.
В 2008 на сцену вышла компания Docker (тогда она называлась dotCloud) с одноименной технологией, объединившей достижения LXC с продвинутыми инструментами для разработчиков и еще больше облегчившей использование контейнеров. Сегодня технология с открытым кодом Docker – это наиболее известный и популярный инструментарий развертывания и управления Linux-контейнерами.
Наряду с многими другими компаниями, Red Hat и Docker являются участниками проекта Open Container Initiative (OCI), целью которого является унификация стандартов управления контейнерными технологиями.
Проект Open Container Initiative работает под эгидой организации Linux Foundation. Он был учрежден в 2015 году «с целью создания открытых отраслевых стандартов контейнерных форматов и сред исполнения». В настоящий момент его главной задачей является разработка спецификаций для контейнерных образов и сред исполнения.
Спецификация среды исполнения задает набор открытых стандартов, описывающих состав и структуру комплекта файловой системы контейнера (filesystem bundle), и то, как этот комплект должен распаковываться средой исполнения. В основном, эта спецификация нужна для того, чтобы контейнер работал, как задумано, и все необходимые ресурсы были доступны и находились в нужных местах.
Спецификация контейнерных образов определяет стандарты для «манифеста образа, сериализации файловой системы и конфигурирования образа».
Вместе две эти спецификации определяют то, что находится внутри контейнерного образа, а также его зависимости, окружения, аргументы и другие параметры, необходимые для корректного выполнения контейнера.
Linux-контейнеры – это очередной эволюционный шаг в развитии методов разработки, развертывания и сопровождения приложений. Обеспечивая переносимость и управление версиями, образ контейнера гарантирует, что если приложение работает на компьютере разработчика, то оно будет работать и в промышленной среде.
Требуя меньше системных ресурсов по сравнению с виртуальной машиной, Linux-контейнер почти не уступает ей в возможностях изоляции и значительно облегчает сопровождение составных многоуровневых приложений.
Смысл Linux-контейнеров в том, чтобы ускорить разработку и помочь вам оперативно реагировать на требования бизнеса по мере их появления, а не предоставить какой-то конкретный софт для решения возникающих задач. Причем, в контейнер можно упаковывать не только приложения целиком, но и отдельные части приложения и сервисы, а затем использовать технологии наподобие Kubernetes для автоматизации и оркестрации таких контейнеризованных приложений. Иначе говоря, можно создавать монолитные решения, где вся логика приложения, runtime-компоненты и зависимости находятся в одном контейнере, или же строить распределенные приложения из множества контейнеров, работающих как микросервисы.
Контейнеры – это отличный способ ускорить доставку ПО и приложений заказчикам, используя их в промышленных средах. Но это закономерно повышает ответственность и риски. О том, как обеспечить безопасность контейнеров, рассказывает Джош Брессер, стратег по безопасности Red Hat.
«Я очень давно занимаюсь вопросами безопасности, и им почти всегда не придают должного значения до тех пор, пока технология или идея не становится мейнстримом, – сетует Брессер. – Все согласны, что это проблема, но так уж устроен мир. Сегодня мир захватывают контейнеры, и их место в общей картине безопасности начинает проясняться. Должен сказать, что контейнеры не являются чем-то особенным, это просто очередной инструмент. Но поскольку сегодня они в центре внимания, то пора поговорить об их безопасности.
Минимум раз в неделю меня заверяют, что запускать рабочие нагрузки в контейнерах – это безопасно, поэтому не стоит беспокоиться, что там внутри них. На самом деле все совсем не так, и такое отношение весьма опасно. Безопасность внутри контейнера важна в той же мере, что и безопасность на любом другом участке ИТ-инфраструктуры. Контейнеры уже здесь, они активно используются и распространяются с поразительной скоростью. Однако никакого волшебства по части безопасности в них нет. Контейнер безопасен настолько, насколько безопасно выполняющееся внутри него содержимое. Поэтому если ваш контейнер содержит кучу уязвимостей, то результат будет точно такой же, как и в случае «голого железа» с той же кучей уязвимостей».
Технология контейнеров меняет устоявшийся взгляд на вычислительную среду. Суть нового подхода в том, что у вас есть образ, который содержит только то, что вам нужно, и который вы запускаете только тогда, когда это нужно. У вас больше нет никакого постороннего софта, который установлен, но работает непонятно зачем и может стать причиной больших неприятностей. С точки зрения безопасности это называется «поверхность атаки». Чем меньше у вас запущено всяких вещей в контейнере, тем меньше эта поверхность, и тем выше безопасность. Однако даже если внутри контейнера запущено немного программ, вам все равно нужно убедиться, что содержимое контейнера не устарело и не кишит уязвимостями. Размер поверхности атак не имеет никакого значения, если внутри установлено нечто, что имеет серьезные уязвимости безопасности. Контейнеры не всемогущи, им тоже нужны обновления безопасности.
Banyan опубликовала отчет под названием «Более 30% официальных образов в Docker Hub имеют уязвимости безопасности с высоким уровнем критичности». 30% – это много. Поскольку Docker Hub является реестром общественного пользования, он содержит массу контейнеров, созданных самой разной публикой. И поскольку размещать контейнеры в таком реестре может кто угодно, никто не поручится, что свежеопубликованный контейнер не содержит старого «дырявого» ПО. Docker Hub – это и благословение, и проклятие. С одной стороны, он экономит массу времени и усилий при работе с контейнерами, с другой, не дает никаких гарантий, что загруженный контейнер не содержит известные уязвимости безопасности.
Большинство этих уязвимых образов не являются вредоносными, никто не встраивал в них «дырявый» софт со злым умыслом. Просто кто-то в свое время упаковал софт в контейнер и выложил его на Docker Hub. Прошло время, и в софте обнаружилась уязвимость. И до тех пор, пока кто-нибудь не будет за этим следить и заниматься обновлением, Docker Hub так и будет рассадником уязвимых образов.
При развертывании контейнеров базовые образы обычно «подтягиваются» из реестра. Если это реестр общественного пользования, то не всегда можно понять, с чем вы имеете дело, и в некоторых случаях получить образ с весьма серьезными уязвимостями. Содержимое контейнера – это действительно важно. Поэтому ряд организаций начинают создавать сканеры, которые заглядывают внутрь контейнерных образов и сообщают о найденных уязвимостях. Но сканеры – это только половина решения. Ведь после того, как уязвимость найдена, для нее нужно найти и установить обновление безопасности.
Конечно, вы можете полностью отказаться от сторонних контейнеров, чтобы разрабатывать их и управлять ими исключительно собственными силами, но это очень непростое решение, и оно может серьезно отвлечь вас от основных задач и целей. Поэтому гораздо лучше найти партнера, который разбирается в безопасности контейнеров и умеет решать соответствующие проблемы, чтобы вы могли сосредоточиться на том, что вам действительно нужно.
Red Hat предлагает полностью интегрированную платформу для внедрения Linux-контейнеров, которая подходит как для небольших пилотных проектов, так и для комплексных систем на основе оркестрируемых мультиконтейнерных приложений – от операционной системы для хоста, где работают контейнеры, до верифицированных контейнерных образов для построения собственных приложений или же платформы оркестрации и средства управления для промышленной контейнерной среды.
Контейнеры и большинство технологий для развертывания и управления ими выпускаются Red Hat в виде ПО с открытым исходным кодом (open source).
Контейнеры Linux – еще один эволюционный шаг в том, как мы разрабатываем, развертываем и управляем приложениями. Они обеспечивают переносимость и контроль версий, помогая гарантировать, что работающее на ноутбуке разработчика будет работать на производстве.
Используете ли вы контейнеры в своей работе и как оцениваете их перспективы? Поделитесь своей болью, надеждами и успехами.
Ответ: использовать контейнеры. Вместе с вашим приложением контейнер содержит в себе все необходимые конфигурации (и файлы), поэтому его можно легко переносить из среды разработки в среду тестирования, а затем в промышленную среду, не опасаясь никаких побочных эффектов. Кризис устранен, все в выигрыше.
Это, конечно, упрощенный пример, но Linux-контейнеры действительно позволяют успешно справляться с множеством проблем, связанных с переносимостью, настраиваемостью и изоляцией приложений. Будь то локальная ИТ-инфраструктура, облако или гибридное решение на их основе, контейнеры эффективно справляются со своей задачей. Разумеется, помимо собственно контейнеров, важен и выбор правильной контейнерной платформы.
Что такое Linux-контейнеры
Linux-контейнер – это набор процессов, изолированный от остальной операционной системы и запускаемый с отдельного образа, который содержит все файлы, необходимые для их работы. Образ содержит все зависимости приложения и поэтому может легко переноситься из среды разработки в среду тестирования, а затем в промышленную среду.
А разве это не просто виртуализация?
И да, и нет. Поможет разобраться такой подход:
- Виртуализация обеспечивает одновременную работу нескольких операционных систем на одном компьютере
- Контейнеры используют одно и то же ядро операционной системы и изолируют процессы приложения от остальной системы
Что это значит? Прежде всего, то, что для одновременной работы нескольких операционных систем на одном гипервизоре (программе, которая реализует виртуализацию), требуется больше системных ресурсов, чем для аналогичной конфигурации на основе контейнеров. Ресурсы, как правило, не безграничны, поэтому, чем меньше «весят» ваши приложения, тем плотнее их можно разместить на серверах. Все Linux-контейнеры, работающие на компьютере, используют одну и ту же операционную систему, поэтому ваши приложений и сервисы остаются легковесными и работают в параллельном режиме, не тормозя друг друга.
Краткая история контейнеров
Прародителем контейнеров можно считать технологию FreeBSD Jail, который появился в 2000 году. Он позволяет создавать внутри одной операционной системы FreeBSD несколько независимых систем, работающих на ее же ядре, так называемых «тюремных камер» (jails). Камеры задумывались как изолированные среды, которые администратор может безопасно предоставлять внутренним пользователям или внешним клиентам. Поскольку камера строится на основе вызова chroot и представляет собой виртуальную среду со своими файлами, сетью и пользователями, процессы не могут выйти за пределы камеры и повредить основную ОС. Однако в силу конструктивных ограничений механизм Jail все же не обеспечивает полной изоляции процессов, и со временем появились способы «побега» из камеры.
Но сама идея была многообещающей, и уже в 2001 году на платформе Linux появился проект VServer, созданный, по словам его основателя, Жака Гелинаса (Jacques Gélinas), для того, чтобы запускать «несколько стандартных Linux-серверов на одной машине с высокой степенью независимости и безопасности». Таким образом, в Linux появился фундамент для реализации параллельно работающих пользовательских сред, и постепенно стало вырисовываться то, что мы сегодня называем контейнерами.
На пути к практическому использованию
Крупным и быстрым шагом на пути к изоляции стала интеграция уже имеющихся технологий. В частности, механизма cgroups, действующего на уровне ядра Linux и ограничивающего использование системных ресурсов процессом или группой процессов, с системой инициализации systemd, отвечающей за создание пользовательского пространства и запуск процессов. Объединение этих механизмов, изначально созданных для того, чтобы повысить общую управляемость в Linux, позволило значительно лучше контролировать изолированные процессы и заложило основу для успешного разделения сред.
Следующая веха в истории контейнеров связана с развитием пространств имен пользователей (User namespaces), «позволяющих разделить присвоенные процессу идентификаторы пользователя и группы внутри и вне пространства имен. В контексте контейнеров это означает, что пользователи и группы могут иметь привилегии на выполнение определенных операций внутри контейнера, но не за его пределами». Это похоже на концепцию Jail, но более безопасно за счет дополнительной изоляции процессов.
Затем появилась система виртуализации Linux Containers project (LXC), которая предложила ряд крайне востребованных инструментов, шаблонов, библиотек и средств языковой поддержки, резко упростив использование контейнеров на практике.
Появление Docker
В 2008 на сцену вышла компания Docker (тогда она называлась dotCloud) с одноименной технологией, объединившей достижения LXC с продвинутыми инструментами для разработчиков и еще больше облегчившей использование контейнеров. Сегодня технология с открытым кодом Docker – это наиболее известный и популярный инструментарий развертывания и управления Linux-контейнерами.
Наряду с многими другими компаниями, Red Hat и Docker являются участниками проекта Open Container Initiative (OCI), целью которого является унификация стандартов управления контейнерными технологиями.
Стандартизация и Open Container Initiative
Проект Open Container Initiative работает под эгидой организации Linux Foundation. Он был учрежден в 2015 году «с целью создания открытых отраслевых стандартов контейнерных форматов и сред исполнения». В настоящий момент его главной задачей является разработка спецификаций для контейнерных образов и сред исполнения.
Спецификация среды исполнения задает набор открытых стандартов, описывающих состав и структуру комплекта файловой системы контейнера (filesystem bundle), и то, как этот комплект должен распаковываться средой исполнения. В основном, эта спецификация нужна для того, чтобы контейнер работал, как задумано, и все необходимые ресурсы были доступны и находились в нужных местах.
Спецификация контейнерных образов определяет стандарты для «манифеста образа, сериализации файловой системы и конфигурирования образа».
Вместе две эти спецификации определяют то, что находится внутри контейнерного образа, а также его зависимости, окружения, аргументы и другие параметры, необходимые для корректного выполнения контейнера.
Контейнеры как абстракция
Linux-контейнеры – это очередной эволюционный шаг в развитии методов разработки, развертывания и сопровождения приложений. Обеспечивая переносимость и управление версиями, образ контейнера гарантирует, что если приложение работает на компьютере разработчика, то оно будет работать и в промышленной среде.
Требуя меньше системных ресурсов по сравнению с виртуальной машиной, Linux-контейнер почти не уступает ей в возможностях изоляции и значительно облегчает сопровождение составных многоуровневых приложений.
Смысл Linux-контейнеров в том, чтобы ускорить разработку и помочь вам оперативно реагировать на требования бизнеса по мере их появления, а не предоставить какой-то конкретный софт для решения возникающих задач. Причем, в контейнер можно упаковывать не только приложения целиком, но и отдельные части приложения и сервисы, а затем использовать технологии наподобие Kubernetes для автоматизации и оркестрации таких контейнеризованных приложений. Иначе говоря, можно создавать монолитные решения, где вся логика приложения, runtime-компоненты и зависимости находятся в одном контейнере, или же строить распределенные приложения из множества контейнеров, работающих как микросервисы.
Контейнеры в промышленных средах
Контейнеры – это отличный способ ускорить доставку ПО и приложений заказчикам, используя их в промышленных средах. Но это закономерно повышает ответственность и риски. О том, как обеспечить безопасность контейнеров, рассказывает Джош Брессер, стратег по безопасности Red Hat.
«Я очень давно занимаюсь вопросами безопасности, и им почти всегда не придают должного значения до тех пор, пока технология или идея не становится мейнстримом, – сетует Брессер. – Все согласны, что это проблема, но так уж устроен мир. Сегодня мир захватывают контейнеры, и их место в общей картине безопасности начинает проясняться. Должен сказать, что контейнеры не являются чем-то особенным, это просто очередной инструмент. Но поскольку сегодня они в центре внимания, то пора поговорить об их безопасности.
Минимум раз в неделю меня заверяют, что запускать рабочие нагрузки в контейнерах – это безопасно, поэтому не стоит беспокоиться, что там внутри них. На самом деле все совсем не так, и такое отношение весьма опасно. Безопасность внутри контейнера важна в той же мере, что и безопасность на любом другом участке ИТ-инфраструктуры. Контейнеры уже здесь, они активно используются и распространяются с поразительной скоростью. Однако никакого волшебства по части безопасности в них нет. Контейнер безопасен настолько, насколько безопасно выполняющееся внутри него содержимое. Поэтому если ваш контейнер содержит кучу уязвимостей, то результат будет точно такой же, как и в случае «голого железа» с той же кучей уязвимостей».
Что не так с безопасностью контейнеров
Технология контейнеров меняет устоявшийся взгляд на вычислительную среду. Суть нового подхода в том, что у вас есть образ, который содержит только то, что вам нужно, и который вы запускаете только тогда, когда это нужно. У вас больше нет никакого постороннего софта, который установлен, но работает непонятно зачем и может стать причиной больших неприятностей. С точки зрения безопасности это называется «поверхность атаки». Чем меньше у вас запущено всяких вещей в контейнере, тем меньше эта поверхность, и тем выше безопасность. Однако даже если внутри контейнера запущено немного программ, вам все равно нужно убедиться, что содержимое контейнера не устарело и не кишит уязвимостями. Размер поверхности атак не имеет никакого значения, если внутри установлено нечто, что имеет серьезные уязвимости безопасности. Контейнеры не всемогущи, им тоже нужны обновления безопасности.
Banyan опубликовала отчет под названием «Более 30% официальных образов в Docker Hub имеют уязвимости безопасности с высоким уровнем критичности». 30% – это много. Поскольку Docker Hub является реестром общественного пользования, он содержит массу контейнеров, созданных самой разной публикой. И поскольку размещать контейнеры в таком реестре может кто угодно, никто не поручится, что свежеопубликованный контейнер не содержит старого «дырявого» ПО. Docker Hub – это и благословение, и проклятие. С одной стороны, он экономит массу времени и усилий при работе с контейнерами, с другой, не дает никаких гарантий, что загруженный контейнер не содержит известные уязвимости безопасности.
Большинство этих уязвимых образов не являются вредоносными, никто не встраивал в них «дырявый» софт со злым умыслом. Просто кто-то в свое время упаковал софт в контейнер и выложил его на Docker Hub. Прошло время, и в софте обнаружилась уязвимость. И до тех пор, пока кто-нибудь не будет за этим следить и заниматься обновлением, Docker Hub так и будет рассадником уязвимых образов.
При развертывании контейнеров базовые образы обычно «подтягиваются» из реестра. Если это реестр общественного пользования, то не всегда можно понять, с чем вы имеете дело, и в некоторых случаях получить образ с весьма серьезными уязвимостями. Содержимое контейнера – это действительно важно. Поэтому ряд организаций начинают создавать сканеры, которые заглядывают внутрь контейнерных образов и сообщают о найденных уязвимостях. Но сканеры – это только половина решения. Ведь после того, как уязвимость найдена, для нее нужно найти и установить обновление безопасности.
Конечно, вы можете полностью отказаться от сторонних контейнеров, чтобы разрабатывать их и управлять ими исключительно собственными силами, но это очень непростое решение, и оно может серьезно отвлечь вас от основных задач и целей. Поэтому гораздо лучше найти партнера, который разбирается в безопасности контейнеров и умеет решать соответствующие проблемы, чтобы вы могли сосредоточиться на том, что вам действительно нужно.
Решения Red Hat для контейнеров
Red Hat предлагает полностью интегрированную платформу для внедрения Linux-контейнеров, которая подходит как для небольших пилотных проектов, так и для комплексных систем на основе оркестрируемых мультиконтейнерных приложений – от операционной системы для хоста, где работают контейнеры, до верифицированных контейнерных образов для построения собственных приложений или же платформы оркестрации и средства управления для промышленной контейнерной среды.
Инфраструктура
- Хост
Red Hat Enterprise Linux (RHEL) – Linux-дистрибутив, заработавший высокую репутацию в мире по уровню доверия и сертификации. Если требуется только поддержка контейнерных приложений, то можно использовать специализированный дистрибутив Red Hat Enterprise Linux Atomic Host. Он обеспечивает создание контейнерных решений и распределенных систем/кластеров, но не содержит функционал операционной системы общего назначения, который есть в RHEL. - Внутри контейнера
Использование Red Hat Enterprise Linux внутри контейнеров гарантирует, что обычные, не контейнеризованные приложения, развернутые на платформе RHEL, будут точно так же работать и внутри контейнеров. Если организация сама разрабатывает приложения, то RHEL внутри контейнеров позволяет сохранить привычный уровень технической поддержки и обновлений для контейнеризованных приложений. Кроме того, обеспечивается переносимость – иначе говоря, приложения будут без проблем работать везде, где есть RHEL, начиная с машины разработчика и заканчивая облаком. - Хранилище данных
Контейнерам может потребоваться много места в хранилище данных. Кроме того, у них есть один конструктивный недостаток – при аварийном завершении работы контейнера находящееся в нем stateful-приложение теряет все свои данные. Интегрированная в состав платформы Red Hat OpenShift программная СХД Red Hat Gluster Storage предоставляет эластичное управляемое хранилище для контейнеризованных приложений, избавляя от необходимости развертывать независимый кластер хранения или тратиться на дорогостоящее расширение традиционных монолитных систем хранения. - Инфраструктура-как-услуга (IaaS)
Red Hat OpenStack Platform объединяет физические серверы, виртуальные машины и контейнеры в одну унифицированную платформу. В результате, контейнерные технологии и контейнеризованные приложения полностью интегрируются с ИТ-инфраструктурой, открывая путь к полной автоматизации, самообслуживанию и квотированию ресурсов по всему стеку технологий.
Платформа
- Платформа контейнерных приложений
Платформа Red Hat OpenShift интегрирует ключевые контейнерные технологии, такие как docker и Kubernetes, с операционной системой корпоративного класса Red Hat Enterprise Linux. Решение может развертываться в частном облаке или в общедоступных облачных средах, в том числе с возможностью сопровождения силами Red Hat. Кроме того, оно поддерживает как stateful-, так и stateless-приложения, обеспечивая перевод на контейнерные рельсы без архитектурной переработки имеющихся приложений. - Решение «все в одном»
Иногда лучше получить все и сразу. Именно для таких случаев и предназначен пакет Red Hat Cloud Suite, в состав которого входит платформа разработки контейнерных приложений, инфраструктурные компоненты для построения частного облака, средства интеграции с общедоступными облачными средами и общая для всех компонентов система управления. Red Hat Cloud Suite позволяет модернизировать корпоративную ИТ-инфраструктуру таким образом, чтобы разработчики могли быстро создавать и предоставлять сервисы сотрудникам и заказчикам, а ИТ-специалисты имели централизованный контроль над всеми составляющими ИТ-системы.
Управление
- Управление гибридными облаками
Успех зависит от гибкости и наличия выбора. Универсальных решений не существует, поэтому в случае корпоративной ИТ-инфраструктуры всегда стоит иметь больше одного варианта. Дополняя общедоступные облачные платформы, частные облака и традиционные дата-центры, контейнеры расширяют выбор. Red Hat CloudForms позволяет управлять гибридными облаками и контейнерами легко масштабируемым и понятным способом, обеспечивая интеграцию контейнерных систем управления, таких как Kubernetes и Red Hat OpenShift, с виртуальными средами Red Hat Virtualization и VMware. - Автоматизация контейнеров
Создание и управление контейнерами – это зачастую монотонная и отнимающая массу времени работа. Ansible Tower by Red Hat позволяет автоматизировать ее и избавиться от необходимости писать скрипты shell и выполнять операции вручную. Сценарии Ansible дают возможность автоматизировать весь жизненный цикл контейнера, включая сборку, развертывание и управление. Вам больше не придется заниматься рутиной, и появится время для более важных дел.
Контейнеры и большинство технологий для развертывания и управления ими выпускаются Red Hat в виде ПО с открытым исходным кодом (open source).
Контейнеры Linux – еще один эволюционный шаг в том, как мы разрабатываем, развертываем и управляем приложениями. Они обеспечивают переносимость и контроль версий, помогая гарантировать, что работающее на ноутбуке разработчика будет работать на производстве.
Используете ли вы контейнеры в своей работе и как оцениваете их перспективы? Поделитесь своей болью, надеждами и успехами.
