ну самое первое, это нужно собрать имедж. Для этого в репозиторий с проектом(сервисом) можно положить Dockerfile, Makefile, т.е. все необходимое для сборки. На этом же этапе можно делать и тесты, вплоть до интеграционных. Т.е. подняли необходимые сайд-контейнеры, развернули структуру базы, прогнали тесты, если все ок - тогда собранный имедж уже пушим в реджистри. (вариантов много, от своего до docherhub и bintray). Собирать тоже можно любым CI, хоть дженкинсом, хоть travis-ci. Здесь имхо, главное чтобы сборка была описана в Makefile, тогда переход между любой системой CI достаточно безболезнен. После того как у нас где то есть имедж в реджистри, его можно деплоить в различные среды. Здесь как удобно, кто-то использует helm, для самых простых кейсов и kubectl напрямую подойдет. У меня исторически используется ansible, поэтому в репозитории лежат темплейты сервисов. деплой через ансибл - это просто вызов плейбука в духе ansible-playbook -i environments/dev echoserver.yml Но если вы малознакомы с ансиблом, я бы посоветовал начать просто с plain kubectl манифестов, дабы не забивать мозг лишним.

Почему вы берете именно мейкфайл? Почему бы не написать просто shell скрипт? В моем понимании мейкфайл нужен когда у вас предусмотрено много разных действий и между ними существуют зависимости

Блин, ну вроде все подключил, дженкинс вроде кубер видит. Но пр ипопытке собрать проект: "ERROR: Node is not a Kubernetes node: " Я так понимаю с нодой кубера он все же не подружился( Сталкивался кто?

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

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

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

да с теми вопросами я уже разобрался. меня сейчас волнует как деплоить в сам кубер. Вот я собрал приложение в поде, сейчас я так понимаю мне надо сделать образ и потом выкинуть его на реджистри, а дальше - уже сдеплоить. И вот именно последние 3 шага(образ, реджистри, деплой) у меня пока проблемные. Собрать я так понимаю можно прилинковав в контейнер докер и с него собрать образ, спушить скорее всего тоже достаточно просто. А вот как сдеплоить - у меня пока никаких мыслей нет(

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

пока вам непонятна вся цепочка, старайтесь не использовать лишние компоненты (KISS). В вашем случае jenkins (пока) вообще не нужен. Собрать и упаковать приложение в докер контейнер можно даже локально. И также локально в докере запустить, убедиться что все работает. Дальше (тоже локально) можно запушить его в реджистри. Зарегистриуйте себе безоплатный аккаунт на докерхаб и в него запушите. После этого задеплоить его в кубере можно даже без каких-либо манифестов. Просто через kubectl run --image=mydockerhub/my-awesome-app my-awesome-app --port=8080

нашелся такой проект, по inotify отслеживает что логи ротировались и отправлет сигнал процессу https://github.com/occrp/watchful-nginx на nginx & logrotate в разных контейнерах ориентирован. но идею можно адаптировать и для отслеживания состояния конфигов и релода. общий pid namespace пригодился бы.

А что конкретно нужно - я понимаю. И даже примерно понимаю что зачем и почему. Но как сделать некоторые из необходимых шагов - тут да, путаница

А что конкретно нужно - я понимаю. И даже примерно понимаю что зачем и почему. Но как сделать некоторые из необходимых шагов - тут да, путаница

я же вам и говорю, чтобы не было путаницы нужно сначала руками сделать, разобраться, а потом настроить CI и полную схему для остальных ваших 100500 контейнеров. Так сказать сделать прототип.

Ты немного путаешь понятия, сделать контейнер, сделать под и сделать деплоймент.

@Visteras что ты хочешь делать дженкинсом?

заметил в helm chart в prometheus интересный контейнер в деплойменте https://github.com/jimmidyson/configmap-reload который релодит prometheus когда изменяется конфигмап вызовом url. я так понимаю pid namespace в pod не шарится и нет возможности отправлять сигнал из одного контейнера в другой. так хотелось бы просто релодить приложение при изменении конфигурации, вместо того чтобы тригерить rollout update.

Шарятся, но,выключили по дефолту ибо овер дофига контейнеров хотят быть pid1. Можно включить обратно флагом в kubelet

какие есть костыли для обхода? если приложение ждет сигнал для релода конфигурации

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

1) берем из репы сам проект 2) тянем зависимости 3) выполняем(в моем случае go build -i -o ... ) 4) перетягиваем полученный файл в другую директорию и там уже его надо дальше упаковывать в образ докером и пушить в реджистри

Посмотри в сторону helm для деплоя и обновления, 4й пункт сведешь к одной строке "helm upgrade $PROJECT_NAME".

Шарятся, но,выключили по дефолту ибо овер дофига контейнеров хотят быть pid1. Можно включить обратно флагом в kubelet

действительно, в kubelet опция: --docker-disable-shared-pid The Container Runtime Interface (CRI) defaults to using a shared PID namespace for containers in a pod when running with Docker 1.13.1 or higher. Setting this flag reverts to the previous behavior of isolated PID namespaces. This ability will be removed in a future Kubernetes release. (default true) только нафига она глобальная. или на уровне подов нужно в spec добавлять чтото?

Зато 100500 ответов позакрывали, мол все починено. Я сдался и херачу helm template | kubectl apply -f - —prune

Вот не знаю. Секунду назад думал что гдабальная,,задумался и сейчас не уверен :) надо в reference pod spec глянуть

Ну вот сборка да, а тестирование куда пропало?

Да, там у тебя еще есть только go build... а контейнер ты будешь собирать?

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

Погоди, ты торопишься, сборка контейнера, что в себя включает?

какие есть костыли для обхода? если приложение ждет сигнал для релода конфигурации

Недавно сломали "ручной" rollback (когда просто деплоим предыдущую версию) заразы, при этом чиня фундаментальный баг дебильной заплаткой. И баг не починили и rollback сломали.

положить в образ готовое приложение и конфиг

Дальше запускает Dockerfile так?