Ringkasan repositori

Artifact Registry memungkinkan Anda menyimpan berbagai jenis artefak, membuat beberapa repositori dalam satu project, dan mengaitkan lokasi regional atau multi-regional tertentu dengan setiap repositori. Halaman ini menjelaskan pertimbangan untuk membantu Anda merencanakan lokasi dan organisasi repositori.

Pertimbangkan proses internal untuk membuat artefak dan penggunaan oleh konsumen artefak Anda saat membuat repositori.

Format repositori

Setiap repositori dikaitkan dengan format artefak tertentu. Misalnya, repositori Docker menyimpan image Docker. Anda dapat membuat beberapa repositori untuk setiap format di project Google Cloud yang sama.

Mode repositori

Ada beberapa mode repositori. Setiap mode memiliki tujuan yang berbeda, sehingga Anda tidak dapat mengubah mode repositori setelah membuat repositori.

Repositori standar

Repositori standar adalah repositori Artifact Registry reguler untuk artefak pribadi Anda. Anda mengupload dan mendownload artefak langsung dengan repositori ini dan menggunakan Artifact Analysis untuk memindai kerentanan dan metadata lainnya.

Untuk membuat repositori standar, ikuti langkah-langkah di Membuat repositori standar.

Repositori jarak jauh

Repositori jarak jauh adalah repositori hanya baca yang bertindak sebagai proxy untuk menyimpan artefak dari sumber upstream berikut:

  • Repositori Artifact Registry standar.
  • Sumber eksternal seperti Docker Hub, Maven Central, Python Package Index (PyPI), Debian, atau CentOS.

Saat pertama kali Anda meminta versi artefak, repositori akan mendownloadnya dari sumber upstream dan meng-cache salinannya. Repositori jarak jauh menayangkan salinan yang di-cache saat versi yang sama diminta lagi.

Repositori jarak jauh mengurangi latensi dan meningkatkan ketersediaan untuk build dan deployment di Google Cloud. Anda juga dapat menggunakan Artifact Analysis untuk memindai paket yang di-cache untuk menemukan kerentanan dan metadata lainnya.

Untuk mempelajari repositori jarak jauh lebih lanjut, baca Ringkasan repositori jarak jauh. Untuk membuat repositori jarak jauh, ikuti langkah-langkah di Membuat repositori jarak jauh.

Repositori virtual

Repositori hanya baca yang berfungsi sebagai satu titik akses untuk mendownload, menginstal, atau men-deploy artefak dengan format yang sama dari satu atau beberapa repositori upstream. Repositori upstream dapat berupa repositori standar, jarak jauh, atau virtual.

Repositori virtual menyederhanakan konfigurasi klien untuk konsumen artefak Anda. Anda juga dapat memitigasi serangan kebingungan dependensi dengan mengonfigurasi kebijakan upstream untuk memprioritaskan repositori dengan artefak pribadi Anda daripada repositori jarak jauh yang meng-cache artefak publik.

Untuk mempelajari repositori virtual lebih lanjut, baca Ringkasan repositori virtual. Untuk membuat repositori virtual, ikuti langkah-langkah dalam Membuat repositori virtual.

Contoh penggunaan repositori

Diagram berikut menunjukkan salah satu dari banyak kemungkinan cara Anda dapat menggunakan repositori dalam mode yang berbeda secara bersamaan. Diagram menunjukkan alur kerja di dua project Google Cloud. Dalam project pengembangan, developer mem-build aplikasi Java. Dalam project runtime terpisah, build lain akan membuat image container dengan aplikasi untuk di-deploy ke Google Kubernetes Engine.

Repositori standar, virtual, dan jarak jauh yang digunakan di dua project.

  1. Dalam project pengembangan, tim pengembangan Java menggunakan Cloud Build untuk mem-build aplikasi Java.

    • Build dapat meminta dependensi Java publik menggunakan repositori virtual. Repositori virtual menayangkan dependensi dari repositori jarak jauh, yang merupakan proxy penyimpanan dalam cache untuk Maven Central.
    • Cloud Build mengupload paket ke repositori Maven standar dalam project komponen.

  2. Dalam project runtime, Cloud Build mengemas aplikasi Java.

    Build menggunakan repositori virtual Maven untuk mendownload aplikasi. Repositori virtual menyediakan paket dari repositori standar dalam project pengembangan. Build juga dapat mendownload dependensi Java publik dari repositori virtual yang sama.

  3. Dalam project runtime, Cloud Build mengupload image penampung yang di-build ke repositori Docker standar.

  4. GKE mengambil image dari repositori virtual Docker.

    • Repositori Docker standar upstream menyediakan image pribadi, seperti aplikasi Java dalam container.
    • Repositori jarak jauh upstream menyediakan image yang diminta GKE dari Docker Hub.

