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

@zhulik мне тераформ лень наоборот :)

@zhulik погоди, я что то сразу не понял, а что ты "дальше" делаешь тераформом? Оно же надо что бы инфру развернуть имея провайдер. Для к3с есть провайдер? Что именно ты им делаешь? Может и мне поможет действительно.

@zhulik я с тераформом почти не знаком, потому заленился разбираться. Им можно развернуть в к3с постгрю, минио и прочие сервисы?

@3draven любыми ресурсами кубера можно управлять, и хельмом тоже https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs

https://registry.terraform.io/providers/hashicorp/helm/latest/docs

@zhulik а запустить тераформ из ансибла можно? Что бы просто был один плейбук, который раскатает все. Я так понимаю у тераформа преимущество только в краткости и готовых провайдерах, но все равно с нуля все ансиблом делать. Что бы два раза не возится с разными штуками и иметь одну команду на раскатку. Или это принято по другому делать?

@3draven ну это типа 2 разных слоя: ансибл базово готовит ОС серверов, а терраформ уже то, что на них запускается. В моем случае я меняю и запускаю плейбук раз в 100 реже, чем терраформ, поэтому смысла интегрировать их я не вижу: тупо медленно будет ради ничего.

@zhulik я правильно понимаю, что тераформ берет провайдер как слой абстракции и еа любом провайдере с одними и теми же настройками может развернуть постгрю? Он время по сравнению с ансиблом экономит при написании деплоя, это проще чем ансиблом все раскатать?

@zhulik мне надо себе максимально облегчить жизнь, так как и без того много возни.

@3draven не, провайдер это не абстракция, это просто маппинг ресурсов платформы в HCl. Создать постгрю в кубере, в aws rds или в azure это три большие разницы с тз терраформа. Переносимо будет если у тебя и там и там все в кубере сидит, не важно managed или нет.

@zhulik тогда в чем плюс по сравнению с ансиблом? Мне надо развернуть инфру на свои три с половиной калеки сервиса. Тераформ мне жизнь облегчит? :)

@3draven на три с половиной, наверно, усложнит. Но когда и если сервисов станет больше, с терраформом и кубером будет проще кмк

@zhulik тогда пока отложу, мне не так много надо. Если бы ему можно было прям сказать "разверни постгрес вон там, и пару настроек" было бы полезно. Но пока, масштаб не тот.

@zhulik а как ты к3с разворачиваешь, есть проверенные ансибл плейбуки или сам писал?

@3draven там одна команда буквально, k3sup, для control plane одни параметры, для воркеров другие. Есть, наверно, готовые плейбуки, но мне лень искать было

@zhulik а потом постгря и прочие сервисы уже в тераформе?

@3draven ага, через провайдер для хельма. Имей в виду ещё, что у кубера есть своя бд, k3s поставляется с etcd, и ее желательно бэкапать на всякий

@zhulik а если я хочу поставить свой кастомный сервис в к3с, это делать тераформом можно или ансиблом придется?

@3draven терраформом, тебе нужно будет контейнеризовать твой сервис, и как минимум создать deployment или stateful set в зависимости от сервиса. Скорее всего ещё нужен будет service, и, если http, то ещё ingress. K3s поставляется с cert manger, можно без особой возни получить https от let's encrypt, и оно его само продлевать будет

@zhulik спасибо, примерно понятно. То есть терраформ по сути будет содержать ямл, настраивающий провайдер, ямла, описывающий набор контейнеров, которые нужно развернуть в кубере и настройки контейнеров?

@zhulik ну то есть терраформ это по сути докер композ для поддерживаемых провайдеров?

@3draven ну типа, но ямла там можно вообще не касаться, вместо него HCl.

@3draven k3s - "дистрибутив" кубера, предназначенный для голого железа и всякой эмбедовки/эдж. Все, что работает с кубером, работает с к3с. С терраформом можно декларативно описать ресурсы и терраформ это раскатает. Разница с традиционным ямлом в том, что язык сильно приятнее, ты всегда четко видишь, какие изменения к кластеру применяются, и можешь легко референсить один ресурс из другого. Через него же можно управлять и постгрей, и минио, и ещё кучей всего, что он же сам в кластер и поставил

@kurator88 а, разглядел картинку. Это структура проекта такая в ansible

@3draven у меня как-то всё в один файл уложилось.

1 сервис - 1 файл,
1 файл со всеми секретами для всех сервисов

@kurator88 ну, у тебя планы пожиже видать :) Через два шага в моих планах там черт ногу сломит.

