Maaf OpenShift, kami tidak cukup menghargai Anda dan tidak menerima begitu saja

Postingan ini ditulis karena karyawan kami memiliki cukup banyak percakapan dengan klien tentang pengembangan aplikasi di Kubernetes dan spesifikasi pengembangan tersebut di OpenShift.







Kami biasanya memulai dengan tesis bahwa Kubernetes hanyalah Kubernetes, dan OpenShift sudah menjadi platform Kubernetes, seperti Microsoft AKS atau Amazon EKS. Masing-masing platform ini memiliki keunggulannya sendiri, ditargetkan pada satu atau target audiens lainnya. Dan setelah itu, percakapan sudah mengalir ke perbandingan kekuatan dan kelemahan platform tertentu.



Secara umum, kami berpikir untuk menulis posting ini dengan kesimpulan seperti "Dengar, tidak masalah di mana harus menjalankan kode, di OpenShift atau di AKS, di EKS, di beberapa Kubernetes kustom, atau di Kubernetes apa pun (singkatnya, sebut saja KUK) sangat sederhana, baik di sana maupun di sana. "



Kemudian kami berencana untuk mengambil "Hello World" yang paling sederhana dan, dengan menggunakan contohnya, menunjukkan apa yang umum dan apa perbedaan antara KUK dan Red Hat OpenShift Container Platform (selanjutnya, OCP atau hanya OpenShift).



Namun, saat kami menulis posting ini, kami menyadari bahwa kami sudah terbiasa menggunakan OpenShift begitu lama dan begitu banyak sehingga kami tidak menyadari bagaimana itu telah tumbuh dan berubah menjadi platform luar biasa yang telah menjadi lebih dari sekedar distribusi Kubernetes. Kami terbiasa menerima kematangan dan kesederhanaan OpenShift begitu saja sementara kehilangan kecemerlangannya.



Secara umum, waktunya telah tiba untuk pertobatan aktif, dan sekarang kita akan selangkah demi selangkah membandingkan pelaksanaan "Hello World" kami di KUK dan OpenShift, dan kami akan melakukannya seobjektif mungkin (yah, mungkin, terkadang menunjukkan sikap pribadi terhadap subjek). Jika Anda tertarik dengan opini subjektif murni tentang masalah ini, Anda dapat membacanya di sini (ID) . Dalam posting ini, kami akan tetap berpegang pada fakta dan fakta saja.



Kluster



Jadi, "Hello World" membutuhkan cluster. Katakanlah "tidak" ke cloud publik apa pun segera agar tidak membayar server, register, jaringan, transfer data, dll. Karenanya, kami memilih cluster single-node sederhana di Minikube (untuk KUK) dan Code Ready Containers (untuk cluster OpenShift). Kedua opsi ini sangat mudah dipasang, tetapi akan membutuhkan cukup banyak sumber daya di laptop Anda.







Majelis di KUK-e



Jadi ayo pergi.



Langkah 1 - membangun gambar container kita



Saya akan mulai dengan menerapkan "Hello World" ke minikube. Ini akan membutuhkan:



  1. 1. Docker Terinstal.
  2. 2. Git yang diinstal.
  3. 3. Menginstal Maven (sebenarnya proyek ini menggunakan mvnw binary, jadi Anda bisa melakukannya tanpa itu).
  4. 4. Sebenarnya, sumber itu sendiri, yaitu klon dari repositori github.com/gcolman/quarkus-hello-world.git


Langkah pertama adalah membuat proyek Quarkus. Jangan khawatir jika Anda belum pernah bekerja dengan Quarkus.io - ini mudah. Anda cukup memilih komponen yang ingin Anda gunakan dalam proyek (RestEasy, Hibernate, Amazon SQS, Camel, dll.), Lalu Quarkus sendiri, tanpa partisipasi Anda, mengkonfigurasi arketipe maven dan mengunggah semuanya ke github. Artinya, secara harfiah satu klik mouse - dan Anda selesai. Itulah mengapa kami menyukai Quarkus.







Cara termudah untuk membangun "Hello World" menjadi image container adalah dengan menggunakan ekstensi Docker quarkus-maven, yang akan melakukan semua pekerjaan. Dengan munculnya Quarkus, ini menjadi sangat mudah dan sederhana: tambahkan ekstensi container-image-docker dan Anda dapat membuat gambar dengan perintah maven.



./mvnw quarkus:add-extension -Dextensions=โ€container-image-dockerโ€


Terakhir, kami membangun citra kami menggunakan Maven. Hasilnya, kode sumber kami berubah menjadi gambar container siap pakai yang sudah bisa diluncurkan di runtime container.







