дичь какая-то)

почему дичь?

клон чего? Код разрабов? И они держат у себя ключ в гите?)

единственное, что я бы собирал контейнер с уже ansible плейбукой

и подкладывал бы только inventory

единственное, что я бы собирал контейнер с уже ansible плейбукой

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

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

Там не один плейбук, а под каждый репозиторий + инфраструктурные

и? будет много контейнеров

либо один с кучей репозиториев.

Один образ с кучей репозиториев, которые ещё и изменяются

И например разработчик переменную изменил, он пересобирает этот образ?

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

ключ в переменеую окружения + ссх агент https://docs.gitlab.com/ee/ci/ssh_keys/ Зачем ключ репозитории хранить?

разработчик изменяет переменную, и делает git push, дальше работает CI/CD, которые тестируют изменения, и если они валидны выкадвыает докер образ с :stable

ключ в переменеую окружения + ссх агент https://docs.gitlab.com/ee/ci/ssh_keys/ Зачем ключ репозитории хранить?

Ещё раз, не сканает, потому что например в инфраструктурном проекте для окружения production будет один ключ для уже используемого сервера и дугой для только раскатанного инстанса aws

Потому что там на сервере деплойного пользователя ещё нет

основная цель этих телодвижений - это деливерить контейнер (рабочее окружение) который протестирован, и ready to use, а не отдельные плейбуки. не отдельные докер окружения где они могут запускаться, и не отдельные инвентори в которых вомзонжо есть конфлиткты в структуре и то как эту структуру использует плейбука

основная цель этих телодвижений - это деливерить контейнер (рабочее окружение) который протестирован, и ready to use, а не отдельные плейбуки. не отдельные докер окружения где они могут запускаться, и не отдельные инвентори в которых вомзонжо есть конфлиткты в структуре и то как эту структуру использует плейбука

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

основная цель этих телодвижений - это деливерить контейнер (рабочее окружение) который протестирован, и ready to use, а не отдельные плейбуки. не отдельные докер окружения где они могут запускаться, и не отдельные инвентори в которых вомзонжо есть конфлиткты в структуре и то как эту структуру использует плейбука

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

б-г в помощь

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

На выходе вообще запуск контейнера/ов с кодом на инстансе. Есть кучка проектов с сервисами и инфраструктурных проектов, при чем плейбуки в них могут быть и не связаны между собой никак. В текущей схеме условно говоря я могу отдать какой-то сервис в другой проект при чем и вместе с тем, как он и билдится и деплоится, этот процесс на другие сервисы может быть вообще не завязан (а в идеале и не должен, если у меня есть 20 сервисов например, то каждый должен разворачиваться вполне себе независимо). А в случае с образом, получается, что я как минимум билд и деплой всех сервисов должен хранить вместе

Хотя из общего у них собственно только роли, которые лежат отдельно

кул стори.

я так понял, исторически сложилось?

Подход разработки и доставки кода

Все в IaC

? давайте поговорим с какими проблемами вы сталкиваетесь ?

с таким подходом

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

В другой конторе работал как раз с подходом деплой отдельно, код отдельно

И своих подводных камней тоже хватало

очень рад за вас

И например разработчик переменную изменил, он пересобирает этот образ?

видимо я вот этот ваш пассаж не правильно понял

вы какую переменную имели в виду, которая привязана к плейбуке/роли или к инветори?

Может быть и так и так

Как пример, изменил существующую переменную - изменил инвентори, добавил новую - изменил шаблон

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

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

В group vars лежат ещё например переменные для .env, которые как раз таки при одинаковом шаблоне отличаются для каждого окружения

т.е. у вас inventory окружений лежат рядом с плейбуками в одном репозитории?

Да

спасибо, теперь все стало понятно, вопросов боьше нет

И при подходе gitlab ci оно должно быть именно так, остальное будет криво

Я уже пробовал)

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

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

какие неудобства?

Ну как пример копипаста в разных проектах

Я использую один aws аккаунт, а реквизиты прописаны одни и те же в 5 местах

