Men-deploy aplikasi .NET di Google Cloud

Last reviewed 2022-01-19 UTC

Halaman ini memberikan ringkasan tentang cara men-deploy aplikasi .NET di Google Cloud dan memberikan panduan tentang cara memilih pendekatan deployment yang tepat untuk aplikasi Anda.

Pengantar

Framework Microsoft .NET menyediakan serangkaian alat dan library yang lengkap untuk pengembangan aplikasi. Dengan munculnya dukungan Docker di Windows dan kemampuan untuk menjalankan aplikasi .NET di Linux, aplikasi .NET kini juga dapat mendukung berbagai target deployment.

Agar pengembangan dan pengujian menjadi efisien, Anda dapat mengotomatiskan deployment aplikasi dan menjadikannya bagian dari pipeline continuous integration continuous delivery (CI/CD). Namun, untuk memilih alat yang tepat dan membuat pipeline CI/CD, Anda harus mengidentifikasi terlebih dahulu cara menjalankan aplikasi dalam produksi dan pendekatan deployment yang ingin Anda lakukan.

Tidak ada satu cara terbaik untuk men-deploy aplikasi .NET di Google Cloud. Opsi deployment terbaik untuk Anda bergantung pada aplikasi dan persyaratan Anda. Misalnya, jika aplikasi Anda memerlukan .NET Framework lengkap atau harus berjalan di IIS, deployment Anda akan didasarkan pada Windows. Di sisi lain, jika aplikasi Anda dapat berjalan dengan fungsi yang didukung oleh .NET, Anda memiliki opsi untuk men-deploy di Linux.

Halaman ini membahas berbagai cara Anda dapat menjalankan aplikasi .NET dan men-deploy-nya di Google Cloud, termasuk kondisi yang sesuai untuk setiap opsi. Pada akhirnya, opsi deployment Anda diringkas dalam pohon keputusan untuk membantu Anda memutuskan komponen dan pendekatan mana yang terbaik untuk aplikasi .NET Anda. Google Cloud

Model deployment

Ada dua cara dasar untuk melakukan deployment otomatis aplikasi. Paket deployment di-push ke server aplikasi, atau server aplikasi menarik paket aplikasi dari lokasi yang diketahui. Bagian berikut membahas perbedaan antara kedua model ini.

Deployment berbasis push

Dalam deployment berbasis push, artefak deployment—file zip, paket NuGet, atau artefak lainnya—awalnya hanya tersedia untuk server deployment. Server deployment dapat berupa mesin khusus atau peran yang diasumsikan oleh sistem CI.

Untuk melakukan deployment, proses di server deployment terhubung ke server aplikasi, menyalin artefak deployment, dan memulai penginstalannya. Jika ada lebih dari satu server aplikasi, proses ini akan diulang secara paralel atau, lebih umumnya, secara berurutan sehingga artefak di-deploy ke semua server aplikasi.

Diagram berikut menggambarkan alur ini.

Deployment berbasis push

Berbagai alat pengelolaan konfigurasi tersedia yang memungkinkan Anda mengotomatiskan deployment dengan cara ini. Beberapa alat ini mengikuti pendekatan imperatif di mana urutan langkah deployment ditentukan dengan cara seperti skrip. Meskipun pendekatan ini intuitif, pendekatan ini rentan terhadap penyimpangan konfigurasi—yaitu, setelah jangka waktu tertentu, status beberapa mesin mungkin tidak identik dan mungkin tidak sepenuhnya mencerminkan status yang Anda inginkan. Oleh karena itu, banyak alat memungkinkan Anda menentukan status yang diinginkan, dan alat tersebut akan mencari tahu langkah-langkah yang diperlukan untuk mewujudkan status ini.

Di Windows, alat yang umum digunakan untuk model deployment ini meliputi:

Alat open source populer mencakup Ansible, Chef Infra, dan Puppet. Meskipun alat ini terutama menargetkan Linux, alat ini juga dapat men-deploy target Windows.

Keamanan

Agar server deployment dapat mengirimkan deployment ke server aplikasi, saluran kembali harus tersedia. Misalnya, Web Deploy dan Octopus Deploy menggunakan protokol dan port kustom untuk tugas ini, sedangkan Ansible menggunakan SSH.

Terlepas dari protokol yang digunakan alat, komunikasi yang aman sangat penting untuk membantu mencegah penyerang menggunakan saluran belakang untuk men-deploy aplikasi berbahaya. Yang terpenting, komunikasi yang aman mengharuskan server deployment dapat melakukan autentikasi dengan server aplikasi.

SSH dapat menggunakan autentikasi kunci publik. Jika Anda menggunakan konfigurasi IAM yang sesuai, Anda dapat membiarkan Google Cloud menangani secara otomatis pendistribusian kunci publik yang digunakan untuk SSH ke server aplikasi. Namun, jika Anda tidak menggunakan IAM, Google Cloud tidak dapat mengelola kunci untuk Anda, dan Anda harus mengelola tugas ini sendiri.

Salah satu opsinya adalah Active Directory. Jika server deployment dan server aplikasi menjalankan Windows dan merupakan anggota domain Active Directory, autentikasi ditangani menggunakan Kerberos. Namun, menjalankan lingkungan Active Directory yang toleran terhadap kesalahan, memerlukan setidaknya dua instance VM tambahan untuk menjalankan pengontrol domain. Jika konfigurasi Anda menggunakan penskalaan otomatis, semua server juga harus bergabung ke domain secara dinamis, yang memperlambat proses pengaktifan server. Penskalaan otomatis juga dapat menyebabkan objek komputer yang tidak aktif terakumulasi di direktori, sehingga memerlukan logika pembersihan tambahan. Jika Anda menggunakan Active Directory di lingkungan berbasis cloud, Anda harus mempertimbangkan faktor tambahan ini.

Jika tidak ada Active Directory, autentikasi harus ditangani menggunakan NTLM atau melalui cara lain, seperti autentikasi Dasar HTTP. Kedua pendekatan ini memerlukan kredensial agar tetap disinkronkan antara server deployment dan server aplikasi serta disimpan dengan aman. Kedua tugas ini bisa jadi sulit.

