или я неверно понял проблему ?

У тебя есть один конфиг со стейтом для одного конкретного окружения и множество окружений. Как случайно не применить конфигурацию не к тому окружению?

Котаны, а вы знали про тесную интеграцию контейнеров и VSCode? Я открыл для себя и не нарадуюсь. Основные фишки:
- VS Code запускается внутри подготовленного контейнера, есть все нужные тулы и дебагеры.
- Код монтируется с ФС, но это норма и не удивишь
- Можно привязать сбоку compose и поднимать маленькое dev-окружение (помимо базы, я сейчас прикрутил mitmproxy)
- Весь конфиг хранится в коде в самом репозитории

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

Мне интересен чужой опыт. Пользовались? Как? Какие грабли собрали? Может есть интересные статейки на тему?

Забыл ссылку https://code.visualstudio.com/docs/remote/containers

Можно ssh агента внутрь прокинуть если он умеет его использовать

Глянь ещё на https://github.com/cloudposse/geodesic, может быть там какие-то интересные решения подглядишь

Прочитал ридми, не понял соли. Навскидку выглядит как докер образ с предустановленными тулами и интеграцией с бекендом управляющим ролями (IAM?)

Какую проблему оно решает?

Это не так клево. Я понимаю, что многие хранят docker-compose внутри репозитория с кодом и в нем поднимают дев окружение. Devcontainers VS Code делают примерно то же самое, только управляешь всем из VS Code’а. И получаешь чуть более тесную интеграцию

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

непонимаю, что значит “один конфиг со стейтом и множество окружений”.

есть tfstate в котором хранится состояние одного из множества твоих окружений. Например, через awscli зашел на тестовый аккаунт и настроил инфру данной конфигурацией.
Затем переключился на прод аккаунт, не заметил/забыл, и применяешь ту же конфигурацию напротив того же tfstate.

Стало ли понятнее?

Да теперь понял. Только не понимаю зачем для таких случаев иметь один и тот же стейт )

Как концепт выглядит интересно. Спасибо. А есть ли живой опыт общения с тулой или статьи на тему?

Конечно не надо. Проблема в “случайном” переключении между окружениями. Работал с одним окружением, потом переключился на другое, забыл переключиться на первое и применил конфигурацию первого на второе окружение. Есть ли какие-либо методы защиты от этого?

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

нету кажется, но мне кажется, что когда ты сделаешь plan по другому окружению, там будет что то типа “удалю 100500 сущностей, добавлю 100500 сущностей”

Пока только так. Но если у терраформа - рефреш состояния включен по умолчанию. То для пулуми он по умолчанию выключен =)

Я оттуда дербанил кое-какие идеи, как есть не использовал.

К примеру, переключение между окружениями (да что там - между клиентами) очень удобно делать через direnv

Для амазона чтобы не хранить ключи откытым текстом даже локально - awsvault