Tutorial: Pengujian validasi otomatis

Sebagai bagian dari setiap penerapan yang membangun layanan data berkemampuan Arc, Microsoft menjalankan alur CI/CD otomatis yang melakukan pengujian end-to-end. Pengujian ini diorkestrasi melalui dua kontainer yang dipertahankan bersama produk inti (Pengontrol Data, SQL Managed Instance yang diaktifkan oleh server Azure Arc & PostgreSQL). Kontainer ini adalah:

• arc-ci-launcher: Berisi dependensi penyebaran (misalnya, ekstensi CLI), serta kode penyebaran produk (menggunakan Azure CLI) untuk mode konektivitas Langsung dan Tidak Langsung. Setelah Kubernetes di-onboarding dengan Pengontrol Data, kontainer memanfaatkan Sonobuoy untuk memicu pengujian integrasi paralel.
• arc-sb-plugin: Plugin Sonobuoy yang berisi pengujian integrasi end-to-end berbasis Pytest, mulai dari uji asap sederhana (penyebaran, penghapusan), hingga skenario ketersediaan tinggi yang kompleks, uji kekacauan (penghapusan sumber daya) dll.

Kontainer pengujian ini tersedia untuk umum bagi pelanggan dan mitra untuk melakukan pengujian validasi layanan data dengan dukungan Arc di kluster Kubernetes mereka sendiri yang berjalan di mana saja, untuk memvalidasi:

• Distro/versi Kubernetes
• Host disto/versions
• Penyimpanan (StorageClass/CSI), jaringan (misalnya LoadBalancer, DNS)
• Kubernetes lain atau penyiapan khusus infrastruktur

Agar Pelanggan yang ingin menjalankan Layanan Data dengan dukungan Arc pada distribusi yang tidak terdokumentasi, mereka harus menjalankan pengujian validasi ini agar berhasil dianggap didukung. Selain itu, Mitra dapat menggunakan pendekatan ini untuk mensertifikasi solusi mereka sesuai dengan Data Services dengan dukungan Arc - lihat Validasi Kubernetes layanan data dengan dukungan Azure Arc.

Diagram berikut menguraikan proses tingkat tinggi ini:

Dalam tutorial ini, Anda akan mempelajari cara:

Prasyarat

• Kredensial:

  • File test.env.tmpl berisi kredensial yang diperlukan, dan merupakan kombinasi dari prasyarat yang ada yang diperlukan untuk onboarding Kluster Terhubung Azure Arc dan Pengontrol Data yang Terhubung Langsung. Penyetelan file ini dijelaskan di bawah ini dengan sampel.
  • File kubeconfig ke kluster Kubernetes yang diuji dengan cluster-admin akses (diperlukan untuk onboarding Connected Cluster saat ini)

• Alat klien:

  • kubectl diinstal - versi minimum (Mayor:"1", Minor:"21")
  • git antarmuka baris perintah (atau alternatif berbasis UI)

Persiapan manifes Kubernetes

Peluncur tersedia sebagai bagian microsoft/azure_arc dari repositori, sebagai manifes Kustomisasi - Kustomisasi dibangun ke dalam kubectl - sehingga tidak ada alat tambahan yang diperlukan.

1. Kloning repositori secara lokal:

git clone https://github.com/microsoft/azure_arc.git

2. Navigasi ke azure_arc/arc_data_services/test/launcher, untuk melihat struktur folder berikut:

├── base                                         <- Comon base for all Kubernetes Clusters
│   ├── configs
│   │   └── .test.env.tmpl                       <- To be converted into .test.env with credentials for a Kubernetes Secret
│   ├── kustomization.yaml                       <- Defines the generated resources as part of the launcher
│   └── launcher.yaml                            <- Defines the Kubernetes resources that make up the launcher
└── overlays                                     <- Overlays for specific Kubernetes Clusters
    ├── aks
    │   ├── configs
    │   │   └── patch.json.tmpl                  <- To be converted into patch.json, patch for Data Controller control.json
    │   └── kustomization.yaml
    ├── kubeadm
    │   ├── configs
    │   │   └── patch.json.tmpl
    │   └── kustomization.yaml
    └── openshift
        ├── configs
        │   └── patch.json.tmpl
        ├── kustomization.yaml
        └── scc.yaml

