Bermigrasi ke Google Cloud: Bermigrasi dari deployment manual ke deployment otomatis dalam container

Last reviewed 2023-12-08 UTC

Dokumen ini membantu Anda merencanakan dan merancang jalur migrasi dari deployment manual ke deployment otomatis dalam container di Google Cloud menggunakan alat berbasis cloud dan layanan terkelola Google Cloud.

Dokumen ini adalah bagian dari rangkaian multi-bagian berikut tentang migrasi ke Google Cloud:

Dokumen ini berguna jika Anda berencana memodernisasi proses deployment, jika Anda bermigrasi dari proses deployment manual dan lama ke deployment otomatis dan dalam container, atau jika Anda mengevaluasi peluang untuk bermigrasi dan ingin mempelajari seperti apa tampilannya.

Sebelum memulai migrasi ini, Anda harus mengevaluasi cakupan migrasi dan status proses deployment Anda saat ini, serta menetapkan ekspektasi dan sasaran Anda. Pilih titik awal sesuai dengan cara men-deploy workload Anda saat ini:

  • Anda men-deploy workload secara manual.
  • Anda men-deploy beban kerja dengan alat pengelolaan konfigurasi (CM).

Sulit untuk beralih dari deployment manual langsung ke deployment yang sepenuhnya otomatis dan dalam container. Sebagai gantinya, sebaiknya lakukan langkah-langkah migrasi berikut:

  1. Men-deploy menggunakan alat orkestrasi container.
  2. Deploy secara otomatis.

Pada setiap langkah migrasi, Anda akan mengikuti fase yang ditentukan dalam artikel Migrate to Google Cloud: Get started:

  1. Menilai dan menemukan workload Anda.
  2. Merencanakan dan membangun fondasi.
  3. Men-deploy workload Anda.
  4. Mengoptimalkan lingkungan dan workload Anda.

Diagram berikut menggambarkan fase migrasi di setiap langkah.

Jalur migrasi dengan empat fase.

Jalur migrasi ini ideal, tetapi Anda dapat menghentikan proses migrasi lebih awal jika manfaat beralih ke langkah berikutnya lebih besar daripada biaya untuk kasus khusus. Misalnya, jika tidak berencana untuk men-deploy beban kerja secara otomatis, Anda dapat berhenti setelah men-deploy dengan menggunakan alat orkestrasi container. Anda dapat membuka kembali dokumen ini di masa mendatang, jika sudah siap untuk melanjutkan perjalanan.

Saat Anda berpindah dari satu langkah migrasi ke langkah lainnya, ada fase transisi saat Anda mungkin menggunakan proses deployment yang berbeda secara bersamaan. Bahkan, Anda tidak perlu hanya memilih satu opsi deployment untuk semua beban kerja Anda. Misalnya, Anda mungkin memiliki lingkungan hybrid tempat Anda mengelola infrastruktur yang menerapkan pola IaC, sambil tetap men-deploy beban kerja Anda dengan alat orkestrasi container.

Bermigrasi ke alat orkestrasi container

Salah satu langkah pertama Anda untuk beralih dari deployment manual adalah men-deploy beban kerja dengan alat orkestrasi container. Pada langkah ini, Anda akan merancang dan mengimplementasikan proses deployment untuk menangani workload dalam container menggunakan alat orkestrasi container, seperti Kubernetes.

Jika beban kerja Anda belum di-container, Anda akan menghabiskan upaya yang signifikan untuk mem-build-nya dalam container. Tidak semua beban kerja cocok untuk containerization. Jika Anda men-deploy beban kerja yang belum siap untuk cloud atau siap untuk containerization, mungkin tidak ada gunanya untuk mem-build workload dalam container. Beberapa workload bahkan tidak dapat mendukung containerization karena alasan teknis atau lisensi.

Menilai dan menemukan workload Anda

Untuk menentukan cakupan migrasi, pertama-tama Anda memerlukan inventaris artefak yang saat ini Anda produksi dan deploy beserta dependensinya pada sistem dan artefak lain. Untuk membuat inventaris ini, Anda harus menggunakan keahlian tim yang merancang dan mengimplementasikan proses produksi dan deployment artefak saat ini. Dokumen Migrasi ke Google Cloud: Menilai dan menemukan workload Anda membahas cara menilai lingkungan Anda selama migrasi dan cara membuat inventaris aplikasi.

