Прошлая неделя подарила два «вкусных» релиза из Open Source-мира контейнеров: практически одновременно обновились Docker (версия 17.06) и Kubernetes (версия 1.7). Какие возможности они принесли? В статье представлена информация из анонсов и release notes этих релизов с небольшими уточнениями по некоторым из ключевых изменений.
Docker CE 17.06
28 июня был анонсирован Docker CE (Community Edition) 17.06 — первый выпуск контейнерной системы, собранный с помощью проекта Moby, анонсированного в апреле. Подробнее о Moby мы уже писали.
Сборка в несколько этапов
Главной фичей релиза стала официальная стабилизация поддержки многоэтапных сборок (multi-stage builds), впервые представленных в Docker 17.05.0. Её суть заключается в возможности описывать в одном
Dockerfile
несколько этапов сборки образа для того, чтобы в конечный образ не попадали промежуточные данные, которые не требуются. Очевидный пример, который приводят в Docker: Java-разработчики обычно используют Apache Maven для компиляции своих приложений, однако Maven не нужен в конечном контейнере (образе) для запуска этих приложений. Теперь можно оформить Dockerfile
таким образом, что сам Maven будет использоваться в промежуточном образе (для сборки), но не попадёт в конечный (для запуска).Вот вариант
Dockerfile
для простого приложения на Java Spring Boot:FROM node:latest AS storefront
WORKDIR /usr/src/atsea/app/react-app
COPY react-app/package.json .
RUN npm install
COPY . /usr/src/atsea/app
RUN npm run build
FROM maven:latest AS appserver
WORKDIR /usr/src/atsea
COPY pom.xml .
RUN mvn -B -f pom.xml -s /usr/share/maven/ref/settings-docker.xml dependency:resolve
COPY . .
RUN mvn -B -s /usr/share/maven/ref/settings-docker.xml package -DskipTests
FROM java:8-jdk-alpine
WORKDIR /static
COPY --from=storefront /usr/src/atsea/app/react-app/build/ .
WORKDIR /app
COPY --from=appserver /usr/src/atsea/target/AtSea-0.0.1-SNAPSHOT.jar .
ENTRYPOINT ["java", "-jar", "/app/AtSea-0.0.1-SNAPSHOT.jar"]
CMD ["--spring.profiles.active=postgres"]
Как видно, две подготовительные стадии здесь используют Node.js и Apache Maven для сборки приложения, однако результирующий образ будем компактным, не имея в своём составе ни Node.js, ни Maven.
Примечание: До настоящего времени у себя в компании мы для этих целей использовали фичу под названием артефакты в собственной Open Source-утилите dapp (её обзор см. здесь).
Логи и метрики
Метрики Docker теперь могут использоваться в плагинах. Для демонстрации приводится пример плагина, который проксирует запросы на метрику, доступную в нём:
$ docker plugin install --grant-all-permissions cpuguy83/docker-metrics-plugin-test:latest
$ curl http://127.0.0.1:19393/metrics
Но это лишь демонстрация, а реальное предназначение этого новшества — отправлять с помощью плагинов собранные метрики в какой-либо внешний сервис или делать их доступными для сборки другим сервисом (например, Prometheus).
Плагины теперь также могут использоваться и для логов (т.е. для реализации logging drivers), а вывод списка всех драйверов журналирования добавлен в
docker info
. Кроме того, реализацию docker service logs
, которая (тоже с прошлого релиза, 17.05) может показывать и логи индивидуальных заданий (/task/{id}/logs
в REST), перенесли из ветки Edge в Stable, поэтому теперь легко получить обобщённые логи для всего сервиса, запущенного в Swarm.Сеть
Стала возможной привязка сервисов к сетям внутри узла (node-local): Host, Macvlan, IPVlan, Bridge, local-scope. Приводимый для Macvlan пример — это создание специфичных для узла сетевых конфигураций на рабочих узлах и сети на управляющем узле, которая будет их применять:
[Wrk-node1]$ docker network create --config-only --subnet=10.1.0.0/16 local-config
[Wrk-node2]$ docker network create --config-only --subnet=10.2.0.0/16 local-config
[Mgr-node2]$ docker network create --scope=swarm --config-from=local-config -d macvlan
mynet
[Mgr-node2]$ docker service create --network=mynet my_new_service
В рамках этого же изменения была добавлена цепочка
DOCKER-USER
в iptables, которая вставляется первой в FORWARD
и не сбрасывается (за это дополнение — благодарность ertaquo!).Кроме того, во внутренние алгоритмы Service Discovery привнесены изменения, которые призваны улучшить логику её работы.
Swarm
Ряд новшеств получил режим Swarm, а в частности:
- объекты конфигурации (Configuration Objects), позволяющие безопасно передавать информацию о конфигурации по аналогии с тем, как это делалось для секретов:
$ echo "This is a config" | docker config create test_config - $ docker service create --name=my-srv --config=test_config … $ docker exec -it 37d7cfdff6d5 cat test_config This is a config
- функция ротации CA-сертификатов в системе public key infrastructure (PKI), применяемой для безопасного деплоя системы оркестровки контейнеров (
docker swarm ca --rotate
); - поддержка событий (ранее были доступны вне Swarm) для получения в реальном времени данных о сервисах, узлах, сетях, секретах;
- новый флаг
--datapath-addr
дляdocker swarm init
, указывающий сетевой интерфейс для изоляции заданий управления (control traffic) от данных приложений (data traffic) — полезно в случае приложений, производящих большую нагрузку на ввод/вывод; - возможность указывать место хранения секрета в контейнере (вместо традиционного
/var/run
).
Более подробный лог изменений в Docker 17.06 вместе с ссылками на коммиты можно найти в Docker CE release notes. А для любителей смотреть и слушать есть 8-минутное видео с рассказом и демонстрацией основных новшеств.
Kubernetes 1.7
29 июня был анонсирован Kubernetes 1.7, главными нововведениями которого названы улучшения в безопасности, поддержке stateful-приложений, расширяемости платформы. Что за этим стоит?
Безопасность
- Объявлен стабильным Network Policy API, позволяющий настраивать правила, определяющие (и ограничивающие) взаимодействие между подами.
- Node authorizer, позволяющий ограничивать API-запросы kubelet (к секретам, подам и другим объектам узла).
- Альфа-версия шифрования секретов и других ресурсов, хранимых в etcd.
- В kubelet TLS bootstrapping добавлена поддержка ротации сертификата клиента и сервера.
- Логи Audit, хранимые сервером API, стали более настраиваемыми и расширяемыми с поддержкой фильтрации событий и webbooks, а также стали предоставлять больше данных для аудита системы.
Поддержка stateful-приложений
- Бета-версия функции автоматических обновлений
StatefulSet
, используемых для деплоя stateful-приложений. Стратегия обновлений определяется полемspec.updateStrategy
, поддерживающим сейчас два значения:OnDelete
иRollingUpdate
. - Поддержка в
StatefulSets
более быстрого масштабирования и запуска приложений, не требующих строгой очередности, настраиваемой теперь через Pod Management Policy. Такие приложения теперь могут запускаться параллельно и без ожидания получения подом определённых статусов (Running, Ready). - Альфа-версия локального хранилища (Local Storage): в
StorageClasses
внутриStatefulSets
теперь можно получить доступ к локальному хранилищу через стандартный интерфейс PVC/PV. - Умный откат (и история изменений) при обновлениях
DaemonSets
. - Новый плагин StorageOS Volume, реализующий постоянные томы хранения высокой доступности во всём кластере (из локального или подключённого к узлу хранилища).
Расширяемость
- Агрегация API позволяет расширять возможности Kubernetes собственными API. Прослойка агрегации работает вместе с kube-apiserver и ничего не делает, пока не зарегистрирован ни один ресурс для расширения API. Регистрация API выполняется через объект
APIService
, который реализуется черезextension-apiserver
внутри пода, работающего в кластере Kubernetes. - В Container Runtime Interface (CRI) добавлены новые RPC-вызовы для получения метрик контейнера. Добавлена альфа-версия интеграции с containerd, поддерживающая базовый жизненный цикл пода и управления образами.
Другое
- Альфа-версия поддержки внешних контроллеров Dynamic Admission, позволяющих добавлять API-серверу бизнес-логику при модификации объектов.
- Альфа-версия Policy-based Federated Resource Placement, что позволяет определять основанные на политиках решения по федеративным ресурсам (с использованием внешнего движка политик, например, основываясь на требованиях к цене или производительности).
- На смену Third Party Resource (TPR) пришли Custom Resource Definitions (CRD), которые предлагают «более ясный API» и решают ряд проблем, зафиксированных во время бета-тестирования TPR. Полностью TPR будут убраны в Kubernetes 1.8 (доступно руководство по миграции).