Memigrasikan VM monolit - Pengoptimalan

Penting: UI Migrate to Containers di Konsol Google Cloud, migctl, dan CRD yang menggunakan cluster pemrosesan untuk memigrasikan workload ke Google Cloud kini tidak digunakan lagi. Dukungan bagi pengguna lama hingga Mei 2024, setelah itu tidak akan tersedia lagi. Jika Anda baru menggunakan Migrate to Containers, gunakan CLI Migrate to Containers untuk melakukan migrasi di mesin lokal. Untuk mengetahui informasi selengkapnya, lihat Bermigrasi ke arsitektur CLI Container.

Setelah workload Anda dimigrasikan dari VM ke container, banyak kemungkinan terbuka. Anda dapat mengoptimalkan container serta menerapkan alat dan proses modernisasi. Memodifikasi kode sumber beban kerja dan deployment kini jauh lebih mudah. Sementara itu, alat operasi, seperti logging dan pemantauan, dapat terintegrasi sepenuhnya dengan beban kerja siap pakai.

Tujuan

Di akhir tutorial ini, Anda akan mempelajari cara:

• Pelajari artefak migrasi.
• Ubah kode sumber dan Dockerfile dari beban kerja yang dimigrasikan.
• Manfaatkan Cloud Operations untuk memantau dan melihat log beban kerja yang dimigrasikan.
• Mengoptimalkan workload lebih lanjut menggunakan praktik terbaik modernisasi.

Sebelum memulai

Tutorial ini adalah tindak lanjut dari tutorial Migrasi dan deployment. Sebelum memulai, ikuti petunjuk cara membuat dan menyesuaikan rencana migrasi untuk VM Anda. Kemudian, deploy artefak dalam container yang dihasilkan.

Pelajari artefak migrasi

Di bagian ini, Anda akan mempelajari beberapa artefak yang dibuat selama proses migrasi dan apa perannya. Kemudian, Anda dapat mengubah file ini untuk menambah dan memperbarui beban kerja di masa mendatang.

1. Lihat konfigurasi Dockerfile.

   cat  ${HOME}/bank-of-anthos/src/ledgermonolith/Dockerfile
   

   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.12.1 as migrate-for-anthos-runtime
   FROM gcr.io/my-project/ledgermonolith-service-non-runnable-base:8-25-2022--22-12-57 as source-content
   
   COPY --from=migrate-for-anthos-runtime / /
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   ADD logs.yaml /code/config/logs/logsArtifact.yaml
   ADD services-config.yaml /.m4a/
   
   ENTRYPOINT [ "/.v2k.go" ]
   

   File ini berisi langkah yang diperlukan guna membuat image container untuk beban kerja ini. Anda dapat menambahkan dan mengupdate library, membuat perubahan pada kode sumber, dan menambahkan file baru. Referensi terbaru untuk konfigurasi ini dapat ditemukan di sini.

2. Lihat file deployment_spec.yaml.

   cat  ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml
   

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     creationTimestamp: null
     labels:
       app: ledgermonolith-service
       migrate-for-anthos-optimization: "true"
       migrate-for-anthos-version: v1.12.1
     name: ledgermonolith-service
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: ledgermonolith-service
         migrate-for-anthos-optimization: "true"
         migrate-for-anthos-version: v1.12.1
     serviceName: ledgermonolith-service
     template:
       metadata:
         creationTimestamp: null
         labels:
           app: ledgermonolith-service
           migrate-for-anthos-optimization: "true"
           migrate-for-anthos-version: v1.12.1
       spec:
         containers:
         - env:
           - name: HC_V2K_SERVICE_MANAGER
             value: "true"
           image: gcr.io/my-project/ledgermonolith-service:8-25-2022--22-12-57
           imagePullPolicy: IfNotPresent
           name: ledgermonolith-service
           resources: {}
           volumeMounts:
           - mountPath: /var/lib/postgresql
             name: ledgermonolith-db
             subPath: var/lib/postgresql
         volumes:
         - name: ledgermonolith-db
           persistentVolumeClaim:
             claimName: ledgermonolith-db
     updateStrategy: {}
   . . .
   . . .
   

   File ini berisi definisi resource Kubernetes untuk beban kerja yang dimigrasikan. Class ini menentukan StatefulSet untuk proses, Layanan untuk port, serta sepasang PersistentVolumeClaim dan PersistentVolume yang menyimpan database yang dimigrasikan.

   Dalam contoh output ini, image Docker yang ditetapkan untuk StatefulSet adalah gcr.io/my-project/ledgermonolith-service:11-24-2021--16-22-59, yang dihasilkan selama proses migrasi dan berisi beban kerja dari VM asli.

