плохой коммит помержили, потом черепикнули, сверху налабали уже, потом поревертили в первой бранчи, всем привет.

ещё бывает коммит прямым пушем и скваш.

причем здесь всё это? если есть известный commit id, он во всех уголках этой вселенной означает одно и то же.

> Да, имаджстор тоже может уйти в даун, но это одна сущность вместо двух. согласен. единственный аргументированный минус из всего обсуждения.

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

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

dangling commits есть, но его нет, например.

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

и вообще, тут никто не осуждает ваш подход, просто он не единственно верный

я и не говорю, что он единственно верный. вообще это не мой подход, это Best practices.

разработчик за прод не отвечает, он отвечает за код. я ^аккуратно коммичу^ так не работает, драть все равно будут админа, независимо от аккуратности разработчика.

а она так себе, иначе не нужны были никакие cicd. аккуратно накодил, аккуратно залил и все работает ок.

я и не говорю, что он единственно верный. вообще это не мой подход, это Best practices.

в вас говорит религия

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

Это всё хорошо, пока это один человек. Но это плохо скейлится. + давать куберу доступ к гиту это тоже не супер. В какой-то момент там был только password based auth и пароль протекал в манифест. Возможно от вашего подхода есть ускорение воркфлоу, но скейлить это тяжело. У меня был деплой из гита на 300 серверов, но пришлось поднимать зеркала, ибо один гит-сервер загибался. http get != git pull

вы так говорите, как будто при сборке образа клонировать репу не надо :)

1 раз против 300. Разница есть

> http get != git pull это смотря как реализовать. --depth=1 примерно равно http get

Про shallow clone я знаю. Памяти на отдачу гитом уходит сильно больше

у вас точно был git а не адъ на jgit?

Разные варианты тестировали. Отдача http статики, которая закешивается нормально, сильно быстрее

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

Разные варианты тестировали. Отдача http статики, которая закешивается нормально, сильно быстрее

с этим не поспоришь, но на 300 серверов должно ж хватить чего угодно

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

давайте я попробую еще раз. Последний. Вот этот кусок yaml: apiVersion: v1 kind: Pod metadata: name: server spec: containers: - image: nginx:version1 name: nginx volumeMounts: - mountPath: /mypath name: git-volume volumes: - name: git-volume gitRepo: repository: "git@somewhere:me/my-git-repository.git" revision: "22f1d8406d464b0c0874075539c1f2e96c253775" дает абсолютно те же самые гарантии что и apiVersion: v1 kind: Pod metadata: name: server spec: containers: - image: nginx:version1-built-from-22f1d8406d464b0c0874075539c1f2e96c253775 1 в 1. Назовите этот кусок yaml артефактом, если вам так удобнее, прогоняйте его по любым тестам, деплойте его A/B деплоем, делайте что угодно, что вам Best practices велят, всё что вы ждете от докер имаджа с исходниками внутри вы получите и с замапленым гитом. Единственная разница, которую за весь день удалось услышать - появляется необходимость чтобы git сервер был рабочим в довесок к рабочему docker registry.

а с джавой-то так не пройдет

(троллфейс)

а с джавой-то так не пройдет

? шах и мат :)

давайте я попробую еще раз. Последний. Вот этот кусок yaml: apiVersion: v1 kind: Pod metadata: name: server spec: containers: - image: nginx:version1 name: nginx volumeMounts: - mountPath: /mypath name: git-volume volumes: - name: git-volume gitRepo: repository: "git@somewhere:me/my-git-repository.git" revision: "22f1d8406d464b0c0874075539c1f2e96c253775" дает абсолютно те же самые гарантии что и apiVersion: v1 kind: Pod metadata: name: server spec: containers: - image: nginx:version1-built-from-22f1d8406d464b0c0874075539c1f2e96c253775 1 в 1. Назовите этот кусок yaml артефактом, если вам так удобнее, прогоняйте его по любым тестам, деплойте его A/B деплоем, делайте что угодно, что вам Best practices велят, всё что вы ждете от докер имаджа с исходниками внутри вы получите и с замапленым гитом. Единственная разница, которую за весь день удалось услышать - появляется необходимость чтобы git сервер был рабочим в довесок к рабочему docker registry.

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

хоть пипом деплойте или побайтово, я же написал, дело хозяйское

самый главный вопрос, зачем это? потому что можно? бгг

как релизы трекать будете? я ещё согласен на тег или версию, но разгребать на проде коммиты по ша - разгребайте, дело хозяйское

самый главный вопрос, зачем это? потому что можно? бгг

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

Это всё хорошо, пока это один человек. Но это плохо скейлится. + давать куберу доступ к гиту это тоже не супер. В какой-то момент там был только password based auth и пароль протекал в манифест. Возможно от вашего подхода есть ускорение воркфлоу, но скейлить это тяжело. У меня был деплой из гита на 300 серверов, но пришлось поднимать зеркала, ибо один гит-сервер загибался. http get != git pull

