Ringkasan repositori

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

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

Format repositori

Setiap repositori dikaitkan dengan format artefak tertentu. Misalnya, repositori Python menyimpan paket Python. 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 harus mengupload dan mendownload artefak langsung dengan repositori ini dan menggunakan Artifact Analysis untuk memindai kerentanan dan metadata lainnya.
Repositori jarak jauh

Repositori hanya baca yang berfungsi sebagai proxy untuk menyimpan artefak dari sumber eksternal preset seperti Docker Hub, Maven Central, Python Package Index (PyPI), Debian, atau CentOS, serta sumber yang ditentukan pengguna untuk format yang didukung. Saat pertama kali Anda meminta versi artefak, repositori akan mendownloadnya dari sumber eksternal dan menyimpan salinannya dalam cache. Repositori 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 mendeteksi kerentanan dan metadata lainnya.

Repositori virtual

Repositori hanya baca yang berfungsi sebagai titik akses tunggal 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 Anda untuk memprioritaskan repositori dengan artefak pribadi Anda daripada repositori jarak jauh yang meng-cache artefak publik.

Contoh penggunaan repositori

Diagram berikut menunjukkan salah satu dari banyak cara yang dapat dilakukan untuk menggunakan repositori dalam berbagai mode secara bersamaan. Diagram ini menunjukkan alur kerja di dua project Google Cloud. Dalam project pengembangan, developer mem-build aplikasi Java. Dalam project runtime yang terpisah, build lain membuat image container dengan aplikasi untuk deployment 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 membangun aplikasi Java.

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

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

    Build menggunakan repositori virtual Maven untuk mendownload aplikasi. Repositori virtual menayangkan 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 container yang telah 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. Penggunaan lokasi yang sama untuk layanan Google Cloud memiliki manfaat yang dijelaskan di Lokasi repositori.

Dukungan domain gcr.io

Artifact Registry mendukung hosting image di domain gcr.io. Jika beralih dari Container Registry ke Artifact Registry, Anda dapat menyiapkan repositori gcr.io 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 untuk kompatibilitas dengan perilaku Container Registry.

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

Lokasi repositori

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

Pertimbangan lokasi

Membuat repositori di region yang sama dengan layanan Google Cloud lainnya memiliki sejumlah manfaat:

  • Kurangi 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 lain di region yang sama tidak dikenai biaya.

    Meskipun tanpa biaya untuk traffic keluar dari multi-region ke layanan Google Cloud di region terkait, harga ini hanya berlaku untuk sekumpulan region tertentu.

    • Untuk multi-region us, traffic keluar ke sebuah 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 akan dikenai biaya, sedangkan traffic keluar ke region di Australia akan dikenai biaya.

  • Anda hanya dapat menggunakan streaming image di GKE dan Dataproc Serverless jika image container Anda disimpan dalam repositori Artifact Registry di region yang sama dengan workload atau multi-region yang sesuai dengan region dengan beban kerja Anda. Streaming gambar dapat mengurangi waktu inisialisasi beban kerja secara signifikan saat Anda menggunakan image container 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 dikenai biaya traffic keluar yang lebih rendah daripada repositori yang terletak di benua lain.

Membatasi lokasi repositori

Jika perlu mematuhi peraturan atau kebijakan yang mengharuskan Anda menyimpan data di region tertentu, Anda dapat menyertakan batasan lokasi resource dalam kebijakan organisasi Google Cloud yang hanya mengizinkan pembuatan repositori di region 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 sendiri artefak Anda ke repositori di lokasi yang mematuhi kebijakan, lalu menghapus repositori yang tidak mematuhi kebijakan.

Struktur project

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

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

Memusatkan repositori
Buat semua repositori dalam satu project, lalu berikan akses ke akun utama 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. Fitur ini juga dapat menyederhanakan penyiapan repositori virtual atau solusi seperti Software Delivery Shield 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 saat Anda memiliki kebijakan tata kelola data atau batas kepercayaan yang memerlukan lebih banyak pemisahan tingkat project dan kontrol resource.

Kontrol akses

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

Beberapa layanan Google Cloud, seperti Cloud Build, Cloud Run, dan GKE menggunakan akun layanan default dengan izin default ke repositori dalam project Google Cloud yang sama. Namun, setelan default ini mungkin tidak cocok untuk proses pengembangan software Anda, atau mungkin tidak mematuhi persyaratan kebijakan atau keamanan di organisasi Anda. Administrator repositori Anda harus secara eksplisit memberikan akses layanan ini ke repositori 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 memberi akun layanan Artifact Registry akses ke repositori upstream.

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

  • Anda akan 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 berada dalam pengembangan dan repositori produksi untuk aplikasi yang dirilis. Developer memerlukan akses baca dan tulis ke repositori pengembangan dan akses hanya baca ke repositori produksi.
  • Anda memiliki repositori demo dengan aplikasi contoh. Tim penjualan Anda hanya memerlukan akses hanya baca untuk mendownload demo.

Enkripsi data

Secara default, Google Cloud otomatis mengenkripsi data saat dalam penyimpanan menggunakan kunci enkripsi yang dikelola oleh Google. Jika memiliki persyaratan kepatuhan atau peraturan khusus yang terkait dengan 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 dapat mengelompokkannya atau memfilter daftar repositori berdasarkan label. Misalnya, Anda dapat menggunakan label untuk mengelompokkan repositori berdasarkan tahap pengembangan atau menurut tim untuk tujuan otomatisasi atau penagihan. Untuk informasi selengkapnya tentang membuat dan menggunakan label repositori, lihat Melabeli repositori.

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

Langkah Berikutnya