Cluster Anthos on bare metal kini menjadi Google Distributed Cloud (khusus software) untuk bare metal. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Deploy cluster Google Distributed Cloud di edge

Tutorial ini memperkenalkan solusi siap pakai yang menggunakan Google Distributed Cloud dan Config Sync untuk men-deploy cluster Kubernetes di edge dalam skala besar. Tutorial ini ditujukan untuk operator dan developer platform. Sebelum membaca dokumen ini, pastikan bahwa Anda sudah familier dengan teknologi dan konsep berikut:

Playbook yang bermanfaat.
Deployment edge dan tantangannya.
Cara bekerja dengan project Google Cloud.
Men-deploy aplikasi web dalam container.
Antarmuka command line gcloud dan kubectl.

Dalam tutorial ini, Anda menggunakan virtual machine (VM) Compute Engine untuk mengemulasi yang di-deploy di edge, dan contoh aplikasi tempat penjualan sebagai edge sebagian besar workload standar dan berbasis cloud. Google Distributed Cloud and Config Sync menyediakan pengelolaan dan kontrol terpusat untuk cluster edge Anda. Config Sync secara dinamis mengambil konfigurasi baru dari GitHub dan menerapkan kebijakan dan konfigurasi ini ke cluster Anda.

Arsitektur deployment edge

Deployment edge retail adalah cara yang baik untuk mengilustrasikan arsitektur yang yang digunakan dalam deployment Google Distributed Cloud standar.

Toko ritel fisik adalah titik interaksi terdekat antara unit bisnis perusahaan dan konsumen. Sistem perangkat lunak di dalam toko harus menjalankan beban kerja mereka, menerima pembaruan tepat waktu, dan melaporkan metrik penting dalam isolasi dari sistem manajemen pusat perusahaan. Selain itu, sistem software perlu dirancang sedemikian rupa sehingga dapat diperluas ke lebih banyak penyimpanan lokasi di masa mendatang. Meskipun Google Distributed Cloud memenuhi semua persyaratan ini untuk sistem software toko, profil tepi memungkinkan kasus penggunaan penting: deployment di lingkungan dengan resource hardware terbatas seperti etalase toko ritel.

Diagram berikut menunjukkan deployment Google Distributed Cloud yang menggunakan edge di toko ritel:

Deployment Google Distributed Cloud yang menggunakan profil edge di toko retail

Diagram sebelumnya menunjukkan toko retail fisik pada umumnya. Toko ini memiliki smart perangkat seperti pembaca kartu, mesin tempat penjualan, kamera, dan {i>printer<i}. Toko ini juga memiliki tiga perangkat hardware komputasi fisik (berlabel Node 1, Node 2, dan Node 3). Semua perangkat ini terhubung ke {i>switch<i} jaringan pusat. Jadi, ketiga perangkat komputasi terhubung satu sama lain melalui jaringan Lapisan 2. Tujuan perangkat komputasi yang saling terhubung membentuk infrastruktur {i>bare metal<i}. Google Distributed Cloud berjalan di dalam ketiga perangkat komputasi. Ini perangkat juga memiliki penyimpanan {i>disk<i} sendiri dan dikonfigurasi untuk replikasi data di antara keduanya untuk ketersediaan tinggi.

Diagram juga menunjukkan komponen utama berikut yang merupakan bagian dari Deployment Google Distributed Cloud:

Komponen yang ditandai sebagai MetalLB adalah load balancer paket yang di-deploy dengan Google Distributed Cloud.
Komponen Config Sync memungkinkan sinkronisasi status cluster berdasarkan repositori sumber. Ini adalah langkah opsional {i>add-on<i} yang membutuhkan instalasi dan konfigurasi terpisah. Untuk selengkapnya informasi tentang cara menyiapkan Sinkronisasi Konfigurasi dan berbagai nomenklatur, lihat Dokumentasi Sinkronisasi Konfigurasi.
Repositori root dan repositori namespace ditampilkan di bagian atas diagram di luar lokasi penyimpanan merepresentasikan dua repositori sumber.