Mengubah kode sumber

Selanjutnya, Anda akan mempelajari cara mengubah kode sumber beban kerja dan Dockerfile, memberi tag dan mengirim image container baru, serta men-deploy beban kerja yang diperbarui ini ke cluster Anda.

1. Ubah pengontrol utama buku besar untuk selalu mengembalikan saldo statis ketika saldo dikueri. Jalankan perintah berikut yang akan menggantikan Long balance = info.getBalance(); untuk Long balance = 12345L;.

   sed -i 's/Long balance = info.getBalance();/Long balance = 12345L;/g' \
   ${HOME}/bank-of-anthos/src/ledgermonolith/src/main/java/anthos/samples/bankofanthos/ledgermonolith/LedgerMonolithController.java
   

2. Buka root kode sumber layanan dan bangun artefak Java.

   cd ${HOME}/bank-of-anthos/src/ledgermonolith/
   mvn -f . package
   

   Catatan: Java 17+ diperlukan untuk membangun Bank of Anthos.

3. Tambahkan perintah COPY di Dockerfile untuk menyalin artefak Java yang baru dibuat ke dalam image container.

   echo "COPY ${HOME}/bank-of-anthos/src/ledgermonolith/target/ledgermonolith-1.0.jar /opt/monolith/ledgermonolith.jar" >> ${HOME}/bank-of-anthos/src/ledgermonolith/Dockerfile
   

4. Build dan kirim image container.

   docker build . -t gcr.io/$PROJECT_ID/ledgermonolith-service:static-balance --no-cache
   docker push gcr.io/$PROJECT_ID/ledgermonolith-service:static-balance
   

5. Ubah sumber gambar ke gambar yang baru dikirim,

   sed -i 's/image:.*/gcr.io\/$PROJECT_ID\/ledgermonolith-service:static-balance/g' ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml
   kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml
   

   Anda dapat melihat status Pod menggunakan perintah berikut:

   kubectl get pods
   

   Mungkin perlu waktu beberapa detik hingga Pod ledgermonolith-service aktif dan berjalan.

   NAME                           READY   STATUS    RESTARTS   AGE
   accounts-db-0                  1/1     Running   0          3m53s
   contacts-d5dcdc87c-jbrhf       1/1     Running   0          3m53s
   frontend-5768bd978-xdvpl       1/1     Running   0          3m53s
   ledgermonolith-service-0       1/1     Running   0          1m11s
   loadgenerator-8485dfd-582xv    1/1     Running   0          3m53s
   userservice-8477dfcb46-rzw7z   1/1     Running   0          3m53s
   

6. Setelah semua Pod ditetapkan ke Running, Anda dapat menemukan alamat IP eksternal frontend dari LoadBalancer.

   kubectl get service frontend
   

   NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
   frontend   LoadBalancer   10.79.248.161   ##.##.##.##.    80:31304/TCP   46m
   

7. Buka browser dan kunjungi halaman web di alamat IP eksternal yang ditemukan sebelumnya (pastikan untuk menggunakan HTTP, bukan HTTPS).

   http://EXTERNAL_IP
   

   Anda seharusnya dapat login dengan kredensial default dan melihat transaksi. Anda akan melihat bahwa saldo menunjukkan $123,45, seperti yang diharapkan dari perubahan kode sumber.

   

Memantau container

