Восстановление инструментов Armory в офлайн-среде: пошаговое руководство

Восстановление Armory в закрытом контуре — это не только возврат контейнеров и чартов. Нужно согласованно поднять локальный реестр, Helm-репозиторий, оператор, секреты, базы данных, объектное хранилище и пайплайны. Ниже — практический порядок действий для офлайн-среды, где нет доступа к Docker Hub, публичным Helm-репозиториям и внешним API.

1. Что считается восстановлением инструментов

Под инструментами Armory понимаются:

• armory-operator и CRD SpinnakerService;
• armory-cli, halyard и утилиты spin;
• образы микросервисов Armory CD: deck, gate, orca, clouddriver, front50, echo, igor, fiat, kayenta, rosco;
• Helm-чарты, манифесты, плагины и профили конфигурации;
• секреты, учетные записи облаков, уведомления и пайплайны.
  Цель восстановления — получить работоспособный Armory CD, который запускается, принимает пайплайны и не обращается в интернет.

2. Подготовка

Перед началом зафиксируйте:

• версию Armory CD, оператора и CLI;
• состав namespace, например armory и spinnaker;
• список образов с digest, а не только с tag;
• перечень Helm-чартов и локальных URL репозитория;
• доступы к внутреннему registry, S3/MinIO, SQL и Vault;
• резервные копии секретов, ConfigMap, CR и пайплайнов.
  Проверьте, что в закрытом контуре синхронизировано время, настроены DNS, доверенные сертификаты и прокси, если он используется для внутренних сервисов.

3. Источники артефактов

В офлайн-среде все зависимости должны лежать внутри:

• локальный Docker/OCI registry: registry.local/armory/...;
• локальный Helm-репозиторий: https://helm.local/armory;
• каталог с бинарниками armory-cli, halyard, kubectl, helm, skopeo;
• защищенное хранилище резервных копий: s3://backup/armory/... или MinIO;

• репозиторий конфигураций Git с пайплайнами и манифестами.
  Если артефакты переносятся через промежуточный узел, сверяйте checksum и подписи. Неподписанные или устаревшие образы лучше не использовать.

4. Пошаговый порядок восстановления

Шаг 1. Проверка Kubernetes и доступа к registry

Убедитесь, что кластер доступен, а worker-узлы могут скачать образы из локального registry:

kubectl get nodes
kubectl get ns
crictl pull registry.local/armory/armory-operator:VERSION

Если используется Helm, проверьте добавленный локальный репозиторий:

helm repo list
helm repo update

Шаг 2. Восстановление оператора и CRD

Установите или восстановите Armory Operator из локального чарта. Затем примените сохраненные CRD и CR SpinnakerService.

helm upgrade --install armory-operator local/armory-operator -n armory
kubectl apply -f backup/crds/
kubectl apply -f backup/spinnakerservice.yaml

После этого оператор начнет создавать поды. Если registry недоступен, поды зависнут в ImagePullBackOff; сначала исправьте доступ к образам.

Шаг 3. Восстановление секретов и конфигураций

Восстановите Secret и ConfigMap в правильном namespace. Для секретов используйте штатное хранилище: Kubernetes Secret, Vault или внешний secret manager.

kubectl apply -f backup/secrets/
kubectl apply -f backup/configmaps/

Проверьте, что в конфигурации указаны внутренние адреса: registry, MinIO/S3, SQL, Redis, SMTP, OIDC/SAML. Внешние URL Armory должны вести на внутренний DNS.

Шаг 4. Восстановление данных и пайплайнов

Если Armory использует внешние БД и объектное хранилище, сначала восстановите их:

• SQL: orca, clouddriver, front50, echo, fiat;
• объектное хранилище: бакеты front50, orca, echo, kayenta;
• Redis, если он используется для кеша и очередей.
  Затем импортируйте приложения и пайплайны через spin или API:

spin application save --file backup/applications/app.json
spin pipeline save --file backup/pipelines/pipeline.json

Для плагинов восстановите манифесты и локальные артефакты, иначе Deck или Orca не загрузят расширения.

Шаг 5. Запуск и проверка

Дождитесь готовности подов:

kubectl get pods -n spinnaker -w
kubectl get svc -n spinnaker

Проверьте:

• armory-cli version и hal config version;
• доступность Deck и Gate через внутренний URL;

• список приложений и пайплайнов;
• выполнение тестового пайплайна без внешних вызовов;
• загрузку плагинов и отсутствие ошибок в логах Orca, Clouddriver, Front50;
• корректность прав Fiat и доступа к учетным записям.
  Если пайплайн обращается к внешнему репозиторию, замените URL на локальный зеркальный репозиторий.

5. Типовые ошибки

• Восстановили образы по tag, а не по digest, и получили несовместимые версии.
• Забыли CRD, поэтому оператор не видит SpinnakerService.
• Секреты применили в другом namespace.
• В конфигурации остались публичные URL, из-за чего поды не стартуют.
• Не восстановили бакеты Front50, поэтому пайплайны и приложения исчезли.
• Не проверили плагины: UI загружается, но функции Armory недоступны.
• Использовали самоподписанные сертификаты без добавления в truststore.

6. Чек-лист восстановления

• [ ] Известны версии Armory CD, Operator и CLI.
• [ ] Все образы доступны в локальном registry по digest.
• [ ] Helm-чарты и CRD восстановлены из проверенного источника.
• [ ] Secret и ConfigMap применены в нужные namespace.
• [ ] SQL, Redis и объектное хранилище восстановлены.
• [ ] Пайплайны, приложения и плагины импортированы.
• [ ] Проверен тестовый запуск пайплайна.
• [ ] В логах нет ошибок доступа к интернету.
• [ ] Составлена инструкция для следующего восстановления.

7. Итог

Восстановление инструментов Armory в офлайн-среде требует дисциплины: сначала инфраструктура и артефакты, затем оператор и конфигурация, потом данные и пайплайны. Если все зависимости размещены во внутреннем registry и Helm-репозитории, а секреты и бакеты восстановлены согласованно, Armory CD возвращается в работу без доступа к публичной сети.