Untuk setiap artefak, Anda perlu mengevaluasi cakupan pengujian saat ini. Anda harus memiliki cakupan pengujian yang tepat untuk semua artefak sebelum melanjutkan ke langkah berikutnya. Jika harus menguji dan memvalidasi setiap artefak secara manual, Anda tidak akan mendapatkan manfaat dari otomatisasi. Gunakan metodologi yang menyoroti pentingnya pengujian, seperti pengembangan berbasis pengujian.

Saat mengevaluasi prosedur, pertimbangkan jumlah versi artefak yang berbeda yang mungkin Anda miliki dalam produksi. Misalnya, jika versi terbaru sebuah artefak adalah beberapa versi lebih cepat dari instance yang harus Anda dukung, Anda harus mendesain model yang mendukung kedua versi tersebut.

Pertimbangkan juga strategi percabangan yang digunakan untuk mengelola codebase Anda. Strategi pencabangan hanyalah bagian dari model kolaborasi yang perlu Anda evaluasi, dan Anda perlu menilai proses kolaborasi yang lebih luas di dalam dan di luar tim Anda. Misalnya, jika Anda mengadopsi strategi cabang yang fleksibel, tetapi tidak menyesuaikannya dengan proses komunikasi, efisiensi tim tersebut dapat berkurang.

Pada fase penilaian ini, Anda juga menentukan cara membuat artefak yang Anda hasilkan lebih efisien dan sesuai untuk containerization dibandingkan proses deployment saat ini. Salah satu cara untuk meningkatkan efisiensi adalah dengan menilai hal-hal berikut:

  • Bagian umum: Evaluasi kesamaan artefak Anda. Misalnya, jika Anda memiliki library umum dan dependensi runtime lainnya, pertimbangkan untuk menggabungkannya dalam satu lingkungan runtime.
  • Persyaratan lingkungan runtime: Menilai apakah Anda dapat menyederhanakan lingkungan runtime untuk mengurangi variannya. Misalnya, jika Anda menggunakan lingkungan runtime yang berbeda untuk menjalankan semua beban kerja, pertimbangkan untuk memulai dari basis yang sama untuk mengurangi beban pemeliharaan.
  • Komponen yang tidak diperlukan: Nilai apakah artefak Anda berisi bagian yang tidak perlu. Misalnya, Anda mungkin memiliki alat utilitas, seperti alat proses debug dan pemecahan masalah, yang tidak terlalu diperlukan.
  • Konfigurasi dan injeksi rahasia: Menilai cara Anda mengonfigurasi artefak sesuai dengan persyaratan lingkungan runtime Anda. Misalnya, sistem injeksi konfigurasi Anda saat ini mungkin tidak mendukung lingkungan dalam container.
  • Persyaratan keamanan: Menilai apakah model keamanan container Anda memenuhi persyaratan Anda. Misalnya, model keamanan lingkungan dalam container mungkin bertentangan dengan persyaratan beban kerja untuk memiliki hak istimewa pengguna super, akses langsung ke resource sistem, atau tenancy tunggal.
  • Persyaratan logika deployment: Nilai apakah Anda perlu menerapkan proses deployment lanjutan. Misalnya, jika perlu mengimplementasikan proses deployment canary, Anda dapat menentukan apakah alat orkestrasi container mendukungnya atau tidak.

Merencanakan dan membangun fondasi

Selanjutnya, Anda akan menyediakan dan mengonfigurasi infrastruktur dan layanan Google Cloud untuk mendukung proses deployment Anda di Google Cloud. Dokumen Migrasi ke Google Cloud: Merencanakan dan membangun fondasi berisi panduan tentang cara membangun fondasi.

Untuk mencapai fleksibilitas yang diperlukan guna mengelola resource Google Cloud, sebaiknya rancang hierarki resource Google Cloud yang mendukung beberapa lingkungan seperti untuk workload pengembangan, pengujian, dan produksi.

Saat menetapkan identitas pengguna dan layanan, untuk isolasi terbaik, Anda memerlukan setidaknya akun layanan untuk setiap langkah proses deployment. Misalnya, jika proses Anda menjalankan langkah-langkah untuk menghasilkan artefak dan untuk mengelola penyimpanan artefak tersebut di repositori, Anda memerlukan setidaknya dua akun layanan. Jika ingin menyediakan dan mengonfigurasi lingkungan pengembangan dan pengujian untuk proses deployment, Anda mungkin perlu membuat lebih banyak akun layanan. Jika memiliki kumpulan akun layanan berbeda per lingkungan, Anda harus membuat lingkungan tersebut independen dari satu sama lain. Meskipun konfigurasi ini meningkatkan kompleksitas infrastruktur dan membebani tim operasi, konfigurasi ini memberi Anda fleksibilitas untuk menguji dan memvalidasi setiap perubahan secara independen pada proses deployment.

