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 artefak oleh konsumen saat Anda 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 dalam 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 secara 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 menyimpan salinannya dalam cache. 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 guna 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 menyimpan artefak publik dalam cache.

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 berbagai mode secara bersamaan. Diagram menunjukkan alur kerja di dua project Google Cloud . Dalam project pengembangan, developer membangun aplikasi Java. Dalam project runtime terpisah, build lain membuat image container dengan aplikasi untuk di-deploy ke Google Kubernetes Engine.

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

  1. Di project pengembangan, tim pengembangan Java menggunakan Cloud Build untuk membangun aplikasi Java.

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

  2. Di project runtime, Cloud Build akan memasukkan aplikasi Java ke dalam container.

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

  3. Di project runtime, Cloud Build mengupload image container yang dibangun 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 Google Cloud layanan memiliki manfaat yang dijelaskan di 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 lain.

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 lain yang berinteraksi dengan repositori. Tidak ada biaya untuk traffic keluar dari Artifact Registry ke layanan lain di region yang sama. Google Cloud

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

  • Untuk us multi-region, traffic keluar ke region di Amerika Serikat seperti us-central tidak dikenai biaya, sedangkan traffic keluar ke region di Kanada atau Amerika Selatan 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 tempat workload Anda berada. Streaming gambar dapat mengurangi waktu inisialisasi workload secara signifikan saat Anda menggunakan image container yang lebih besar karena workload 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 biaya keluar yang lebih rendah daripada repositori yang berlokasi di benua lain.

Membatasi lokasi repositori

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

Kebijakan pembersihan

Kebijakan pembersihan Artifact Registry menentukan kriteria untuk menghapus versi artefak secara otomatis yang tidak lagi Anda perlukan 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 penyimpanan, Artifact Registry akan menerapkan kebijakan penyimpanan.

Menghapus kebijakan

Kebijakan penghapusan menghapus artefak yang cocok dengan kriteria wajib berikut:

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

    • 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 diperlakukan sebagai untagged. Artefak yang diberi tag di repositori dengan tag yang tidak dapat diubah diaktifkan tidak dapat dihapus.

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

Berikut adalah cara opsional untuk menentukan kebijakan penghapusan Anda:

  • 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.
    • Awalan 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 mencocokkan 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 dalam 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 penyimpanan

Kebijakan penyimpanan menyimpan artefak yang cocok dengan kondisi yang sama seperti kebijakan penghapusan, atau sejumlah versi terbaru.

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 Pertahankan versi terbaru Anda ditetapkan untuk mempertahankan 3 versi paket yang cocok dengan Awalan paket: {release-xyz}, hanya release-xyz-v1, dan release-xyz-v2 yang dipertahankan.

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 Anda beralih dari Container Registry ke Artifact Registry, Anda dapat menyiapkan repositori gcr.io di Artifact Registry 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 agar kompatibel 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, batas kepercayaan, dan struktur tim.

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

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

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 memberikan akses secara eksplisit ke repositori untuk 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 Google Cloud layanan.
  • Anda sedang menyiapkan repositori virtual. Anda harus memberikan akses secara eksplisit kepada akun layanan Artifact Registry ke repositori upstream.

Untuk prinsipal lain yang memerlukan akses ke repositori, administrator repositori Anda harus memberikan akses. Dengan mengikuti prinsip keamanan 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 di 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 yang didukung Google Cloud . 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 memberikan cara untuk mengatur resource khusus untuk Google Cloud layanan. Di Artifact Registry, Anda dapat menambahkan label ke repositori sehingga Anda dapat mengelompokkannya atau memfilter daftar repositori menurut label. Misalnya, Anda dapat menggunakan label untuk mengelompokkan repositori menurut tahap pengembangan atau menurut tim untuk tujuan otomatisasi atau penagihan. Untuk mengetahui informasi selengkapnya tentang cara membuat dan menggunakan label repositori, lihat Memberi label pada repositori.

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

Langkah Berikutnya