Aplikasi "berorientasikan awan" (asli awan) atau ringkasnya "awan" dicipta khusus untuk berfungsi dalam infrastruktur awan. Ia biasanya dibina sebagai satu set perkhidmatan mikro berganding longgar yang dibungkus dalam bekas, yang seterusnya diuruskan oleh platform awan. Aplikasi ini selamat gagal secara lalai, yang bermaksud ia berfungsi dengan pasti dan berskala walaupun dalam menghadapi kegagalan peringkat infrastruktur yang teruk. Bahagian belakang syiling ialah set sekatan (kontrak) yang dikenakan oleh platform awan pada aplikasi kontena agar dapat mengurusnya secara automatik.
Menyedari sepenuhnya keperluan dan kepentingan untuk beralih ke awan, banyak organisasi masih tidak tahu di mana untuk bermula. Dalam siaran ini, kami akan melihat beberapa prinsip yang, apabila membangunkan aplikasi kontena, akan membolehkan anda merealisasikan potensi platform awan dan mencapai operasi yang boleh dipercayai dan penskalaan aplikasi walaupun dengan kegagalan teruk di peringkat infrastruktur IT. Matlamat utama prinsip yang digariskan di sini adalah untuk mempelajari cara membina aplikasi yang boleh diuruskan secara automatik oleh platform awan seperti Kubernetes.
Prinsip Reka Bentuk Perisian
Dalam dunia pengaturcaraan, prinsip adalah peraturan yang agak umum yang mesti dipatuhi semasa membangunkan perisian. Mereka boleh digunakan dengan mana-mana bahasa pengaturcaraan. Setiap prinsip mempunyai matlamat tersendiri, yang biasanya dicapai melalui corak dan amalan. Terdapat juga beberapa prinsip asas untuk mencipta perisian berkualiti tinggi, yang mana semua yang lain mengikutinya. Berikut adalah beberapa contoh prinsip asas:
- (Keep it simple, stupid) - jangan rumitkan;
- (Jangan ulangi diri sendiri) - jangan ulangi diri sendiri;
- (Anda tidak akan memerlukannya) - jangan cipta sesuatu yang tidak diperlukan segera;
- (Separation of concerns) - untuk berkongsi tanggungjawab.
Seperti yang anda lihat, prinsip ini tidak menetapkan sebarang peraturan khusus, tetapi tergolong dalam kategori yang dipanggil pertimbangan akal berdasarkan pengalaman praktikal, yang dikongsi oleh banyak pembangun dan yang sering dirujuk.
Di samping itu, ada - satu set lima prinsip pertama pengaturcaraan dan reka bentuk berorientasikan objek, yang dirumuskan oleh Robert Martin. SOLID termasuk prinsip pelengkap umum dan terbuka kepada tafsiran yang - apabila digunakan dalam gabungan - membantu untuk mencipta sistem perisian yang lebih baik dan mengekalkannya dengan lebih baik dalam jangka panjang.
Prinsip SOLID tergolong dalam alam OOP dan dirumuskan dalam bahasa konsep dan konsep seperti kelas, antara muka dan warisan. Secara analogi, untuk aplikasi awan, prinsip pembangunan juga boleh dirumuskan, hanya elemen asas di sini tidak akan menjadi kelas, tetapi bekas. Dengan mengikuti prinsip ini, anda boleh membuat aplikasi kontena yang memenuhi matlamat dan objektif platform awan seperti Kubernetes dengan lebih baik.
Bekas Berasaskan Awan: Pendekatan Topi Merah
Hari ini, hampir mana-mana aplikasi boleh dibungkus dengan mudah dalam bekas. Tetapi untuk membolehkan aplikasi diautomatikkan dan diatur dengan berkesan dalam platform awan seperti Kubernetes, usaha tambahan diperlukan.
Metodologi berikut digunakan sebagai asas untuk idea dan banyak lagi kerja lain mengenai pelbagai aspek membina aplikasi web, daripada pengurusan kod sumber kepada model penskalaan. Prinsip yang diterangkan hanya digunakan untuk pembangunan aplikasi kontena yang dibina di atas perkhidmatan mikro dan direka bentuk untuk platform awan seperti Kubernetes. Elemen asas dalam perbincangan kami ialah imej kontena, dan masa jalan sasaran kontena ialah platform orkestrasi kontena. Tujuan prinsip yang dicadangkan adalah untuk mencipta bekas yang, pada kebanyakan platform orkestrasi, adalah mungkin untuk mengautomasikan tugas penjadualan (penjadualan - memilih hos untuk menjalankan contoh kontena), penskalaan dan pemantauan. Prinsip dibentangkan tanpa susunan tertentu.
Prinsip Keprihatinan Tunggal (SCP)
Prinsip ini serupa dalam banyak cara dengan Prinsip Tanggungjawab Tunggal. ), yang merupakan sebahagian daripada set SOLID dan menyatakan bahawa setiap objek mesti mempunyai satu tanggungjawab, dan tanggungjawab ini mesti dirangkumkan sepenuhnya dalam kelas. Intipati SRP ialah setiap tanggungjawab adalah sebab untuk berubah, dan kelas harus mempunyai satu dan hanya satu sebab untuk berubah.
Dalam SCP, bukannya perkataan "tanggungjawab" (tanggungjawab), kami menggunakan perkataan "tugas" (kebimbangan) untuk menunjukkan tahap abstraksi yang lebih tinggi dan tujuan kontena yang lebih luas berbanding kelas OOP. Dan jika matlamat SRP adalah untuk mempunyai hanya satu sebab untuk perubahan, maka keinginan di sebalik SCP adalah untuk memperluaskan kemungkinan menggunakan semula dan menggantikan bekas. Dengan mengikuti SRP dan mencipta bekas yang melakukan satu perkara dan melakukannya dengan cara yang lengkap dari segi fungsi, anda meningkatkan peluang untuk menggunakan semula imej bekas tersebut dalam konteks aplikasi yang berbeza.
Prinsip SCP mengatakan bahawa setiap bekas harus menyelesaikan satu tugas dan melakukannya dengan baik. Selain itu, SCP dalam dunia kontena lebih mudah dicapai berbanding SRP dalam dunia OOP, kerana kontena biasanya menjalankan satu proses tunggal, dan kebanyakan masa proses ini menyelesaikan satu tugasan.
Jika perkhidmatan mikro kontena perlu menyelesaikan beberapa tugas sekaligus, maka ia boleh dibahagikan kepada bekas tugas tunggal dan digabungkan dalam satu pod (unit penggunaan platform kontena) menggunakan templat sidecar dan bekas init. Selain itu, SCP memudahkan untuk menggantikan bekas lama (seperti pelayan web atau broker mesej) dengan yang baharu yang melakukan kerja yang sama tetapi mempunyai lebih banyak fungsi atau skala yang lebih baik.
Prinsip Kebolehmerhatian Tinggi (HOP)
Apabila menggunakan bekas sebagai cara bersatu untuk membungkus dan menjalankan aplikasi, aplikasi itu sendiri dianggap sebagai "kotak hitam". Walau bagaimanapun, jika ia adalah bekas awan, maka ia mesti menyediakan API khusus kepada masa jalan untuk memantau kesihatan kontena dan mengambil tindakan yang sewajarnya jika perlu. Tanpa ini, tidak mungkin untuk menyatukan automasi mengemas kini bekas dan mengurus kitaran hayatnya, yang seterusnya akan memburukkan kestabilan dan kebolehgunaan sistem perisian.
Dalam amalan, aplikasi dalam kontena hendaklah sekurang-kurangnya mempunyai API untuk pelbagai jenis pemeriksaan kesihatan: ujian keaktifan dan ujian kesediaan. Jika permohonan menuntut lebih daripada itu, ia mesti menyediakan cara lain untuk memantau keadaannya. Contohnya, mengelog peristiwa penting melalui STDERR dan STDOUT untuk pengagregatan pengelogan menggunakan Fluentd, Logstash dan alatan lain yang serupa. Serta penyepaduan dengan perpustakaan pengesanan dan metrik seperti OpenTracing, Prometheus, dll.
Secara umum, aplikasi masih boleh dilihat sebagai "kotak hitam", tetapi ia mesti disediakan dengan semua API yang diperlukan oleh platform untuk memantau dan mengurusnya dengan cara yang terbaik.
Prinsip Pematuhan Kitaran Hayat (LCP)
LCP adalah antitesis HOP. Walaupun HOP mengatakan bahawa bekas mesti menyediakan API baca kepada platform, LCP memerlukan aplikasi untuk dapat membaca maklumat daripada platform. Selain itu, bekas itu bukan sahaja harus menerima acara, tetapi juga menyesuaikan diri, dengan kata lain, bertindak balas kepada mereka. Oleh itu, nama prinsip itu, yang boleh dianggap sebagai keperluan untuk menyediakan API tulis kepada platform.
Platform mempunyai jenis acara yang berbeza untuk membantu mengurus kitaran hayat bekas. Tetapi terpulang kepada permohonan untuk memutuskan yang mana antara mereka untuk dilihat dan bagaimana untuk bertindak balas.
Jelas bahawa beberapa acara lebih penting daripada yang lain. Contohnya, jika aplikasi tidak bertolak ansur dengan ranap, maka ia mesti menerima isyarat: tamatkan (SIGTERM) mesej dan memulakan prosedur penamatannya secepat mungkin agar tepat pada masanya untuk isyarat: bunuh (SIGKILL) yang datang selepas SIGTERM .
Selain itu, acara seperti PostStart dan PreStop boleh menjadi penting kepada kitaran hayat aplikasi. Contohnya, selepas melancarkan aplikasi, ia mungkin mengambil masa tertentu untuk "memanaskan badan" sebelum ia boleh membalas permintaan. Atau aplikasi mesti mengeluarkan sumber dalam beberapa cara khas apabila ia ditutup.
Prinsip kebolehubahan imej bekas (Prinsip Ketidakbolehubahan Imej, IIP)
Secara amnya diterima bahawa aplikasi kontena harus kekal sama selepas dibina, walaupun ia dijalankan dalam persekitaran yang berbeza. Ini memerlukan keperluan untuk membuat luaran storan data pada masa jalan (dengan kata lain, gunakan alat luaran untuk ini), dan juga bergantung pada konfigurasi khusus masa jalan luaran, dan bukannya mengubah suai atau mencipta bekas unik untuk setiap persekitaran. Selepas sebarang perubahan pada aplikasi, imej bekas mesti dibina semula dan digunakan untuk semua persekitaran yang digunakan. Ngomong-ngomong, apabila menguruskan sistem IT, prinsip yang sama digunakan, yang dikenali sebagai prinsip kebolehubahan pelayan dan infrastruktur.
Matlamat IIP adalah untuk menghalang penciptaan imej bekas yang berasingan untuk persekitaran masa jalan yang berbeza dan menggunakan imej yang sama di mana-mana bersama-sama dengan konfigurasi khusus persekitaran yang sesuai. Mengikuti prinsip ini membolehkan anda melaksanakan amalan penting sedemikian dari sudut pandangan mengautomasikan sistem awan seperti rollback (roll-back) dan roll-forward (roll-forward) kemas kini aplikasi.
Prinsip Kebolehgunaan Proses (PDP)
Salah satu ciri paling penting bagi bekas ialah sifatnya yang tidak lama: contoh bekas mudah dibuat dan mudah dimusnahkan, jadi ia boleh diganti dengan mudah dengan contoh lain pada bila-bila masa. Terdapat banyak sebab untuk penggantian sedemikian: kegagalan ujian kesihatan, penskalaan aplikasi, pemindahan ke hos lain, kehabisan sumber platform atau situasi lain.
Akibatnya, aplikasi kontena mesti menyimpan keadaannya menggunakan beberapa cara luaran, atau menggunakan skim teragih berlebihan dalaman untuk ini. Di samping itu, aplikasi mesti bermula dan selesai dengan cepat, dan bersedia untuk kegagalan perkakasan yang membawa maut secara tiba-tiba.
Satu amalan untuk membantu melaksanakan prinsip ini ialah memastikan bekas kecil. Persekitaran awan secara automatik boleh memilih hos untuk menjalankan contoh kontena, jadi lebih kecil saiz kontena, lebih cepat ia akan bermula - ia hanya akan menyalin ke hos sasaran melalui rangkaian dengan lebih pantas.
Prinsip Pengekalan Diri (S-CP)
Menurut prinsip ini, pada peringkat pemasangan, semua komponen yang diperlukan dimasukkan ke dalam bekas. Bekas harus dibina dengan andaian bahawa sistem hanya mempunyai kernel Linux tulen, jadi semua perpustakaan tambahan yang diperlukan harus diletakkan di dalam bekas itu sendiri. Ia juga harus mengandungi perkara seperti masa jalan untuk bahasa pengaturcaraan yang sesuai, platform aplikasi (jika perlu) dan kebergantungan lain yang akan diperlukan semasa pengendalian aplikasi kontena.
Pengecualian dibuat hanya untuk konfigurasi, yang berbeza dari persekitaran ke persekitaran, dan mesti disediakan pada masa jalankan, contohnya, melalui Kubernetes ConfigMap.
Aplikasi boleh memasukkan berbilang komponen dalam kontena, seperti bekas DBMS yang berasingan sebagai sebahagian daripada aplikasi web kontena. Menurut prinsip S-CP, bekas ini tidak boleh digabungkan menjadi satu, tetapi harus dibuat supaya bekas DBMS mengandungi semua yang diperlukan untuk operasi pangkalan data, dan bekas aplikasi web mengandungi semua yang diperlukan untuk pengendalian web. aplikasi, pelayan web yang sama . Akibatnya, pada masa jalan, bekas aplikasi web akan bergantung pada bekas DBMS dan mengaksesnya seperti yang diperlukan.
Prinsip Pengurungan Masa Jalan (RCP)
Prinsip S-CP mentakrifkan bagaimana bekas harus dibina dan apa yang harus terkandung dalam fail imej binari. Tetapi bekas bukan hanya "kotak hitam" yang mempunyai hanya satu ciri - saiz fail. Pada masa jalanan, bekas juga memperoleh dimensi lain: jumlah memori yang digunakan, masa pemproses dan sumber sistem lain.
Dan di sini prinsip RCP sangat berguna, mengikut mana bekas itu mesti memenggal keperluannya untuk sumber sistem dan memindahkannya ke platform. Dengan mempunyai profil sumber untuk setiap bekas (berapa banyak CPU, memori, rangkaian dan sumber cakera yang diperlukan), platform boleh menghantar dan autoscale secara optimum, mengurus kapasiti IT dan mengekalkan tahap SLA untuk bekas.
Di samping memenuhi keperluan sumber kontena, aplikasi juga penting untuk tidak melampaui had yang ditunjukkan dengan sendirinya. Jika tidak, apabila kekurangan sumber berlaku, platform lebih cenderung untuk memasukkannya dalam senarai aplikasi yang perlu diganggu atau dipindahkan.
Apabila kita bercakap tentang berpusatkan awan, yang kami maksudkan adalah cara kami bekerja.
Di atas, kami merumuskan beberapa prinsip umum yang menetapkan asas metodologi untuk membina aplikasi kontena berkualiti tinggi untuk persekitaran awan.
Ambil perhatian bahawa sebagai tambahan kepada prinsip umum ini, anda juga memerlukan kaedah dan teknik lanjutan tambahan untuk bekerja dengan bekas. Selain itu, kami mempunyai beberapa garis panduan ringkas yang lebih khusus dan harus digunakan (atau tidak digunakan) bergantung pada situasi:
- Cuba kurangkan saiz imej: alih keluar fail sementara dan jangan pasang pakej yang tidak perlu - lebih kecil saiz bekas, lebih cepat ia dipasang dan disalin ke hos sasaran melalui rangkaian.
- Sasarkan ID Pengguna sewenang-wenangnya: jangan gunakan arahan sudo atau mana-mana id pengguna khas untuk memulakan bekas anda.
- Labelkan Port Penting: Nombor port juga boleh ditetapkan pada masa jalan, tetapi lebih baik untuk menentukannya dengan arahan EXPOSE supaya orang dan program lain boleh menggunakan imej anda dengan lebih mudah.
- Simpan data berterusan pada volum: Data yang sepatutnya kekal selepas bekas dimusnahkan hendaklah ditulis kepada jilid.
- Tulis metadata imej: teg, label dan anotasi menjadikan imej lebih mudah digunakan - pembangun lain akan berterima kasih kepada anda.
- Segerakkan hos dan imej: Sesetengah aplikasi kontena memerlukan bekas untuk menyegerakkan dengan hos berdasarkan atribut tertentu, seperti masa atau ID mesin.
- Kesimpulannya, kami berkongsi corak dan amalan terbaik yang akan membantu anda melaksanakan prinsip yang disenaraikan di atas dengan lebih berkesan:
11 Jun jam 11.00
Apa yang akan anda pelajari:
- Red Hat Enterprise Linux CoreOS yang tidak boleh diubah
- Jaringan perkhidmatan OpenShift
- rangka kerja operator
- Rangka kerja Knatif
Sumber: www.habr.com