OpenShift 4.0 - bersiap-siap untuk melompat hiper

Ini adalah yang pertama dari serangkaian publikasi kami yang ditujukan untuk peningkatan dan penambahan dalam pembaruan terbaru platform Red Hat OpenShift ke versi 4.0, yang akan membantu Anda mempersiapkan transisi ke versi baru.



Alat apa yang dapat Anda miliki untuk menciptakan produk perangkat lunak yang lebih baik, dan bagaimana mereka meningkatkan keamanan dan membuat pengembangan lebih mudah dan lebih dapat diandalkan?

Dari saat perwakilan dari komunitas Kubernetes yang baru terbentuk pertama kali berkumpul pada musim gugur 2014 di kantor Google di Seattle, sudah dapat dikatakan bahwa proyek Kubernetes ditakdirkan untuk secara fundamental mengubah pendekatan modern dalam pengembangan dan implementasi perangkat lunak. Pada saat yang sama, penyedia layanan cloud publik terus aktif berinvestasi dalam pengembangan infrastruktur dan layanan, yang sangat memudahkan dan menyederhanakan pekerjaan dengan TI dan pembuatan perangkat lunak, dan menjadikannya sangat terjangkau, yang hanya bisa dibayangkan oleh sedikit orang pada awal dekade.

Tentu saja, pengumuman setiap layanan cloud baru disertai dengan berbagai diskusi oleh para ahli di Twitter, dan perselisihan diadakan pada berbagai topik - termasuk akhir era open source, penurunan TI di sisi klien (on-premise IT), keniscayaan monopoli perangkat lunak baru di awan, dan bagaimana paradigma baru X akan menggantikan semua paradigma lainnya.

Namun, kenyataannya adalah tidak ada yang hilang, dan hari ini Anda dapat mengamati pertumbuhan eksponensial produk akhir dan metode untuk pengembangan mereka, yang terkait dengan kemunculan perangkat lunak baru yang terus-menerus dalam kehidupan kita. Dan terlepas dari kenyataan bahwa segala sesuatu di sekitar akan berubah, pada saat yang sama, pada dasarnya, semuanya akan tetap tidak berubah. Pengembang perangkat lunak akan terus menulis kode dengan kesalahan, teknisi pemeliharaan, dan spesialis keandalan akan terus berjalan dengan pager dan menerima peringatan otomatis di Slack, manajer akan tetap beroperasi pada konsep-konsep OpEx dan CapEx, dan setiap kali terjadi kegagalan, senior pengembang sedih akan sedih dengan kata-kata: "Aku berkata" ...

Dengan semakin kompleksnya proyek, muncul risiko baru, dan kehidupan masyarakat saat ini sangat tergantung pada perangkat lunak sehingga pengembang hanya diwajibkan untuk mencoba melakukan pekerjaan mereka dengan lebih baik.

Kubernetes adalah salah satu alat tersebut. Pekerjaan sedang dilakukan untuk mengintegrasikannya dengan alat dan layanan lain ke dalam satu platform tunggal dalam kerangka kerja Red Hat OpenShift, yang akan membuat perangkat lunak lebih andal, mudah dikelola, dan aman bagi pengguna.

Dengan itu, muncul pertanyaan: bagaimana membuat bekerja dengan Kubernet lebih mudah dan nyaman?

Jawabannya mungkin tampak sangat sederhana:

• Mengotomatiskan saat-saat kompleks ketika menggunakan awan atau di luar cloud
• fokus pada keandalan sambil menyembunyikan kompleksitas;
• Terus berupaya merilis pembaruan yang sederhana dan aman
• mencapai kemampuan kontrol dan audit;
• berusaha untuk awalnya memberikan keamanan tinggi, tetapi tidak dengan mengorbankan kegunaan.

Rilis OpenShift selanjutnya harus mempertimbangkan baik pengalaman pembuat maupun pengalaman pengembang lain yang mengimplementasikan perangkat lunak dalam skala besar di perusahaan terbesar di dunia. Selain itu, perlu memperhitungkan semua pengalaman akumulasi ekosistem terbuka yang saat ini menjadi dasar dunia modern. Dalam hal ini, perlu untuk meninggalkan mentalitas lama pengembang amatir dan beralih ke filosofi baru dari masa depan otomatis. Ini harus menjadi "jembatan" antara cara lama dan baru untuk menyebarkan perangkat lunak dan memanfaatkan sepenuhnya semua infrastruktur yang tersedia - tidak masalah apakah itu dilayani oleh penyedia cloud terbesar atau berjalan pada sistem kecil di pinggiran.

Bagaimana cara mencapai hasil seperti itu?