Di bagian ini, Anda akan mempelajari cara memigrasikan workload ke container akan memfasilitasi kemampuan observasi seperti menjelajahi log serta memantau aplikasi dan layanan Anda.

1. Buka Google Cloud Console, jelajahi produk GKE, lalu klik Workloads.

2. Temukan beban kerja ledgermonolith-service, lalu klik untuk melihat status saat ini dan historisnya. Di halaman ini, Anda dapat melihat penggunaan memori dan CPU, serta peristiwa dan spesifikasi.

   

3. Klik tab Logs untuk melihat log historis beban kerja. Anda juga dapat melihat informasi ini menggunakan Cloud Logging.

   

Pengoptimalan lebih lanjut

Dari sini, ada banyak proses dan aktivitas pengoptimalan yang dapat meningkatkan pengalaman container. Berikut adalah beberapa contoh aktivitas tersebut di luar cakupan tutorial ini.

• Tambahkan kebijakan keamanan dan identitas. Dengan menyiapkan kebijakan, Anda dapat membatasi akses ke berbagai workload dan konfigurasi tidak hanya secara eksternal, tetapi juga secara internal di antara layanan. Kebijakan, seperti kontrol akses berbasis peran, serta akses masuk dan keluar, disertakan.

• Integrasikan dengan pipeline deployment dan continuous integration. Dengan mengintegrasikan workload dalam pipeline continuous integration dan deployment, Anda mempercepat kecepatan pengembangan dan pengujian fitur.

• Pisahkan beban kerja yang dimigrasikan menjadi microservice. Saat ini, workload ledgermonolith-service yang dimigrasikan terdiri dari tiga proses logis dan database. Class ini dapat dibagi menjadi beberapa microservice, sehingga Anda dapat menyiapkan penskalaan dan kebijakan yang lebih mendetail yang menargetkan layanan dan proses tertentu. Hal ini mengurangi hambatan saat melakukan pengembangan dan iterasi.

• Mengonfigurasi mesh layanan. Mengimplementasikan mesh layanan di seluruh workload Anda akan menyediakan fitur seperti pengelolaan traffic, autentikasi bersama, dan kemampuan observasi. Mesh layanan dapat diimplementasikan dalam satu cluster atau di beberapa cluster.

• Aktifkan penskalaan otomatis dan update berkelanjutan. Dengan menyiapkan penskalaan otomatis dan update berkelanjutan, Kubernetes membuat workload menjadi fault-tolerant dan memiliki ketersediaan tinggi. Penskalaan otomatis mencakup menskalakan node dan Pod secara horizontal, serta menskalakan resource yang dialokasikan secara vertikal. Jadwalkan beberapa replika workload dan upgrade satu per satu dengan cara yang tangguh untuk mengonfigurasi fitur ini.

Ringkasan

Anda telah memulai rangkaian tutorial ini dengan aplikasi langsung yang terdiri dari beberapa layanan. Beberapa layanan berada di cluster GKE dan beberapa layanan berada di VM di Compute Engine. Anda telah berhasil memigrasikan layanan dan database monolitik dari VM ke cluster GKE. Proses ini mengurangi biaya komputasi dan meningkatkan kemudahan pengembangan bagi developer. Terakhir, Anda telah mempelajari cara melakukan iterasi dengan cepat atas kode sumber, dan praktik terbaik modernisasi.

Pembersihan

Untuk menghindari tagihan Google Cloud yang tidak perlu, Anda harus menghapus resource yang digunakan untuk tutorial ini setelah selesai. Referensi tersebut adalah:

• Cluster GKE boa-cluster
• Cluster GKE migration-processing
• VM Compute Engine ledgermonolith-service

Anda dapat menghapus resource ini secara manual, atau ikuti langkah-langkah berikut untuk menghapus project, yang juga akan menghapus semua resource.

Perhatian: Menghapus project memiliki efek berikut:

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

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

Di konsol Google Cloud, buka halaman Manage resource.

Buka Manage resource

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

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

Langkah selanjutnya

• Pelajari merencanakan praktik terbaik untuk migrasi.