Baik Anda menggunakan Linux atau Windows, mengamankan komunikasi antara server aplikasi dan deployment memerlukan mekanisme yang terpisah dari IAM. Namun, penggunaan beberapa mekanisme untuk mengontrol akses ke sistem meningkatkan kompleksitas secara keseluruhan dan dengan demikian meningkatkan risiko kesalahan konfigurasi yang tidak disengaja.

Update sistem operasi

Anda harus dapat men-deploy versi baru paket aplikasi secara efisien di server aplikasi, tetapi Anda juga harus dapat melayani sistem operasi yang mendasarinya di server tersebut. Hal ini berarti menginstal patch keamanan. Untuk fleet server yang lebih besar, Anda harus mengotomatiskan proses ini dengan cara yang meminimalkan risiko dan meminimalkan jumlah server yang tidak tersedia saat diupdate.

Anda juga dapat menggunakan pendekatan push untuk update sistem operasi, dengan server deployment memicu update OS di server aplikasi. Di Linux, biasanya SSH digunakan untuk menjalankan perintah update dari jarak jauh. Di Windows, PowerShell remoting (yang bergantung pada WinRM) adalah pilihan umum. Untuk kedua mekanisme tersebut, Anda harus dapat melakukan autentikasi secara aman dan menyimpan kredensial secara aman.

Penskalaan otomatis

Dalam lingkungan statis tempat jumlah server aplikasi tidak berubah, server deployment mengetahui semua target deployment terlebih dahulu. Dalam lingkungan cloud, penskalaan otomatis jumlah server aplikasi naik dan turun sering kali bermanfaat. Hal ini menimbulkan dua tantangan saat Anda menggunakan deployment berbasis push:

  • Saat server aplikasi baru ditambahkan, daftarkan server tersebut ke server deployment untuk memastikan server baru disertakan dalam deployment mendatang.
  • Server baru harus menerima deployment awalnya.

Peristiwa penskalaan otomatis tidak dimulai oleh server deployment. Sebagai gantinya, proses ini dimulai oleh grup instance terkelola yang mendasarinya, yang berfungsi di tingkat di bawah server deployment.

Instance server aplikasi baru harus mendaftarkan dirinya ke server deployment dan memicu deployment sebelum server aplikasi baru dapat melayani permintaan. Diagram berikut menggambarkan proses ini.

Penskalaan otomatis dengan deployment berbasis push

Agar pendekatan ini berfungsi, tidak cukup jika server deployment dapat menghubungi dan mengautentikasi server aplikasi. Server aplikasi juga perlu menghubungi server deployment dan melakukan otentikasi dengannya.

Terakhir, server yang baru diluncurkan juga harus memiliki patch keamanan OS terbaru. Memulai update selama proses penskalaan otomatis akan menunda proses secara signifikan. Oleh karena itu, image yang digunakan untuk membuat VM server aplikasi harus sudah menginstal update. Anda dapat mengelola hal ini dengan dua cara:

  • Gunakan image publik yang disediakan oleh Google Cloud, yang selalu diupdate oleh Google. Karena image ini hanya berisi OS, Anda harus menangani penyesuaian apa pun (kode aplikasi, utilitas, dan konfigurasi OS) menggunakan skrip startup atau sebagai bagian dari deployment aplikasi.
  • Pertahankan image OS kustom dan selalu perbarui. Cara ini memungkinkan Anda menerapkan penyesuaian pada gambar, tetapi meningkatkan kompleksitas pengelolaan deployment secara keseluruhan.

Melakukan deployment berbasis push sangatlah intuitif, tetapi dapat menghasilkan kompleksitas yang cukup besar jika Anda mempertimbangkan keamanan, update OS, dan penskalaan otomatis. Bagian berikut membahas deployment berbasis pull, yang merupakan cara deployment yang lebih cloud-native.

Deployment berbasis pull

Dalam deployment berbasis pull, deployment dilakukan secara tidak langsung. Setelah sistem CI menghasilkan artefak deployment versi baru, sistem tersebut akan memublikasikan artefak ke repositori. Diagram berikut menggambarkan alur ini.

Deployment berbasis pull

Saat deployment dilakukan—yang mungkin segera setelah memublikasikan artefak atau pada tahap selanjutnya—server deployment akan memicu deployment sebenarnya. Sekali lagi, server deployment mungkin merupakan sistem terpisah atau peran yang diasumsikan oleh sistem CI. Memicu deployment melibatkan koneksi ke server aplikasi untuk menarik dan menginstal artefak deployment dari repositori pusat.

Meskipun perbedaan antara model berbasis push dan model berbasis pull mungkin awalnya tampak kecil, melakukan deployment berbasis pull memiliki beberapa implikasi penting:

  • Pemicuan server aplikasi untuk menarik artefak deployment tidak harus terjadi di tingkat aplikasi atau OS. Sebagai gantinya, server deployment dapat memicu operasi pull dengan meminta Compute Engine memulai ulang atau mengganti VM. Hal ini dapat menghindari tantangan keamanan yang terkait dengan deployment berbasis push.
  • Daripada hanya berisi file aplikasi, artefak deployment dapat berupa image Docker atau image VM, yang dapat menyatukan proses penerapan update aplikasi dan OS.

Keamanan

Server deployment tidak perlu berinteraksi dengan server aplikasi sama sekali untuk jenis deployment tertentu. Misalnya, tidak ada interaksi yang diperlukan jika artefak deployment adalah salah satu dari berikut ini:

  • Image VM.
  • Image Docker yang akan di-deploy ke Google Kubernetes Engine.
  • Paket yang akan di-deploy ke App Engine.

Sebagai gantinya, server deployment hanya perlu berinteraksi dengan APIGoogle Cloud untuk memulai deployment. Hal ini berarti proses deployment dapat mengandalkan mekanisme autentikasi yang disediakan oleh IAM, yang menghilangkan kebutuhan untuk mengelola kunci atau kredensial.