Dalam tutorial ini, kita akan fokus pada langkah-langkah untuk AKS, tetapi struktur overlay di atas dapat diperluas untuk menyertakan distribusi Kubernetes tambahan.

Manifes siap disebarkan akan mewakili hal berikut:

├── base
│   ├── configs
│   │   ├── .test.env                           <- Config 1: For Kubernetes secret, see sample below
│   │   └── .test.env.tmpl
│   ├── kustomization.yaml
│   └── launcher.yaml
└── overlays
    └── aks
        ├── configs
        │   ├── patch.json.tmpl
        │   └── patch.json                      <- Config 2: For control.json patching, see sample below
        └── kustomization.yam

Ada dua file yang perlu dibuat untuk melokalisasi peluncur untuk berjalan di dalam lingkungan tertentu. Masing-masing file ini dapat dihasilkan dengan menyalin-menempelkan dan mengisi setiap file templat (*.tmpl) di atas:

• .test.env: isi dari .test.env.tmpl
• patch.json: isi dari patch.json.tmpl

Konfigurasi 1: .test.env

Sampel .test.env file yang diisi, yang dihasilkan berdasarkan .test.env.tmpl dibagikan di bawah ini dengan komentar sebaris.

Dengan kata lain, setelah menyalin-menempelkan .test.env.tmpl dan mengedit untuk membuat .test.env, file yang dihasilkan akan terlihat mirip dengan sampel di bawah ini. Proses untuk mengisi .test.env file identik di seluruh sistem operasi dan terminal.

Sampel selesai dari .test.env:

# ======================================
# Arc Data Services deployment version =
# ======================================

# Controller deployment mode: direct, indirect
# For 'direct', the launcher will also onboard the Kubernetes Cluster to Azure Arc
# For 'indirect', the launcher will skip Azure Arc and extension onboarding, and proceed directly to Data Controller deployment - see `patch.json` file
export CONNECTIVITY_MODE="direct"

# The launcher supports deployment of both GA/pre-GA trains - see detailed explanation below [1]
export ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN="stable"
export ARC_DATASERVICES_EXTENSION_VERSION_TAG="1.11.0"

# Image version
export DOCKER_IMAGE_POLICY="Always"
export DOCKER_REGISTRY="mcr.microsoft.com"
export DOCKER_REPOSITORY="arcdata"
export DOCKER_TAG="v1.11.0_2022-09-13"

# "arcdata" Azure CLI extension version override - see detailed explanation below [2]
export ARC_DATASERVICES_WHL_OVERRIDE=""

# ================
# ARM parameters =
# ================

# Custom Location Resource Provider Azure AD Object ID - this is a single, unique value per Azure AD tenant - see detailed explanation below [3]
export CUSTOM_LOCATION_OID="..."

# A pre-rexisting Resource Group is used if found with the same name. Otherwise, launcher will attempt to create a Resource Group
# with the name specified, using the Service Principal specified below (which will require `Owner/Contributor` at the Subscription level to work)
export LOCATION="eastus"
export RESOURCE_GROUP_NAME="..."

# A Service Principal with "sufficient" privileges - see detailed explanation below [4]
export SPN_CLIENT_ID="..."
export SPN_CLIENT_SECRET="..."
export SPN_TENANT_ID="..."
export SUBSCRIPTION_ID="..."

# Optional: certain integration tests test upload to Log Analytics workspace:
# https://learn.microsoft.com/azure/azure-arc/data/upload-logs
export WORKSPACE_ID="..."
export WORKSPACE_SHARED_KEY="..."

# ====================================
# Data Controller deployment profile =
# ====================================

# Samples for AKS
# To see full list of CONTROLLER_PROFILE, run: az arcdata dc config list
export CONTROLLER_PROFILE="azure-arc-aks-default-storage"

# azure, aws, gcp, onpremises, alibaba, other
export DEPLOYMENT_INFRASTRUCTURE="azure"

# The StorageClass used for PVCs created during the tests 
export KUBERNETES_STORAGECLASS="default"

# ==============================
# Launcher specific parameters =
# ==============================