Anda juga perlu menyediakan dan mengonfigurasi layanan dan infrastruktur untuk mendukung workload dalam container Anda:

Dengan menggunakan alat orkestrasi container, Anda tidak perlu khawatir mengenai penyediaan infrastruktur saat men-deploy beban kerja baru. Misalnya, Anda dapat menggunakan Autopilot untuk mengelola konfigurasi cluster GKE secara otomatis.

Men-deploy artefak Anda dengan alat orkestrasi container

Berdasarkan persyaratan yang Anda kumpulkan pada fase penilaian dan fase dasar langkah ini, Anda melakukan hal berikut:

  • Memasukkan beban kerja ke dalam container.
  • Terapkan prosedur deployment untuk menangani beban kerja dalam container Anda.

Memasukkan beban kerja ke dalam container adalah tugas yang sulit. Berikut ini adalah daftar umum aktivitas yang perlu Anda adaptasi dan perluas untuk menyimpan beban kerja dalam container. Tujuan Anda adalah memenuhi kebutuhan Anda sendiri, seperti pengelolaan jaringan dan traffic, penyimpanan persisten, injeksi rahasia dan konfigurasi, serta persyaratan fault tolerance. Dokumen ini mencakup dua aktivitas: membuat kumpulan image container untuk digunakan sebagai dasar, dan membuat kumpulan image container untuk beban kerja Anda.

Pertama, Anda mengotomatiskan produksi artefak, sehingga Anda tidak perlu membuat image baru secara manual untuk setiap deployment baru. Proses pembuatan artefak harus otomatis dipicu setiap kali kode sumber diubah, sehingga Anda memiliki masukan langsung tentang setiap perubahan.

Jalankan langkah-langkah berikut untuk menghasilkan setiap gambar:

  1. Membangun image
  2. Jalankan rangkaian pengujian.
  3. Simpan image dalam registry.

Misalnya, Anda dapat menggunakan Cloud Build untuk mem-build artefak, menjalankan rangkaian pengujian terhadap artefak tersebut, dan, jika pengujian berhasil, simpan hasilnya di Artifact Registry.

Anda juga perlu menetapkan aturan dan konvensi untuk mengidentifikasi artefak Anda. Saat memproduksi gambar, beri label pada setiap gambar agar setiap eksekusi proses dapat diulang. Misalnya, sebuah konvensi yang populer adalah mengidentifikasi rilis menggunakan pembuatan versi semantik dengan cara Anda memberi tag pada image container saat membuat rilis. Saat memproduksi gambar yang masih perlu diperbaiki sebelum dirilis, Anda dapat menggunakan ID yang mengikatnya ke titik di codebase tempat proses Anda menghasilkannya. Misalnya, jika menggunakan repositori Git, Anda dapat menggunakan hash commit sebagai ID untuk image container yang sesuai yang Anda buat saat mengirim commit ke cabang utama repositori Anda.

Selama fase penilaian pada langkah ini, Anda mengumpulkan informasi tentang artefak, bagian-bagian umumnya, dan persyaratan runtime-nya. Berbekal informasi ini, Anda dapat mendesain dan mem-build kumpulan image container dasar dan kumpulan gambar lainnya untuk workload Anda. Gunakan image dasar sebagai titik awal untuk mem-build image untuk workload Anda. Kumpulan gambar dasar harus dikontrol secara ketat dan didukung untuk menghindari berkembangnya lingkungan runtime yang tidak didukung.

Saat membuat image container dari image dasar, jangan lupa untuk memperluas rangkaian pengujian Anda agar mencakup image, tidak hanya beban kerja di dalam setiap image. Anda dapat menggunakan alat seperti InSpec, ServerSpec, dan RSpec untuk menjalankan rangkaian pengujian kepatuhan terhadap lingkungan runtime.

Setelah selesai memindahkan beban kerja ke dalam container dan menerapkan prosedur untuk menghasilkan image container tersebut secara otomatis, Anda harus menerapkan prosedur deployment untuk menggunakan alat orkestrasi container. Pada fase penilaian, Anda menggunakan informasi tentang persyaratan logika deployment yang telah dikumpulkan untuk mendesain prosedur deployment yang lengkap. Dengan alat orkestrasi container, Anda dapat fokus menulis logika deployment menggunakan mekanisme yang disediakan, dan tidak perlu menerapkannya secara manual.