Perubahan pada cluster akan diterapkan ke repositori sumber terpusat ini. Deployment Google Distributed Cloud di berbagai lokasi edge menarik pembaruan dari repositori sumber. Perilaku ini ditunjukkan oleh tanda panah yang menghubungkan kedua repositori dalam diagram pada Config Sync komponen di dalam cluster Google Distributed Cloud yang berjalan di perangkat.
Komponen kunci lain yang digambarkan sebagai bagian dari klaster ini adalah Runtime VM di GDC. Runtime VM di GDC memungkinkan pengoperasian yang ada Workload berbasis VM di dalam cluster tanpa perlu containerization. Tujuan Dokumentasi VM Runtime di GDC menjelaskan cara mengaktifkannya dan men-deploy workload VM Anda ke dalam cluster.
Komponen yang ditandai sebagai Application menunjukkan software yang di-deploy ke dikelompokkan dengan toko ritel. Aplikasi tempat penjualan yang terlihat di kios toko ritel bisa menjadi salah satu contoh aplikasi tersebut.

Kotak-kotak di bagian bawah diagram mewakili banyak perangkat (seperti kios, tablet, atau kamera) di dalam toko ritel, yang semuanya terhubung ke {i>switch<i} jaringan pusat. Jaringan lokal di dalam toko memungkinkan aplikasi yang berjalan di dalam deployment Google Distributed Cloud untuk mencapai perangkat.

Di bagian selanjutnya, Anda akan melihat emulasi deployment toko retail ini di Google Cloud menggunakan VM Compute Engine. Emulasi inilah yang Anda gunakan dalam tutorial selanjutnya untuk bereksperimen dengan Google Distributed Cloud.

Deployment edge yang diemulasi di Google Cloud

Diagram berikut adalah gambaran dari semua yang Anda siapkan di Google Cloud dalam tutorial ini. Diagram ini berkaitan dengan toko retail dari bagian sebelumnya. Deployment ini merepresentasikan edge yang diemulasi lokasi deployment aplikasi tempat penjualan. Arsitektur juga menunjukkan contoh workload aplikasi tempat penjualan sederhana yang Anda gunakan dalam tutorial ini. Anda mengakses aplikasi tempat penjualan di dalam cluster dengan menggunakan {i>browser<i} web sebagai kios.

Arsitektur aplikasi tempat penjualan dan cara deployment di dalam cluster Google Distributed Cloud yang berjalan di VM Compute Engine

Tiga virtual machine (VM) Compute Engine dalam diagram sebelumnya mewakili perangkat keras fisik (atau {i>node<i}) di lokasi edge yang umum. Ini perangkat keras akan terhubung bersama dengan {i> switch <i}jaringan untuk membentuk perangkat keras infrastruktur logam. Di lingkungan emulasi kami di Google Cloud, VM ini terhubung satu sama lain melalui jalur default Virtual Private Cloud (VPC) dalam project Google Cloud.

Dalam instalasi Google {i> Distributed Cloud<i} biasa, Anda dapat mengonfigurasi load balancer Anda sendiri. Namun, untuk tutorial ini, Anda tidak menyiapkan pemuatan eksternal dengan load balancer Jaringan Passthrough Eksternal Regional. Sebagai gantinya, gunakan load balancer MetalLB yang dipaketkan dengan Google Distributed Cloud. Load balancer MetalLB yang dipaketkan memerlukan Lapisan 2 konektivitas jaringan antar {i>node<i}. Dengan demikian, konektivitas Lapisan 2 antara VM Compute Engine diaktifkan dengan membuat VxLAN berada di atas jaringan Virtual Private Cloud (VPC) default.

