Artikel ini menjelaskan kumpulan praktik terbaik untuk membuat container lebih mudah dioperasikan. Praktik ini mencakup berbagai topik, mulai dari keamanan hingga pemantauan dan logging. Tujuannya adalah membuat aplikasi lebih mudah dijalankan di Google Kubernetes Engine dan di container secara umum. Banyak praktik yang dibahas di sini terinspirasi oleh metodologi dua belas faktor yang merupakan referensi bagus untuk membangun aplikasi berbasis cloud.
Praktik terbaik ini juga tidak sama pentingnya. Misalnya, mungkin Anda berhasil menjalankan beban kerja produksi tanpa sebagian di antaranya, tetapi workload lainnya bersifat mendasar. Secara khusus, pentingnya keamanan terkait praktik terbaik adalah bersifat subjektif Apakah Anda mengimplementasikannya bergantung pada lingkungan dan batasan Anda.
Untuk mendapatkan hasil maksimal dari artikel ini, Anda memerlukan pengetahuan tentang Docker dan Kubernetes. Beberapa praktik terbaik yang dibahas di sini juga berlaku untuk container Windows, tetapi sebagian besar mengasumsikan bahwa Anda menggunakan container Linux. Untuk saran tentang cara mem-build container, lihat Praktik Terbaik untuk Membuat Container.
Gunakan mekanisme asli logging dari container
Tingkat kepentingan: TINGGI.
Sebagai bagian integral dari pengelolaan aplikasi, log berisi informasi berharga tentang peristiwa yang terjadi dalam aplikasi. Docker dan Kubernetes berupaya untuk mempermudah pengelolaan log.
Pada server klasik, Anda mungkin perlu menulis log ke file tertentu dan menangani rotasi Log untuk menghindari pengisian disk. Jika memiliki sistem logging lanjutan, Anda dapat meneruskan log tersebut ke server jarak jauh untuk memusatkan-nya.
Container menawarkan cara yang mudah dan standar untuk menangani log karena Anda dapat
menulisnya ke stdout dan stderr. Docker menangkap baris log ini dan memungkinkan
Anda untuk mengaksesnya menggunakan docker logs perintah. Sebagai developer
aplikasi, Anda tidak perlu menerapkan mekanisme logging tingkat lanjut. Sebagai gantinya,
gunakan mekanisme logging native.
Operator platform harus menyediakan sistem untuk pencatatan terpusat dan membuatnya dapat ditelusuri. Di GKE, layanan ini disediakan oleh Fluent Bit dan Cloud Logging. Bergantung pada versi master cluster GKE Anda, Fluentd atau Fluent Bit akan digunakan untuk mengumpulkan log. Mulai GKE 1.17, log dikumpulkan menggunakan agen berbasis Fluentbit. Cluster GKE yang menggunakan versi sebelum GKE 1.17 menggunakan agen berbasis Fluentd. stack.Pada distribusi Kubernetes lainnya, metode yang umum digunakan antara lain penggunaan stack EFK (Elasticsearch, Fluentd, Kibana).
Log JSON
Sebagian besar sistem pengelolaan log sebenarnya adalah database deret waktu yang menyimpan dokumen yang diindeks waktu. Dokumen tersebut biasanya dapat diberikan dalam format JSON. Di Cloud Logging dan EFK, satu baris log disimpan sebagai dokumen, beserta beberapa metadata (informasi tentang pod, container, node, dan sebagainya).
Anda dapat memanfaatkan perilaku tersebut dengan langsung mencatat dalam format JSON dengan kolom yang berbeda. Selanjutnya, Anda dapat menelusuri log dengan lebih efektif berdasarkan kolom tersebut.
Misalnya, pertimbangkan untuk mentransformasi log berikut ke dalam format JSON:
[2018-01-01 01:01:01] foo - WARNING - foo.bar - There is something wrong.
Berikut adalah log yang ditransformasi:
{
"date": "2018-01-01 01:01:01",
"component": "foo",
"subcomponent": "foo.bar",
"level": "WARNING",
"message": "There is something wrong."
}
Transformasi ini memungkinkan Anda dengan mudah menelusuri log untuk semua
WARNING log level atau semua log dari subkomponen foo.bar.
Jika memutuskan untuk menulis log berformat JSON, perhatikan bahwa Anda harus menulis setiap peristiwa pada satu baris agar dapat diurai dengan benar. Pada kenyataannya, terlihat seperti berikut:
{"date":"2018-01-01 01:01:01","component":"foo","subcomponent":"foo.bar","level": "WARNING","message": "There is something wrong."}
Seperti yang dapat Anda lihat, hasilnya menjadi kurang mudah dibaca daripada baris log biasa. Jika Anda memutuskan untuk menggunakan metode ini, pastikan tim Anda tidak terlalu mengandalkan pemeriksaan log manual.
Pola sidecar agregator log
Beberapa aplikasi (seperti Tomcat) tidak dapat dikonfigurasi dengan mudah untuk menulis log ke stdout dan stderr. Karena aplikasi semacam itu menulis ke berbagai file log di disk, cara terbaik untuk menanganinya di Kubernetes adalah dengan menggunakan pola file bantuan untuk logging. File bantuan adalah container kecil yang berjalan di pod yang sama dengan aplikasi Anda. Untuk tampilan file bantuan yang lebih mendetail, lihat dokumentasi resmi Kubernetes.
Dalam solusi ini, Anda menambahkan agen logging dalam container file bantuan ke aplikasi Anda (di pod yang sama) dan berbagi volume emptyDir di antara dua penampung, seperti yang ditunjukkan dalam contoh YAML di GitHub ini. Selanjutnya, Anda akan mengonfigurasi aplikasi untuk menulis log ke volume bersama dan mengonfigurasi agen logging untuk membaca dan meneruskannya jika diperlukan.
karena Anda tidak menggunakan mekanisme logging Docker dan Kubernetes native, Anda harus menangani rotasi log. Jika agen logging Anda tidak menangani rotasi log, container sidecar lain di pod yang sama dapat menangani rotasi tersebut.
Pastikan container Anda bersifat stateless dan tidak dapat diubah
Tingkat kepentingan: TINGGI.
Jika Anda mencoba container untuk pertama kalinya, jangan perlakukan container sebagai server tradisional. Misalnya, Anda mungkin ingin mengupdate aplikasi di dalam container yang berjalan, atau mem-patch container yang berjalan saat kerentanan muncul.
Container pada dasarnya tidak didesain untuk bekerja seperti itu. Container didesain agar menjadi stateless dan tidak dapat diubah.
Stateless
Stateless berarti setiap status (data persisten dalam bentuk apa pun) disimpan di luar container. Penyimpanan eksternal ini dapat berupa beberapa bentuk, bergantung pada apa yang Anda perlukan:
- Untuk menyimpan file, sebaiknya gunakan penyimpanan objek seperti Cloud Storage.
- Untuk menyimpan informasi seperti sesi pengguna, sebaiknya gunakan penyimpanan nilai kunci eksternal berlatensi rendah, seperti Redis atau Memcached.
- Jika memerlukan penyimpanan level blok (misalnya, untuk database), Anda dapat menggunakan disk eksternal yang terpasang ke container. Jika terjadi GKE, sebaiknya gunakan persistent disk.
Dengan menggunakan opsi ini, Anda dapat menghapus data dari container itu sendiri, yang berarti bahwa container dapat dimatikan dan dihancurkan dengan bersih kapan saja tanpa khawatir data akan hilang Jika container baru dibuat untuk menggantikan container lama, Anda cukup menghubungkan container baru ke datastore yang sama atau mengikatnya ke disk yang sama.
Imutabilitas
Imutabilitas berarti container tidak akan diubah selama masa aktifnya: tidak ada update, tanpa patch, tidak ada perubahan konfigurasi. Jika harus mengupdate kode aplikasi atau menerapkan patch, Anda harus membuat gambar baru dan men-deploy-nya ulang. imutabilitas membuat deployment lebih aman dan lebih berulang. Jika perlu melakukan roll back, Anda cukup men-deploy ulang gambar lama. Pendekatan ini memungkinkan Anda men-deploy gambar container yang sama di setiap lingkungan Anda, membuatnya semirip mungkin.
Untuk menggunakan gambar container yang sama di berbagai lingkungan, sebaiknya eksternalkan konfigurasi container (memproses port, opsi runtime, dan sebagainya). Container biasanya dikonfigurasi dengan variabel lingkungan atau file konfigurasi yang dipasang di jalur tertentu. Di Kubernetes, Anda dapat menggunakan Secret dan ConfigMaps untuk memasukkan konfigurasi dalam container sebagai file atau variabel lingkungan.
Jika perlu memperbarui konfigurasi, deploy container baru (berdasarkan gambar yang sama), dengan konfigurasi yang diperbarui.
Kombinasi stateless dan imutabilitas adalah salah satu nilai jual infrastruktur berbasis container. Kombinasi ini memungkinkan untuk mengotomatiskan deployment serta meningkatkan frekuensi dan keandalan-nya.
Menghindari container hak istimewa
Tingkat kepentingan: TINGGI.
Di mesin virtual atau server bare-metal, hindari dalam menjalankan aplikasi dengan pengguna root karena alasan sederhana: jika aplikasi disusupi, penyerang akan memiliki akses penuh ke server. Untuk alasan yang sama, hindari penggunaan container hak istimewa. Container hak istimewa adalah container yang memiliki akses ke semua perangkat mesin host, yang mengabaikan hampir semua fitur keamanan container.
Jika Anda yakin bahwa Anda perlu menggunakan container hak istimewa, pertimbangkan alternatif berikut:
- Berikan kemampuan khusus ke container melalui
opsi securityContext
Kubernete atau
--cap-addDocker flag. Dokumentasi docker mencantumkan kemampuan yang diaktifkan secara default maupun yang harus Anda aktifkan secara eksplisit. - Jika aplikasi Anda harus mengubah setelan host agar dapat dijalankan, ubah setelan tersebut baik dalam container sidecar atau dalam container init. .Tidak seperti aplikasi Anda, container tersebut tidak perlu terekspos ke traffic internal atau eksternal, sehingga membuatnya lebih terisolasi.
- Jika Anda perlu mengubah sysctl di Kubernetes, gunakan anotasi khusus.
Anda dapat melarang container hak istimewa di Kubernetes menggunakan Pengontrol Kebijakan. Di cluster Kubernetes, Anda tidak dapat membuat pod yang melanggar kebijakan yang dikonfigurasi menggunakan Pengontrol Kebijakan.
Buat aplikasi Anda mudah dipantau
Tingkat kepentingan: TINGGI.
Seperti logging, pemantauan merupakan bagian integral dari manajemen aplikasi. Dalam banyak pemantauan aplikasi dalam container mengikuti prinsip yang sama yang berlaku untuk pemantauan aplikasi yang tidak berada dalam container. Namun, karena infrastruktur dalam container cenderung sangat dinamis, dengan container yang sering dibuat atau dihapus, Anda tidak perlu mengonfigurasi ulang sistem pemantauan setiap kali hal ini terjadi.
Anda dapat membedakan dua class utama pemantauan: pemantauan black-box dan pemantauan white-box. Pemantauan black-box mengacu pada pemeriksaan aplikasi dari luar, seolah-olah Anda adalah pengguna akhir. Pemantauan black-box berguna jika layanan akhir yang ingin Anda tawarkan tersedia dan berfungsi. Karena berada di luar infrastruktur, pemantauan black-box tidak berbeda antara infrastruktur tradisional dan dalam container.
Pemantauan white-box mengacu pada pemeriksaan aplikasi dengan semacam akses istimewa, dan untuk mengumpulkan metrik tentang perilakunya yang tidak dapat dilihat pengguna akhir. Karena pemantauan white-box harus memeriksa lapisan infrastruktur terdalam Anda, pemantauan ini berbeda secara signifikan dengan infrastruktur tradisional dan dalam container.
Opsi populer di komunitas Kubernetes untuk pemantauan white box adalah Prometheus, yaitu sistem yang secara otomatis dapat menemukan pod yang harus dipantau. Prometheus melakukan scraping pod untuk matrik; dengan harapan mendapatkan format tertentu Google Cloud menawarkan Google Cloud Managed Service for Prometheus, sebuah layanan yang dapat digunakan untuk memantau dan membuat pemberitahuan tentang workload secara global tanpa perlu mengelola dan mengoperasikan Prometheus secara manual dalam skala besar. Secara default, Google Cloud Managed Service for Prometheus dikonfigurasi untuk mengumpulkan metrik sistem dari cluster GKE dan mengirimkannya ke Cloud Monitoring. Untuk mengetahui informasi selengkapnya, lihat Kemampuan observasi untuk GKE.
Untuk mendapatkan manfaat dari Prometheus atau Monitoring, aplikasi Anda perlu menampilkan metrik. Dua metode berikut menunjukkan cara melakukannya.
Endpoint HTTP metrik
Endpoint HTTP metrik bekerja dengan cara yang mirip dengan endpoint yang disebutkan
nanti dalam
mengekspos kondisi aplikasi Anda.
Ini mengekspos metrik internal aplikasi, biasanya pada /metrics URI.
Responsnya akan terlihat seperti ini:
http_requests_total{method="post",code="200"} 1027
http_requests_total{method="post",code="400"} 3
http_requests_total{method="get",code="200"} 10892
http_requests_total{method="get",code="400"} 97
Dalam contoh ini, http_requests_total adalah metrik, method dan code adalah label, dan angka paling kanan adalah nilai metrik ini untuk label tersebut.
Di sini, sejak dimulai, aplikasi telah merespons permintaan HTTP GET 97
kali dengan kode error 400.
Pembuatan endpoint HTTP ini mudah dilakukan dengan mudah menggunakan library klien Prometheus yang tersedia dalam banyak bahasa. OpenCensus juga dapat mengekspor metrik menggunakan format ini (di antara banyak fitur lainnya). Jangan mengekspos endpoint ini ke internet publik.
Dokumentasi Prometheus resmi membahas topik ini secara lebih mendalam. Anda juga dapat membaca Bab 6 dari Site Reliability Engineering untuk mempelajari lebih lanjut pemantauan white-box (dan black-box).
Pola sidecar untuk pemantauan
Tidak semua aplikasi dapat diinstrumen dengan /metrics endpoint HTTP. Untuk
mempertahankan pemantauan standar, sebaiknya gunakan sidecar bantuan untuk mengekspor
metrik dalam format yang tepat.
Bagian Pola sidecar agregator log menjelaskan cara menggunakan penampung sidecar untuk mengelola log aplikasi. Anda dapat menggunakan pola yang sama untuk pemantauan: container sidecar menghosting agen pemantauan yang menerjemahkan metrik saat diekspos oleh aplikasi ke format dan protokol yang dipahami oleh sistem pemantauan global.
Pertimbangkan contoh konkret: Aplikasi Java dan Ekstensi Manajemen Java
(JMX). Banyak aplikasi Java mengekspos metrik menggunakan JMX. Daripada menulis ulang
aplikasi untuk mengekspos metrik dalam format Prometheus, Anda dapat memanfaatkan
jmx_exporter.
jmx_exporter mengumpulkan metrik dari aplikasi melalui JMX dan mengekspos
melalui /metrics endpoint yang dapat dibaca Prometheus. Pendekatan ini juga
bermanfaat untuk membatasi eksposur endpoint JMX, yang dapat digunakan
untuk mengubah setelan aplikasi.
Mengekspos kondisi aplikasi Anda
Tingkat kepentingan: SEDANG
Untuk memfasilitasi pengelolaannya dalam produksi, aplikasi harus berkomunikasi tentang statusnya ke keseluruhan sistem: apakah aplikasi berjalan? Apakah responsif? Apakah perangkat siap menerima traffic? Bagaimana perilakunya?
Kubernetes memiliki dua jenis health check: pemeriksaan keaktifan dan pemeriksaan kesiapan. Masing-masing memiliki penggunaan khusus, seperti yang dijelaskan di bagian ini. Anda dapat menerapkan keduanya dengan berbagai cara (termasuk menjalankan perintah di dalam container atau memeriksa port TCP), tetapi metode yang lebih disukai adalah menggunakan endpoint HTTP yang dijelaskan dalam praktik terbaik ini. Untuk mengetahui informasi selengkapnya tentang topik ini, baca dokumentasi Kubernetes.
Pemeriksaan keaktifan
Cara yang direkomendasikan untuk menerapkan
pemeriksaan keaktifan
adalah agar aplikasi mengekspos /healthzendpoint HTTP. Setelah menerima
permintaan pada endpoint ini, aplikasi harus mengirim respons "200 OK" jika
dianggap responsif. Di Kubernetes, responsif berarti container tidak
perlu dimatikan atau dimulai ulang. Faktor yang menentukan responsif bervariasi dari satu
aplikasi ke aplikasi lainnya, tetapi biasanya berarti sebagai berikut:
- Aplikasi sedang berjalan.
- Dependensi utamanya terpenuhi (misalnya, dapat mengakses database-nya).
Pemeriksaan kesiapan
Cara yang direkomendasikan untuk mengimplementasikan
pemeriksaan kesiapan
adalah agar aplikasi Anda mengekspos endpoint HTTP /ready. Saat menerima
permintaan pada endpoint ini, aplikasi harus mengirim respons "200 OK" jika
siap menerima traffic. Siap menerima traffic berarti sebagai berikut:
- Aplikasi responsif.
- Semua langkah inisialisasi potensial telah selesai.
- Permintaan valid apa pun yang dikirim ke aplikasi tidak akan menghasilkan error.
Kubernetes menggunakan pemeriksaan kesiapan untuk mengatur deployment aplikasi Anda. Jika Anda mengupdate Deployment, Kubernetes akan melakukan update berkelanjutan pada pod milik Deployment tersebut. Kebijakan update default-nya adalah mengupdate pod satu per satu: Kubernetes menunggu pod baru siap (seperti yang ditunjukkan oleh pemeriksaan kesiapan) sebelum mengupdate pod berikutnya.
Hindari menjalankan sebagai root
Tingkat kepentingan: SEDANG
Container menyediakan isolasi: dengan setelan default, proses di dalam container Docker tidak dapat mengakses informasi dari mesin host atau dari container lain yang berlokasi sama. Namun, karena container berbagi kernel mesin host, isolasi tidak selengkap mesin virtual, seperti yang dijelaskan dalam postingan blog ini. Penyerang dapat menemukan kerentanan yang belum diketahui (baik di Docker atau kernel Linux itu sendiri) yang memungkinkan penyerang untuk melarikan diri dari container. Jika penyerang menemukan kerentanan dan proses Anda sedang berjalan sebagai root di dalam container, penyerang tersebut akan mendapatkan akses root ke mesin host.
Untuk menghindari kemungkinan ini, praktik terbaiknya adalah tidak menjalankan proses sebagai
root di dalam container. Anda dapat menerapkan perilaku ini di Kubernetes dengan menggunakan Pengontrol Kebijakan.
Saat membuat pod di Kubernetes, gunakan
opsi runAsUser
untuk menentukan pengguna Linux yang menjalankan proses. Pendekatan ini menggantikan
petunjuk USER Dockerfile.
Faktanya, ada tantangan. Banyak paket perangkat lunak yang terkenal memiliki proses utamanya dijalankan sebagai root. Jika Anda ingin menghindari berjalan sebagai root, desain container Anda sehingga dapat dijalankan dengan pengguna yang tidak memiliki hak istimewa dan tidak dikenal. Praktik ini sering kali berarti bahwa Anda harus mengubah izin akses di berbagai folder. Dalam container, jika Anda mengikuti praktik terbaik aplikasi tunggal per container dan Anda menjalankan satu aplikasi dengan satu pengguna—sebaiknya bukan root, Anda dapat memberikan izin tulis ke folder dan file yang perlu ditulis kepada semua pengguna, dan membuat semua folder dan file lainnya hanya dapat ditulis oleh root.
Cara mudah untuk memeriksa apakah container Anda mematuhi praktik terbaik ini adalah dengan
menjalankannya secara lokal dengan pengguna acak dan menguji apakah penampung berfungsi dengan benar. Ganti
[YOUR_CONTAINER] dengan nama container Anda.
docker run --user $((RANDOM+1)) [YOUR_CONTAINER]
Jika container memerlukan volume eksternal, Anda dapat mengonfigurasi opsi Kubernetes fsGroup untuk memberikan kepemilikan volume ini ke grup Linux tertentu. Konfigurasi ini memecahkan masalah kepemilikan file eksternal.
Anda dijalankan oleh pengguna tanpa hak istimewa, proses tersebut tidak akan dapat terikat ke port di bawah 1024. Hal ini biasanya tidak menjadi masalah karena Anda dapat mengonfigurasi Layanan Kubernetes untuk mengarahkan traffic dari satu port ke port lainnya. Misalnya, Anda dapat mengonfigurasi server HTTP untuk mengikat ke port 8080 dan mengalihkan traffic dari port 80 dengan Layanan Kubernetes.
Pilih versi image dengan cermat
Tingkat kepentingan: SEDANG
Saat menggunakan image Docker, baik sebagai image dasar di Dockerfile atau sebagai image yang di-deploy di Kubernetes, Anda harus memilih tag image yang digunakan.
Sebagian besar image publik dan pribadi mengikuti sistem pemberian tag yang mirip dengan yang dijelaskan dalam Praktik Terbaik untuk Membuat Container. Jika gambar menggunakan sistem yang dekat dengan Pembuatan Versi Semantik, Anda harus mempertimbangkan beberapa pemberian tag secara spesifik.
Yang terpenting, tag "terbaru" dapat sering dipindahkan dari gambar ke gambar. Akibatnya, Anda tidak dapat mengandalkan tag ini untuk build yang dapat diprediksi atau dapat direproduksi. Misalnya, ambil Dockerfile berikut:
FROM debian:latest
RUN apt-get -y update && \ apt-get -y install nginx
Jika Anda mem-build image dari Dockerfile ini dua kali, pada waktu yang berbeda, Anda dapat mendapat dua versi Debian dan NGINX yang berbeda. Sebagai gantinya, pertimbangkan versi revisi ini:
FROM debian:11.6
RUN apt-get -y update && \ apt-get -y install nginx
Dengan menggunakan tag yang lebih presisi, pastikan bahwa image yang dihasilkan akan selalu didasarkan pada versi minor Debian tertentu. Karena versi Debian tertentu juga mengirimkan versi NGINX tertentu, anda memiliki kontrol lebih atas image yang sedang di-build.
Hasil ini tidak hanya berlaku pada waktu build, tetapi juga pada saat dijalankan. Jika Anda mereferensikan tag "terbaru" di manifes Kubernetes, Anda tidak memiliki jaminan terkait versi yang akan digunakan Kubernetes. Node cluster yang berbeda mungkin menarik tag "terbaru" yang sama pada momen yang berbeda. Jika tag diperbarui pada satu titik di antara penarikan, Anda dapat mendapat node berbeda yang menjalankan image yang berbeda (yang semuanya diberi tag "terbaru" pada satu titik).
Idealnya, Anda harus selalu menggunakan tag yang tidak dapat diubah di baris FROM. Tag ini memungkinkan Anda memiliki build yang dapat direproduksi. Namun, ada beberapa kelemahan keamanan: semakin banyak Anda menyematkan versi yang ingin digunakan, semakin tidak otomatis patch keamanan yang akan ada pada image Anda. Jika gambar yang Anda gunakan menggunakan pembuatan versi semantik yang tepat, versi patch (yaitu, "Z" di "XYZ") tidak boleh memiliki perubahan yang tidak kompatibel dengan versi sebelumnya: Anda dapat menggunakan "XY" tag dan dapatkan perbaikan bug secara otomatis.
Bayangkan sebuah perangkat lunak yang disebut "SuperSoft". Misalkan proses keamanan untuk SuperSoft adalah untuk memperbaiki kerentanan melalui versi patch baru. Anda ingin menyesuaikan SuperSoft, dan Anda telah menulis Dockerfile berikut:
FROM supersoft:1.2.3
RUN a-command
Setelah beberapa waktu, vendor menemukan kerentanandan merilis SuperSoft
versi 1.2.4 untuk mengatasi masalah
Dalam hal ini, Anda harus tetap
mengetahui informasi tentang patch SuperSoft dan mengupdate Dockerfile Anda sebagaimana mestinya.
Jika Anda menggunakan FROM supersoft:1.2 di Dockerfile, versi baru
akan otomatis ditarik.
Pada akhirnya, Anda harus memeriksa sistem pemberian tag dari setiap gambar eksternal yang digunakan dengan cermat, memutuskan seberapa besar Anda memercayai orang-orang yang membuat image tersebut, dan memutuskan tag yang akan digunakan.
Langkah selanjutnya
- Pelajari Praktik terbaik untuk membuat container.
- Bangun container pertama Anda dengan Cloud Build.
- Jalankan cluster GKE pertama Anda.
- Mempercepat pembangunan Cloud Build.
- Docker Inc. memiliki kumpulan praktik terbaik sendiri. Beberapa di antaranya tercakup dalam dokumen ini, tetapi yang lain tidak.
Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.