Aplikasi “Cloud native” atau sekadar “cloud” dibuat khusus untuk bekerja di infrastruktur cloud. Mereka biasanya dibuat sebagai sekumpulan layanan mikro yang digabungkan secara longgar yang dikemas dalam container, yang kemudian dikelola oleh platform cloud. Aplikasi semacam itu dipersiapkan untuk menghadapi kegagalan secara default, yang berarti aplikasi tersebut bekerja dengan andal dan dapat diskalakan bahkan jika terjadi kegagalan tingkat infrastruktur yang serius. Sisi lain dari koin ini adalah serangkaian batasan (kontrak) yang diberlakukan oleh platform cloud pada aplikasi container agar dapat mengelolanya secara otomatis.
Meskipun menyadari sepenuhnya kebutuhan dan pentingnya beralih ke aplikasi berbasis cloud, banyak organisasi masih belum tahu harus mulai dari mana. Dalam postingan ini, kita akan melihat sejumlah prinsip yang, jika diikuti saat mengembangkan aplikasi dalam container, akan memungkinkan Anda mewujudkan potensi platform cloud dan mencapai pengoperasian dan penskalaan aplikasi yang andal bahkan jika terjadi kegagalan serius pada infrastruktur TI. tingkat. Tujuan akhir dari prinsip-prinsip yang diuraikan di sini adalah untuk mempelajari cara membangun aplikasi yang dapat dikelola secara otomatis oleh platform cloud seperti Kubernetes.
Prinsip Desain Perangkat Lunak
Dalam dunia pemrograman, prinsip mengacu pada aturan umum yang harus diikuti ketika mengembangkan perangkat lunak. Mereka dapat digunakan saat bekerja dengan bahasa pemrograman apa pun. Setiap prinsip mempunyai tujuannya masing-masing, alat untuk mencapainya biasanya berupa pola dan praktik. Ada juga sejumlah prinsip dasar untuk membuat perangkat lunak berkualitas tinggi, yang menjadi dasar prinsip-prinsip lainnya. Berikut beberapa contoh prinsip dasar:
- (Tetap sederhana, bodoh) – jangan mempersulitnya;
- (Jangan ulangi dirimu sendiri) - jangan ulangi dirimu sendiri;
- (Anda tidak akan membutuhkannya) - jangan membuat sesuatu yang tidak langsung dibutuhkan;
- Pemisahan kekhawatiran – berbagi tanggung jawab.
Seperti yang Anda lihat, prinsip-prinsip ini tidak menetapkan aturan khusus apa pun, tetapi termasuk dalam kategori pertimbangan akal sehat berdasarkan pengalaman praktis, yang dimiliki oleh banyak pengembang dan sering dirujuk.
Selain itu, ada – Seperangkat lima prinsip pertama pemrograman dan desain berorientasi objek, yang dirumuskan oleh Robert Martin. SOLID mencakup prinsip-prinsip yang luas, terbuka, dan saling melengkapi yang—bila diterapkan bersama—membantu menciptakan sistem perangkat lunak yang lebih baik dan memeliharanya dengan lebih baik dalam jangka panjang.
Prinsip SOLID termasuk dalam bidang OOP dan dirumuskan dalam bahasa konsep dan konsep seperti kelas, antarmuka, dan pewarisan. Secara analogi, prinsip pengembangan juga dapat dirumuskan untuk aplikasi cloud, hanya saja elemen dasar di sini bukanlah kelas, melainkan wadah. Dengan mengikuti prinsip-prinsip ini, Anda dapat membuat aplikasi dalam container yang lebih memenuhi tujuan dan sasaran platform cloud seperti Kubernetes.
Kontainer cloud-native: pendekatan Red Hat
Saat ini, hampir semua aplikasi dapat dikemas dengan relatif mudah ke dalam wadah. Namun agar aplikasi dapat diotomatisasi dan diatur secara efektif dalam platform cloud seperti Kubernetes, diperlukan upaya tambahan.
Dasar dari ide-ide yang diuraikan di bawah ini adalah metodologi dan masih banyak karya lainnya tentang berbagai aspek membangun aplikasi web, mulai dari manajemen kode sumber hingga model penskalaan. Prinsip-prinsip yang dijelaskan hanya berlaku untuk pengembangan aplikasi dalam container yang dibangun di atas layanan mikro dan dirancang untuk platform cloud seperti Kubernetes. Elemen dasar dalam diskusi kita adalah gambar container, dan runtime container target adalah platform orkestrasi container. Tujuan dari prinsip yang diusulkan adalah untuk membuat wadah yang tugas penjadwalannya, penskalaannya, dan pemantauannya dapat diotomatisasi pada sebagian besar platform orkestrasi. Prinsip-prinsip tersebut disajikan tanpa urutan tertentu.
Prinsip Kepedulian Tunggal (SCP)
Prinsip ini dalam banyak hal mirip dengan Prinsip Tanggung Jawab Tunggal. ), yang merupakan bagian dari himpunan SOLID dan menyatakan bahwa setiap objek harus mempunyai satu tanggung jawab, dan tanggung jawab tersebut harus sepenuhnya dikemas dalam sebuah kelas. Inti dari SRP adalah bahwa setiap tanggung jawab adalah alasan untuk berubah, dan sebuah kelas harus mempunyai satu dan hanya satu alasan untuk berubah.
Di SCP, kami menggunakan kata “kepedulian” dan bukan kata “tanggung jawab” untuk menunjukkan tingkat abstraksi yang lebih tinggi dan tujuan yang lebih luas dari sebuah wadah dibandingkan dengan kelas OOP. Dan jika tujuan SRP hanya memiliki satu alasan untuk melakukan perubahan, maka di balik SCP adalah keinginan untuk memperluas kemampuan untuk menggunakan kembali dan mengganti kontainer. Dengan mengikuti SRP dan membuat container yang memecahkan satu masalah dan melakukannya dengan cara yang lengkap secara fungsional, Anda meningkatkan peluang untuk menggunakan kembali image container tersebut dalam konteks aplikasi yang berbeda.
Prinsip SCP menyatakan bahwa setiap wadah harus menyelesaikan satu masalah dan menyelesaikannya dengan baik. Selain itu, SCP di dunia container lebih mudah dicapai daripada SRP di dunia OOP, karena container biasanya menjalankan satu proses, dan seringkali proses ini menyelesaikan satu tugas.
Jika layanan mikro container harus menyelesaikan beberapa masalah sekaligus, maka layanan tersebut dapat dibagi menjadi container tugas tunggal dan digabungkan dalam satu pod (unit penerapan platform container) menggunakan templat container sidecar dan init. Selain itu, SCP memudahkan penggantian wadah lama (seperti server web atau perantara pesan) dengan wadah baru yang memecahkan masalah yang sama namun memiliki fungsionalitas yang lebih luas atau skala yang lebih baik.
Prinsip Observabilitas Tinggi (HOP)
Ketika container digunakan sebagai cara terpadu untuk mengemas dan menjalankan aplikasi, aplikasi itu sendiri diperlakukan sebagai kotak hitam. Namun, jika ini adalah container cloud, maka container tersebut harus menyediakan API khusus pada runtime untuk memantau kesehatan container dan, jika perlu, mengambil tindakan yang sesuai. Tanpa hal ini, tidak mungkin menyatukan otomatisasi pembaruan container dan pengelolaan siklus hidupnya, yang pada gilirannya akan memperburuk stabilitas dan kegunaan sistem perangkat lunak.
Dalam praktiknya, aplikasi dalam container setidaknya harus memiliki API untuk berbagai jenis pemeriksaan kesehatan: uji keaktifan dan uji kesiapan. Jika suatu aplikasi mengklaim dapat berbuat lebih banyak, aplikasi tersebut harus menyediakan cara lain untuk memantau statusnya. Misalnya, mencatat peristiwa penting melalui STDERR dan STDOUT untuk agregasi log menggunakan Fluentd, Logstash, dan alat serupa lainnya. Serta integrasi dengan perpustakaan penelusuran dan pengumpulan metrik, seperti OpenTracing, Prometheus, dll.
Secara umum, aplikasi masih dapat diperlakukan sebagai kotak hitam, namun 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. Meskipun HOP menyatakan bahwa container harus mengekspos API yang telah dibaca ke platform, LCP mengharuskan aplikasi untuk dapat menerima informasi dari platform. Selain itu, wadahnya tidak hanya harus menerima peristiwa, tetapi juga beradaptasi, dengan kata lain, bereaksi terhadapnya. Oleh karena itu nama prinsipnya, yang dapat dianggap sebagai persyaratan untuk menyediakan platform dengan API penulisan.
Platform memiliki berbagai jenis peristiwa untuk membantu mengelola siklus hidup sebuah container. Namun terserah pada aplikasi itu sendiri untuk memutuskan mana yang akan dilihat dan bagaimana bereaksi.
Jelas bahwa beberapa peristiwa lebih penting daripada peristiwa lainnya. Misalnya, jika suatu aplikasi tidak mentoleransi kerusakan dengan baik, aplikasi tersebut harus menerima pesan signal: terminasi (SIGTERM) dan memulai rutinitas penghentiannya secepat mungkin untuk menangkap sinyal: kill (SIGKILL) yang muncul setelah SIGTERM.
Selain itu, peristiwa seperti PostStart dan PreStop dapat menjadi penting bagi siklus hidup aplikasi. Misalnya, setelah meluncurkan suatu aplikasi, mungkin diperlukan waktu pemanasan sebelum dapat merespons permintaan. Atau aplikasi harus melepaskan sumber daya dengan cara khusus saat dimatikan.
Prinsip Kekekalan Gambar (IIP)
Secara umum diterima bahwa aplikasi dalam container harus tetap tidak berubah setelah dibuat, meskipun aplikasi tersebut dijalankan di lingkungan yang berbeda. Hal ini memerlukan kebutuhan untuk mengeksternalisasi penyimpanan data pada waktu proses (dengan kata lain, menggunakan alat eksternal untuk ini) dan mengandalkan konfigurasi eksternal yang spesifik waktu proses, daripada memodifikasi atau membuat wadah unik untuk setiap lingkungan. Setelah perubahan apa pun pada aplikasi, gambar kontainer harus dibangun kembali dan disebarkan ke semua lingkungan yang digunakan. Omong-omong, ketika mengelola sistem TI, prinsip serupa digunakan, yang dikenal sebagai prinsip kekekalan server dan infrastruktur.
Tujuan IIP adalah untuk mencegah pembuatan image container terpisah untuk lingkungan runtime yang berbeda dan menggunakan image yang sama di mana saja dengan konfigurasi spesifik lingkungan yang sesuai. Kepatuhan terhadap prinsip ini memungkinkan penerapan praktik penting seperti otomatisasi sistem cloud seperti roll-back dan roll-forward pembaruan aplikasi.
Prinsip Pembuangan Proses (PDP)
Salah satu karakteristik terpenting dari sebuah container adalah kefanaannya: sebuah instance dari sebuah container mudah dibuat dan mudah dihancurkan, sehingga dapat dengan mudah diganti dengan instance lain kapan saja. Ada banyak alasan untuk penggantian tersebut: kegagalan uji kemudahan servis, penskalaan aplikasi, transfer ke host lain, kehabisan sumber daya platform, atau situasi lainnya.
Akibatnya, aplikasi dalam container harus mempertahankan statusnya menggunakan beberapa cara eksternal, atau menggunakan skema terdistribusi internal dengan redundansi untuk ini. Selain itu, aplikasi harus dimulai dengan cepat dan dimatikan dengan cepat, serta bersiap menghadapi kegagalan perangkat keras yang fatal secara tiba-tiba.
Salah satu praktik yang membantu menerapkan prinsip ini adalah menjaga wadah tetap berukuran kecil. Lingkungan cloud dapat secara otomatis memilih host untuk meluncurkan instance container, jadi semakin kecil containernya, semakin cepat container tersebut dimulai - container tersebut akan disalin ke host target melalui jaringan dengan lebih cepat.
Prinsip Pengendalian Diri (S-CP)
Menurut prinsip ini, pada tahap perakitan, semua komponen yang diperlukan disertakan dalam wadah. Penampung harus dibangun dengan asumsi bahwa sistem hanya memiliki kernel Linux murni, sehingga semua perpustakaan tambahan yang diperlukan harus ditempatkan di penampung itu sendiri. Itu juga harus berisi hal-hal seperti runtime untuk bahasa pemrograman yang sesuai, platform aplikasi (jika perlu), dan dependensi lain yang akan diperlukan saat aplikasi container sedang berjalan.
Pengecualian dibuat untuk konfigurasi yang bervariasi dari satu lingkungan ke lingkungan lainnya dan harus disediakan pada saat runtime, misalnya melalui ConfigMap Kubernetes.
Suatu aplikasi dapat mencakup beberapa komponen dalam container, misalnya, container DBMS terpisah dalam aplikasi web dalam container. Menurut prinsip S-CP, container ini tidak boleh digabungkan menjadi satu, tetapi harus dibuat sedemikian rupa sehingga container DBMS berisi semua yang diperlukan untuk pengoperasian database, dan container aplikasi web berisi semua yang diperlukan untuk pengoperasian web. aplikasi, server web yang sama. Akibatnya, pada saat runtime, container aplikasi web akan bergantung pada container DBMS dan mengaksesnya sesuai kebutuhan.
Prinsip Pengurungan Waktu Proses (RCP)
Prinsip S-CP mendefinisikan bagaimana wadah harus dibangun dan apa isi biner gambar. Namun container bukan sekadar “kotak hitam” yang hanya memiliki satu karakteristik – ukuran file. Selama eksekusi, container mengambil dimensi lain: jumlah memori yang digunakan, waktu CPU, dan sumber daya sistem lainnya.
Dan di sini prinsip RCP berguna, yang menurutnya wadah harus menghilangkan persyaratannya untuk sumber daya sistem dan mentransfernya ke platform. Dengan profil sumber daya setiap kontainer (berapa banyak sumber daya CPU, memori, jaringan, dan disk yang dibutuhkan), platform dapat secara optimal melakukan penjadwalan dan penskalaan otomatis, mengelola kapasitas TI, dan mempertahankan tingkat SLA untuk kontainer.
Selain memenuhi kebutuhan sumber daya kontainer, penting juga agar aplikasi tidak melampaui batasnya sendiri. Jika tidak, ketika terjadi kekurangan sumber daya, kemungkinan besar platform akan memasukkannya ke dalam daftar aplikasi yang perlu dihentikan atau dimigrasi.
Saat kita berbicara mengenai cloud-first, yang kita maksud adalah cara kita bekerja.
Di atas, kami merumuskan sejumlah prinsip umum yang menjadi landasan metodologis untuk membangun aplikasi container berkualitas tinggi untuk lingkungan cloud.
Perhatikan bahwa selain prinsip-prinsip umum ini, Anda juga memerlukan metode dan teknik lanjutan tambahan untuk bekerja dengan container. Selain itu, kami memiliki beberapa rekomendasi singkat yang lebih spesifik dan sebaiknya diterapkan (atau tidak diterapkan) tergantung pada situasinya:
- Cobalah untuk mengurangi ukuran gambar: hapus file sementara dan jangan menginstal paket yang tidak perlu - semakin kecil ukuran wadahnya, semakin cepat ia dirakit dan disalin ke host target melalui jaringan.
- Fokus pada ID Pengguna yang berubah-ubah: jangan gunakan perintah sudo atau ID pengguna khusus apa pun untuk meluncurkan container Anda.
- Tandai port penting: Anda dapat mengatur nomor port saat runtime, tetapi lebih baik menentukannya menggunakan perintah EXPOSE - ini akan memudahkan orang dan program lain untuk menggunakan gambar Anda.
- Simpan data persisten pada volume: Data yang tersisa setelah kontainer dimusnahkan harus ditulis ke volume.
- Tulis metadata gambar: tag, label, dan anotasi membuat gambar lebih mudah digunakan - pengembang lain akan berterima kasih.
- Sinkronkan host dan gambar: Beberapa aplikasi dalam container memerlukan container untuk melakukan sinkronisasi dengan host pada atribut tertentu, seperti waktu atau ID mesin.
- Sebagai kesimpulan, kami membagikan template dan praktik terbaik yang akan membantu Anda menerapkan prinsip-prinsip yang tercantum di atas secara lebih efektif:
11 Juni pukul 11.00
Apa yang akan Anda pelajari:
- CoreOS Linux Red Hat Enterprise yang tidak dapat diubah
- Jaring layanan OpenShift
- Kerangka operator
- Kerangka kerja asli
Sumber: www.habr.com