# Log/test result upload from launcher container, via SAS URL - see detailed explanation below [5]
export LOGS_STORAGE_ACCOUNT="<your-storage-account>"
export LOGS_STORAGE_ACCOUNT_SAS="?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=...&spr=https&sig=..."
export LOGS_STORAGE_CONTAINER="arc-ci-launcher-1662513182"

# Test behavior parameters
# The test suites to execute - space seperated array, 
# Use these default values that run short smoke tests, further elaborate test suites will be added in upcoming releases
export SQL_HA_TEST_REPLICA_COUNT="3"
export TESTS_DIRECT="direct-crud direct-hydration controldb"
export TESTS_INDIRECT="billing controldb kube-rbac"
export TEST_REPEAT_COUNT="1"
export TEST_TYPE="ci"

# Control launcher behavior by setting to '1':
#
# - SKIP_PRECLEAN: Skips initial cleanup
# - SKIP_SETUP: Skips Arc Data deployment
# - SKIP_TEST: Skips sonobuoy tests
# - SKIP_POSTCLEAN: Skips final cleanup
# - SKIP_UPLOAD: Skips log upload
#
# See detailed explanation below [6]
export SKIP_PRECLEAN="0"
export SKIP_SETUP="0"
export SKIP_TEST="0"
export SKIP_POSTCLEAN="0"
export SKIP_UPLOAD="0"

Penjelasan terperinci untuk variabel tertentu

1. ARC_DATASERVICES_EXTENSION_* - Versi ekstensi dan pelatihan

Wajib: ini diperlukan untuk direct penyebaran mode.

Peluncur dapat menyebarkan rilis GA dan pra-GA.

Versi ekstensi untuk pemetaan release-train (ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) diperoleh dari sini:

• GA: stable - Log versi
• Pra-GA: preview - Pengujian pra-rilis

2. ARC_DATASERVICES_WHL_OVERRIDE - URL unduhan versi Azure CLI sebelumnya

Opsional: biarkan ini kosong .test.env untuk menggunakan default pra-paket.

Gambar peluncur dimas sebelumnya dengan versi CLI arcdata terbaru pada saat setiap rilis gambar kontainer. Namun, untuk bekerja dengan rilis dan pengujian peningkatan yang lebih lama, mungkin perlu menyediakan tautan unduhan URL Blob Azure CLI kepada peluncur, untuk mengambil alih versi yang telah dipaketkan sebelumnya; misalnya untuk menginstruksikan peluncur untuk menginstal versi 1.4.3, isi:

export ARC_DATASERVICES_WHL_OVERRIDE="https://azurearcdatacli.blob.core.windows.net/cli-extensions/arcdata-1.4.3-py2.py3-none-any.whl"

Versi CLI ke pemetaan URL Blob dapat ditemukan di sini.

3. CUSTOM_LOCATION_OID - ID Objek Lokasi Kustom dari penyewa Microsoft Entra spesifik Anda

Wajib: ini diperlukan untuk pembuatan Lokasi Kustom Kluster Terhubung.

Langkah-langkah berikut bersumber dari Aktifkan lokasi kustom di kluster Anda untuk mengambil ID Objek Lokasi Kustom unik untuk penyewa Microsoft Entra Anda.

Ada dua pendekatan untuk mendapatkan CUSTOM_LOCATION_OID penyewa Microsoft Entra Anda.

1. Melalui Azure CLI:

   az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query objectId -o tsv
   # 51dfe1e8-70c6-4de...      <--- This is for Microsoft's own tenant - do not use, the value for your tenant will be different, use that instead to align with the Service Principal for launcher.
   

   

2. Melalui portal Azure - navigasikan ke bilah Microsoft Entra Anda, dan cari Custom Locations RP:

   

4. SPN_CLIENT_* - Kredensial Perwakilan Layanan

Wajib: ini diperlukan untuk penyebaran Mode Langsung.

Peluncur masuk ke Azure menggunakan kredensial ini.

Pengujian validasi dimaksudkan untuk dilakukan pada kluster Kubernetes Non-Produksi/Uji & Langganan Azure - berfokus pada validasi fungsional penyiapan Kubernetes/Infrastruktur. Oleh karena itu, untuk menghindari jumlah langkah manual yang diperlukan untuk melakukan peluncuran, disarankan untuk menyediakan SPN_CLIENT_ID/SECRET yang memiliki Owner di tingkat Grup Sumber Daya (atau Langganan), karena akan membuat beberapa sumber daya dalam Grup Sumber Daya ini, serta menetapkan izin ke sumber daya tersebut terhadap beberapa Identitas Terkelola yang dibuat sebagai bagian dari penyebaran (penetapan peran ini pada gilirannya mengharuskan Perwakilan Layanan memiliki Owner).

