Aplikasi "berbasis cloud" (cloud asli) atau hanya "cloud" dibuat khusus untuk digunakan dalam infrastruktur cloud. Biasanya mereka dibangun sebagai satu set layanan microser longgar ditambah dikemas dalam wadah, yang, pada gilirannya, dikelola oleh platform cloud. Aplikasi seperti itu secara default siap untuk kegagalan, yang berarti mereka bekerja dengan andal dan skala bahkan jika terjadi kegagalan serius pada tingkat infrastruktur. Sisi lain dari koin adalah serangkaian pembatasan (kontrak) yang diberlakukan platform cloud pada aplikasi kontainer agar dapat mengelolanya secara otomatis.
Sadar akan kebutuhan dan pentingnya pindah ke aplikasi cloud, banyak organisasi masih tidak tahu harus mulai dari mana. Dalam posting ini, kami akan mempertimbangkan sejumlah prinsip, kepatuhan yang selama pengembangan aplikasi kontainer akan menyadari potensi platform cloud dan mencapai operasi yang andal dan penskalaan aplikasi bahkan jika terjadi kegagalan serius di tingkat infrastruktur TI. Tujuan utama dari prinsip-prinsip yang diuraikan di sini adalah untuk mempelajari cara membuat aplikasi yang dapat dikelola secara otomatis oleh platform cloud seperti Kubernetes.
Prinsip Desain Perangkat Lunak
Dalam dunia pemrograman, prinsip dipahami sebagai aturan yang cukup umum yang harus diperhatikan ketika mengembangkan perangkat lunak. Mereka dapat digunakan saat bekerja dengan bahasa pemrograman apa pun. Setiap prinsip memiliki tujuan masing-masing, templat dan praktik biasanya berfungsi sebagai instrumen untuk pencapaian mereka. Ada juga sejumlah prinsip dasar untuk membuat perangkat lunak berkualitas tinggi, yang diikuti oleh semua yang lain. Berikut adalah beberapa contoh prinsip dasar:
- KISS (Keep it simple, stupid) - jangan menyulitkan;
- KERING (Jangan ulangi diri Anda sendiri) - jangan ulangi;
- YAGNI (Anda tidak akan membutuhkannya) - jangan membuat sesuatu yang tidak ada kebutuhan mendesaknya;
- SoC (Pemisahan keprihatinan) - untuk berbagi tanggung jawab.
Seperti yang Anda lihat, prinsip-prinsip ini tidak menetapkan aturan khusus, tetapi termasuk dalam kategori yang disebut pertimbangan akal sehat berdasarkan pengalaman praktis yang dibagikan oleh banyak pengembang dan yang mereka rujuk secara teratur.
Selain itu, ada
SOLID - seperangkat lima prinsip pertama pemrograman dan desain berorientasi objek, yang dirumuskan oleh Robert Martin. SOLID mencakup prinsip saling melengkapi yang digeneralisasi dan terbuka untuk interpretasi, yang - bila diterapkan dalam kombinasi - membantu menciptakan sistem perangkat lunak yang lebih baik dan mendukung mereka dalam jangka panjang.
Prinsip SOLID berlaku untuk OOP dan dirumuskan dalam hal konsep dan konsep seperti kelas, antarmuka, dan warisan. Dengan analogi, untuk aplikasi cloud, Anda juga dapat merumuskan prinsip-prinsip pengembangan, hanya elemen dasar di sini tidak akan menjadi kelas, tetapi sebuah wadah. Mengikuti prinsip-prinsip ini, Anda dapat membuat aplikasi kemas yang lebih memenuhi tujuan dan sasaran platform cloud seperti Kubernetes.
Wadah Berbasis Cloud: Pendekatan Red Hat
Saat ini, hampir semua aplikasi relatif mudah untuk dimasukkan ke dalam wadah. Tetapi agar aplikasi otomatis terotomatisasi dan diatur dalam platform cloud seperti Kubernetes, diperlukan upaya ekstra.
Ide-ide yang disajikan di bawah ini didasarkan pada metodologi
The Twelve-Factor App dan banyak karya lain tentang berbagai aspek pembuatan aplikasi web, dari kontrol sumber hingga model skala. Prinsip-prinsip yang diuraikan hanya berlaku untuk pengembangan aplikasi kontainer yang dibangun berdasarkan layanan microser dan dirancang untuk platform cloud seperti Kubernetes. Elemen dasar dalam diskusi kami adalah gambar wadah, dan runtime wadah target adalah platform orkestrasi wadah. Tujuan dari prinsip-prinsip yang diusulkan adalah untuk membuat wadah yang, pada sebagian besar platform orkestrasi, Anda dapat mengotomatiskan tugas penjadwalan (penjadwalan - memilih host untuk menjalankan instance wadah), penskalaan dan pemantauan. Prinsip-prinsip tersebut diatur dalam urutan acak.
Prinsip Kekhawatiran Tunggal (SCP)
Prinsip ini dalam banyak hal mirip dengan Prinsip Tanggung Jawab Tunggal (
SRP ), yang merupakan bagian dari paket SOLID dan menyatakan bahwa setiap objek harus memiliki satu tanggung jawab, dan tanggung jawab ini harus sepenuhnya dirangkum dalam kelas. Inti dari SRP adalah bahwa setiap tugas adalah alasan untuk perubahan, dan kelas harus memiliki satu dan hanya satu alasan untuk perubahan.
Dalam SCP, alih-alih kata "tanggung jawab", kami menggunakan kata "keprihatinan" untuk menunjukkan tingkat abstraksi yang lebih tinggi dan tujuan wadah yang lebih luas dibandingkan dengan kelas OOP. Dan jika tujuan SRP hanya memiliki satu alasan untuk perubahan, maka SCP memiliki keinginan untuk memperluas kemungkinan menggunakan kembali dan mengganti wadah. Dengan mengikuti SRP dan membuat wadah yang memecahkan satu tugas tunggal dan membuatnya secara fungsional lengkap, Anda meningkatkan peluang untuk menggunakan kembali gambar wadah ini dalam berbagai konteks aplikasi.
Prinsip SCP menyatakan bahwa setiap wadah harus menyelesaikan satu tugas tunggal dan melakukannya dengan baik. Selain itu, SCP dalam dunia kontainer dicapai lebih mudah daripada SRP dalam dunia OOP, karena kontainer biasanya melakukan satu proses tunggal, dan sebagian besar waktu proses ini menyelesaikan satu tugas tunggal.
Jika layanan wadah mikro harus menyelesaikan beberapa masalah sekaligus, maka itu dapat dibagi menjadi wadah tugas tunggal dan menggabungkannya menjadi satu pod (unit penyebaran platform wadah) menggunakan templat sespan dan wadah init. Selain itu, SCP memudahkan untuk mengganti wadah lama (seperti server web atau broker pesan) dengan yang baru yang memecahkan masalah yang sama, tetapi memiliki fungsionalitas yang ditingkatkan atau skala yang lebih baik.
Prinsip kenyamanan pemantauan (Prinsip Observabilitas Tinggi, HOP)
Saat menggunakan wadah sebagai cara terpadu pengemasan dan peluncuran aplikasi, aplikasi itu sendiri dianggap sebagai "kotak hitam". Namun, jika ini adalah wadah cloud, maka mereka harus menyediakan runtime dengan API khusus untuk memantau kesehatan kontainer dan mengambil tindakan yang sesuai jika perlu. Tanpa ini, tidak akan mungkin untuk menyatukan otomatisasi memperbarui wadah dan mengelola siklus hidup mereka, yang, pada gilirannya, akan memperburuk stabilitas dan kegunaan sistem perangkat lunak.
Dalam praktiknya, aplikasi kontainer setidaknya harus memiliki API untuk berbagai jenis pemeriksaan kesehatan: tes liveness dan tes kesiapan. Jika aplikasi mengklaim lebih, maka harus menyediakan cara lain untuk memantau kondisinya. Misalnya, mencatat peristiwa penting melalui STDERR dan STDOUT untuk mengumpulkan log menggunakan Fluentd, Logstash, dan alat serupa lainnya. Serta integrasi dengan jejak dan koleksi pustaka metrik seperti OpenTracing, Prometheus, dll.
Secara umum, aplikasi masih dapat dianggap sebagai "kotak hitam", tetapi pada saat yang sama harus dilengkapi dengan semua API yang dibutuhkan platform untuk memantau dan mengelolanya dengan cara terbaik.
Prinsip Kesesuaian Siklus Hidup (LCP)
LCP adalah antitesis dari HOP. Jika HOP menyatakan bahwa wadah harus menyediakan platform dengan API untuk dibaca, maka LCP mengharuskan aplikasi untuk dapat menerima informasi dari platform. Selain itu, wadah tidak hanya harus menerima acara, tetapi juga beradaptasi, dengan kata lain, meresponsnya. Oleh karena itu nama prinsip, yang dapat dianggap sebagai persyaratan untuk menyediakan platform dengan API untuk menulis.
Platform memiliki berbagai jenis peristiwa yang membantu mengelola siklus hidup wadah. Tetapi terserah pada aplikasi untuk memutuskan yang mana dari mereka untuk melihat dan bagaimana menanggapi.
Jelas bahwa beberapa peristiwa lebih penting daripada yang lain. Misalnya, jika aplikasi tidak mentolerir penutupan darurat, maka ia harus menerima pesan sinyal: terminate (SIGTERM) dan memulai prosedur terminasi sesegera mungkin untuk menangkap sinyal: kill (SIGKILL) yang datang setelah SIGTERM.
Selain itu, acara seperti PostStart dan PreStop dapat menjadi penting untuk siklus hidup aplikasi. Misalnya, setelah meluncurkan aplikasi, mungkin perlu beberapa waktu untuk "pemanasan" sebelum dapat menanggapi permintaan. Atau aplikasi itu entah bagaimana harus melepaskan sumber daya saat shutdown.
Prinsip imutabilitas gambar wadah (Image Immutability Principle, IIP)
Secara umum diterima bahwa aplikasi kemas harus tetap tidak berubah setelah perakitan, bahkan jika mereka berjalan di lingkungan yang berbeda. Ini menyiratkan kebutuhan untuk mengeksternalisasi penyimpanan data pada saat runtime (dengan kata lain, gunakan alat eksternal untuk ini), serta bergantung pada konfigurasi eksternal yang dikonfigurasi untuk lingkungan runtime tertentu, alih-alih memodifikasi atau membuat wadah unik untuk setiap lingkungan. Setelah ada perubahan pada aplikasi, gambar kontainer harus dipasang kembali dan digunakan di semua lingkungan yang digunakan. Omong-omong, ketika mengelola sistem TI, prinsip yang sama digunakan, yang dikenal sebagai prinsip kekekalan server dan infrastruktur.
Tujuan IIP adalah untuk mencegah pembuatan gambar wadah terpisah untuk lingkungan runtime yang berbeda dan menggunakan gambar yang sama di mana-mana bersama dengan konfigurasi yang sesuai untuk lingkungan tertentu. Dengan mengikuti prinsip ini, Anda dapat menerapkan praktik penting semacam itu dari sudut pandang otomatisasi sistem cloud sebagai roll-back dan roll-forward pembaruan aplikasi.
Prinsip Disposabilitas Proses (PDP)
Salah satu karakteristik terpenting dari sebuah wadah adalah sifatnya yang sementara: wadah contoh mudah dibuat dan mudah dihancurkan, sehingga dapat dengan mudah diganti dengan wadah lain kapan saja. Mungkin ada banyak alasan untuk penggantian seperti itu: kegagalan tes kesehatan, penskalaan aplikasi, transfer ke host lain, kehabisan sumber daya platform, atau situasi lain.
Akibatnya, aplikasi kontainer harus mempertahankan keadaan mereka menggunakan beberapa cara eksternal, atau menggunakan sirkuit terdistribusi internal dengan redundansi untuk ini. Selain itu, aplikasi harus diluncurkan dengan cepat dan ditutup dengan cepat, dan bersiaplah untuk kegagalan perangkat keras yang mendadak fatal.
Salah satu praktik yang membantu menerapkan prinsip ini adalah membuat wadah kecil. Lingkungan cloud dapat secara otomatis memilih host untuk meluncurkan instance kontainer, jadi semakin kecil container, semakin cepat akan dimulai - itu hanya akan disalin ke host target melalui jaringan lebih cepat.
Prinsip Self-Containment (S-CP)
Menurut prinsip ini, pada tahap perakitan semua komponen yang diperlukan termasuk dalam wadah. Kontainer harus dibangun dengan harapan bahwa sistem hanya memiliki kernel Linux yang bersih, sehingga semua pustaka tambahan yang diperlukan harus ditempatkan dalam wadah itu sendiri. Hal-hal juga harus ditempatkan di sana, seperti runtime untuk bahasa pemrograman yang sesuai, platform aplikasi (jika perlu), dan dependensi lain yang akan diperlukan selama pengoperasian aplikasi kontainer.
Pengecualian hanya dibuat untuk konfigurasi yang bervariasi dari satu lingkungan ke lingkungan lainnya, dan harus disediakan pada saat dijalankan, misalnya melalui Kubernetes ConfigMap.
Suatu aplikasi dapat mencakup beberapa komponen yang di kemas, misalnya, wadah DBMS yang terpisah sebagai bagian dari aplikasi wadah web. Menurut prinsip S-CP, wadah ini tidak boleh digabungkan menjadi satu, tetapi dibuat agar wadah DBMS berisi semua yang diperlukan agar database berfungsi, dan wadah aplikasi web berisi semua yang diperlukan agar aplikasi web berfungsi, server web yang sama . Akibatnya, saat runtime, wadah aplikasi web akan bergantung pada wadah DBMS dan mengaksesnya sesuai kebutuhan.
Runtime Confinement Principle (RCP)
Prinsip S-CP mendefinisikan bagaimana wadah harus dirakit dan apa yang harus berisi file gambar biner. Tapi sebuah wadah bukan hanya "kotak hitam", yang hanya memiliki satu karakteristik - ukuran file. Saat runtime, wadah memperoleh dimensi lain: jumlah memori yang digunakan, waktu prosesor, dan sumber daya sistem lainnya.
Dan di sini prinsip RCP berguna, yang menurutnya wadah harus memenggal persyaratan untuk sumber daya sistem dan mentransfernya ke platform. Memiliki profil sumber daya dari setiap wadah (berapa banyak CPU, memori, jaringan dan sumber daya sistem disk yang dibutuhkan), platform dapat secara optimal melakukan penjadwalan dan penskalaan, mengelola kapasitas TI dan mendukung level SLA untuk wadah.
Selain memenuhi persyaratan sumber daya wadah, juga penting agar aplikasi tidak melampaui kerangka yang ditentukan oleh wadah. Kalau tidak, jika ada kekurangan sumber daya, platform lebih cenderung untuk memasukkannya ke dalam daftar aplikasi yang perlu diinterupsi atau dimigrasikan.
Berbicara tentang fokus pada cloud, kami terutama memaksudkan cara kami bekerja.
Di atas, kami merumuskan sejumlah prinsip umum yang menetapkan fondasi metodologis untuk membangun aplikasi kontainer berkualitas tinggi untuk lingkungan cloud.
Perhatikan bahwa selain prinsip-prinsip umum ini, Anda juga akan memerlukan metode dan teknik canggih tambahan untuk bekerja dengan wadah. Selain itu, kami memiliki beberapa rekomendasi singkat yang lebih spesifik dan harus diterapkan (atau tidak diterapkan) tergantung pada situasi:
Webinar pada versi baru OpenShift Container Platform - 411 Juni pukul 11.00
Apa yang akan Anda pelajari:
- CoreOS Linux Red Hat Enterprise yang Tidak Berubah
- Mesh layanan openshift
- Kerangka kerja operator
- Kerangka kerja knatif