Siaran ini ditulis kerana pekerja kami mempunyai banyak perbualan dengan pelanggan tentang pembangunan aplikasi pada Kubernetes dan butiran pembangunan sedemikian pada OpenShift.
Kami biasanya bermula dengan tesis bahawa Kubernetes hanyalah Kubernetes, dan OpenShift sudah pun menjadi platform Kubernetes, seperti Microsoft AKS atau Amazon EKS. Setiap platform ini mempunyai kelebihan tersendiri, ditujukan kepada khalayak sasaran tertentu. Dan selepas ini, perbualan bertukar kepada membandingkan kekuatan dan kelemahan platform tertentu.
Secara umum, kami terfikir untuk menulis siaran ini dengan kesimpulan seperti "Dengar, tidak kira di mana untuk menjalankan kod, pada OpenShift atau pada AKS, pada EKS, pada beberapa Kubernetes tersuai, atau pada apa sahaja Kubernetes (untuk ringkasnya kita panggil KUK) "Ia sangat mudah, di sana dan di sana."
Kemudian kami merancang untuk menggunakan "Hello World" yang paling mudah dan menggunakan contohnya untuk menunjukkan perkara biasa dan apakah perbezaan antara KUC dan Platform Kontena OpenShift Red Hat (selepas ini, OCP atau ringkasnya OpenShift).
Walau bagaimanapun, semasa kami menulis siaran ini, kami menyedari bahawa kami telah terbiasa menggunakan OpenShift untuk sekian lama sehingga kami langsung tidak menyedari bagaimana ia telah berkembang dan bertukar menjadi platform yang menakjubkan yang menjadi lebih daripada sekadar pengedaran Kubernetes. Kami cenderung untuk mengambil mudah kematangan dan kesederhanaan OpenShift, dan melupakan kecemerlangannya.
Secara umum, masanya telah tiba untuk bertaubat secara aktif, dan sekarang kami akan membandingkan langkah demi langkah pentauliahan "Hello World" kami pada KUK dan OpenShift, dan kami akan melakukan ini seobjektif mungkin (baik, kecuali dengan kadang-kadang menunjukkan sikap peribadi terhadap subjek). Jika anda berminat dengan pendapat subjektif semata-mata mengenai isu ini, anda boleh membacanya . Dan dalam entri ini kami akan berpegang kepada fakta dan hanya fakta.
Kelompok
Jadi, "Hello World" kami memerlukan kelompok. Kami akan segera mengatakan "tidak" kepada mana-mana awan awam, supaya tidak membayar untuk pelayan, pendaftaran, rangkaian, pemindahan data, dsb. Sehubungan itu, kami memilih kluster nod tunggal yang mudah dihidupkan (untuk KUK) dan (untuk kluster OpenShift). Kedua-dua pilihan ini sangat mudah untuk dipasang, tetapi memerlukan banyak sumber pada komputer riba anda.
Perhimpunan di KUK-e
Jadi mari kita pergi.
Langkah 1 β membina imej kontena kami
Mari mulakan dengan menggunakan "Hello World" kami ke minikube. Untuk melakukan ini, anda memerlukan:
- 1. Docker dipasang.
- 2. Git dipasang.
- 3. Memasang Maven (sebenarnya, projek ini menggunakan binari mvnw, jadi anda boleh melakukannya tanpanya).
- 4. Sebenarnya, sumber itu sendiri, iaitu. klon repositori
Langkah pertama ialah membuat projek Quarkus. Jangan risau jika anda tidak pernah bekerja dengan Quarkus.io - ianya mudah. Anda hanya pilih komponen yang ingin anda gunakan dalam projek (RestEasy, Hibernate, Amazon SQS, Camel, dll.), dan kemudian Quarkus sendiri, tanpa sebarang penyertaan anda, mengkonfigurasi archetype maven dan meletakkan segala-galanya pada github. Iaitu, secara literal satu klik tetikus dan anda sudah selesai. Itulah sebabnya kami suka Quarkus.
Cara paling mudah untuk membina "Hello World" kami ke dalam imej bekas adalah dengan menggunakan sambungan quarkus-maven untuk Docker, yang akan melakukan semua kerja yang diperlukan. Dengan kemunculan Quarkus, ini telah menjadi sangat mudah dan mudah: tambahkan sambungan container-image-docker dan anda boleh mencipta imej menggunakan arahan maven.
./mvnw quarkus:add-extension -Dextensions=βcontainer-image-dockerβ
Akhirnya, kami membina imej kami menggunakan Maven. Akibatnya, kod sumber kami bertukar menjadi imej bekas siap sedia yang sudah boleh dijalankan dalam persekitaran masa jalan kontena.
./mvnw -X clean package -Dquarkus.container-image.build=true
Itu sahaja, kini anda boleh memulakan bekas dengan arahan docker run, memetakan perkhidmatan kami ke port 8080 supaya ia boleh diakses.
docker run -i β rm -p 8080:8080 gcolman/quarkus-hello-world
Selepas contoh kontena dimulakan, yang tinggal hanyalah menyemak dengan arahan curl bahawa perkhidmatan kami sedang dijalankan:
Jadi semuanya berfungsi dan ia sangat mudah dan ringkas.
Langkah 2 β hantar bekas kami ke repositori imej bekas
Buat masa ini, imej yang kami buat disimpan secara tempatan, dalam storan kontena tempatan kami. Jika kami ingin menggunakan imej ini dalam persekitaran COOK kami, maka ia mesti diletakkan di beberapa repositori lain. Kubernetes tidak mempunyai ciri sedemikian, jadi kami akan menggunakan dockerhub. Kerana, pertama, ia percuma, dan kedua, (hampir) semua orang melakukannya.
Ini juga sangat mudah, dan anda hanya perlukan akaun dockerhub.
Jadi, kami memasang dockerhub dan menghantar imej kami ke sana.
Langkah 3 β lancarkan Kubernetes
Terdapat banyak cara untuk memasang konfigurasi kubernetes untuk menjalankan "Hello World" kami, tetapi kami akan menggunakan yang paling mudah, itulah cara kami...
Mula-mula, mari lancarkan kluster minikube:
minikube start
Langkah 4 β gunakan imej kontena kami
Sekarang kita perlu menukar kod dan imej bekas kita kepada konfigurasi kubernetes. Dalam erti kata lain, kami memerlukan definisi pod dan penempatan yang menunjuk kepada imej kontena kami di dockerhub. Salah satu cara paling mudah untuk melakukan ini ialah menjalankan arahan penggunaan cipta yang menunjuk ke imej kami:
kubectl create deployment hello-quarkus β image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Dengan arahan ini, kami memberitahu COO kami untuk membuat konfigurasi penempatan, yang harus mengandungi spesifikasi pod untuk imej kontena kami. Perintah ini juga akan menggunakan konfigurasi ini pada kluster minikube kami, dan membuat penempatan yang akan memuat turun imej bekas kami dan melancarkan pod dalam kluster.
Langkah 5 β buka akses kepada perkhidmatan kami
Memandangkan kami mempunyai imej kontena yang digunakan, tiba masanya untuk memikirkan cara mengkonfigurasi akses luaran kepada perkhidmatan Restful ini, yang sebenarnya, diprogramkan dalam kod kami.
Terdapat banyak cara di sini. Contohnya, anda boleh menggunakan perintah expose untuk mencipta komponen Kubernetes yang sesuai secara automatik, seperti perkhidmatan dan titik akhir. Sebenarnya, inilah yang akan kami lakukan dengan melaksanakan perintah expose untuk objek penempatan kami:
kubectl expose deployment hello-quarkus β type=NodePort β port=8080
Mari kita luangkan sedikit masa untuk melihat pilihan "-type" pada arahan expose.
Apabila kami mendedahkan dan mencipta komponen yang diperlukan untuk menjalankan perkhidmatan kami, kami, antara lain, perlu dapat menyambung dari luar ke perkhidmatan hello-quarkus, yang terletak di dalam rangkaian yang ditentukan perisian kami. Dan parameter jenis membolehkan kami membuat dan menyambungkan perkara seperti pengimbang beban untuk menghalakan trafik ke rangkaian ini.
Contohnya dengan menulis type=LoadBalancer, kami menyediakan pengimbang beban secara automatik dalam awan awam untuk menyambung ke gugusan Kubernetes kami. Ini, sudah tentu, bagus, tetapi anda perlu memahami bahawa konfigurasi sedemikian akan terikat dengan ketat pada awan awam tertentu dan akan menjadi lebih sukar untuk dipindahkan antara contoh Kubernetes dalam persekitaran yang berbeza.
Dalam contoh kita jenis=NodePort, iaitu perkhidmatan kami diakses oleh alamat IP dan nombor port nod. Pilihan ini membolehkan anda untuk tidak menggunakan sebarang awan awam, tetapi memerlukan beberapa langkah tambahan. Pertama, anda memerlukan pengimbang beban anda sendiri, jadi kami akan menggunakan pengimbang beban NGINX dalam kelompok kami.
Langkah 6 β pasang pengimbang beban
minikube mempunyai beberapa fungsi platform yang memudahkan untuk mencipta komponen yang boleh diakses secara luaran, seperti pengawal kemasukan. Minikube disertakan dengan pengawal kemasukan Nginx, dan apa yang perlu kita lakukan ialah mendayakannya dan mengkonfigurasinya.
minikube addons enable ingress
Sekarang kami akan mencipta pengawal kemasukan Nginx dengan hanya satu arahan, yang akan berfungsi di dalam kluster minikube kami:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Langkah 7 β Menyediakan kemasukan
Sekarang kita perlu mengkonfigurasi pengawal kemasukan Nginx supaya ia menerima permintaan hello-quarkus.
Dan akhirnya, kita perlu menggunakan konfigurasi ini.
kubectl apply -f ingress.yml
Memandangkan kami melakukan semua ini pada komputer kami sendiri, kami hanya menambah alamat IP nod kami ke fail hos /etc/ untuk menghalakan permintaan http ke minikube kami ke pengimbang beban NGINX.
192.168.99.100 hello-quarkus.info
Itu sahaja, kini perkhidmatan minikube kami boleh diakses secara luaran melalui pengawal kemasukan Nginx.
Nah, itu mudah, bukan? Atau tidak begitu?
Berjalan pada OpenShift (Bekas Sedia Kod)
Sekarang mari kita lihat bagaimana semua ini dilakukan pada Red Hat OpenShift Container Platform (OCP).
Seperti minikube, kami memilih reka bentuk kluster OpenShift nod tunggal dalam bentuk Bekas Sedia Kod (CRC). Sebelum ini, ia dipanggil minishift dan berdasarkan projek OpenShift Origin, tetapi kini ia adalah CRC dan dibina di atas Platform Kontena OpenShift Red Hat.
Di sini kami, maaf, tidak boleh tidak berkata: "OpenShift hebat!"
Pada mulanya, kami berfikir untuk menulis bahawa pembangunan pada OpenShift tidak berbeza daripada pembangunan pada Kubernetes. Dan pada dasarnya beginilah keadaannya. Tetapi dalam proses menulis siaran ini, kami teringat berapa banyak pergerakan tambahan yang perlu anda lakukan apabila anda tidak mempunyai OpenShift, dan itulah sebabnya, sekali lagi, ia sangat bagus. Kami menyukainya apabila segala-galanya dilakukan dengan mudah, dan betapa mudahnya contoh kami untuk digunakan dan dijalankan pada OpenShift berbanding dengan minikube itulah yang mendorong kami untuk menulis siaran ini.
Mari kita lalui proses itu dan lihat apa yang perlu kita lakukan.
Jadi, dalam contoh minikube, kami bermula dengan Docker... Tunggu, kami tidak lagi memerlukan Docker dipasang pada mesin.
Dan kami tidak memerlukan git tempatan.
Dan Maven tidak diperlukan.
Dan anda tidak perlu mencipta imej bekas dengan tangan anda.
Dan anda tidak perlu mencari sebarang repositori imej kontena.
Dan tidak perlu memasang pengawal kemasukan.
Dan anda tidak perlu mengkonfigurasi kemasukan sama ada.
Awak faham, kan? Untuk menggunakan dan menjalankan aplikasi kami pada OpenShift, anda tidak memerlukan mana-mana perkara di atas. Dan proses itu sendiri kelihatan seperti ini.
Langkah 1 β Lancarkan kluster OpenShift anda
Kami menggunakan Bekas Sedia Kod daripada Red Hat, yang pada asasnya adalah Minikube yang sama, tetapi hanya dengan gugusan Openshift nod tunggal sepenuhnya.
crc start
Langkah 2 β Bina dan gunakan aplikasi ke kluster OpenShift
Pada langkah inilah kesederhanaan dan kemudahan OpenShift didedahkan dalam semua kemuliaannya. Seperti semua pengedaran Kubernetes, kami mempunyai banyak cara untuk menjalankan aplikasi dalam kelompok. Dan, seperti dalam kes KUK, kami sengaja memilih yang paling mudah.
OpenShift sentiasa dibina sebagai platform untuk mencipta dan menjalankan aplikasi kontena. Pembinaan kontena sentiasa menjadi bahagian penting platform ini, jadi terdapat satu tan sumber Kubernetes tambahan untuk tugasan yang berkaitan.
Kami akan menggunakan proses OpenShift's Source 2 Image (S2I), yang mempunyai beberapa cara berbeza untuk mengambil sumber kami (kod atau binari) dan mengubahnya menjadi imej bekas yang berjalan pada kelompok OpenShift.
Untuk melakukan ini kita memerlukan dua perkara:
- Kod sumber kami berada dalam repositori git
- Imej pembina berdasarkan binaan yang akan dilakukan.
Terdapat banyak imej sedemikian yang dikekalkan oleh Red Hat dan di peringkat komuniti, dan kami akan menggunakan imej OpenJDK, kerana saya sedang membina aplikasi Java.
Anda boleh menjalankan binaan S2I kedua-duanya daripada konsol grafik Pembangun OpenShift dan dari baris arahan. Kami akan menggunakan arahan apl baharu, memberitahunya tempat untuk mendapatkan imej pembina dan kod sumber kami.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Itu sahaja, aplikasi kami dibuat. Dengan berbuat demikian, proses S2I melakukan perkara berikut:
- Mencipta perkhidmatan build-pod untuk semua jenis perkara yang berkaitan dengan membina aplikasi.
- Mencipta konfigurasi OpenShift Build.
- Saya memuat turun imej pembina ke pendaftaran docker OpenShift dalaman.
- Mengklon "Hello World" ke repositori tempatan.
- Saya melihat bahawa terdapat pom maven di sana, jadi saya menyusun aplikasi menggunakan maven.
- Mencipta imej kontena baharu yang mengandungi aplikasi Java yang disusun dan meletakkan imej ini ke dalam pendaftaran kontena dalaman.
- Terbitan Kubernetes dengan spesifikasi untuk pod, perkhidmatan, dsb.
- Saya mula menggunakan imej kontena.
- Mengalih keluar pod binaan perkhidmatan.
Terdapat banyak dalam senarai ini, tetapi perkara utama ialah keseluruhan binaan berlaku secara eksklusif di dalam OpenShift, pendaftaran Docker dalaman berada di dalam OpenShift, dan proses binaan mencipta semua komponen Kubernetes dan menjalankannya dalam kelompok.
Jika anda memantau secara visual pelancaran S2I dalam konsol, anda boleh melihat cara pod binaan dilancarkan apabila binaan selesai.
Sekarang mari kita lihat log pod pembina: pertama, ia menunjukkan cara maven menjalankan tugasnya dan memuat turun kebergantungan untuk membina aplikasi java kami.
Selepas binaan maven selesai, binaan imej kontena dimulakan, dan kemudian imej binaan ini dihantar ke repositori dalaman.
Itu sahaja, proses membina selesai. Sekarang mari kita pastikan bahawa pod dan perkhidmatan aplikasi kami berjalan dalam kelompok.
oc get service
Itu sahaja. Dan hanya satu pasukan. Apa yang perlu kita lakukan ialah mendedahkan perkhidmatan ini untuk akses dari luar.
Langkah 3 β dedahkan perkhidmatan untuk akses dari luar
Seperti dalam kes KUC, pada platform OpenShift "Hello World" kami juga memerlukan penghala untuk mengarahkan trafik luaran ke perkhidmatan dalam kelompok. OpenShift menjadikannya sangat mudah. Pertama, komponen penghalaan HAProxy dipasang dalam kelompok secara lalai (ia boleh ditukar kepada NGINX yang sama). Kedua, terdapat sumber khas dan sangat boleh disesuaikan dipanggil Laluan dan ia menyerupai objek Ingress dalam Kubernetes lama yang baik (sebenarnya, Laluan OpenShift sangat mempengaruhi reka bentuk objek Ingress, yang kini boleh digunakan dalam OpenShift) , tetapi untuk "Hello World" kami , dan dalam hampir semua kes lain, Laluan standard cukup untuk kami tanpa konfigurasi tambahan.
Untuk mencipta FQDN yang boleh dihalakan untuk "Hello World" (ya, OpenShiift mempunyai DNS sendiri untuk penghalaan mengikut nama perkhidmatan), kami hanya akan mendedahkan perkhidmatan kami:
oc expose service quarkus-hello-world
Jika anda melihat Laluan yang baru dibuat, anda boleh menemui FQDN dan maklumat penghalaan lain di sana:
oc get route
Dan akhirnya, kami mengakses perkhidmatan kami dari penyemak imbas:
Tetapi sekarang ia sangat mudah!
Kami menyukai Kubernetes dan segala-galanya yang membolehkan kami lakukan oleh teknologi ini, dan kami juga menyukai kesederhanaan dan kemudahan. Kubernetes telah dicipta untuk sangat memudahkan operasi diedarkan, bekas boleh skala, tetapi kesederhanaannya tidak lagi mencukupi untuk memasukkan aplikasi ke dalam pengeluaran hari ini. Di sinilah OpenShift memainkan peranan, mengikuti perkembangan masa dan menawarkan Kubernetes, yang ditujukan terutamanya kepada pembangun. Banyak usaha telah dilaburkan untuk menyesuaikan platform OpenShift khusus untuk pembangun, termasuk penciptaan alatan seperti S2I, ODI, Portal Pembangun, Rangka Kerja Operator OpenShift, integrasi IDE, Katalog Pembangun, integrasi Helm, pemantauan dan banyak lagi.
Kami berharap artikel ini menarik dan berguna untuk anda. Anda boleh mendapatkan sumber tambahan, bahan dan perkara lain yang berguna untuk pembangunan pada platform OpenShift pada portal .
Sumber: www.habr.com