Docker. Best practices на примере образа Oracle xe 11g

[amarao]

У докера нет лучших практик. У докера есть «быстро» и «какой такой продакшен?».

[Sath]

А что вы скажите на Containerizing the Cloud with Docker on Google Cloud Platform и kubernetes который открыл гугл?
И с личного опыта хочу сказать что продакшн на Docker есть.

[amarao]

Kubernetes не щупал.

Насчёт второго — в этом и ужас. Оно в таком виде потом на продакшен, а потом вопросы: «ну что за подстава, мы его запускали как wget h ttp://...;docker run, а оно у нас все пароли из базы спёрло».

У докера в том виде, как его сопровождает комьюнити, нет ни безопасности, ни best practice (в контексте «best of production»). Оно задумывалось как rapid development (мне надо _СЕЙЧАС_ это запустить и насрать на мнение aptitude о зависимостях), а оказалось в продакшене у многих хипстерско-вевбдванольных конторах без нормальных сисадминов (птички-облака-бигдата-а-что-такое-oom-killer).

При правильной позиции сисадминов и вменяемых (с позиции devops) девелоперов его можно готовить и использовать как любую другую программу. Но в таких средах обычно docker ничего существенно не меняет, потому что у людей и CI нормальный, и пакеты в свой репозиторий (rpm/deb) выкладываются (сами).

[rhamdeew]

Но все же, согласитесь, всегда приятно если «быстро» будет чуточку легче и еще быстрей.
Насчет продакшена, что скажете про www.iron.io?

[amarao]

Эм, я не до конца понял как оно у них внутри устроено. А поддержку «для клиентов» вам все впилят куда угодно. Будете самолёты с ПО в докере покупать — будут вам самолёты с докером. Захотите атомные реакторы и сможете за это платить — будут вам атомные реакторы с деплоем через curl.

[frol]

Если уметь его готовить — это очень мощный инструмент, а если образ всегда начинается с FROM ubuntu, то это уже личные проблемы каждого, такие люди и curl ... | bash и sudo make install делают. Инструмент не виноват в глупости того, кто пользуется инструментом. Молотком можно людей калечить, а можно гвозди забивать.

[frol]

Я так и не понял как вы связали .dockerignore с уменьшением веса финального образа. Этот файл влияет только на процесс сборки, то есть что будет доступно для копирования в Dockerfile. Однако, если не копировать, то образ и не будет увеличиваться. Так что на вес образа влияла команда вида COPY * /tmp (или ADD).

Вот тут можно наглядно сравнить два образа: ImageLayers.

В остальном, спасибо, что несёте добро в массы, а то неоправданно огромные образы буквально завалили DockerHub.

[Sath]

По поводу .dockerignore — в процессе сборки каждая инструкция это инкрементальный слой.
В начале сборки загружаются все файлы которые есть в папке рядом с Dockerfile, этот первый этап также является слоем

[frol]

Это неправда. Я даже провёл только что эксперимент:

$ du -sh .
413M    .

$ cat Dockerfile
FROM alpine

COPY serial.txt /tmp/serial.txt

$ cat .dockerignore
cat: .dockerignore: No such file or directory

$ ls -lah serial.txt
-rw-r--r-- 1 frol frol 30 May 25 15:43 serial.txt

$ docker build -t qq .
Sending build context to Docker daemon 432.5 MB
Sending build context to Docker daemon
Step 0 : FROM alpine
 ---> 8697b6cc1f48
Step 1 : COPY serial.txt /tmp/serial.txt
 ---> 2209f356a4ea
Removing intermediate container 9d055644cb5b
Successfully built 2209f356a4ea

$ docker images | grep qq
qq                        latest              2209f356a4ea        5 seconds ago       5.238 MB

У меня в папке файлов на 413МБ, никакого .dockerignore нет, docker build запаковал в tar все файлы и получил 435МБ, которые «отправил на сборку» (так работает build) и в образ я добавил только файл serial.txt, весящий 30 байт, но финальный образ весит 5.2МБ!