@3draven у меня просто набор заданий которые не связаны друг с другом
1) поставить wg для vpn
2) установить весь софт которым я чаще всего пользуюсь
3) поднять blocky как dns для фильтра
4) создать учётку для разработки
5) поднять docker-compose с seafile

Я просто реально не понимаю смысла вот этих папок всех. У тебя есть простая задача - поставить docker, что там может быть сложного, всего две строки в sh

curl -fsSL https://get.docker.com -o get-docker.sh ; sudo sh ./get-docker.sh

@kurator88 я не брал на себя обязанность доказывать тебе крутость ансибла :) Мне он по масштабу задачи подходит идеально. Терраформ великоват, а скрипты маловаты. Что бы понять ансибл надо знать всякие идемпотентности и прочую хрень, тогда оценишь. Ну и опыт разработки хотя бы средних проектов иметь. Он для них идеален по моему.

@3draven ты возможно не понял.

У меня достаточно всего написанного на ansible скриптах. Там где мой ansible скрипт занимает 1 файл, у тебя 5 папок.

Я не спрашиваю зачем тебе ansible. Я не понимаю почему ты его ТАК готовишь.

@kurator88 Все просто, это стандартная структура ролей в галакси. Я мог все в одном файле сделать, но как уже писал, это рабочая привычка.

@kurator88 я не создавал эти папки, просто сгенерил проект.

@3draven а это приносит тебе удовольствие ? Объясню вопрос.

Я на работе делаю хорошо потому что это моя профессиональная деятельность. Хобби мне нужно ради удовольствия, поэтому я срезаю некоторые углы чтобы быстрее получить результат и сделать не так хорошо но ювстрее. Я сознательно отказываюсь от слишком надёжных решений чтобы не тратить время на из настройку. Я бы перегорел делать все правильно, считай с одной работы на другую пришел

@kurator88 я набрал одну команду, оно сгенерило роль, я заполнил пару файлов. Это не сложно. Не предмет для усталости...честно сказать я и внимания не обратил. Ну была бы каша в одном файле, я бы сам, как уже писал, через два шага бы жалел. Просто не заметил даже.

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

@3draven @kurator88 вставлю свои 5 копеек, хоть и не ansible-man. Любая подобная структура (код, скрипты, конфиги) должны как минимум хорошо восприниматься глазами и нормально редактироваться обычным текстовым редактором и из консоли (а то мало ли что). Такое глубокое дерево с кучей пустых файлов - не очень удобно, на мой взгляд.

@vsv @kurator88 я пустые папки не стал удалять потому, что оно полежит время, если я ничего нового для этой штуки не придумаю, вот потом и удалю...если не забуду. Пока рано, а потом может и не надо будет. Хочется, делаешь форк, сливаешь в файл и радуешься ;)

@vsv @kurator88 а с консоли редактировать точно не надо будет. Суть ансибла в том, что тебе на сервера вообще заходить не надо. Со своего ноута запустил, подождал и все.

@vsv @kurator88 я давно хотел с ним повозиться, я не девопс. Идемпотентность и полное отсутствие необходимости заходить на десять серверов, да еще и прозрачное перетаскивание инфы между локалхостом и удаленкой, это прям конфета для моих дальнейших планов. Скрипты это одноразовый код в сравнении с этим. Одноразовый код я не люблю.

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

@nett00n если есть рекомендации или исправления, буду признателен. Это первый плейбук, что я написал :)

@3draven Для первого раза вообще пушка. Я бы предложил
- Перенести роли в папку roles
- common variables в defaults/main.yml. Тогда будут заданы дефолты, которые могут быть overrided в group_vars/host_vars
- уже фичареквест: генерировать docker_install\templates\daemon.j2.json из тоже из переменных, а не захардкоженным списком

@nett00n ок, сделаю, спасибо. Меня тут ругают, что папок пустых много, их принято удалять или структура проекта важнее?

@3draven вкусовщина, как по мне

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

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

@3draven
Есть galaxy
https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a-file

@nett00n Дефолты разносить долго, искать их :) Остальное сделал. Мало того теперь весь трафик в впн, который попытается по айпишнику использовать другой днс напрямую все равно будет завернут на pi-hole

@nett00n действительно роли хранить в папке красивее и переменные оно само подхватило когда они там где надо, удобно.

@3draven Не, есть дефолты для ролей (./roles/rolename/defaults/main.yml), а поверх них ещё можно прописать дефолты для плэйбуки в ./defaults/main.yml