Где хранить билд-артефакты в DevOps-практике?

Выбор хранилища зависит от типа артефакта, требований к версионированию, безопасности и интеграции с пайплайном.

Основные варианты:

1. Артефакт-репозитории (Artifact Repositories):

   • Назначение: Хранение бинарных артефактов (Docker-образы, Java .jar, npm-пакеты, .deb/.rpm).
   • Примеры: JFrog Artifactory, Sonatype Nexus, Azure Artifacts, GitHub Packages.
   • Преимущества: Версионирование, проксирование внешних репозиториев, контроль доступа, интеграция с CI/CD (Maven, Gradle, Docker).
   • Пример публикации Docker-образа:

     docker tag myapp:latest my-registry.example.com/myapp:1.2.3
     docker push my-registry.example.com/myapp:1.2.3

2. Объектные хранилища (Object Storage):

   • Назначение: Хранение больших или редко используемых артефактов (инсталляторы, бэкапы, лог-файлы сборок).
   • Примеры: Amazon S3, Google Cloud Storage, Azure Blob Storage, MinIO.
   • Преимущества: Высокая доступность, масштабируемость, низкая стоимость для cold storage.
   • Пример загрузки через AWS CLI:

     aws s3 cp ./build/output.zip s3://my-ci-bucket/artifacts/project/v1.2.3/

3. Встроенные хранилища CI/CD-систем:

   • Назначение: Временное хранение артефактов в рамках выполнения пайплайна.
   • Примеры: GitLab CI Artifacts, GitHub Actions Artifacts, Jenkins Archive Artifacts.
   • Преимущества: Простая настройка, автоматическая очистка, прямая ссылка из job'а.

Моя практика: Для production-проектов я использую комбинацию: Docker-образы пушатся в приватный registry (например, Nexus или Harbor), бинарные пакеты — в Artifactory, а временные логи сборок и отчеты тестов — во встроенное хранилище CI (например, GitLab) с ограниченным временем жизни. Ключевые артефакты промоута (те, что прошли все стадии и одобрены для деплоя) всегда имеют четкую версию и хранятся в артефакт-репозитории как единственный источник истины для развертывания.