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

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

во-первых, IT automation это общее предназначение. Во вторых continuous delivery.

Сontnuous delivery - "непрерывная доставка".

привет, кто-нибудь юзает динамического jenkins слева? типа этого - https://hub.docker.com/r/jenkinsci/slave/ я правильно ж понимаю, что это просто образ с дженкинс слейвом, который автоматически коннектится к моему мастеру и на основе этого образа я должен строить образ уже с моим приложением и всякими тестами итд?

непрерывная доставка у вас билды из воздуха берёт?

непрерывная доставка у вас билды из воздуха берёт?

у нас билды собирает дженкинс ?))))) ещё для этого есть (по вкусу!) Bamboo, GitLab, TeamCity, younameit.

я с вами частично согласен, ansible для сборки не свосем подходящий инструмент.

мне в наследство досталась сборка на ansible, надеюсь избавится от неё

привет, кто-нибудь юзает динамического jenkins слева? типа этого - https://hub.docker.com/r/jenkinsci/slave/ я правильно ж понимаю, что это просто образ с дженкинс слейвом, который автоматически коннектится к моему мастеру и на основе этого образа я должен строить образ уже с моим приложением и всякими тестами итд?

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

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

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

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

у него физических хостов меньше, чем нужно окружений для сборки

я так думаю

либо хочется унификации и взаимозаменяемости

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

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

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

не принципиально. systemd-nspawn - все достоинства контейнеров без недостатков доскера.

Ставишь на хост докер и билдишь все в нем

не принципиально. systemd-nspawn - все достоинства контейнеров без недостатков доскера.

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

Ставишь на хост докер и билдишь все в нем

+1

да)

ну тогда и systemd подойдёт

только подшаманить надо не много)

не, тогда не подойдёт

не принципиально. systemd-nspawn - все достоинства контейнеров без недостатков доскера.

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

systemd - вроде как не no name )

чуть чуть так)

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

systemd - ноунеймовый инструмент? O_o лол

ну nspawn я просто не слышал

containerd

просто с докером больше народу знакомо и под CI тулзы обычно есть модуль для сборки в докере

дело вкуса

вот когда доскер-демон колом встанет вместе с мешком контейнеров - приходите, про systemd-nspawn расскажу.

дело вкуса

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

вот когда доскер-демон колом встанет вместе с мешком контейнеров - приходите, про systemd-nspawn расскажу.

а до тех пор это будет premature optimization

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

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

речь про конкретно эту фичу в systemd и распространённость её использования для этого use case

с распространённостью самого systemd спорить не стану

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

ну так. не хочешь, не ешь :)

а во вторых, тебе посоветовали два более приемлемых решения, чем регистрация докер контейнера как jenkins slave

речь про конкретно эту фичу в systemd и распространённость её использования для этого use case

это НЕ фича системд. это просто УЖЕ входящий в комплект свежеустановленной сиcтемы инструмент для управления УЖЕ существующими функциями: приватная сеть в нескольких режимах, автопроброс портов, запуск контейнера как сервиса (systemctl start .....) - вот это вот всё "искаропки". я уж не говорю о автомагической поддержке разрешения имён контейнеров как хостов.

это НЕ фича системд. это просто УЖЕ входящий в комплект свежеустановленной сиcтемы инструмент для управления УЖЕ существующими функциями: приватная сеть в нескольких режимах, автопроброс портов, запуск контейнера как сервиса (systemctl start .....) - вот это вот всё "искаропки". я уж не говорю о автомагической поддержке разрешения имён контейнеров как хостов.

на чем сидите?

а во вторых, тебе посоветовали два более приемлемых решения, чем регистрация докер контейнера как jenkins slave

я это решение в книге continuous integration with docker and jenkins нашел, мне показалось оно вполне годным

да я понял. Вы же не спорите с тем, что jenkins+build in docker выдаст больше результатов в гугле чем jenkins + build with systemd-nspawn

os

я это решение в книге continuous integration with docker and jenkins нашел, мне показалось оно вполне годным

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

я бы поднял slave...

не в докере, сборку можешь делать в контейнерах

да я понял. Вы же не спорите с тем, что jenkins+build in docker выдаст больше результатов в гугле чем jenkins + build with systemd-nspawn

потому что правильный запрос jenkins slave run container

with docker container

и все

и по крону чистить

потому что правильный запрос jenkins slave run container

с каким утверждением вы спорите? Сборка в докер контейнере более распространена, чем в systemd контейнере.

