используют докеры странно. Оказалось, что здесь не происходит сборки контейнеров. Т.е. весь код подсовывается через volume внутрь контейнера. Т.е. выкатка выглядит как "подсунуть новый код в контейнеры". Выглядит максимально странным. Ребята сказали, что они так ускорили сборку (фактически её нет, сборки).
С моей стороны претензия к этому:
- я бы хотел использовать оркестратор, чтобы избавить себя от возни с конкретными виртуалками и отдать это на откуп кубернетесу. При таком подходе с volume мы не сможем нормально пользоваться kubernetes.
То, что они сделали — костыль, но противопоставить этому я могу немногое. Вопрос: какие аргументы за и против прокидывания кода через volume? Их аргементы против. Нафига кубер, если есть 2 тачки, с которыми можно и руками управляться. Но что будет, если тачек станет больше? Кажется, что инструментом гвозди забиваются (я про докер).
это может иметь смысл, если приложение огромное, а релизы катятся по несколько штук в сутки. Насколько часто обновляете приложение?
Нет, релизы не частые (думаю, что максимум раз в сутки, скорее раз в 2-3 суток). Я предлагаю каждый раз собирать контейнеры с кодом внутри, а не снаружи. Что мы выиграем от этого? Изолированность.
поставь вопрос по другому - решают ли они все свои поставленные задачи?
нужно рационально подходить ко всему вольюмы для чего то же придуманы и нужны - в 1ю очередь для постоянных хранилищ но хранить конфиги в них наверное не разумно - для этого есть секреты и конфиги и в докере и в кубере
смысл не записывать все в свой образ очевиден - не нужна сборка и можно быстро обновлять версии сервисов не меняя конфигурации я больше склоняюсь к тому что сервисы должны как можно меньше знать и быть привязаны к конкретным параметрам и условиям - так система становится гибче - большую часть нагрузки по конфигурированию сервисов переносить в оркестратор - он для этого и задуман
Обсуждают сегодня