5. LOGS_STORAGE_ACCOUNT_SAS - URL SAS Akun Penyimpanan Blob

Disarankan: membiarkan ini kosong berarti Anda tidak akan mendapatkan hasil dan log pengujian.

Peluncur memerlukan lokasi persisten (Azure Blob Storage) untuk mengunggah hasil, karena Kubernetes belum (belum) mengizinkan penyalinan file dari pod yang dihentikan/selesai - lihat di sini. Peluncur mencapai konektivitas ke Azure Blob Storage menggunakan URL SAS yang dilingkup akun (dibandingkan dengan cakupan kontainer atau blob) - URL yang ditandatangani dengan definisi akses terikat waktu - lihat Memberikan akses terbatas ke sumber daya Azure Storage menggunakan tanda tangan akses bersama (SAS), untuk:

1. Buat Kontainer Penyimpanan baru di Akun Penyimpanan yang sudah ada sebelumnya (LOGS_STORAGE_ACCOUNT), jika tidak ada (nama berdasarkan LOGS_STORAGE_CONTAINER)
2. Membuat blob baru bernama unik (file log tar pengujian)

Langkah-langkah berikut bersumber dari Berikan akses terbatas ke sumber daya Azure Storage menggunakan tanda tangan akses bersama (SAS).

?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=...&spr=https&sig=...

Ada beberapa pendekatan untuk menghasilkan URL SAS. Contoh ini menunjukkan portal:

Untuk menggunakan Azure CLI sebagai gantinya, lihat az storage account generate-sas

6. SKIP_* - mengontrol perilaku peluncur dengan melewati tahap tertentu

Opsional: biarkan ini kosong .test.env untuk menjalankan semua tahapan (setara dengan 0 atau kosong)

Peluncur mengekspos SKIP_* variabel, untuk menjalankan dan melewati tahap tertentu - misalnya, untuk melakukan eksekusi "pembersihan saja".

Meskipun peluncur dirancang untuk membersihkan baik di awal maupun di akhir setiap eksekusi, dimungkinkan untuk peluncuran dan/atau kegagalan pengujian untuk meninggalkan sumber daya residu. Untuk menjalankan peluncur dalam mode "bersihkan saja", atur variabel berikut di .test.env:

export SKIP_PRECLEAN="0"         # Run cleanup
export SKIP_SETUP="1"            # Do not setup Arc-enabled Data Services
export SKIP_TEST="1"             # Do not run integration tests
export SKIP_POSTCLEAN="1"        # POSTCLEAN is identical to PRECLEAN, although idempotent, not needed here
export SKIP_UPLOAD="1"           # Do not upload logs from this run

Pengaturan di atas menginstruksikan peluncur untuk membersihkan semua sumber daya Arc dan Arc Data Services, dan untuk tidak menyebarkan/menguji/mengunggah log.

Konfigurasi 2: patch.json

Sampel file yang patch.json diisi, yang dihasilkan berdasarkan patch.json.tmpl dibagikan di bawah ini:

Perhatikan bahwa spec.docker.registry, repository, imageTag harus identik dengan nilai di .test.env atas

Sampel selesai dari patch.json:

{
    "patch": [
        {
            "op": "add",
            "path": "spec.docker",
            "value": {
                "registry": "mcr.microsoft.com",
                "repository": "arcdata",
                "imageTag": "v1.11.0_2022-09-13",
                "imagePullPolicy": "Always"
            }
        },        
        {
            "op": "add",
            "path": "spec.storage.data.className",
            "value": "default"
        },  
        {
            "op": "add",
            "path": "spec.storage.logs.className",
            "value": "default"
        }                  
    ]
}

Penyebaran peluncur

Disarankan untuk menyebarkan peluncur dalam kluster Non-Produksi/Pengujian - karena melakukan tindakan destruktif pada Arc dan sumber daya Kubernetes lainnya yang digunakan.

