Ringkasan deployment workload VM

Panduan ini membahas konteks konseptual yang diperlukan untuk men-deploy workload berbasis virtual machine (VM) ke cluster Google Distributed Cloud (GDC) dengan air gap di bare metal menggunakan runtime VM. Workload dalam panduan ini adalah contoh platform sistem tiket yang tersedia di hardware lokal.

Arsitektur

Hierarki resource

Di GDC, Anda men-deploy komponen yang membentuk sistem tiket dalam organisasi tenant khusus untuk tim Operasi, yang identik dengan organisasi pelanggan mana pun. Organisasi adalah kumpulan cluster, resource infrastruktur, dan workload aplikasi yang dikelola bersama. Setiap organisasi dalam instance GDC menggunakan kumpulan server khusus, yang memberikan isolasi yang kuat antar-tenant. Untuk mengetahui informasi selengkapnya tentang infrastruktur, lihat Mendesain batas akses.

Selain itu, Anda men-deploy dan mengelola resource sistem tiket bersama-sama dalam sebuah project, yang memberikan isolasi logis dalam organisasi menggunakan kebijakan dan penegakan software. Resource dalam project dimaksudkan untuk menggabungkan komponen yang harus tetap bersama selama siklus prosesnya.

Sistem tiket mengikuti arsitektur tiga tingkat yang mengandalkan load balancer untuk mengarahkan traffic di seluruh server aplikasi yang terhubung ke server database yang menyimpan data persisten.

Arsitektur ini memungkinkan skalabilitas dan pemeliharaan, karena setiap tingkat dapat dikembangkan dan dikelola secara independen. Arsitektur ini juga memberikan pemisahan masalah yang jelas, sehingga menyederhanakan proses debug dan pemecahan masalah. Menggabungkan tingkat ini dalam project GDC memungkinkan Anda men-deploy dan mengelola komponen secara bersamaan, misalnya, server aplikasi dan database Anda.

Jaringan

Menjalankan sistem tiket di lingkungan produksi memerlukan deployment dua atau beberapa server aplikasi untuk mencapai ketersediaan tinggi jika terjadi kegagalan node. Jika digabungkan dengan load balancer, topologi ini juga memungkinkan pendistribusian beban ke beberapa mesin untuk menskalakan aplikasi secara horizontal. Platform native Kubernetes GDC menggunakan Cloud Service Mesh untuk merutekan traffic dengan aman ke server aplikasi yang membentuk sistem tiket.

Cloud Service Mesh adalah implementasi Google berdasarkan project open source yang mengelola, mengamati, dan mengamankan layanan. Fitur Cloud Service Mesh berikut dimanfaatkan untuk menghosting sistem tiket di GDC:

• Load balancing: Cloud Service Mesh memisahkan alur traffic dari penskalaan infrastruktur, sehingga membuka banyak fitur pengelolaan traffic, termasuk pemilihan rute permintaan dinamis. Sistem tiket memerlukan koneksi klien persisten, jadi kami mengaktifkan sesi persisten menggunakan DestinationRules untuk mengonfigurasi perilaku perutean traffic.

• TLS termination: Cloud Service Mesh mengekspos gateway ingress menggunakan sertifikat TLS dan menyediakan autentikasi transpor dalam cluster melalui mTLS (Mutual Transport Layer Security) tanpa harus mengubah kode aplikasi apa pun.

• Pemulihan kegagalan: Cloud Service Mesh menyediakan sejumlah fitur pemulihan kegagalan yang penting, termasuk waktu tunggu, pemutus arus listrik, health check aktif, dan upaya coba lagi yang dibatasi.

Dalam cluster Kubernetes, kami menggunakan objek Service standar sebagai cara abstrak untuk mengekspos server aplikasi dan database ke jaringan. Service menyediakan cara yang mudah untuk menargetkan instance menggunakan pemilih dan menyediakan resolusi nama dalam cluster menggunakan server DNS yang mendukung cluster.

apiVersion: v1
kind: Service
metadata:
  name: http-ingress
spec:
  selector:
    app.kubernetes.io/component: application-server
  ports:
  - name: http
    port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: database-ingress
spec:
  selector:
    app.kubernetes.io/component: database-server
  ports:
  - name: mysql
    port: 3306

Compute

