Прошлая неделя подарила два «вкусных» релиза из 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 (доступно руководство по миграции).