а почему не в одном?

Я использую один aws аккаунт, а реквизиты прописаны одни и те же в 5 местах

В одном и том же, но в каждом проекте с кодом

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

у меня это решено так: 1. есть контейнер с ansible и нужными модулями anbible:stable 2. от него наследуются контейнеры с описанием окружения FROM ansible:stable, назовем его env1:stable 3. от контейнера env1:stable наследуются все контейнеры которые будут запущены против окружения env1 FROM env1:stable

какие минусы вы видите в таком подходе?

Эти контейнеры служат для деплоя?

из пункта 3 - да

все остаьные - нет

Как минимум 2 минуса 1 - я не могу прочитать в одном месте все, что мне нужно для развёртывания (к примеру я только пришёл к вам и не знаю что в каком образе и как это доставляется в итоге на сервер) 2 - я не могу развернуть ПО без этих образов, к примеру к себе на виртуалку. А я как разработчик хочу поднять все окружение из своих веток и посмотреть как это работает и на ходу что-то изменять. Ну или банально у меня нет доступа к registry, а такое уже вполне случалось как раз на предыдущем месте благодаря ркн

1. почему не можете прочитать? запустим контейнер из п.3 вы получите все что нужно (плейбуки, python модули, inventory) 2. тоже не понятно, вы можете запустить контейнер, изменять в нем плейбуки и далее комитить изменения. вопрос с registry совсем не понятен, что мешает хранить в нескольких?

А, ну и ещё я что-то меняю в деплое сервисов, например всем пригорело с php переехать на go. 1 сервис я уже поменял, остальные нет. Всё в окружении production. Для каждого сервиса нужно сначала менять код, а потом пересобирать образ? Причём может быть ещё придётся и вариативность продумывать, сейчас ведь какая-то часть окружения деплоится совсем по-другому и надо отслеживать, чтобы эти изменения были совместимы с сервисами которые деплоятся по старому

этим и занимается CI, из примера выше, у нас остаются контейнеры ansible:stable env1:stable от них наследуются php web:php, и web:go, но это уже вкусовщина

1. почему не можете прочитать? запустим контейнер из п.3 вы получите все что нужно (плейбуки, python модули, inventory) 2. тоже не понятно, вы можете запустить контейнер, изменять в нем плейбуки и далее комитить изменения. вопрос с registry совсем не понятен, что мешает хранить в нескольких?

1. А где это все описано? Только в фс контейнера? Если да, то это крайне неудобно, репозиторий гораздо лучше. И код нередко важен для понимания работы или сборки сервиса, значит я смотрю то в контейнер, то в git 2. Мне необходимы лишние действия. Вместо того, чтобы мне просто склонировать код определённой ветки и запустить плейбук мне ещё дополнительно нужно качать контейнер под определённое окружение и думать как это разворачивается. Кстати подтягивается код с фс? Я например сделал изменения в коде, мне нужно пересобрать код и залить на свой же локалхост например. 3. Например нам не повезло и все наши registry забанил ркн. Как быстро восстановить эти образы и куда-то залить так, чтобы деплой не вставал?

этим и занимается CI, из примера выше, у нас остаются контейнеры ansible:stable env1:stable от них наследуются php web:php, и web:go, но это уже вкусовщина

А потом у нас в окружениях рано или поздно появляются несовместимые изменения, хотя бы просто в процессе изменения деплоя и мы имеем php:v2 php:v3 go:v2 go:v5 и уже непонятно что откуда наследуется и зачем их столько

ПО то разное, которое разворачивается в идеале одним контейнером

И билдится

ERROR: S client not available

Банально, нода, 3 проекта - 3 версии

Один проект остался as is и там нода 8 и всегда останется

я к сожалению потерял суть этого диалога, навсякий случай отвечу: 1. есть две точки входа, /etc/ansible и /opt/playbook 2. вы так же можете делать git clone изменения кода и запускать котнейрех с подмаунченым volume: docker run --rm -it -v`pwd`:/opt/playbook ... , в /opt/playbook будет прокинута директория с хост системы 3. вы не знаете как решить эту проблему? еще раз, иерархия наследования трехуровневая, ansible, окружения, playbook-роли