./mvnw -X clean package -Dquarkus.container-image.build=true


Faktanya, itu saja, sekarang Anda dapat memulai container dengan perintah jalankan buruh pelabuhan, setelah memetakan layanan kami ke port 8080 sehingga Anda dapat mengaksesnya.



docker run -i โ€” rm -p 8080:8080 gcolman/quarkus-hello-world








Setelah instance container dimulai, tetap hanya memeriksa dengan perintah curl bahwa layanan kami sedang berjalan:







Jadi semuanya bekerja dan itu sangat mudah dan sederhana.



Langkah 2 - mendorong container kita ke repositori gambar container



Sejauh ini, gambar yang telah kita buat disimpan secara lokal, di penyimpanan wadah lokal kita. Jika kita ingin menggunakan gambar ini di lingkungan KUK kita, maka itu harus dimasukkan ke dalam repositori lain. Kubernetes tidak memiliki fitur seperti itu, jadi kami akan menggunakan dockerhub. Karena, pertama, gratis, dan kedua, (hampir) semua orang melakukannya.



Ini juga sangat sederhana, dan Anda hanya memerlukan akun dockerhub.



Jadi, kami meletakkan dockerhub dan mengirim gambar kami ke sana.







Langkah 3 - meluncurkan Kubernetes



Ada banyak cara untuk menggabungkan konfigurasi kubernetes untuk menjalankan Hello World, tetapi kami akan menggunakan yang paling sederhana, kami adalah tipe orang seperti ini ...



Pertama, mulai klaster minikube:



minikube start


Langkah 4 - menerapkan gambar kontainer kami



Sekarang kita perlu mengubah kode dan image container kita dalam konfigurasi kubernetes. Dengan kata lain, kita memerlukan definisi pod dan penerapan dengan indikasi image container kita di dockerhub. Salah satu cara termudah untuk melakukannya adalah dengan menjalankan perintah create deployment yang mengarah ke gambar kita:







kubectl create deployment hello-quarkus โ€” image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT


Dengan perintah ini, kami memberi tahu KUK kami untuk membuat konfigurasi penerapan yang harus berisi spesifikasi pod untuk gambar container kami. Perintah ini juga akan menerapkan konfigurasi ini ke cluster minikube kami, dan membuat penerapan yang mendownload gambar container kami dan memulai pod di cluster.



Langkah 5 - buka akses ke layanan kami



Sekarang setelah kita memiliki image container yang diterapkan, saatnya memikirkan tentang cara mengonfigurasi akses eksternal ke layanan Restful ini, yang sebenarnya sudah diprogram dalam kode kita.



Ada banyak cara. Misalnya, Anda dapat menggunakan perintah expose untuk secara otomatis membuat komponen Kubernetes yang sesuai seperti layanan dan titik akhir. Sebenarnya, inilah yang akan kita lakukan dengan menjalankan perintah expose untuk objek penerapan kita:



kubectl expose deployment hello-quarkus โ€” type=NodePort โ€” port=8080


Mari kita bahas sejenak opsi "- type" dari perintah eksposur.



Ketika kami mengekspos dan membuat komponen yang diperlukan untuk menjalankan layanan kami, kami ingin, antara lain, dapat terhubung dari luar ke layanan hello-quarkus yang ada di dalam SDN kami. Dan parameter type memungkinkan kita membuat dan menghubungkan hal-hal seperti load balancer untuk merutekan lalu lintas ke jaringan itu.



Misalnya dengan menulis type = LoadBalancer, kami akan secara otomatis menginisialisasi load balancer di cloud publik untuk terhubung ke cluster Kubernetes kami. Ini, tentu saja, bagus, tetapi Anda perlu memahami bahwa konfigurasi seperti itu akan terikat secara kaku ke cloud publik tertentu dan akan lebih sulit untuk mentransfernya antara instance Kubernetes di lingkungan yang berbeda.



Dalam contoh kami, type = NodePort , yaitu panggilan ke layanan kami menggunakan alamat IP node dan nomor port. Opsi ini memungkinkan Anda untuk tidak menggunakan cloud publik apa pun, tetapi memerlukan sejumlah langkah tambahan. Pertama, Anda memerlukan penyeimbang beban Anda sendiri, jadi kami akan menerapkan penyeimbang beban NGINX di kluster kami.



Langkah 6 - Instal penyeimbang beban



Minikube memiliki sejumlah fungsi platform yang memudahkan pembuatan komponen yang diperlukan untuk akses eksternal, seperti pengontrol masuk. Minikube hadir dengan pengontrol masuk Nginx, dan kita hanya perlu mengaktifkannya dan mengkonfigurasinya.



