Memanfaatkan kontainer dan pengorkestrasi

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Merancang Aplikasi .NET Cloud Native untuk Azure, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Kontainer dan orkestrator dirancang untuk menyelesaikan masalah umum pada pendekatan penyebaran monolitik.

Tantangan dalam penyebaran monolitik

Secara tradisional, sebagian besar aplikasi telah disebarkan sebagai satu unit. Aplikasi tersebut disebut sebagai monolit. Pendekatan umum penyebaran aplikasi ini sebagai unit tunggal bahkan jika terdiri dari beberapa modul atau rakitan dikenal sebagai arsitektur monolitik, seperti yang ditunjukkan pada Gambar 3-1.

Gambar 3-1. Arsitektur monolitik.

Meskipun mereka memiliki manfaat kesederhanaan, arsitektur monolitik menghadapi banyak tantangan:

Penyebaran

Selain itu, mereka memerlukan memulai ulang aplikasi, yang dapat berdampak sementara pada ketersediaan jika teknik tanpa henti tidak diterapkan saat menyebarkan.

Skalabilitas

Aplikasi monolitik dihosting sepenuhnya pada satu instans komputer, sering kali membutuhkan perangkat keras dengan kemampuan tinggi. Jika ada bagian monolit yang memerlukan penskalaan, salinan lain dari seluruh aplikasi harus disebarkan ke komputer lain. Dengan monolit, Anda tidak dapat menskalakan komponen aplikasi satu per satu - itu semua atau tidak sama sekali. Komponen penskalaan yang tidak memerlukan penskalaan menghasilkan penggunaan sumber daya yang tidak efisien dan mahal.

Lingkungan

Aplikasi monolitik biasanya disebarkan ke lingkungan hosting dengan sistem operasi, runtime, dan dependensi pustaka yang telah diinstal sebelumnya. Lingkungan ini mungkin tidak cocok dengan tempat aplikasi dikembangkan atau diuji. Inkonsistensi di seluruh lingkungan aplikasi adalah sumber masalah umum untuk penyebaran monolitik.

Penghubung

Aplikasi monolitik cenderung mengalami kopling tinggi di seluruh komponen fungsionalnya. Tanpa batas keras, perubahan sistem sering mengakibatkan efek samping yang tidak diinginkan dan mahal. Fitur/perbaikan baru menjadi rumit, memakan waktu, dan mahal untuk diterapkan. Pembaruan memerlukan pengujian ekstensif. Penggabungan juga menyulitkan memfaktorkan ulang komponen atau mengganti dengan implementasi alternatif. Bahkan ketika dibangun dengan pemisahan tanggung jawab yang ketat, erosi arsitektur mulai terjadi ketika basis kode monolitik memburuk karena adanya "kasus-kasus khusus" yang tak kunjung usai.

Ketergantungan pada platform

Aplikasi monolitik dibangun dengan tumpukan teknologi tunggal. Sambil menawarkan keseragaman, komitmen ini dapat menjadi hambatan bagi inovasi. Fitur dan komponen baru akan dibangun menggunakan tumpukan aplikasi saat ini - bahkan ketika teknologi yang lebih modern mungkin menjadi pilihan yang lebih baik. Risiko jangka panjang adalah arsitektur teknologi Anda menjadi ketinggalan zaman dan usang. Merancang ulang seluruh aplikasi ke platform baru yang lebih modern paling tidak mahal dan berisiko.

Apa manfaat kontainer dan orkestrator?

Kami memperkenalkan kontainer di Bab 1. Kami menyoroti bagaimana Cloud Native Computing Foundation (CNCF) menetapkan peringkat kontainerisasi sebagai langkah pertama dalam Cloud-Native Trail Map mereka - panduan untuk perusahaan yang memulai perjalanan cloud-native mereka. Di bagian ini, kita membahas manfaat kontainer.

Docker adalah platform manajemen kontainer paling populer. Ini berfungsi dengan kontainer di Linux atau Windows. Kontainer menyediakan lingkungan aplikasi terpisah tetapi dapat direproduksi yang berjalan dengan cara yang sama pada sistem apa pun. Aspek ini membuatnya sempurna untuk mengembangkan dan menghosting layanan cloud-native. Kontainer diisolasi satu sama lain. Dua kontainer pada perangkat keras host yang sama dapat memiliki versi perangkat lunak yang berbeda, tanpa menyebabkan konflik.