imageTag Spesifikasi

Peluncur didefinisikan dalam Manifes Kubernetes sebagai Job, yang mengharuskan menginstruksikan Kubernetes tempat menemukan gambar peluncur. Ini diatur dalam base/kustomization.yaml:

images:
- name: arc-ci-launcher
  newName: mcr.microsoft.com/arcdata/arc-ci-launcher
  newTag: v1.11.0_2022-09-13

kubectl apply

Untuk memvalidasi bahwa manifes telah disiapkan dengan benar, coba validasi sisi klien dengan --dry-run=client, yang mencetak sumber daya Kubernetes yang akan dibuat untuk peluncur:

kubectl apply -k arc_data_services/test/launcher/overlays/aks --dry-run=client
# namespace/arc-ci-launcher created (dry run)
# serviceaccount/arc-ci-launcher created (dry run)
# clusterrolebinding.rbac.authorization.k8s.io/arc-ci-launcher created (dry run)
# secret/test-env-fdgfm8gtb5 created (dry run)                                        <- Created from Config 1: `patch.json`
# configmap/control-patch-2hhhgk847m created (dry run)                                <- Created from Config 2: `.test.env`
# job.batch/arc-ci-launcher created (dry run)

Untuk menyebarkan peluncur dan log ekor, jalankan hal berikut:

kubectl apply -k arc_data_services/test/launcher/overlays/aks
kubectl wait --for=condition=Ready --timeout=360s pod -l job-name=arc-ci-launcher -n arc-ci-launcher
kubectl logs job/arc-ci-launcher -n arc-ci-launcher --follow

Pada titik ini, peluncur harus dimulai - dan Anda akan melihat yang berikut:

Meskipun yang terbaik adalah menyebarkan peluncur dalam kluster tanpa sumber daya Arc yang sudah ada sebelumnya, peluncur berisi validasi pra-penerbangan untuk menemukan CRD dan sumber daya ARM Arc dan Arc Data Services yang sudah ada sebelumnya, dan mencoba membersihkannya dengan upaya terbaik (menggunakan kredensial Perwakilan Layanan yang disediakan), sebelum menyebarkan rilis baru:

Proses penemuan dan pembersihan metadata yang sama ini juga dijalankan saat peluncur keluar, untuk meninggalkan kluster sedekat mungkin dengan status yang sudah ada sebelumnya sebelum peluncuran.

Langkah-langkah yang dilakukan oleh peluncur

Pada tingkat tinggi, peluncur melakukan urutan langkah-langkah berikut:

1. Mengautentikasi ke API Kubernetes menggunakan Akun Layanan yang dipasang Pod

2. Mengautentikasi ke ARM API menggunakan Perwakilan Layanan yang dipasang Rahasia

3. Lakukan pemindaian metadata CRD untuk menemukan Sumber Daya Kustom Arc dan Arc Data Services yang ada

4. Bersihkan Sumber Daya Kustom yang ada di Kubernetes, dan sumber daya berikutnya di Azure. Jika ada ketidakcocokan antara kredensial dibandingkan .test.env dengan sumber daya yang ada di kluster, keluar.

5. Hasilkan sekumpulan variabel lingkungan unik berdasarkan tanda waktu untuk nama Kluster Arc, Pengontrol Data, dan Lokasi Kustom/Namespace. Mencetak variabel lingkungan, mengaburkan nilai sensitif (misalnya Kata Sandi Perwakilan Layanan, dll.)

6. a. Untuk Mode Langsung - Onboard Kluster ke Azure Arc, lalu sebarkan pengontrol.

   b. Untuk Mode Tidak Langsung: sebarkan Pengontrol Data

7. Setelah Pengontrol Data adalah Ready, buat sekumpulan log Azure CLI (az arcdata dc debug) dan simpan secara lokal, berlabel sebagai setup-complete - sebagai garis besar.

8. TESTS_DIRECT/INDIRECT Gunakan variabel lingkungan dari .test.env untuk meluncurkan serangkaian eksekusi pengujian Sonobuoy paralel berdasarkan array yang dipisahkan spasi (TESTS_(IN)DIRECT). Eksekusi ini dijalankan di namespace baru sonobuoy , menggunakan arc-sb-plugin pod yang berisi pengujian validasi Pytest.

