1. Omówienie
Artifact Registry to w pełni zarządzany menedżer pakietów, który udostępnia ujednolicony sposób zarządzania obrazami kontenerów OCI i pakietami językowymi (np. Maven i npm).
Rejester artefaktów jest w pełni zintegrowany z szerokim zakresem innych usług Google Cloud, jak w tych przykładach:
- Cloud Build może przesyłać artefakty obrazów bezpośrednio do Artifact Registry.
- Cloud Deploy może wdrażać obrazy z rejestru artefaktów bezpośrednio do różnych środowisk uruchomieniowych.
- Udostępnia ona obrazy środowisk uruchomieniowych kontenerów, takich jak Cloud Run i GKE, oraz umożliwia zaawansowane funkcje optymalizacji wydajności, takie jak strumieniowanie obrazów.
- Rejestr artefaktów może służyć jako punkt wykrywania dla analizy artefaktów, aby stale monitorować znane luki w zabezpieczeniach.
- Cloud IAM zapewnia spójną i szczegółową kontrolę dostępu do artefaktów oraz uprawnień.
W tym laboratorium omówimy wiele z tych funkcji w ramach praktycznego samouczka.
Czego się nauczysz
Jakie są cele edukacyjne tego laboratorium?
- Utwórz oddzielne repozytoria dla kontenerów i pakietów językowych
- Tworzenie i używanie obrazów kontenerów za pomocą Artifact Registry
- Korzystanie z rejestru artefaktów do analizowania stanu zabezpieczeń i treści Twoich artefaktów
- Konfigurowanie i używanie Artifact Registry do obsługi zależności Maven w Javie
2. Konfiguracja i wymagania
Konfigurowanie środowiska we własnym tempie
- 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órego nie używają interfejsy API Google. Zawsze możesz ją zaktualizować.
- Identyfikator projektu jest niepowtarzalny w ramach wszystkich projektów Google Cloud i nie można go zmienić (po ustawieniu). Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie ma znaczenia, jaki to ciąg. W większości laboratoriów z kodem musisz podać identyfikator projektu (zwykle oznaczony jako
PROJECT_ID). Jeśli nie podoba Ci się wygenerowany identyfikator, możesz wygenerować inny losowy. Możesz też spróbować użyć własnego adresu e-mail, aby sprawdzić, czy jest on dostępny. Nie można go zmienić po wykonaniu tego kroku. Pozostanie on do końca projektu. - Informacyjnie: istnieje jeszcze 3 wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o wszystkich 3 wartościach znajdziesz w dokumentacji.
- Następnie musisz włączyć rozliczenia w konsoli Cloud, aby korzystać z zasobów i interfejsów API Cloud. Przejście przez ten samouczek nie będzie kosztowne, a być może nawet bezpłatne. Aby wyłączyć zasoby i uniknąć obciążenia opłatami po zakończeniu samouczka, możesz usunąć utworzone zasoby lub usunąć 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 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 laboratorium znajduje się w organizacji GoogleCloudPlatform na GitHubie. Skopiuj go za pomocą poniższego polecenia.
git clone https://github.com/GoogleCloudPlatform/java-docs-samples
3. Przekazywanie obrazów kontenerów
Tworzenie repozytorium Dockera w Artifact Registry
Jak już wspomnieliśmy, 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 są powszechnie stosowanymi standardami. Na przykład żądania zależności Maven różnią się od żądań zależności Node.
Aby obsługiwać specyfikacje interfejsu API artefaktu, usługa Artifact Registry musi zarządzać artefaktami w odpowiednich typach repozytoriów. Podczas tworzenia nowego repozytorium należy podać 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 Google Cloud Console – Rejestrowanie artefaktów – Repozytoria. Zwróć uwagę na nowo utworzone repozytorium Dockera o nazwie container-example. Jeśli klikniesz je, zobaczysz, że jest ono obecnie puste.
Konfigurowanie uwierzytelniania Dockera w Artifact Registry
Aby uzyskać dostęp do repozytorium artefaktów, musisz podać dane logowania. Zamiast konfigurować oddzielne dane logowania, możesz skonfigurować Dockera tak, aby korzystał z Twoich danych logowania gcloud.
W Cloud Shell uruchom to polecenie, aby skonfigurować Dockera tak, aby używał Google Cloud CLI do uwierzytelniania żądań do Artifact Registry w regionie us-central1:
gcloud auth configure-docker us-central1-docker.pkg.dev
Jeśli polecenie poprosi o potwierdzenie zmiany konfiguracji Dockera w Cloud Shell, naciśnij klawisz Enter.
Poznawanie przykładowej aplikacji
Przykładowa aplikacja znajduje się w repozytorium Git skopiowanym na poprzednim kroku. Przejdź do katalogu java i sprawdź kod aplikacji.
cd java-docs-samples/run/helloworld/
ls
Folder zawiera przykładową aplikację w Javie, która renderuje prostą stronę internetową. Oprócz różnych plików, które nie są istotne w tym konkretnym laboratorium, zawiera kod źródłowy w folderze src oraz plik Dockerfile, którego użyjemy do utworzenia obrazu kontenera.
Kompilowanie obrazu kontenera
Zanim będzie można przechowywać obrazy kontenerów w Artifact Registry, musisz utworzyć repozytorium.
Aby utworzyć obraz kontenera i oznaczyć go tagiem z pełną ścieżką do rejestru artefaktów, uruchom to polecenie:
docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .
Przesyłanie obrazu kontenera do Artifact Registry
Aby przesłać obraz kontenera do utworzonego wcześniej repozytorium, uruchom to polecenie:
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 etykietą 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 uruchomione lub już zakończone. Po zakończeniu procesu możesz zobaczyć 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
Ponieważ przesłałeś/przesłałaś pierwszy obraz do repozytorium container-example, możemy przyjrzeć mu się dokładniej. Na karcie Wersje kliknij wersję, którą właśnie utworzyliśmy. Aby wyświetlić obraz w większym przybliżeniu:
Górny przycisk kopiowania jest szczególnie przydatny, ponieważ umożliwia łatwy dostęp do pełnego identyfikatora URI obrazu w przypadku danej wersji obrazu, w tym do hasha SHA. Ten identyfikator URI można następnie wykorzystać do pobrania określonej wersji obrazu lub jako odwołania do obrazu w wdrożeniu Kubernetes lub usłudze Cloud Run. Aby przetestować identyfikator URI obrazu, uruchom w Cloud Shell to polecenie:
docker pull $IMAGE_URI
Zależność
Przechodząc na kartę „Zależności” u góry, zobaczysz wszystkie zależności wykryte na obrazie. Pamiętaj, że zawiera ona zależności na poziomie języka i systemu operacyjnego. Możesz też zobaczyć licencje na oprogramowanie powiązane z poszczególnymi zależnościami.
Przyjrzyj się uważnie i zobaczysz, że informacje SBOM nie zostały jeszcze wypełnione. Aby wypełnić informacje o SOM dla artefaktu, możesz uruchomić to polecenie w Cloud Shell, używając pełnego 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 znajdziesz na niej link do automatycznie wygenerowanego pliku SBOM zapisanego w Cloud Storage. Jeśli korzystasz z SBOM w przypadku obrazów, możesz automatycznie generować SBOM dla swoich artefaktów i utworzyć część procesu CI/CD, która będzie odpowiadać za generowanie.
Badanie luk w zabezpieczeniach obrazów
Gdy klikniesz kartę „Wady” u góry widoku, zobaczysz wszystkie luki w zabezpieczeniach wykryte na obrazie. Oprócz podsumowania podanego u góry strony w tabeli u dołu znajdziesz pełną listę luk w zabezpieczeniach. Każdy wiersz zawiera link do biuletynu CVE, który wskazuje na jego ważność i pakiet, z którego pochodzi. W przypadku luk, dla których dostępna jest poprawka, zawiera ona również instrukcje dotyczące aktualizacji zależności, które pozwolą usunąć lukę.
5. Wirtualne i zdalne repozytoria
W poprzedniej sekcji do wypychania i ściągania obrazów użyliśmy pojedynczego repozytorium obrazów. Jest to świetne rozwiązanie w przypadku mniejszych zastosowań, ale wiąże się z pewnymi wyzwaniami, zwłaszcza w większych organizacjach z różnymi zespołami, które wymagają autonomii w przypadku swoich repozytoriów. Zwykle zespoły lub działy firmy mają własne repozytorium obrazów z własnymi uprawnieniami i konfiguracją. Aby uprościć korzystanie z obrazów w tych repozytoriach i chronić użytkownika przed podstawową strukturą organizacyjną, Artifact Registry udostępnia repozytoria wirtualne, które mogą agregować zasoby z wielu repozytoriów podstawowych. Architektura może wyglądać tak:
Repozytorium zdalne dla Docker Hub
Docker Hub to popularna publiczna rejestracja obrazów, która hostuje wiele obrazów kontenera open source. Korzystanie bezpośrednio z publicznego repozytorium jest proste, ale wiąże się z wieloma wyzwaniami w środowisku produkcyjnym, które możemy pokonać za pomocą repozytoriów zdalnych w Artifact Registry.
Repositoria zdalne umożliwiają przekierowywanie żądań do rejestru źródłowego i przechowywanie w pamięci podręcznej obrazów. Dzięki temu nie tylko skrócisz czas pobierania obrazów, ale też nie będziesz zależny od dostępności usługi zewnętrznej i zyskasz możliwość zastosowania tych samych zasad bezpieczeństwa i dostępu, które stosujesz w przypadku własnych obrazów.
Aby utworzyć zdalne repozytorium dla Docker Hub, uruchom 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 zdalne repozytorium może przekierowywać żądania do zdalnego repozytorium, uruchom w Cloud Shell to polecenie, aby pobrać obraz nginx:
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine
Po pomyślnym pobraniu możesz też sprawdzić repozytorium w konsoli Cloud i sprawdzić, czy obraz nginx w pamięci podręcznej zawiera te same informacje o zależnościach i lukach w zabezpieczeniach, co obraz, który został przez Ciebie utworzony.
Tworzenie repozytorium wirtualnego
Stosując procesy stosowane do tej pory, 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 ubezpiecza korzystanie z obrazów innych firm. Minusem tak dużej liczby repozytoriów jest to, że użytkownicy tych obrazów mogą mieć z tym problem. Jak deweloper może ustalić, którego repozytorium obrazów użyć podczas wdrażania?
Aby uprościć korzystanie z repozytorium i ukryć jego podrzędne repozytoria za warstwą abstrakcji, możesz utworzyć w Artifact Registry repozytorium wirtualne, używając 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"
Teraz możemy pobierać obrazy z wirtualnego repozytorium bez ujawniania struktury podstawowej. Aby sprawdzić, czy wszystko działa zgodnie z oczekiwaniami, uruchom 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 repozytoriów i obrazu możemy teraz użyć ich w ramach wdrożenia. Aby zilustrować przykładowy przypadek użycia i uniknąć wdrażania dodatkowej infrastruktury, wdrożymy kontener w Cloud Run. W najprostszej formie wdrożenie można wykonać, 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
Teraz, gdy obraz kontenera został wdrożony, warto zastanowić się, jak możemy wzmocnić nasz łańcuch dostaw. W poprzedniej sekcji omówiliśmy, jak analiza kontenera w Artifact Registry dostarcza informacji o bibliotekach i licencjach używanych w obrazie. Nadal jednak możliwe jest, że osoby o złośliwych zamiarach wprowadzą szkodliwe treści do Twojego obrazu w łańcuchu dostawy. W tej sekcji omówimy, jak można użyć ramy SLSA do wprowadzenia uwierzytelniania artefaktów kompilacji, a nawet wykorzystać podpisy kryptograficzne samych artefaktów, aby zapewnić, że tylko zaufane artefakty będą mogły być wdrażane w środowisku wykonawczym Cloud Run.
Weryfikacja SLSA za pomocą Cloud Build
Ramy SLSA zapewniają różne poziomy dowodów dla artefaktów łańcucha dostaw. Specyfikacja i wdrożenie mogą na pierwszy rzut oka wydawać się przytłaczające, ale w Cloud Build tworzenie oświadczenia SLSA jest tak proste jak dodanie specyfikacji cloudbuild.yaml z wartością requestedVerifyOption ustawioną na VERIFIED.
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 utwórz nowe zadanie Cloud Build, które skompiluje nową wersję obrazu Hello World w języku Java. Aby to zrobić, 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żesz przejść do interfejsu Cloud Build w konsoli Google Cloud i wyświetlić poziom SLSA, który osiągnąłeś, otwierając kompilację i sprawdzając artefakty kompilacji w sekcji Podsumowanie kompilacji. Na obrazie znajduje się przycisk, który umożliwia wyświetlenie „Statystyk zabezpieczeń”. Po kliknięciu zobaczysz potwierdzenie SLSA oraz znane raporty o lukach w zabezpieczeniach, które wcześniej pojawiły się w interfejsie rejestru artefaktów, gdy przesłaliśmy lokalną wersję.
Źródło danych SLSA dla obrazu można też pobrać, wykonują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 w Cloud Build za pomocą autoryzacji plików binarnych
Dzięki użyciu potoku Cloud Build można mieć pewność, że wszystkie obrazy wdrażane w produkcji zostały utworzone za pomocą tego programowalnego i powtarzalnego środowiska kompilacji.
Właśnie w tym miejscu pojawia się autoryzacja plików binarnych. Umożliwia to umieszczenie bramy przed środowiskiem uruchomieniowym kontenera, która sprawdza obraz kontenera i weryfikuje istnienie zaufanego poświadczenia. Jeśli nie zostanie znaleziona żadna weryfikacja, w zależności od konfiguracji usługa utworzy wpisy w dzienniku kontrolnym lub całkowicie zablokuje wdrożenie.
Aby zmienić domyślną konfigurację autoryzacji binarnej w naszym projekcie tak, aby wymagała wbudowanego poświadczenia wydanego przez Cloud Run, uruchamiamy 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
Oczywiście możesz też dodać własne certyfikatory, ale nie jest to objęte zakresem tego CodeLab. Możesz to zrobić jako dodatkowe ćwiczenie poza programem.
Aby wymusić uwierzytelnianie binarne w usłudze Cloud Run, uruchom w Cloud Shell to polecenie:
gcloud run services update hello-world \
--region us-central1 \
--binary-authorization=default
Przetestujmy, czy usługa Binary Authorization została prawidłowo zastosowana, ponownie wdrażając obraz utworzony lokalnie.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1
Zgodnie z oczekiwaniami powinien pojawić się komunikat o błędzie, który wyjaśnia, dlaczego nie można wdrożyć obrazu.
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 naszej 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żeniu powinno się udać i powinien wyświetlić się 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 Maven w Javie
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 dla artefaktów Java, 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 i zwróć uwagę na nowo utworzone repozytorium Maven o nazwie java-repo. Po kliknięciu tego repozytorium zobaczysz, że jest ono obecnie puste.
Konfigurowanie uwierzytelniania w repozytorium artefaktów
Użyj tego polecenia, aby zaktualizować dobrze znaną lokalizację domyślnych danych logowania aplikacji (ADC) za pomocą danych logowania na koncie użytkownika, dzięki czemu pomocnik danych logowania rejestru artefaktów będzie mógł uwierzytelniać się za ich pomocą podczas łączenia z repozytoriami:
gcloud auth login --update-adc
Konfigurowanie Mavena w Artifact Registry
Aby wydrukować konfigurację repozytorium, którą chcesz dodać do projektu w Javie, uruchom to polecenie:
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 w Cloud Shell to polecenie 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ć ciąg znaków <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 repozytorium Artifact Registry w Maven możesz używać tego repozytorium do przechowywania plików Java Jars, aby były dostępne dla innych projektów w Twojej organizacji.
Aby przesłać pakiet Java do Artifact Registry, uruchom to polecenie:
mvn deploy
Sprawdzanie pakietu Javy w Artifact Registry
Otwórz Cloud Console – Artifact Registry – Repositories (Konsola Cloud – Artifact Registry – Repozytoria). Kliknij java-repo i sprawdź, czy znajduje się tam binarny element helloworld:
9. Gratulacje!
Gratulacje! Masz ukończoną tę lekcję.
Omówione zagadnienia
- Utworzono repozytoria dla kontenerów i pakietów językowych
- Zarządzanie obrazami kontenerów za pomocą Artifact Registry
- Zintegrowana usługa Artifact Registry z Cloud Code
- skonfigurować Maven do używania Artifact Registry do obsługi zależności Javy.
Czyszczenie
Aby usunąć cały projekt, uruchom w Cloud Shell to polecenie:
gcloud projects delete $PROJECT_ID