Kontainer didefinisikan oleh file berbasis teks sederhana yang menjadi artefak proyek dan diperiksa ke kontrol sumber. Meskipun server lengkap dan komputer virtual memerlukan upaya manual untuk diperbarui, kontainer mudah dikontrol versinya. Aplikasi yang dibangun untuk dijalankan dalam kontainer dapat dikembangkan, diuji, dan disebarkan menggunakan alat otomatis sebagai bagian dari alur build.

Kontainer tidak dapat diubah. Setelah menentukan kontainer, Anda dapat membuat ulang dan menjalankannya dengan cara yang sama persis. Imutabilitas ini berkontribusi terhadap desain berbasis komponen. Jika beberapa bagian aplikasi berevolusi berbeda dari yang lain, mengapa menyebarkan ulang seluruh aplikasi ketika Anda hanya dapat menyebarkan bagian yang paling sering berubah? Fitur dan aspek lintas fungsi dari sebuah aplikasi dapat dipecah menjadi unit terpisah. Gambar 3-2 menunjukkan bagaimana aplikasi monolitik dapat memanfaatkan kontainer dan layanan mikro dengan mendelegasikan fitur atau fungsionalitas tertentu. Fungsionalitas yang tersisa dalam aplikasi itu sendiri juga telah dikontainerisasi.

Gambar 3-2. Memecah aplikasi monolitik untuk mengadopsi sepenuhnya layanan mikro.

Setiap layanan cloud-native dibangun dan disebarkan dalam kontainer terpisah. Masing-masing dapat memperbarui sesuai kebutuhan. Layanan individual dapat dihosting pada simpul dengan sumber daya yang sesuai untuk setiap layanan. Lingkungan tempat setiap layanan berjalan bersifat tetap, digunakan bersama di seluruh lingkungan pengembangan, pengujian, dan produksi, dan mudah untuk diberi versi. Koupling antara berbagai area aplikasi terjadi secara eksplisit sebagai panggilan atau pesan antar layanan, bukan dependensi waktu kompilasi dalam monolit. Anda juga dapat memilih teknologi yang paling sesuai dengan kemampuan tertentu tanpa memerlukan perubahan pada aplikasi lainnya.

Layanan kontainer memerlukan manajemen otomatis. Tidak akan layak untuk mengelola sekumpulan besar kontainer yang disebarkan secara independen secara manual. Misalnya, pertimbangkan tugas-tugas berikut:

• Bagaimana instans kontainer akan disediakan di seluruh kluster banyak komputer?
• Setelah disebarkan, bagaimana kontainer akan menemukan dan berkomunikasi satu sama lain?
• Bagaimana kontainer dapat mengubah skala masuk atau keluar sesuai dengan permintaan?
• Bagaimana Anda memantau kesehatan setiap kontainer?
• Bagaimana Anda melindungi kontainer dari kegagalan perangkat keras dan perangkat lunak?
• Bagaimana cara memperbarui kontainer untuk aplikasi yang sedang berjalan tanpa waktu henti?

Sistem orkestrasi kontainer mengatasi dan mengotomatiskan masalah ini serta tantangan lainnya.

Dalam ekosistem cloud-native, Kubernetes telah menjadi orkestrator kontainer de facto. Ini adalah platform sumber terbuka yang dikelola oleh Cloud Native Computing Foundation (CNCF). Kubernetes mengotomatiskan penyebaran, penskalaan, dan permasalahan operasional beban kerja terkontainer di seluruh kluster mesin. Namun, menginstal dan mengelola Kubernetes sangat kompleks.

Pendekatan yang jauh lebih baik adalah memanfaatkan Kubernetes sebagai layanan terkelola dari vendor cloud. Cloud Azure menampilkan platform Kubernetes yang dikelola sepenuhnya yang berjudul Azure Kubernetes Service (AKS). AKS mengabstraksi kompleksitas dan overhead operasional dalam mengelola Kubernetes. Anda menggunakan Kubernetes sebagai layanan cloud; Microsoft bertanggung jawab untuk mengelola dan mendukungnya. AKS juga terintegrasi erat dengan layanan Azure lainnya dan alat pengembangan.

