Комментарии 37
У докера нет лучших практик. У докера есть «быстро» и «какой такой продакшен?».
+3
А что вы скажите на Containerizing the Cloud with Docker on Google Cloud Platform и kubernetes который открыл гугл?
И с личного опыта хочу сказать что продакшн на Docker есть.
И с личного опыта хочу сказать что продакшн на Docker есть.
+2
Kubernetes не щупал.
Насчёт второго — в этом и ужас. Оно в таком виде потом на продакшен, а потом вопросы: «ну что за подстава, мы его запускали как wget h ttp://...;docker run, а оно у нас все пароли из базы спёрло».
У докера в том виде, как его сопровождает комьюнити, нет ни безопасности, ни best practice (в контексте «best of production»). Оно задумывалось как rapid development (мне надо _СЕЙЧАС_ это запустить и насрать на мнение aptitude о зависимостях), а оказалось в продакшене у многих хипстерско-вевбдванольных конторах без нормальных сисадминов (птички-облака-бигдата-а-что-такое-oom-killer).
При правильной позиции сисадминов и вменяемых (с позиции devops) девелоперов его можно готовить и использовать как любую другую программу. Но в таких средах обычно docker ничего существенно не меняет, потому что у людей и CI нормальный, и пакеты в свой репозиторий (rpm/deb) выкладываются (сами).
Насчёт второго — в этом и ужас. Оно в таком виде потом на продакшен, а потом вопросы: «ну что за подстава, мы его запускали как wget h ttp://...;docker run, а оно у нас все пароли из базы спёрло».
У докера в том виде, как его сопровождает комьюнити, нет ни безопасности, ни best practice (в контексте «best of production»). Оно задумывалось как rapid development (мне надо _СЕЙЧАС_ это запустить и насрать на мнение aptitude о зависимостях), а оказалось в продакшене у многих хипстерско-вевбдванольных конторах без нормальных сисадминов (птички-облака-бигдата-а-что-такое-oom-killer).
При правильной позиции сисадминов и вменяемых (с позиции devops) девелоперов его можно готовить и использовать как любую другую программу. Но в таких средах обычно docker ничего существенно не меняет, потому что у людей и CI нормальный, и пакеты в свой репозиторий (rpm/deb) выкладываются (сами).
+2
Но все же, согласитесь, всегда приятно если «быстро» будет чуточку легче и еще быстрей.
Насчет продакшена, что скажете про www.iron.io?
Насчет продакшена, что скажете про www.iron.io?
0
Если уметь его готовить — это очень мощный инструмент, а если образ всегда начинается с
FROM ubuntu
, то это уже личные проблемы каждого, такие люди и curl ... | bash
и sudo make install
делают. Инструмент не виноват в глупости того, кто пользуется инструментом. Молотком можно людей калечить, а можно гвозди забивать.+1
Я так и не понял как вы связали
Вот тут можно наглядно сравнить два образа: ImageLayers.
В остальном, спасибо, что несёте добро в массы, а то неоправданно огромные образы буквально завалили DockerHub.
.dockerignore
с уменьшением веса финального образа. Этот файл влияет только на процесс сборки, то есть что будет доступно для копирования в Dockerfile. Однако, если не копировать, то образ и не будет увеличиваться. Так что на вес образа влияла команда вида COPY * /tmp
(или ADD).Вот тут можно наглядно сравнить два образа: ImageLayers.
В остальном, спасибо, что несёте добро в массы, а то неоправданно огромные образы буквально завалили DockerHub.
+1
По поводу .dockerignore — в процессе сборки каждая инструкция это инкрементальный слой.
В начале сборки загружаются все файлы которые есть в папке рядом с Dockerfile, этот первый этап также является слоем
В начале сборки загружаются все файлы которые есть в папке рядом с Dockerfile, этот первый этап также является слоем
0
Это неправда. Я даже провёл только что эксперимент:
У меня в папке файлов на 413МБ, никакого
Таким образом
$ 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, что видно из моего эксперимента.+2
Интересно, возможно я шибаюсь. Похоже на то что доработали это начиная с версии 1.4
-1
Убедитесь сами и поправьте статью дабы не вводить людей в заблуждение, пожалуйста.
0
Как минимум вот тут все описано
docs.docker.com/articles/dockerfile_best-practices
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.
0
Предпочитаете верить написанной глупости (неточности/устаревшей информации) вместо своих собственных глаз?
0
НЛО прилетело и опубликовало эту надпись здесь
В статье есть все ссылки как на результат так и на исходник
Я уже признал что дело было не в этом,
вот причина разростания образа в несколько раз:
Я уже признал что дело было не в этом,
вот причина разростания образа в несколько раз:
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*
0
Да, вы правы, я ошибся…
0
Нет, всегда так и было. Если вы добавляете не конкретные файлы, а целые директории, то .dockerignore позволяет указать какие типы дочерних файлов/директорий добавлять всё же не стоит.
+3
НЛО прилетело и опубликовало эту надпись здесь
Под одним процессом подразумевается что не нужно лепить в 1 контейнер кучу сервисов, и SSHD на дисерт, к примеру.
0
НЛО прилетело и опубликовало эту надпись здесь
ну init это один процес, и процес который init мэнеджит — еще один, уже два.
зачем процесс который менеджит init?
И под процессом я закладывал смысл не 1 pid а 1 сервис, надеюсь о child процессах не будем прододжать…
0
НЛО прилетело и опубликовало эту надпись здесь
Антипаттерн и тут? docs.docker.com/articles/dockerfile_best-practices
Это официальная дока, и я с ней полностью согласен.
В данном случае(с Oracle DB) по другому нормально создать контейнер не получилось, если вы имеете свое мнение по этому поводу — пишите предложения
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) по другому нормально создать контейнер не получилось, если вы имеете свое мнение по этому поводу — пишите предложения
0
НЛО прилетело и опубликовало эту надпись здесь
Установка пакетов с нуля — довольно медленная операция, пусть и не частая. Мы сначала обновляем зависимости, а потом уже запускаем билд контейнера. То есть для докера, обновление пакетов выглядит как обновление всех остальных исходников. Такая схема отрабатывает гораздо быстрее и без лишних промежуточных коммитов.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Docker. Best practices на примере образа Oracle xe 11g