Di Red Hat, adalah kebiasaan untuk melakukan pekerjaan yang membosankan dan tidak berterima kasih untuk waktu yang lama untuk menjaga komunitas yang sudah mapan dan mencegah penutupan proyek-proyek di mana perusahaan ikut serta. Komunitas open-source terdiri dari sejumlah besar pengembang berbakat yang menciptakan hal-hal yang paling luar biasa - menghibur, mendidik, menemukan peluang baru dan hanya cantik, tetapi, tentu saja, tidak ada yang mengharapkan semua peserta untuk bergerak ke arah yang sama atau mengejar tujuan bersama. Penggunaan energi ini, pengalihannya ke arah yang benar, kadang-kadang diperlukan untuk pengembangan area yang akan berguna bagi pengguna kami, tetapi pada saat yang sama, kami harus memantau perkembangan komunitas kami dan belajar dari mereka.

Pada awal 2018, Red Hat mengakuisisi proyek CoreOS, yang memiliki pandangan serupa tentang masa depan - pendekatan open-source yang lebih aman dan andal. Perusahaan bekerja pada pengembangan lebih lanjut dari ide-ide ini dan implementasinya, menerapkan filosofi kami - berusaha mencapai operasi yang aman dari semua perangkat lunak. Semua pekerjaan ini dibangun di atas Kubernetes, Linux, cloud publik, cloud pribadi, dan ribuan proyek lain yang mendasari ekosistem digital modern kita.

Rilis baru OpenShift 4 akan dapat dimengerti, otomatis dan lebih alami

Platform OpenShift akan bekerja dengan sistem operasi Linux yang terbaik dan paling dapat diandalkan, dengan dukungan perangkat keras logam, virtualisasi yang mudah digunakan, pemrograman otomatis infrastruktur dan, tentu saja, wadah (yang pada dasarnya hanya gambar Linux).

Platform harus aman sejak awal, tetapi pada saat yang sama memberikan kemungkinan iterasi yang nyaman bagi pengembang - yaitu, memiliki fleksibilitas dan keandalan yang cukup, sambil tetap memungkinkan administrator untuk mengaudit dan memberikan kemudahan manajemen.

Seharusnya memungkinkan Anda untuk menjalankan perangkat lunak "dalam bentuk layanan", dan tidak mengarah pada perluasan infrastruktur yang tidak terkendali untuk operator.

Ini akan memungkinkan pengembang untuk fokus pada menciptakan produk nyata untuk pengguna dan pelanggan. Tidak perlu merobohkan hutan pengaturan perangkat keras dan perangkat lunak, dan semua komplikasi acak akan menjadi hal di masa lalu.

OpenShift 4: Platform NoOps Tidak Perlu Perawatan

Publikasi ini menjelaskan tugas-tugas yang membantu membentuk visi perusahaan untuk OpenShift 4. Tim memiliki tugas untuk menyederhanakan tugas harian mengoperasikan dan memelihara perangkat lunak secara maksimal, menjadikan proses ini mudah dan mudah, baik untuk spesialis implementasi maupun untuk pengembang. Tetapi bagaimana seseorang dapat mendekati tujuan ini? Bagaimana cara membuat platform untuk meluncurkan perangkat lunak yang memerlukan intervensi minimal? Apa yang dimaksud NoOps dalam konteks ini?

Jika Anda mencoba mengabaikannya, maka bagi pengembang konsep "tanpa server" atau "NoOps" berarti alat dan layanan yang memungkinkan Anda menyembunyikan komponen "operasional" atau meminimalkan beban ini untuk pengembang.

• Bekerja bukan dengan sistem, tetapi dengan antarmuka aplikasi (API).
• Jangan mengimplementasikan perangkat lunak - biarkan penyedia melakukan ini sebagai ganti Anda.
• Anda seharusnya tidak segera mengambil pembuatan kerangka kerja besar - mulailah dengan menulis fragmen kecil yang akan bertindak sebagai "blok bangunan", cobalah untuk membuat kode ini berfungsi dengan data dan acara, dan bukan dengan disk dan basis data.

Tugasnya, seperti sebelumnya, adalah mempercepat iterasi dalam pengembangan perangkat lunak, memberikan kesempatan untuk menciptakan produk yang lebih baik, dan agar pengembang tidak dapat khawatir tentang sistem di mana perangkat lunaknya berjalan. Pengembang yang berpengalaman sangat menyadari bahwa jika Anda berfokus pada pengguna, gambarnya dapat berubah dengan cepat, jadi Anda tidak perlu terlalu banyak berupaya dalam menulis perangkat lunak jika Anda tidak memiliki kepercayaan mutlak terhadap kebutuhannya.

Bagi para profesional yang terlibat dalam pemeliharaan dan operasi, kata "NoOps" mungkin terdengar agak menakutkan. Tetapi ketika berkomunikasi dengan insinyur operasi, menjadi jelas bahwa pola dan metode yang digunakan oleh mereka, bertujuan untuk memastikan keandalan keandalan (Site Reliability Engineering, SRE), sebagian besar tumpang tindih dengan pola yang dijelaskan di atas:

