Ini adalah postingan pertama dari serangkaian postingan tentang perubahan, peningkatan, dan penambahan dalam pembaruan platform Red Hat OpenShift 4.0 mendatang yang akan membantu Anda mempersiapkan transisi ke versi baru.
Sejak komunitas Kubernetes pertama kali berkumpul di kantor Google di Seattle pada musim gugur tahun 2014, sudah jelas bahwa proyek Kubernetes ditakdirkan untuk merevolusi cara perangkat lunak dikembangkan dan diterapkan saat ini. Pada saat yang sama, penyedia layanan cloud publik terus berinvestasi secara aktif dalam pengembangan infrastruktur dan layanan, yang membuat bekerja dengan TI dan membuat perangkat lunak menjadi lebih mudah dan mudah diakses, dan menjadikannya sangat mudah diakses, yang hanya sedikit orang yang bayangkan pada awalnya. dekade ini.
Tentu saja, pengumuman setiap layanan cloud baru disertai dengan banyak diskusi di antara para ahli di Twitter, dan perdebatan dilakukan mengenai berbagai topik - termasuk berakhirnya era open source, penurunan TI lokal, dan hal yang tidak dapat dihindari. tentang monopoli perangkat lunak baru di cloud, dan bagaimana paradigma baru X akan menggantikan semua paradigma lainnya.
Tentu saja, semua perselisihan ini sangat bodoh
Kenyataannya adalah tidak ada yang akan hilang, dan saat ini kita dapat melihat pertumbuhan eksponensial dalam produk akhir dan cara pengembangannya, karena terus bermunculannya perangkat lunak baru 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 masih akan menulis kode dengan kesalahan, insinyur operasi dan spesialis keandalan masih akan berkeliling dengan pager dan menerima peringatan otomatis di Slack, manajer akan tetap beroperasi dalam hal OpEx dan CapEx, dan setiap kali terjadi kegagalan, senior pengembang akan melakukannya. menghela nafas sedih dengan kata-kata: "Sudah kubilang"...
Ah, benarkah harus didiskusikan, adalah alat apa yang dapat kita miliki untuk menciptakan produk perangkat lunak yang lebih baik, dan bagaimana alat tersebut dapat meningkatkan keamanan serta membuat pengembangan lebih mudah dan andal. Ketika proyek menjadi lebih kompleks, risiko baru pun muncul, dan saat ini kehidupan masyarakat sangat bergantung pada perangkat lunak sehingga pengembang harus berusaha melakukan pekerjaan mereka dengan lebih baik.
Kubernetes adalah salah satu alat tersebut. Pekerjaan sedang dilakukan untuk menggabungkan Red Hat OpenShift dengan alat dan layanan lain ke dalam satu platform yang akan membuat perangkat lunak lebih andal, lebih mudah dikelola, dan lebih aman bagi pengguna.
Oleh karena itu, tim OpenShift menanyakan satu pertanyaan sederhana:
Bagaimana Anda bisa membuat bekerja dengan Kubernetes menjadi lebih mudah dan nyaman?
Jawabannya sangat jelas:
- mengotomatiskan aspek penerapan yang kompleks di cloud atau di luar cloud;
- fokus pada keandalan sambil menyembunyikan kompleksitas;
- terus berupaya merilis pembaruan yang sederhana dan aman;
- mencapai pengendalian dan auditabilitas;
- berusaha untuk memastikan keamanan yang tinggi pada awalnya, tetapi tidak dengan mengorbankan kegunaan.
Rilis OpenShift berikutnya harus mempertimbangkan pengalaman pembuatnya dan pengalaman pengembang lain yang mengimplementasikan perangkat lunak dalam skala besar di perusahaan terbesar di dunia. Selain itu, harus memperhitungkan seluruh akumulasi pengalaman ekosistem terbuka yang mendasari dunia modern saat ini. Pada saat yang sama, kita perlu meninggalkan mentalitas lama pengembang amatir dan beralih ke filosofi baru tentang masa depan otomatis. Perusahaan perlu menjembatani kesenjangan antara cara lama dan cara baru dalam menerapkan perangkat lunak, dan memanfaatkan sepenuhnya semua infrastruktur yang tersedia—baik yang dihosting oleh penyedia cloud terbesar atau dijalankan pada sistem kecil di edge.
Bagaimana cara mencapai hasil ini?
Di Red Hat, merupakan kebiasaan untuk melakukan pekerjaan yang membosankan dan tanpa pamrih dalam waktu lama untuk melestarikan komunitas yang sudah ada dan mencegah penutupan proyek yang melibatkan perusahaan. Komunitas sumber terbuka berisi sejumlah besar pengembang berbakat yang menciptakan hal-hal paling luar biasa - menghibur, mendidik, membuka peluang baru, dan sungguh indah, tetapi, tentu saja, tidak ada yang mengharapkan semua orang bergerak ke arah yang sama atau mengejar tujuan bersama. . Memanfaatkan energi ini dan mengarahkannya ke arah yang benar terkadang diperlukan untuk mengembangkan area yang dapat memberikan manfaat bagi pengguna kami, namun pada saat yang sama kami harus memantau perkembangan komunitas kami dan belajar dari mereka.
Pada awal tahun 2018, Red Hat mengakuisisi proyek CoreOS, yang memiliki pandangan serupa tentang masa depan - lebih aman dan andal, dibuat berdasarkan prinsip sumber terbuka. Perusahaan telah berupaya untuk lebih mengembangkan ide-ide ini dan menerapkannya, menerapkan filosofi kami - mencoba memastikan bahwa semua perangkat lunak berjalan dengan aman. Semua pekerjaan ini dibangun di Kubernetes, Linux, cloud publik, cloud pribadi, dan ribuan proyek lainnya yang mendukung ekosistem digital modern kita.
Rilis baru OpenShift 4 akan menjadi jelas, otomatis, dan lebih alami
Platform OpenShift akan bekerja dengan sistem operasi Linux terbaik dan paling andal, dengan dukungan perangkat keras bare-metal, virtualisasi yang nyaman, pemrograman infrastruktur otomatis dan, tentu saja, container (yang pada dasarnya hanyalah image Linux).
Platform harus aman sejak awal, namun tetap memungkinkan pengembang untuk melakukan iterasi dengan mudah—yaitu, cukup fleksibel dan aman sambil tetap memungkinkan administrator untuk mengaudit dan mengelolanya dengan mudah.
Hal ini harus memungkinkan perangkat lunak dijalankan “sebagai layanan” dan tidak menyebabkan pertumbuhan infrastruktur yang tidak terkendali bagi operator.
Ini akan memungkinkan pengembang untuk fokus menciptakan produk nyata bagi pengguna dan pelanggan. Anda tidak perlu melewati belantara pengaturan perangkat keras dan perangkat lunak, dan semua komplikasi yang tidak disengaja akan berlalu begitu saja.
OpenShift 4: Platform NoOps yang tidak memerlukan pemeliharaan
В menggambarkan tugas-tugas yang membantu membentuk visi perusahaan untuk OpenShift 4. Tujuan tim adalah menyederhanakan tugas sehari-hari dalam mengoperasikan dan memelihara perangkat lunak sebanyak mungkin, untuk membuat proses ini mudah dan santai - baik bagi spesialis yang terlibat dalam implementasi maupun bagi pengembang. Namun bagaimana Anda bisa lebih dekat dengan tujuan ini? Bagaimana cara membuat platform untuk menjalankan perangkat lunak yang memerlukan intervensi minimal? Apa arti NoOps dalam konteks ini?
Jika kita mencoba untuk mengabstraksikannya, maka bagi pengembang, konsep "tanpa server" atau "NoOps" berarti alat dan layanan yang memungkinkan Anda menyembunyikan komponen "operasional" atau meminimalkan beban ini bagi pengembang.
- Bekerja bukan dengan sistem, tetapi dengan antarmuka aplikasi (API).
- Jangan repot-repot menerapkan perangkat lunak - biarkan penyedia yang melakukannya untuk Anda.
- Jangan langsung membuat kerangka besar - mulailah dengan menulis bagian-bagian kecil yang akan bertindak sebagai "blok penyusun", cobalah membuat kode ini berfungsi dengan data dan peristiwa, dan bukan dengan disk dan database.
Tujuannya, seperti sebelumnya, adalah untuk mempercepat iterasi dalam pengembangan perangkat lunak, memberikan peluang untuk menciptakan produk yang lebih baik, dan agar pengembang tidak perlu khawatir tentang sistem yang menjalankan perangkat lunaknya. Pengembang berpengalaman sangat menyadari bahwa berfokus pada pengguna dapat dengan cepat mengubah gambarannya, jadi Anda tidak perlu terlalu berusaha keras dalam menulis perangkat lunak kecuali Anda benar-benar yakin itu diperlukan.
Bagi para profesional pemeliharaan dan pengoperasian, kata “NoOps” mungkin terdengar sedikit menakutkan. Namun ketika berkomunikasi dengan insinyur lapangan, menjadi jelas bahwa pola dan teknik yang mereka gunakan bertujuan untuk memastikan keandalan dan keandalan (Site Reliability Engineering, SRE) memiliki banyak kesamaan dengan pola yang dijelaskan di atas:
- Jangan mengelola sistem - otomatiskan proses manajemennya.
- Jangan mengimplementasikan perangkat lunak - buatlah saluran untuk menerapkannya.
- Hindari menggabungkan semua layanan Anda dan membiarkan kegagalan salah satu layanan menyebabkan keseluruhan sistem gagal—sebarkan layanan tersebut ke seluruh infrastruktur Anda menggunakan alat otomatisasi, dan hubungkan layanan tersebut dengan cara yang dapat dipantau dan dipantau.
SRE tahu bahwa ada sesuatu yang tidak beres dan mereka harus melacak dan memperbaiki masalahnya—sehingga mereka mengotomatiskan pekerjaan rutin dan menetapkan anggaran kesalahan terlebih dahulu sehingga mereka siap membuat prioritas dan mengambil keputusan ketika masalah muncul. .
Kubernetes di OpenShift adalah platform yang dirancang untuk memecahkan dua masalah utama: alih-alih memaksa Anda untuk memahami mesin virtual atau API penyeimbang beban, Kubernetes bekerja dengan abstraksi tingkat tinggi - proses penerapan dan layanan. Daripada menginstal agen perangkat lunak, Anda dapat menjalankan container, dan daripada menulis tumpukan pemantauan Anda sendiri, gunakan alat yang sudah tersedia di platform. Jadi, saus rahasia OpenShift 4 sebenarnya bukan rahasia - ini hanya masalah mengambil prinsip SRE dan konsep tanpa server dan membawanya ke kesimpulan logis untuk membantu pengembang dan insinyur operasi:
- Mengotomatiskan dan menstandarkan infrastruktur yang digunakan aplikasi
- Menghubungkan proses penerapan dan pengembangan secara bersamaan tanpa membatasi pengembang itu sendiri
- Memastikan bahwa peluncuran, audit, dan pengamanan layanan, fitur, aplikasi, atau seluruh tumpukan ke-XNUMX tidak lebih sulit dari yang pertama.
Namun apa perbedaan antara platform OpenShift 4 dan pendahulunya serta pendekatan “standar” untuk memecahkan masalah tersebut? Apa yang mendorong skala tim implementasi dan operasi? Karena raja dalam situasi ini adalah cluster. Jadi,
- Kami memastikan bahwa tujuan cluster jelas (Cloud yang terhormat, saya mengambil cluster ini karena saya bisa)
- Mesin dan sistem operasi ada untuk melayani cluster (Yang Mulia)
- Kelola status host dari cluster, minimalkan pembangunan kembali (drift).
- Untuk setiap elemen penting dari sistem, diperlukan pengasuh (mekanisme) yang akan memantau dan menghilangkan masalah
- Kegagalan *setiap* aspek atau elemen sistem dan mekanisme pemulihan terkait adalah bagian normal dari kehidupan
- Seluruh infrastruktur harus dikonfigurasi melalui API.
- Gunakan Kubernetes untuk menjalankan Kubernetes. (Ya, ya, itu bukan salah ketik)
- Pembaruan harus mudah dan tidak merepotkan untuk dipasang. Jika diperlukan lebih dari satu klik untuk menginstal pembaruan, jelas kami melakukan sesuatu yang salah.
- Memantau dan melakukan debug komponen apa pun seharusnya tidak menjadi masalah, oleh karena itu pelacakan dan pelaporan di seluruh infrastruktur juga harus mudah dan nyaman.
Ingin melihat kemampuan platform ini beraksi?
Versi pratinjau OpenShift 4 telah tersedia untuk pengembang. Dengan penginstal yang mudah digunakan, Anda dapat menjalankan klaster di AWS di atas Red Had CoreOS. Untuk menggunakan pratinjau, Anda hanya memerlukan akun AWS untuk menyediakan infrastruktur dan serangkaian akun untuk mengakses gambar pratinjau.
- Untuk memulai, buka dan klik "Memulai".
- Masuk ke akun Red Hat Anda (atau buat akun baru) dan ikuti instruksi untuk menyiapkan cluster pertama Anda.
Setelah instalasi berhasil, lihat tutorial kami untuk mendapatkan pemahaman lebih dalam tentang sistem dan konsep yang menjadikan platform OpenShift 4 cara yang mudah dan nyaman untuk menjalankan Kubernetes.
Coba rilis OpenShift baru dan bagikan pendapat Anda. Kami berkomitmen untuk menjadikan pekerjaan dengan Kumbernetes semudah dan semudah mungkin—masa depan NoOps dimulai hari ini.
Sekarang perhatian!
Di konferensi Pada tanggal 20 April, salah satu pengembang OpenShift, Vadim Rutkovsky, akan mengadakan kelas master - dia akan memecah sepuluh cluster dan memaksa mereka untuk memperbaikinya. Konferensi ini berbayar, tetapi dengan kode promosi #RedHat Anda mendapatkan diskon 37%.
Kelas master pada 17:15 - 18:15, dan stand buka sepanjang hari. T-shirt, topi, stiker - biasa saja!
Aula #2
“Di sini keseluruhan sistem perlu diubah: kami memperbaiki cluster k8s yang rusak bersama dengan mekanik bersertifikat.”
Sumber: www.habr.com