по делу - выпускать сегодня приложение без маломальского CICD немодно, вредно и непродуктивно

да ещё и на пхп.

особенно в k8s

работать не будет. как вы это тестить собрались я тоже не увидел. расскажите, очень интересно. или сурово без тестов сразу в бой?

я бы вам рекомендовал нанять девопса, он вам все процессы настроит, там недолго, но эффективно

которое ваше сообщение читаю, и ни одного дельного совета, только сферические размышления в вакууме как надо писать и на чем

чего они сферические? они конкретные. надо настроить cicd. Иначе прод работать не будет. у пхп специфика такая, что там постоянно нужен штат админов. если ещё не наладить деплой, то двойной штат

для конкретных советов нужно больше информации. сколько у вас бекендов, как вы деплоитесь, как тестите и прочее

по делу - выпускать сегодня приложение без маломальского CICD немодно, вредно и непродуктивно

Как мапинг исходников внутрь пода через volumes противоречит CI CD религии?

как это тестить?

Причем тут тесты? Это способ запуска/упаковки/доставки. Оно ортогонально тому тесты это или прод или еще чтото

это не религия, это здравый смысл. мапить исходники - идея довольно плохая в случае с кубернетесом. можно намапиться до разных версий бекенда в проде. если бекенд один, вопросов нет. если 50 то работать уже вряд ли будет

в случае с пхп, сомневаюсь, что бекенд один

. Чем замена версии докер имаджа в каком-то deployment.yaml отличается от замены git commit id в том же самом deployment.yaml? И там и там поды будут перезапущены согласно стратегии.

вместо этого будет обрастать человек, менеджащий инфраструктуру

хахаха, отлично

по делу - выпускать сегодня приложение без маломальского CICD немодно, вредно и непродуктивно

+1

надо где-то хранить соответствие докеримаджа и гиткоммита внутри него. чтобы мы понимали что мы это потестили

если релизы раз в день, то очень скоро все станет непонятно

надо где-то хранить соответствие докеримаджа и гиткоммита внутри него. чтобы мы понимали что мы это потестили

Почему? Докер имадж один, php-fpm, жует то, что ему подсунули

тогда зачем все эти сложности? собирать сразу докеримадж с кодом внутри, его тестить и в прод

там наверняка юйй какой нибудь, кода больше, чем сам докеримадж весит

тогда зачем все эти сложности? собирать сразу докеримадж с кодом внутри, его тестить и в прод

Почему сложности? Ну удобнее людям тэги в гите двигать, чем имаджи собирать, что теперь, запрещать чтоли?

а зачем тут люди? дженкинс же или подобные

меньше ненужной работы людям, больше времени сделать что-либо полезное в приложении

дженкинс пусть срабатывает на коммит. меньше вероятности ошибки

а зачем тут люди? дженкинс же или подобные

Да причем тут дженкинс? Еще раз: Мэпинг исходников в под не противоречит Ci Cd. В конце концов что-то где-то обновит deployment.yaml и сделает kubectl apply. Обновится поле докер имаджа иди гит коммита - не важно. Будет ли это обновление елать человек, робот, или коллегия на архитекторов на ежегодном заседании анонимным голосованием - это не было в вопросе и нет в моих ответах, но есть в ваших почему тл

правильно. зачем делать просто и эффективно. надо делать сложно и непрозрачно

в лаптопе поиграться можно что угодно делать и как угодно. в большом приложении с кучей бекендов лишняя сумятица ни к чему.

с каких пор работа с гитом непрозрачна?

разговор про деплой, а не работу с гитом

правильно. зачем делать просто и эффективно. надо делать сложно и непрозрачно

Ну как минимум не надо собирать образы на каждый чих, держать локальный Docker registry который любит распухать, а так же значительно проще разрабатывать, ибо если на лаптопе мапить исходники и в проде мапить исходники, то как бы прод становится ближе к деву :)

?

всё зависит от приложения. в одной большой конторе так и делают до сих пор. поэтому там семь админов и все плохо спят.

Да чем хуже то? Не лучше и не хуже, просто по-другому. Назовёте технические аргументы чем оно так плохо?

непонятно как это тестить, человеческий фактор, нарушение 12factors,

