1. Обзор
Artifact Registry — это полностью управляемый менеджер пакетов, предоставляющий единый инструмент для управления образами контейнеров OCI и языковыми пакетами (такими как Maven и npm).
Реестр артефактов полностью интегрирован с широким спектром других сервисов Google Cloud, как показано в следующих примерах:
- Cloud Build может напрямую загружать артефакты образов в реестр артефактов.
- Cloud Deploy позволяет развертывать образы реестра артефактов непосредственно в различных средах выполнения.
- Он предоставляет образы средам выполнения контейнеров, таким как Cloud Run и GKE, и обеспечивает расширенные возможности оптимизации производительности, например, потоковую передачу образов.
- Реестр артефактов может служить точкой обнаружения для анализа артефактов, позволяя непрерывно отслеживать известные уязвимости.
- Облачное управление идентификацией и доступом (Cloud IAM) обеспечивает согласованный и детальный контроль над доступом к артефактам и правами доступа.
В этой лабораторной работе вы познакомитесь со многими из этих функций в форме практического руководства.
Что вы узнаете
Каковы учебные цели этой лабораторной работы?
- Создайте разные репозитории для контейнеров и языковых пакетов.
- Создавайте и используйте образы контейнеров с помощью Artifact Registry.
- Используйте реестр артефактов для анализа уровня безопасности и содержимого ваших артефактов.
- Настройка и использование реестра артефактов для зависимостей Java Maven.
2. Настройка и требования
Настройка среды для самостоятельного обучения
- Войдите в консоль Google Cloud и создайте новый проект или используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .
- Название проекта — это отображаемое имя участников данного проекта. Это строка символов, не используемая API Google. Вы всегда можете его изменить.
- Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (его нельзя изменить после установки). Консоль Cloud автоматически генерирует уникальную строку; обычно вам неважно, какая она. В большинстве практических заданий вам потребуется указать идентификатор вашего проекта (обычно обозначается как
PROJECT_ID). Если сгенерированный идентификатор вас не устраивает, вы можете сгенерировать другой случайный идентификатор. В качестве альтернативы вы можете попробовать свой собственный и посмотреть, доступен ли он. После этого шага его нельзя изменить, и он сохраняется на протяжении всего проекта. - К вашему сведению, существует третье значение — номер проекта , которое используется некоторыми API. Подробнее обо всех трех значениях можно узнать в документации .
- Далее вам потребуется включить оплату в консоли Cloud для использования ресурсов/API Cloud. Выполнение этого практического задания не потребует больших затрат, если вообще потребует. Чтобы отключить ресурсы и избежать дополнительных расходов после завершения этого урока, вы можете удалить созданные ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на бесплатную пробную версию стоимостью 300 долларов США .
Настройте gcloud
В Cloud Shell укажите идентификатор проекта и номер проекта. Сохраните их как переменные PROJECT_ID и PROJECT_NUMBER .
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
Включить сервисы Google
gcloud services enable \
cloudresourcemanager.googleapis.com \
run.googleapis.com \
artifactregistry.googleapis.com \
containerregistry.googleapis.com \
containerscanning.googleapis.com \
binaryauthorization.googleapis.com \
cloudbuild.googleapis.com
Получите исходный код
Исходный код для этой лабораторной работы находится в организации GoogleCloudPlatform на GitHub. Клонируйте его с помощью приведенной ниже команды.
git clone https://github.com/GoogleCloudPlatform/java-docs-samples
3. Изображения контейнеров для перемещения
Создайте репозиторий Docker в реестре артефактов.
Как уже упоминалось, Artifact Registry поддерживает различные форматы репозиториев, позволяющие управлять образами контейнеров и языковыми пакетами. Взаимодействие с различными типами репозиториев артефактов определено в спецификациях и является широко распространенным стандартом. Например, запросы к зависимостям Maven отличаются от запросов к зависимостям Node.
Для поддержки конкретных спецификаций API артефактов, Artifact Registry необходимо управлять вашими артефактами в соответствующих типах репозиториев. При создании нового репозитория вы передаете флаг --repository-format чтобы указать тип репозитория.
Для создания первого репозитория для образов Docker выполните следующую команду в Cloud Shell:
gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"
Нажмите «Авторизовать», если появится запрос на авторизацию Cloud Shell.
Перейдите в Google Cloud Console — Artifact Registry — Repositories и обратите внимание на свой недавно созданный репозиторий Docker под названием container-example . Если вы щелкнете по нему, то увидите, что в данный момент он пуст.
Настройка аутентификации Docker в реестре артефактов
При подключении к реестру артефактов для предоставления доступа требуются учетные данные. Вместо настройки отдельных учетных данных Docker можно настроить таким образом, чтобы он беспрепятственно использовал ваши учетные данные gcloud.
В Cloud Shell выполните следующую команду, чтобы настроить Docker для использования Google Cloud CLI для аутентификации запросов к Artifact Registry в регионе us-central1 :
gcloud auth configure-docker us-central1-docker.pkg.dev
Если при выполнении команды потребуется подтверждение изменения конфигурации Docker в Cloud Shell, нажмите Enter.
Ознакомьтесь с примером приложения.
Пример приложения находится в репозитории Git, который вы клонировали на предыдущем шаге. Перейдите в каталог java и просмотрите код приложения.
cd java-docs-samples/run/helloworld/
ls
В папке находится пример Java-приложения, которое отображает простую веб-страницу: помимо различных файлов, не имеющих отношения к данной лабораторной работе, она содержит исходный код в папке src , а также Dockerfile, который мы будем использовать для создания образа контейнера.
Создайте образ контейнера.
Прежде чем вы сможете сохранять образы контейнеров в реестре артефактов, вам необходимо его создать.
Выполните следующую команду, чтобы создать образ контейнера и пометить его полным путем к реестру артефактов:
docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .
Загрузите образ контейнера в реестр артефактов.
Выполните следующую команду, чтобы отправить образ контейнера в ранее созданный репозиторий:
docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1
Просмотрите изображение в реестре артефактов.
Перейдите в консоль Google Cloud — Реестр артефактов — Репозитории . Откройте репозиторий container-example и убедитесь, что образ java-hello-world там присутствует.
Щелкните по изображению и обратите внимание на изображение с тегом tag1 . Поскольку мы включили автоматическое сканирование изображений через сервис containerscanning.googleapis.com , вы можете видеть, что сканирование на уязвимости либо выполняется, либо уже завершено. После его завершения вы сможете увидеть количество обнаруженных уязвимостей для этой версии изображения. Мы рассмотрим уязвимости и другие данные об артефактах в следующем разделе.
4. Проверка изображений контейнеров
Теперь, когда вы загрузили свой первый образ в репозиторий container-example , мы можем рассмотреть его подробнее. На вкладке «Версии» щелкните по только что созданной версии. Чтобы показать образ более подробно:
Кнопка копирования вверху особенно полезна, поскольку она предоставляет простой способ доступа к полному URI образа для данной версии образа, включая SHA-хеш. Этот URI затем можно использовать для загрузки определенной версии образа или в качестве ссылки на образ в развертывании Kubernetes или в службе Cloud Run. Чтобы проверить URI образа, вы можете выполнить следующую команду в Cloud Shell:
docker pull $IMAGE_URI
Понимание зависимостей
Перейдя на вкладку «Зависимости» вверху, вы увидите все зависимости, обнаруженные в вашем образе. Обратите внимание, что здесь перечислены как зависимости на уровне языка программирования, так и на уровне операционной системы. Вы также можете увидеть лицензии на программное обеспечение, привязанные к каждой из зависимостей.
Если присмотреться, можно заметить, что информация в SBOM еще не заполнена. Чтобы заполнить SOM для вашего артефакта, вы можете выполнить следующую команду в Cloud Shell, используя полный URI изображения, который можно скопировать из навигационной цепочки вверху.
gcloud artifacts sbom export --uri $IMAGE_URI
После обновления страницы появится ссылка на автоматически сгенерированный SBOM, хранящийся в Cloud Storage. Если вы используете SBOM для своих образов, вы можете настроить автоматическую генерацию SBOM для своих артефактов и включить этот процесс в свой конвейер CI/CD.
Исследование уязвимостей изображений
При нажатии на вкладку «Уязвимости» в верхней части окна вы можете увидеть все обнаруженные в вашем образе уязвимости. Помимо сводки уязвимостей вверху, вы можете увидеть полный список уязвимостей в таблице внизу. Каждая строка содержит ссылку на бюллетень CVE, указывающий на степень серьезности уязвимости и пакет, в котором она была обнаружена. Для уязвимостей, для которых доступно исправление, также приводятся инструкции по обновлению зависимостей для устранения уязвимости.
5. Виртуальные и удалённые репозитории
В предыдущем разделе мы использовали единое хранилище образов для отправки и получения образов. Это отлично подходит для небольших проектов, но создает проблемы, особенно для крупных организаций с различными командами, которым требуется автономия в управлении своими хранилищами. Часто у команд или бизнес-подразделений есть собственное хранилище образов со своими правами доступа и конфигурацией. Чтобы упростить использование образов в этих хранилищах и защитить пользователя от базовой организационной структуры, Artifact Registry предоставляет виртуальные хранилища, которые могут объединять ресурсы из нескольких базовых хранилищ. Потенциальная архитектура может выглядеть следующим образом:
Удаленный репозиторий для Docker Hub
Docker Hub — популярный общедоступный реестр образов, содержащий множество образов контейнеров с открытым исходным кодом. Хотя прямое использование общедоступного репозитория довольно просто, в производственной среде это сопряжено с рядом проблем, которые можно преодолеть с помощью удаленных репозиториев в Artifact Registry.
Удаленные репозитории позволяют перенаправлять запросы к вышестоящему реестру и кэшировать образы по пути. Это не только сокращает время загрузки образов, но и устраняет зависимость от доступности внешнего сервиса, а также позволяет применять те же политики безопасности и доступа, что и к собственным образам.
Для создания удалённого репозитория для Docker Hub можно выполнить следующую команду в Cloud Shell:
gcloud artifacts repositories create dockerhub \
--repository-format=docker \
--mode=remote-repository \
--remote-docker-repo=docker-hub \
--location=us-central1 \
--description="Example Remote Repo for Docker Hub"
Теперь в списке репозиториев вашего реестра артефактов должен появиться дополнительный репозиторий:
Чтобы проверить, может ли ваш удалённый репозиторий перенаправлять запросы к нему, выполните следующую команду в Cloud Shell для загрузки образа nginx :
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine
После успешного выполнения операции pull вы также можете посмотреть репозиторий в Cloud Console и убедиться, что кэшированный образ nginx теперь предоставляет те же отчеты о зависимостях и уязвимостях, которые мы видели для образа, созданного вами самостоятельно.
Создание виртуального репозитория
Следуя описанным выше процессам, вы можете создать несколько репозиториев для каждой команды или подразделения и четко определить права собственности и разрешения IAM для каждого из них. Мы также можем создавать прокси для удаленных репозиториев, что упрощает и делает более безопасным использование образов сторонних разработчиков. Недостаток такого большого количества репозиториев становится очевидным, если взглянуть на ситуацию с точки зрения потребителя этих образов. Как разработчику понять, какой репозиторий образов ему следует использовать при развертывании?
Для упрощения использования и сокрытия базовых репозиториев за уровнем абстракции можно создать виртуальный репозиторий в Artifact Registry с помощью следующей команды в Cloud Shell:
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com \
--role roles/artifactregistry.reader
cat <<EOF > /tmp/upstream.json
[{
"id" : "hello-repo",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/container-example",
"priority" : 100
},{
"id" : "dockerhub",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/dockerhub",
"priority" : 101
}]
EOF
gcloud artifacts repositories create all-images \
--repository-format=docker \
--mode=virtual-repository \
--location=us-central1 \
--upstream-policy-file=/tmp/upstream.json \
--description="Example Virtual Repo"
Теперь мы можем загружать образы из виртуального репозитория, не раскрывая его базовую структуру. Чтобы убедиться, что всё работает как положено, вы можете выполнить следующие команды в Cloud Shell:
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/nginx:stable-alpine
6. Развертывание в облаке.
После того, как соответствующие репозитории и образы будут созданы, мы можем перейти к их использованию при развертывании. Чтобы проиллюстрировать пример использования и избежать развертывания дополнительной инфраструктуры, мы развернем наш контейнер в Cloud Run. В простейшем случае развертывание можно выполнить, запустив следующую команду в Cloud Shell:
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1 \
--allow-unauthenticated
После завершения развертывания отобразится автоматически сгенерированный URL-адрес, по которому вы сможете получить доступ к своему сервису.
Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1] OK Deploying... Done. OK Creating Revision... OK Routing traffic... OK Setting IAM Policy... Done. Service [hello-world] revision [hello-world-00001-wtc] has been deployed and is serving 100 percent of traffic. Service URL: https://hello-world-13746229022.us-central1.run.app
Если вы откроете этот URL-адрес в новой вкладке браузера, вы должны увидеть сообщение "Hello World", свидетельствующее об успешном завершении процесса.
7. Укрепить безопасность цепочки поставок
Теперь, когда ваш образ контейнера развернут в рабочей среде, самое время подумать о том, как укрепить нашу сквозную цепочку поставок. В предыдущем разделе мы рассмотрели, как анализ контейнеров в Artifact Registry предоставляет информацию об используемых в образе библиотеках и лицензиях. Однако злоумышленники по-прежнему могут внедрять вредоносный контент в ваш образ по всей цепочке поставок. В этом разделе мы рассмотрим, как можно использовать фреймворк SLSA для аттестации артефактов сборки и даже использовать криптографические подписи самих артефактов, чтобы гарантировать, что в нашу среду выполнения Cloud Run можно развертывать только доверенные артефакты.
Аттестация SLSA с использованием Cloud Build
Структура SLSA предоставляет различные уровни подтверждения для артефактов цепочки поставок. Спецификация и реализация могут показаться сложными на первый взгляд, но с Cloud Build создание аттестации SLSA так же просто, как добавление спецификации cloudbuild.yaml с параметром requestedVerifyOption , установленным в значение VERIFIED .
Для нашего приложения мы можем выполнить следующую команду в Cloud Shell, чтобы создать файл cloudbuild.yaml в папке helloworld.
cat <<EOF > cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', '\$_IMAGE_URI', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['push', '\$_IMAGE_URI']
images:
- '\$_IMAGE_URI'
options:
requestedVerifyOption: VERIFIED
substitutions:
_IMAGE_URI: us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:latest
EOF
Теперь мы создадим новое задание Cloud Build Job, которое соберет новую версию нашего образа Java Hello World, выполнив следующую команду в Cloud Shell.
gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build
После завершения сборки мы можем перейти в пользовательский интерфейс Cloud Build в консоли Google Cloud и посмотреть достигнутый уровень SLSA, открыв нашу сборку и посмотрев артефакты сборки в разделе «Сводка сборки». На изображении есть кнопка для просмотра «Аналитики безопасности». При нажатии на нее вы увидите аттестацию SLSA, а также знакомые отчеты об уязвимостях, которые мы видели ранее в пользовательском интерфейсе реестра артефактов при отправке локальной сборки.
Происхождение изображения в базе данных SLSA также можно получить, выполнив следующую команду в Cloud Shell:
gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
--show-provenance
Требуется подтверждение происхождения облачной сборки с помощью бинарной авторизации.
Разве не было бы здорово, если бы при наличии конвейера Cloud Build все образы, развертываемые в производственной среде, были созданы с использованием этой программируемой и воспроизводимой среды сборки?
Здесь вступает в дело авторизация бинарных файлов. Она позволяет установить «привратника» перед средой выполнения контейнеров, который проверяет образ контейнера и подтверждает наличие доверенного подтверждения. Если подтверждение не найдено, он либо создает записи в журнале аудита, либо полностью блокирует развертывание в зависимости от конфигурации.
Чтобы изменить конфигурацию авторизации бинарных файлов по умолчанию в нашем проекте и потребовать встроенную аттестацию, выдаваемую Cloud Run, выполните следующую команду в Cloud Shell:
cat << EOF > /tmp/policy.yaml
defaultAdmissionRule:
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
evaluationMode: REQUIRE_ATTESTATION
requireAttestationsBy:
- projects/$PROJECT_ID/attestors/built-by-cloud-build
name: projects/$PROJECT_ID/policy
EOF
gcloud container binauthz policy import /tmp/policy.yaml
Здесь вы, конечно, могли бы также добавить свои собственные пользовательские аттестаторы, но это выходит за рамки данного практического занятия и остается необязательным дополнительным домашним заданием.
Для обеспечения авторизации бинарных файлов в нашей службе Cloud Run мы выполняем следующую команду в Cloud Shell:
gcloud run services update hello-world \
--region us-central1 \
--binary-authorization=default
Давайте проверим правильность применения нашей бинарной авторизации, сначала повторно развернув локально собранный образ.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1
Как и ожидалось, вы должны получить сообщение об ошибке, объясняющее, почему образ не удалось развернуть, которое будет выглядеть примерно так:
Image us-central1-docker.pkg.dev/my-project/all-images/java-hello-world@sha256:71eebbf04bf7d1d023e5de5e18f786ea3b8b6411bf64c8def3301c71baca0518 denied by attestor projects/my-project/attestors/built-by-cloud-build: No attestations found that were valid and signed by a key trusted by the attestor
Для развертывания новой версии в нашем сервисе Cloud Run нам необходимо предоставить образ, созданный с помощью Cloud Build.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:cloud-build \
--region us-central1
На этот раз развертывание должно пройти успешно, и отобразится сообщение об успешном развертывании, аналогичное приведенному ниже:
Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1] OK Deploying... Done. OK Creating Revision... OK Routing traffic... Done. Service [hello-world] revision [hello-world-00005-mq4] has been deployed and is serving 100 percent of traffic. Service URL: https://hello-world-13746229022.us-central1.run.app
8. Управление языковыми пакетами Java Maven
В этом разделе вы узнаете, как настроить Java-репозиторий Artifact Registry и загружать в него пакеты, используя их в различных приложениях.
Создайте репозиторий пакетов Maven.
Для создания репозитория для Java-артефактов выполните следующую команду в Cloud Shell:
gcloud artifacts repositories create java-repo \
--repository-format=maven \
--location=us-central1 \
--description="Example Java Maven Repo"
Нажмите «Авторизовать», если появится запрос на авторизацию Cloud Shell.
Перейдите в консоль Google Cloud — Реестр артефактов — Репозитории и обратите внимание на свой недавно созданный репозиторий Maven с именем java-repo . Если вы щелкнете по нему, то увидите, что в данный момент он пуст.
Настройте аутентификацию в репозитории артефактов.
Используйте следующую команду, чтобы обновить общеизвестное местоположение учетных данных приложения по умолчанию (ADC) учетными данными вашей учетной записи пользователя, чтобы вспомогательная программа для работы с учетными данными реестра артефактов могла использовать их для аутентификации при подключении к репозиториям:
gcloud auth login --update-adc
Настройка Maven для реестра артефактов
Выполните следующую команду, чтобы вывести конфигурацию репозитория, которую необходимо добавить в ваш Java-проект:
gcloud artifacts print-settings mvn \
--repository=java-repo \
--location=us-central1 | tee config.xml
Откройте файл pom.xml в редакторе Cloud Shell, выполнив следующую команду в Cloud Shell из каталога helloworld:
cloudshell edit pom.xml
и добавьте полученные настройки в соответствующие разделы файла.
Обновите раздел distributionManagement.
<distributionManagement>
<snapshotRepository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</snapshotRepository>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</repository>
</distributionManagement>
Обновите раздел репозиториев.
<repositories>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
Обновите раздел расширений в разделе сборки.
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.1.0</version>
</extension>
</extensions>
Вот пример полного файла для вашего означения. Убедитесь, что вы заменили <PROJECT> на идентификатор вашего проекта.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example.run</groupId>
<artifactId>helloworld</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<parent>
<groupId>com.google.cloud.samples</groupId>
<artifactId>shared-configuration</artifactId>
<version>1.2.0</version>
</parent>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.source>17</maven.compiler.source>
<spring-boot.version>3.2.2</spring-boot.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<!-- [START Artifact Registry Config] -->
<distributionManagement>
<snapshotRepository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</snapshotRepository>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</repository>
</distributionManagement>
<repositories>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<build>
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.2.0</version>
</extension>
</extensions>
<!-- [END Artifact Registry Config] -->
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring-boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>3.4.0</version>
<configuration>
<to>
<image>gcr.io/PROJECT_ID/helloworld</image>
</to>
</configuration>
</plugin>
</plugins>
</build>
</project>
Загрузите свой Java-пакет в реестр артефактов.
После настройки Artifact Registry в Maven вы можете использовать Artifact Registry для хранения Java-JAR-файлов, которые будут использоваться другими проектами в вашей организации.
Выполните следующую команду, чтобы загрузить ваш Java-пакет в реестр артефактов:
mvn deploy
Проверьте наличие пакета Java в реестре артефактов.
Перейдите в Cloud Console - Artifact Registry - Repositorys. Щелкните java-repo и убедитесь, что там присутствует бинарный артефакт helloworld :
9. Поздравляем!
Поздравляем, вы завершили практическое занятие!
Что вы уже осветили
- Созданы репозитории для контейнеров и языковых пакетов.
- Управляемые образы контейнеров с использованием реестра артефактов.
- Интегрированный реестр артефактов с Cloud Code
- Настроил Maven для использования Artifact Registry для зависимостей Java.
Уборка
Выполните следующую команду в Cloud Shell, чтобы удалить весь проект.
gcloud projects delete $PROJECT_ID