Saat merancang dan mengimplementasikan prosedur deployment, pertimbangkan cara memasukkan file dan secret konfigurasi ke workload Anda, dan cara mengelola data untuk beban kerja stateful. File konfigurasi dan injeksi secret berperan penting untuk menghasilkan artefak yang tidak dapat diubah. Dengan men-deploy artefak yang tidak dapat diubah, Anda dapat melakukan hal berikut:

  • Misalnya, Anda dapat men-deploy artefak di lingkungan pengembangan Anda. Kemudian, setelah menguji dan memvalidasinya, Anda memindahkannya ke lingkungan jaminan kualitas. Terakhir, Anda memindahkannya ke lingkungan produksi.
  • Anda menurunkan kemungkinan terjadi masalah di lingkungan produksi karena artefak yang sama melewati beberapa aktivitas pengujian dan validasi.

Jika beban kerja Anda berstatus stateful, sebaiknya Anda menyediakan dan mengonfigurasi penyimpanan persisten yang diperlukan untuk data Anda. Di Google Cloud, Anda memiliki berbagai opsi:

Jika dapat otomatis menghasilkan artefak untuk di-deploy, Anda dapat menyiapkan lingkungan runtime untuk fitur yang digunakan untuk men-deploy beban kerja Anda. Guna mengontrol lingkungan runtime untuk alat deployment, Anda dapat menyiapkan lingkungan sebagai build di Cloud Build dan menggunakan build tersebut sebagai satu-satunya cara untuk men-deploy artefak di lingkungan Anda. Dengan menggunakan Cloud Build, Anda tidak mengharuskan setiap operator untuk menyiapkan lingkungan runtime di komputernya. Anda dapat segera mengaudit prosedur yang membuat lingkungan runtime beserta kontennya dengan memeriksa kode sumber konfigurasi build.

Mengoptimalkan lingkungan Anda

Setelah menerapkan proses deployment, Anda dapat menggunakan alat orkestrasi container untuk mulai mengoptimalkan proses deployment. Untuk informasi selengkapnya, lihat Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda.

Persyaratan iterasi pengoptimalan ini adalah sebagai berikut:

  • Perluas sistem pemantauan Anda sesuai kebutuhan.
  • Memperluas cakupan pengujian.
  • Tingkatkan keamanan lingkungan Anda.

Anda memperluas sistem pemantauan untuk mencakup produksi artefak baru, prosedur deployment, dan semua lingkungan runtime baru Anda.

Jika Anda ingin memantau, mengotomatiskan, dan mengkodifikasi proses secara efektif, sebaiknya tingkatkan cakupan pengujian. Pada fase penilaian, Anda memastikan bahwa Anda memiliki setidaknya cakupan pengujian menyeluruh. Selama fase pengoptimalan, Anda dapat memperluas rangkaian pengujian untuk mencakup lebih banyak kasus penggunaan.

Terakhir, jika ingin meningkatkan keamanan lingkungan, Anda dapat mengonfigurasi otorisasi biner untuk mengizinkan hanya serangkaian image bertanda tangan yang di-deploy di cluster Anda. Anda juga dapat mengaktifkan Artifact Analysis untuk memindai image container yang disimpan di Artifact Registry untuk mendeteksi kerentanan.

Bermigrasi ke otomatisasi deployment

Setelah bermigrasi ke alat orkestrasi container, Anda dapat beralih ke otomatisasi deployment penuh, dan dapat memperpanjang prosedur produksi serta deployment artefak untuk men-deploy workload Anda secara otomatis.

Menilai dan menemukan workload Anda

Berdasarkan evaluasi sebelumnya, kini Anda dapat berfokus pada persyaratan proses deployment:

  • Langkah-langkah persetujuan manual: Menilai apakah Anda perlu mendukung langkah manual apa pun dalam prosedur deployment.
  • Unit deployment per waktu: Menilai jumlah unit deployment per waktu yang perlu Anda dukung.
  • Faktor-faktor yang menyebabkan deployment baru: Menilai sistem eksternal mana yang berinteraksi dengan prosedur deployment Anda.

Jika Anda perlu mendukung langkah-langkah deployment manual, bukan berarti prosedur Anda tidak dapat diotomatiskan. Dalam hal ini, Anda mengotomatiskan setiap langkah prosedur dan menempatkan gate persetujuan manual jika sesuai.