minikube addons enable ingress


Sekarang, hanya dengan satu perintah, kita akan membuat pengontrol masuk Nginx yang akan bekerja di dalam klaster minikube kita:



ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m


Langkah 7 - Konfigurasi Ingress



Sekarang kita perlu mengonfigurasi pengontrol masuk Nginx untuk menerima permintaan hello-quarkus.











Akhirnya, kita perlu menerapkan konfigurasi ini.







kubectl apply -f ingress.yml








Karena kami melakukan semua ini di komputer kami, kami cukup menambahkan alamat IP node kami ke file / etc / hosts untuk mengarahkan permintaan http ke minikube kami ke penyeimbang beban NGINX.



192.168.99.100 hello-quarkus.info


Itu saja, sekarang layanan minikube kami dapat diakses dari luar melalui pengontrol masuk Nginx.







Nah, itu mudah, bukan? Atau tidak juga?









Luncurkan di OpenShift (Code Ready Containers)



Sekarang mari kita lihat bagaimana semuanya dilakukan di Red Hat OpenShift Container Platform (OCP).



Seperti minikube, kami memilih skema dengan cluster OpenShift node tunggal dalam bentuk Code Ready Containers (CRC). Dulu disebut minishift dan didasarkan pada proyek OpenShift Origin, tetapi sekarang ini adalah CRC dan dibangun di atas Platform Kontainer OpenShift Red Hat.



Di sini kami, maaf, tidak bisa tidak mengatakan: "OpenShift hebat!"



Awalnya, kami berpikir untuk menulis bahwa pengembangan di OpenShift tidak berbeda dengan pengembangan di Kubernetes. Dan ternyata memang begitu. Tetapi dalam proses menulis posting ini, kami ingat berapa banyak gerakan yang tidak perlu yang harus Anda lakukan ketika Anda tidak memiliki OpenShift, dan oleh karena itu, sekali lagi, ini luar biasa. Kami senang ketika semuanya mudah, dan betapa mudahnya dibandingkan dengan minikube, contoh kami diterapkan dan dijalankan di OpenShift, pada kenyataannya, yang mendorong kami untuk menulis posting ini.



Mari melalui prosesnya dan lihat apa yang perlu kita lakukan.



Jadi, dalam contoh minikube, kami mulai dengan Docker ... Hentikan, kami tidak lagi perlu menginstal Docker di mesin.



Dan kami tidak membutuhkan git lokal.

Dan Maven tidak dibutuhkan.

Dan Anda tidak perlu membuat gambar container dengan tangan Anda.

Dan tidak perlu mencari repositori gambar container apa pun.

Dan Anda tidak perlu memasang pengontrol masuk.

Dan Anda juga tidak perlu mengonfigurasi masuknya.




Anda mengerti, bukan? Anda tidak memerlukan semua hal di atas untuk menerapkan dan menjalankan aplikasi kami di OpenShift. Dan prosesnya sendiri terlihat seperti ini.



Langkah 1 - Meluncurkan OpenShift Cluster Anda



Kami menggunakan Code Ready Containers dari Red Hat, yang pada dasarnya adalah Minikube yang sama, tetapi hanya dengan cluster Openshift node tunggal yang lengkap.



crc start


Langkah 2 - Bangun dan Terapkan Aplikasi ke OpenShift Cluster



Pada langkah inilah kesederhanaan dan kenyamanan OpenShift terwujud dalam segala kemuliaannya. Seperti semua distribusi Kubernetes, kami memiliki banyak cara untuk menjalankan aplikasi pada sebuah cluster. Dan, seperti halnya KUK, sengaja kami pilih yang paling sederhana.



OpenShift selalu dibangun sebagai platform untuk membangun dan menjalankan aplikasi dalam container. Membangun container selalu menjadi bagian integral dari platform ini, jadi ada banyak resource Kubernetes tambahan untuk tugas terkait.



Kami akan menggunakan proses OpenShift Source 2 Image (S2I), yang memiliki beberapa cara berbeda untuk mengambil sumber kami (kode atau binari) dan mengubahnya menjadi gambar kontainer yang berjalan pada cluster OpenShift.



Untuk ini kita membutuhkan dua hal:



  • Kode sumber kami di repositori git
  • Gambar builder, berdasarkan build yang akan dilakukan.


Ada banyak gambar di luar sana, baik yang dikelola oleh Red Hat maupun komunitas, dan kami akan menggunakan gambar OpenJDK, karena saya sedang membangun aplikasi Java.



