Pull to refresh
8
0
Максим Биленко @Sath

User

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

Разве что для кеширования при будущих сборках
В статье есть все ссылки как на результат так и на исходник
Я уже признал что дело было не в этом,
вот причина разростания образа в несколько раз:
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*
Антипаттерн и тут? 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) по другому нормально создать контейнер не получилось, если вы имеете свое мнение по этому поводу — пишите предложения
ну init это один процес, и процес который init мэнеджит — еще один, уже два.

зачем процесс который менеджит init?
И под процессом я закладывал смысл не 1 pid а 1 сервис, надеюсь о child процессах не будем прододжать…
Под одним процессом подразумевается что не нужно лепить в 1 контейнер кучу сервисов, и SSHD на дисерт, к примеру.
Существенного уменьшения размера образа я добился за счет оптимизации Dockerfile и объединения RUN инструкций и отказа от COPY/ADD
Да, вы правы, я ошибся…
Как минимум вот тут все описано
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.

Интересно, возможно я шибаюсь. Похоже на то что доработали это начиная с версии 1.4
По поводу .dockerignore — в процессе сборки каждая инструкция это инкрементальный слой.
В начале сборки загружаются все файлы которые есть в папке рядом с Dockerfile, этот первый этап также является слоем
А что вы скажите на Containerizing the Cloud with Docker on Google Cloud Platform и kubernetes который открыл гугл?
И с личного опыта хочу сказать что продакшн на Docker есть.
Теоритически можно будет экранировать большую часть внешних воздействий
Apple watch :) Там предуспотрена такая функция, да и превью там видно, возможно даже будет возможно выбирать точку резкости.
В статье просто описаны логические основы без красивой обвертки.
Но если это все централизировать и поднять Kibana — все выглядит очень даже достойно и удобно.

Как для продакшна, я считаю, подобная технология просто must have
В прочем и для девелопмента и тестирования очень удобно
Кривизна наложения режит глаза, можно было сделать округление в фотошопе в 2 клика
Сори, перепутал. правильно утилита называется fsck
А вобщем вам повезло если вы не застали подобных проблем, зачастую это распространенные грабли
Только не говорите что у вас ниразу небыло Kernel Panic (к примеру) после очередного минорного обновления ядра?
Или ошибки при перезагрузке с монтированием рут девайса, когда нужно логинится в шел и делать ремаунт, править fstab?
Ниразу не убивали файловую систему chkfs?
Итог: Нельзя говорить что что-то реально лучше а что-то полное гг, просто у каждого продукта свои достоинства и недостатки. Я против холиваров, спасибо.
Прошу прощения за резкость, но только мне показалось что статья ниочем?
Вы знаете, я гурман, но вы тоже тот еще :) У меня даже мысли небыло использовать Tmux для cmd :)
1

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity