Но... конфиг для кубера там тоже будет?

Пока это изучи, многое прояснится в ходе.

У тебя примерно такой пайплайн получится: 1. сборка go 2. публикация артефактов 3. запуск контейнера дженкинсом, с этими артефактами, тестирование 4. пуш Dockerfile в git, 5. сборка Docker образа. Дальше уже другой пайплайн стартует.

Ну можешь в один объеденить, но лучше чтобы через контроль версий проходило.

https://www.pluralsight.com/courses/docker-ansible-continuous-delivery может помочь

а зачем "5. пуш Dockerfile в git" ?

а зачем "5. пуш Dockerfile в git" ?

Перепутал шаги (-:

Ну то есть сперва dockerfile пушится в гит, и только увидев это, дженкинс дальше идет собирать сам образ.

ну как бы докерфайл один раз написали и он не меняется. А меняется код. 12 факторов же

Если версионирование контейнеров не идет, или конфиги никогда не меняются, то можно и так. В зависимости от ситуации, это уже кто как.

стоп, у нас уже есть репозиторий, в нем код, Dockerfile, (Jenkinsfile|.travis.yml|Makefile) и т.д. при пуше каких-либо изменений в репу, стартует CI\CD. Запускаются сборка, тесты, упаковка артифакта в докер имедж, тесты, пуш в реджистри, (и опционально деплой в различные среды). Версия докеримеджа может быть привязана к git tag, branch name, commit hash и т.д. Мне лично git tag нравится.

Вообще образы хорошо бы версионировать — в любой момент потом можно будет вернуться. Просто дженкинс может вешать тег с версией, после интеграционного тестирования и перевешивать тег latest.

Тогда на образ потом тоже тег ляжет и кубик сам тебе latest поднимет, прямо не отходя от кассы.

это все понятно. Не понятно для чего пушить что-либо в репозиторий в процессе сборки.

Ну да, я не так выразился, надо было написать: "вешает метку"

имелся в виду docker tag ?

У тебя примерно такой пайплайн получится: 1. сборка go 2. публикация артефактов 3. запуск контейнера дженкинсом, с этими артефактами, тестирование 4. пуш Dockerfile в git, 5. сборка Docker образа. Дальше уже другой пайплайн стартует.

Эм... вообще у меня все это дело через дженкинс идет. Т.е. в шаге 1 я беру из репы код потом я его собираю дальше я тестирую что получилось. потом нужно уже собрать образ дальше - запушить его в реджистри и в конце - уже деплоим в кубере И все это в одном поде которые стартует от дженкинса

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

Хорошо, а как тогда можно убрать последний шаг? ведь куберу надо сообщить что версия появилась новая?

Хорошо, а как тогда можно убрать последний шаг? ведь куберу надо сообщить что версия появилась новая?

У тебя тег latest для этого есть

я думал что дженкинс должен просто выполнить что-то типа kubectl apply -f deployment.yaml где прописан будет нужный образ из реджистри. и всё. дальше уже сам кубер все доделает

И staging

ну пусть там будет latest, но kubectl apply все равно надо сделать?

latest тэг при деплое путь к беде

Там rc сам должен увидеть, что тег поменялся и все сделать сам.

как то лучше фиксировать, по git commit hash \ git tag

latest тэг при деплое путь к беде

Ну prod или еще как

latest на проде конечно не надо...

ну понятно что там не именно latest, но я не понимаюб как сказать куберу что пора проверять что там что-то обновилось в образе

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

ну понятно что там не именно latest, но я не понимаюб как сказать куберу что пора проверять что там что-то обновилось в образе

Это replication controller сам увидит.

Это replication controller сам увидит.

откуда? он что, дергается постоянно реджистри на новые версии?

откуда? он что, дергается постоянно реджистри на новые версии?

Он постоянно проверяет теги, да.

Он постоянно проверяет теги, да.

это с чего вдруг?

я вообще не уверен что если не форсить always pull политику для имейджей применение latest поверх latest хоть что то стригерит

в общем поэтому я и говорю что latest или prod или еще что то там фиксированное в качестве тэга для docker image плохо. нужно отличать один деплой от другого. если по git tag - то пускай будет prod-<date> какой нить, чтобы все явно было

хотя бы по такому тегу можно понять однозначно какой именно код у тебя в имейдже

Тебе что тегов жалко, вешай хоть десять разных

Ты не меняешь теги в данном случае, а снимешь тег, с одного образа и вешаешь его на другой. RC это точно увидит.

кубер не сможет понять, что тэг обновился. Где-то в доке это говорится (не использовать latest). Мой процесс: у меня есть установка с нуля (деплой манифестов) и на каждый CI\CD я просто делаю kubectl set image. Не понимаю что вы тут за велосипеды изобретаете. Тэги на образы пока делаю коротышами от SHA-коммита.

я вообще не уверен что если не форсить always pull политику для имейджей применение latest поверх latest хоть что то стригерит

Да, верно, только так. + поду нужно удалить чтобы триггер на пулл сработал

кубер не сможет понять, что тэг обновился. Где-то в доке это говорится (не использовать latest). Мой процесс: у меня есть установка с нуля (деплой манифестов) и на каждый CI\CD я просто делаю kubectl set image. Не понимаю что вы тут за велосипеды изобретаете. Тэги на образы пока делаю коротышами от SHA-коммита.

Вооот! И для этого надо иметь возможность что бы агент дженкинса мог сказать kubectl ..., так?

Да, верно, только так. + поду нужно удалить чтобы триггер на пулл сработал

не нужно, у меня само обновляет если я обновил стаейтфул. думаю деплоймент так же может

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

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

значит надо обновить деплоймент, так?

т.е. что-то вроде kubectl apply -f deployment.yaml

именно так

если тэг имиджа не меняется, то обновлением деплоймента ничего не произойдёт

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

Как добавить kubectl в контейнер агента дженкинса в котором все собирается?

измени имидж контейнера с агентом дженкинса, установи туда kubectl

Как добавить kubectl в контейнер агента дженкинса в котором все собирается?

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

Как добавить kubectl в контейнер агента дженкинса в котором все собирается?

с дженкинсом не сталкивался, слишком тяжёлый он. использую докер-контейнер для деплоя (alpine + kubectl)

Но это не то, что тебе нужно.

Но это не то, что тебе нужно.

а что мне нужно?

Ты просто стартуешь в поде jenkins-слейв, а это не то...

значит надо обновить деплоймент, так?

варианты: 1) политика пулла Always, использовать статический тэг (latest), удалением поды вызывается репулл. 2) использовать тэги на каждый деплой. kubectl set image