Anda dapat memulai S2I build baik dari konsol grafis OpenShift Developer maupun dari baris perintah. Kami akan menggunakan perintah aplikasi baru untuk memberi tahu di mana mendapatkan gambar pembuat dan kode sumber kami.







oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git


Itu saja, aplikasi kami telah dibuat. Dalam melakukannya, proses S2I melakukan hal-hal berikut:



  • Membuat pod build layanan untuk semua hal yang terkait dengan pembuatan aplikasi.
  • Membuat konfigurasi OpenShift Build.
  • Mengunduh gambar pembuat ke registri buruh pelabuhan internal OpenShift.
  • Menggandakan "Hello World" ke repositori lokal.
  • Melihat ada pom maven di sana dan menyusun aplikasi dengan maven.
  • Membuat gambar container baru yang berisi aplikasi Java yang telah dikompilasi dan memasukkan gambar tersebut ke registry container internal.
  • Membuat Deployment Kubernetes dengan spesifikasi pod, layanan, dll.
  • Meluncurkan penerapan gambar container.
  • Layanan build-pod telah dihapus.


Ada banyak hal dalam daftar ini, tetapi yang utama adalah semua build berlangsung secara eksklusif di dalam OpenShift, registri Docker internal ada di dalam OpenShift, dan proses build membuat semua komponen Kubernetes dan menjalankannya di cluster.



Jika Anda melacak peluncuran S2I secara visual di konsol, Anda dapat melihat bagaimana pod build diluncurkan selama build.







Sekarang mari kita lihat log dari builder pod: pertama, ini menunjukkan bagaimana maven bekerja dan mendownload dependensi untuk membangun aplikasi java kita.







Setelah build maven selesai, build image container akan dimulai, lalu gambar yang dibuat ini dikirim ke repositori internal.







Itu saja, proses perakitannya selesai. Sekarang pastikan pod dan layanan aplikasi kita berjalan di cluster.



oc get service








Itu saja. Dan hanya satu tim. Kami hanya perlu mengekspos layanan ini untuk akses eksternal.



Langkah 3 - paparkan layanan untuk akses eksternal



Seperti dalam kasus KUK, pada platform OpenShift, "Hello World" kami juga membutuhkan router untuk mengarahkan lalu lintas eksternal ke layanan di dalam cluster. OpenShift membuatnya sangat mudah. Pertama, komponen perutean HAProxy diinstal di cluster secara default (Anda dapat mengubahnya ke NGINX yang sama). Kedua, ada sumber daya khusus dan sangat dapat disesuaikan yang disebut Routes, yang menyerupai objek Ingress di Kubernetes lama yang baik (pada kenyataannya, Rute OpenShift sangat memengaruhi desain objek Ingress, yang sekarang dapat digunakan di OpenShift) , tetapi untuk "Hello World" kami, dan di hampir semua kasus lainnya, Route standar tanpa konfigurasi tambahan sudah cukup bagi kami.



Untuk membuat FQDN yang dapat dirutekan untuk "Hello World" (ya, OpenShiift memiliki DNS sendiri untuk perutean berdasarkan nama layanan), kami cukup mengekspos layanan kami:







oc expose service quarkus-hello-world


Jika Anda melihat Route yang baru dibuat, Anda dapat menemukan FQDN dan informasi perutean lainnya di sana:



oc get route








Terakhir, kami mengakses layanan kami dari browser:







Sekarang sangat mudah!



Kami menyukai Kubernetes dan segala hal yang dimungkinkan oleh teknologi untuk kami lakukan, dan kami juga menyukai kesederhanaan dan cahaya. Kubernetes dibuat untuk membuatnya sangat mudah untuk mengoperasikan container yang terdistribusi dan dapat diskalakan, tetapi kesederhanaannya tidak lagi cukup untuk meluncurkan aplikasi. Dan di sinilah OpenShift berperan, yang mengikuti perkembangan waktu dan menawarkan Kubernetes, yang difokuskan terutama pada pengembang. Banyak upaya telah diinvestasikan untuk menyesuaikan platform OpenShift khusus untuk pengembang, termasuk pembuatan alat seperti S2I, ODI, Portal Pengembang, Kerangka Kerja Operator OpenShift, integrasi IDE, Katalog Pengembang, integrasi Helm, pemantauan, dan banyak lainnya.



Semoga artikel ini menarik dan bermanfaat untuk Anda. Dan untuk menemukan sumber daya tambahan, materi, dan hal berguna lainnya untuk pengembangan di platform OpenShift, kunjungi portal Red Hat Developers .



All Articles