Dalam contoh ini, semua repositori, build, dan cluster GKE berada di region yang sama. Menggunakan lokasi yang sama untuk layanan Google Cloud memiliki manfaat yang dijelaskan dalam Lokasi repositori.

Lokasi repositori

Anda dapat membuat satu atau beberapa repositori di region atau multi-region yang didukung. Lokasi repositori yang baik menyeimbangkan biaya latensi, ketersediaan, dan bandwidth untuk konsumen data. Organisasi Anda mungkin juga memiliki persyaratan kepatuhan tertentu.

Pertimbangan lokasi

Bagian ini menjelaskan alasan Anda mungkin ingin membuat repositori di region yang sama dengan layanan Google Cloud lainnya.

Anda dapat mengurangi latensi dan biaya traffic keluar jaringan dengan membuat repositori di region yang sama tempat Anda menjalankan GKE, Cloud Run, Cloud Build, dan layanan Google Cloud lainnya yang berinteraksi dengan repositori. Traffic keluar dari Artifact Registry ke layanan Google Cloud lainnya di region yang sama tidak dikenai biaya.

Meskipun tidak ada biaya untuk traffic keluar dari multi-region ke layanan Google Cloud di region yang sesuai, harga ini hanya berlaku untuk sekumpulan region terbatas.

  • Untuk multi-region us, traffic keluar ke region di Amerika Serikat seperti us-central tidak dikenai biaya, sedangkan ke region mana pun di Kanada atau Amerika Selatan akan dikenai biaya.
  • Untuk multi-region asia, traffic keluar ke region di Asia seperti asia-northeast1 tidak dikenai biaya, tetapi traffic keluar ke region di Australia dikenai biaya.
Anda hanya dapat menggunakan streaming image di GKE dan Dataproc Serverless jika image container Anda disimpan di repositori Artifact Registry di region yang sama dengan workload Anda atau multi-region yang sesuai dengan region dengan workload Anda. Streaming gambar dapat mengurangi waktu inisialisasi beban kerja secara signifikan saat Anda menggunakan image penampung yang lebih besar karena beban kerja dapat dimulai sebelum seluruh image didownload.

Pertimbangkan lokasi konsumen di luar Google Cloud. Misalnya, jika tim developer Anda di Australia perlu mendownload artefak dari Artifact Registry ke workstation lokal mereka, repositori di region Australia akan mengurangi latensi dan menimbulkan tagihan keluar yang lebih rendah daripada repositori yang terletak di benua lain.

Membatasi lokasi repositori

Jika Anda perlu mematuhi peraturan atau kebijakan yang mengharuskan Anda menyimpan data di wilayah tertentu, Anda dapat menyertakan batasan lokasi resource dalam kebijakan organisasi Google Cloud yang hanya mengizinkan pembuatan repositori di wilayah yang mematuhi kebijakan. Artifact Registry hanya menerapkan batasan setelah Anda menyertakannya dalam kebijakan organisasi. Jika Anda memiliki repositori yang ada di lokasi yang tidak mematuhi kebijakan, Anda harus memindahkan artefak ke repositori di lokasi yang mematuhi kebijakan, lalu menghapus repositori yang tidak mematuhi kebijakan.

Kebijakan pembersihan

Kebijakan pembersihan Artifact Registry menentukan kriteria untuk menghapus versi artefak yang tidak lagi Anda perlukan secara otomatis atau menyimpan artefak yang ingin Anda simpan tanpa batas waktu.

Kebijakan pembersihan berguna jika Anda menyimpan banyak versi artefak, tetapi hanya perlu menyimpan versi tertentu yang Anda rilis ke produksi. Anda dapat menentukan kebijakan penghapusan dengan kriteria untuk menghapus artefak dan kebijakan penyimpanan dengan kriteria untuk mempertahankan artefak.

Jika versi artefak cocok dengan kriteria dalam kebijakan penghapusan dan kebijakan simpan, Artifact Registry akan menerapkan kebijakan simpan.

