1. Обзор
Artifact Registry — это полностью управляемый менеджер пакетов, предоставляющий унифицированный инструмент для управления образами контейнеров OCI и языковыми пакетами (такими как Maven и npm).
Реестр артефактов полностью интегрирован с широким спектром других сервисов Google Cloud, как показано в следующих примерах:
- Cloud Build может напрямую загружать артефакты изображений в реестр артефактов.
- Cloud Deploy может развертывать образы реестра артефактов непосредственно в различных средах выполнения.
- Он предоставляет образы средам выполнения контейнеров, таким как Cloud Run и GKE, и обеспечивает расширенные возможности оптимизации производительности, такие как потоковая передача изображений.
- Реестр артефактов может служить точкой обнаружения для анализа артефактов для постоянного мониторинга известных уязвимостей.
- Cloud IAM обеспечивает последовательный и детальный контроль над доступом к артефактам и разрешениями.
В ходе этой лабораторной работы вы познакомитесь со многими из этих функций в форме практического руководства.
Что вы узнаете
Каковы цели обучения в этой лаборатории?
- Создайте разные репозитории для контейнеров и языковых пакетов.
- Создавайте и используйте образы контейнеров с помощью реестра артефактов.
- Используйте реестр артефактов для анализа состояния безопасности и содержимого ваших артефактов.
- Настройка и использование реестра артефактов для зависимостей Java Maven
2. Настройка и требования
Самостоятельная настройка среды
- Войдите в Google Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .
- Имя проекта — это отображаемое имя для участников этого проекта. Это строка символов, не используемая API Google. Вы всегда можете обновить его.
- Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (невозможно изменить после его установки). Cloud Console автоматически генерирует уникальную строку; обычно тебя не волнует, что это такое. В большинстве лабораторий кода вам потребуется указать идентификатор проекта (обычно идентифицируемый как
PROJECT_ID). Если вам не нравится сгенерированный идентификатор, вы можете создать другой случайный идентификатор. Альтернативно, вы можете попробовать свой собственный и посмотреть, доступен ли он. Его нельзя изменить после этого шага и он сохраняется на протяжении всего проекта. - К вашему сведению, есть третье значение — номер проекта , которое используют некоторые API. Подробнее обо всех трех этих значениях читайте в документации .
- Затем вам необходимо включить выставление счетов в Cloud Console, чтобы использовать облачные ресурсы/API. Прохождение этой лаборатории кода не будет стоить много, если вообще что-то стоить. Чтобы отключить ресурсы и избежать выставления счетов за пределами этого руководства, вы можете удалить созданные вами ресурсы или удалить проект. Новые пользователи 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 в реестре артефактов.
Как упоминалось ранее, реестр артефактов поддерживает различные форматы репозиториев, которые позволяют вам управлять образами контейнеров и языковыми пакетами. Взаимодействие с различными типами хранилищ артефактов определено в спецификациях и является широко распространенным стандартом. Например, запросы зависимостей Maven отличаются от запросов зависимостей Node.
Для поддержки определенных спецификаций API артефактов реестру артефактов необходимо управлять вашими артефактами в соответствующих типах репозиториев. Когда вы создаете новый репозиторий, вы передаете флаг --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 — Реестр артефактов — Репозитории и обратите внимание на недавно созданный репозиторий Docker с именемContainer container-example . Если вы нажмете на него, вы увидите, что в данный момент он пуст.
Настройка аутентификации Docker для реестра артефактов
При подключении к реестру артефактов для предоставления доступа требуются учетные данные. Вместо того, чтобы настраивать отдельные учетные данные, Docker можно настроить на беспрепятственное использование ваших учетных данных gcloud.
В Cloud Shell выполните следующую команду, чтобы настроить Docker для использования Google Cloud CLI для аутентификации запросов к реестру артефактов в регионе us-central1 :
gcloud auth configure-docker us-central1-docker.pkg.dev
Если команда запросит подтверждение изменения конфигурации докера 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 Console — Реестр артефактов — Хранилища . Откройте репозиторий 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, хранящийся в облачном хранилище. Если вы полагаетесь на SBOM для своих изображений, возможно, вы захотите автоматически генерировать SBOM для своих артефактов и сделать генерацию частью вашего конвейера CI/CD.
Исследование уязвимостей изображений
Щелкнув вкладку «Уязвимости» в верхней части представления, вы увидите все уязвимости, обнаруженные в вашем изображении. Помимо сводки уязвимостей вверху, вы можете увидеть полный список уязвимостей в таблице внизу. Каждая строка ссылается на бюллетень CVE, указывая степень серьезности и пакет, из которого она возникла. Для уязвимостей, для которых доступно исправление, также приведены инструкции по обновлению зависимостей для устранения уязвимости.
5. Виртуальные и удаленные репозитории
В предыдущем разделе мы использовали один репозиторий изображений для отправки и получения наших изображений. Это отлично подходит для небольших случаев использования, но создает проблемы, особенно для крупных организаций с разными командами, которым требуется автономия в отношении своих репозиториев. Команды или бизнес-подразделения обычно имеют собственный репозиторий изображений со своими разрешениями и конфигурацией. Чтобы упростить использование изображений в этих репозиториях и оградить потребителя от базовой организационной структуры, Artifact Registry предоставляет виртуальные репозитории, которые могут объединять ресурсы из нескольких базовых репозиториев. Потенциальная архитектура может выглядеть так:
Удаленный репозиторий для Docker Hub
Docker Hub — популярный общедоступный реестр образов, в котором размещено множество образов контейнеров с открытым исходным кодом. Хотя прямое использование общедоступного репозитория является простым, оно сопряжено с рядом проблем в производственной среде, которые мы можем преодолеть с помощью удаленных репозиториев в реестре артефактов.
Удаленные репозитории дают вам возможность пересылать запросы к вышестоящему реестру и кэшировать изображения по пути. Это не только сокращает время загрузки изображений, но также устраняет зависимость от времени безотказной работы внешней службы и дает вам возможность применять те же политики безопасности и доступа, которые вы применяете к своим собственным изображениям.
Чтобы создать удаленный репозиторий для 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
После успешного извлечения вы также можете просмотреть репозиторий в облачной консоли и убедиться, что кэшированный образ nginx теперь предоставляет те же отчеты о зависимостях и уязвимостях, которые мы видели для образа, который вы создали самостоятельно.
Создание виртуального репозитория
Следуя процессам, которые мы использовали до сих пор, вы можете создать несколько репозиториев для каждой команды или бизнеса и четко определить права собственности и разрешения IAM для каждого. Мы также можем создавать прокси для удаленных репозиториев, что упрощает и безопаснее использование сторонних изображений. Недостаток такого большого количества репозиториев становится очевидным, если вы сместите свою точку зрения на потребителя этих изображений. Как разработчик должен узнать, какой репозиторий изображений ему следует использовать при развертывании?
Чтобы упростить использование и скрыть базовые репозитории за уровнем абстракции, вы можете создать виртуальный репозиторий в реестре артефактов с помощью следующей команды в 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 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. Укрепление безопасности цепочки поставок
Теперь, когда ваш образ контейнера запущен в эксплуатацию, возможно, настало время подумать о том, как мы можем укрепить нашу сквозную цепочку поставок. В предыдущем разделе мы рассмотрели, как контейнерный анализ реестра артефактов позволяет получить представление о библиотеках и лицензиях, используемых в образе. Однако злоумышленники по-прежнему могут внедрить вредоносный контент в ваше изображение по всей цепочке поставок. В этом разделе мы рассмотрим, как мы можем использовать платформу 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, которое создает новую версию нашего образа 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 Console и просмотреть достигнутый нами уровень SLSA, открыв нашу сборку, а затем просмотрев артефакты сборки в разделе «Сводка сборки». На изображении есть кнопка для просмотра «Security Insights». Нажав на нее, вы увидите аттестацию 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.
В Cloud Shell выполните следующую команду, чтобы создать репозиторий для артефактов Java:
gcloud artifacts repositories create java-repo \
--repository-format=maven \
--location=us-central1 \
--description="Example Java Maven Repo"
Нажмите «Авторизовать», если появится запрос на авторизацию Cloud Shell.
Перейдите в Google Cloud Console — Реестр артефактов — Репозитории и обратите внимание на недавно созданный репозиторий 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>
<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 в реестр артефактов.
Настроив реестр артефактов в Maven, вы теперь можете использовать реестр артефактов для хранения файлов Java Jars для использования другими проектами в вашей организации.
Выполните следующую команду, чтобы загрузить пакет Java в реестр артефактов:
mvn deploy
Проверьте пакет Java в реестре артефактов.
Перейдите в Cloud Console — Реестр артефактов — Репозитории. Щелкните java-repo и проверьте наличие двоичного артефакта helloworld :
9. Поздравляем!
Поздравляем, вы завершили работу над кодом!
Что вы рассмотрели
- Созданы репозитории для контейнеров и языковых пакетов.
- Управляемые образы контейнеров с помощью реестра артефактов
- Интегрированный реестр артефактов с облачным кодом
- Настроен Maven для использования реестра артефактов для зависимостей Java.
Очистка
Выполните следующую команду в Cloud Shell, чтобы удалить весь проект.
gcloud projects delete $PROJECT_ID