Я согласен с вашей точкой зрения.
Я против супервизоров с несколькими сервисами. Я за то чтобы инфраструктуру разбивать на мельчайшие детали(microservices). Это дает больше отказоустойчивости, в случае если какой-либо компонент отваливается — все остальное продолжает работать
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) по другому нормально создать контейнер не получилось, если вы имеете свое мнение по этому поводу — пишите предложения
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.
По поводу .dockerignore — в процессе сборки каждая инструкция это инкрементальный слой.
В начале сборки загружаются все файлы которые есть в папке рядом с Dockerfile, этот первый этап также является слоем
В статье просто описаны логические основы без красивой обвертки.
Но если это все централизировать и поднять Kibana — все выглядит очень даже достойно и удобно.
Как для продакшна, я считаю, подобная технология просто must have
В прочем и для девелопмента и тестирования очень удобно
Только не говорите что у вас ниразу небыло Kernel Panic (к примеру) после очередного минорного обновления ядра?
Или ошибки при перезагрузке с монтированием рут девайса, когда нужно логинится в шел и делать ремаунт, править fstab?
Ниразу не убивали файловую систему chkfs?
Итог: Нельзя говорить что что-то реально лучше а что-то полное гг, просто у каждого продукта свои достоинства и недостатки. Я против холиваров, спасибо.
Я против супервизоров с несколькими сервисами. Я за то чтобы инфраструктуру разбивать на мельчайшие детали(microservices). Это дает больше отказоустойчивости, в случае если какой-либо компонент отваливается — все остальное продолжает работать
Разве что для кеширования при будущих сборках
Я уже признал что дело было не в этом,
вот причина разростания образа в несколько раз:
Это официальная дока, и я с ней полностью согласен.
В данном случае(с Oracle DB) по другому нормально создать контейнер не получилось, если вы имеете свое мнение по этому поводу — пишите предложения
зачем процесс который менеджит init?
И под процессом я закладывал смысл не 1 pid а 1 сервис, надеюсь о child процессах не будем прододжать…
docs.docker.com/articles/dockerfile_best-practices
В начале сборки загружаются все файлы которые есть в папке рядом с Dockerfile, этот первый этап также является слоем
И с личного опыта хочу сказать что продакшн на Docker есть.
Но если это все централизировать и поднять Kibana — все выглядит очень даже достойно и удобно.
Как для продакшна, я считаю, подобная технология просто must have
В прочем и для девелопмента и тестирования очень удобно
А вобщем вам повезло если вы не застали подобных проблем, зачастую это распространенные грабли
Или ошибки при перезагрузке с монтированием рут девайса, когда нужно логинится в шел и делать ремаунт, править fstab?
Ниразу не убивали файловую систему chkfs?
Итог: Нельзя говорить что что-то реально лучше а что-то полное гг, просто у каждого продукта свои достоинства и недостатки. Я против холиваров, спасибо.