Saat Anda menggunakan artefak deployment seperti paket zip atau NuGet, yang hanya berisi file dan biner aplikasi, Anda dapat memicu deployment dengan cara berikut:

  • Jika server dikonfigurasi untuk menarik dan menginstal artefak deployment terbaru saat sistem operasi dimulai, Anda dapat memicu update dengan meminta Google Cloud memulai ulang VM. Meskipun memulai ulang mungkin tampak membuang-buang waktu, hal ini menghindari kebutuhan server deployment untuk melakukan autentikasi dengan server aplikasi.
  • Seperti pada deployment berbasis push, server deployment dapat memicu update dari jarak jauh menggunakan saluran kembali. Namun, pendekatan ini tunduk pada implikasi keamanan dan tantangan yang sama dalam mengelola kredensial yang berlaku untuk deployment berbasis push.
  • Server deployment dapat menjalankan agen yang mengamati repositori untuk artefak deployment baru. Saat artefak baru terdeteksi, server dapat menerapkannya secara otomatis. Masalah yang mungkin terjadi adalah beberapa server aplikasi dapat menginstal update secara bersamaan dan dengan demikian tidak tersedia. Untuk menghindari hal ini, agen dapat melacak status server di repositori dan menggunakan informasi status server ini untuk memberikan update secara terkontrol.

Dalam setiap kasus ini, pastikan Anda mengontrol akses tulis ke repositori untuk mencegah server menarik dan menginstal paket berbahaya.

Update sistem operasi

Saat image Docker atau VM digunakan sebagai artefak deployment, artefak ini menggabungkan file dan dependensi aplikasi. Dengan begitu, Anda dapat menggunakan mekanisme deployment yang sama untuk mengupdate sistem operasi dan aplikasi. Dalam hal ini, Anda harus memastikan bahwa artefak deployment baru dapat dibuat dan dipublikasikan untuk dua kasus terpisah. Salah satunya adalah saat versi aplikasi baru tersedia. Yang kedua adalah saat update keamanan baru untuk sistem operasi atau dependensi lainnya dirilis.

Dalam kasus lain, jika artefak deployment hanya berisi file aplikasi, memperbarui sistem operasi adalah tugas terpisah. Oleh karena itu, implikasi yang sama yang dibahas dalam konteks deployment berbasis push berlaku.

Penskalaan otomatis

Meminta server aplikasi menarik artefak deployment selaras dengan ide penskalaan otomatis, dan menghindari sebagian besar kompleksitas yang muncul dari penggabungan penskalaan otomatis dengan deployment berbasis push. Setiap kali server aplikasi baru diluncurkan karena peristiwa penskalaan otomatis, server akan menghubungi repositori, lalu menarik dan menginstal paket deployment terbaru.

Jika Anda menggunakan image VM atau Docker, mekanisme untuk menarik image disediakan oleh Google Cloud. Jika Anda menggunakan paket lain seperti arsip zip atau NuGet, Anda harus mengonfigurasi server aplikasi untuk memulai deployment setelah startup. Anda dapat melakukannya dengan menyesuaikan image VM atau menggunakan skrip startup.

Target deployment

Sebelumnya, aplikasi .NET hanya berjalan di Windows, dan Windows tidak mendukung container. Hal ini membuat Anda tidak punya banyak pilihan tentang lingkungan tempat menjalankan aplikasi.

Dengan munculnya .NET, Anda dapat memutuskan untuk menjalankan aplikasi di Windows atau di Linux. Karena kedua sistem operasi mendukung container, Anda kini memiliki beberapa pilihan tentang lingkungan yang akan ditargetkan.

Sistem operasi

Meskipun Mono telah menawarkan cara untuk men-deploy aplikasi .NET di platform selain Windows selama bertahun-tahun, Linux baru menjadi platform yang didukung sepenuhnya untuk stack pengembangan Microsoft setelah rilis .NET.

.NET hanya menyediakan sebagian kecil kemampuan .NET Framework. Oleh karena itu, menargetkan .NET memberlakukan batasan tertentu pada aplikasi. Yang lebih penting bagi aplikasi yang sudah ada, porting dari .NET Framework ke .NET mungkin tidak selalu mudah dan hemat biaya; dalam kasus tertentu, porting mungkin tidak dapat dilakukan sama sekali.

Oleh karena itu, pertanyaan mendasar saat memilih model dan target deployment adalah apakah akan menggunakan Linux (yang memerlukan .NET) atau Windows (yang mendukung .NET atau .NET Framework).

Potensi manfaat menjalankan aplikasi .NET di Linux meliputi hal-hal berikut:

  • Anda dapat menggunakan lingkungan fleksibel App Engine, lingkungan terkelola sepenuhnya.
  • Anda dapat menggunakan GKE, lingkungan terkelola yang mendukung orkestrasi container.
  • Anda dapat menghindari biaya tambahan untuk image Compute Engine premium yang terkait dengan pemberian lisensi Windows.

Anda harus menimbang manfaat ini dengan potensi kerugian berikut dari penggunaan .NET di Linux:

  • Upaya yang diperlukan untuk mem-porting aplikasi .NET Framework yang ada ke .NET mungkin mengimbangi potensi penghematan biaya. Atau seperti yang disebutkan, mungkin tidak mungkin untuk mem-porting aplikasi .NET Framework yang ada ke .NET.
  • Linux tidak mendukung IIS. Kestrel, server web .NET, menunjukkan performa yang sangat baik, tetapi tidak menawarkan set fitur yang sama dengan IIS. Oleh karena itu, Anda mungkin harus menggunakan Kestrel bersama dengan server web seperti Nginx.
  • Tidak ada padanan langsung Layanan Windows di Linux. Meskipun Anda biasanya dapat mengonversi layanan Windows menjadi aplikasi konsol Linux yang dapat berjalan sebagai daemon, konversi ini mungkin tidak selalu mudah.
  • Pemecahan masalah dan proses debug aplikasi .NET di Linux memerlukan alat dan keterampilan yang berbeda dibandingkan saat Anda menggunakan .NET di Windows. Hal ini dapat menjadi tantangan jika tim Anda memiliki sedikit pengalaman dengan Linux.