Dalam persegi panjang berlabel "Jaringan overlay L2 (VxLAN)", software dan komponen yang berjalan di dalam tiga VM Compute Engine. Ini mencakup cluster Google Distributed Cloud dan Reverse proxy. Cluster ini diwakili oleh "Google Distributed Cloud" persegi panjang. Persegi panjang ini yang merepresentasikan cluster ini termasuk persegi panjang lainnya ditandai sebagai "Namespace Kubernetes (pos)". Ini merepresentasikan namespace Kubernetes di dalam cluster. Seluruh komponen di dalam namespace Kubernetes ini membentuk aplikasi tempat penjualan yang di-deploy ke cluster Google Distributed Cloud. Intinya memiliki tiga microservice: Server API, Inventaris, dan Pembayaran. Semua komponen ini bersama-sama mewakili satu "aplikasi" yang ditampilkan dalam Diagram arsitektur peluncuran edge.

Load balancer MetalLB paket dari cluster Google Distributed Cloud tidak dapat dijangkau langsung dari luar VM. Diagram ini menunjukkan Reverse proxy NGINX yang dikonfigurasi untuk berjalan di dalam VM guna mengarahkan traffic yang masuk ke VM Compute Engine ke load balancer. Ini hanya solusi untuk tujuan tutorial ini di mana node edge diemulasi menggunakan Google Cloud dan melakukan load balancing di semua VM Compute Engine. Di lokasi edge yang sebenarnya, ini dapat dilakukan dengan konfigurasi jaringan.

Tujuan

Gunakan VM Compute Engine untuk mengemulasi infrastruktur bare metal yang berjalan di lokasi edge.
Buat cluster Google Distributed Cloud di infrastruktur edge yang diemulasikan.
Hubungkan dan daftarkan cluster dengan Google Cloud.
Deploy contoh workload aplikasi tempat penjualan di cluster Google Distributed Cloud.
Menggunakan konsol Google Cloud untuk memverifikasi dan memantau aplikasi tempat penjualan yang beroperasi di lokasi edge.
Menggunakan Config Sync untuk mengupdate aplikasi tempat penjualan yang berjalan di cluster Google Distributed Cloud.

Sebelum memulai

Di Konsol Google Cloud, pada halaman pemilih project, pilih atau membuat project Google Cloud.

Catatan: Jika tidak berencana untuk menyimpan resource yang Anda buat dalam prosedur ini, buatlah project, bukan memilih project yang ada. Setelah menyelesaikan langkah ini, Anda dapat menghapus project, yang menghapus semua resource yang terkait dengan project ini.

Buka pemilihan project
Pastikan penagihan diaktifkan untuk project Cloud Anda. Pelajari cara memeriksa apakah penagihan telah diaktifkan pada suatu project.
Instal dan inisialisasi Google Cloud CLI.

Lakukan fork dan clone repositori anthos-samples

Semua skrip yang digunakan dalam tutorial ini disimpan di anthos-samples repositori resource. Struktur folder di bawah /anthos-bm-edge-deployment/acm-config-sink diatur sesuai dengan apa yang diharapkan oleh Config Sync. Clone repositori ini ke akun GitHub Anda sendiri sebelum melanjutkan dengan langkah-langkah berikut.

Jika Anda belum memilikinya, buat akun di GitHub.
Membuat token akses pribadi untuk digunakan dalam konfigurasi Config Sync. Tindakan ini diperlukan untuk Komponen Config Sync di cluster untuk melakukan autentikasi dengan akun GitHub saat mencoba menyinkronkan perubahan baru.
1. Pilih cakupan public_repo saja.
2. Simpan token akses yang Anda buat di tempat yang aman untuk digunakan nanti.
Lakukan fork repositori anthos-samples ke akun GitHub Anda sendiri:
1. Buka repositori anthos-samples.
2. Klik ikon Fork di pojok kanan atas halaman.
3. Klik akun pengguna GitHub yang ingin Anda jadikan tujuan fork repositori. Anda secara otomatis diarahkan ke laman dengan versi bercabang Anda Repositori anthos-samples.
Buka terminal di lingkungan lokal Anda.
Clone repositori forked dengan menjalankan perintah berikut, yaitu GITHUB_USERNAME adalah nama pengguna untuk GitHub Anda akun:
```
git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment
```
Catatan: Repositori sumber untuk solusi ini dan cabang Anda dari solusi ini repositori adalah repositori publik. Dokumen ini menunjukkan penggunaan akses token untuk meniru kasus penggunaan sebenarnya dengan repositori pribadi.

