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

Один из самых популярных поставщиков контейнерных технологий Docker регистрирует в феврале 2022 года рекордную цифру 15+ миллионов активных пользователей в месяц .

Успех Docker свидетельствует о влиянии контейнерных технологий на весь ИТ-ландшафт.

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

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

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

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

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

Образы контейнеров

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

Формат файла для указания образа контейнера в экосистеме Docker называется Dockerfile. Мы можем создать Dockerfile с помощью нашего редактора кода и превратить его в образ контейнера с помощью команды docker build.

Вот пример Dockerfile из сообщества NodeJS

ОТ узла:16

Создать каталог приложения

РАБОЧИЙ КАТАЛОГ /usr/src/app

Установить зависимости приложения

Подстановочный знак используется, чтобы убедиться, что package.json

И package-lock.json копируются

где доступно (npm@5+)

КОПИРОВАТЬ пакет*.json ./

ЗАПУСТИТЬ установку npm

Если вы создаете свой код для производства

ЗАПУСК npm ci --only=production

Объединяем исходный код приложения

КОПИРОВАТЬ . .

ВЫСТАВИТЬ 8080

CMD [ "узел", "server.js" ]

Вы можете видеть, что приведенный выше файл Dockerfile выполняет команды с директивой RUN почти так же, как вы делаете это в терминале вашей системы UNIX. Но файлы Dockerfile также предлагают специфичные для контейнера объявления, такие как COPY и EXPOSE, которые мы используем для ввода данных в процесс контейнера или для привязки порта.

Каждый образ контейнера ссылается на «базовый образ». Это делается с помощью оператора FROM. Приведенный выше пример ссылается на официальный образ NodeJS Docker. Использование образа Docker NodeJS в качестве базового образа гарантирует, что у нас уже есть контейнер Linux с предустановленными зависимостями NodeJS, такими как npm и node.

Но вместо этого мы могли бы выбрать любой другой образ Docker из официального реестра Docker Hub.

Концепция повторного использования существующих образов контейнеров путем ссылки на базовые образы называется многоуровневым образом. Образы контейнеров могут состоять из нескольких слоев. Приведенный выше пример Dockerfile основан на слое образа NodeJS, который основан на слое образа Ubuntu.

Реестры контейнеров

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

Реестры контейнеров помогают нам распространять образы контейнеров. Реестр — это база данных для образов контейнеров, которую мы можем использовать через Rest API или клиент. Одним из самых популярных реестров контейнеров является Docker Hub Registry. Это место, где многие сообщества с открытым исходным кодом загружают свои официальные образы контейнеров.

В примере Dockerfile из последнего раздела используется официальный образ Docker Hub для NodeJS. Интерфейс командной строки (CLI) docker по умолчанию выполняет поиск в реестре контейнеров Docker Hub, если требуемый образ контейнера не может быть найден в хост-системе.

Загрузка образа контейнера из реестра называется «вытягиванием» или «вытягиванием».

Вы также можете разместить реестр контейнеров самостоятельно. Nexus и Artifactory — два распространенных приложения, предоставляющих реестры контейнеров. Большинство облачных провайдеров, таких как Amazon Web Service, Microsoft Azure или Google Cloud Platform, предлагают пользователям управляемые реестры контейнеров.