Container

Container sangat cocok untuk aplikasi yang berjalan dalam satu proses. Contohnya mencakup:

  • Layanan Windows
  • Aplikasi konsol Linux yang bertindak sebagai daemon
  • Layanan WCF yang dihosting sendiri
  • Aplikasi ASP.NET MVC atau Web API yang dihosting Kestrel

Banyak aplikasi .NET menargetkan IIS. Biasanya digunakan untuk mengelola beberapa aplikasi (di direktori virtual dan kumpulan aplikasi terpisah) dan oleh karena itu mungkin tidak cocok dengan pola satu proses.

Saat memindahkan penyiapan berbasis IIS ke container, Anda dapat mengambil pendekatan yang berbeda:

  • Masukkan IIS, dengan semua direktori dan pool virtual, ke dalam satu image Docker berbasis Windows menggunakan image microsoft/iis sebagai dasarnya. Kecuali jika aplikasi terhubung erat, pendekatan ini biasanya tidak disarankan karena tidak memungkinkan aplikasi diupdate dan di-deploy secara terpisah.
  • Gunakan image Docker berbasis Windows terpisah untuk setiap aplikasi, yang masing-masing menjalankan IIS. Hal ini memastikan Anda dapat mengelola aplikasi secara terpisah. Namun, IIS menimbulkan overhead yang tidak dapat diabaikan dan dapat menjadi signifikan jika Anda perlu mengoperasikan sejumlah besar container ini.
  • Migrasikan beberapa atau semua aplikasi dari IIS ke Kestrel. Karena Kestrel dapat di-deploy di container berbasis Windows atau container Docker berbasis Linux, pendekatan ini memungkinkan Anda mengelola container secara terpisah.

IIS memungkinkan beberapa aplikasi web berjalan di satu situs web, yang berbagi satu nama domain. Saat mengemas aplikasi ke dalam container terpisah, Anda dapat memperoleh fungsi yang sama dengan menggunakan load balancing berbasis konten. Dengan cara yang sama, load balancer HTTP Google membuat deployment proxy terbalik kustom di depan server Kestrel menjadi tidak diperlukan.

Sebagian besar aplikasi dapat dikontainerisasi; jarang ada aplikasi yang tidak dapat dikontainerisasi. Namun, beberapa skenario containerisasi menimbulkan tantangan:

  • Untuk aplikasi yang dikelola IIS, deployment aplikasi biasanya sudah otomatis. Namun, langkah-langkah untuk mengonfigurasi IIS (membuat kumpulan aplikasi, binding, dan sebagainya) dilakukan secara manual. Saat beralih ke container, Anda juga harus mengotomatiskan semua langkah awal ini.
  • Aplikasi yang mengandalkan file konfigurasi atau data yang berada di disk mungkin memerlukan perubahan. Misalnya, informasi konfigurasi dapat diperoleh dari variabel lingkungan, dan file serta folder yang relevan dapat dipasang sebagai volume. Hal ini membuat image tetap stateless dan bebas dari konfigurasi khusus lingkungan.

Terakhir, jika Anda menggunakan container Docker berbasis Windows, perhatikan bahwa Google Cloud tidak mendukung Hyper-V dan tidak memungkinkan Anda menjalankan container Hyper-V. Oleh karena itu, Anda hanya dapat men-deploy container Windows Server di Google Cloud. Container Windows Server lebih ringan daripada container Hyper-V dan menawarkan tingkat isolasi yang berbeda.

Batasan deployment

Faktor tertentu dalam cara aplikasi Anda dibuat dapat membatasi pendekatan deployment yang Anda gunakan, seperti yang dibahas di bagian ini.

Arsitektur aplikasi

Faktor utama yang perlu dipertimbangkan saat memilih target dan model deployment adalah arsitektur aplikasi. Di satu sisi spektrum, aplikasi mungkin mengikuti pola arsitektur monolitik, di mana semua logika aplikasi diimplementasikan dalam satu codebase dan berjalan dalam satu proses atau kumpulan aplikasi IIS. Di ujung spektrum lainnya, aplikasi mungkin mengikuti pola microservice. Dalam pendekatan ini, aplikasi terdiri dari sejumlah layanan yang berjalan secara independen dalam proses terpisah, di kumpulan aplikasi IIS terpisah, atau sebagai layanan Windows terpisah.

Terakhir, Anda mungkin memiliki beberapa aplikasi independen yang di-deploy menggunakan strategi deployment yang seragam, di mana setiap aplikasi itu sendiri mungkin bersifat monolitik. Untuk tujuan diskusi ini, pendekatan ini dapat dianggap setara dengan skenario microservice.

Dalam arsitektur microservice, Anda ingin aplikasi berjalan secara efektif dari segi biaya sekaligus menjaga layanan tetap terisolasi dan dapat dikelola secara independen. Anda dapat mengalokasikan VM khusus untuk setiap layanan, yang memastikan bahwa layanan dapat dikelola dan di-deploy secara terpisah. Namun, pendekatan ini dapat menghasilkan sejumlah besar VM yang kurang dimanfaatkan, sehingga menimbulkan biaya yang tidak perlu. Untuk aplikasi seperti ini, model deployment yang memungkinkan pengemasan yang lebih ketat—khususnya, model berbasis container—kemungkinan akan lebih hemat biaya.

Status dan tanpa kewarganegaraan

Saat mendesain aplikasi untuk cloud, cobalah untuk menjaga agar aplikasi tidak memiliki status dan mengelola status secara eksternal menggunakan layanan penyimpanan berbasis Google Cloud . Aplikasi stateless menawarkan sejumlah keuntungan, termasuk:

  • Instance ini dapat di-deploy secara redundan untuk meningkatkan ketersediaan dan kapasitas.
  • Permintaan dapat didistribusikan secara bebas di antara instance.
  • Fitur ini cocok untuk penskalaan otomatis.
  • Jika terjadi kegagalan, lingkungan (baik container maupun VM) dapat dibuat ulang tanpa risiko kehilangan data.

