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

Комментарии (9)


  1. o_serega
    03.07.2017 09:22
    +1

    Альфа-версия шифрования секретов и других ресурсов, хранимых в etcd.


    Неужели)


  1. Caravus
    03.07.2017 11:11
    +2

    Главной фичей релиза стала поддержка многоэтапных сборок (multi-stage builds)
    multi-stage build support появилась в v17.05.0-ce


    1. shurup
      03.07.2017 11:16
      +1

      Спасибо, исправил в тексте на: «Главной фичей релиза стала официальная стабилизация поддержки многоэтапных сборок (multi-stage builds), впервые представленных в Docker 17.05.0».


      1. Caravus
        03.07.2017 11:21

        Судя по ишью на гитхабе — ничего стабильного там не добавилось :)


        1. shurup
          03.07.2017 11:22

          Ну, по крайней мере, добавилась уверенность разработчиков, что всем можно это использовать ;-)


  1. ertaquo
    03.07.2017 14:34
    +1

    В Docker добавили цепочку DOCKER-USER в iptables, которая вставляется первой в FORWARD и не сбрасывается.
    Т. е. теперь можно закрыть доступ к опубликованному через Docker порту для конкретного интерфейса/IP, или наоборот.


    1. shurup
      03.07.2017 14:47

      Спасибо. Читал об этом в комментариях opennet'а, но не увидел конкретной записи в release notes, поэтому написать забыл. Если правильно всё понял, было частью node-local в Swarm (#32981 в Moby) (#1675 в libnetwork).


  1. ALexhha
    03.07.2017 15:30

    Я вот кстати не понял, почему они в примере с multi-stage build в финальном образе используют java:8-jdk-alpine, а не java:8-jre-alpine, вроде для запуска jar достаточно обычного jre. Ведь они описывают эту фичу как возможность максимально минимизировать финальный образ.


    1. Caravus
      03.07.2017 17:11
      +3

      Вполне возможно что пример писал вообще человек без навыков java :) А golang постеснялись — итак везде он…