Таким образом .dockerignore может сократить этап архивирования для build, но файлы из текущего каталога не попадут в образ если вы их туда не скопируете командами COPY или ADD, что видно из моего эксперимента.

[Sath]

Интересно, возможно я шибаюсь. Похоже на то что доработали это начиная с версии 1.4

[frol]

Убедитесь сами и поправьте статью дабы не вводить людей в заблуждение, пожалуйста.

[Sath]

Как минимум вот тут все описано
docs.docker.com/articles/dockerfile_best-practices

Use a .dockerignore file
For faster uploading and efficiency during docker build, you should use a .dockerignore file to exclude files or directories from the build context and final image. For example, unless.git is needed by your build process or scripts, you should add it to .dockerignore, which can save many megabytes worth of upload time.

[frol]

Предпочитаете верить написанной глупости (неточности/устаревшей информации) вместо своих собственных глаз?

[Sath]

В статье есть все ссылки как на результат так и на исходник
Я уже признал что дело было не в этом,
вот причина разростания образа в несколько раз:

ADD chkconfig /sbin/chkconfig
ADD init.ora /
ADD initXETemp.ora /
ADD oracle-xe_11.2.0-1.0_amd64.debaa /
ADD oracle-xe_11.2.0-1.0_amd64.debab /
ADD oracle-xe_11.2.0-1.0_amd64.debac /
# ADD oracle-xe_11.2.0-1.0_amd64.deb /
RUN cat /oracle-xe_11.2.0-1.0_amd64.deba* > /oracle-xe_11.2.0-1.0_amd64.deb

...
# Remove installation files
RUN rm /oracle-xe_11.2.0-1.0_amd64.deb*

[Sath]

Если слои нафиг не нужны можно вообще компактить итоговые имеджи, но зачем это можеть быть надо представить сложно.

Разве что для кеширования при будущих сборках

[Sath]

Да, вы правы, я ошибся…

[Sath]

Существенного уменьшения размера образа я добился за счет оптимизации Dockerfile и объединения RUN инструкций и отказа от COPY/ADD

[vintage]

Нет, всегда так и было. Если вы добавляете не конкретные файлы, а целые директории, то .dockerignore позволяет указать какие типы дочерних файлов/директорий добавлять всё же не стоит.

[Sath]

Под одним процессом подразумевается что не нужно лепить в 1 контейнер кучу сервисов, и SSHD на дисерт, к примеру.

[Sath]

ну init это один процес, и процес который init мэнеджит — еще один, уже два.

зачем процесс который менеджит init?
И под процессом я закладывал смысл не 1 pid а 1 сервис, надеюсь о child процессах не будем прододжать…

[Sath]

Антипаттерн и тут? docs.docker.com/articles/dockerfile_best-practices

Run only one process per container
In almost all cases, you should only run a single process in a single container. Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers. If that service depends on another service, make use of container linking.

Это официальная дока, и я с ней полностью согласен.
В данном случае(с Oracle DB) по другому нормально создать контейнер не получилось, если вы имеете свое мнение по этому поводу — пишите предложения

[Sath]

Я согласен с вашей точкой зрения.
Я против супервизоров с несколькими сервисами. Я за то чтобы инфраструктуру разбивать на мельчайшие детали(microservices). Это дает больше отказоустойчивости, в случае если какой-либо компонент отваливается — все остальное продолжает работать

[vintage]

Установка пакетов с нуля — довольно медленная операция, пусть и не частая. Мы сначала обновляем зависимости, а потом уже запускаем билд контейнера. То есть для докера, обновление пакетов выглядит как обновление всех остальных исходников. Такая схема отрабатывает гораздо быстрее и без лишних промежуточных коммитов.

[vintage]

Нет, примерно таким скриптом:

git pull
npm install
docker build --rm -t my/app .

А в Dockerfile уже все сбилженные файлы просто добавляются в образ.

[vintage]

Не очень понял о чём вы.

[vintage]

А, ну у нас сначала собирается образ с билдером, потом он билдит исходники приложения в хостовой директории, а потом билдится образ из получившихся файлов :-)