Menyiapkan lingkungan workstation

Untuk menyelesaikan deployment edge yang dijelaskan dalam dokumen ini, Anda memerlukan satu workstation yang memiliki akses ke Internet dan alat berikut yang telah diinstal:

Docker
alat antarmuka command line envsubst (biasanya pra-instal di Linux dan OS lain yang mirip Unix)

Jalankan semua perintah dalam tutorial di workstation yang Anda konfigurasi di bagian ini.

Di workstation Anda, lakukan inisialisasi variabel lingkungan dalam instance shell baru:

export PROJECT_ID="PROJECT_ID"
export REGION="us-central1"
export ZONE="us-central1-a"

# port on the admin Compute Engine instance you use to set up an nginx proxy
# this allows to reach the workloads inside the cluster via the VM IP
export PROXY_PORT="8082"

# should be a multiple of 3 since N/3 clusters are created with each having 3 nodes
export GCE_COUNT="3"

# url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples
export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples"

# this is the username used to authenticate to your fork of this repository
export SCM_TOKEN_USER="GITHUB_USERNAME"

# access token created in the earlier step
export SCM_TOKEN_TOKEN="ACCESS_TOKEN"

Ganti nilai berikut:

PROJECT_ID: Project ID Google Cloud Anda.
GITHUB_USERNAME: nama pengguna GitHub Anda.
ACCESS_TOKEN: token akses pribadi yang Anda buat untuk repositori GitHub.

Simpan nilai default untuk variabel lingkungan lainnya. Mereka adalah yang akan dijelaskan di bagian selanjutnya.

Di workstation Anda, lakukan inisialisasi Google Cloud CLI:

gcloud config set project "${PROJECT_ID}"
gcloud services enable compute.googleapis.com

gcloud config set compute/region "${REGION}"
gcloud config set compute/zone "${ZONE}"

Di workstation Anda, buat akun layanan Google Cloud untuk di instance Compute Engine. Skrip ini membuat file kunci JSON untuk akun layanan baru di <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Langkah ini juga menyiapkan Cloud Key Management Service key ring dan kunci untuk enkripsi kunci pribadi SSH.

./scripts/create-primary-gsa.sh

Contoh berikut hanya sebagian dari skrip. Untuk melihat seluruh skrip, klik View on GitHub.

# ...
EXISTS=$(gcloud iam service-accounts list \
  --filter="email=${GSA_EMAIL}" \
  --format="value(name, disabled)" \
  --project="${PROJECT_ID}")

if [[ -z "${EXISTS}" ]]; then
  echo "GSA [${GSA_EMAIL}]does not exist, creating it"

  # GSA does NOT exist, create
  gcloud iam service-accounts create ${GSA_NAME} \
    --description="GSA used on each Target machine to make gcloud commands" \
    --display-name="target-machine-gsa" \
    --project "${PROJECT_ID}"
else
  if [[ "${EXISTS}" =~ .*"disabled".* ]]; then
    # Found GSA is disabled, enable
    gcloud iam service-accounts enable "${GSA_EMAIL}" --project "${PROJECT_ID}"
  fi
  # otherwise, no need to do anything
fi
# ...

Menyediakan instance Compute Engine

Di bagian ini, Anda akan membuat VM Compute Engine tempat Google Distributed Cloud akan diinstal. Anda juga akan memverifikasi konektivitas ke VM ini sebelum melanjutkan ke bagian instal.

Di workstation Anda, buat kunci SSH yang digunakan untuk komunikasi antara ke instance Compute Engine.
```
ssh-keygen -f ./build-artifacts/consumer-edge-machine
```

Mengenkripsi kunci pribadi SSH menggunakan Cloud Key Management Service.

gcloud kms encrypt \
    --key gdc-ssh-key \
    --keyring gdc-ce-keyring \
    --location global \
    --plaintext-file build-artifacts/consumer-edge-machine \
    --ciphertext-file build-artifacts/consumer-edge-machine.encrypted