Mendesain aplikasi agar tidak memiliki status tidak selalu mudah, dan banyak aplikasi lama tidak mengikuti praktik ini. Namun, menganalisis apakah Anda dapat membuat aplikasi stateless tetap bermanfaat.

Status sesi

Aplikasi ASP.NET dan ASP.NET MVC biasanya menggunakan sesi untuk melacak status pengguna, sehingga membuat aplikasi stateful. Namun, ada beberapa opsi untuk membatasi dampak sesi:

  • Jika jumlah data sesi kecil, Anda dapat menyimpan status di cookie yang dienkripsi atau ditandatangani.
  • Daripada menggunakan penyedia status sesi InProc default, Anda dapat menggunakan penyedia SQLServer. Namun, hal ini memerlukan instance SQL Server, yang menimbulkan biaya tambahan dan dapat memengaruhi latensi dan ketersediaan aplikasi.
  • Anda dapat memanfaatkan afinitas sesi di Cloud Load Balancing. Fitur ini memastikan bahwa semua permintaan dari satu klien dirutekan ke instance aplikasi yang sama. Namun, penggunaan afinitas sesi dapat berdampak negatif pada keadilan penyeimbangan beban; yaitu, instance aplikasi tertentu dapat menerima lebih banyak permintaan daripada yang lain. Selain itu, jika instance aplikasi dihentikan karena alasan apa pun, semua sesi yang ditangani oleh instance tersebut akan hilang, yang berpotensi memengaruhi pengguna akhir. Oleh karena itu, mengandalkan afinitas sesi bukanlah solusi yang ideal, tetapi sering kali dapat menjadi kompromi yang layak antara keandalan dan biaya.

Cache dalam memori

Aplikasi biasanya menggunakan cache dalam memori untuk menghindari penghitungan atau pencarian database yang berlebihan. Hal ini menjadi masalah jika beberapa instance aplikasi berjalan secara bersamaan, karena cache dapat menjadi tidak koheren.

Untuk menghindari ketidakkonsistenan, gunakan cache terdistribusi, baik secara langsung maupun dengan menggunakan antarmuka IDistributedCache. Server penyimpanan cache seperti Redis atau Memcached biasanya memiliki permintaan resource yang relatif rendah, tetapi menambah kompleksitas pada penyiapan secara keseluruhan.

Penyimpanan

Data dalam bentuk gambar, lampiran, atau file media biasanya disimpan di disk. Penggunaan persistent disk di VM untuk tujuan ini biasanya bukan pilihan, karena mencegah data dibagikan di antara beberapa mesin, dan berisiko kehilangan data jika instance VM dibuat ulang. Sebagai gantinya, Anda dapat menggunakan salah satu pendekatan berikut:

  • Pindahkan data ke server berbagi file. Hal ini meminimalkan dampak pada aplikasi. Namun, mengoperasikan server SMB atau NFS dengan ketersediaan tinggi berarti biaya dan upaya pemeliharaan tambahan.
  • Pindahkan data ke Cloud Storage. Meskipun memerlukan perubahan pada aplikasi, Cloud Storage memiliki ketersediaan yang tinggi, jauh lebih hemat biaya daripada menjalankan server file, dan tidak memerlukan pekerjaan pemeliharaan tambahan.
  • Pindahkan data ke server file Filestore. Pendekatan ini mungkin memerlukan beberapa perubahan pada aplikasi, tetapi setelah disediakan, Anda dapat menskalakan kapasitas instance sesuai kebutuhan tanpa periode nonaktif. Filestore juga mendukung beberapa instance aplikasi serentak yang mengakses sistem file yang sama secara bersamaan.
  • Pindahkan data ke Cloud Volumes Service. Cloud Volumes Service memungkinkan Anda memindahkan aplikasi berbasis file ke Google Cloud, dengan dukungan untuk volume NFS dan SMB. Anda tidak perlu membangun ulang arsitektur aplikasi, dan Anda mendapatkan penyimpanan persisten untuk aplikasi tanpa kerumitan.

Strategi deployment

Saat men-deploy versi baru aplikasi, Anda harus meminimalkan risiko dan dampak pada pengguna akhir. Tiga strategi paling umum untuk mencapai hal ini adalah Buat Ulang, Blue-Green, dan deployment berkelanjutan.

Membuat ulang strategi

Ide dari strategi Buat ulang adalah menghentikan aplikasi yang berjalan di semua server, men-deploy versi baru, dan memulai aplikasi. Strategi ini memiliki kelemahan yang jelas karena menyebabkan gangguan layanan, tetapi menghindari potensi masalah yang dapat muncul saat dua versi aplikasi yang berbeda sementara berada bersama dan mengakses data umum.

Strategi Blue-Green

Ide di balik strategi Biru-Hijau (juga disebut sebagai Merah-Hitam) adalah men-deploy versi aplikasi baru di kumpulan server baru. Setelah deployment selesai, Anda mengalihkan semua traffic dari kumpulan server lama ke kumpulan server baru. Pendekatan ini untuk sementara memerlukan hingga dua kali jumlah server yang Anda butuhkan untuk produksi, tetapi menghindari gangguan layanan.

Prasyarat untuk strategi ini adalah dua versi aplikasi dapat berada secara bersamaan untuk sementara dan tidak saling mengganggu. Untuk aplikasi yang mengakses database, setiap iterasi perubahan pada skema database harus kompatibel mundur setidaknya dengan versi sebelumnya.

Strategi deployment bertahap

Ide deployment berkelanjutan adalah mengupdate satu server demi server. Seperti strategi Biru-Hijau, hal ini berarti bahwa untuk jangka waktu tertentu, dua versi aplikasi yang berbeda akan berjalan bersamaan. Namun, tidak seperti deployment Blue-Green, Anda mengalihkan traffic dari versi lama ke versi baru secara bertahap. Saat lebih banyak server diupdate, lebih banyak pengguna akan diarahkan ke versi baru hingga akhirnya, saat server terakhir telah diupdate, semua pengguna akan menggunakan versi baru. Manfaat utama pendekatan ini adalah potensi masalah dapat dideteksi lebih awal, sebelum memengaruhi semua pengguna, sehingga membantu menurunkan risiko secara keseluruhan.

