1. Przegląd
Artifact Registry to usługa w pełni zarządzana, która udostępnia ujednolicone narzędzie do zarządzania obrazami kontenerów OCI i pakietami językowymi (takimi jak Maven i npm).
Artifact Registry jest w pełni zintegrowany z szeroką gamą innych usług Google Cloud, na przykład:
- Cloud Build może bezpośrednio przesyłać artefakty obrazów do Artifact Registry.
- Cloud Deploy może wdrażać obrazy Artifact Registry bezpośrednio w różnych środowiskach wykonawczych.
- Dostarcza obrazy do środowisk wykonawczych kontenerów, takich jak Cloud Run i GKE, oraz umożliwia zaawansowane funkcje optymalizacji wydajności, takie jak przesyłanie strumieniowe obrazów.
- Artifact Registry może służyć jako punkt wykrywania dla usługi Analiza artefaktów, która stale monitoruje znane luki w zabezpieczeniach.
- Cloud IAM zapewnia spójną i szczegółową kontrolę dostępu do artefaktów i uprawnień.
W tym module poznasz wiele z tych funkcji w formie praktycznego samouczka.
Czego się nauczysz
Jakie są cele tego modułu?
- Utwórz różne repozytoria dla kontenerów i pakietów językowych
- Tworzenie obrazów kontenerów i używanie ich w Artifact Registry
- Używaj Artifact Registry do analizowania stanu bezpieczeństwa i zawartości artefaktów
- Konfigurowanie i używanie Artifact Registry na potrzeby zależności Maven w Javie
2. Konfiguracja i wymagania
Samodzielne konfigurowanie środowiska
- Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub użyj istniejącego. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.
- Nazwa projektu to wyświetlana nazwa uczestników tego projektu. Jest to ciąg znaków, który nie jest używany przez interfejsy API Google. Zawsze możesz ją zaktualizować.
- Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić po ustawieniu. Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się tym przejmować. W większości ćwiczeń z programowania musisz odwoływać się do identyfikatora projektu (zwykle oznaczanego jako
PROJECT_ID). Jeśli wygenerowany identyfikator Ci się nie podoba, możesz wygenerować inny losowy identyfikator. Możesz też spróbować własnej nazwy i sprawdzić, czy jest dostępna. Po tym kroku nie można go zmienić i pozostaje on taki przez cały czas trwania projektu. - Warto wiedzieć, że istnieje też trzecia wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.
- Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Wykonanie tego laboratorium nie będzie kosztować dużo, a może nawet nic. Aby wyłączyć zasoby i uniknąć naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub projekt. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.
Konfigurowanie gcloud
W Cloud Shell ustaw identyfikator projektu i numer projektu. Zapisz je jako zmienne PROJECT_ID i PROJECT_NUMBER.
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
Włączanie usług 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
Pobieranie kodu źródłowego
Kod źródłowy tego modułu znajduje się w organizacji GoogleCloudPlatform na GitHubie. Skopiuj go za pomocą tego polecenia.
git clone https://github.com/GoogleCloudPlatform/java-docs-samples
3. Przekazywanie obrazów kontenerów
Tworzenie repozytorium Dockera w Artifact Registry
Jak wspomnieliśmy wcześniej, Artifact Registry obsługuje różne formaty repozytoriów, które umożliwiają zarządzanie obrazami kontenerów i pakietami językowymi. Interakcje z różnymi typami repozytoriów artefaktów są zdefiniowane w specyfikacjach i stanowią powszechnie przyjęte standardy. Na przykład żądania zależności Maven różnią się od żądań zależności Node.
Aby obsługiwać specyfikacje interfejsu API konkretnego artefaktu, Artifact Registry musi zarządzać artefaktami w odpowiednich typach repozytoriów. Podczas tworzenia nowego repozytorium przekazujesz flagę --repository-format, aby wskazać typ repozytorium.
Aby utworzyć pierwsze repozytorium obrazów Dockera, uruchom w Cloud Shell to polecenie:
gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"
Jeśli pojawi się prośba o autoryzację Cloud Shell, kliknij Autoryzuj.
Otwórz konsolę Google Cloud – Artifact Registry – Repozytoria i zwróć uwagę na nowo utworzone repozytorium Dockera o nazwie container-example. Jeśli je klikniesz, zobaczysz, że jest ono obecnie puste.
Konfigurowanie uwierzytelniania Dockera w Artifact Registry
Podczas łączenia się z Artifact Registry wymagane są dane logowania, aby zapewnić dostęp. Zamiast konfigurować oddzielne dane logowania, możesz skonfigurować Dockera tak, aby bezproblemowo korzystał z danych logowania gcloud.
Aby skonfigurować Dockera tak, aby używał Google Cloud CLI do uwierzytelniania żądań do Artifact Registry w regionie us-central1, uruchom w Cloud Shell to polecenie:
gcloud auth configure-docker us-central1-docker.pkg.dev
Jeśli polecenie wyświetli prośbę o potwierdzenie zmiany konfiguracji Dockera w Cloud Shell, naciśnij Enter.
Zapoznaj się z przykładową aplikacją
Przykładowa aplikacja jest dostępna w repozytorium Git sklonowanym w poprzednim kroku. Przejdź do katalogu java i sprawdź kod aplikacji.
cd java-docs-samples/run/helloworld/
ls
Folder zawiera przykładową aplikację w języku Java, która renderuje prostą stronę internetową. Oprócz różnych plików nieistotnych w tym konkretnym laboratorium zawiera kod źródłowy w folderze src oraz plik Dockerfile, którego użyjemy do utworzenia obrazu kontenera.
Tworzenie obrazu kontenera
Zanim zaczniesz przechowywać obrazy kontenerów w Artifact Registry, musisz utworzyć repozytorium.
Uruchom to polecenie, aby utworzyć obraz kontenera i oznaczyć go tagiem z pełną ścieżką do Artifact Registry:
docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .
Przesyłanie obrazu kontenera do Artifact Registry
Uruchom to polecenie, aby przesłać obraz kontenera do utworzonego wcześniej repozytorium:
docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1
Sprawdzanie obrazu w Artifact Registry
Otwórz konsolę Google Cloud – Artifact Registry – Repozytoria.. Otwórz repozytorium container-example i sprawdź, czy znajduje się w nim obraz java-hello-world.
Kliknij obraz i zwróć uwagę na obraz oznaczony tagiem tag1. Ponieważ włączyliśmy automatyczne skanowanie obrazów za pomocą usługi containerscanning.googleapis.com, możesz zobaczyć, że skanowanie pod kątem luk w zabezpieczeniach jest w toku lub zostało już zakończone. Po zakończeniu skanowania zobaczysz liczbę wykrytych luk w zabezpieczeniach w tej wersji obrazu. W następnej sekcji omówimy luki w zabezpieczeniach i inne informacje o artefaktach.
4. Sprawdzanie obrazów kontenerów
Po przesłaniu pierwszego obrazu do repozytorium container-example możemy przyjrzeć się mu bliżej. Na karcie wersji kliknij utworzoną przed chwilą wersję. Aby wyświetlić obraz w większym powiększeniu:
Przycisk kopiowania u góry jest szczególnie przydatny, ponieważ zapewnia łatwy dostęp do pełnego i jednoznacznego identyfikatora URI obrazu w tej wersji, w tym do skrótu SHA. Ten identyfikator URI może być następnie używany do pobierania określonej wersji obrazu lub jako odniesienie do obrazu we wdrożeniu Kubernetes lub usłudze Cloud Run. Aby przetestować URI obrazu, możesz uruchomić w Cloud Shell to polecenie:
docker pull $IMAGE_URI
Zależności
Na karcie „Zależności” u góry możesz zobaczyć wszystkie zależności wykryte na obrazie. Zwróć uwagę, że zawiera on zarówno zależności na poziomie języka, jak i systemu operacyjnego. Możesz też zobaczyć licencje na oprogramowanie dołączone do poszczególnych zależności.
Jeśli przyjrzysz się uważnie, zobaczysz, że informacje o SBOM nie zostały jeszcze wypełnione. Aby wypełnić SOM artefaktu, możesz uruchomić w Cloud Shell to polecenie, używając pełnego i jednoznacznego identyfikatora URI obrazu, który możesz skopiować z paska nawigacyjnego u góry.
gcloud artifacts sbom export --uri $IMAGE_URI
Po odświeżeniu strony będzie ona zawierać link do automatycznie wygenerowanego dokumentu SBOM przechowywanego w Cloud Storage. Jeśli korzystasz z SBOM dla swoich obrazów, możesz automatycznie generować SBOM dla swoich artefaktów i włączyć generowanie do potoku CI/CD.
Sprawdzanie luk w zabezpieczeniach obrazu
Gdy u góry widoku klikniesz kartę „Luki w zabezpieczeniach”, zobaczysz wszystkie luki w zabezpieczeniach wykryte na obrazie. Oprócz podsumowania luk w zabezpieczeniach u góry możesz zobaczyć pełną listę luk w zabezpieczeniach w tabeli u dołu. Każdy wiersz zawiera link do biuletynu CVE, który wskazuje poziom ważności i pakiet, z którego pochodzi. W przypadku luk w zabezpieczeniach, dla których dostępne jest rozwiązanie, zawiera też instrukcje aktualizowania zależności w celu usunięcia luki.
5. Wirtualne i zdalne repozytoria
W poprzedniej sekcji użyliśmy jednego repozytorium obrazów do wypychania i pobierania obrazów. Sprawdza się to w przypadku zastosowań na małą skalę, ale stwarza problemy, zwłaszcza w większych organizacjach z różnymi zespołami, które wymagają autonomii w zakresie swoich repozytoriów. Zespoły lub działy firmy często mają własne repozytorium obrazów z własnymi uprawnieniami i konfiguracją. Aby uprościć korzystanie z obrazów w tych repozytoriach i ukryć przed użytkownikiem podstawową strukturę organizacyjną, Artifact Registry udostępnia repozytoria wirtualne, które mogą agregować zasoby z wielu repozytoriów bazowych. Przykładowa architektura może wyglądać tak:
Zdalne repozytorium Docker Hub
Docker Hub to popularny publiczny rejestr obrazów, który zawiera wiele obrazów kontenerów typu open source. Bezpośrednie korzystanie z repozytorium publicznego jest proste, ale w środowisku produkcyjnym wiąże się z wieloma wyzwaniami, które możemy pokonać dzięki repozytoriom zdalnym w Artifact Registry.
Repozytoria zdalne umożliwiają przekazywanie żądań do rejestru nadrzędnego i buforowanie obrazów po drodze. Nie tylko skraca to czas pobierania obrazów, ale też eliminuje zależność od czasu działania usługi zewnętrznej i umożliwia stosowanie tych samych zasad bezpieczeństwa i dostępu, które obowiązują w przypadku własnych obrazów.
Aby utworzyć repozytorium zdalne dla Docker Hub, możesz uruchomić w Cloud Shell to polecenie:
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"
Na liście repozytoriów Artifact Registry powinno pojawić się dodatkowe repozytorium:
Aby sprawdzić, czy repozytorium zdalne może przekazywać żądania do repozytorium zdalnego, uruchom w Cloud Shell to polecenie, aby pobrać obraz nginx:
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine
Gdy pobieranie się powiedzie, możesz też sprawdzić repozytorium w konsoli Cloud i zobaczyć, że obraz nginx w pamięci podręcznej zawiera teraz te same raporty o zależnościach i lukach w zabezpieczeniach, które były widoczne w przypadku obrazu utworzonego samodzielnie.
Tworzenie repozytorium wirtualnego
Postępując zgodnie z dotychczasowymi procesami, możesz utworzyć wiele repozytoriów dla każdego zespołu lub firmy i wyraźnie określić własność oraz uprawnienia IAM dla każdego z nich. Możemy też tworzyć serwery proxy dla zdalnych repozytoriów, co ułatwia i zwiększa bezpieczeństwo korzystania z obrazów innych firm. Wadą tak dużej liczby repozytoriów jest to, że utrudnia to korzystanie z tych obrazów. Jak deweloper może sprawdzić, którego repozytorium obrazów powinien użyć w swoim wdrożeniu?
Aby uprościć korzystanie z repozytoriów i ukryć je za warstwą abstrakcji, możesz utworzyć wirtualne repozytorium w Artifact Registry za pomocą tego polecenia w 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"
Możemy teraz pobierać obrazy z wirtualnego repozytorium bez ujawniania jego struktury. Aby sprawdzić, czy wszystko działa zgodnie z oczekiwaniami, możesz uruchomić w Cloud Shell te polecenia:
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. Wdrożenie w Cloud Run
Po utworzeniu odpowiednich repozytoriów i obrazów możemy ich użyć we wdrożeniu. Aby zilustrować przykładowy przypadek użycia i uniknąć wdrażania dodatkowej infrastruktury, wdrożymy nasz kontener w Cloud Run. W najprostszej postaci wdrożenie można przeprowadzić, uruchamiając w Cloud Shell to polecenie:
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1 \
--allow-unauthenticated
Po zakończeniu wdrażania wyświetli się automatycznie wygenerowany adres URL, pod którym możesz uzyskać dostęp do usługi.
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
Jeśli otworzysz ten adres URL w nowej karcie przeglądarki, powinien wyświetlić się komunikat „Hello World”.
7. Wzmocnienie bezpieczeństwa łańcucha dostaw
Obraz kontenera został wdrożony na serwerze produkcyjnym, więc warto teraz przyjrzeć się temu, jak możemy wzmocnić nasz łańcuch dostaw. W poprzedniej sekcji omówiliśmy, jak analiza kontenerów w Artifact Registry dostarcza informacji o bibliotekach i licencjach używanych w obrazie. Jednak złośliwe podmioty mogą wprowadzić szkodliwe treści do obrazu w łańcuchu dostaw. W tej sekcji omówimy, jak za pomocą struktury SLSA wprowadzić atestowanie artefaktów kompilacji, a nawet wykorzystać podpisy kryptograficzne samych artefaktów, aby mieć pewność, że w środowisku wykonawczym Cloud Run można wdrażać tylko zaufane artefakty.
Atest SLSA w Cloud Build
Framework SLSA zapewnia różne poziomy dowodów dotyczących artefaktów łańcucha dostaw. Specyfikacja i wdrożenie mogą na pierwszy rzut oka wydawać się skomplikowane, ale dzięki Cloud Build tworzenie atestu SLSA jest tak proste, jak dodanie specyfikacji cloudbuild.yaml z ustawionym na VERIFIED parametrem requestedVerifyOption.
W przypadku naszej aplikacji możemy uruchomić w Cloud Shell to polecenie, aby utworzyć plik cloudbuild.yaml w folderze 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
Teraz utworzymy nowe zadanie Cloud Build, które skompiluje nową wersję obrazu Java Hello World. W tym celu uruchom to polecenie w Cloud Shell:
gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build
Po zakończeniu kompilacji możemy przejść do interfejsu Cloud Build w konsoli Google Cloud i wyświetlić osiągnięty poziom SLSA. W tym celu otwórz kompilację, a następnie w sekcji Podsumowanie kompilacji sprawdź artefakty kompilacji. Na obrazie znajduje się przycisk „Statystyki dotyczące bezpieczeństwa”. Po kliknięciu tego przycisku zobaczysz atest SLSA oraz znane raporty o lukach w zabezpieczeniach, które były wcześniej widoczne w interfejsie Artifact Registry po przesłaniu lokalnej kompilacji.
Pochodzenie SLSA naszego obrazu można też pobrać, uruchamiając w Cloud Shell to polecenie:
gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
--show-provenance
Wymaganie pochodzenia kompilacji Cloud Build w przypadku Binary Authorization
Skoro mamy już potok Cloud Build, czy nie warto zadbać o to, aby wszystkie obrazy wdrażane w środowisku produkcyjnym były tworzone w tym programowalnym i powtarzalnym środowisku kompilacji?
Właśnie tu do akcji wkracza usługa Binary Authorization. Umożliwia to umieszczenie przed środowiskami wykonawczymi kontenerów mechanizmu kontroli, który sprawdza obraz kontenera i weryfikuje istnienie zaufanego zaświadczenia. Jeśli nie znajdzie poświadczenia, utworzy wpisy w dzienniku kontrolnym lub całkowicie zablokuje wdrożenie (zależnie od konfiguracji).
Aby zmienić domyślną konfigurację Binary Authorization w projekcie tak, aby wymagała wbudowanego atestu wydanego przez Cloud Run, uruchom w Cloud Shell to polecenie:
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
Możesz też dodać własnych niestandardowych atestatorów, ale to wykracza poza zakres tego Codelabs i jest opcjonalnym zadaniem domowym.
Aby wymusić autoryzację binarną w usłudze Cloud Run, uruchom w Cloud Shell to polecenie:
gcloud run services update hello-world \
--region us-central1 \
--binary-authorization=default
Sprawdźmy, czy usługa Binary Authorization jest prawidłowo stosowana, najpierw ponownie wdrażając lokalnie utworzony obraz.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1
Powinien pojawić się komunikat o błędzie wyjaśniający, dlaczego nie można wdrożyć obrazu. Będzie on wyglądać mniej więcej tak:
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
Aby wdrożyć nową wersję w usłudze Cloud Run, musimy podać obraz utworzony za pomocą 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
Tym razem wdrożenie powinno się powieść i wyświetlić komunikat o udanym wdrożeniu podobny do tego poniżej:
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. Zarządzanie pakietami językowymi Java Maven
W tej sekcji dowiesz się, jak skonfigurować repozytorium Java w Artifact Registry i przesłać do niego pakiety, aby wykorzystywać je w różnych aplikacjach.
Tworzenie repozytorium pakietów Maven
Aby utworzyć repozytorium artefaktów Javy, uruchom w Cloud Shell to polecenie:
gcloud artifacts repositories create java-repo \
--repository-format=maven \
--location=us-central1 \
--description="Example Java Maven Repo"
Jeśli pojawi się prośba o autoryzację Cloud Shell, kliknij Autoryzuj.
Otwórz konsolę Google Cloud – Artifact Registry – Repozytoria. Zobaczysz nowo utworzone repozytorium Maven o nazwie java-repo. Jeśli je klikniesz, zobaczysz, że jest ono obecnie puste.
Konfigurowanie uwierzytelniania w Artifact Repository
Aby zaktualizować znaną lokalizację domyślnego uwierzytelniania aplikacji (ADC) za pomocą danych logowania konta użytkownika, tak aby pomocnik danych logowania Artifact Registry mógł ich używać do uwierzytelniania podczas łączenia się z repozytoriami, użyj tego polecenia:
gcloud auth login --update-adc
Konfigurowanie Mavena na potrzeby Artifact Registry
Uruchom to polecenie, aby wydrukować konfigurację repozytorium do dodania do projektu w Javie:
gcloud artifacts print-settings mvn \
--repository=java-repo \
--location=us-central1 | tee config.xml
Otwórz plik pom.xml w edytorze Cloud Shell, uruchamiając to polecenie w Cloud Shell w katalogu helloworld:
cloudshell edit pom.xml
i dodać zwrócone ustawienia do odpowiednich sekcji w pliku.
Zaktualizuj sekcję 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>
Zaktualizuj sekcję repozytoria.
<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>
Zaktualizuj sekcję rozszerzenia w sekcji kompilacja.
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.1.0</version>
</extension>
</extensions>
Oto przykład pełnego pliku. Pamiętaj, aby zastąpić <PROJECT> identyfikatorem projektu.
<?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>
Przesyłanie pakietu Java do Artifact Registry
Po skonfigurowaniu Artifact Registry w Maven możesz używać Artifact Registry do przechowywania plików JAR w języku Java, które będą wykorzystywane przez inne projekty w Twojej organizacji.
Aby przesłać pakiet Java do Artifact Registry, uruchom to polecenie:
mvn deploy
Sprawdzanie pakietu Java w Artifact Registry
Otwórz konsolę Cloud – Artifact Registry – Repozytoria. Kliknij java-repo i sprawdź, czy jest tam artefakt binarny helloworld:
9. Gratulacje!
Gratulacje! Codelab został ukończony.
Omówione zagadnienia
- Utworzone repozytoria kontenerów i pakietów językowych
- Zarządzanie obrazami kontenerów za pomocą Artifact Registry
- Zintegrowany Artifact Registry z Cloud Code
- Skonfigurowano Mavena do używania Artifact Registry w przypadku zależności Javy
Czyszczenie
Aby usunąć cały projekt, uruchom w Cloud Shell to polecenie:
gcloud projects delete $PROJECT_ID