Облачные приложения и Kubernetes: контейнеры

Cloud Server | Amber | Комментировать запись

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

Читайте также:

• Облачные приложения и Kubernetes: основы и тренды
• Облачные приложения и Kubernetes: основы Cloud Native
• Облачные приложения и Kubernetes: микросервисы

Что такое контейнеры?

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

Контейнеры vs. виртуальные машины

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

Среда выполнения контейнера

Сегодня доступно несколько контейнерных сред выполнения, однако Docker является наиболее зрелым, широко поддерживаемым и распространенным форматом, встроенным в большинство систем оркестровки контейнеров. Совсем недавно проект Linux Foundation под названием Open Container Initiative (OCI) начал работу над стандартизацией форматов и сред выполнения контейнеров, что привело к разработке и интеграции облегченных и стабильных сред, совместимых с OCI, таких как containerd. В середине 2018 года проект Kubernetes объявил о доступности для среды выполнения containerd, включив ее в версии Kubernetes 1.10 и выше.

Сборка и доставка: контейнеризация приложения

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

DOCKERFILE
FROM      node: 10.2.1
...
copy      package.json ./
run       npm install
expose    8080
cmd       [”npm”, “start”] ...

Затем разработчики или серверы сборки используют среду выполнения контейнера Docker для встраивания этих зависимостей, библиотек и исходников приложений в двоичный пакет – в образ Docker. Образы Docker состоят из упорядоченных уровней, они компонуемые и могут быть использованы в качестве основы для новых образов. После создания эти образы можно использовать для запуска контейнеров на любом хосте с рабочей средой Docker. Контейнеры играют центральную роль в работе переносимых приложений Cloud Native, поскольку их использование естественным образом ведет к реализации нескольких основных принципов «12 факторов» и Cloud Native. При необходимости данный контейнер Docker:

• Реализует узкую часть логики;
• Явно объявляет все свои программные зависимости в Dockerfile;
• Может обладать высокой портируемостью между облачными провайдерами, если у них есть необходимые ресурсы и среда выполнения Docker;
• Может быстро развертываться для замены вышедшего из строя контейнера того же типа;
• Быстро реплицируется для обработки дополнительной нагрузки функции с высоким спросом (за счет запуска дополнительных экземпляров контейнера).

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

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

На этом этапе в игру вступает Kubernetes и оркестровка.

Создание микросервиса Snappy: жизненный цикл контейнера Web UI

Чтобы продемонстрировать один из возможных процессов разработки приложения на основе контейнеров, мы увеличим микросервис Snappy Web UI, веб-сервер Express и Node.js.

Разработка и загрузка

Поскольку это приложение Express зависит от запуска Node.js и связанных с ним библиотек, Dockerfile snappy_web сначала получает образ Node.js из реестра Docker, например из Docker Hub. Дальнейшие шаги Dockerfile включают в себя настройку приложения, копирование исходного кода и, наконец, определение команды, которую нужно выполнить при запуске контейнера приложения.

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

Сборка и тестирование

Появление нового кода запускает конвейер непрерывной интеграции. Сервер непрерывной интеграции встраивает зависимости Node.js, библиотеки и измененные исходники в образ Docker. После сборки конвейер запускает этот образ как контейнер и приступает к выполнению модульных и интеграционных тестов. Если все тесты пройдены, этот проверенный образ Docker затем помещается в реестр образов контейнера – уровень абстракции, обычно создаваемый поверх хранилища объектов – для тегирования образов контейнера, организации и эффективного повторного использования существующих уровней образа. Частные реестры образов контейнеров позволяют группам обмениваться образами и централизованно публиковать их в надежном месте. А общедоступные реестры позволяют популярным проектам с открытым исходным кодом, таким как Node.js, предоставлять разработчикам последние версии своего программного обеспечения в виде предварительно созданного образа контейнера.

Развертывание и запуск

Теперь, когда образ контейнера веб-интерфейса Snappy, содержащий исправление бага, был одобрен и отправлен в реестр, система оркестровки контейнеров, например Kubernetes, может извлечь этот образ и развернуть его на любом хосте со средой выполнения Docker. Этот работающий контейнер имеет узкое представление о доступных ресурсах, указанных разработчиком, и запускается изолированно от других контейнеров. Один хост с установленной средой выполнения может запускать несколько контейнеров одновременно, в зависимости от доступных ресурсов.