Karena deployment bertahap mengharuskan dua versi aplikasi berjalan bersamaan, strategi ini sering kali juga memerlukan konfigurasi load balancer yang menghindari pengalihan pengguna antar-versi.

Opsi deployment

Hingga saat ini, halaman ini telah membahas model, target, dan strategi deployment. Bagian berikut membahas opsi spesifik untuk men-deploy aplikasi .NET di Google Cloud.

GKE (Windows atau Linux)

GKE menyediakan lingkungan Kubernetes yang dikelola sepenuhnya. Kemampuan orkestrasi Kubernetes membuat GKE sangat cocok untuk menjalankan aplikasi microservice kompleks yang terdiri dari banyak container. Namun, bahkan untuk aplikasi yang tidak mengikuti pola microservice, GKE memungkinkan Anda menjalankan banyak container di infrastruktur bersama dengan cara yang efisien sumber daya dan mudah dikelola.

GKE mengharuskan semua bagian aplikasi dikemas sebagai container Docker. Container berbasis Linux memerlukan penggunaan .NET dan lingkungan berbasis Linux. Membangun container di Linux bisa menjadi tantangan jika sistem CI Anda berbasis Windows. Namun, Azure Pipelines dan Team Foundation Server serta Cloud Build menyediakan dukungan bawaan untuk membangun aplikasi .NET serta untuk membangun dan memublikasikan image container berbasis Linux.

GKE menawarkan fleksibilitas tertinggi untuk aplikasi yang bersifat stateless. Dengan menggunakan set stateful dan volume persisten, Anda juga dapat menjalankan jenis aplikasi stateful tertentu di GKE.

Cluster GKE mencakup sejumlah instance VM, yang disebut node, tempat container dijadwalkan. Di cluster multi-zona atau regional, GKE dapat menyebarkan node dan workload di beberapa zona untuk memastikan ketersediaan tinggi.

Harga didasarkan pada jumlah node yang berjalan. Oleh karena itu, GKE paling hemat biaya jika node digunakan dengan baik. Anda dapat menjalankan workload yang lebih besar di cluster yang sama atau dengan menskalakan jumlah node secara otomatis sesuai kebutuhan.

Deployment berbasis pull menggunakan perintah kubectl

Men-deploy aplikasi ke GKE memerlukan dua langkah:

  1. Memublikasikan image Docker ke Artifact Registry atau ke registry Docker eksternal menggunakan docker push atau cara lainnya. Langkah ini biasanya ditangani oleh sistem CI.
  2. Memicu deployment menggunakan kubectl. Langkah ini dapat ditangani oleh sistem CI atau secara terpisah. Karena deployment dimulai dari jarak jauh, tidak masalah apakah kubectl dijalankan di Linux atau Windows.

GKE memiliki dukungan bawaan untuk strategi deployment ulang dan deployment bertahap. Meskipun primitif untuk mengontrol deployment cukup fleksibel untuk memungkinkan strategi deployment lainnya, penggunaan strategi yang berbeda memerlukan alat atau skrip tambahan.

Deployment berbasis pull menggunakan Spinnaker

Jika kemampuan bawaan GKE untuk mengatur deployment tidak cukup untuk tujuan Anda, Anda dapat menggabungkan GKE dengan Spinnaker. Spinnaker memiliki dukungan bawaan untuk GKE dan memungkinkan Anda menerapkan strategi deployment yang lebih canggih, termasuk deployment Blue-Green.

Karena Spinnaker bukan layanan terkelola, Anda harus men-deploy dan memeliharanya secara terpisah. Anda dapat men-deploy Spinnaker di instance VM Linux terpisah atau di cluster GKE.

Knative dan Cloud Run

Untuk container .NET stateless Anda, Knative dan versi terkelolanya, Cloud Run, menyediakan lingkungan container serverless. Container serverless menawarkan manfaat seperti penyediaan, penskalaan otomatis, dan load balancing tanpa overhead pengelolaan infrastruktur.

Untuk men-deploy container di cluster Kubernetes, Knative menyediakan permukaan API yang lebih tinggi dan lebih kecil daripada Kubernetes. Dengan demikian, Knative dapat membantu Anda menghindari kompleksitas Kubernetes, sehingga memudahkan deployment container Anda.

Cloud Run mengikuti Knative API, tetapi berjalan di infrastruktur Google, sehingga tidak memerlukan cluster Kubernetes. Cloud Run menyediakan opsi serverless untuk container. Secara default, container di Cloud Run diskalakan otomatis dan ditagih selama durasi permintaan. Waktu deployment dalam detik. Cloud Run juga menyediakan fitur yang berguna, seperti revisi dan pemisahan traffic.

Layanan Knative adalah versi Cloud Run yang lebih fleksibel yang menawarkan kesederhanaan Knative dan Cloud Run dengan fleksibilitas operasional Kubernetes. Misalnya, Cloud Run di GKE Enterprise memungkinkan Anda menambahkan GPU ke instance pokok yang menjalankan container atau menskalakan aplikasi Anda ke banyak container.

Cloud Run terintegrasi dengan layanan lain seperti Pub/Sub, Cloud Scheduler, Cloud Tasks, dan backend seperti Cloud SQL. Layanan ini dapat digunakan untuk frontend web yang diskalakan otomatis atau mikroservice internal yang dipicu oleh peristiwa.

Compute Engine (Windows atau Linux)

Compute Engine memungkinkan Anda membuat dan mengelola instance VM. Layanan ini mendukung berbagai versi Windows Server dan distribusi Linux, serta opsi ukuran dan konfigurasi. Dengan fleksibilitas ini, Anda dapat menggunakan instance VM Compute Engine untuk berbagai workload.

