Postingan ini ditulis karena karyawan kami cukup banyak berdiskusi dengan klien tentang pengembangan aplikasi di Kubernetes dan spesifik 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 masing-masing, ditujukan untuk target audiens tertentu. Dan setelah ini, pembicaraan beralih ke membandingkan kekuatan dan kelemahan platform tertentu.
Secara umum, kami berpikir untuk menulis postingan ini dengan kesimpulan seperti “Dengar, tidak masalah di mana menjalankan kode, di OpenShift atau di AKS, di EKS, di beberapa Kubernet khusus, atau di Kubernetes apa pun. (untuk singkatnya sebut saja KUK) “Ini sangat sederhana, baik di sana maupun di sana.”
Kemudian kami berencana untuk mengambil “Hello World” yang paling sederhana dan menggunakan contohnya untuk menunjukkan kesamaan dan perbedaan antara KUC dan Red Hat OpenShift Container Platform (selanjutnya disebut OCP atau OpenShift saja).
Namun, saat kami menulis postingan ini, kami menyadari bahwa kami sudah begitu lama menggunakan OpenShift sehingga kami tidak menyadari bagaimana OpenShift telah berkembang dan berubah menjadi platform luar biasa yang menjadi lebih dari sekadar distribusi Kubernetes. Kita cenderung meremehkan kedewasaan dan kesederhanaan OpenShift, dan melupakan kecemerlangannya.
Secara umum, waktunya telah tiba untuk pertobatan aktif, dan sekarang kami akan selangkah demi selangkah membandingkan pelaksanaan “Hello World” kami di KUK dan OpenShift, dan kami akan melakukannya seobjektif mungkin (yah, kecuali terkadang dengan menunjukkan a sikap pribadi terhadap subjek). Jika Anda tertarik dengan opini subjektif murni tentang masalah ini, Anda dapat membacanya . Dan dalam postingan kali ini kami akan tetap berpegang pada fakta dan hanya fakta saja.
Cluster
Jadi, “Hello World” kita memerlukan cluster. Kami akan segera mengatakan "tidak" pada cloud publik mana pun, agar tidak membayar untuk server, registry, jaringan, transfer data, dll. Oleh karena itu, kami memilih cluster node tunggal yang sederhana (untuk KUK) dan (untuk kluster OpenShift). Kedua opsi ini sangat mudah untuk diinstal, namun akan membutuhkan resource yang cukup besar di laptop Anda.
Majelis di KUK-e
Jadi ayo pergi.
Langkah 1 – membangun image container kita
Mari kita mulai dengan menerapkan “Hello World” ke minikube. Untuk melakukan ini, Anda memerlukan:
- 1. Docker terinstal.
- 2. Git terinstal.
- 3. Menginstal Maven (sebenarnya, proyek ini menggunakan biner mvnw, jadi Anda dapat melakukannya tanpanya).
- 4. Sebenarnya sumber itu sendiri, yaitu. klon repositori
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, mengonfigurasi arketipe maven dan meletakkan semuanya di github. Artinya, satu klik mouse dan selesai. Inilah mengapa kami menyukai Quarkus.
Cara termudah untuk membuat "Hello World" menjadi image container adalah dengan menggunakan ekstensi quarkus-maven untuk Docker, yang akan melakukan semua pekerjaan yang diperlukan. Dengan munculnya Quarkus, ini menjadi sangat mudah dan sederhana: tambahkan ekstensi container-image-docker dan Anda dapat membuat gambar menggunakan perintah maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Terakhir, kami membangun image kami menggunakan Maven. Hasilnya, kode sumber kami berubah menjadi image container siap pakai yang sudah dapat dijalankan di lingkungan runtime container.
./mvnw -X clean package -Dquarkus.container-image.build=true
Itu saja, sekarang Anda dapat memulai container dengan perintah docker run, memetakan layanan kami ke port 8080 sehingga dapat diakses.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Setelah instance container dimulai, yang tersisa hanyalah memeriksa dengan perintah curl apakah layanan kami sedang berjalan:
Jadi semuanya berfungsi dan itu sangat mudah dan sederhana.
Langkah 2 – kirim container kita ke repositori image container
Untuk saat ini, gambar yang kami buat disimpan secara lokal, di penyimpanan kontainer lokal kami. Jika kita ingin menggunakan gambar ini di lingkungan COOK kita, maka gambar tersebut harus ditempatkan di beberapa repositori lain. Kubernetes tidak memiliki fitur seperti itu, jadi kami akan menggunakan dockerhub. Sebab, pertama, gratis, dan kedua, (hampir) semua orang melakukannya.
Ini juga sangat sederhana, dan yang Anda perlukan hanyalah akun dockerhub.
Jadi, kami menginstal dockerhub dan mengirimkan gambar kami ke sana.
Langkah 3 – luncurkan Kubernetes
Ada banyak cara untuk merakit konfigurasi kubernetes untuk menjalankan "Hello World" kami, tapi kami akan menggunakan yang paling sederhana, begitulah...
Pertama, mari kita luncurkan cluster minikube:
minikube start
Langkah 4 – terapkan image container kami
Sekarang kita perlu mengubah kode dan gambar container menjadi konfigurasi kubernetes. Dengan kata lain, kita memerlukan definisi pod dan penerapan yang menunjuk ke image container kita di dockerhub. Salah satu cara termudah untuk melakukan ini adalah dengan menjalankan perintah buat penerapan yang menunjuk ke gambar kita:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Dengan perintah ini kami memberi tahu COO kami untuk membuat konfigurasi penerapan, yang harus berisi spesifikasi pod untuk image container kami. Perintah ini juga akan menerapkan konfigurasi ini ke cluster minikube kami, dan membuat penerapan yang akan mendownload image container kami dan meluncurkan pod di cluster.
Langkah 5 – buka akses ke layanan kami
Sekarang setelah kita memiliki image container yang diterapkan, sekarang saatnya memikirkan cara mengonfigurasi akses eksternal ke layanan Restful ini, yang sebenarnya diprogram dalam kode kita.
Ada banyak cara di sini. Misalnya, Anda dapat menggunakan perintah mengekspos untuk secara otomatis membuat komponen Kubernetes yang sesuai, seperti layanan dan titik akhir. Sebenarnya, inilah yang akan kita lakukan dengan menjalankan perintah mengekspos objek penerapan kita:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Mari luangkan waktu sejenak untuk melihat opsi "-type" pada perintah mengekspos.
Saat kami mengekspos dan membuat komponen yang diperlukan untuk menjalankan layanan kami, kami, antara lain, harus dapat terhubung dari luar ke layanan hello-quarkus, yang berada di dalam jaringan yang ditentukan perangkat lunak kami. Dan parameter mengetik memungkinkan kami membuat dan menghubungkan hal-hal seperti penyeimbang beban untuk merutekan lalu lintas ke jaringan ini.
Misalnya dengan menulis ketik=LoadBalancer, kami secara otomatis menyediakan penyeimbang beban di cloud publik untuk terhubung ke cluster Kubernetes kami. Ini tentu saja bagus, tetapi Anda perlu memahami bahwa konfigurasi seperti itu akan terikat secara ketat pada cloud publik tertentu dan akan lebih sulit untuk ditransfer antar instance Kubernetes di lingkungan yang berbeda.
Dalam contoh kami ketik=NodePort, yaitu, layanan kami diakses berdasarkan 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 cluster kami.
Langkah 6 – instal penyeimbang beban
minikube memiliki sejumlah fungsi platform yang memudahkan pembuatan komponen yang dapat diakses secara eksternal, seperti pengontrol ingress. Minikube dibundel dengan pengontrol ingress Nginx, dan yang harus kita lakukan hanyalah mengaktifkan dan mengkonfigurasinya.
minikube addons enable ingress
Sekarang kita akan membuat pengontrol ingress Nginx hanya dengan satu perintah, yang akan bekerja di dalam cluster minikube kita:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Langkah 7 – Menyiapkan masuknya
Sekarang kita perlu mengkonfigurasi pengontrol ingress Nginx agar menerima permintaan hello-quarkus.
Dan terakhir, kita perlu menerapkan konfigurasi ini.
kubectl apply -f ingress.yml
Karena kita melakukan semua ini di komputer kita sendiri, kita cukup menambahkan alamat IP node kita ke file /etc/ host untuk merutekan permintaan http ke minikube kita ke penyeimbang beban NGINX.
192.168.99.100 hello-quarkus.info
Itu saja, sekarang layanan minikube kami dapat diakses secara eksternal melalui pengontrol ingress Nginx.
Ya, itu mudah, bukan? Atau tidak terlalu banyak?
Berjalan di OpenShift (Kontainer Siap Kode)
Sekarang mari kita lihat bagaimana semua ini dilakukan pada Red Hat OpenShift Container Platform (OCP).
Seperti halnya minikube, kami memilih desain cluster OpenShift node tunggal dalam bentuk Code Ready Containers (CRC). Sebelumnya disebut minishift dan didasarkan pada proyek OpenShift Origin, namun sekarang menjadi CRC dan dibangun di atas Platform OpenShift Container Red Hat.
Di sini, maaf, kami tidak bisa tidak berkata: “OpenShift luar biasa!”
Awalnya kami berpikir untuk menulis bahwa pengembangan di OpenShift tidak berbeda dengan pengembangan di Kubernetes. Dan pada hakikatnya memang demikianlah adanya. Namun dalam proses penulisan postingan ini, kami mengingat berapa banyak gerakan ekstra yang harus Anda lakukan saat Anda tidak memiliki OpenShift, dan itulah alasannya, sekali lagi, ini luar biasa. Kami senang ketika semuanya dilakukan dengan mudah, dan betapa mudahnya contoh kami diterapkan dan dijalankan di OpenShift dibandingkan dengan minikube, itulah yang mendorong kami untuk menulis postingan ini.
Mari kita jalani prosesnya dan lihat apa yang perlu kita lakukan.
Jadi, dalam contoh minikube, kita mulai dengan Docker... Tunggu, kita tidak perlu lagi menginstal Docker di mesin.
Dan kita tidak membutuhkan git lokal.
Dan Maven tidak diperlukan.
Dan Anda tidak perlu membuat gambar container dengan tangan Anda.
Dan Anda tidak perlu mencari tempat penyimpanan gambar container apa pun.
Dan tidak perlu memasang pengontrol ingress.
Dan Anda juga tidak perlu mengonfigurasi ingress.
Anda mengerti, kan? Untuk menerapkan dan menjalankan aplikasi kami di OpenShift, Anda tidak memerlukan hal-hal di atas. Dan prosesnya sendiri terlihat seperti ini.
Langkah 1 – Luncurkan klaster OpenShift Anda
Kami menggunakan Code Ready Containers dari Red Hat, yang pada dasarnya adalah Minikube yang sama, tetapi hanya dengan cluster Openshift single-node yang lengkap.
crc start
Langkah 2 – Bangun dan terapkan aplikasi ke cluster OpenShift
Pada langkah inilah kesederhanaan dan kenyamanan OpenShift terungkap dengan segala kemegahannya. Seperti halnya semua distribusi Kubernetes, kami memiliki banyak cara untuk menjalankan aplikasi dalam sebuah cluster. Dan, seperti halnya KUK, kami secara khusus memilih yang paling sederhana.
OpenShift selalu dibangun sebagai platform untuk membuat dan menjalankan aplikasi dalam container. Pembuatan container selalu menjadi bagian integral dari platform ini, jadi ada banyak sumber daya tambahan Kubernetes untuk tugas-tugas terkait.
Kami akan menggunakan proses Gambar Sumber 2 (S2I) OpenShift, yang memiliki beberapa cara berbeda untuk mengambil sumber kami (kode atau binari) dan mengubahnya menjadi gambar dalam container yang berjalan pada cluster OpenShift.
Untuk melakukan ini kita memerlukan dua hal:
- Kode sumber kami ada di repositori git
- Gambar pembangun yang menjadi dasar pembuatannya akan dilakukan.
Ada banyak gambar seperti itu yang dikelola baik oleh Red Hat maupun di tingkat komunitas, dan kami akan menggunakan gambar OpenJDK, karena saya sedang membangun aplikasi Java.
Anda dapat menjalankan build S2I dari konsol grafis OpenShift Developer dan dari baris perintah. Kami akan menggunakan perintah aplikasi baru, 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 kita telah dibuat. Dalam melakukannya, proses S2I melakukan hal-hal berikut:
- Membuat pod build layanan untuk segala hal yang terkait dengan pembuatan aplikasi.
- Membuat konfigurasi OpenShift Build.
- Saya mengunduh gambar pembuat ke registri buruh pelabuhan OpenShift internal.
- Mengkloning "Hello World" ke repositori lokal.
- Saya melihat ada maven pom disana, jadi saya kompilasi aplikasinya menggunakan maven.
- Membuat gambar kontainer baru yang berisi aplikasi Java yang dikompilasi dan memasukkan gambar ini ke dalam registri kontainer internal.
- Membuat Deployment Kubernetes dengan spesifikasi untuk pod, layanan, dll.
- Saya mulai menerapkan gambar kontainer.
- Menghapus pod build layanan.
Ada banyak hal dalam daftar ini, tetapi yang terpenting adalah keseluruhan build terjadi 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 memantau peluncuran S2I secara visual di konsol, Anda dapat melihat bagaimana pod build diluncurkan saat build selesai.
Sekarang mari kita lihat log pod pembuat: pertama, ini menunjukkan bagaimana maven melakukan tugasnya dan mengunduh dependensi untuk membangun aplikasi java kita.
Setelah pembangunan maven selesai, pembangunan gambar kontainer dimulai, dan kemudian gambar yang dibangun ini dikirim ke repositori internal.
Selesai, proses build selesai. Sekarang mari kita pastikan bahwa pod dan layanan aplikasi kita berjalan di cluster.
oc get service
Itu saja. Dan hanya satu tim. Yang harus kita lakukan adalah mengekspos layanan ini untuk akses dari luar.
Langkah 3 – mengekspos layanan untuk akses dari luar
Seperti halnya KUC, pada platform OpenShift, “Hello World” kami juga memerlukan router untuk mengarahkan lalu lintas eksternal ke layanan di dalam cluster. OpenShift membuat ini sangat mudah. Pertama, komponen perutean HAProxy diinstal di cluster secara default (dapat diubah ke NGINX yang sama). Kedua, ada sumber daya khusus dan sangat dapat disesuaikan yang disebut Routes dan mirip dengan objek Ingress di Kubernetes lama yang bagus (sebenarnya, Routes 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 sudah cukup bagi kami tanpa konfigurasi tambahan.
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
Dan terakhir, kami mengakses layanan kami dari browser:
Tapi sekarang semuanya sangat mudah!
Kami menyukai Kubernetes dan segala sesuatu yang dimungkinkan oleh teknologi ini, dan kami juga menyukai kesederhanaan dan kemudahannya. Kubernetes diciptakan untuk menyederhanakan pengoperasian container yang terdistribusi dan dapat diskalakan, namun kesederhanaannya tidak lagi cukup untuk memasukkan aplikasi ke dalam produksi saat ini. Di sinilah OpenShift berperan, mengikuti perkembangan zaman dan menawarkan Kubernetes, yang ditujukan terutama untuk pengembang. Banyak upaya telah diinvestasikan untuk menyesuaikan platform OpenShift khusus untuk pengembang, termasuk pembuatan alat seperti S2I, ODI, Portal Pengembang, Kerangka Operator OpenShift, integrasi IDE, Katalog Pengembang, integrasi Helm, pemantauan dan banyak lainnya.
Kami harap artikel ini menarik dan bermanfaat bagi Anda. Anda dapat menemukan sumber daya tambahan, materi, dan hal-hal lain yang berguna untuk pengembangan platform OpenShift di portal .
Sumber: www.habr.com