Etki
я бы просто роутер добавил входным сервисом
Etki
либо контейнер со статикой им сделал
Artem
Действительно, что мешает воткнуть ещё один nginx перед ними который будет разруливать запросы?
Artem
В образах и роллбэк гораздо удобнее делать в случае косячного билда
𝕍ℤ
т.е. билдить fpm с мапом гита, nginx со статикой и еще nginx для роута?
Artem
ну статику модно наверное замонтировать через volume
Etki
зачем
Artem
ну чтобы образы не обрастали
Etki
вместо этого будет обрастать человек, менеджащий инфраструктуру
Artem
мало ли у них там пару гигов мусора в статике
Etki
деплойменты тоже из деплойментов станут чем-то странным
Artem
ну а так да, просто статику в образах можно держать тоже
Etki
разве два гига - это сильно неподъемно?
Artem
ну смотря для кого, я просто привык что у меня образы по 50-200мб на сервисах
Artem
у всех по разному конечно
Etki
да, держать надо больше, но это все равно дешевле, чем лишнее звено вводить
Etki
hardware is cheap, people are not
Konstantin
ну так и советуют. только сейчас у меня имейдж nginx, на котором фронт, и все урлы api и rest перенаправляются на fpm, на котором бэк. а придется из всего этого один образ собирать
А собрать два образа? Nginx+front и fpm+back?
𝕍ℤ
А собрать два образа? Nginx+front и fpm+back?
сейчас так и работает. точнее, fpm не билдится, там имейдж с хаба и мап гита, а nginx да, буду билдить
Konstantin
𝕍ℤ
https://kubernetes.io/docs/concepts/storage/volumes/#gitrepo
Konstantin
Спасибо
Konstantin
А собирать в образ не лучше/быстрее?
𝕍ℤ
зависит от ваших предпочтений, если хотите микросервисы, то мапить. однако, в ходе дискуссий выяснилось, что подход со сборкой обдного образа со всем на борту гораздо популярнее
𝕍ℤ
полистайте переписку выше)
Zon
зависит от ваших предпочтений, если хотите микросервисы, то мапить. однако, в ходе дискуссий выяснилось, что подход со сборкой обдного образа со всем на борту гораздо популярнее
Всё-таки предложено несколько контейнеров. Роутер ( или ингресс ) под с nginx и data container с собранным фронтом, под с fpm и data container с собранным беком. Итого 3 пода и 5 контейнеров. С ингрессом - 2 пода и 4 контейнера. При деплое пересобираются два из них, с сорцами.
Zon
Ибо мапить нужно не из гита, а из другого контейнера
Zon
https://docs.docker.com/engine/tutorials/dockervolumes/ родная докеровская дока на эту тему
𝕍ℤ
Ибо мапить нужно не из гита, а из другого контейнера
простите, а зачем?) куб сам зафетчит и создаст вольюм
Zon
простите, а зачем?) куб сам зафетчит и создаст вольюм
Это хорошо, если в репе только нужный код. Но у многих в репе ещё и тесты, например. Их удобно версионировать вместе.
𝕍ℤ
у большинства в репах тесты, только я не понял, что плохого мапить вместе с тестами
G72K
билдить образы мешает юниксовская привычка разделять зоны ответственности. поясню. есть, например, отлаженный и оттестированный образ nginx, такой же образ fpm. есть отдельно код бэка и фронта, они друг от друга не зависят статикой. и, по идее, что бы всю эту мозаику сложить в работающее приложение, нужно настроить деплои в одном неймспэйсе, запамить туда исходники, и радоваться. т.е. не пересобирать каждый раз образы, которые и так идеально работают, а, например, билдить volume с исходниками. и мне удивительно, что такой подход среди адептов куба считается ненормальным
есть официальный gitRepo volume type, вам не подходит? https://kubernetes.io/docs/concepts/storage/volumes/#gitrepo
𝕍ℤ
не подходит в случае фронта, там extjs и его надо предварительно собирать
G72K
в кубе единица работы - это контейнер. контейнер неделим, и для куба нет разницы, завалился контейнер из-за недочетов сборки или ошибки синтаксиса в приложении
не контейнер, а под. Под перезапустится при смене volume . так что вполне можно исходники примонтировать и оставаться идеологически верным
G72K
не подходит в случае фронта, там extjs и его надо предварительно собирать
собирайте в init container
Zon
не подходит в случае фронта, там extjs и его надо предварительно собирать
Вот в таких случаях, как раз дата-контейнер и нужен. Если нет сборки, зависимостей и тд - можно и напрямую, но ощущение неконсистентности остаётся
G72K
И старт будет проходить сильно дольше
ну если не хотят контейнер со скомпилированными исходниками собирать, то где-то же должно оно компилироваться же
Zon
ну если не хотят контейнер со скомпилированными исходниками собирать, то где-то же должно оно компилироваться же
Где-то должно. Но это настолько неконсистентно, зависимо от внешних модулей, что лучше всё-таки собрать образ
Zon
Я давно не смотрел в пхп, но у них там разве менеджер зависимостей не появился?
𝕍ℤ
инит-контейнеры в рамках деплоя тож работают?
G72K
инит-контейнеры в рамках деплоя тож работают?
да, везде где есть PodSpec работают, даже в Job :)
G72K
Где-то должно. Но это настолько неконсистентно, зависимо от внешних модулей, что лучше всё-таки собрать образ
а что, кто-то еще не складывает все зависимости в гит рядом с кодом?
𝕍ℤ
а объясните на пальцах, как в кубе мапить данные с одного контейнера на другой
Zon
а что, кто-то еще не складывает все зависимости в гит рядом с кодом?
Спрошу наших скала девелоперов, может мы что-то не так делаем
G72K
а объясните на пальцах, как в кубе мапить данные с одного контейнера на другой
никак :( есть хак: в init container перелить то что хочется в emptyDir и пото её замапить в другие контейнеры
𝕍ℤ
а ссылки есть почитать?
G72K
Спрошу наших скала девелоперов, может мы что-то не так делаем
забыл про джавистов, да они так не делают. выруливают локальным artifactory кажется , но всё равно боль
G72K
а ссылки есть почитать?
хз, попробуйте сами, тм просто. command переопределяет entrypoint контейнера, так что можно запустить образ с данными которые хочется раздать другим контейнерам в поде и в качестве команды указать /bin/cp в emptyDir volume, который потом подцепляете к остальным конетйнерам в поде
𝕍ℤ
ох, магия.. не люблю магию в данном её проявлении)
Etki
не контейнер, а под. Под перезапустится при смене volume . так что вполне можно исходники примонтировать и оставаться идеологически верным
Меня сегодня изобьют походу за эту фразу. Мы там раза два точно поговорили.
G72K
Меня сегодня изобьют походу за эту фразу. Мы там раза два точно поговорили.
написал непрочитав :)
Etki
Короч
Etki
Не нужно ничего выносить из контейнера в другой контейнер и на хост
Etki
Это от дьявола
Etki
Исключение только для хранилищ
Konstantin
Я давно не смотрел в пхп, но у них там разве менеджер зависимостей не появился?
Composer, аналог npm
Sn00part
вы написали больше 100 сообщений, но по делу ни одного xD
Sn00part
по делу - выпускать сегодня приложение без маломальского CICD немодно, вредно и непродуктивно
Sn00part
да ещё и на пхп.
Sn00part
особенно в k8s
Sn00part
работать не будет.
как вы это тестить собрались я тоже не увидел. расскажите, очень интересно.
или сурово без тестов сразу в бой?
Sn00part
я бы вам рекомендовал нанять девопса, он вам все процессы настроит, там недолго, но эффективно
𝕍ℤ
которое ваше сообщение читаю, и ни одного дельного совета, только сферические размышления в вакууме как надо писать и на чем
Sn00part
чего они сферические? они конкретные. надо настроить cicd. Иначе прод работать не будет. у пхп специфика такая, что там постоянно нужен штат админов. если ещё не наладить деплой, то двойной штат
Sn00part
для конкретных советов нужно больше информации. сколько у вас бекендов, как вы деплоитесь, как тестите и прочее
G72K
по делу - выпускать сегодня приложение без маломальского CICD немодно, вредно и непродуктивно
Как мапинг исходников внутрь пода через volumes противоречит CI CD религии?
Sn00part
как это тестить?
G72K
Причем тут тесты? Это способ запуска/упаковки/доставки. Оно ортогонально тому тесты это или прод или еще чтото
Sn00part
это не религия, это здравый смысл.
мапить исходники - идея довольно плохая в случае с кубернетесом. можно намапиться до разных версий бекенда в проде. если бекенд один, вопросов нет. если 50 то работать уже вряд ли будет
Sn00part
в случае с пхп, сомневаюсь, что бекенд один
G72K
. Чем замена версии докер имаджа в каком-то deployment.yaml отличается от замены git commit id в том же самом deployment.yaml? И там и там поды будут перезапущены согласно стратегии.
Anonymous
Sn00part
надо где-то хранить соответствие докеримаджа и гиткоммита внутри него. чтобы мы понимали что мы это потестили
Sn00part
если релизы раз в день, то очень скоро все станет непонятно
G72K
надо где-то хранить соответствие докеримаджа и гиткоммита внутри него. чтобы мы понимали что мы это потестили
Почему? Докер имадж один, php-fpm, жует то, что ему подсунули
Sn00part
тогда зачем все эти сложности? собирать сразу докеримадж с кодом внутри, его тестить и в прод