Брр.. да как так то? вот есть cI/cd все тесты прошли в итоге релиз в прод. последнее действие: обвновить deployment.yaml , какая разница что в нем обновлять: верси имаджа или гит коммит?

человеческий факто тут причем?и то и то могут обновлять как роботы, так и человек, ничего про это не было в вопросе

гит коммит и версия имаджа должна быть протестирована вместе. мы может просто про разные приложения говорим? где один имадж раз в год меняется и две виртуалочки с кодом?

у меня 47 имаджей есть в проде сейчас и 12 релизных версий приложения например

приложение большое, его сразу не перепишешь, по частям только.

пхп там тоже есть

практика с маппингом коммита там просто не работает. работает другая, про которую я рассказал. в других реалиях, возможно, сработает и маппинг. но зачем делать неправильно, а потом переделывать, когда можно сразу сделать нормально и избавить себя от проблем в будущем

гит коммит и версия имаджа должна быть протестирована вместе. мы может просто про разные приложения говорим? где один имадж раз в год меняется и две виртуалочки с кодом?

имадж php-fpm, жрет что дают.у него свой цикл обновления/релизов

тем более Best practices уже есть, доки по этому делу тоже. тот же 12factors покрывает 80% всех вопросов

php-fpm просто запускалка кода. точно так же как ядро, докер и версия куба: их обновления как-то тестируются +- степень паранои, но в целом обычно не идет речь о перетестировании всех приложений во всех окружениях

тем более Best practices уже есть, доки по этому делу тоже. тот же 12factors покрывает 80% всех вопросов

какой пункт 12factors нарушен при мапинге гита?

практика с маппингом коммита там просто не работает. работает другая, про которую я рассказал. в других реалиях, возможно, сработает и маппинг. но зачем делать неправильно, а потом переделывать, когда можно сразу сделать нормально и избавить себя от проблем в будущем

да в чем конкретно не работает то можете сказать? если прищуриться то и скачивание имаджа и скачивание гит коммита - это просто загрузка тарбола, ничем друг от друга они не отличаются

в результате каких процессов источник этого тарбола обновился вообще к вопросу отношения не имеет

Брр.. да как так то? вот есть cI/cd все тесты прошли в итоге релиз в прод. последнее действие: обвновить deployment.yaml , какая разница что в нем обновлять: верси имаджа или гит коммит?

Артефакт != ревизия в скв

Артефакт != ревизия в скв

ой да ладно? а если я закомичу артефакт в гит ? :) на если сеьезно, все равно одно и то же, если гарантируется, что если процесс перехода из ревизии в артефакт повторяем. в случае PHP этого элементарно добиться

Давайте без ой да ладно

А по существу?

По существу выше

Если хотите передергивать - пожалуйста

чем FROM nginx COPY src /mypath и потом в кубе: containers: - image: nginx-and-sources настолько принципильно отличается от containers: - image: nginx name: nginx volumeMounts: - mountPath: /mypath name: git-volume volumes: - name: git-volume gitRepo: repository: "git@somewhere:me/my-git-repository.git" revision: "22f1d8406d464b0c0874075539c1f2e96c253775" что во втором случае прям контора утонет в админах и будет еле дышать?

этап сборки, релиз и выполнения не определён чётко. имадж и гит коммит надо тестировать вместе. либо хранить где-то пары протестенных айди.

этап сборки, релиз и выполнения не определён чётко. имадж и гит коммит надо тестировать вместе. либо хранить где-то пары протестенных айди.

почему вы хотите хранить пары php-fpm + git commit, но не предлагаете хранить kernel version + kube version + docker version + flannel version + image version?

и там и там есть относительно часто меняющаяся версия и относительно стабильная среда выполнения

> этап сборки /bin/true > релиз обновления deploy.yaml сначала в тестовом, потом препрод, потом в прод кубе > выполнения всё в deployment.yaml, определено четко

если вам нужен формализм, то ваш артефакт не image:version, а кусок yaml , вот и гоняйте его по всем стадиям вашего ci cd, ничего принципиально не меняется

Если хотите передергивать - пожалуйста

если есть функция f(src) -> artifact и она детерминированная, то ревизия это и есть артефакт со всех точек зрения

почему вы хотите хранить пары php-fpm + git commit, но не предлагаете хранить kernel version + kube version + docker version + flannel version + image version?

