Каталог состояния: что коммитить, а что никогда
Состояние проекта живёт в одном месте, и у каждого файла в нём есть явный ответ на вопрос, попадает ли он в репозиторий.
Всё состояние проекта лежит в одном служебном каталоге в корне проекта. Никаких запасных путей и совместимости с прежними раскладками — продукт до публичного релиза, поддерживать старые установки не нужно, поэтому раскладка одна и безусловная.
Рядом, в том же корне, лежит файл конфигурации проекта — его редактирует человек, и он коммитится в репозиторий. Именно он, а не что-либо в служебном каталоге, задаёт проект, трек, облако и кластер.
Строгий разбор конфигурации
Конфигурация разбирается строго: неизвестный ключ не игнорируется, а останавливает работу с отдельной, понятной ошибкой. Версия схемы по умолчанию считается первой; любая другая заявленная версия тоже отклоняется явно.
Это раздражает при первом знакомстве и экономит часы потом. Опечатка в имени ключа при мягком разборе означает, что настройка молча не применилась, а поведение объяснят чем угодно другим.
Что не попадает в git
База состояния, запись о последнем применении, реестр целей, кэш клонов репозиториев, ключи проекта — всё это локальное и в репозиторий не идёт.
Отдельно и жёстче — файлы состояния Terraform, в том числе зашифрованные. Для них есть не рекомендация, а проверка: если такой файл оказался в индексе или в истории, применение и удаление отклоняются с ненулевым выходом.
Причина в том, что файл состояния Terraform содержит достаточно данных, чтобы им можно было навредить, и попадает он под контроль версий всегда по невнимательности — обычно вместе с git add ..
Что попадает
Манифесты приложений для ArgoCD — это и есть содержимое GitOps-репозитория, оно обязано быть в git.
Публичные ключи SSH — их безопасно коммитить, на то они и публичные.
Журнал аудита — опционально: он добавляется в индекс только если это включено в конфигурации проекта.
Про два журнала аудита
Их действительно два, и это стоит назвать прямо. Есть журнал в устаревшем формате построчного JSON, без цепочки контроля целостности. И есть новый — с цепочкой на HMAC-SHA256, отдельным файлом на каждую цель.
Второй устойчив к подделке: изменить запись в середине, не сломав цепочку, нельзя. Первый оставлен для совместимости и честно помечен как устаревший, а не выдан за то же самое.
Почему один каталог, а не разбросанные файлы
Первое: удаление проекта — это удаление одного каталога. Не поиск временных файлов по системе.
Второе: правило про git становится проверяемым. Когда состояние в одном месте, проверить, не утекло ли оно в репозиторий, — конечная операция.
Третье: перенос проекта на другую машину сводится к понятному вопросу — что взять с собой. Ответ: репозиторий, а из служебного каталога только ключи, если так принято в команде.
Что бывает, когда конфигурации нет
Проект без файла конфигурации останавливается громко и с понятной ошибкой. Не создаёт файл с настройками по умолчанию, не спрашивает интерактивно, не догадывается.
Это часть общего правила: отсутствие источника истины — ошибка, а не повод для тихого запасного варианта.