Membuat file konfigurasi lingkungan .envrc dan mencarinya. Sesudah membuat, memeriksa file .envrc untuk memastikan bahwa variabel lingkungan memiliki telah diganti dengan nilai yang benar.

envsubst < templates/envrc-template.sh > .envrc
source .envrc

Berikut adalah contoh file .envrc yang dibuat dengan mengganti variabel lingkungan dalam file templates/envrc-template.sh. Perhatikan bahwa baris yang diperbarui akan ditandai:

# GSA Key used for provisioning (result of running ./scripts/create-primary-gsa.sh)
LOCAL_GSA_FILE=$(pwd)/build-artifacts/consumer-edge-gsa.json
export LOCAL_GSA_FILE
# GCP Project ID
export PROJECT_ID="abm-edge-project"
# Bucket to store cluster snapshot information
export SNAPSHOT_GCS="abm-edge-project-cluster-snapshots"

# GCP Project Region (Adjust as desired)
export REGION="us-central1"
# GCP Project Zone (Adjust as desired)
export ZONE="us-central1-a"

# Gitlab Personal Access Token credentials (generated in Quick Start step 2)
export SCM_TOKEN_USER="LarryPage"
export SCM_TOKEN_TOKEN="oo901Sp-FHuzmz__dgl0393atkf69c8L"

# Default Root Repo setup for multiple locations
export ROOT_REPO_URL="https://github.com/LarryPage/anthos-samples"
export ROOT_REPO_BRANCH="main"
export ROOT_REPO_DIR="/anthos-bm-edge-deployment/acm-config-sink"

# OIDC Configuration (off by default)
export OIDC_CLIENT_ID="" # Optional, requires GCP API setup work
export OIDC_CLIENT_SECRET="" # Optional
export OIDC_USER="" # Optional
export OIDC_ENABLED="false" # Flip to true IF implementing OIDC on cluster

Membuat instance Compute Engine tempat Google Distributed Cloud terinstal.

./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \
    tee ./build-artifacts/gce-info

Menginstal Google Distributed Cloud dengan Ansible

Skrip yang digunakan dalam panduan ini membuat cluster Google Distributed Cloud di yang terdiri dari tiga instance Compute Engine. Jumlah klaster yang dibuat adalah dikontrol oleh variabel lingkungan GCE_COUNT. Misalnya, Anda menyetel variabel lingkungan GCE_COUNT menjadi 6 untuk membuat dua Cluster Google Distributed Cloud dengan 3 instance VM masing-masing. Secara default variabel lingkungan GCE_COUNT ditetapkan ke 3. Oleh karena itu, dalam panduan ini cluster dengan 3 instance Compute Engine akan dibuat. VM instance diberi nama dengan imbuhan cnuc- yang diikuti dengan angka. VM pertama di mana instance dari setiap cluster bertindak sebagai workstation admin tempat penginstalan akan dipicu. Cluster tersebut juga diberi nama yang sama dengan admin VM workstation (misalnya, cnuc-1, cnuc-4, cnuc-7).

Playbook Ansible melakukan hal berikut:

Mengonfigurasi instance Compute Engine dengan alat yang diperlukan, seperti sebagai docker, bmctl, gcloud, dan nomos.
Menginstal Google Distributed Cloud di instance Compute Engine yang dikonfigurasi.
Membuat cluster mandiri Google Distributed Cloud yang disebut cnuc-1.
Mendaftarkan cluster cnuc-1 ke Google Cloud.
Menginstal Config Sync ke cluster cnuc-1.
Mengonfigurasi Config Sync untuk disinkronkan dengan cluster konfigurasi yang terletak di anthos-bm-edge-deployment/acm-config-sink di repositori forked Anda.
Menghasilkan Login token untuk cluster.

Selesaikan langkah-langkah berikut untuk menyiapkan dan memulai proses penginstalan:

Di workstation Anda, buat image Docker yang digunakan untuk penginstalan. Ini gambar ini memiliki semua alat yang diperlukan untuk proses instalasi, seperti Ansible, Python, dan Google Cloud CLI.

gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/

