Передача GitOps проекта и восстановление источника
«Релиз» связал Git источник, Argo CD, два Kustomize окружения, ручное применение, drift, продвижение и возврат версии. Последняя глава собирает эти механизмы в передаваемый комплект. Результат — следующий разработчик понимает текущее намерение, порядок bootstrap, зависимости образов и Secret, а также границу того, что уже проверено и что ещё предстоит выполнить.
Автор подготовил локальные черновики, исходники и архив. Git операции, Docker сборки, создание кластера, установка Argo CD, sync, HTTP сценарии и тесты не выполнялись. Этот статус not_run находится в уроках, README и editorial плане. Передача не должна превращать подготовленные команды в выдуманный протокол успешного запуска.
Разделяем архив файлов и реальную историю reader
ZIP содержит начальный dev/stage источник версии один и полный код обеих версий API. Reader создаёт собственный repository вне другого Git дерева, commits, теги и последующие promotion решения. Поэтому архив сам по себе не содержит его состоявшуюся history и не доказывает, что stage когда-либо использовал вторую версию. Эти сведения появляются только при самостоятельном проходе.
Для передачи живой лаборатории нужно сохранить Git repository с фактическими refs и объяснениями commits. Если передать только working tree после отката, следующий человек не увидит, какое продвижение было отменено и какой кандидат считался выбранным. Local bundle можно вновь построить из исходной истории, но она должна остаться вне удаляемого кластера.
Также передаются sources images и сведения об артефактах reader. Ploshchadka-api:1, api:2 и web:1 должны обозначать известное содержимое. Если digest получен при реальной сборке, его записывают как фактический результат; если нет, не выдумывают значение. Базовый node:24-alpine пока фиксирует ветку, поэтому архив честно называет этот предел повторяемости.
Bootstrap имеет собственную последовательность
Сначала создаётся отдельный kind-release и загружаются собственные образы. Затем namespaces, Git PVC/Deployment/Service, импорт bundle и Argo CD v3.5.4 из официального pinned файла. После готовности инструмента создаются учебные Secret, AppProject и два Application. Такой порядок показывает зависимости и не предлагает применить все каталоги одной рекурсивной командой.
Git URL разрешается внутри кластера. UI port-forward адресуется человеку, web port-forward адресуется пользовательскому сценарию, Kubernetes API используется контроллером и reader командами. Эти каналы не заменяют друг друга. Если localhost UI работает, это ещё не доказывает, что repo-server прочитал main. Если Git daemon доступен, это ещё не доказывает готовность API образа.
Git PVC использует default StorageClass, наличие которой reader должен установить по наблюдению. Архив не разворачивает неизвестный provisioner. При пересоздании Pod том сохраняет источник в пределах окружения, при удалении kind этого обещания нет. Регламент восстановления поэтому начинается с внешней рабочей копии Git, а не с надежды на переживший очистку локальный PVC.
У каждого слоя есть ожидаемое наблюдение
Следующая таблица помогает следующему участнику выбрать первый вопрос. Это перечень будущих проверок, а не результаты авторского выполнения.
| Слой | Что нужно сопоставить |
|---|---|
| Источник | Repo URL, main refs, опубликованный bundle и resolved commit |
| Декларация | Overlay path, namespace, image и hash ConfigMap |
| Применение | Diff, sync операция, отслеживаемые ресурсы |
| Выполнение | Наличие image, Secret, Pod события, readiness |
| Пользователь | Web маршрут и /api/lessons |
Если Application не строит source, сначала читают его URL/path/revision и состояние Git Pod. Если Deployment создан, но контейнер не стартует, смотрят image и Secret. Если Pod ready, но каталог неверный, исследуют код, env и маршрут. Такая последовательность не гарантирует ответ на любой инцидент, но соответствует конкретной цепочке «Площадки» и сокращает случайные действия.
Synced сообщает согласование декларации, health — состояние ресурсов, HTTP — прикладной результат. Эти наблюдения могут различаться. Передающий не должен сводить их к одной записи «всё зелёное», особенно если пользовательский путь не выполнялся. Для реального отчёта полезны конкретная revision, среда и наблюдение результата, без выдуманного времени успешного выпуска.
Promotion и rollback сохраняют намерение
Из dev в stage переносится один выбранный image и совместимый APP_VERSION, сохраняя stage параметры окружения. Самостоятельный commit stage объясняет решение о продвижении. Reader сначала публикует bundle и читает diff, затем выполняет manual sync. Один shared main commit не означает автоматического применения обеих сред, поскольку Application paths и действия различны.
Откат должен вернуть совместимый набор и доступный прежний image. Оперативный history rollback не меняет main, поэтому долгосрочное намерение исправляют Git commit. Если причиной ошибки были внешний Secret или изменяемые данные другого приложения, возврат source не восстанавливает их автоматически. Наш API stateless упрощает упражнение, не устанавливая универсальную гарантию восстановления.
Drift после ручного scale либо возвращают sync, либо сохраняют как выбранное намерение в overlay и Git. Параллельного HPA в комплекте нет. Если следующий разработчик добавит autoscaler, нужно пересмотреть владение replicas и правила сравнения, а не скрывать поле случайным исключением. Распределение ответственности входит в handoff так же, как имена файлов.
Удаление и секреты остаются адресными
Prune удаляет осмысленно лишний отслеживаемый набор конкретного Application после чтения diff. Namespace, Git Service/PVC и внешний api-demo-secret относятся к bootstrap. Application в исходном комплекте не содержит finalizer каскадного удаления. Если reader позднее меняет этот договор, его последствия должны быть описаны рядом с актуальной декларацией.
Реальные credentials не помещаются в Git или bundle. Учебная строка демонстрирует SecretRef, но не является аутентификацией рабочего сайта. Стандартный Argo CD installation имеет широкую Kubernetes роль; AppProject ограничивает допустимые приложения, не уменьшая ServiceAccount полномочия автоматически. Для публичного окружения это отдельная проектная задача с реальными владельцами и проверкой.
При завершении локальной работы сначала сохраняют нужную историю и сведения вне кластера. Затем выбирают адресное удаление своей лаборатории, понимая судьбу PVC. Команда завершения не должна быть частью обычного sync или неожиданной кнопки очистки приложения. Если появились реальные пользовательские данные, потребуется отдельная процедура копирования и восстановления, которой этот курс не выполнял.
В handoff.md архива собраны эти обязанности, а оглавление серии связывает десять учебных результатов. Следующий читатель получает автономные исходники, понятный читаемый Git bootstrap и честные ожидаемые состояния. Самостоятельный запуск сможет превратить not_run в фактический опыт только после наблюдений выбранной среды; подготовленный материал не подменяет их наличием инструмента в YAML.