Sistem tiket merekomendasikan penggunaan bare metal atau virtual machine untuk menghosting penginstalan lokal, dan kami menggunakan pengelolaan virtual machine (VM) GDC untuk men-deploy server aplikasi dan database sebagai workload VM. Dengan menentukan resource Kubernetes, kita dapat menentukan VirtualMachine dan VirtualMachineDisk untuk menyesuaikan resource agar memenuhi kebutuhan kita untuk berbagai jenis server. VirtualMachineExternalAccess memungkinkan kita mengonfigurasi transfer data masuk dan transfer data keluar untuk VM.

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: vm1-boot-disk
spec:
  size: 100G
  source:
    image:
      name: ts-ticketing-system-app-server-2023-08-18-203258
      namespace: vm-system
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  labels:
    app.kubernetes.io/component: application-server
  name: vm1
  namespace: support
spec:
  compute:
    vcpus: 8
    memory: 12G
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: vm1-boot-disk

---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
  name: vm1
  namespace: support
spec:
  enabled: true
  ports:
   - name: ssh
     protocol: TCP
     port: 22

Untuk OS image tamu, kami membuat image kustom untuk memenuhi persyaratan kepatuhan dan keamanan kami. Koneksi ke instance VM yang sedang berjalan dapat dilakukan melalui SSH menggunakan VirtualMachineAccessRequest, yang memungkinkan kita membatasi kemampuan untuk terhubung ke VM melalui RBAC Kubernetes dan menghindari kebutuhan untuk membuat akun pengguna lokal di image kustom. Permintaan akses juga menentukan time to live (TTL) yang memungkinkan permintaan akses berbasis waktu untuk mengelola VM yang berakhir secara otomatis.

Otomatisasi

Sebagai hasil utama untuk project ini, kami merancang pendekatan untuk menginstal instance sistem tiket dengan cara yang dapat diulang, yang dapat mendukung otomatisasi ekstensif dan mengurangi penyimpangan konfigurasi antar-deployment.

Pipeline Rilis

Penyesuaian image server aplikasi dan database dimulai dari image sistem operasi dasar, dengan memodifikasi image dasar sesuai kebutuhan untuk menginstal dependensi yang diperlukan untuk setiap image server. Kami memilih OS image dasar karena penggunaannya yang luas untuk menghosting sistem tiket dalam penginstalan lokal. Image OS dasar ini juga menyediakan kemampuan penguatan keamanan yang diperlukan untuk memenuhi Panduan Penerapan Teknis Keamanan (STIG) yang diperlukan untuk memberikan image yang mematuhi kontrol NIST-800-53.

Pipeline continuous integration (CI) kami menggunakan alur kerja berikut untuk menyesuaikan image server aplikasi dan database:

Saat developer membuat perubahan pada skrip penyesuaian atau dependensi image, kami memicu alur kerja otomatis di alat CI kami untuk membuat kumpulan image baru yang dipaketkan dengan rilis GDC. Sebagai bagian dari pembuatan image, kami juga memperbarui dependensi OS (yum update) dan menyederhanakan image dengan kompresi untuk mengurangi ukuran image yang diperlukan untuk mentransfer image ke lingkungan pelanggan.

Siklus proses pengembangan software

Siklus proses pengembangan software (SDLC) adalah proses yang membantu organisasi merencanakan, membuat, menguji, dan men-deploy software. Dengan mengikuti SDLC yang jelas, organisasi memastikan bahwa software dikembangkan secara konsisten dan dapat diulang, serta mengidentifikasi potensi masalah sejak dini. Selain membangun image dalam pipeline continuous integration (CI), kami juga menentukan lingkungan untuk mengembangkan dan melakukan staging versi pra-rilis sistem tiket untuk pengujian dan uji mutu.

Men-deploy instance terpisah dari sistem tiket per project GDC memungkinkan kami menguji perubahan secara terpisah, tanpa memengaruhi instance yang ada di instance GDC yang sama. Kami menggunakan ResourceManager API untuk membuat dan menghapus Project secara deklaratif menggunakan resource Kubernetes.

apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-dev
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-qa
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-staging

Dengan menggabungkan paket diagram dan mengelola infrastruktur seperti virtual machine sebagai kode, developer dapat dengan cepat melakukan iterasi untuk membuat perubahan dan menguji fitur baru bersama instance produksi. API deklaratif juga memungkinkan framework eksekusi uji otomatis untuk melakukan pengujian regresi reguler dan memverifikasi kapabilitas yang ada.

Operabilitas

Operabilitas adalah kemudahan dalam mengoperasikan dan memelihara sistem. Hal ini merupakan pertimbangan penting dalam desain aplikasi software apa pun. Pemantauan yang efektif berkontribusi pada operabilitas karena memungkinkan masalah diidentifikasi dan diatasi sebelum berdampak signifikan pada sistem. Pemantauan juga dapat digunakan untuk mengidentifikasi peluang peningkatan dan menetapkan dasar pengukuran untuk tujuan tingkat layanan (SLO).