AKS adalah teknologi berbasis kluster. Kumpulan komputer virtual federasi, atau simpul, disebarkan ke cloud Azure. Bersama-sama mereka membentuk lingkungan yang sangat andal, atau kluster. Kluster muncul sebagai satu entitas utuh untuk aplikasi native-cloud Anda. Pada tingkat dasar, AKS mendistribusikan layanan kontainer Anda ke node-node ini sesuai dengan strategi yang telah ditentukan untuk membagikan beban secara merata.

Apa manfaat peningkatan skala?

Layanan yang dibangun pada kontainer dapat memanfaatkan manfaat penskalakan yang disediakan oleh alat orkestrasi seperti Kubernetes. Secara desain, kontainer hanya mengetahui tentang diri mereka sendiri. Setelah Anda memiliki beberapa kontainer yang perlu bekerja sama, Anda harus mengaturnya pada tingkat yang lebih tinggi. Mengatur sejumlah besar kontainer dan dependensi bersama, seperti konfigurasi jaringan, adalah di mana alat orkestrasi berperan penting untuk menjadi penyelamat! Kubernetes membuat lapisan abstraksi atas grup kontainer dan mengaturnya ke dalam pod. Pod berjalan pada mesin pekerja yang disebut sebagai simpul. Struktur terorganisir ini disebut sebagai kluster. Gambar 3-3 menunjukkan berbagai komponen kluster Kubernetes.

Komponen kluster Kubernetes. Gambar 3-3. Komponen kluster Kubernetes.

Penskalaan beban kerja dalam kontainer adalah fitur utama dari orkestrator kontainer. AKS mendukung penskalaan otomatis di dua dimensi: Instans kontainer dan simpul komputasi. Bersama-sama mereka memberi AKS kemampuan untuk merespons lonjakan permintaan dengan cepat dan efisien dan menambahkan sumber daya tambahan. Kami membahas penskalakan di AKS nanti di bab ini.

Deklaratif versus imperatif

Kubernetes mendukung konfigurasi deklaratif dan imperatif. Pendekatan imperatif melibatkan menjalankan berbagai perintah yang memberi tahu Kubernetes apa yang harus dilakukan setiap langkah. Jalankan gambar ini. Hapus pod ini. Mengekspos port ini. Dengan pendekatan deklaratif, Anda membuat file konfigurasi, yang disebut manifes, untuk menjelaskan apa yang Anda inginkan alih-alih apa yang harus dilakukan. Kubernetes membaca manifes dan mengubah status akhir yang Anda inginkan menjadi status akhir aktual.

Perintah imperatif sangat bagus untuk pembelajaran dan eksperimen interaktif. Namun, Anda harus membuat file manifes Kubernetes secara deklaratif untuk merangkul infrastruktur sebagai pendekatan kode, menyediakan penyebaran yang andal dan dapat diulang. File manifes menjadi artefak proyek dan digunakan dalam alur CI/CD Anda untuk mengotomatiskan penyebaran Kubernetes.

Jika Anda telah mengonfigurasi kluster menggunakan perintah imperatif, Anda dapat mengekspor manifes deklaratif dengan menggunakan kubectl get svc SERVICENAME -o yaml > service.yaml. Perintah ini menghasilkan manifes yang mirip dengan yang ditunjukkan di bawah ini:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2019-09-13T13:58:47Z"
  labels:
    component: apiserver
    provider: kubernetes
  name: kubernetes
  namespace: default
  resourceVersion: "153"
  selfLink: /api/v1/namespaces/default/services/kubernetes
  uid: 9b1fac62-d62e-11e9-8968-00155d38010d
spec:
  clusterIP: 10.96.0.1
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 6443
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Saat menggunakan konfigurasi deklaratif, Anda dapat mempratinjau perubahan yang akan dilakukan sebelum menerapkannya dengan menggunakan kubectl diff -f FOLDERNAME terhadap folder tempat file konfigurasi Anda berada. Setelah Anda yakin ingin menerapkan perubahan, jalankan kubectl apply -f FOLDERNAME. Tambahkan -R untuk memproses hierarki folder secara rekursif.

Anda juga dapat menggunakan konfigurasi deklaratif dengan fitur Kubernetes lainnya, salah satunya penyebaran. Penyebaran deklaratif membantu mengelola rilis, pembaruan, dan penskalakan. Mereka menginstruksikan pengontrol penyebaran Kubernetes tentang cara menyebarkan perubahan baru, meluaskan skala beban, atau mengembalikan ke revisi sebelumnya. Jika kluster tidak stabil, penyebaran deklaratif akan secara otomatis mengembalikan kluster kembali ke keadaan yang diinginkan. Misalnya, jika node harus mengalami kerusakan, mekanisme penyebaran akan mengganti node untuk mencapai kondisi yang Anda inginkan.