Untuk memastikan aplikasi di-deploy dan dikelola secara terpisah, deploy hanya satu aplikasi atau layanan untuk setiap instance VM. Untuk memastikan ketersediaan tinggi, jalankan minimal dua instance VM per aplikasi, yang masing-masing berada di zona yang berbeda. Oleh karena itu, Anda dapat mengasumsikan bahwa Anda memerlukan dua kali lipat jumlah instance VM dari jumlah aplikasi atau layanan yang ingin Anda deploy, terlepas dari perkiraan beban.

Compute Engine menyediakan cara mudah untuk menerapkan penskalaan otomatis melalui grup instance terkelola. Grup instance terkelola juga menyediakan cara untuk menerapkan deployment bertahap, seperti yang dibahas di halaman ini nanti.

Karena Compute Engine dikenai biaya berdasarkan instance VM, Anda dapat mengasumsikan bahwa menjalankan aplikasi di Compute Engine paling hemat biaya saat aplikasi menerima beban yang cukup besar, yang berarti penggunaan instance VM yang tinggi. Sebaliknya, jika jumlah layanan dan aplikasi banyak, tetapi penggunaan rata-rata rendah, opsi deployment lain seperti GKE sering kali lebih ekonomis, karena memungkinkan beberapa aplikasi menggunakan infrastruktur umum tanpa mengorbankan isolasi workload.

Untuk menjalankan instance VM Windows, Anda harus menggunakan image premium. Image ini berisi salinan Windows berlisensi dan oleh karena itu dikenai biaya tambahan. Akibatnya, VM Windows umumnya kurang hemat biaya dibandingkan VM yang menggunakan distribusi Linux seperti CentOS atau Debian, yang tidak dikenai biaya lisensi.

Anda dapat menggunakan SSH atau RDP untuk menyiapkan instance VM secara manual, baik untuk men-deploy aplikasi secara manual atau untuk menangani konfigurasi awal yang diperlukan untuk menyiapkan mesin untuk deployment pertama. Namun, hal ini dapat menyebabkan komputer memiliki konfigurasi unik, yang berbeda dari instance VM lainnya. Dalam jangka panjang, menyiapkan instance VM secara manual dapat menjadi rumit dan memakan banyak tenaga. Oleh karena itu, sebaiknya otomatiskan prosesnya agar dapat diulang.

Mengotomatiskan deployment aplikasi di Compute Engine mencakup tugas-tugas berikut:

  1. Menyediakan dan menyiapkan instance VM untuk deployment aplikasi pertama.
  2. Melakukan deployment aplikasi.
  3. Melakukan servis OS (menginstal update keamanan).

Dua bagian berikut menjelaskan cara menangani ketiga langkah tersebut secara terpadu menggunakan pendekatan deployment berbasis pull. Meskipun mekanisme dan alatnya berbeda untuk pendekatan yang dijelaskan di bagian ini, ide umumnya mirip dengan cara aplikasi berbasis container di-deploy menggunakan GKE.

Deployment berbasis pull menggunakan grup instance terkelola

Grup instance terkelola paling umum digunakan untuk menerapkan penskalaan otomatis, tetapi juga menyediakan cara untuk menangani deployment bergilir. Setelah template instance dibuat yang merujuk ke versi baru aplikasi, Anda dapat menggunakan fungsi penggantian rolling untuk mengganti instance VM yang menggunakan template lama dengan instance yang menggunakan template baru.

Prasyarat untuk pendekatan ini adalah versi baru aplikasi disediakan sebagai template instance. Anda dapat melakukannya dengan dua cara:

  • Tentukan template instance yang menggunakan salah satu image OS publik. Gunakan skrip startup untuk mengonfigurasi sistem dan menginstal aplikasi dari bucket Cloud Storage, repositori NuGet, registry Docker, atau sumber lain. Diagram berikut menggambarkan pendekatan ini.

    Deployment berbasis pull menggunakan grup instance terkelola dan image publik

  • Buat image VM kustom sebagai bagian dari proses CI/CD, proses yang sering disebut sebagai pembuatan image. Dalam pendekatan ini, Anda menggunakan salah satu image OS publik untuk membuat instance VM baru, menginstal aplikasi terbaru di dalamnya, membuat image VM dari instance, dan membuat image tersedia di project Google Cloud . Seluruh proses dapat sepenuhnya diotomatiskan menggunakan alat seperti Packer. Gambar yang dihasilkan kemudian dapat dirujuk dalam template instance. Diagram berikut mengilustrasikan pendekatan ini.

    Deployment berbasis pull menggunakan grup instance terkelola dan image kustom

Kelemahan membuat image kustom (opsi kedua) adalah bahwa pemanggangan image adalah proses yang relatif lambat, sering kali memerlukan waktu beberapa menit. Oleh karena itu, pendekatan ini tidak hanya menambah kompleksitas pada proses CI/CD, tetapi juga memperlambat proses CI/CD. Di sisi lain, meluncurkan VM baru menggunakan image kustom adalah proses yang mudah dan cepat, yang bermanfaat saat Anda menggunakan penskalaan otomatis.

Menggunakan skrip startup untuk men-deploy aplikasi (opsi pertama) memiliki trade-off yang berlawanan. Hal ini tidak menimbulkan overhead pembuatan image dalam proses CI/CD, tetapi memperlambat proses pembuatan instance VM. Selain itu, jika skrip startup tidak sepenuhnya andal atau jika sistem tempat biner aplikasi didownload tidak memiliki ketersediaan yang tinggi, pendekatan ini dapat menyebabkan ketersediaan yang lebih rendah.

Pendekatan yang paling sesuai untuk aplikasi Anda bergantung pada aplikasi itu sendiri dan kompleksitas konfigurasi. Dalam beberapa skenario, bahkan mungkin lebih baik menggabungkan kedua pendekatan:

  • Image kustom berisi semua konfigurasi dan dependensi, tetapi bukan biner aplikasi yang sebenarnya. Image baru dibuat saat konfigurasi atau dependensi apa pun berubah, tetapi tidak untuk setiap build aplikasi. Hal ini membantu menghindari perlambatan pipeline CI/CD aplikasi.
  • Aplikasi diinstal menggunakan skrip startup. Untuk meminimalkan risiko dan perlambatan, proses ini harus sesederhana mungkin.