Мы в итоге выпилили деплой через git. Всетаки git это не про деплои - долго и дорого выходит. Артефакты через s3 гораздо быстрее разливаются. А при своевременном клинапе ваще копейки стоит.

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

@zhukva так @poselivanov на митапах рассказывает как мы живём

в примере gke: gitlab + gitlab-ci + k8s Сборка образов в ci и push их в gcr, после этого update deployment в k8s на новый образ в pod'e. из такого простенького.

вопрос. Если создавать configmap из файла командой, то можно как то заапдейтить configmap измений этот файл не пересоздавая configmap?

kubectl create configmap my-config —from-file=path/to/bar -o json |kubectl apply -f -

может —dry-run еще добавить по вкусу

коллеги, кто-нибудь из вас скрещивал traefik, tls+SNI и letsencrypt? или я первый буду?

kubectl create configmap my-config —from-file=path/to/bar -o json |kubectl apply -f -

Благодарю ?

@not_logan я на днях собираюсь этим заняться

в примере gke: gitlab + gitlab-ci + k8s Сборка образов в ci и push их в gcr, после этого update deployment в k8s на новый образ в pod'e. из такого простенького.

спасибо. а использовать свой приватный регистр возможно?

https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

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

так у вас собственная установка гитлаба или пользуетесь их сервисом? если собственная, интересна схема взаимодействия с кубом)

@not_logan я на днях собираюсь этим заняться

значит - синхронно будем грабли собирать, ок

без проблем =)

так у вас собственная установка гитлаба или пользуетесь их сервисом? если собственная, интересна схема взаимодействия с кубом)

собственная, просто на раннере настроен gcloud sdk чтобы можно было управлять k8s командами с раннера

а всем разруливает gitlab-ci

т.е., пристите за нубство, гитлаб установлен рядом с к8s, а не в нём самом?

да, гитлаб там же в гугле, но на отдельной vm

а вообще кто-нибудь устанавливал cicd непосредственно в куб?

да. геррит в поде дженкинс тоже. дженкинс через плагин спавнит поды тестит гасит

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

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

там это даже не бета

гитлаб неплох за неимением альтернатив.

гитлаб неплох за неимением альтернатив.

гитлаб отвратителен, просто лучше ничего нет

можно ещё посмотреть на gitblit

Gerrit, если надо кодревью, но он ужасный просто в плане интерфейса

гитлаб отвратителен, просто лучше ничего нет

чем же он отвратителен?

чем же он отвратителен?

- тем, как он написан - конфигом CI системы - желанием все делать самостоятельно (кто-нибудь научил его грузить артифакты отдельно без ухищрений?) - работой с БД - установщиком, который возит с собой ВСЕ (странно, что операционку не возит) - большим количеством дырок в безопасности

> установщиком, который возит с собой ВСЕ (странно, что операционку не возит)

ERROR: S client not available

ставлю в докере - возит ?

centos, надеюсь?

понятия не имею, не смотрел. Вангую, что убунта какая-нибудь.

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

если честно, все CI-системы, конфигурирующиеся единым yaml-файлом в корне, должны сгореть

потому что проверка, релиз, выкатка - это разные джобы

- тем, как он написан - конфигом CI системы - желанием все делать самостоятельно (кто-нибудь научил его грузить артифакты отдельно без ухищрений?) - работой с БД - установщиком, который возит с собой ВСЕ (странно, что операционку не возит) - большим количеством дырок в безопасности

список вообще мутный, как написан имхо вообще фиолетово - работу свою выполняет, БД причём тут? дырки фиксят, гитлаб один из немногих кто релизит раз в неделю

потому что проверка, релиз, выкатка - это разные джобы

что мешает в одном конфиге это описывать?

то, что конфиг применяется во время выполнения джобы

поэтому конфигурировать ее до начала выполнения он не может

такой вот каламбур

блин, я наверное тупой и ничего не понимаю (

поэтому конфигурировать ее до начала выполнения он не может

А зачем это может понадобиться? Набор джобов и их поведение от дня к недели не меняется

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

поэтому конфигурировать ее до начала выполнения он не может

почему?

Потому что до начала запуска прогона и чтения проекта из репозитория конфигурации не существует

ну так пусть прочитает первым делом после чекаута и самосконфигурируется

Курица и яйцо

Джоба может быть найдена после чекаута

Чекаут может быть частью джобы

Одно из этих двух должно быть первым

Одно из этих двух должно быть первым

не означает ли это что оба подхода равнозначны? )

можно и чтото среднее: зарание прописаные фазы, но что конкретно происходит внутри фазы берется из конфига

Какие два подхода?

Я объясняю, почему подход с одним файлом а репе нежизнеспособен

один: если честно, все CI-системы, конфигурирующиеся единым yaml-файлом в корне, должны сгореть второй: все что не "один"

Нет, не равнозначны

Один не вызывает бесконечную боль

Ребят в каком случае под периодически может становится "Ready: false"

причем у меня пачка однотипных подов и у всех в одинаковое время становится ready: false