Menggunakan konfigurasi deklaratif memungkinkan infrastruktur direpresentasikan sebagai kode yang dapat dicek masuk dan diberi versi bersama kode aplikasi. Ini memberikan kontrol perubahan yang ditingkatkan dan dukungan yang lebih baik untuk penyebaran berkelanjutan menggunakan rangkaian proses build dan deploy.

Skenario apa yang ideal untuk kontainer dan orkestrator?

Skenario berikut sangat ideal untuk menggunakan kontainer dan orkestrator.

Aplikasi yang membutuhkan waktu aktif dan skalabilitas tinggi

Aplikasi individual yang memiliki persyaratan waktu aktif dan skalabilitas tinggi adalah kandidat ideal untuk arsitektur cloud-native menggunakan layanan mikro, kontainer, dan orkestrator. Mereka dapat dikembangkan dalam kontainer, diuji di berbagai lingkungan versi, dan disebarkan ke sistem operasi produksi tanpa waktu henti. Penggunaan kluster Kubernetes memastikan aplikasi tersebut juga dapat menskalakan sesuai permintaan dan pulih secara otomatis dari kegagalan node.

Sejumlah besar aplikasi

Organisasi yang menyebarkan dan memelihara sejumlah besar aplikasi mendapat manfaat dari kontainer dan orkestrator. Upaya di muka untuk menyiapkan lingkungan kontainer dan kluster Kubernetes terutama merupakan biaya tetap. Menyebarkan, memelihara, dan memperbarui aplikasi individual memiliki biaya yang bervariasi dengan jumlah aplikasi. Di luar beberapa aplikasi, kompleksitas mempertahankan aplikasi kustom secara manual melebihi biaya penerapan solusi menggunakan kontainer dan orkestrator.

Kapan Anda harus menghindari penggunaan kontainer dan orkestrator?

Jika Anda tidak dapat membuat aplikasi dengan mengikuti prinsip aplikasi Twelve-Factor, Anda harus mempertimbangkan untuk menghindari kontainer dan orkestrator. Dalam kasus ini, pertimbangkan platform hosting berbasis VM, atau mungkin beberapa sistem hibrid. Dengan itu, Anda dapat selalu memisahkan bagian-bagian fungsi tertentu menjadi kontainer terpisah atau bahkan fungsi tanpa server.

Sumber daya pengembangan

Bagian ini menunjukkan daftar singkat sumber daya pengembangan yang dapat membantu Anda mulai menggunakan kontainer dan orkestrator untuk aplikasi Anda berikutnya. Jika Anda mencari panduan tentang cara merancang aplikasi arsitektur layanan mikro cloud-native Anda, baca pendamping buku ini, .NET Microservices: Arsitektur untuk Aplikasi .NET Dalam Kontainer.

Pengembangan Kubernetes Lokal

Penyebaran Kubernetes memberikan nilai besar di lingkungan produksi, tetapi juga dapat berjalan secara lokal pada komputer pengembangan Anda. Meskipun Anda mungkin bekerja pada layanan mikro individual secara independen, mungkin ada kalanya Anda harus menjalankan seluruh sistem secara lokal - sama seperti yang akan berjalan saat disebarkan ke produksi. Ada beberapa alat yang dapat membantu: Minikube dan Docker Desktop. Visual Studio juga menyediakan alat untuk pengembangan Docker.

Minikube

Apa itu Minikube? Proyek Minikube mengatakan "Minikube mengimplementasikan kluster Kubernetes lokal di macOS, Linux, dan Windows." Tujuan utamanya adalah "menjadi alat terbaik untuk pengembangan aplikasi Kubernetes lokal dan untuk mendukung semua fitur Kubernetes yang sesuai." Menginstal Minikube terpisah dari Docker, tetapi Minikube mendukung hypervisor yang berbeda dari yang didukung Docker Desktop. Fitur Kubernetes berikut saat ini didukung oleh Minikube:

• Sistem Nama Domain (DNS)
• NodePorts
• ConfigMaps dan rahasia konfigurasi
• Papan Pemantau
• Runtime kontainer: Docker, rkt, CRI-O, dan kontainer
• Mengaktifkan Antarmuka Jaringan Kontainer (CNI)
• Akses Masuk