Dalam skenario saat Anda ingin men-deploy banyak aplikasi atau layanan berbeda yang memiliki konfigurasi dasar yang sama, pendekatan hybrid ini dapat menghindari keharusan untuk membuat dan memelihara puluhan atau ratusan image yang hampir identik.

Anda dapat menggunakan grup instance terkelola untuk mengatur deployment workload Linux dan Windows. Untuk Linux, penggunaan grup instance terkelola untuk men-deploy container Docker di instance VM dapat dilakukan dan didukung oleh platform. Namun, sebaiknya hanya untuk aplikasi yang sering digunakan. Dalam kasus lain, men-deploy satu container Docker per VM memberikan sedikit keuntungan dibandingkan menggunakan GKE atau lingkungan fleksibel App Engine.

Jika Anda menggunakan container Windows Server, ikuti panduan berikut untuk menjalankan container menggunakan Compute Engine dan grup instance terkelola:

  • Gunakan image yang dibuat khusus dengan Docker yang sudah diinstal sebelumnya atau salah satu image publik berikut:
    • Windows Server 2019 Datacenter Core for Containers
    • Windows Server 2019 Datacenter for Containers
  • Gunakan skrip startup untuk menarik image Docker dan memulainya sebagai container Windows Server selama startup VM. Anda dapat menggunakan pemetaan port yang sesuai untuk mengekspos layanan yang berjalan di dalam container.

Perhatikan bahwa skrip startup tidak dijamin hanya berjalan setelah layanan Docker dimulai. Untuk menangani kasus dengan baik saat skrip berjalan sebelum Docker tersedia, sertakan logika coba lagi yang sesuai ke dalam skrip.

Saat membuat image berbasis Windows di lingkungan non-cloud, Anda mungkin mengandalkan Microsoft Deployment Toolkit (MDT) atau Windows Deployment Services (WDS). Namun, karena pengelolaan image dan pembuatan instance VM berdasarkan image kustom adalah fitur inti Compute Engine, alat tambahan ini tidak diperlukan. Compute Engine tidak hanya mendukung skrip startup, tetapi juga skrip spesialisasi untuk instance VM berbasis Windows. Oleh karena itu, Anda biasanya tidak perlu menggunakan file unattend.xml kustom. Namun, penginstalan Windows tetap harus digeneralisasi menggunakan GCESysprep sebelum Anda membuat image.

Deployment berbasis pull menggunakan Spinnaker

Grup instance terkelola menyediakan cara yang ringan dan andal untuk menerapkan deployment bertahap, tetapi kemampuan grup instance terkelola mungkin tidak memadai untuk aplikasi tertentu. Untuk menerapkan strategi dan pipeline deployment yang lebih canggih, Anda dapat menggunakan Spinnaker.

Pendekatan dasar yang dilakukan Spinnaker untuk mengatur deployment di Compute Engine mirip dengan yang dibahas di bagian sebelumnya, yaitu juga mengandalkan pembuatan image. Oleh karena itu, pertimbangan yang sama berlaku.

Karena Spinnaker bukan layanan terkelola, Anda harus men-deploy dan memeliharanya secara terpisah dari aplikasi. Anda dapat men-deploy Spinnaker di instance VM Linux terpisah atau di cluster GKE.

Deployment jarak jauh berbasis push

Opsi deployment berbasis penarikan yang dibahas di bagian sebelumnya menawarkan berbagai manfaat. Namun, cara ini tidak cocok untuk setiap jenis aplikasi. Khususnya, aplikasi stateful sering kali tidak cocok dengan pendekatan ini dan mungkin lebih cocok dengan pendekatan berbasis push.

Dalam pendekatan berbasis push, ketiga tugas deployment (penyediaan instance VM, melakukan deployment aplikasi, dan melayani OS) harus ditangani satu per satu. Anda dapat menggunakan alat yang sama untuk ketiga tugas tersebut, tetapi tidak jarang Anda menggunakan alat yang berbeda untuk setiap tugas.

Anda dapat menyediakan instance VM server aplikasi dengan cara yang sama seperti infrastruktur lainnya, menggunakan alat otomatisasi seperti Terraform. Anda dapat menggunakan skrip startup atau spesialisasi untuk menginstal alat yang diperlukan untuk mengotomatiskan deployment aplikasi. Misalnya, jika Anda menggunakan Puppet, Chef, atau Octopus Deploy, Anda harus memastikan bahwa software agen untuk alat ini telah diinstal.

Dari perspektif keamanan, untuk mengurangi permukaan serangan, pastikan bahwa komunikasi antara server deployment dan agen apa pun yang berjalan di instance VM server aplikasi menggunakan jaringan internal. Selain itu, pastikan port yang digunakan tidak terekspos ke internet publik.

Di lingkungan yang tidak menggunakan penskalaan otomatis, bergabung dengan server aplikasi berbasis Windows ke domain Active Directory adalah cara yang efektif untuk memusatkan konfigurasi. Dengan menggunakan Active Directory, Anda juga dapat mengontrol tugas pengelolaan seperti layanan OS.

Memilih opsi deployment

Seperti yang disebutkan di awal halaman ini, tidak ada satu cara terbaik untuk men-deploy aplikasi .NET di Google Cloud. Opsi deployment terbaik untuk Anda bergantung pada aplikasi dan persyaratan Anda. Untuk memilih model yang tepat, salah satu pertanyaan pertama adalah apakah akan menggunakan .NET atau .NET Framework dan, bergantung pada hal ini, apakah akan men-deploy di Linux atau Windows. Setelah Anda mengidentifikasi target sistem operasi, gunakan pohon keputusan berikut untuk membantu mengidentifikasi model deployment yang sesuai.

Untuk men-deploy aplikasi .NET di Linux:

Pohon keputusan untuk men-deploy menggunakan .NET dan Linux

Untuk men-deploy aplikasi .NET atau .NET Framework di Windows:

Pohon keputusan untuk men-deploy menggunakan Windows

Langkah berikutnya