Pull to refresh

Comments 37

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

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

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

При правильной позиции сисадминов и вменяемых (с позиции devops) девелоперов его можно готовить и использовать как любую другую программу. Но в таких средах обычно docker ничего существенно не меняет, потому что у людей и CI нормальный, и пакеты в свой репозиторий (rpm/deb) выкладываются (сами).
UFO just landed and posted this here
Но все же, согласитесь, всегда приятно если «быстро» будет чуточку легче и еще быстрей.
Насчет продакшена, что скажете про www.iron.io?
Эм, я не до конца понял как оно у них внутри устроено. А поддержку «для клиентов» вам все впилят куда угодно. Будете самолёты с ПО в докере покупать — будут вам самолёты с докером. Захотите атомные реакторы и сможете за это платить — будут вам атомные реакторы с деплоем через curl.
Если уметь его готовить — это очень мощный инструмент, а если образ всегда начинается с FROM ubuntu, то это уже личные проблемы каждого, такие люди и curl ... | bash и sudo make install делают. Инструмент не виноват в глупости того, кто пользуется инструментом. Молотком можно людей калечить, а можно гвозди забивать.
Я так и не понял как вы связали .dockerignore с уменьшением веса финального образа. Этот файл влияет только на процесс сборки, то есть что будет доступно для копирования в Dockerfile. Однако, если не копировать, то образ и не будет увеличиваться. Так что на вес образа влияла команда вида COPY * /tmp (или ADD).

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

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

$ 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, что видно из моего эксперимента.
Интересно, возможно я шибаюсь. Похоже на то что доработали это начиная с версии 1.4
Убедитесь сами и поправьте статью дабы не вводить людей в заблуждение, пожалуйста.
Как минимум вот тут все описано
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.

Предпочитаете верить написанной глупости (неточности/устаревшей информации) вместо своих собственных глаз?
UFO just landed and posted this here
В статье есть все ссылки как на результат так и на исходник
Я уже признал что дело было не в этом,
вот причина разростания образа в несколько раз:
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*
UFO just landed and posted this here
Если слои нафиг не нужны можно вообще компактить итоговые имеджи, но зачем это можеть быть надо представить сложно.

Разве что для кеширования при будущих сборках
UFO just landed and posted this here
Да, вы правы, я ошибся…
Существенного уменьшения размера образа я добился за счет оптимизации Dockerfile и объединения RUN инструкций и отказа от COPY/ADD
Нет, всегда так и было. Если вы добавляете не конкретные файлы, а целые директории, то .dockerignore позволяет указать какие типы дочерних файлов/директорий добавлять всё же не стоит.
UFO just landed and posted this here
Под одним процессом подразумевается что не нужно лепить в 1 контейнер кучу сервисов, и SSHD на дисерт, к примеру.
UFO just landed and posted this here
ну init это один процес, и процес который init мэнеджит — еще один, уже два.

зачем процесс который менеджит init?
И под процессом я закладывал смысл не 1 pid а 1 сервис, надеюсь о child процессах не будем прододжать…
UFO just landed and posted this here
Антипаттерн и тут? 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) по другому нормально создать контейнер не получилось, если вы имеете свое мнение по этому поводу — пишите предложения
UFO just landed and posted this here
Я согласен с вашей точкой зрения.
Я против супервизоров с несколькими сервисами. Я за то чтобы инфраструктуру разбивать на мельчайшие детали(microservices). Это дает больше отказоустойчивости, в случае если какой-либо компонент отваливается — все остальное продолжает работать
Установка пакетов с нуля — довольно медленная операция, пусть и не частая. Мы сначала обновляем зависимости, а потом уже запускаем билд контейнера. То есть для докера, обновление пакетов выглядит как обновление всех остальных исходников. Такая схема отрабатывает гораздо быстрее и без лишних промежуточных коммитов.
UFO just landed and posted this here
Нет, примерно таким скриптом:

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


А в Dockerfile уже все сбилженные файлы просто добавляются в образ.
UFO just landed and posted this here
Не очень понял о чём вы.
UFO just landed and posted this here
А, ну у нас сначала собирается образ с билдером, потом он билдит исходники приложения в хостовой директории, а потом билдится образ из получившихся файлов :-)
Sign up to leave a comment.

Articles

Change theme settings