Setelah menginstal Minikube, Anda dapat dengan cepat mulai menggunakannya dengan menjalankan minikube start perintah , yang mengunduh gambar dan memulai kluster Kubernetes lokal. Setelah kluster dimulai, Anda berinteraksi dengannya menggunakan perintah Kubernetes kubectl standar.

Docker Desktop

Anda juga dapat bekerja dengan Kubernetes langsung dari Docker Desktop di Windows. Ini adalah satu-satunya opsi Anda jika Anda menggunakan Kontainer Windows, dan juga merupakan pilihan yang bagus untuk kontainer non-Windows. Gambar 3-4 menunjukkan cara mengaktifkan dukungan Kubernetes lokal saat menjalankan Docker Desktop.

Gambar 3-4. Mengonfigurasi Kubernetes di Docker Desktop.

Docker Desktop adalah alat paling populer untuk mengonfigurasi dan menjalankan aplikasi kontainer secara lokal. Saat bekerja dengan Docker Desktop, Anda dapat mengembangkan secara lokal dengan menggunakan kumpulan images kontainer Docker yang persis sama dengan yang akan Anda terapkan ke dalam produksi. Docker Desktop dirancang untuk "membangun, menguji, dan mengirim" aplikasi kontainer secara lokal. Ini mendukung kontainer Linux dan Windows. Setelah Anda mendorong gambar Anda ke registri gambar, seperti Azure Container Registry atau Docker Hub, AKS dapat mengambil dan menyebarkannya ke lingkungan produksi.

Alat Visual Studio Docker

Visual Studio mendukung pengembangan Docker untuk aplikasi berbasis web. Saat membuat aplikasi ASP.NET Core baru, Anda memiliki opsi untuk mengonfigurasinya dengan dukungan Docker, seperti yang ditunjukkan pada Gambar 3-5.

Gambar 3-5. Aktifkan Dukungan Docker di Visual Studio

Ketika opsi ini dipilih, proyek dibuat dengan Dockerfile di root-nya, yang dapat digunakan untuk membangun dan menghosting aplikasi dalam kontainer Docker. Contoh Dockerfile ditampilkan dalam Gambar 3-6.

FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY ["eShopWeb/eShopWeb.csproj", "eShopWeb/"]
RUN dotnet restore "eShopWeb/eShopWeb.csproj"
COPY . .
WORKDIR "/src/eShopWeb"
RUN dotnet build "eShopWeb.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "eShopWeb.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "eShopWeb.dll"]

Gambar 3-6. Dockerfile yang dihasilkan Visual Studio

Setelah dukungan ditambahkan, Anda dapat menjalankan aplikasi Anda dalam kontainer Docker di Visual Studio. Gambar 3-7 menunjukkan berbagai opsi eksekusi yang tersedia dari proyek ASP.NET Core baru yang dibuat dengan dukungan Docker ditambahkan.

Gambar 3-7. Opsi Pengoperasian Docker di Visual Studio

Selain itu, kapan saja Anda dapat menambahkan dukungan Docker ke aplikasi ASP.NET Core yang ada. Dari Penjelajah Solusi Visual Studio, klik kanan pada proyek dan pilih Tambahkan>Dukungan Docker, seperti yang ditunjukkan pada Gambar 3-8.

Gambar 3-8. Menambahkan dukungan Docker ke Visual Studio

Alat Docker untuk Visual Studio Code

Ada banyak ekstensi yang tersedia untuk Visual Studio Code yang mendukung pengembangan Docker.

Microsoft menyediakan ekstensi Docker untuk Visual Studio Code. Ekstensi ini menyederhanakan proses penambahan dukungan kontainer ke aplikasi. Ini membuat perancah file yang diperlukan, membangun gambar Docker, dan memungkinkan Anda untuk men-debug aplikasi Anda di dalam kontainer. Ekstensi ini menampilkan penjelajah visual yang memudahkan untuk mengambil tindakan pada kontainer dan gambar seperti memulai, menghentikan, memeriksa, menghapus, dan banyak lagi. Ekstensi ini juga mendukung Docker Compose yang memungkinkan Anda mengelola beberapa kontainer yang sedang berjalan sebagai satu unit.

SebelumnyaBerikutnya