Setelah berhasil berjalan, build akan menghasilkan output seperti berikut:

...
latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498
DONE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                         IMAGES                                                  STATUS
2238baa2-1f41-440e-a157-c65900b7666b  2022-08-17T19:28:57+00:00  6M53S     gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz  gcr.io/my_project/consumer-edge-install (+1 more)  SUCCESS

Buat file inventaris Ansible dari template.

envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml

Jalankan skrip penginstalan yang memulai container Docker dari image yang dibuat sebelumnya. Skrip secara internal menggunakan Docker untuk memunculkan container dengan pemasangan volume ke direktori kerja saat ini. Setelah berhasil penyelesaian skrip ini, Anda harus berada di dalam kontainer Docker yang dibuat. Anda memicu penginstalan Ansible dari dalam container ini.

./install.sh

Jika berhasil dijalankan, skrip akan menghasilkan output seperti berikut:

...
Check the values above and if correct, do you want to proceed? (y/N): y
Starting the installation
Pulling docker install image...

==============================
Starting the docker container. You will need to run the following 2 commands (cut-copy-paste)
==============================
1: ./scripts/health-check.sh
2: ansible-playbook all-full-install.yaml -i inventory
3: Type 'exit' to exit the Docker shell after installation
==============================
Thank you for using the quick helper script!
(you are now inside the Docker shell)

Dari dalam container Docker, verifikasi akses ke Compute Engine instance Compute Engine.

./scripts/health-check.sh

Jika berhasil dijalankan, skrip akan menghasilkan output seperti berikut:

...
cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}

Dari dalam container Docker, jalankan playbook Ansible untuk menginstal Google Distributed Cloud di instance Compute Engine. Setelah selesai, Anda akan lihat Login Token untuk cluster yang dicetak di layar.

ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.log

Setelah berhasil berjalan, penginstalan akan menghasilkan output seperti berikut:

...
TASK [abm-login-token : Display login token] **************************************************************************
ok: [cnuc-1] => {
    "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW
iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd
4CwanGlof6s-fbu8"
}
skipping: [cnuc-2]
skipping: [cnuc-3]

PLAY RECAP ***********************************************************************************************************
cnuc-1                     : ok=205  changed=156  unreachable=0    failed=0    skipped=48   rescued=0    ignored=12
cnuc-2                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2
cnuc-3                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2

Login ke cluster Google Distributed Cloud di Konsol Google Cloud

Setelah playbook Ansible berjalan hingga selesai, playbook mandiri Cluster Google Distributed Cloud diinstal di dalam Compute Engine atau VM. Cluster ini juga terdaftar di Google Cloud menggunakan Hubungkan Agen. Namun, untuk melihat detail tentang cluster ini, Anda harus mencatat ke dalam cluster dari Konsol Google Cloud. Untuk masuk ke Cluster GKE menyelesaikan langkah-langkah berikut.

Salin token dari output playbook Ansible di bagian sebelumnya bagian.

Catatan: Jika Anda tidak lagi memiliki akses ke output konsol, periksa log di ./build-artifacts/ansible-run.log untuk mendapatkan token Anda. Anda juga dapat jalankan playbook berikut untuk mengambil token kembali: ansible-playbook all-get-login-tokens.yaml -i inventory
Di Google Cloud Console, buka halaman Kubernetes clusters dan gunakan token yang disalin untuk login ke cluster cnuc-1.

Buka halaman cluster Kubernetes
1. Pada daftar klaster, klik Tindakan di samping cluster cnuc-1, lalu klik Login.
2. Pilih Token dan tempel token yang telah disalin.
3. Klik Login.
Di konsol Google Cloud, buka halaman Config di bagian Features.

Buka Konfigurasi

Pada tab Packages, periksa kolom Sync status di tabel cluster. Pastikan statusnya Disinkronkan. Status Disinkronkan menunjukkan bahwa Sinkronisasi Konfigurasi telah berhasil menyinkronkan konfigurasi GitHub dengan , cnuc-1.

kami

Mengonfigurasi proxy untuk traffic eksternal