Зачем тебе его запускать, я никак не могу понять?

варианты: 1) политика пулла Always, использовать статический тэг (latest), удалением поды вызывается репулл. 2) использовать тэги на каждый деплой. kubectl set image

в любом случае надо иметь возможность автоматически запускать kubectl

Зачем тебе его запускать, я никак не могу понять?

кого?

в любом случае надо иметь возможность автоматически запускать kubectl

и в чём проблема-то?)

кого?

jenkins-slave

https://pastebin.com/c9GHGTyF Сейчас pipeline выглядит так

Не самый лучший вариант но все понятно

https://pastebin.com/c9GHGTyF Сейчас pipeline выглядит так

с постоянным go get можно и инфаркт получить, особенно со старыми проектами. Используй менеджер зависимостей

с постоянным go get можно и инфаркт получить, особенно со старыми проектами. Используй менеджер зависимостей

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

с постоянным go get можно и инфаркт получить, особенно со старыми проектами. Используй менеджер зависимостей

Это не относится к делу, но да.

go build -i -o auth && mv auth /go/bin/auth легко превращается в go install

go build -i -o auth && mv auth /go/bin/auth легко превращается в go install

это тоже понятно. а вот что дальше должно быть? в последних двух шагах?

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

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

говорю же, кури docker-build-step а купик прямо так дергай.

это тоже понятно. а вот что дальше должно быть? в последних двух шагах?

docker build -t image:git-sha1 . docker push image:git-sha1 kubectl set image container-name=image:git-sha1

говорю же, кури docker-build-step а купик прямо так дергай.

как его "прямо так дернуть"? docker-build-step я гляну, сейчас просто не имею возможности. а вот как кубцтл получить при сборке - я не понимаю. там же нужен конфиг, его откуда брать?

в gitlab-ci можно запихнуть сертификат и конфиг в переменные окружения, не знаю можно ли так в дженкинс. Либо сделать готовый имидж с конфигом и авторизацией

Хм.. вообще - умеет. В общем буду думать. Конфигов же может быть несколько? Я про то что я могу сгенерить новый и использовать его? И потом если что просто убить?

как его "прямо так дернуть"? docker-build-step я гляну, сейчас просто не имею возможности. а вот как кубцтл получить при сборке - я не понимаю. там же нужен конфиг, его откуда брать?

https://plugins.jenkins.io/kubernetes-cd вот так "прямо так"

https://plugins.jenkins.io/kubernetes а ты, видимо, вот это смотришь, вот это не то (-:

Да, действительно возможно именно так. Вечером обязательно проверю

https://plugins.jenkins.io/kubernetes-cd вот так "прямо так"

То что вы советуете работает если item не pipeline а "свободная конфигурация". в pipeline его просто нет

так что опять вернулись к чему было - не понятно как это сделать(