Другие развиваются и версия обновляется

прощу прощения, я пожалуй сольюсь из этой бесседы

Хорошо, тоже спать уже надо

Всем привет. Не подскажите с чем может быть связано? TASK [Gathering Facts] ********************************************************* fatal: [VV10888-TEST]: UNREACHABLE! => {"changed": false, "msg": "argument must be an int, or have a fileno() method.", "unreachable": true} Гугл ничего не подсказал

Гадать где ошибка без кода такое себе занятие

уже разобрался, спасибо

уже разобрался, спасибо

и че было?

Добры день. Как Вы решаете задачи, если нет специального модуля? У меня из одной строки, генерирующей список пользователей на bash: users=($( for NAME in `cut -d: -f1 /etc/passwd`; do uid=`id -u $NAME` ; if [ $uid -ge 1000 ]; then echo $NAME ; fi; done )) echo ${users[@]} получилось 4 таска: https://pastebin.com/bs6MRcVZ Есть идеи, как сделать лучше?

Добры день. Как Вы решаете задачи, если нет специального модуля? У меня из одной строки, генерирующей список пользователей на bash: users=($( for NAME in `cut -d: -f1 /etc/passwd`; do uid=`id -u $NAME` ; if [ $uid -ge 1000 ]; then echo $NAME ; fi; done )) echo ${users[@]} получилось 4 таска: https://pastebin.com/bs6MRcVZ Есть идеи, как сделать лучше?

Для решения задачи понадобится pastebin или что-то подобное как минимум ?

Для решения задачи понадобится pastebin или что-то подобное как минимум ?

Зато можно накопировать и запустить сразу)

"дешевле" модуль напитонить)

Зато можно накопировать и запустить сразу)

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

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

Я поправил, спасибо.

Подскажите, какой-нибудь "мусор" остаётся после отработки playbook'а, который может привести к каким-нибудь недобствам? Retry файлы отключены. Может Ansible ещё что-то куда-то писать, например, в скрытые каталоги?

Подскажите, какой-нибудь "мусор" остаётся после отработки playbook'а, который может привести к каким-нибудь недобствам? Retry файлы отключены. Может Ansible ещё что-то куда-то писать, например, в скрытые каталоги?

на целевом хосте временные файлы могут остаться

Я поправил, спасибо.

Замечательно. Как выглядит изначальная задача?

Замечательно. Как выглядит изначальная задача?

Поменять политику устаревания паролей списку пользователей

Прошу извинить, мой парсер русского вывалился с ошибкой - не могу понять смысл фразы.

на целевом хосте временные файлы могут остаться

а на хосте с самим ансиблом может что-то оставаться?

Прошу извинить, мой парсер русского вывалился с ошибкой - не могу понять смысл фразы.

Запустить это chage -m 1 -M 90 -W 7 -I 10 $USERNAME

Прошу извинить, мой парсер русского вывалился с ошибкой - не могу понять смысл фразы.

Программа chage изменяет количество дней между датой смены пароля...

а на хосте с самим ансиблом может что-то оставаться?

Почему бы нет. Я для другой задачи генерировал файл на нем с помощью delegate_to

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

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

Или писать свой модуль

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

Я в модуле user не увидел таких параметров, которые тут пытаюсь поменять

Там есть expires, которым мне кажется можно примерно то же сделать

Добры день. Как Вы решаете задачи, если нет специального модуля? У меня из одной строки, генерирующей список пользователей на bash: users=($( for NAME in `cut -d: -f1 /etc/passwd`; do uid=`id -u $NAME` ; if [ $uid -ge 1000 ]; then echo $NAME ; fi; done )) echo ${users[@]} получилось 4 таска: https://pastebin.com/bs6MRcVZ Есть идеи, как сделать лучше?

awk -F: '($3 >= 1000) {print $1}' /etc/passwd