«Облачные» или просто «облачные» приложения создаются специально для работы в облачных инфраструктурах.
Обычно они представляют собой набор слабосвязанных микросервисов, упакованных в контейнеры, которые, в свою очередь, управляются облачной платформой.
Такие приложения по умолчанию подготовлены к сбоям, а значит, надежно работают и масштабируются даже в случае серьезных сбоев на уровне инфраструктуры.
Другая сторона медали — наборы ограничений (контрактов), которые облачная платформа накладывает на контейнерные приложения, чтобы иметь возможность управлять ими в автоматическом режиме.
Хотя многие организации полностью осознают необходимость и важность перехода на облачные приложения, они все еще не знают, с чего начать.
В этом посте мы рассмотрим ряд принципов, соблюдение которых при разработке контейнерных приложений позволит реализовать потенциал облачных платформ и добиться надежной работы и масштабирования приложений даже в случае серьезных сбоев в ИТ-инфраструктуре.
уровень.
Конечная цель изложенных здесь принципов — научиться создавать приложения, которыми можно автоматически управлять с помощью облачных платформ, таких как Kubernetes.
Принципы проектирования программного обеспечения
В мире программирования принципы относятся к довольно общим правилам, которые необходимо соблюдать при разработке программного обеспечения.Их можно использовать при работе с любым языком программирования.
Каждый принцип имеет свои цели, инструментами достижения которых обычно являются шаблоны и практики.
Также существует ряд основополагающих принципов создания качественного программного обеспечения, из которых вытекают все остальные.
Вот несколько примеров фундаментальных принципов:
- ЦЕЛОВАТЬ (Будь проще, глупый) – не усложняй;
- СУХОЙ (Не повторяйся) – не повторяйся;
- Ягни (Вам это не понадобится) - не создавайте того, что не нужно сразу;
- SoC Разделите заботы – разделите обязанности.
Кроме того, существует ТВЕРДЫЙ – Набор первых пяти принципов объектно-ориентированного программирования и проектирования, сформулированных Робертом Мартином.
SOLID включает в себя широкие, открытые, взаимодополняющие принципы, которые при совместном применении помогают создавать более качественные программные системы и лучше поддерживать их в долгосрочной перспективе.
Принципы SOLID относятся к области ООП и сформулированы на языке таких понятий и понятий, как классы, интерфейсы и наследование.
По аналогии можно сформулировать принципы разработки и для облачных приложений, только базовым элементом здесь будет не класс, а контейнер.
Следуя этим принципам, вы сможете создавать контейнерные приложения, которые лучше соответствуют целям и задачам облачных платформ, таких как Kubernetes.
Облачные контейнеры: подход Red Hat
Сегодня практически любое приложение можно относительно легко упаковать в контейнеры.Но для эффективной автоматизации и оркестрации приложений на облачной платформе, такой как Kubernetes, требуются дополнительные усилия.
В основу изложенных ниже идей легла методология Приложение Двенадцать Факторов и многие другие работы по различным аспектам создания веб-приложений, от управления исходным кодом до моделей масштабирования.
Описанные принципы применимы только к разработке контейнерных приложений, построенных на основе микросервисов и предназначенных для облачных платформ, таких как Kubernetes. Базовым элементом в нашем обсуждении является образ контейнера, а целевой средой выполнения контейнера является платформа оркестрации контейнеров.
Целью предлагаемых принципов является создание контейнеров, для которых задачи планирования, масштабирования и мониторинга могут быть автоматизированы на большинстве платформ оркестрации.
Принципы представлены в произвольном порядке.
Принцип единого предприятия (SCP)
Этот принцип во многом аналогичен принципу единой ответственности.рекомендуемая розничная цена ), который является частью набора SOLID и гласит, что каждый объект должен иметь одну ответственность, и эта ответственность должна быть полностью инкапсулирована в класс.
Суть SRP в том, что каждая ответственность является причиной изменения, и у класса должна быть одна и только одна причина для изменения.
В SCP мы используем слово «забота» вместо слова «ответственность», чтобы указать на более высокий уровень абстракции и более широкое назначение контейнера по сравнению с ООП-классом.
И если цель SRP — иметь только одну причину для изменений, то за SCP стоит желание расширить возможности повторного использования и замены контейнеров.
Следуя SRP и создавая контейнер, который решает одну проблему и делает это функционально завершенным способом, вы увеличиваете вероятность повторного использования этого образа контейнера в различных контекстах приложения.
Принцип SCP гласит, что каждый контейнер должен решать одну проблему и делать это хорошо.
Более того, SCP в мире контейнеров достичь легче, чем SRP в мире ООП, поскольку контейнеры обычно запускают один единственный процесс, и большую часть времени этот процесс решает одну единственную задачу.
Если какой-то контейнерный микросервис должен решать сразу несколько задач, то его можно разделить на однозадачные контейнеры и объединить в рамках одного пода (единицы развертывания контейнерной платформы) с помощью шаблонов контейнеров Sidecar и Init. Кроме того, SCP позволяет легко заменить старый контейнер (например, веб-сервер или брокер сообщений) на новый, который решает ту же проблему, но имеет расширенную функциональность или лучше масштабируется.
Принцип высокой наблюдаемости (HOP)
Когда контейнеры используются как унифицированный способ упаковки и запуска приложений, сами приложения рассматриваются как «черный ящик».Однако если это облачные контейнеры, то они должны предоставить специальные API для среды выполнения, чтобы отслеживать работоспособность контейнеров и при необходимости предпринимать соответствующие действия.
Без этого не удастся унифицировать автоматизацию обновления контейнеров и управление их жизненным циклом, что, в свою очередь, ухудшит стабильность и удобство использования программного комплекса.
На практике контейнеризованное приложение должно как минимум иметь API для различных типов проверок работоспособности: тестов работоспособности и тестов готовности.
Если приложение заявляет, что может делать больше, оно должно предоставить другие средства мониторинга своего состояния.
Например, регистрация важных событий через STDERR и STDOUT для агрегирования журналов с помощью Fluentd, Logstash и других подобных инструментов.
А также интеграция с библиотеками трассировки и сбора метрик, такими как OpenTracing, Prometheus и т. д. В целом, приложение по-прежнему можно рассматривать как черный ящик, но оно должно быть обеспечено всеми API-интерфейсами, которые необходимы платформе для наилучшего мониторинга и управления им.
Принцип соответствия жизненного цикла (LCP)
LCP является противоположностью HOP. В то время как HOP утверждает, что контейнер должен предоставлять платформе API-интерфейсы чтения, LCP требует, чтобы приложение могло принимать информацию от платформы.Более того, контейнер должен не только получать события, но и адаптироваться, то есть реагировать на них.
Отсюда и название принципа, который можно рассматривать как требование обеспечить платформу написанием API. 
Платформы имеют разные типы событий, которые помогают управлять жизненным циклом контейнера.
Но какие из них воспринимать и как реагировать, решает само приложение.
Понятно, что некоторые события важнее других.
Например, если приложение плохо переносит сбои, оно должно принимать сообщения «сигнал: завершение» (SIGTERM) и как можно быстрее инициировать процедуру завершения, чтобы перехватить сигнал «сигнал: уничтожение» (SIGKILL), который следует после SIGTERM. Кроме того, такие события, как PostStart и PreStop, могут иметь важное значение для жизненного цикла приложения.
Например, после запуска приложения ему может потребоваться некоторое время на разогрев, прежде чем оно сможет отвечать на запросы.
Или приложение должно каким-то особым образом освобождать ресурсы при завершении работы.
Принцип неизменности изображения (IIP)
Общепринято, что контейнерные приложения должны оставаться неизменными после сборки, даже если они запускаются в разных средах.Это приводит к необходимости экстернализировать хранилище данных во время выполнения (другими словами, использовать для этого внешние инструменты) и полагаться на внешние, специфичные для времени выполнения конфигурации, а не модифицировать или создавать уникальные контейнеры для каждой среды.
После любых изменений в приложении образ контейнера необходимо пересобрать и развернуть во всех используемых средах.
Кстати, при управлении ИТ-системами используется аналогичный принцип, известный как принцип неизменяемости серверов и инфраструктуры.
Цель IIP — предотвратить создание отдельных образов контейнеров для разных сред выполнения и везде использовать один и тот же образ вместе с соответствующей конфигурацией для конкретной среды.
Следование этому принципу позволяет реализовать такие важные с точки зрения автоматизации облачных систем практики, как откат и накат обновлений приложений.
Принцип одноразовости процесса (PDP)
Одной из наиболее важных характеристик контейнера является его эфемерность: экземпляр контейнера легко создать и легко уничтожить, поэтому его можно легко заменить другим экземпляром в любое время.Причин такой замены может быть много: сбой проверки работоспособности, масштабирование приложения, перенос на другой хост, исчерпание ресурсов платформы и другие ситуации.
Как следствие, контейнерные приложения должны поддерживать свое состояние с помощью каких-то внешних средств или использовать для этого внутренние распределенные схемы с избыточностью.
Кроме того, приложение должно быстро запускаться и быстро завершать работу, а также быть готовым к внезапному фатальному сбою оборудования.
Одна из практик, которая помогает реализовать этот принцип, — сохранять контейнеры небольшими.
Облачные среды могут автоматически выбирать хост для запуска экземпляра контейнера, поэтому чем меньше контейнер, тем быстрее он запустится — он просто быстрее скопируется на целевой хост по сети.
Принцип самоподдержания (S-CP)
По этому принципу на этапе сборки в контейнер помещаются все необходимые компоненты.Контейнер следует строить исходя из того, что в системе имеется только чистое ядро Linux, поэтому все необходимые дополнительные библиотеки следует размещать в самом контейнере.
Он также должен содержать такие вещи, как среда выполнения для соответствующего языка программирования, платформа приложения (при необходимости) и другие зависимости, которые потребуются во время работы приложения-контейнера.
Исключения составляются для конфигураций, которые различаются от среды к среде и должны предоставляться во время выполнения, например, через Kubernetes ConfigMap.
Приложение может включать в себя несколько контейнерных компонентов, например отдельный контейнер СУБД внутри контейнерного веб-приложения.
По принципу S-CP эти контейнеры не должны объединяться в один, а должны быть сделаны так, чтобы контейнер СУБД содержал все необходимое для работы базы данных, а контейнер веб-приложения содержал все необходимое для работы веба.
приложение, тот же веб-сервер.
В результате во время выполнения контейнер веб-приложения будет зависеть от контейнера СУБД и обращаться к нему по мере необходимости.
Принцип ограничения времени выполнения (RCP)
Принцип S-CP определяет, как должен быть построен контейнер и что должен содержать двоичный файл образа.Но контейнер — это не просто «черный ящик», имеющий только одну характеристику — размер файла.
Во время выполнения контейнер принимает другие измерения: объем используемой памяти, время процессора и другие системные ресурсы.
И здесь на помощь приходит принцип RCP, согласно которому контейнер должен обезглавить свои требования к системным ресурсам и передать их платформе.
Благодаря профилям ресурсов каждого контейнера (сколько ресурсов ЦП, памяти, сети и дисков ему требуется) платформа может оптимально выполнять планирование и автоматическое масштабирование, управлять ИТ-мощностью и поддерживать уровни SLA для контейнеров.
Помимо удовлетворения требований контейнера к ресурсам, приложению также важно не выходить за собственные границы.
В противном случае при возникновении нехватки ресурсов платформа с большей вероятностью включит его в список приложений, которые необходимо закрыть или перенести.
Когда мы говорим о приоритете облака, мы говорим о том, как мы работаем.
Выше мы сформулировали ряд общих принципов, которые задают методологическую основу построения качественных контейнерных приложений для облачных сред. Обратите внимание, что помимо этих общих принципов вам также потребуются дополнительные продвинутые методы и приемы работы с контейнерами.
Кроме того, у нас есть несколько коротких рекомендаций, которые более конкретны и их следует применять (или не применять) в зависимости от ситуации:
- Постарайтесь уменьшить размер образов: удалите временные файлы и не устанавливайте ненужные пакеты — чем меньше размер контейнера, тем быстрее он собирается и копируется на целевой хост по сети.
- Сосредоточьтесь на произвольных идентификаторах пользователей: не используйте команду sudo или какой-либо специальный идентификатор пользователя для запуска контейнеров.
- Отмечайте важные порты: вы можете устанавливать номера портов во время выполнения, но лучше указывать их с помощью команды EXPOSE — это облегчит использование ваших изображений другими людьми и программами.
- Храните постоянные данные на томах.
Данные, которые должны остаться после уничтожения контейнера, должны быть записаны на тома.
- Записывайте метаданные изображения: теги, метки и аннотации упрощают использование изображений — другие разработчики будут вам благодарны.
- Синхронизация хоста и изображений.
Некоторые контейнерные приложения требуют, чтобы контейнер синхронизировался с хостом по определенным атрибутам, таким как время или идентификатор компьютера.
- В заключение мы поделимся шаблонами и лучшими практиками, которые помогут вам более эффективно реализовать перечисленные выше принципы: www.slideshare.net/luebken/container-patterns docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices docs.projectatomic.io/container-best-practices docs.openshift.com/enterprise/3.0/creating_images/guidelines.html www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf Leanpub.com/k8spatterns 12фактор.
нет
- Неизменяемый Red Hat Enterprise Linux CoreOS
- Сервисная сетка OpenShift
- Структура оператора
- Родной фреймворк
-
С Новым Кодексом!
19 Oct, 24 -
Что Такое Сетка Данных В Памяти
19 Oct, 24