Menghapus kebijakan

Kebijakan hapus akan menghapus artefak yang cocok dengan kriteria yang diperlukan berikut:

  • Status tag: menunjukkan apakah kebijakan harus memeriksa artefak yang diberi tag atau artefak yang tidak diberi tag. Artefak diberi tag saat mengirim atau mengambil image ke atau dari repositori. Untuk mengetahui informasi selengkapnya tentang tag Docker, lihat Konsep penampung.

    • Status tag apa pun: mengabaikan status tag dan berlaku untuk artefak yang diberi tag dan tidak diberi tag.
    • Diberi tag: hanya berlaku untuk artefak yang diberi tag.
    • Tidak diberi tag: hanya berlaku untuk artefak yang tidak diberi tag.

    Format yang tidak mendukung tag akan diperlakukan sebagai untagged. Artefak bertag di repositori dengan tag yang tidak dapat diubah diaktifkan tidak dapat dihapus.

    Untuk mengetahui informasi selengkapnya tentang status tag yang berlaku untuk kebijakan pembersihan, lihat referensi TagState.

Berikut adalah cara opsional untuk menentukan kebijakan penghapusan:

  • Awalan tag: adalah daftar awalan tag yang dipisahkan koma. Misalnya, awalan test, dan staging akan cocok dengan gambar dengan tag testenv dan staging-1.5. tagState harus ditetapkan ke TAGGED untuk menggunakan awalan tag.
    • Awal versi: - adalah daftar awalan versi artefak yang dipisahkan koma. Misalnya, v1, v2 akan cocok dengan versi v1.5, v2.0alpha, dan v10.2.
  • Awalan paket: adalah daftar awalan nama artefak. Anda dapat memasukkan beberapa awalan dengan menekan Enter atau , di antara awalan. Misalnya, red, blue akan membuat dua awalan, red dan blue, serta akan cocok dengan nama artefak red-team, redis, dan bluebird.
  • Lebih lama dari: adalah waktu minimum sejak versi artefak diupload ke repositori, yang ditentukan sebagai durasi. Misalnya, 30d adalah 30 hari. Anda dapat menentukan durasi detik, menit, jam, atau hari dengan menambahkan s, m, h, atau d.
  • Lebih baru dari: adalah waktu maksimum sejak versi artefak diupload ke repositori, yang ditentukan sebagai durasi. Misalnya, 30d adalah 30 hari.

Kebijakan Keep

Kebijakan simpan menyimpan artefak yang cocok dengan kondisi yang sama seperti kebijakan hapus, atau jumlah versi terbaru yang ditetapkan.

Misalnya, dengan repositori yang berisi artefak berikut:

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-west1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

Jika kebijakan Simpan versi terbaru Anda ditetapkan untuk menyimpan 3 versi paket yang cocok dengan Awalan paket: {release-xyz}, hanya release-xyz-v1, dan release-xyz-v2 yang disimpan.

Penghapusan yang dipicu oleh kebijakan penghapusan diperhitungkan dalam kuota permintaan penghapusan per project Artifact Registry Anda.

Untuk membuat dan menerapkan kebijakan pembersihan ke repositori Anda, lihat Mengonfigurasi kebijakan pembersihan.

Dukungan domain gcr.io

Artifact Registry mendukung hosting image di domain gcr.io. Jika bertransisi dari Container Registry ke Artifact Registry, Anda dapat menyiapkan Artifact Registry repositori gcr.io untuk meminimalkan perubahan pada otomatisasi dan alur kerja yang ada. Repositori ini menyediakan:

  • Pengalihan permintaan ke domain gcr.io.
  • Pembuatan repositori gcr.io saat image pertama dikirim ke nama host gcr.io untuk kompatibilitas dengan perilaku Container Registry.

Untuk mengetahui informasi selengkapnya, lihat Transisi ke repositori dengan dukungan domain gcr.io

Struktur project

Hierarki resource adalah cara Anda mengatur resource di seluruh project Google Cloud. Struktur yang Anda pilih bergantung pada faktor-faktor seperti persyaratan tata kelola data, batasan kepercayaan, dan struktur tim.

Ada dua pendekatan umum untuk menyiapkan repositori di organisasi multi-project.