Pemantauan

Kami mengintegrasikan sistem tiket dengan infrastruktur kemampuan observasi GDC yang ada, termasuk logging dan metrik. Untuk metrik, kami mengekspos endpoint HTTP dari setiap VM yang memungkinkan aplikasi meng-scrape titik data yang dihasilkan oleh server aplikasi dan database. Endpoint ini mencakup metrik sistem yang dikumpulkan menggunakan pengekspor node aplikasi dan metrik khusus aplikasi.

Dengan endpoint yang terekspos di setiap VM, kami mengonfigurasi perilaku polling aplikasi menggunakan resource kustom MonitoringTarget untuk menentukan interval scrape dan menganotasi metrik.

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
  name: database-monitor
spec:
  podMetricsEndpoints:
    path:
      value: /metrics
    port:
      annotation: application.io/dbMetrics
    scrapeInterval: 60s

Untuk logging, kami menginstal dan mengonfigurasi pemroses logging dan metrik di setiap VM untuk mengikuti log yang relevan dan mengirim data log ke alat logging, tempat data diindeks dan dikueri melalui instance pemantauan. Log audit diteruskan ke endpoint khusus yang dikonfigurasi dengan retensi yang diperpanjang untuk kepatuhan. Aplikasi berbasis container dapat menggunakan resource kustom LoggingTarget dan AuditLoggingTarget untuk menginstruksikan pipeline logging agar mengumpulkan log dari layanan tertentu dalam project Anda.

Berdasarkan data yang tersedia di pemroses logging dan pemantauan, kami membuat pemberitahuan menggunakan resource kustom MonitoringRule, yang memungkinkan kami mengelola konfigurasi ini sebagai kode dalam paket diagram kami. Dengan menggunakan API deklaratif untuk menentukan pemberitahuan dan dasbor, kita juga dapat menyimpan konfigurasi ini di repositori kode dan mengikuti proses peninjauan kode dan continuous integration yang sama yang kita andalkan untuk perubahan kode lainnya.

Mode Kegagalan

Pengujian awal mengungkap beberapa mode kegagalan terkait resource yang membantu kami memprioritaskan metrik dan pemberitahuan mana yang harus ditambahkan terlebih dahulu. Kami mulai dengan memantau penggunaan memori dan disk yang tinggi, karena kesalahan konfigurasi database awalnya menyebabkan tabel buffer menggunakan semua memori yang tersedia dan logging yang berlebihan mengisi persistent volume disk yang terpasang. Setelah menyesuaikan ukuran buffer penyimpanan dan menerapkan strategi rotasi log, kami kemudian memperkenalkan pemberitahuan yang berjalan jika VM mendekati penggunaan memori atau disk yang tinggi.

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringRule
metadata:
  name: monitoring-rule
spec:
  interval: 60s
  limit: 0
  alertRules:
  - alert: vm1_disk_usage
    expr:
      (node_filesystem_size_bytes{container_name="compute"} -
      node_filesystem_avail_bytes{container_name="compute"}) * 100 /
      node_filesystem_size_bytes{container_name="compute"} > 90
    labels:
      severity: error
      code: TS-R0001
      resource: vm1
    annotations:
      message: "vm1 disk usage above 90% utilization"

Setelah memverifikasi stabilitas sistem, kami mengalihkan fokus ke mode kegagalan aplikasi dalam sistem tiket. Karena proses debug masalah dalam aplikasi sering kali mengharuskan kami menggunakan secure shell (SSH) ke setiap VM server aplikasi untuk memeriksa log sistem tiket, kami mengonfigurasi aplikasi untuk meneruskan log ini ke alat logging untuk membangun stack kemampuan observasi GDC dan mengkueri semua log operasional sistem tiket di instance pemantauan.

Pencatatan terpusat juga memungkinkan kami membuat kueri log dari beberapa VM secara bersamaan, sehingga menggabungkan tampilan kami untuk setiap komponen sistem.

Cadangan

Pencadangan penting untuk pengoperasian sistem software karena memungkinkan sistem dipulihkan jika terjadi kegagalan. GDC menawarkan pencadangan dan pemulihan VM melalui resource Kubernetes. Membuat resource kustom VirtualMachineBackupRequest dengan resource kustom VirtualMachineBackupPlanTemplate memungkinkan kita mencadangkan volume persisten yang terpasang ke setiap VM ke penyimpanan objek, tempat cadangan dapat dipertahankan sesuai dengan kebijakan retensi yang ditetapkan.

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupPlanTemplate
metadata:
  name: vm-backup-plan
