Information
- Rating
- Does not participate
- Location
- Ян де нова о-ва
- Date of birth
- Registered
- Activity
Specialization
Fullstack Developer, Software Architect
Lead
Java
Docker
React
TypeScript
Java Spring Framework
Designing application architecture
High-loaded systems
Ловить таких очень дорого и сложно.
Процесс докера работает а host-системе и взаимодействует с ядром host-системы.
Проблемой может быть только такая уязвимость, благодаря которой уязвимым станет сам бинарник процесса еще на этапе сборки.
Можно, конечно, было передавать все архивом и раскладывать файлы по местам, а старые удалять. Но это — неустойчиво к человеческим ошибкам.
Но есть задачи, где его вполне можно использовать в production.
Сам по себе он обновляться не будет. Ничто не мешает включить restart policy.
Но попробуйте убить его процесс через
kill -9
Дети останутся. Так же они останутся, если докер демон закрэшится из-за внутренней ошибки. Именно об этом шла речь.
Авторы докера еще не рекомендуют запускать в контейнере более одного процесса.
А вот эти авторы очень популярного base image другого мнения.
У любого решения есть плюсы и минусы. Взвешивать их и принимать решения только тому, кто несёт ответствнность за результат.
Здесь проще всего задать пароль, имя пользователя, хост и имя базы данных переменными окружения, передаваемыми самому контейнеру с СУБД. Так, чтобы они совпали с вашими.
Здесь обычно создаётся volume с конфигурацией, этот volume мэпится на директорию хост системы и там конфигурация правится руками. Некоторые параметры тоже можно передавать переменными окружения. Другой вариант — отнаследовать production image от development image и поменять там конфигурацию, просто перекрыв её новой при помощи директивы COPY.
Тут даже не скажу. Я написал «некоторые считают, что deployment исчезнет», но это не значит, что он уже исчез конкретно у нас.
Думаю, можно поступить также, как с конфигурацией, вынесенной на отдельный volume. Или опять отнаследовать образ.
Но сам я такого не делал.
Как то так:
VOLUME ["/opt/tomcat/logs"]
Данные, сохраненные контейнером в эту директорию не будут удалены вместе с контейнером.
Можно также мэпить тома на директории host системы.
Тогда отвечу так: я понятия не имею :)
Их проблема в исполнении кастомного кода во время установки.
Это — бОльшая хрупкость, по сравнению с докером у которого кастомный установочный код выполняется во время сборки образа.
В первом случае для устранения сбоев при установке нужен доступ на production.
Во втором сбои устраняются заранее во время сборки образа.
Другими словами, первая группа инструментов отправляет в продакшен код, который должен там исполниться в незнакомой среде хост системы.
Докер отправляет в продакшен заранее собранный процесс и требуемые ему данные. Здесь нет стадии исполнения кода во время установки. А нет исполнения — нет ошибок.
Эта задача заведомо более сложная, чем то, что делает докер — тупо запускает заранее подготовленные процессы — никакой кастомной логики во время установки не выполняется.
Другими словами, в случае с паппетом есть чему ломаться во время установки на продакшен.
В случае с докером поломки будут не во время установки, а во время сборки образа. То есть для их устранения не нало иметь доступ на production server.
Вот тут, например, обсуждают мажину с 12гб памяти 12 свопа, где запущено 183 контейнера и там докер съел 5гб виртуальной памяти.
Вообще, процесс докера работает через cgroups и использует системные вызовы ядра хост системы. Он не тащит с собой дополнительный линукс в свою память.
Докер — бесплатный, с открытыми исходниками, предоставляется по лицензии Apache 2.
То есть vendor lock in здесь такой же, как при использовании Linux.