Memusatkan repositori
Buat semua repositori dalam satu project, lalu berikan akses ke prinsipal dari project lain di level repositori. Pendekatan ini dapat lebih efektif jika satu orang atau tim menangani administrasi repositori dan akses repositori di seluruh organisasi Anda.
Hal ini juga dapat menyederhanakan penyiapan repositori virtual karena Anda hanya perlu mengaktifkan dan mengelola satu instance Artifact Registry.
Repositori khusus project
Membuat repositori dalam project yang menyimpan dan mendownload artefak. Pendekatan ini mungkin diperlukan jika Anda memiliki kebijakan tata kelola data atau batas kepercayaan yang memerlukan lebih banyak pemisahan dan kontrol resource di tingkat project.

Kontrol akses

Repositori hanya dapat diakses dengan izin yang sesuai, kecuali jika Anda mengonfigurasi repositori untuk akses publik. Anda dapat memberikan izin di tingkat project atau repositori.

Beberapa layanan Google Cloud menggunakan akun layanan default dengan izin default ke repositori dalam project Google Cloud yang sama. Namun, setelan default ini mungkin tidak sesuai untuk proses pengembangan software Anda atau mungkin tidak mematuhi persyaratan keamanan atau kebijakan di organisasi Anda. Administrator repositori Anda harus secara eksplisit memberikan akses ke repositori kepada layanan ini jika:

  • Artifact Registry berada di project yang berbeda dengan layanan yang berinteraksi dengannya.
  • Anda menggunakan peran IAM kustom dengan akun layanan default, bukan peran bawaan.
  • Anda tidak menggunakan akun layanan default untuk layanan Google Cloud.
  • Anda sedang menyiapkan repositori virtual. Anda harus secara eksplisit memberikan akses akun layanan Artifact Registry ke repositori upstream.

Untuk akun utama lain yang memerlukan akses ke repositori, administrator repositori Anda harus memberikan akses. Berdasarkan prinsip keamanan dengan hak istimewa terendah, berikan izin minimum yang diperlukan. Contoh:

  • Anda men-deploy image container di Artifact Registry ke cluster GKE di beberapa project yang berbeda. Akun layanan untuk node dalam cluster ini hanya memerlukan akses baca ke repositori.
  • Anda memiliki repositori pengembangan untuk aplikasi yang sedang dalam pengembangan dan repositori produksi untuk aplikasi yang dirilis. Developer memerlukan akses baca dan tulis ke repositori pengembangan dan akses baca saja ke repositori produksi.
  • Anda memiliki repositori demo dengan aplikasi contoh. Tim penjualan Anda hanya memerlukan akses hanya baca untuk mendownload demo.

Membatasi download artefak

Anda dapat membatasi download artefak dengan aturan download. Aturan download memungkinkan Anda mengizinkan atau menolak download artefak dari repositori dan paket. Anda juga dapat menetapkan kondisi agar aturan berlaku untuk tag atau versi tertentu.

Untuk mengetahui detail tentang cara kerja aturan download, lihat bagian Membatasi download artefak dalam ringkasan Mengontrol akses dan melindungi artefak.

Enkripsi data

Secara default, Google Cloud otomatis mengenkripsi data saat dalam penyimpanan menggunakan kunci milik dan dikelola Google. Jika Anda memiliki persyaratan kepatuhan atau peraturan khusus terkait kunci yang melindungi data, Anda dapat membuat repositori yang dienkripsi dengan kunci enkripsi yang dikelola pelanggan (CMEK).

Artifact Registry juga mendukung batasan kebijakan organisasi yang dapat mewajibkan CMEK untuk melindungi resource.

Label dan tag

Label menyediakan cara untuk mengatur resource khusus untuk layanan Google Cloud. Di Artifact Registry, Anda dapat menambahkan label ke repositori sehingga Anda dapat mengelompokkan repositori atau memfilter daftar repositori menurut label. Misalnya, Anda dapat menggunakan label untuk mengelompokkan repositori berdasarkan tahap pengembangan atau menurut tim untuk tujuan penagihan atau otomatisasi. Untuk informasi selengkapnya tentang cara membuat dan menggunakan label repositori, lihat Memberi label pada repositori.

Anda juga dapat menerapkan tag ke repositori. Meskipun label terutama untuk mengatur dan memfilter resource khusus layanan, tag digunakan untuk kontrol terprogram atas kebijakan di seluruh organisasi Google Cloud. Untuk informasi selengkapnya, lihat Memberi tag pada repositori.

Langkah Berikutnya