9. Agregator Sonobuoy mengakumulasi junit hasil pengujian dan log per arc-sb-plugin eksekusi pengujian, yang diekspor ke dalam pod peluncur.

10. Kembalikan kode keluar dari pengujian, dan hasilkan serangkaian log debug lain - Azure CLI dan sonobuoy - disimpan secara lokal, berlabel sebagai test-complete.

11. Lakukan pemindaian metadata CRD, mirip dengan Langkah 3, untuk menemukan Sumber Daya Kustom Arc dan Arc Data Services yang ada. Kemudian, lanjutkan untuk menghancurkan semua sumber daya Data Arc dan Arc dalam urutan terbalik dari penyebaran, serta CRD, Role/ClusterRoles, PV/PVC, dll.

12. Coba gunakan token LOGS_STORAGE_ACCOUNT_SAS SAS yang disediakan untuk membuat kontainer Akun Penyimpanan baru bernama berdasarkan LOGS_STORAGE_CONTAINER, di Akun LOGS_STORAGE_ACCOUNTPenyimpanan yang sudah ada sebelumnya . Jika kontainer Akun Penyimpanan sudah ada, gunakan kontainer tersebut. Unggah semua hasil pengujian dan log lokal ke kontainer penyimpanan ini sebagai tarball (lihat di bawah).

13. Keluar.

Pengujian yang dilakukan per rangkaian pengujian

Ada sekitar 375 pengujian integrasi unik yang tersedia, di 27 suite pengujian - masing-masing menguji fungsionalitas terpisah.

Sebagai contoh, untuk sqlinstance-ha, pengujian berikut dilakukan:

• test_critical_configmaps_present: Memastikan ConfigMaps dan bidang yang relevan ada untuk Instans SQL.
• test_suspended_system_dbs_auto_heal_by_orchestrator: Memastikan apakah master dan msdb ditangguhkan dengan cara apa pun (dalam hal ini, pengguna). Pemeliharaan orkestrator menyembuhkannya secara otomatis.
• test_suspended_user_db_does_not_auto_heal_by_orchestrator: Memastikan apakah Database Pengguna sengaja ditangguhkan oleh pengguna, rekonsiliasi pemeliharaan Orchestrator tidak memulihkannya secara otomatis.
• test_delete_active_orchestrator_twice_and_delete_primary_pod: Menghapus pod orkestrator beberapa kali, diikuti oleh replika utama, dan memverifikasi semua replika disinkronkan. Harapan waktu failover untuk 2 replika dilonggarkan.
• test_delete_primary_pod: Menghapus replika utama dan memverifikasi semua replika disinkronkan. Harapan waktu failover untuk 2 replika dilonggarkan.
• test_delete_primary_and_orchestrator_pod: Menghapus pod replika dan orkestrator utama dan memverifikasi semua replika disinkronkan.
• test_delete_primary_and_controller: Menghapus replika utama dan pod pengontrol data dan memverifikasi titik akhir utama dapat diakses dan replika utama baru disinkronkan. Harapan waktu failover untuk 2 replika dilonggarkan.
• test_delete_one_secondary_pod: Menghapus replika sekunder dan pod pengontrol data dan memverifikasi semua replika disinkronkan.
• test_delete_two_secondaries_pods: Menghapus replika sekunder dan pod pengontrol data dan memverifikasi semua replika disinkronkan.
• test_delete_controller_orchestrator_secondary_replica_pods:
• test_failaway: Memaksa failover AG menjauh dari primer saat ini, memastikan primer baru tidak sama dengan primer lama. Memverifikasi semua replika disinkronkan.
• test_update_while_rebooting_all_non_primary_replicas: Pengujian pembaruan berbasis pengontrol tahan dengan percobaan ulang meskipun berbagai keadaan bergejolak.

Memeriksa Hasil Pengujian

Contoh kontainer penyimpanan dan file yang diunggah oleh peluncur:

Dan hasil pengujian yang dihasilkan dari eksekusi:

Membersihkan sumber daya

Untuk menghapus peluncur, jalankan:

kubectl delete -k arc_data_services/test/launcher/overlays/aks

Ini membersihkan manifes sumber daya yang disebarkan sebagai bagian dari peluncur.

Konten terkait