Dokumen ini menjelaskan metodologi aplikasi dua belas faktor yang populer dan cara menerapkannya saat Anda mengembangkan aplikasi yang berjalan di Google Cloud. Jika menggunakan metodologi ini, Anda dapat membuat aplikasi yang skalabel dan tangguh yang dapat di-deploy terus-menerus dengan fleksibilitas maksimum.
Dokumen ini ditujukan bagi developer yang sudah memahami Google Cloud, kontrol versi, continuous integration, dan teknologi container.
Pengantar
Developer memindahkan aplikasi ke cloud, dengan demikian mereka menjadi lebih berpengalaman dalam mendesain dan men-deploy aplikasi berbasis cloud. Dari pengalaman tersebut, serangkaian praktik terbaik, yang umumnya dikenal sebagai dua belas faktor, telah muncul. Mendesain aplikasi dengan mempertimbangkan faktor-faktor ini memungkinkan Anda men-deploy aplikasi ke cloud yang lebih portabel dan tangguh jika dibandingkan dengan aplikasi yang di-deploy ke lingkungan lokal, yang memerlukan waktu lebih lama untuk menyediakan resource baru.
Namun, mendesain aplikasi modern berbasis cloud memerlukan perubahan cara berpikir Anda tentang rekayasa software, konfigurasi, dan deployment, jika dibandingkan dengan mendesain aplikasi untuk lingkungan lokal. Dokumen ini membantu Anda memahami cara menerapkan kedua belas faktor tersebut pada desain aplikasi.
Keuntungan aplikasi dua belas faktor
Desain dua belas faktor juga membantu Anda memisahkan komponen aplikasi, sehingga setiap komponen dapat diganti dengan mudah, atau ditingkatkan atau diturunkan skalanya dengan lancar. Karena faktor tersebut tidak bergantung pada bahasa pemrograman atau stack software, desain dua belas faktor dapat diterapkan ke berbagai aplikasi.
Dua belas faktor
1. Codebase
Anda harus melacak kode untuk aplikasi dalam sistem kontrol versi seperti Git atau Mercurial. Anda mengerjakan aplikasi dengan memeriksa kode ke lingkungan pengembangan lokal Anda. Menyimpan kode di sistem kontrol versi memungkinkan tim Anda untuk bekerja sama dengan memberikan jejak audit perubahan pada kode, cara sistematis untuk mengatasi konflik penggabungan, dan kemampuan untuk melakukan roll back kode ke versi sebelumnya. Platform ini juga menyediakan tempat untuk melakukan continuous integration (CI) dan continuous deployment (CD).
Meskipun developer mungkin sedang mengerjakan berbagai versi kode di lingkungan pengembangan mereka, pada waktu tertentu sumber terpercaya adalah kode dalam sistem kontrol versi. Kode di repositori adalah hal yang di-build, diuji, dan di-deploy, dan jumlah repositori tidak bergantung pada jumlah lingkungan. Kode dalam repositori digunakan untuk menghasilkan satu build, yang digabungkan dengan konfigurasi khusus lingkungan untuk menghasilkan rilis yang tidak dapat diubah, yaitu rilis yang tidak dapat melakukan perubahan, termasuk ke konfigurasi— yang kemudian dapat di-deploy ke sebuah lingkungan. (Setiap perubahan yang diperlukan untuk rilis harus menghasilkan rilis baru.)
Cloud Source Repositories memungkinkan Anda untuk berkolaborasi dan mengelola kode dalam repositori Git pribadi yang skalabel dan berfitur lengkap. Library ini dilengkapi dengan fungsi penelusuran kode di seluruh repositori. Anda juga dapat terhubung ke produk Google Cloud lainnya seperti Cloud Build, App Engine, Cloud Logging, dan Pub/Sub.
2. Dependensi
Ada dua pertimbangan terkait dependensi untuk aplikasi dua belas faktor: deklarasi dependensi dan isolasi dependensi.
Aplikasi dua belas faktor tidak perlu memiliki dependensi implisit. Anda harus mendeklarasikan dependensi apa pun secara eksplisit dan memeriksa dependensi tersebut ke dalam kontrol versi. Hal ini memungkinkan Anda memulai kode secara cepat dengan cara yang dapat diulang dan memudahkan pelacakan perubahan dependensi. Banyak bahasa pemrograman menawarkan cara untuk mendeklarasikan dependensi secara eksplisit, seperti pip untuk Python dan Bundler untuk Ruby.
Anda juga harus mengisolasi aplikasi dan dependensinya dengan mengemasnya ke dalam container. Container memungkinkan Anda mengisolasi aplikasi dan dependensinya dari lingkungannya serta memastikan aplikasi berfungsi secara seragam meskipun ada perbedaan antara lingkungan pengembangan dan staging.
Artifact Registry adalah layanan pengelolaan artefak pribadi yang terkelola sepenuhnya dan mendukung berbagai jenis artefak seperti image container, paket bahasa (seperti Maven dan npm), serta paket OS (seperti RPM). Untuk membantu mengelola hasil build CI/CD dan dependensinya, Anda dapat menggunakan Cloud IAM dengan Artifact Registry dengan kontrol akses yang sangat terperinci. Artifact Analysis mendeteksi kerentanan dalam image container yang dikirim ke Artifact Registry untuk membantu memastikan image container Anda aman untuk di-deploy.
Selain itu, karena sudah terintegrasi dengan CI/CD, Anda juga dapat menyiapkan pipeline yang sepenuhnya otomatis untuk mendapatkan masukan dalam waktu singkat. Anda dapat mengirim image ke registry-nya, lalu mengambil image menggunakan endpoint HTTP dari mesin mana pun, baik itu instance Compute Engine atau hardware Anda sendiri.
3. Konfigurasi
Setiap aplikasi modern memerlukan beberapa bentuk konfigurasi. Biasanya Anda memiliki konfigurasi yang berbeda untuk setiap lingkungan, seperti pengembangan, pengujian, dan produksi. Konfigurasi ini biasanya mencakup kredensial akun layanan dan handle resource untuk mendukung layanan seperti database.
Konfigurasi untuk setiap lingkungan harus berada di luar kode dan tidak boleh dimasukkan ke dalam kontrol versi. Semua orang hanya mengerjakan satu versi kode, tetapi Anda memiliki beberapa konfigurasi. Lingkungan deployment menentukan konfigurasi mana yang akan digunakan. Dengan begitu, satu versi biner dapat di-deploy ke setiap lingkungan, dengan satu-satunya perbedaan adalah konfigurasi runtime. Cara mudah untuk memeriksa apakah konfigurasi telah dieksternalkan dengan benar adalah dengan melihat apakah kode dapat dipublikasikan tanpa mengungkapkan kredensial apa pun.
Salah satu cara mengeksternalkan konfigurasi adalah dengan membuat file konfigurasi. Namun, file konfigurasi biasanya khusus untuk bahasa atau framework pengembangan.
Pendekatan yang lebih baik adalah menyimpan konfigurasi dalam variabel lingkungan. Ini mudah diubah untuk setiap lingkungan saat runtime, kemungkinan tidak dimasukkan ke dalam kontrol versi, dan tidak bergantung pada bahasa pemrograman dan framework pengembangan. Di Google Kubernetes Engine (GKE), Anda dapat menggunakan ConfigMaps. Dengan begitu, Anda dapat mengikat variabel lingkungan, nomor port, file konfigurasi, argumen command line, dan artefak konfigurasi lainnya ke container pod dan komponen sistem Anda saat runtime.
Cloud Functions dan Cloud Run mendukung penggunaan variabel lingkungan. Anda dapat mengeksternalkan konfigurasi dan mengubahnya dari Google Cloud Console atau dengan menggunakan Google Cloud SDK.
4. Layanan Pendukung
Setiap layanan yang digunakan aplikasi sebagai bagian dari operasi normalnya, seperti sistem file, database, sistem caching, dan antrean pesan, harus diakses sebagai layanan dan dieksternalkan dalam konfigurasi. Anda harus menganggap layanan pendukung ini sebagai abstraksi untuk resource yang mendasarinya. Misalnya, saat memperlakukan penyimpanan sebagai layanan pendukung memungkinkan Anda untuk mengubah jenis penyimpanan yang mendasarinya dengan lancar, karena penyimpanan tersebut dipisahkan dari aplikasi. Selanjutnya, Anda dapat melakukan perubahan seperti beralih dari database PostgreSQL lokal ke Cloud SQL untuk PostgreSQL tanpa mengubah kode aplikasi.
5. Build, rilis, jalankan
Penting untuk memisahkan proses deployment software ke dalam tiga tahap yang berbeda: build, rilis, dan jalankan. Setiap tahap harus menghasilkan artefak yang dapat diidentifikasi secara unik. Setiap deployment harus ditautkan ke rilis tertentu yang merupakan hasil dari penggabungan konfigurasi lingkungan dengan suatu build. Hal ini memungkinkan rollback yang mudah dan jejak audit yang terlihat dari histori setiap deployment produksi.
Anda dapat memicu tahap build secara manual, tetapi biasanya dipicu secara otomatis saat Anda meng-commit kode yang telah lulus semua pengujian yang diperlukan. Tahap build mengambil kode, mengambil library dan aset yang diperlukan, lalu mengemasnya ke dalam biner atau container mandiri. Hasil dari tahap build adalah artefak build.
Setelah tahap build selesai, tahap rilis akan menggabungkan artefak build dengan konfigurasi lingkungan tertentu. Tindakan ini akan menghasilkan rilis. Rilis tersebut dapat otomatis di-deploy ke dalam lingkungan oleh aplikasi deployment berkelanjutan. Atau, Anda dapat memicu rilis melalui aplikasi deployment berkelanjutan yang sama.
Terakhir, tahap run akan meluncurkan rilis dan memulainya. Misalnya, jika
Anda men-deploy ke GKE, Cloud Build dapat memanggil langkah build
gke-deploy
untuk men-deploy ke cluster GKE Anda. Cloud Build
dapat mengelola dan mengotomatiskan tahap build, rilis, dan jalankan di berbagai
berbagai bahasa dan lingkungan menggunakan file konfigurasi build dalam format YAML atau
JSON.
Selain itu, Anda dapat menggunakan Cloud Deploy, yang merupakan layanan terkelola sepenuhnya yang menyediakan continuous delivery ke GKE, Cloud Run, dan GKE Enterprise. Dengan Cloud Deploy, Anda dapat membuat pipeline pengiriman yang mencakup langkah persetujuan dan promosi yang lancar ke berbagai lingkungan. Selain itu, Cloud Deploy mendukung rollback satu langkah untuk aplikasi yang di-deploy di semua target.
6. Proses
Anda menjalankan aplikasi dua belas faktor di lingkungan sebagai satu atau beberapa proses. Proses ini harus stateless dan tidak boleh saling berbagi data. Hal ini memungkinkan aplikasi meningkatkan skala melalui replikasi prosesnya. Membuat aplikasi stateless juga akan menjadikan proses portabel di seluruh infrastruktur komputasi.
Jika Anda terbiasa dengan konsep sesi "melekat", hal ini memerlukan perubahan cara berpikir Anda dalam menangani dan mempertahankan data. Karena proses dapat hilang kapan saja, Anda tidak dapat mengandalkan konten penyimpanan lokal yang tersedia, atau bahwa setiap permintaan berikutnya akan ditangani oleh proses yang sama. Oleh karena itu, Anda harus secara eksplisit mempertahankan data apa pun yang perlu digunakan kembali dalam layanan pendukung eksternal seperti database.
Jika perlu mempertahankan data, Anda dapat menggunakan Memorystore dan Filestore sebagai layanan pendukung untuk menyimpan status aplikasi Anda ke dalam cache dan berbagi data umum antar proses untuk mendorong pengaitan longgar.
7. Binding port
Di lingkungan non-cloud, aplikasi web sering ditulis untuk dijalankan di container aplikasi seperti GlassFish, Apache Tomcat, dan Apache HTTP Server. Sebaliknya, aplikasi dua belas faktor tidak mengandalkan container aplikasi eksternal. Sebagai gantinya, mereka memaketkan library server web sebagai suatu bagian dari aplikasi itu sendiri.
Ini adalah praktik terbaik arsitektur bagi layanan untuk mengekspos nomor port,
yang ditentukan oleh variabel lingkungan
PORT.
Aplikasi yang mengekspor binding port dapat menggunakan informasi binding port secara eksternal (sebagai variabel lingkungan) saat menggunakan model platform-as-a-service. Di Google Cloud, Anda dapat men-deploy aplikasi di layanan platform seperti seperti Compute Engine, GKE, App Engine, atau Cloud Run.
Dalam layanan ini, lapisan pemilihan rute merutekan permintaan dari nama host yang ditampilkan kepada publik ke proses web Anda yang terikat port. Misalnya, saat men-deploy aplikasi ke App Engine, Anda mendeklarasikan dependensi untuk menambahkan library server web ke aplikasi, seperti Express (untuk Node.js), Flask, dan Gunicorn (untuk Python) atau Jetty (untuk Java).
Anda tidak boleh melakukan hard code nomor port dalam kode Anda. Sebagai gantinya, Anda harus memberikan nomor port di lingkungan, seperti dalam variabel lingkungan. Hal ini menjadikan aplikasi Anda portabel saat Anda menjalankannya di Google Cloud.
Karena Kubernetes memiliki penemuan layanan bawaan, di Kubernetes Anda dapat memisahkan binding port dengan memetakan port layanan ke container. Penemuan layanan dilakukan dengan menggunakan nama DNS internal.
Daripada melakukan hard code pada port yang diproses server web, konfigurasi menggunakan variabel lingkungan. Cuplikan kode dari suatu aplikasi App Engine berikut ini menunjukkan cara menerima nilai port yang diteruskan dalam variabel lingkungan.
const express = require('express')
const request = require('got')
const app = express()
app.enable('trust proxy')
const PORT = process.env.PORT || 8080
app.listen(PORT, () => {
console.log('App listening on port ${PORT}')
console.log('Press Ctrl+C to quit.')
})
8. Serentak
Anda harus menguraikan aplikasi ke dalam proses independen berdasarkan jenis proses, seperti proses latar belakang, web, dan proses pekerja. Hal ini memungkinkan aplikasi Anda untuk meningkatkan dan menurunkan skala berdasarkan persyaratan workload individual. Sebagian besar aplikasi berbasis cloud memungkinkan Anda melakukan penskalaan sesuai permintaan. Anda harus mendesain aplikasi sebagai beberapa proses terdistribusi yang mampu menjalankan blok pekerjaan secara independen dan menyebarkan skala dengan menambahkan lebih banyak proses.
Bagian berikut menjelaskan beberapa konstruksi untuk memungkinkan aplikasi melakukan penskalaan. Aplikasi yang dibuat dengan prinsip ketersediaan dan statelessness sebagai intinya berada di posisi yang baik untuk diperoleh dari konstruksi penskalaan horizontal ini.
Menggunakan Cloud Run
Cloud Run
adalah platform komputasi yang memungkinkan Anda menjalankan container langsung di atas infrastruktur yang dikelola Google. Cloud Run mendukung dua cara untuk menjalankan
kode Anda. Cloud Run services berjalan terus-menerus sebagai layanan. Ini biasanya digunakan untuk
merespons permintaan atau peristiwa web. Cloud Run jobs menjalankan kode yang melakukan pekerjaan
tertentu dan menghentikan saat pekerjaan selesai. Cloud Run juga menawarkan
Cloud Scheduler untuk menjalankan tugas batch. Struktur ini sangat cocok untuk menerapkan
konkurensi dan untuk menskalakan arsitektur layanan yang memungkinkan.
Untuk informasi selengkapnya tentang Cloud Run, lihat Apa itu Cloud Run.
Menggunakan Cloud Functions
Cloud Functions adalah fungsi stateless dengan satu tujuan tunggal yang berjalan di Google Cloud, dengan arsitektur dasar tempatnya dijalankan dikelola oleh Google untuk Anda. Cloud Functions merespons pemicu peristiwa, seperti suatu upload ke bucket Cloud Storage atau pesan Pub/Sub. Setiap pemanggilan fungsi merespons satu peristiwa atau permintaan.
Cloud Functions menangani permintaan masuk dengan menetapkannya ke instance fungsi Anda. Ketika volume permintaan masuk melebihi jumlah instance yang ada, Cloud Functions mungkin memulai instance baru untuk menangani permintaan. Dengan perilaku penskalaan yang otomatis dan terkelola sepenuhnya ini, Cloud Functions dapat menangani banyak permintaan secara paralel, masing-masing menggunakan suatu instance yang berbeda pada fungsi Anda.
Menggunakan App Engine
Anda dapat menghosting aplikasi di infrastruktur terkelola Google Cloud menggunakan App Engine. Instance adalah unit komputasi yang digunakan App Engine untuk menskalakan aplikasi Anda secara otomatis. Pada waktu tertentu, aplikasi Anda dapat berjalan di satu instance atau di banyak instance, dengan permintaan tersebar di semua instance tersebut.
Penjadwal App Engine menentukan cara menyalurkan setiap permintaan baru. Scheduler mungkin menggunakan instance yang ada (baik yang tidak ada aktivitas maupun yang menerima permintaan serentak), menempatkan permintaan dalam antrean permintaan yang tertunda, atau memulai instance baru untuk permintaan tersebut. Keputusan ini memperhitungkan jumlah instance yang tersedia, seberapa cepat aplikasi Anda melayani permintaan (latensinya), dan berapa lama waktu yang diperlukan untuk memulai instance baru.
Jika Anda menggunakan penskalaan otomatis, Anda dapat menyeimbangkan performa dan biaya dengan menetapkan pemakaian CPU target, throughput target, dan permintaan serentak maksimum.
Anda dapat menentukan jenis penskalaan dalam file app.yaml, yang diupload untuk
versi layanan Anda. Berdasarkan input konfigurasi ini, infrastruktur App Engine
menggunakan instance dinamis atau resident. Untuk mengetahui informasi selengkapnya tentang
jenis penskalaan, lihat
dokumentasi App Engine.
Menggunakan penskalaan otomatis GKE
Ada beberapa konstruksi utama Kubernetes yang berlaku untuk proses penskalaan:
Penskalaan Otomatis Pod Horizontal (HPA). Kubernetes dapat dikonfigurasi untuk meningkatkan atau menurunkan jumlah pod yang berjalan di cluster berdasarkan metrik standar atau kustom. Hal ini berguna ketika Anda perlu merespons beban variabel di cluster GKE.
Penskalaan otomatis node. Jika permintaan meningkat, Anda mungkin perlu menskalakan cluster untuk mengakomodasi lebih banyak pod. Dengan GKE, Anda dapat mengonfigurasi cluster Anda secara deklaratif untuk melakukan penskalaan. Dengan mengaktifkanpenskalaan otomatis GKE akan otomatis menskalakan node saat pod tambahan perlu dijadwalkan dan saat node yang ada tidak dapat mengakomodasi mereka. GKE juga menurunkan skala node saat beban pada cluster menurun, sesuai dengan batas yang telah Anda konfigurasi.
Tugas. GKE mendukung tugas Kubernetes. Tugas dapat didefinisikan secara luas sebagai tugas yang memerlukan satu atau beberapa pod untuk dijalankan agar dapat menjalankan tugas. Tugas mungkin berjalan satu kali atau sesuai jadwal. Pod yang menjadi tempat tugas berjalan akan dibuang saat tugas selesai. File YAML yang mengonfigurasi tugas menentukan detail tentang penanganan error, paralelisme, cara mulai ulang ditangani, dan sebagainya.
Menggunakan Compute Engine.
Atau, Anda dapat men-deploy dan mengelola aplikasi di Compute Engine. Dalam hal ini, Anda dapat menskalakan aplikasi untuk merespons beban variabel menggunakan grup instance terkelola (MIG) berdasarkan pemakaian CPU, permintaan yang ditangani, atau sinyal telemetri lainnya dari aplikasi Anda.
Gambar berikut mengilustrasikan fitur utama yang disediakan oleh grup instance terkelola.
Menggunakan grup instance terkelola memungkinkan aplikasi Anda diskalakan untuk permintaan yang masuk dan memiliki ketersediaan tinggi. Konsep ini berfungsi sangat baik untuk aplikasi stateless seperti front-end web dan untuk beban kerja berbasis batch dengan performa tinggi.
9. Ketersediaan
Untuk aplikasi yang berjalan di infrastruktur cloud, Anda harus memperlakukannya dan infrastruktur dasar sebagai resource yang dapat diuraikan. Aplikasi Anda harus dapat menangani hilangnya sementara infrastruktur yang mendasarinya serta harus dapat mematikan dan memulai ulang dengan baik.
Prinsip utama yang perlu dipertimbangkan meliputi hal-hal berikut:
- Pisahkan fungsi seperti pengelolaan status dan penyimpanan data transaksi menggunakan layanan pendukung. Untuk mengetahui informasi selengkapnya, lihat Layanan pendukung di bagian awal dokumen ini.
- Mengelola variabel lingkungan di luar aplikasi agar dapat digunakan pada saat runtime.
- Memastikan waktu startup minimal. Artinya, Anda harus menentukan banyaknya lapisan yang akan di-build ke dalam image saat menggunakan virtual machine, seperti image publik dibandingkan image kustom. Keputusan ini berlaku khusus untuk setiap aplikasi dan harus didasarkan pada tugas yang dijalankan skrip startup. Misalnya, jika Anda mendownload beberapa paket atau biner dan menginisialisasinya selama startup, sebagian besar waktu mulai Anda akan dikhususkan untuk menyelesaikan tugas ini.
- Gunakan fitur native Google Cloud untuk melakukan tugas infrastruktur. Misalnya, Anda dapat menggunakan update berkelanjutan di GKE dan dan mengelola kunci keamanan menggunakan Cloud Key Management Service (Cloud KMS).
Gunakan sinyal SIGTERM (saat tersedia) untuk memulai penonaktifan tanpa masalah. Misalnya, saat App Engine Flex menghentikan suatu instance, biasanya App Engine Flex mengirimkan sinyal STOP (SIGTERM) ke container aplikasi. Aplikasi Anda dapat menggunakan sinyal ini untuk melakukan tindakan pembersihan sebelum penonaktifan container. (Aplikasi Anda tidak perlu merespons peristiwa SIGTERM.) Dalam kondisi normal, sistem menunggu hingga 30 detik agar aplikasi berhenti, lalu mengirimkan sinyal KILL (SIGKILL).
Cuplikan berikut di aplikasi App Engine menunjukkan cara Anda dapat menangkap sinyal SIGTERM untuk menutup koneksi database terbuka.
const express = require('express') const dbConnection = require('./db') // Other business logic related code app.listen(PORT, () => { console.log('App listening on port ${PORT}') console.log('Press Ctrl+C to quit.') }) process.on('SIGTERM', () => { console.log('App Shutting down') dbConnection.close() // Other closing of database connection })
10. Kesetaraan lingkungan
Aplikasi perusahaan berpindah-pindah lingkungan selama siklus pengembangannya. Biasanya, lingkungan ini merupakan pengembangan, pengujian dan staging, serta produksi. Sebaiknya jaga lingkungan ini semirip mungkin.
Kesetaraan lingkungan adalah fitur yang dianggap oleh sebagian besar developer. Meskipun demikian, seiring dengan pertumbuhan perusahaan dan ekosistem IT mereka, kesetaraan lingkungan menjadi lebih sulit untuk dikelola.
Mempertahankan kesetaraan lingkungan menjadi lebih mudah dalam beberapa tahun terakhir karena developer telah menggunakan kontrol sumber, pengelolaan konfigurasi, dan file konfigurasi dengan template. Hal ini mempermudah deployment aplikasi ke beberapa lingkungan secara konsisten. Sebagai contoh, dengan menggunakan Docker dan Docker Compose, Anda dapat memastikan bahwa stack aplikasi mempertahankan bentuk dan instrumentasinya di seluruh lingkungan.
Tabel berikut mencantumkan layanan dan alat Google Cloud yang dapat Anda gunakan saat mendesain aplikasi untuk berjalan di Google Cloud. Komponen-komponen ini memiliki berbagai tujuan dan secara kolektif membantu Anda membangun alur kerja yang membuat lingkungan Anda lebih konsisten.
| Komponen Google Cloud | Tujuan |
|---|---|
| Cloud Source Repositories | Satu tempat bagi tim Anda untuk menyimpan, mengelola, dan melacak kode. |
| Artifact Registry | Pengelola paket universal untuk semua artefak build dan dependensi. |
| Cloud Build | Suatu layanan terkelola sepenuhnya yang menjalankan build Anda di infrastruktur Google Cloud. |
| Cloud KMS | Simpan kunci kriptografis Anda di satu layanan cloud terpusat untuk digunakan langsung oleh aplikasi dan resource cloud lainnya. |
| Cloud Storage | Simpan gambar kustom yang Anda buat dari disk sumber, gambar, snapshot, atau gambar yang disimpan di Cloud Storage. Anda dapat menggunakan image ini untuk membuat instance mesin virtual (VM) yang disesuaikan untuk aplikasi Anda. |
| Cloud Deploy | Menyediakan pengiriman otomatis aplikasi Anda ke serangkaian lingkungan target dalam urutan yang ditentukan. |
11. Log
Log memberi Anda kesadaran tentang kesehatan aplikasi. Penting untuk memisahkan pengumpulan, pemrosesan, dan analisis log dari logika inti aplikasi Anda. Pemisahan logging sangat berguna saat aplikasi Anda memerlukan penskalaan dinamis dan berjalan di cloud publik, karena dapat menghilangkan beban pengelolaan lokasi penyimpanan untuk log dan penggabungan dari VM terdistribusi (dan seringkali bersifat efemeral).
Google Cloud menawarkan serangkaian alat yang membantu pengumpulan, pemrosesan, dan analisis log terstruktur. Sebaiknya instal Agen Cloud Logging di VM Compute Engine Anda. (Agen ini sudah diinstal sebelumnya di App Engine dan image VM GKE secara default.) Agen memantau kumpulan lokasi logging yang telah dikonfigurasi sebelumnya. Log yang dihasilkan oleh aplikasi Anda yang berjalan di VM dikumpulkan dan di-streaming ke Cloud Logging.
Ketika logging diaktifkan untuk cluster GKE, agen logging akan di-deploy di setiap node yang merupakan bagian dari cluster tersebut. Agen mengumpulkan log, memperkaya log dengan metadata yang relevan, dan menyimpannya di penyimpanan data. Log ini tersedia untuk ditinjau menggunakan Cloud Logging. Jika Anda memerlukan kontrol lebih besar atas apa yang dicatat ke dalam log, Anda dapat menggunakan set daemon Fluentd.
Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi agen Logging.
12. Proses admin
Proses administratif biasanya terdiri dari tugas satu kali atau tugas berjangka waktu dan dapat diulang seperti membuat laporan, menjalankan skrip batch, memulai pencadangan database, dan memigrasikan skema. Faktor proses admin dalam manifesto dua belas faktor ditulis dengan mempertimbangkan tugas satu kali. Untuk aplikasi berbasis cloud, faktor ini menjadi lebih relevan saat Anda membuat tugas yang dapat diulang, dan panduan di bagian ini berorientasi pada tugas-tugas seperti itu.
Pemicu dengan waktu sering kali dibuat sebagai cron job dan ditangani pada dasarnya oleh aplikasi itu sendiri. Model ini berfungsi, tetapi ini memperkenalkan logika yang dikaitkan erat dengan aplikasi serta memerlukan pemeliharaan dan koordinasi, terutama jika aplikasi Anda didistribusikan di seluruh zona waktu.
Oleh karena itu, saat mendesain proses admin, Anda harus memisahkan pengelolaan tugas ini dari aplikasi itu sendiri. Bergantung pada alat dan infrastruktur tempat aplikasi Anda berjalan, gunakan saran berikut:
- Untuk menjalankan aplikasi di GKE, mulai container terpisah untuk tugas admin. Anda dapat memanfaatkan CronJobs di GKE. CronJobs berjalan dalam container sementara dan memungkinkan Anda mengontrol waktu, frekuensi eksekusi, dan percobaan ulang jika tugas gagal atau jika tugas tersebut memerlukan waktu terlalu lama untuk diselesaikan.
- Untuk menghosting aplikasi di App Engine atau Compute Engine, Anda dapat mengeksternalkan mekanisme pemicu dan membuat suatu endpoint untuk dipanggil pemicu. Pendekatan ini membantu menentukan batas seputar tanggung jawab aplikasi, berbeda dengan fokus tujuan tunggal endpoint. Cloud Tasks adalah layanan eksekusi tugas asinkron yang dapat Anda gunakan untuk menerapkan pola ini dengan App Engine. Anda juga dapat menggunakan Cloud Scheduler, enjadwal tingkat perusahaan yang terkelola sepenuhnya di Google Cloud, untuk memicu operasi terjadwal.
Melampaui dua belas faktor
Dua belas faktor yang dijelaskan dalam dokumen ini menawarkan panduan tentang cara melakukan pendekatan mem-build aplikasi berbasis cloud. Aplikasi ini adalah elemen penyusun dasar dari sebuah perusahaan.
Sebuah perusahaan biasa memiliki banyak aplikasi seperti ini, sering kali dikembangkan oleh beberapa tim secara kolaboratif untuk memberikan kemampuan bisnis. Sebaiknya tetapkan beberapa prinsip tambahan selama siklus proses pengembangan aplikasi, bukan sebagai susulan, untuk membahas cara aplikasi berkomunikasi satu sama lain, serta cara prinsip tersebut diamankan dan akses yang terkontrol.
Bagian berikut menguraikan beberapa pertimbangan tambahan yang harus Anda buat selama pendesainan dan pengembangan aplikasi.
Mengutamakan API
Aplikasi berkomunikasi menggunakan API. Saat membuat aplikasi, pikirkan tentang bagaimana aplikasi akan digunakan oleh ekosistem aplikasi Anda, dan mulailah dengan merancang strategi API. Desain API yang baik membuat API mudah digunakan oleh developer aplikasi dan pemangku kepentingan eksternal. Sebaiknya mulai dengan mendokumentasikan API menggunakan spesifikasi OpenAPI sebelum Anda menerapkan kode apa pun.
API memisahkan fungsi aplikasi yang mendasarinya. Endpoint API yang dirancang dengan baik harus mengisolasi dan memisahkan aplikasi yang menggunakannya dari infrastruktur aplikasi yang menyediakan layanan. Pemisahan ini memberi Anda kemampuan untuk mengubah layanan dasar dan infrastrukturnya secara independen, tanpa memengaruhi konsumen aplikasi.
Penting untuk membuat katalog, mendokumentasikan, dan memublikasikan API yang Anda kembangkan, sehingga konsumen API dapat menemukan dan menggunakan API tersebut. Idealnya, Anda ingin konsumen API melayani dirinya sendiri. Anda dapat melakukannya dengan menyiapkan portal developer. Portal developer berfungsi sebagai titik entri bagi semua konsumen API— internal untuk perusahaan, atau eksternal untuk konsumen seperti developer dari ekosistem partner Anda.
Apigee, rangkaian produk pengelolaan API Google, membantu Anda mengelola seluruh siklus proses API mulai dari desain, build, hingga publikasi.
Keamanan
Ranah keamanan yang luas, dan meliputi sistem operasi, jaringan dan firewall, keamanan data dan database, keamanan aplikasi, serta pengelolaan identitas dan akses. Sangat penting untuk menangani semua dimensi keamanan dalam ekosistem perusahaan.
Dari sudut pandang aplikasi, API menyediakan akses ke aplikasi dalam ekosistem perusahaan Anda. Oleh karena itu, Anda harus memastikan bahwa elemen penyusun ini memenuhi pertimbangan keamanan selama proses desain dan build aplikasi. Pertimbangan untuk membantu melindungi akses ke aplikasi Anda meliputi hal-hal berikut:
- Transport Layer Security (TLS). Menggunakan TLS untuk membantu melindungi data dalam pengiriman. Anda mungkin ingin menggunakan TLS timbal balik untuk aplikasi bisnis Anda; hal ini menjadi lebih mudah jika Anda menggunakan mesh layanan seperti Istio di Google Kubernetes Engine. Beberapa kasus penggunaan juga umum digunakan untuk membuat daftar izin dan daftar tolak berdasarkan alamat IP sebagai lapisan keamanan tambahan. Keamanan transport juga melibatkan perlindungan layanan Anda dari serangan DDoS dan bot.
- Keamanan aplikasi dan pengguna akhir. Keamanan transportasi membantu memberikan keamanan untuk data dalam pengiriman dan membangun kepercayaan. Namun, praktik terbaiknya adalah menambahkan keamanan tingkat aplikasi untuk mengontrol akses ke aplikasi Anda berdasarkan siapa konsumen aplikasi tersebut. Konsumennya dapat berupa aplikasi lain, karyawan, partner, atau pelanggan akhir perusahaan Anda. Anda dapat menerapkan keamanan menggunakan kunci API (untuk aplikasi yang menggunakan), autentikasi dan otorisasi berbasis sertifikasi, pertukaran JSON Web Tokens (JWTs) atau Security Assertion Markup Language (SAML).
Lanskap keamanan terus berkembang dalam suatu perusahaan, sehingga Anda akan lebih sulit untuk membuat kode konstruksi keamanan dalam aplikasi Anda. Produk pengelolaan API seperti Apigee membantu mengamankan API di semua lapisan yang disebutkan di bagian ini.
Keamanan supply chain software merupakan masalah yang menantang untuk dipecahkan. Anda harus melakukan tindakan pencegahan. Software Delivery Shield adalah solusi menyeluruh yang terkelola sepenuhnya dan end-to-end yang membantu meningkatkan keamanan supply chain software di seluruh siklus proses pengembangan software. Ini menawarkan layanan berikut, dan lainnya:
Cloud Build. Mendukung build SLSA Level 3 untuk image container dan menghasilkan provenance build yang diautentikasi dan tidak palsu untuk aplikasi dalam container.
Assured Open Source Software. Membantu mengurangi risiko supply chain software Anda dengan menggunakan paket OSS yang sama dengan yang digunakan Google.
Selain itu, berbagai layanan dan fungsi disiapkan untuk membantu meningkatkan keamanan supply chain software Anda.
Untuk informasi selengkapnya tentang keamanan supply chain software, lihat Keamanan supply chain software. Untuk mengetahui informasi selengkapnya tentang Software Delivery Shield, lihat Ringkasan Software Delivery Shield.
Langkah selanjutnya
- Meninjau aplikasi demo microservice yang menerapkan prinsip aplikasi dua belas faktor dan dibuat menggunakan produk serta layanan Google Cloud.
- Mengunjungi Cloud Architecture Center dan temukan arsitektur referensi, panduan, dan praktik terbaik untuk membuat atau memigrasikan workload Anda di Google Cloud.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.