Ringkasan deployment workload VM

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

Arsitektur

Hierarki resource

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

Selain itu, Anda men-deploy dan mengelola resource sistem tiket bersama-sama dalam project, yang memberikan isolasi logis dalam organisasi menggunakan kebijakan dan penegakan perangkat lunak. 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 kemudahan pemeliharaan, karena setiap tingkat dapat dikembangkan dan dipelihara secara independen. Hal ini juga memberikan pemisahan masalah yang jelas, yang menyederhanakan proses penelusuran dan pemecahan masalah. Dengan mengapsulasi tingkat ini dalam project GDC, Anda dapat men-deploy dan mengelola komponen secara bersamaan, misalnya, server aplikasi dan database Anda.

Jaringan

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

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

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

• Penghentian TLS: Cloud Service Mesh mengekspos gateway masuk menggunakan sertifikat TLS dan menyediakan autentikasi transport 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 penting, termasuk waktu tunggu, pemutus arus listrik, health check aktif, dan upaya coba lagi yang dibatasi.

Dalam cluster Kubernetes, kita menggunakan objek Service standar sebagai cara abstrak untuk mengekspos server aplikasi dan database ke jaringan. Layanan menyediakan cara mudah untuk menargetkan instance menggunakan pemilih dan menyediakan resolusi nama dalam cluster menggunakan server DNS yang kompatibel dengan 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, kami dapat menentukan VirtualMachine dan VirtualMachineDisk untuk menyesuaikan resource agar memenuhi kebutuhan kami 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 image OS tamu, kami membuat image kustom untuk memenuhi persyaratan kami terkait kepatuhan dan keamanan. 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 waktu aktif (TTL) yang memungkinkan permintaan akses berbasis waktu mengelola VM yang otomatis berakhir.

Otomatisasi

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

Merilis Pipeline

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

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

Saat developer melakukan perubahan pada skrip penyesuaian atau dependensi gambar, kami akan memicu alur kerja otomatis di alat CI kami untuk membuat kumpulan gambar baru yang disertakan dalam rilis GDC. Sebagai bagian dari pembuatan image, kami juga memperbarui dependensi OS (yum update) dan mengoptimalkan 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 terdefinisi dengan baik, organisasi memastikan bahwa software dikembangkan secara konsisten dan berulang serta mengidentifikasi potensi masalah sejak awal. Selain membuat image di pipeline continuous integration (CI), kami juga menentukan lingkungan untuk mengembangkan dan melakukan staging versi pra-rilis sistem tiket untuk pengujian dan penjaminan kualitas.

Men-deploy instance sistem tiket terpisah 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

Jika dikombinasikan dengan pengemasan diagram dan pengelolaan infrastruktur seperti mesin virtual sebagai kode, developer dapat melakukan iterasi dengan cepat untuk membuat perubahan dan menguji fitur baru bersama instance produksi. API deklaratif juga memungkinkan framework eksekusi pengujian otomatis melakukan pengujian regresi rutin dan memverifikasi kemampuan yang ada.

Pengoperasian

Kemampuan pengoperasian adalah kemudahan sistem untuk dioperasikan dan dipelihara. 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 untuk tujuan tingkat layanan (SLO).

Pemantauan

Kami mengintegrasikan sistem tiket dengan infrastruktur pengamatan 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 eksportir node aplikasi dan metrik khusus aplikasi.

Dengan endpoint yang diekspos di setiap VM, kami mengonfigurasi perilaku polling aplikasi menggunakan resource kustom MonitoringTarget untuk menentukan interval pengambilan 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 log dan metrik di setiap VM untuk memantau 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 di 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 pengemasan diagram. Dengan menggunakan API deklaratif untuk menentukan pemberitahuan dan dasbor, kita juga dapat menyimpan konfigurasi ini di repositori kode dan mengikuti proses integrasi berkelanjutan dan peninjauan kode yang sama yang kita andalkan untuk perubahan kode lainnya.

Mode Kegagalan

Pengujian awal menemukan beberapa mode kegagalan terkait resource yang membantu kami memprioritaskan metrik dan pemberitahuan yang akan ditambahkan terlebih dahulu. Kami memulai dengan memantau penggunaan memori dan disk yang tinggi, karena kesalahan konfigurasi database awalnya menyebabkan tabel buffer menggunakan semua memori yang tersedia dan logging berlebihan mengisi disk volume persisten yang terpasang. Setelah menyesuaikan ukuran buffer penyimpanan dan menerapkan strategi rotasi log, kami 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: <a href="/distributed-cloud/hosted/docs/latest/gdch/gdch-io/service-manual/ts/runbooks/ts-r0001">TS-R0001</a>
      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 masalah pen-debug-an 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 pencatatan log untuk membangun stack observabilitas 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 menyatukan tampilan 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 mengikuti 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.

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 terpisah untuk meminimalkan waktu nonaktif dan gangguan layanan:

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

Untuk upgrade OS, kami terus membuat 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 ticketing 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 waktu henti melalui API sistem tiket untuk set update dan data pengguna lainnya. Kami mengembangkan dan menguji update konfigurasi di lingkungan pengembangan dan staging sebelum menggabungkan beberapa set update selama proses rilis GDC.

Integrasi

Penyedia Identitas

Untuk memberikan perjalanan yang lancar kepada pelanggan dan memungkinkan organisasi mengaktifkan 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 karyawan mereka. Karena persyaratan kepatuhan dan kemudahan tata kelola identitas dan akses, pelanggan ini ingin menggunakan penyedia identitas yang ada sebagai sumber tepercaya untuk mengelola akses karyawan mereka ke sistem tiket.

Sistem tiket mendukung penyedia SAML 2.0 dan OIDC melalui modul multi-penyedia identitasnya, 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 kami mengontrol secara deklaratif endpoint mana yang dapat diakses sistem tiket di jaringan.

Penyerapan pemberitahuan

Selain memungkinkan pengguna login untuk membuat kasus dukungan secara manual, kami juga membuat insiden sistem ticketing 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 rahasia GDC, yang didukung oleh secret Kubernetes yang dikontrol melalui role-based access control (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 mengirimkan balasan otomatis kepada pelanggan dengan link kasus, sehingga tim dukungan kami dapat mengelola kotak masuk mereka 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 lebih 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), Payment Card Industry Data Security Standard (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 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 pemberian atau penolakan 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 preset.

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

Pemulihan dari bencana

Replikasi database

Untuk memenuhi persyaratan pemulihan dari bencana (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 primer, sementara situs sekunder terus mereplikasi log biner database. Jika terjadi peristiwa failover, situs sekunder dipromosikan menjadi situs utama baru dan permintaan kemudian dirutekan ke situs utama baru.

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

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

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

1. Aktifkan log biner.

2. Tetapkan ID server.

3. Buat akun pengguna replikasi.

4. Membuat cadangan.

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

1. Tetapkan ID server.

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

3. Memulihkan dari posisi log biner lanjutan cadangan.

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