Mendukung beberapa deployment per hari atau per jam lebih kompleks daripada mendukung beberapa deployment per bulan atau per tahun. Namun, jika Anda tidak sering men-deploy, fleksibilitas dan kemampuan Anda untuk bereaksi terhadap masalah dan mengirimkan fitur baru di workload Anda mungkin akan berkurang. Oleh karena itu, sebelum mendesain dan menerapkan prosedur deployment yang sepenuhnya otomatis, sebaiknya tetapkan ekspektasi dan sasaran Anda.

Evaluasi juga faktor mana yang memicu deployment baru di lingkungan runtime Anda. Misalnya, Anda dapat men-deploy setiap rilis baru di lingkungan pengembangan, tetapi men-deploy rilis tersebut di lingkungan jaminan kualitas hanya jika memenuhi kriteria kualitas tertentu.

Merencanakan dan membangun fondasi

Untuk memperluas fondasi yang dibangun pada langkah sebelumnya, Anda menyediakan dan mengonfigurasi layanan untuk mendukung prosedur deployment otomatis.

Untuk setiap lingkungan runtime, siapkan infrastruktur yang diperlukan untuk mendukung prosedur deployment Anda. Misalnya, jika Anda menyediakan dan mengonfigurasi prosedur deployment di lingkungan pengembangan, jaminan kualitas, praproduksi, dan produksi, Anda bebas menguji perubahan pada prosedur Anda. Namun, jika Anda menggunakan satu infrastruktur untuk men-deploy lingkungan runtime, lingkungan tersebut akan lebih mudah dikelola, tetapi kurang fleksibel saat prosedur perlu diubah.

Saat menyediakan akun dan peran layanan, pertimbangkan untuk mengisolasi lingkungan dan workload Anda dari satu sama lain dengan membuat akun layanan khusus yang tidak berbagi tanggung jawab. Misalnya, jangan gunakan ulang akun layanan yang sama untuk lingkungan runtime yang berbeda.

Men-deploy artefak Anda dengan prosedur yang sepenuhnya otomatis

Pada fase ini, Anda mengonfigurasi prosedur deployment untuk men-deploy artefak Anda tanpa intervensi manual, selain langkah-langkah persetujuan.

Anda dapat menggunakan alat seperti Cloud Deploy untuk menerapkan prosedur deployment otomatis, sesuai dengan persyaratan yang Anda kumpulkan pada fase penilaian pada langkah migrasi ini.

Untuk artefak tertentu, setiap prosedur deployment harus menjalankan tugas-tugas berikut:

  1. Deploy artefak di lingkungan runtime target.
  2. Memasukkan file konfigurasi dan secret dalam artefak yang di-deploy.
  3. Jalankan suite pengujian kepatuhan terhadap artefak yang baru di-deploy.
  4. Promosikan artefak ke lingkungan produksi.

Pastikan prosedur deployment Anda menyediakan antarmuka untuk memicu deployment baru sesuai dengan kebutuhan Anda.

Peninjauan kode adalah langkah penting saat menerapkan prosedur deployment otomatis, karena feedback loop singkat yang merupakan bagian dari prosedur ini. Misalnya, jika Anda men-deploy perubahan ke lingkungan produksi tanpa peninjauan apa pun, Anda akan memengaruhi stabilitas dan keandalan lingkungan produksi. Perubahan yang belum ditinjau, salah format, atau berbahaya dapat menyebabkan layanan berhenti berfungsi.

Mengoptimalkan lingkungan Anda

Setelah mengotomatiskan prosedur deployment, Anda dapat menjalankan iterasi pengoptimalan lainnya. Persyaratan iterasi ini adalah sebagai berikut:

  • Perluas sistem pemantauan Anda sehingga mencakup infrastruktur yang mendukung prosedur deployment otomatis.
  • Mengimplementasikan pola deployment yang lebih canggih.
  • Terapkan prosedur breakbreak.

Sistem pemantauan yang efektif memungkinkan Anda merencanakan pengoptimalan lebih lanjut untuk lingkungan Anda. Saat mengukur perilaku lingkungan, Anda dapat menemukan bottleneck yang menghambat performa atau masalah lainnya, seperti akses dan eksploit yang tidak sah atau tidak disengaja. Misalnya, Anda mengonfigurasi lingkungan agar Anda dapat menerima pemberitahuan ketika pemakaian resource tertentu mencapai batas.

Jika dapat mengorkestrasi container secara efisien, Anda dapat menerapkan pola deployment lanjutan sesuai kebutuhan. Misalnya, Anda dapat menerapkan deployment biru/hijau untuk meningkatkan keandalan lingkungan dan mengurangi dampak dari masalah apa pun bagi pengguna Anda.

Langkah selanjutnya