потому, что вторая часть относительно редко меняется и в ней мы уверены. а первая гораздо чаще.

потому, что вторая часть относительно редко меняется и в ней мы уверены. а первая гораздо чаще.

так вопрос в уверенности в надежности php-fpm имаджа? ну так для этого же у вас есть ci cd! просто у этого имаджа свой релиз цикл, своя команда разработки и вообще всё свое.тесты-шместы, все такое. чем плохо?

если есть функция f(src) -> artifact и она детерминированная, то ревизия это и есть артефакт со всех точек зрения

Она не детерминированная

И все равно это не артефакт

ERROR: S client not available

она _может_ быть не детерменированной

а может и быть такой

Она всегда будет недетерминированнрй, несмотря на теоретическую возможность обратного

Всегда так

И все равно это не артефакт

даже если детерминированная? почему?

у меня нет доверия к разработчикам. я должен быть уверен, что мой имадж работает с любым коммитом. разве плохо это?

Она всегда будет недетерминированнрй, несмотря на теоретическую возможность обратного

ну вот вам пример такого преобразования: cp -r src /var/www/html где ж оно недетремнировано?

даже если детерминированная? почему?

Потому что результат функции это не ее аргумент лрл

у меня нет доверия к разработчикам. я должен быть уверен, что мой имадж работает с любым коммитом. разве плохо это?

а к чему доверие есть? :)

ну вот вам пример такого преобразования: cp -r src /var/www/html где ж оно недетремнировано?

Да не бывает таких сборок

Да не бывает таких сборок

если все зависимости лежат рядом, то бывает

Потому что результат функции это не ее аргумент лрл

но результат всегда можно получить применив функцию к имеющемуся аргументу и получить гарантированный результат

но результат всегда можно получить применив функцию к имеющемуся аргументу и получить гарантированный результат

Хлеб это зерно

Хлеб это зерно

при рассуждениях что "надо бы хлеб, а есть только зерно", наличие возможности в любой момент превратить зерно в хлеб разве не делет такие рассуждения бессмысленными?

Хлеб все равно не зерно

Даже если свести все к гитлеру

Хлеб все равно не зерно

верно. но если вам нужен хлеб вы его получите , так что наличие зерна достаточно )

Я вообще не понимаю, что мы обсуждаем

я уже тоже. пойду уже коньяк пить в конце концов.

у кого-нибудь Dex + LDAP работает? Еще не ставил у себя, но пытаюсь понять где TTL для токена задается

В конфиге декса

Может я не очень хорошо знаю работу gitRepo, но мне кажется, что если комит из гита потерли, то перезапустить или отскейлить под уже не получится.

контейнер должен быть иммутабелен и баста

Может я не очень хорошо знаю работу gitRepo, но мне кажется, что если комит из гита потерли, то перезапустить или отскейлить под уже не получится.

да. точно так же если image из docker registry потерли :) "не делайте так"

это разные области ответственности) не знаю, кстати, как можно из гита стереть коммит. с позиции админа, у реджистри есть бекапы. разработчики бекапы как правило не делают и пролюбливают все чаще.

имадж пересобираться же может, он в себе ничего не хранит stateful

а то, что есть, описано в dockerfile

с гитом сложнее, там постоянно чет мержат, ревертят, черипикают и сквашат

это разные области ответственности) не знаю, кстати, как можно из гита стереть коммит. с позиции админа, у реджистри есть бекапы. разработчики бекапы как правило не делают и пролюбливают все чаще.

Git squash, например. То, что делать это с мастером не очень бестпрактис, это другое дело. И если гит-сервер недоступен, то аутоскейлинг тоже недоступен. Да, имаджстор тоже может уйти в даун, но это одна сущность вместо двух. + Доступ на запись к имаджстор имеют, как правило, меньше людей. ( в идеале ноль )

?

с гитом сложнее, там постоянно чет мержат, ревертят, черипикают и сквашат

git commit id гарантирует его содержимое, с точностью до sha1 коллизий. Чего нельзя сказать о docker image id :)

зачем сравнивать несравнимые вещи? докеримадж сделаем immutable и совпадает он с dockerfile. но при пересборке могут прилететь обновления пакетов и все, приплыли.