Представлен (https://blog.docker.com/2017/06/announcing-docker-17-06-comm.../) релиз инструментария для управления изолированными Linux-контейнерами Docker 17.06 (http://www.docker.com/), предоставляющего высокоуровневый API для манипуляции контейнерами на уровне изоляции отдельных приложений. Docker позволяет, не заботясь о формировании начинки контейнера, запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров. Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Код Docker написан на языке Go и распространяется (https://github.com/dotcloud/docker/) под лицензией Apache 2.0.
Docker 17.06 является первым выпуском, который построен на основе проекта Moby (https://www.opennet.ru/opennews/art.shtml?num=46420), реализующего идею построения систем контейнерной изоляции в виде набора связываемых между собой универсальных компонентов. Выпуск также сформирован в рамках новой нумерации версий (год.месяц) и раздельным формированием релизов Community Edition (CE) и Enterprise Edition (EE).
Другие изменения:- Поддержка многоступенчатой сборки (multi-stage), позволяющей формировать более компактные образы Docker, используя единый Dockerfile. Многоступенчатая сборка основана на использовании промежуточных образов, применяемых для сборки компонентов итогового образа. Например, для создания образа с Java-приложением, можно создать промежуточный образ, включающий Apache Maven и прочие инструменты, необходимые для сборки, но не требуемые для выполнения приложения. При таком разделении при размере промежуточного образа в 620 Мб, размер итогового образа составит всего 145 Мб. Число стадий не лимитировано, например, для формирования единого образа программы AtSea используется объединение результатов двух промежуточных стадий - первой на базе node.js для сборки приложения ReactJS и второй на базе Maven для компиляции приложения Spring Boot, при этом финальный образ поставляется без Maven и node.js;
- В команде "docker build" реализован флаг "--build-arg", позволяющий установить переменные для сборки, определённые в файле Dockerfile;
- Метрики со статистикой о работе управляющего демона теперь могут быть не только запрошены через API, но и переданы плагинам и любым внешним сервисам через обработчик "/metrics";
- Добавлена поддержка оформления в виде плагинов драйверов для накопления и обработки логов;
- В разряд стабильный переведена команда "docker service logs", позволяющая упростить отладку сервисов за счёт избавления администратора от ручного сбора логов из отдельных хостов и контейнеров. При выполнении "docker service logs" логи из всех контейнеров, в которых выполняется указанный сервис, будут перенаправлены в текущую консоль;
- Реализована возможность прикрепления сервисов к внутриузловым сетям (node-local), таким как сети с типами Host, Macvlan, IPVlan и Bridge, а также создаваемым через плагины локального действия. Например, для сети Macvlan можно создать специфичные сетевые конфигурации на рабочих узлах и затем создать общую сеть на управляющем узле, которая объединит эти конфигурации;
- Расширены возможности режима Swarm, предоставляющего средства кластеризации для упакованных в контейнеры приложений. Swarm даёт возможность управлять кластером из нескольких хостов Docker по аналогии с работой с одним виртуальным хостом. В Docker 17.06 добавлен новый объект настройки для режима swarm, который позволяет безопасно передавать информацию о настройках. Во встроенной системе PKI (public key infrastructure) добавлена команда "docker swarm ca --rotate" для инициирования принудительной ротации ключей. В режиме swarm реализована возможность обработки событий ("docker events (https://docs.docker.com/engine/reference/commandline/events/)"), позволяющих средствам мониторинга в реальном режиме времени получить информацию о сервисах, узлах и сетях.URL: https://blog.docker.com/2017/06/announcing-docker-17-06-comm.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=46789
Они вроде в этом релизе планировали добавить цепочку DOCKER_USER в iptables. Добавили, нет, кто-нибудь в курсе?
Да, наконец-то завезли. Какое-то время сидел на test только из-за этого. :)
Когда уже решат проблему при релоаде правил iptables и применения docker-правил в него?
Когда оно уже устаканится и там перестанут ломать всё по диагонали?
когда модным будет что-нибудь другое
Тогда, когда наконец введут адекватный способ узнать id контейнера внутри этого себя самого не через cgroups. Там от версии к версии меняли пути в /proc, народу после обновлений приходилось всё чинить, судя по тому, что я видел на stackoverflow.
В этот раз поломали на отличьненькоhttps://github.com/docker/machine/issues/4156
https://github.com/docker/for-linux/issues/11#issuecomment-3...
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/...
чк, чн
> В этот раз поломали на отличьненькожадный неплательщик бабок правильным пацанам - должен страдать (если присмотреться к патчу - поломали только в CE)
if strings.Contains(v1, ceEdition) && !strings.Contains(v2, ceEdition) {
break things and report unrelated trash instead directly showing what's wrong
}зато на go. Тестами, очевидно, CE не покрыт вообще никак. Пипл схавает и так.
>реализующего идею построения систем контейнерной изоляции в виде набора связываемых между собой универсальных компонентов.выглядит как превращение в глючного монстра
Выглядит как неспособность автора новости выразить свою мысль.
Чтобы не уходить в заблуждения про монстра… тут писал подробнее о том, что такое Moby и для чего его ввели, на русском языке: https://habrahabr.ru/company/flant/blog/329136/
> выглядит как превращение в глючного монстрадокер не может превратиться в то, чем изначально и был.
Уже пару недель используем "--build-arg", но жаль нет аналога, который будет работать только на пересобираемые строки Dockerfile. Изменение аргумента влечёт за собой полную пересборку всех слоёв, хотя в рамках задачи требуется пересобрать слои только согласно изменённым строкам.
> В команде "docker build" реализован флаг "--build-arg", позволяющий установить переменные для сборки, определённые в файле Dockerfile;не понял, о чем речь, эта опция есть и в 1.12
# docker -v
Docker version 1.12.6, build 78d1802# docker build --help | grep arg
--build-arg value Set build-time variables (default [])> Изменение аргумента влечёт за собой полную пересборку всех слоёв
нет, не влечет ;)
# docker build --build-arg ARG1=123 .
Sending build context to Docker daemon 8.704 kB
Step 1 : FROM alpine
---> 665ffb03bfae
Step 2 : RUN echo "Add another layer"
---> Using cache
---> 0af0c3c6b816
Step 3 : RUN echo "And another one"
---> Using cache
---> 1478a7423bc0
Step 4 : COPY xvfb-run /tmp
---> Using cache
---> bc1be1f394c9
Step 5 : ARG ARG1
---> Using cache
---> 6627f647b55c
Step 6 : RUN echo "ARG1=${ARG1}"
---> Using cache
---> 622ecbd7b0dc
Successfully built 622ecbd7b0dcМеняем параметр
# docker build --build-arg ARG1=1234567 .
Sending build context to Docker daemon 8.704 kB
Step 1 : FROM alpine
---> 665ffb03bfae
Step 2 : RUN echo "Add another layer"
---> Using cache
---> 0af0c3c6b816
Step 3 : RUN echo "And another one"
---> Using cache
---> 1478a7423bc0
Step 4 : COPY xvfb-run /tmp
---> Using cache
---> bc1be1f394c9
Step 5 : ARG ARG1
---> Using cache
---> 6627f647b55c
Step 6 : RUN echo "ARG1=${ARG1}"
---> Running in 6cefcfd1c15a
ARG1=1234567
---> b076ab7b6bec
Removing intermediate container 6cefcfd1c15a
Successfully built b076ab7b6becи о чудо, первые 4ре слоя не пересобирались
Только что сам проверил, работает. Неожиданно. Недели полторы назад пересобирался целиком образ, что доставляло много неудобств. Не знаю, что поменялось, но это сильно облегчает жизнь. Спасибо за тест.
> Только что сам проверил, работает. Неожиданно. Недели полторы назад пересобирался целиком
> образ, что доставляло много неудобств. Не знаю, что поменялось, но это
> сильно облегчает жизнь. Спасибо за тест.Я думаю вам понятно, что пересобираются все слои, которые идут за соотв ARG параметром. Поэтому местоположение аргумента в докерфайле играет большое значение ;)
В нашем случае большой роли не играет, это просто переменные окружения http{,s}_proxy, необходимые для установки пакетов на рабочем месте. Для остальных случаев используется динамически формируемое название контейнера (архитектура, дистрибутив, версия, ветка). Таким образом, кэш практически никогда не меняется, если только не добавляется новая зависимость.
Поправка, предыдущий тест не достоверен, я забыл выключить прокси, поэтому ничего не пересобиралось. А из-за зависания ОС при выключении пришлось делать грубое выключение и потёрся пропал кэш и проверять долго... Потом перепроверю, но скорее всего я изначально был прав, пересобирается всё, т.к. аргумент интерпретируется как переменная окружения для всех команд. Видимо явное указание аргумента меняет схему. Попробуйте стереть строчку "ARG ARG1" ради интереса.
А почему в новости нет реально полезной фичи - Multi-stage builds? Которая позволяет в одном Dockerfile описать несколько контейнеров, а в финальном использовать только нужные папки/файлы из промежуточных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 buildFROM java:8-jdk-alpine
WORKDIR /static
COPY --from=storefront /usr/src/atsea/app/react-app/build/ .
WORKDIR /appэто очень круто и очень не хватало
В новости ведь написано об этом первым пунктом "других изменений":
> Поддержка многоступенчатой сборки (multi-stage), позволяющей формировать более компактные образы Docker, используя единый Dockerfile.
Почему именно такой чепухи не хватало? Ви таки нишмагли написать несколько докерфайлов? На мой взгляд, например, эта фича — зарабатывание на плошку риса строками кода.
Вам платят за количество докерфайлов? :D И как вы будете передавать артефакты между контейнерами?
Ну и в сабже не точностьВместо
"В команде "docker build" реализован флаг "--build-arg", позволяющий установить переменные для сборки, определённые в файле Dockerfile;"Должно быть
"В команде "docker build" реализована возможность использовать значение аргументов, передаваемых через опцию "--build-arg" в поле FROM"
Т.е. теперь можно так
ARG ALPINE_VERSION
FROM alpine:${ALPINE_VERSION}
....$ docker build --build-arg ALPINE_VERSION=3.1 .
Sending build context to Docker daemon 9.728kB
Step 1/3 : ARG ALPINE_VERSION
--->
Step 2/3 : FROM alpine:${ALPINE_VERSION}
3.1: Pulling from library/alpine
5cd2c87bea1e: Pull complete
Digest: sha256:d9477888b78e8c6392e0be8b2e73f8c67e2894ff9d4b8e467d1488fcceec21c8
Status: Downloaded newer image for alpine:3.1
---> 00772ebf9244
Step 3/3 : RUN echo "And another one"
---> Running in 27484f729759
And another one
---> 3eaaac555507
Removing intermediate container 27484f729759
Successfully built 3eaaac555507
из присутствующих кто-либо делал инсталляции на 5000 контейнеров? какой режим сети выбирали?
Да, выбрали режим поддержки докера группой программистов из 10 человек.
ты про сам докер, а у меня вопрос в основном по сетевой составляющей. из коробки все ставят оверлей сеть с натом. когда инсталляция разрастается и начинаются проблемы с производительностью все в панике начинают смотреть а чего там тормозит. при этом вменяемых средств трата и мониторинга этого оверлея нет. а с маквлан не все оркестры работают.
а зачем вам нат?
возьмите openvswitch, запилите несколько бриджей, разрулите всё там
ovs приятный