spec:
  backupRepository: "backup-repository"
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupRequest
metadata:
  name: "db-vm-backup"
spec:
  virtualMachineBackupPlanTemplate: vm-backup-plan
  virtualMachine: db1
  virtualMachineBackupName: db-vm-backup

Demikian pula, memulihkan status VM dari cadangan melibatkan pembuatan resource kustom VirtualMachineRestoreRequest, untuk memulihkan server aplikasi dan database tanpa mengubah kode atau konfigurasi untuk kedua layanan tersebut.

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
  name: vm-restore-1
spec:
  virtualMachineBackup: db-vm-backup
  restoreName: restore1
  restoredResourceName: db1

Upgrade

Untuk mendukung siklus proses software sistem tiket dan dependensinya, kami mengidentifikasi tiga jenis upgrade software, yang masing-masing ditangani secara individual untuk meminimalkan periode nonaktif dan gangguan layanan:

1. Upgrade OS.
2. Upgrade platform, seperti versi patch dan utama.
3. Update konfigurasi.

Untuk upgrade OS, kami terus membangun dan merilis image VM baru untuk server aplikasi dan database yang didistribusikan dengan setiap rilis GDC. Image ini berisi perbaikan untuk kerentanan keamanan dan update pada sistem operasi yang mendasarinya.

Upgrade platform sistem tiket memerlukan penerapan update pada image VM yang ada, sehingga kita tidak dapat mengandalkan infrastruktur yang tidak dapat diubah untuk melakukan patching dan update versi rilis utama. Untuk upgrade platform, kami menguji dan memverifikasi versi patch atau rilis utama di lingkungan pengembangan dan staging kami sebelum merilis paket upgrade mandiri bersama dengan rilis GDC.

Terakhir, update konfigurasi diterapkan tanpa periode nonaktif melalui API sistem tiket untuk set update dan data pengguna lainnya. Kami mengembangkan dan menguji update konfigurasi di lingkungan pengembangan dan staging sebelum mengemas beberapa set update bersama-sama selama proses rilis GDC.

Integrasi

Penyedia Identitas

Untuk memberikan perjalanan yang lancar kepada pelanggan dan memungkinkan organisasi mengorientasikan pengguna mereka, kami mengintegrasikan sistem tiket dengan beberapa penyedia identitas yang tersedia di GDC. Biasanya, pelanggan perusahaan dan sektor publik memiliki penyedia identitas yang dikelola dengan baik untuk memberikan dan mencabut hak akses kepada karyawan mereka. Karena persyaratan kepatuhan serta kemudahan tata kelola identitas dan akses, pelanggan ini ingin menggunakan penyedia identitas yang ada sebagai sumber kebenaran untuk mengelola akses karyawan mereka ke sistem tiket.

Sistem tiket mendukung penyedia SAML 2.0 dan OIDC melalui modul penyedia multi-identitas, yang telah kami aktifkan sebelumnya di image VM server aplikasi kami. Pelanggan melakukan autentikasi melalui penyedia identitas organisasi mereka, yang secara otomatis membuat pengguna dan menetapkan peran dalam sistem tiket.

Egress ke server penyedia identitas diizinkan melalui resource kustom ProjectNetworkPolicy, yang membatasi apakah layanan eksternal dapat dijangkau dari organisasi di GDC. Kebijakan ini memungkinkan kita mengontrol secara deklaratif endpoint mana yang dapat diakses oleh sistem tiket di jaringan.

Penyerapan pemberitahuan

Selain mengizinkan pengguna login untuk membuat kasus dukungan secara manual, kami juga membuat insiden sistem tiket sebagai respons terhadap pemberitahuan sistem.

Untuk mencapai integrasi ini, kami menyesuaikan webhook Kubernetes open source untuk menerima pemberitahuan dari aplikasi dan mengelola siklus proses insiden menggunakan endpoint API sistem tiket yang diekspos melalui Cloud Service Mesh.

Kunci API disimpan menggunakan penyimpanan secret GDC, yang didukung oleh secret Kubernetes yang dikontrol melalui kontrol akses berbasis peran (RBAC). Konfigurasi lain seperti endpoint API dan kolom penyesuaian insiden dikelola melalui penyimpanan nilai kunci ConfigMap Kubernetes.

Email

Sistem tiket menawarkan integrasi server email untuk memungkinkan pelanggan menerima dukungan berbasis email. Alur kerja otomatis mengonversi email pelanggan yang masuk menjadi kasus dukungan dan mengirim balasan otomatis kepada pelanggan yang berisi link kasus, sehingga tim dukungan kami dapat mengelola kotak masuk dengan lebih baik, melacak dan menyelesaikan permintaan email secara sistematis, serta memberikan layanan pelanggan yang lebih baik.

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-traffic-from-ticketing-system
spec:
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - ticketing-system