не вижу там systemd

с каким утверждением вы спорите? Сборка в докер контейнере более распространена, чем в systemd контейнере.

да ради яиц. хотите возюкаться с доскером - пжалста.

да что с ним возюкаться то? осиливается с 0 за 1-2 недели. с вашими альтернативами будешь дрючиться, пытаясь нагуглить что-то, что ещё никто не обсуждал(либо обсуждал на форуме арчлинукса)

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

любое отклонение от мейнстрима наказуемо :)

но я оставляю за собой право прийти в этот чатик и поспрашивать про systemd контейнеры, мало ли

и тебе никто не поможет, кроме Сергея)

и тебе никто не поможет, кроме Сергея)

man поможет так-то

ладно, я утрирую же

https://www.bestchange.ru/?p=706111 народ кому не трудно просто надо перейти по ссылке, подождать чтоб сайт погрузился и всё, никакого вреда вашему устройству не наносит, а мне поможет:)

tsung, jmeter, ab, siege?

https://www.bestchange.ru/?p=706111 народ кому не трудно просто надо перейти по ссылке, подождать чтоб сайт погрузился и всё, никакого вреда вашему устройству не наносит, а мне поможет:)

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

Hi! Господа, может кто в курсе, как в jenkins pipeline вытянуть файлы из отработавшей другой джобы, которая была вызвана через build job. Нужны не артифакты, которые можно достать через copyArtifacts, а немного другие файлы.

Доступы к чужим workspace у тебя не получится просто получить. Тебе в обе таски придётся юзать ws('/absolute/path/to/work/space').

подскажите, мне нужно создать апи которое при запросе создает энное кол-во ec2 micro инстансов с предустановленным софтом (socks5 прокси сервер), и затем, также по запросу удаляет (или просто стопает?) все эти инстансы. Я нуб в AWS (но не в linux servers), но может подскажете в какую сторону сразу смотреть чтобы сделать подобное?

подскажите, мне нужно создать апи которое при запросе создает энное кол-во ec2 micro инстансов с предустановленным софтом (socks5 прокси сервер), и затем, также по запросу удаляет (или просто стопает?) все эти инстансы. Я нуб в AWS (но не в linux servers), но может подскажете в какую сторону сразу смотреть чтобы сделать подобное?

Ansible

terraform

terraform

Однозначно

спасибо, буду курить мануалы по terraform

terraform+bash и или система управления конфигурациями(ansible)

зачем баш если есть ансибля?

зачем баш если есть ансибля?

зачем ansible если достаточно bash?

?

?

есть задачи в которых достаточно bash`a

есть задачи в которых достаточно bash`a

Нафиг, ансиблом один раз написал, ещё 10 раз поюзал

Нафиг, ансиблом один раз написал, ещё 10 раз поюзал

ну да, баш же нельзя 10 раз поюзать

ну да, баш же нельзя 10 раз поюзать

У меня есть директория fuck.sh, и я в неё боюсь заходить, ибо там простынки по 1-2к строк на любимом баше. И я хз, что они делают спустя год.

А с ямлом проще, я ридми к роли всегда пишу

+ ко всему терраформ умеет выдавать динамический инвентори для ансибла на основании tfstate

https://alex.dzyoba.com/blog/terraform-ansible/

ну да, баш же нельзя 10 раз поюзать

Конечно нет, он на 1 раз, а потом забываешь что оно делает

У меня есть директория fuck.sh, и я в неё боюсь заходить, ибо там простынки по 1-2к строк на любимом баше. И я хз, что они делают спустя год.

баш становится намного более читаемым если хотя бы использовать элементарные функции и оборачивать в них куски кода. К примеру как здесь https://github.com/tmux-plugins/tpm/blob/master/scripts/install_plugins.sh

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

баш становится намного более читаемым если хотя бы использовать элементарные функции и оборачивать в них куски кода. К примеру как здесь https://github.com/tmux-plugins/tpm/blob/master/scripts/install_plugins.sh

хороший код

баш хороший инструмент, питон хороший инструмент, но для IaC лучшая связка это TF + Ansible.

баш становится намного более читаемым если хотя бы использовать элементарные функции и оборачивать в них куски кода. К примеру как здесь https://github.com/tmux-plugins/tpm/blob/master/scripts/install_plugins.sh

правда в баше вроде как 2 пробела синтаксис общепризнанный, ну это так