Как вы можете использовать другой контейнерный реестр с вашим Docker CLI, описано [здесь] (https://www.docker.com/blog/how-to-use-your-own-registry-2/)

Контейнерная оркестровка

Оперировать производственными системами со многими приложениями-контейнерами сложно. Контейнерные оркестраторы, такие как Kubernetes, Docker Swarm и Docker Compose, существуют для упрощения развертывания и обслуживания контейнерных производственных систем.

Контейнерные оркестраторы сильно различаются по сложности и функциям. Но Docker Compose — хороший инструмент для начала работы с Docker. Он в основном используется для целей локальной разработки или развертывания производственных систем на одной виртуальной машине или компьютере.

Другие оркестраторы, такие как Kubernetes, более сложны в использовании, но позволяют развертывать контейнерные приложения в инфраструктуре с несколькими виртуальными машинами.

Инициатива открытых контейнеров

Инициатива Open Container Initiative (OCI) обеспечивает стандарт для наиболее важных компонентов контейнерных технологий. Частью этих стандартов являются, например, формат образа контейнера и API среды выполнения контейнера.

Среды выполнения контейнеров, такие как containerd, CRI-O, Docker и Mirantis, реализуют этот стандарт среды выполнения контейнеров OCI. Это важно, потому что оркестраторы контейнеров, такие как Kubernetes, позволяют настраивать среду выполнения контейнеров. Вы используете любую среду выполнения контейнера, соответствующую стандарту OCI, в своем кластере Kubernetes.

Причины использования контейнерных технологий

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

Вот 10 причин, по которым вам следует использовать контейнерные технологии.

1. Эффективность использования ресурсов

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

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

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

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

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

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

2. Изоляция

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

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

С другой стороны, контейнерные процессы предлагают более высокую степень изоляции по сравнению с другими. Контейнерный процесс запускается системным вызовом Unix clone, в отличие от системного вызова exec, используемого для большинства других процессов Unix.

Системный вызов «clone» порождает процесс UNIX, подобный системному вызову «exec» или «fork». Но у «клона» есть несколько важных возможностей:

• clone может размещать дочерние процессы в разных пространствах имен UNIX.

• clone может помещать дочерние процессы в другое виртуальное адресное пространство.

• clone может изменить таблицу файловых дескрипторов дочернего процесса.

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

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

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

3. Автоматическая настройка

Образы контейнеров предоставляют декларативный синтаксис, который можно использовать для описания контейнера. Среды выполнения контейнеров используют образы контейнеров для запуска процессов контейнеров в операционной системе хоста.

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

Это важное качество Container Technologies. Это делает развертывание программного обеспечения более предсказуемым, а ошибки в программных системах — более понятными. Разработчики программного обеспечения могут легче воспроизводить ошибки, возникающие в производственных системах, если базовое приложение работает в контейнере. Разработчики могут использовать образ контейнера для запуска приложения в той же среде выполнения на своем локальном компьютере для устранения неполадок.

4. Повторное использование

Экосистема образов контейнеров работает как луковица. Образы контейнеров состоят из нескольких слоев, которые переплетаются друг с другом наподобие луковицы.

Повторное использование, а не переписывание образов контейнеров упрощает указание контейнера. Разработчик NodeJS может использовать официальный образ NodeJS Docker Hub для контейнеризации своего приложения. Нет необходимости указывать процедуры установки для интерпретатора NodeJS или диспетчера пакетов NPM. Этот шаг уже охвачен базовым образом контейнера NodeJS.

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

Дополнительное программное обеспечение, такое как Chef или Ansible, может автоматизировать этот процесс, но администраторы должны настраивать и поддерживать рабочие процессы автоматизации.

5. Гибкость

Контейнер Docker можно развернуть в любой операционной системе с установленным Docker Engine. Docker поддерживает широкий спектр операционных систем от Windows, MacOS до большинства дистрибутивов Linux.

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

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

6. Воспроизводимость

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

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

7. Совместимость

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

Изменения в программном приложении редко требуют изменения образа контейнера. Это упрощает разделение ролей разработчика и оператора в софтверной компании.

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

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

8. Компонуемость

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

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

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

Оркестраторы контейнеров, такие как Kubernetes, могут помочь запланировать и развернуть контейнерные микросервисы на нескольких виртуальных машинах.

9. Масштабируемость

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

Скорость развертывания является важным показателем в хостинге программного обеспечения. Это сокращает время простоя сервисов во время обновлений и упрощает масштабирование.

С другой стороны, создание новой виртуальной машины в автоматизированной инфраструктуре (IaaS), такой как AWS, занимает минуты. Запрос на виртуальную машину большего размера в той же инфраструктуре для удовлетворения растущих потребностей приложения в ресурсах будет стоить вам еще пару минут.

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

10. Менее снисходительный

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

Многие пользователи Linux устанавливают программное обеспечение и зависимости через менеджер пакетов, такой как aptitude, с правами суперпользователя. Это можно сделать с помощью команды sudo, которая запускает команду терминала с привилегиями суперпользователя.

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

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

Резюме

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

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

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

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

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

И это 10 причин, по которым вам следует использовать контейнерные технологии.

Я рекомендую вам ознакомиться с отличной [документацией по Docker] (https://docs.docker.com), если вы хотите начать работу с контейнерными технологиями прямо сейчас.

Впервые опубликовано здесь