Хотя есть много способов воздействия и влияния на ваше приложение для некой контейнерной архитектуры, пространство пользователя предоставляет инструменты, про которые часто забывают:
- языковая исполняющая среда;
- инструменты для отладки и управления.
Контейнеры приложений против контейнеров с суперпривилегиями
Сначала давайте определим два основных типа рабочей нагрузки – контейнеры приложений и контейнеры с суперпривилегиями (SPC). Для каждого из них требуется более или менее детерминированная связь с базовым хостом контейнера, а также безопасный доступ к нему.
Контейнеры можно рассматривать как процессы, которые выполняются в собственном пользовательском пространстве с дополнительной изоляцией. Многие не осознают, что большую часть этой изоляции можно удалить для выполнения различных задач системного администрирования.
Контейнеры – это действительно просто процессы, которые монтируют отдельный образ диска, включенный пространствами имен ядра. Контейнеры служб обычно работают с SELinux и включенными CGroups, в то время как суперпривилегированные контейнеры часто работают без этих ограничений.
Разработчики и системные администраторы сталкиваются с разными проблемами
У контейнеров приложений и супер привилегированных контейнеров разные предназначения и для их разработки требуется различный подход, но хватит лирики… как это влияет на ваше приложение?
Это влияет на принятия решений о том, как создавать, отлаживать, управлять и развертывать ваше приложение в разных средах – от рабочего ноутбука до промышленного сервера. Выбор и стандартизация единого пользовательского пространства контейнера (цепочки инструментов) в разных средах позволит программистам, системным администраторам и архитекторам упростить взаимодействие между разработкой и эксплуатацией, ускоряя развертывание. Развитие навыков работы с одним общим стеком инструментов облегчает общение (между разработчиками и командой эксплуатации), обучение и устранение неполадок (если что-то пойдет не так).
Контейнеры приложений
Пока разработчики и архитекторы приложений больше думают о том, какие языковые среды выполнения им доступны, системные администраторы больше озабочены безопасностью и сроками поддержки платформы.
Разработчики озадачены развертыванием своего кода и данных. Пользователей интересует доступ к этим приложениям
Помните, что когда создаются контейнеры приложений, они – все еще процессы с добавленной в ядро дополнительной изоляцией. Это означает, что к ним применяется большинство обычных правил. Их все еще нужно патчить, улучшать и управлять ими после запуска.
Упакованная в образ контейнера с реда выполнения приложения и его зависимостей упрощает совместное использование кода. Когда все приложение и все его зависимости упакованы в образ контейнера, ускоряется процесс совместной работы, начиная от разработки микросервисов внутри компании, до проверки домашнего проекта потенциального разработчика, с которым вы проводите собеседование.
Среда разработки и серверы
Кроме того, последние версии сертифицированных Red Hat образов контейнеров сторонних производителей доступны через Red Hat Federated Registry. Разработчики, системные администраторы и архитекторы могут использовать эти образы от независимых поставщиков программного обеспечения (ISV) для упрощения разработки, развертывания и эксплуатации готовых решений – все они сертифицированы для использования с экосистемой контейнерных хостов и платформ Red Hat.
Red Hat предоставляет разработчикам доступ к новым языковым средам и серверам через Red Hat Software Collections и сертифицированные приложения ISV. Для системных администраторов есть доступ к инструментам с помощью контейнера rhel-tools. Все они распространяются либо через Red Hat Container Registry, либо через Red Hat Federated Registry.
Интроспекция
Хотите понять из чего собран образ? В этом нам частично помогут метаданные:
Так как образы Docker строятся в виде слоев, мы можем определить, что изменилось между этим слоем и лежащим под ним. Обратите внимание, что последний слой образа был обновлен неделю назад.
Мы даже можем определить, какие именно файлы изменялись между образом и запущенным контейнером. Это особенно полезно при переносе устаревших приложений в контейнеры. Выполняющий миграцию инженер может определить, где приложение вносит изменения в пользовательское пространство. Это позволит ему легче разделить логи, данные, файлы конфигурации и код – и разместить компоненты на правильном устройстве хранения (например, на внешнем по отношению к контейнеру хранилище).
На самом деле мы лишь поверхностно изучаем ценность интроспекции. Представьте насколько удобным может оказаться этот инструментарий при выполнении миграций через несколько лет после того, как создавшие проект разработчик покинет его.
Упрощенное развертывание приложений
В то время как перенос приложения в контейнер обычно выполняется как отдельный проект (один раз), запуск приложений – происходит довольно часто. Команда atomic run позволяет разработчикам встроить сложную логику запуска в метаданные образа контейнера, чтобы ее не нужно было указывать каждый раз при запуске контейнера. Используя метку RUN , запуск можно упростить до:
atomic run ntpd
docker run -d -n ntpd –cap_add SYS_TIME ntp
При этом логика аккуратно сохраняется в Dockerfile , который можно контролировать по версиям:
Жизненный цикл
Большинство дистрибутивов Linux позволяют важным частям программного обеспечения получать обновления основных версий. Например, Fedora старается обновлять ядро как можно быстрее (rebasing). Fedora стремится к инновациям, что замечательно, но иногда это может привести к поломкам. Red Hat Enterprise Linux использует методику обратного переноса (вместо rebasing) патчей к определенным версиям библиотек и двоичных файлов в пользовательском пространстве. Например, версия веб-сервера Apache в Red Hat Enterprise Linux 7 по-прежнему 2.4.6, но команда разработчиков будет тщательно следить за ним для обеспечения безопасности и исправления ошибок. Это дает администраторам уверенность в том, что образы контейнеров будут работоспособны в течение многих лет. В этом случае конфигурационные файлы и другое зависящее от Apache ПО будут продолжать работать даже после обновления образа контейнера для применения обновлений безопасности и исправления ошибок.
Простая строка FROM в вашем Dockerfile отразится на том, сколько сил ваши разработчики и администраторы потратят при обновлении и модернизации в течение жизненного цикла приложения. Более того, поскольку эти контейнеры будут работать на различном оборудовании – от ноутбуков программистов до производственных серверов, поддержка и жизненный цикл являются ключевыми факторами при принятии решения о том, какой дистрибутив использовать в образе контейнера.
Контейнеры с супер привилегиями (SPC)
При использовании суперпривилегированных контейнеров важность отношений между пользовательским пространством и ядром становится очевидной. SPC выполняются с привилегиями, аналогичными обычному процессу, принадлежащему и выполняемому пользователем root. Инструментарий внутри SPC часто напрямую взаимодействует со структурами данных ядра и файловой системой хоста – такими как стек TCP, список процессов, список пользователей и т.д. Контейнер RHEL Tools делает многие из этих операций довольно простыми.
Системные администраторы занимаются управлением, обслуживанием, устранением неполадок и сканированием контейнеров.
SPC также показывают насколько легко развернуть системное ПО и утилиты, особенно если они нужны администратору лишь временно для устранения неполадок. После того, как администратор закончит работу, утилиты можно легко и просто удалить. Чтобы сделать эту операцию безболезненной, компания Red Hat создала специальный контейнер инструментов под названием Atomic Tools Container. Мы продемонстрируем его использование в некоторых из следующих разделов.
А сейчас рассмотрим некоторые дополнительные случаи использования SPC.
Отладка контейнеров и контейнерных хостов
Для начала администратор может войти по ssh на хост контейнера и запустить набор утилит… как обычно. Более удобный способ – запустить эти утилиты из суперпривилегированного контейнера, что позволяет легко удалить их впоследствии и не загрязнять контейнерный хост кучей программ, файлов и конфигураций.
Отслеживание системных вызовов
Очень полезно просматривать, какими системными вызовами приложение обращается к ядру, но как это сделать, если приложение находится в контейнере? Процесс почти идентичен подходу, который используется и вне контейнера: сначала мы вызываем список процессов, затем подключаемся к нему с помощью команды strace. Основное отличие заключается в том, что мы должны разрешить контейнеру видеть таблицу процессов ядра хоста:
Примеры команд (выше) сложно запомнить, в них используется много дополнительных ключей, поэтому вы можете использовать команду atomic, чтобы упростить ее до следующей:
Сканирование сетей
Другой распространенный сценарий – сканирование сети. Как мы можем перехватить исходящие из контейнера пакеты? Как обычно, обратившись к TCP-стеку ядра.
Сначала узнайте IP-адрес контейнера:
Теперь просканируем траффик, но используя SPC:
SystemTap
Служба поддержки Red Hat уже решила эту проблему – с помощью этой статьи в базе знаний Red Hat можно легко запустить SystemTap в контейнере. После того, как у вас будет создан образ контейнера с stap и отладочными символами для установленного ядра, запустить SystemTap не составит труда, поскольку теперь ваше пространство пользователя и ядро работают вместе:
stap -e ‘probe kernel.function(“generic_make_request”) < print_backtrace() >‘
Еще можно измерить скорость системных вызовов в ядре с помощью скрипта syscalltimes, изменив команду stap на:
docker run –privileged -v /lib/modules:/lib/modules –tty=true –interactive=true stap stap $P_VERBOSE_STR -w “$P_PROCESS_STR” -e ‘
Затем скрипт выполняется как обычно, но весь код запускается из суперпривилегированного контейнера:
Сбор данных из контейнеров
В контейнер RHEL Atomic Tools было вложено много труда, чтобы разработать такие инструменты, как kdump, abrt, sosreport, инструменты для анализа файлов ядра и т.д.
Сканирование или управление контейнерами и контейнерными хостами
Для проверки вашего хоста или контейнера можно запустить Docker CIS Benchmark. Также команда запуска значительно упрощена с помощью метки atomic RUN :
atomic run fatherlinux/docker-bench-security
Подробнее про сканирование контейнеров можно прочитать в этой статье(англ).
Заключение
Чтобы проще понять разницу между контейнерами приложений и SPC, стоит посмотреть на них со стороны рабочей нагрузки. Контейнеры приложений поддерживают бизнес-логику, а супер привилегированные контейнеры (SPC) – приложения и инфраструктуру.
Когда операционная система разделяется на ядро (контейнерный хост) и пространство пользователя (образ контейнера), многие из тех же функций поддержки должны быть продуманы по-другому, но объем работы в целом почти не меняется.