• Jangan mengelola sistem - mengotomatiskan proses manajemen mereka.
• Jangan mengimplementasikan perangkat lunak - buat saluran pipa untuk penyebarannya.
• Cobalah untuk tidak menggabungkan semua layanan Anda bersama-sama dan tidak membiarkan kegagalan salah satu dari mereka mengarah pada kegagalan seluruh sistem - membubarkan mereka di seluruh infrastruktur menggunakan alat otomatisasi, dan menghubungkannya, menyediakan kemungkinan kontrol dan pemantauan.

Spesialis SRE tahu bahwa ada sesuatu yang salah dan mereka harus melacak dan memperbaiki masalah - oleh karena itu, mereka mengotomatisasi rutin dan menentukan toleransi kesalahan terlebih dahulu agar siap untuk memprioritaskan dan membuat keputusan ketika masalah terjadi .

OpenShift's Kubernetes adalah platform yang dirancang untuk menyelesaikan dua tugas utama: alih-alih memaksa Anda untuk berurusan dengan mesin virtual atau memuat API penyeimbang, bekerja dengan abstraksi tingkat tinggi - dengan proses dan layanan penyebaran. Alih-alih menginstal agen perangkat lunak, Anda dapat menjalankan wadah, dan alih-alih menulis tumpukan pemantauan Anda sendiri, gunakan alat yang sudah tersedia di platform. Jadi, bahan rahasia OpenShift 4 sebenarnya tidak mewakili rahasia apa pun - Anda hanya perlu menggunakan prinsip-prinsip SRE dan konsep tanpa server sebagai dasar, dan membawanya ke kesimpulan logisnya, untuk membantu pengembang dan teknisi pemeliharaan:

• Mengotomatiskan dan membakukan infrastruktur yang digunakan oleh aplikasi
• Menyatukan proses penyebaran dan pengembangan tanpa membatasi pengembang itu sendiri
• Memastikan bahwa peluncuran, audit, dan keamanan layanan keseratus, fungsi, aplikasi, atau seluruh tumpukan tidak lebih sulit daripada yang pertama.

Tapi apa perbedaan antara platform OpenShift 4 dan pendahulunya dan pendekatan "standar" untuk memecahkan masalah seperti itu? Bagaimana scaling dicapai untuk tim implementasi dan operasi? Karena kenyataan bahwa raja dalam situasi ini adalah sekelompok. Jadi

• Kami membuat tujuan klaster dapat dipahami (Awan yang terhormat, saya mengangkat kluster ini karena saya bisa)
• Mesin dan sistem operasi ada untuk melayani kluster (Yang Mulia)
• Kelola keadaan host dari cluster, minimalkan pembangunan kembali (drift) mereka.
• Untuk setiap elemen penting dari sistem, seorang pengasuh (mekanisme) diperlukan yang akan melacak dan memperbaiki masalah
• Kegagalan * dari setiap aspek atau elemen sistem, mekanisme pemulihan yang sesuai adalah bagian dari kehidupan sehari-hari
• Seluruh infrastruktur harus dikonfigurasi melalui API.
• Gunakan Kubernetes untuk meluncurkan Kubernetes. (Ya, ya, ini bukan salah ketik)
• Pembaruan harus diinstal dengan mudah dan alami. Jika diperlukan lebih dari satu klik untuk menginstal pembaruan, maka jelas Anda \ kami melakukan sesuatu yang salah.
• Pemantauan dan debugging komponen apa pun seharusnya tidak menjadi masalah, dan karenanya, pelacakan dan pelaporan di seluruh infrastruktur juga harus sederhana dan nyaman.

Ingin melihat kemampuan platform dalam aksi?

Versi awal OpenShift 4 telah tersedia untuk pengembang. Dengan penginstal yang mudah digunakan, Anda dapat menjalankan gugus AWS di atas Red Had CoreOS. Untuk menggunakan versi pratinjau, Anda hanya perlu akun AWS untuk menyediakan infrastruktur dan satu set akun untuk mengakses gambar versi pratinjau.

1. Untuk memulai, buka try.openshift.com dan klik "Memulai".
2. Masuk ke akun Red Hat Anda (atau buat yang baru) dan ikuti instruksi untuk mengatur cluster pertama Anda.

Setelah instalasi berhasil, lihat tutorial OpenShift Training kami untuk mempelajari lebih lanjut tentang sistem dan konsep yang menjadikan platform OpenShift 4 alat yang sederhana dan nyaman untuk meluncurkan Kubernetes.

Dan pada konferensi DevOpsForum 2019 , salah satu pengembang OpenShift, Vadim Rutkovsky, akan mengadakan kelas master "Di sini Anda perlu mengubah seluruh sistem: memperbaiki cluster K8 yang rusak bersama-sama dengan tukang kunci bersertifikat" - itu akan memecah sepuluh cluster dan menunjukkan cara memperbaikinya.

Masuk ke konferensi dibayar, tetapi menggunakan kode promo #RedHat - diskon 37%.

Kami menunggu Anda pada 20 April di kelas master di Hall # 2 pukul 17:15, dan di gerai kami - sepanjang hari. Informasi produk yang berguna, pertemuan dengan para ahli, T-shirt, topi, stiker Red Hat - semuanya seperti biasa! :-)