Cluster Google Distributed Cloud yang diinstal pada langkah sebelumnya menggunakan paket load balancer yang disebut MetalLB. Layanan load balancer ini hanya dapat diakses melalui Alamat IP Virtual Private Cloud (VPC). Untuk mengarahkan lalu lintas yang masuk melalui IP eksternal ke load balancer yang dipaketkan, menyiapkan layanan reverse proxy di host admin (cnuc-1). Layanan reverse proxy ini memungkinkan Anda menjangkau API Server aplikasi tempat penjualan melalui IP eksternal admin host (cnuc-1).

Skrip penginstalan pada langkah sebelumnya yang menginstal NGINX di {i>host<i} admin bersama dengan contoh file konfigurasi. Perbarui file ini ke gunakan alamat IP layanan load balancer dan mulai ulang NGINX.

Di workstation, gunakan SSH untuk login ke workstation admin:
```
ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1
```
Dari dalam workstation admin, siapkan reverse proxy NGINX untuk merutekan traffic ke layanan Load Balancer Server API. Mendapatkan alamat IP Load jenis load balancer layanan Kubernetes:
```
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
```

Perbarui file konfigurasi template dengan alamat IP yang diambil:

sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \
    /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"

Mulai ulang NGINX untuk memastikan konfigurasi yang baru diterapkan:
```
sudo systemctl restart nginx
```

Periksa dan verifikasi status server NGINX untuk melaporkan "aktif (berjalan)":

sudo systemctl status nginx

Setelah berhasil dijalankan, NGINX akan menghasilkan output seperti contoh berikut:

● nginx.service - A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago
    Docs: man:nginx(8)
    Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 92573 (nginx)
    Tasks: 17 (limit: 72331)
    Memory: 13.2M
    CGroup: /system.slice/nginx.service
            ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─92574 nginx: worker process
            ├─92575 nginx: worker process
            ├─92577 nginx: ....
            ...
            ...

Keluar dari sesi SSH ke workstation admin:
```
exit
```
Keluar dari sesi shell ke container Docker. Setelah keluar dari admin Anda masih berada di dalam container Docker yang digunakan untuk penginstalan:
```
exit
```

Mengakses aplikasi tempat penjualan

Dengan penyiapan proxy eksternal, Anda dapat mengakses aplikasi yang berjalan di dalam cluster GKE. Untuk mengakses contoh aplikasi tempat penjualan, menyelesaikan langkah-langkah berikut.

Di workstation, dapatkan alamat IP eksternal admin Instance Compute Engine dan akses UI aplikasi tempat penjualan:

EXTERNAL_IP=$(gcloud compute instances list \
    --project ${PROJECT_ID} \
    --filter="name:cnuc-1" \
    --format="get(networkInterfaces[0].accessConfigs[0].natIP)")
echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"

Jika berhasil dijalankan, skrip akan menghasilkan output seperti berikut:

Point the browser to: 34.134.194.84:8082

Buka {i>browser<i} web Anda dan navigasikan ke alamat IP yang ditunjukkan pada {i>output<i} dari perintah sebelumnya. Anda dapat mengakses dan menguji contoh tempat penjualan seperti yang ditunjukkan dalam contoh screenshot berikut:

Menggunakan Config Sync untuk mengupdate Server API

Aplikasi contoh dapat diupgrade ke versi yang lebih baru dengan mengupdate file konfigurasi dalam repositori root. Config Sync mendeteksi melakukan update dan membuat perubahan secara otomatis pada cluster Anda. Dalam contoh ini, repositori root adalah repositori anthos-samples yang Anda clone di awal panduan ini. Untuk melihat cara kerja contoh aplikasi tempat penjualan melakukan upgrade deployment ke versi yang lebih baru, selesaikan langkah-langkah berikut.

Di workstation, perbarui kolom image untuk mengubah Server API dari v1 hingga v2. Konfigurasi YAML untuk deployment berada dalam di anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.
```
containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1
```

Tambahkan, commit, dan kirim perubahan ke repositori forked Anda:

git add acm-config-sink/namespaces/pos/api-server.yaml
git commit -m "chore: updated api-server version to v2"
git push