Mengekspos email sebagai layanan Kubernetes juga menyediakan penemuan layanan dan resolusi nama domain serta memisahkan backend server email dari klien seperti sistem tiket.

Kepatuhan

Logging Audit

Log audit berkontribusi pada postur kepatuhan dengan menyediakan cara untuk melacak dan memantau penggunaan software serta menyediakan catatan aktivitas sistem. Log audit mencatat upaya akses oleh pengguna yang tidak sah, melacak penggunaan API, dan mengidentifikasi potensi risiko keamanan. Log audit memenuhi persyaratan kepatuhan, seperti yang diberlakukan oleh Health Insurance Portability and Accountability Act (HIPAA), Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS), dan Sarbanes-Oxley Act (SOX).

GDC menyediakan sistem untuk mencatat aktivitas dan akses administratif dalam platform serta menyimpan log ini selama jangka waktu yang dapat dikonfigurasi. Men-deploy resource kustom AuditLoggingTarget akan mengonfigurasi pipeline logging untuk mengumpulkan log audit dari aplikasi kita.

Untuk sistem tiket, kami mengonfigurasi target logging audit untuk peristiwa audit sistem yang dikumpulkan, dan peristiwa khusus aplikasi yang dihasilkan oleh log audit keamanan sistem tiket. Kedua jenis log dikirim ke instance Loki terpusat tempat kita dapat menulis kueri dan melihat dasbor di instance pemantauan.

Kontrol akses

Kontrol akses adalah proses memberikan atau menolak akses ke resource berdasarkan identitas pengguna atau proses yang meminta akses. Hal ini membantu melindungi data dari akses yang tidak sah dan memastikan bahwa hanya pengguna yang diberi otorisasi yang dapat membuat perubahan pada sistem. Di GDC, kami mengandalkan RBAC Kubernetes untuk mendeklarasikan kebijakan dan menerapkan otorisasi ke resource sistem yang terdiri dari aplikasi sistem tiket.

Dengan menentukan ProjectRole di GDC, kita dapat memberikan akses terperinci ke resource Kubernetes menggunakan peran otorisasi yang telah ditetapkan.

apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectRole
metadata:
  name: ticketing-system-admin
  labels:
    resourcemanager.gdc.goog/rbac-selector: system
spec:
  rules:
  - apiGroups:
    - ""
    resources:
    - configmaps
    - events
    - pods/log
    - services
    verbs:
    - get
    - list

Disaster recovery

Replikasi database

Untuk memenuhi persyaratan disaster recovery (DR), kami men-deploy sistem tiket dalam konfigurasi primer-sekunder di beberapa instance GDC. Dalam mode ini, permintaan ke sistem tiket biasanya dirutekan ke situs utama, sedangkan situs sekunder terus mereplikasi log biner database. Jika terjadi peristiwa failover, situs sekunder akan dipromosikan menjadi situs utama baru dan permintaan kemudian dirutekan ke situs utama baru.

Kami membangun kemampuan replikasi database untuk mengonfigurasi server database utama dan replika per instance GDC berdasarkan parameter yang ditetapkan.

Untuk mengaktifkan replikasi bagi instance yang sudah ada dan telah berjalan lebih lama dari periode retensi log biner, kita dapat memulihkan database replika menggunakan cadangan database untuk memulai replikasi dari database utama.

Dalam mode utama, server aplikasi dan database beroperasi sama seperti saat ini, tetapi database utama dikonfigurasi untuk mengaktifkan replikasi. Contoh:

1. Aktifkan log biner.

2. Tetapkan ID server.

3. Membuat akun pengguna replikasi.

4. Membuat cadangan.

Dalam mode replika, server aplikasi akan menonaktifkan layanan web penjualan tiket untuk menghindari koneksi langsung ke database replika. Database replika harus dikonfigurasi untuk memulai replikasi dari database utama, misalnya:

1. Tetapkan ID server.

2. Konfigurasikan kredensial pengguna replikasi dan detail koneksi utama, seperti host dan port.

3. Pulihkan dari posisi log biner resume cadangan.

Replikasi database memerlukan konektivitas jaringan agar replika dapat terhubung ke database utama untuk memulai replikasi. Untuk mengekspos endpoint database utama untuk replikasi, kita menggunakan Cloud Service Mesh untuk membuat mesh layanan Ingress yang mendukung TLS termination di mesh layanan, mirip dengan cara kita menangani transfer data HTTPS untuk aplikasi web sistem tiket.