Tidak seperti transisi sebelumnya dan sama-sama revolusioner dari logam kosong ke mesin virtual, container secara dramatis mengurangi redundansi tumpukan perangkat lunak dan mengubah sifat dasar manajemen sistem operasi di perusahaan.
Banyak yang memilih untuk mempercepat migrasi mereka ke container dengan Red Hat OpenShift Container Platform, platform Kubernetes terkemuka di industri untuk sektor perusahaan. Solusi ini secara otomatis mengambil banyak tugas di hari pertama dan menawarkan ekosistem Kubernetes terbaik berdasarkan satu platform, teruji secara menyeluruh, dan sangat aman. Ini adalah solusi paling komprehensif dan fungsional untuk perusahaan, yang berisi semua yang Anda butuhkan untuk memulai dan menghilangkan banyak hambatan teknis dan kerumitan saat membangun platform Kubernetes.
Namun, OpenShift bukanlah tongkat ajaib yang menyelesaikan semua masalah dengan sendirinya. Ya, berkat kemampuannya, platform ini dapat memberikan - dan bermanfaat bagi pelanggannya - banyak manfaat dan dengan cepat terbayar, asalkan pada saat peluncurannya Anda memiliki rencana yang dipikirkan dengan matang. Agar berhasil, ada tujuh area yang perlu dikerjakan secara menyeluruh sebelum memindahkan beban kerja apa pun ke OpenShift.
1. Standarisasi aturan penamaan dan metadata
Hanya ada dua hal sulit dalam ilmu komputer: membatalkan cache dan menamai entitas.
- Phil Karlton
Setiap entitas di OpenShift dan Kubernetes memiliki namanya sendiri. Dan setiap layanan pasti memiliki nama DNS sendiri , satu-satunya batasan di sini adalah aturan penamaan DNS. Sekarang bayangkan aplikasi monolitik telah terurai menjadi 100.500 layanan mikro terpisah, masing-masing dengan basis datanya sendiri. Dan ya, di OpenShift, semuanya hierarkis, terkait, atau harus mengikuti pola. Jadi massa dan massa segala sesuatu harus diberi nama. Dan jika Anda tidak mempersiapkan standar sebelumnya, itu akan berubah menjadi Wild West yang nyata.
Apakah Anda sudah merencanakan skema implementasi layanan? Katakanlah itu akan menjadi satu namespace besar, misalnya, "database", di mana setiap orang akan menghosting database mereka. Oke, dan mari kita asumsikan bahwa semua orang melakukannya, tetapi kemudian mereka mulai menghosting cluster Kafka mereka di ruang nama mereka sendiri. Ya, tetapi apakah Anda perlu membuat "middleware" namespace? Atau lebih baik menyebutnya "perpesanan"? Dan seperti biasa, di beberapa titik ada pria yang selalu menempuh jalannya sendiri dan menganggap dirinya istimewa, dan mengatakan bahwa mereka membutuhkan ruang nama sendiri. Dan dengar, kami memiliki 17 departemen dalam organisasi, mungkin kami perlu melampirkan prefiks departemen standar kami ke semua ruang nama?
Pertimbangkan penamaan dan standar pemeriksaan sebelum memasukkan apa pun ke dalam produksi - Anda akan menghemat banyak waktu dan tenaga jika Anda melakukan ini sebelumnya. Tetapkan standar untuk semuanya. Selain itu, bukan kualitasnya yang penting di sini, tetapi ketersediaan, integritas, dan implementasinya.
Hal mega berguna lainnya adalah metadata . Standarisasi aset apa yang ingin Anda lacak dan pastikan metadata yang tepat ditulis pada sumber daya yang tepat. Mulailah dengan Label yang Direkomendasikan... Misalnya, memberi anotasi "support_email" di metadata namespace dapat menghemat waktu Anda yang berharga saat menghubungi dukungan tingkat 2 jika terjadi kegagalan besar. Selain itu, metadata dapat digunakan untuk mempersingkat nama sumber daya menjadi panjang yang bermakna daripada memberi tanda hubung semua informasi yang diperlukan di sana. Libatkan semua orang mulai dari arsitek aplikasi hingga operator TI, bertukar pikiran, dan cari tahu apa yang mungkin diperlukan untuk memiliki standar yang solid saat OpenShift diluncurkan.
2. Standarisasi gambar dasar perusahaan
Salah satu fitur utama container adalah kemampuan untuk mencampur dan mencocokkan semua bagian dari tumpukan perangkat lunak. Anda dapat, tentu saja, menggunakan jenis OS favorit Anda dan membangun semuanya di atasnya, tetapi dengan bertindak seperti ini, organisasi kehilangan peluang besar. Lagi pula, apa yang benar-benar keren tentang gambar container? Layering. Anda dapat menghapus banyak tugas penting dari pengembang dan menyelesaikannya dengan menstandarkan gambar.
Ambil contoh aplikasi java dasar. Pengembang Anda sepertinya tidak akan salah dengan OpenJDK, tetapi dengan pengelolaan kerentanan, memperbarui perpustakaan, dan masalah kebersihan TI lainnya - mereka bisa. Kita semua tahu bahwa masalah bisnis sering kali harus dibayar dengan kompromi teknis, seperti sengaja menggunakan Java versi lama. Untungnya, tugas-tugas ini mudah diotomatisasi dan dikelola di tingkat perusahaan. Anda masih dapat menggunakan gambar dasar vendor , tetapi pada saat yang sama mengatur dan mengontrol siklus pembaruan Anda dengan membuat gambar dasar Anda sendiri.
Kembali ke contoh di atas, katakanlah pengembang membutuhkan Java 11 dan Anda ingin mereka selalu menggunakan versi terbaru Java 11. Kemudian Anda membuat gambar dasar perusahaan (registry.yourcompany.io/java11) menggunakan sebagai titik awal gambar dasar dari vendor OS (registry.redhat.io/ubi8/openjdk-11). Dan ketika gambar dasar ini diperbarui, Anda secara otomatis membantu pengembang untuk menerapkan pembaruan terbaru. Selain itu, ini menyediakan lapisan abstraksi yang memungkinkan Anda memperluas gambar standar secara mulus dengan pustaka atau paket Linux yang diperlukan.
3. Standardisasi pemeriksaan kesehatan dan kesiapan
Pemantauan servis, dibutuhkan hampir di semua tempat. Dipercaya bahwa pemeriksaan kesehatan tahunan sudah cukup untuk seseorang. Kesehatan aplikasi harus diperiksa, tentu saja, lebih sering, dan dua hal utama harus dipantau:
- Apakah aplikasi sedang berjalan (health check).
- Apakah aplikasi sudah siap (pemeriksaan kesiapan).
Ada banyak metrik lain untuk memudahkan pemantauan aplikasi, tetapi keduanya adalah dasar dari tidak hanya pemantauan tetapi juga penskalaan. Kesehatan biasanya ditentukan oleh konektivitas jaringan dan kemampuan host yang menjalankan aplikasi untuk menanggapi permintaan. Sejauh menyangkut kesiapan, di sini setiap aplikasi harus menanggapi permintaan sesuai dengan standarnya masing-masing. Misalnya, meluncurkan aplikasi dengan latensi sangat rendah dapat mengakibatkan pembaruan cache yang lama atau pemanasan JVM . Dan karenanya, jeda antara tanggapan "Mulai" dan "Siap" bisa mencapai beberapa menit. Tapi, misalnya, untuk REST API stateless dengan database relasional, respons ini akan datang secara bersamaan.
Hal terpenting dalam pemeriksaan ini adalah tidak menyimpang dari logika biner murni. Launched berarti diluncurkan, tanpa ada "jenis diluncurkan" di sana. Selesai berarti siap, dan tidak ada gradasi, seperti "siap menanggapi permintaan seperti itu, tetapi tidak untuk permintaan seperti itu". Prinsipnya sederhana: semua atau tidak sama sekali.
Aspek kedua dari pemeriksaan ini adalah standarisasi. Bagaimana cara memeriksa kesiapan? Jika Anda tidak memiliki standar, maka pertanyaan sederhana seperti itu bisa menjadi mimpi buruk pemantauan yang nyata. Bandingkan saja perbedaan antara standar Quarkus dan standar Spring Boot . Tetapi tidak ada yang menginginkan itu, tetapi standar selalu menjadi masalah. Satu-satunya perbedaan adalah bahwa organisasi Anda sekarang memiliki kekuatan untuk mengembangkan dan menegakkan standar.
Perhatikan di margin. Jangan menciptakan standar Anda sendiri. Temukan dan gunakan yang sudah jadi .
4. Standarisasi log
Melanjutkan topik pemantauan, kami mencatat bahwa kombinasi penyimpanan yang tidak mahal dan solusi data besar telah memunculkan monster baru di perusahaan - pencatatan total. Sebelumnya, ini adalah log konsol yang tidak terstruktur dan kuno yang tidak berumur panjang dan dibuat dari waktu ke waktu. Sekarang mereka berusaha untuk mencatat semuanya dan membangun ilmu data dengan pembelajaran mesin untuk mengoptimalkan operasi dan pemantauan dengan cara yang paling revolusioner. Sayangnya, kita harus mengakui yang sudah jelas: setiap upaya untuk mulai mengumpulkan log dari ratusan aplikasi, tanpa memiliki standar sama sekali dan bahkan tanpa memikirkannya, selalu mengarah pada pengeluaran yang tidak ada gunanya dan selangit untuk alat untuk mengelola log dan transformasi data hanya untuk memulai kerja. Yaitu, bahkan sebelum Anda mengertibahwa pesan "Transisi selesai" atau "Pemblokiran ini dipicu" kemungkinan tidak ada hubungannya dengan operasi Anda.
Strukturnya perlu distandarisasi. Sekali lagi, integritas standar lebih penting daripada kebenarannya. Anda harus dapat menulis parser log terpisah untuk setiap aplikasi yang ada di perusahaan. Ya, ini murni potongan, bukan hal yang direplikasi. Ya, Anda akan memiliki banyak pengecualian yang tidak dapat dikontrol, terutama untuk aplikasi dalam kotak. Namun jangan membuang bayi dengan air, perhatikan detailnya: misalnya, stempel waktu di setiap log harus memenuhi standar ISO yang sesuai ; keluarannya sendiri harus dalam UTC dengan akurasi tempat desimal ke-5 dalam mikrodetik (2018-11-07T00: 25: 00.07387Z). Level log harus diterbitkan dengan CAPS dan harus ada elemen TRACE, DEBUG, INFO, WARN, ERROR. Secara umum, atur strukturnya, dan baru kemudian masuk ke detailnya.
Standarisasi struktur akan memaksa setiap orang untuk berpegang pada aturan yang sama dan menggunakan pola arsitektur yang sama. Ini berlaku untuk aplikasi dan log platform. Dan jangan menyimpang dari solusi yang sudah jadi kecuali benar-benar diperlukan. Tumpukan EFK (Elasticsearch, Fluentd dan Kibana) dari platform OpenShift harus dapat menangani semua skrip Anda. Bagaimanapun, dia memasuki platform karena suatu alasan, dan saat memperbaruinya, ini adalah hal lain yang tidak perlu Anda khawatirkan.
5. Beralih ke GitOps
Salah satu hal hebat tentang OpenShift adalah bahwa semua yang ada di sini - secara harfiah: semuanya - pada akhirnya adalah konfigurasi atau kode, yang berarti dapat dikontrol melalui sistem kontrol versi. Ini memungkinkan Anda merevolusi metode pengiriman dan menghilangkan birokrasi saat meluncurkan produksi.
Secara khusus, skema berbasis tiket tradisional dapat sepenuhnya diganti dengan model dengan permintaan git pull.... Katakanlah pemilik aplikasi ingin menyesuaikan sumber daya yang dialokasikan ke aplikasi setelah mengimplementasikan fungsi baru di dalamnya, misalnya, untuk menambah memori dari 8 GB menjadi 16 GB. Dalam skema tradisional, pengembang perlu membuat tiket dan menunggu orang lain menyelesaikan tugas terkait. Orang lain ini paling sering adalah operator TI yang hanya memperkenalkan penundaan nyata dalam proses penerapan perubahan, tanpa meningkatkan nilai proses ini, atau lebih buruk lagi, menambahkan siklus tambahan yang tidak perlu ke proses ini. Memang, operator punya dua opsi. Pertama, dia meninjau aplikasi dan memutuskan untuk mengeksekusinya, yang mana dia memasuki lingkungan produksi, membuat perubahan yang diminta secara manual, dan memulai ulang aplikasi.
Selain waktu untuk melakukan pekerjaan itu sendiri, ada penundaan tambahan di sini, karena operator, biasanya, selalu memiliki seluruh antrian permintaan untuk dieksekusi. Selain itu, terdapat risiko human error, seperti input 160GB, bukan 16GB. Opsi kedua: operator meragukan aplikasi dan dengan demikian meluncurkan reaksi berantai untuk mengetahui alasan dan konsekuensi dari perubahan yang diminta, sedemikian rupa sehingga terkadang pihak berwenang harus turun tangan.
Sekarang mari kita lihat bagaimana ini dilakukan di GitOps. Permintaan perubahan masuk ke repositori git dan menjadi permintaan penarikan. Setelah itu, developer dapat mengajukan pull request ini (terutama jika terjadi perubahan lingkungan produksi) untuk mendapatkan persetujuan pihak-pihak yang terlibat. Dengan cara ini, profesional keamanan dapat terlibat pada tahap awal, dan selalu memungkinkan untuk melacak urutan perubahan. Standar di area ini dapat diimplementasikan secara terprogram menggunakan alat yang sesuai dalam rantai alat CI / CD. Setelah disetujui, permintaan penarikan diversi dan mudah diaudit. Selain itu, dapat diuji dalam lingkungan pra-produksi sebagai bagian dari proses standar , yang sepenuhnya menghilangkan risiko kesalahan manusia.
Seperti yang Anda lihat, perubahannya radikal. Tetapi mereka akan menjadi baru tidak begitu banyak untuk pengembang yang terbiasa dengan sistem kontrol versi, seperti untuk administrator sistem dan spesialis keamanan. Tetapi segera setelah mereka mempelajari paradigma baru dan menghargai kekuatan dan kesederhanaannya, gagasan itu akan meledak.
6. Cetak Biru
Perpindahan dari aplikasi monolitik ke layanan mikro meningkatkan peran pola desain aplikasi (pola). Memang, aplikasi monolitik khas tidak terlalu dapat diklasifikasikan. Biasanya, ada REST API, pemrosesan batch, dan event driven. HTTP, FTP, kafka, JMS dan Infinispan ? Ya, tolong, dan ini juga bekerja dengan tiga database berbeda pada saat bersamaan. Dan bagaimana Anda membuat diagram ketika sejumlah besar pola integrasi aplikasi perusahaan digabungkan di sini? Tidak mungkin.
Tetapi jika Anda menguraikan aplikasi monolitik seperti itu menjadi bagian-bagian terpisah, maka templat dibedakan menjadi lebih mudah dan lebih mudah. Katakanlah sekarang ada empat aplikasi terpisah dan mereka menggunakan templat berikut:
- REST API untuk mengelola data dalam DBMS.
- Pemrosesan batch yang akan memeriksa server FTP untuk pembaruan data dan mengirimkannya ke topik kafka.
- Camel adalah adaptor yang mengambil data dari topik kafka ini dan mengirimkannya ke REST API
- REST API yang mengekspos informasi agregat yang dikumpulkan dari Data Grid yang bertindak seperti mesin negara.
Jadi sekarang kami memiliki skema, dan skema dapat distandarisasi. REST API harus sesuai dengan standar Open API . Pekerjaan batch akan dikelola sebagai pekerjaan batch OpenShift . Integrasi akan menggunakan Unta... Anda dapat membuat skema untuk API, untuk pekerjaan batch, untuk AI / ML, untuk aplikasi multicast, atau apa pun. Dan kemudian Anda dapat menentukan cara menerapkan skema ini, cara mengkonfigurasinya, template mana yang akan digunakan. Dengan standar ini, Anda tidak perlu selalu mengubah roda, dan Anda dapat lebih fokus pada tugas yang sangat penting, seperti membuat fungsi bisnis baru. Mengerjakan skema mungkin tampak seperti membuang-buang waktu, tetapi usaha yang dikeluarkan akan menghasilkan seratus kali lipat di masa depan.
7. Siapkan API
API dilengkapi dengan arsitektur layanan mikro. Mereka juga harus dikelola dan dipersiapkan dengan lebih baik sebelumnya.
Pertama, standar dibutuhkan lagi di sini. Anda dapat menggunakan standar Open API sebagai titik awal , tetapi Anda harus mempelajari lebih dalam tentang hutan. Meskipun penting untuk mencapai keseimbangan di sini dan tidak jatuh ke dalam regulasi berlebihan yang berlebihan dengan banyak batasan. Lihatlah pertanyaan-pertanyaan ini: Ketika entitas baru dibuat menggunakan POST, haruskah kita mengembalikan 201 atau 200? apakah diperbolehkan untuk memperbarui entitas menggunakan POST dan bukan PUT? Apa perbedaan antara 400 dan 500 tanggapan? - tentang tingkat detail yang sama dengan yang Anda butuhkan.
Kedua, Anda membutuhkan jaring layanan... Ini adalah hal yang sangat kuat dan seiring waktu akan menjadi bagian integral dari Kubernetes. Mengapa? Karena lalu lintas cepat atau lambat akan berubah menjadi masalah, dan Anda ingin mengelolanya baik di dalam pusat data (yang disebut lalu lintas "timur-barat"), dan antara pusat data dan dunia luar ("utara- Selatan"). Anda akan ingin menarik otentikasi dan otorisasi dari aplikasi dan membawanya ke tingkat platform. Anda akan memerlukan kemampuan Kiali untuk memvisualisasikan lalu lintas di dalam jaring layanan, serta skema penerapan aplikasi biru-hijau dan kenari, atau, misalnya, kontrol lalu lintas dinamis. Secara umum, mesh layanan termasuk dalam kategori tugas hari pertama tanpa pertanyaan.
Ketiga, Anda memerlukan solusi manajemen API terpusat... Anda akan ingin memiliki "satu jendela" untuk menemukan dan menggunakan kembali API. Pengembang harus dapat pergi ke penyimpanan API, menemukan API yang mereka inginkan, dan mendapatkan dokumentasi tentang cara menggunakannya. Anda sebaiknya mengelola versi dan penghentian secara konsisten. Jika Anda membangun API untuk konsumen eksternal, itu bisa menjadi titik akhir utara-selatan untuk keamanan dan manajemen beban. 3Scale bahkan dapat membantu dengan monetisasi API. Nah, cepat atau lambat manajemen Anda akan ingin menerima laporan yang menjawab pertanyaan "API apa yang kami miliki?"
Sebagai kesimpulan, kami mencatat bahwa meskipun mengidentifikasi area untuk standardisasi dan mendokumentasikan standar perusahaan dapat menjadi sesuatu yang menakutkan, sebagian besar upaya tidak dihabiskan untuk hal ini, tetapi untuk memantau dan menegakkan kepatuhan terhadap standar. Perpaduan yang kuat dari entropi organisasidan keengganan alami untuk berkonflik dengan kolega sejak awal bertentangan dengan standar. Pertarungan terbagi menjadi pertempuran kecil dan terkadang tak terlihat yang tak terhitung jumlahnya: label yang diperlukan tidak ada di sini, dan nama ini, meskipun tidak sepenuhnya, masih cukup memenuhi standar. Standar biasanya mati karena seribu luka, dan sedikit, jika ada, di organisasi yang mengetahuinya. Dalam arti tertentu, standar itu seperti olahraga: tidak ada yang mau berkeringat dan tegang, tetapi semua orang tahu bahwa umur panjang dan sehat tidak mungkin tanpanya.
Namun, masih ada harapan, dan itu terletak pada otomatisasi. Salah satu standar di atas dapat diterapkan menggunakan otomatisasi. Proses GitOps dapat memverifikasi bahwa semua label dan anotasi yang diperlukan ada di semua file yaml yang relevan. Proses CI / CD dapat menerapkan standar untuk citra perusahaan. Semuanya dapat dikodifikasi, diuji, dan diselaraskan. Selain itu, otomatisasi dapat ditingkatkan saat Anda memperkenalkan standar baru atau mengubah yang sudah ada. Keuntungan yang tidak diragukan lagi dari standardisasi melalui otomasi adalah bahwa komputer tidak menghindari konflik, tetapi hanya menyatakan fakta. Oleh karena itu, dengan kecanggihan dan investasi yang cukup dalam otomatisasi, platform tempat Anda berinvestasi hari ini adalahdapat menghasilkan laba atas investasi yang jauh lebih besar di masa depan dalam bentuk peningkatan kinerja dan stabilitas.