Di konsol Google Cloud, buka halaman Config Sync untuk memeriksa Status spesifikasi Konfigurasi. Pastikan statusnya Disinkronkan.

Buka halaman Config Sync
Di konsol Google Cloud, buka Workload Kubernetes Engine untuk memverifikasi bahwa Deployment telah diperbarui.

Buka halaman Workloads Kubernetes Engine
Jika status Deployment Oke, arahkan browser Anda ke Alamat IP dari bagian sebelumnya untuk melihat aplikasi tempat penjualan. Perhatikan bahwa versi dalam judul menunjukkan "V2", menunjukkan bahwa perubahan aplikasi di-deploy, seperti yang ditunjukkan pada contoh berikut {i>screenshot<i} (tangkapan layar):

Anda mungkin perlu melakukan refresh paksa pada tab browser untuk melihat perubahannya.

Pembersihan

Untuk menghindari biaya Google Cloud yang tidak perlu, hapus resource yang digunakan untuk panduan ini jika sudah selesai. Anda dapat menghapusnya resource secara manual, atau menghapus project Google Cloud Anda, yang juga akan dari semua resource. Selain itu, Anda mungkin juga ingin membersihkan perubahan yang dibuat di workstation lokal Anda:

Workstation lokal

File berikut harus diperbarui untuk menghapus perubahan yang dibuat oleh skrip penginstalan.

Hapus alamat IP VM Compute Engine yang ditambahkan ke file /etc/hosts.
Hapus konfigurasi SSH untuk cnuc-* di file ~/.ssh/config.
Hapus sidik jari VM Compute Engine dari file ~/.ssh/known_hosts.

Hapus Project

Jika Anda membuat project khusus untuk prosedur ini, hapus project Google Cloud dari Konsol Google Cloud.

Perhatian: Menghapus project memiliki efek berikut:

Semua hal dalam project akan dihapus. Jika menggunakan project yang sudah ada untuk tugas dalam dokumen ini, saat Anda menghapusnya, pekerjaan lain yang telah Anda lakukan dalam project tersebut juga akan terhapus.
Project ID kustom hilang. Saat membuat project ini, Anda mungkin telah membuat project ID kustom yang ingin digunakan di masa mendatang. Untuk mempertahankan URL yang menggunakan project ID, seperti URL appspot.com, hapus resource yang dipilih di dalam project, bukan menghapus seluruh project.

Jika Anda berencana mempelajari berbagai arsitektur, tutorial, atau panduan memulai, menggunakan kembali project dapat membantu agar Anda tidak melampaui batas kuota project.

Di konsol Google Cloud, buka halaman Manage resource.

Buka Manage resource

Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.

Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus project.

Manual

Jika Anda menggunakan project yang sudah ada untuk prosedur ini, lakukan hal berikut:

Batalkan pendaftaran semua cluster Kubernetes dengan nama yang diawali dengan cnuc-.
Menghapus semua VM Compute Engine dengan nama yang diawali dengan cnuc-.
Menghapus bucket Cloud Storage dengan nama yang diawali dengan abm-edge-boot.
Hapus Aturan Firewall allow-pod-ingress dan allow-pod-egress.
Hapus rahasia Secret Manager install-pub-key.

Apa langkah selanjutnya?

Anda dapat memperluas panduan ini dengan menambahkan lokasi edge lainnya. Menyetel variabel lingkungan GCE_COUNT ke 6 dan menjalankan kembali langkah yang sama dari bagian sebelumnya membuat tiga instance Compute Engine baru (cnuc-4, cnuc-5, cnuc-6) dan Google Distributed Cloud baru cluster mandiri yang disebut cnuc-4.

Anda juga dapat mencoba memperbarui konfigurasi cluster dalam repositori bercabang untuk menerapkan berbagai versi aplikasi tempat penjualan ke dua cluster, cnuc-1 dan cnuc-4, menggunakan ClusterSelectors.

Untuk detail tentang setiap langkah dalam panduan ini, skrip yang terlibat, lihat anthos-samples repositori resource.