Hello semua di blog ini! Ini adalah siaran ketiga dalam satu siri di mana kami menunjukkan cara untuk menggunakan aplikasi web moden pada Red Hat OpenShift.
Dalam dua catatan sebelum ini, kami menunjukkan cara untuk menggunakan aplikasi web moden dalam beberapa langkah sahaja dan cara menggunakan imej S2I baharu bersama-sama imej pelayan HTTP yang luar biasa, seperti NGINX, menggunakan binaan berantai untuk mengatur penggunaan pengeluaran .
Hari ini kami akan menunjukkan cara untuk menjalankan pelayan pembangunan untuk aplikasi anda pada platform OpenShift dan menyegerakkannya dengan sistem fail tempatan, dan juga bercakap tentang apa itu OpenShift Pipelines dan bagaimana ia boleh digunakan sebagai alternatif kepada perhimpunan terpaut.
OpenShift sebagai persekitaran pembangunan
Aliran kerja pembangunan
Seperti yang telah dinyatakan dalam , proses pembangunan biasa untuk aplikasi web moden hanyalah sejenis "pelayan pembangunan" yang menjejaki perubahan pada fail tempatan. Apabila ia berlaku, binaan aplikasi dicetuskan dan kemudian ia dikemas kini kepada penyemak imbas.
Dalam kebanyakan rangka kerja moden, "pelayan pembangunan" sedemikian dibina ke dalam alat baris arahan yang sepadan.
Contoh tempatan
Mula-mula, mari lihat cara ini berfungsi apabila menjalankan aplikasi secara setempat. Mari kita ambil aplikasi sebagai contoh daripada artikel sebelumnya, walaupun konsep aliran kerja yang hampir sama digunakan dalam semua rangka kerja moden yang lain.
Jadi, untuk memulakan "pelayan dev" dalam contoh React kami, kami akan memasukkan arahan berikut:
$ npm run start
Kemudian dalam tetingkap terminal kita akan melihat sesuatu seperti ini:
Dan aplikasi kami akan dibuka dalam penyemak imbas lalai:
Sekarang, jika kita membuat perubahan pada fail, aplikasi harus dikemas kini dalam penyemak imbas.
OK, semuanya jelas dengan pembangunan dalam mod tempatan, tetapi bagaimana untuk mencapai perkara yang sama pada OpenShift?
Pelayan pembangunan pada OpenShift
Jika anda ingat, dalam , kami melihat apa yang dipanggil fasa larian bagi imej S2I dan melihat bahawa secara lalai, modul servis bertanggungjawab untuk menyelenggara aplikasi web kami.
Walau bagaimanapun, jika anda melihat dengan lebih dekat daripada contoh itu, ia mengandungi pembolehubah persekitaran $NPM_RUN, yang membolehkan anda melaksanakan arahan anda.
Sebagai contoh, kami boleh menggunakan modul nodeshift untuk menggunakan aplikasi kami:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Nota: Contoh di atas dipendekkan untuk menggambarkan idea umum.
Di sini kami telah menambahkan pembolehubah persekitaran NPM_RUN pada penggunaan kami, yang memberitahu masa jalan untuk menjalankan perintah mula benang, yang memulakan pelayan pembangunan React di dalam pod OpenShift kami.
Jika anda melihat log pod yang sedang berjalan, ia akan kelihatan seperti ini:
Sudah tentu, semua ini tidak akan menjadi apa-apa sehingga kita boleh menyegerakkan kod tempatan dengan kod, yang juga dipantau untuk perubahan, tetapi hidup pada pelayan jauh.
Menyegerakkan kod jauh dan tempatan
Nasib baik, nodeshift boleh membantu penyegerakan dengan mudah dan anda boleh menggunakan arahan jam tangan untuk menjejaki perubahan.
Jadi selepas kami menjalankan arahan untuk menggunakan pelayan pembangunan untuk aplikasi kami, kami boleh menggunakan arahan berikut dengan selamat:
$ npx nodeshift watch
Akibatnya, sambungan akan dibuat ke pod berjalan yang kami buat sedikit lebih awal, penyegerakan fail tempatan kami dengan kluster jauh akan diaktifkan, dan fail pada sistem setempat kami akan mula dipantau untuk perubahan.
Oleh itu, jika kami kini mengemas kini fail src/App.js, sistem akan bertindak balas terhadap perubahan ini, menyalinnya ke kluster jauh dan memulakan pelayan pembangunan, yang kemudiannya akan mengemas kini aplikasi kami dalam penyemak imbas.
Untuk melengkapkan gambar, mari tunjukkan rupa keseluruhan arahan ini:
$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000
$ npx nodeshift watch --strictSSL=false
Perintah jam tangan ialah abstraksi di atas perintah oc rsync, anda boleh mengetahui lebih lanjut tentang cara ia berfungsi .
Ini adalah contoh untuk React, tetapi kaedah yang sama boleh digunakan dengan rangka kerja lain, cuma tetapkan pembolehubah persekitaran NPM_RUN seperti yang diperlukan.
β
Talian Paip Openhift
Seterusnya kita akan bercakap tentang alat seperti OpenShift Pipelines dan cara ia boleh digunakan sebagai alternatif kepada binaan berantai.
Apakah itu OpenShift Pipelines
OpenShift Pipelines ialah sistem penyepaduan dan penyampaian berterusan CI/CD asli awan yang direka untuk mengatur saluran paip menggunakan Tekton. Tekton ialah rangka kerja CI/CD asli Kubernetes-sumber terbuka fleksibel yang membolehkan anda mengautomasikan penggunaan pada pelbagai platform (Kubernetes, tanpa pelayan, mesin maya, dsb.) dengan mengabstraksi daripada lapisan asas.
Memahami artikel ini memerlukan sedikit pengetahuan tentang Pipelines, jadi kami amat mengesyorkan agar anda membaca dahulu .
Menyediakan persekitaran kerja anda
Untuk bermain dengan contoh dalam artikel ini, anda perlu menyediakan persekitaran kerja anda terlebih dahulu:
- Pasang dan konfigurasikan kluster OpenShift 4. Contoh kami menggunakan CodeReady Containers (CRD) untuk ini, arahan pemasangan yang boleh didapati .
- Selepas kluster sedia, anda perlu memasang Operator Saluran Paip padanya. Jangan takut, ia mudah, arahan pemasangan .
- Turun (tkn) .
- Jalankan alat baris arahan create-react-app untuk mencipta aplikasi yang kemudiannya akan anda gunakan (ini adalah aplikasi mudah ).
- (Pilihan) Klon repositori untuk menjalankan aplikasi contoh secara setempat dengan pemasangan npm dan kemudian npm mula.
Repositori aplikasi juga akan mempunyai folder k8s, yang akan mengandungi YAML Kubernetes/OpenShift yang digunakan untuk menggunakan aplikasi. Akan ada Tugasan, Tugas Kluster, Sumber dan Talian Paip yang akan kami buat dalam perkara ini .
Mari kita mulakan
Langkah pertama untuk contoh kami ialah mencipta projek baharu dalam kelompok OpenShift. Mari kita panggil webapp-pipeline projek ini dan buatnya dengan arahan berikut:
$ oc new-project webapp-pipeline
Nama projek ini akan muncul dalam kod kemudian, jadi jika anda memutuskan untuk menamakannya sesuatu yang lain, jangan lupa untuk mengedit kod contoh dengan sewajarnya. Bermula dari titik ini, kami tidak akan pergi dari atas ke bawah, tetapi dari bawah ke atas: iaitu, kami akan mula-mula membuat semua komponen penghantar, dan hanya kemudian penghantar itu sendiri.
Jadi, pertama sekali...
Tugasan
Mari kita buat beberapa tugasan, yang kemudiannya akan membantu menggunakan aplikasi dalam saluran paip kami. Tugas pertama - apply_manifests_task - bertanggungjawab untuk menggunakan YAML sumber Kubernetes tersebut (perkhidmatan, penggunaan dan laluan) yang terdapat dalam folder k8s aplikasi kami. Tugas kedua - update_deployment_task - bertanggungjawab untuk mengemas kini imej yang telah digunakan kepada imej yang dibuat oleh saluran paip kami.
Jangan risau jika masih belum jelas. Sebenarnya, tugasan ini adalah seperti utiliti, dan kami akan melihatnya dengan lebih terperinci kemudian. Buat masa ini, mari kita buat sahaja:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml
Kemudian, menggunakan perintah tkn CLI, kami akan menyemak sama ada tugasan telah dibuat:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Nota: Ini adalah tugas tempatan untuk projek semasa anda.
Tugas kelompok
Tugas kluster pada asasnya sama dengan tugas mudah. Iaitu, ia adalah koleksi langkah yang boleh digunakan semula yang digabungkan dalam satu cara atau yang lain apabila menjalankan tugas tertentu. Perbezaannya ialah tugas kelompok tersedia di mana-mana dalam kelompok. Untuk melihat senarai tugas kelompok yang dibuat secara automatik apabila menambah Operator Saluran Paip, kami sekali lagi akan menggunakan perintah tkn CLI:
$ tkn clustertask ls
NAME AGE
buildah 1 day ago
buildah-v0-10-0 1 day ago
jib-maven 1 day ago
kn 1 day ago
maven 1 day ago
openshift-client 1 day ago
openshift-client-v0-10-0 1 day ago
s2i 1 day ago
s2i-go 1 day ago
s2i-go-v0-10-0 1 day ago
s2i-java-11 1 day ago
s2i-java-11-v0-10-0 1 day ago
s2i-java-8 1 day ago
s2i-java-8-v0-10-0 1 day ago
s2i-nodejs 1 day ago
s2i-nodejs-v0-10-0 1 day ago
s2i-perl 1 day ago
s2i-perl-v0-10-0 1 day ago
s2i-php 1 day ago
s2i-php-v0-10-0 1 day ago
s2i-python-3 1 day ago
s2i-python-3-v0-10-0 1 day ago
s2i-ruby 1 day ago
s2i-ruby-v0-10-0 1 day ago
s2i-v0-10-0 1 day ago
Sekarang mari kita buat dua tugas kelompok. Yang pertama akan menjana imej S2I dan menghantarnya ke pendaftaran OpenShift dalaman; yang kedua ialah membina imej kami berdasarkan NGINX, menggunakan aplikasi yang telah kami bina sebagai kandungan.
Buat dan hantar imej
Apabila membuat tugasan pertama, kami akan mengulangi perkara yang telah kami lakukan dalam artikel sebelumnya tentang perhimpunan terpaut. Ingat bahawa kami menggunakan imej S2I (ubi8-s2i-web-app) untuk "membina" aplikasi kami, dan berakhir dengan imej yang disimpan dalam pendaftaran dalaman OpenShift. Kini kami akan menggunakan imej aplikasi web S2I ini untuk mencipta DockerFile untuk apl kami dan kemudian menggunakan Buildah untuk melakukan binaan sebenar dan menolak imej yang terhasil ke pendaftaran dalaman OpenShift, kerana itulah yang OpenShift lakukan apabila anda menggunakan aplikasi anda menggunakan NodeShift .
Bagaimana kami tahu semua ini, anda bertanya? daripada , kami hanya menyalinnya dan mengubah suainya untuk diri kami sendiri.
Jadi, sekarang mari kita buat tugas kelompok s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Kami tidak akan menganalisis ini secara terperinci, tetapi hanya akan menumpukan pada parameter OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Secara lalai, parameter ini sama dengan binaan, di mana React meletakkan kandungan yang dipasang. Rangka kerja lain menggunakan laluan yang berbeza, contohnya, dalam Ember ia adalah dist. Output tugas kelompok pertama kami ialah imej yang mengandungi HTML, JavaScript dan CSS yang kami kumpulkan.
Bina imej berdasarkan NGINX
Bagi tugas kelompok kedua kami, ia harus membina imej berasaskan NGINX untuk kami, menggunakan kandungan aplikasi yang telah kami bina. Pada asasnya, ini adalah bahagian bahagian sebelumnya di mana kami melihat binaan berantai.
Untuk melakukan ini, kami - sama seperti di atas - akan mencipta tugas kelompok webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Jika anda melihat kod tugas kluster ini, anda boleh melihat bahawa ia tidak menyatakan repositori Git yang sedang kami kerjakan atau nama imej yang kami cipta. Kami hanya menentukan apa sebenarnya yang kami pindahkan ke Git, atau imej tertentu di mana imej akhir harus dikeluarkan. Itulah sebabnya tugas kelompok ini boleh digunakan semula apabila bekerja dengan aplikasi lain.
Dan di sini kita dengan anggun beralih ke titik seterusnya...
Π Π΅ΡΡΡΡΡ
Oleh itu, memandangkan, seperti yang baru kami katakan, tugas kluster harus seumum mungkin, kami perlu mencipta sumber yang akan digunakan sebagai input (repositori Git) dan sebagai output (imej akhir). Sumber pertama yang kami perlukan ialah Git, di mana aplikasi kami berada, seperti ini:
# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: web-application-repo
spec:
type: git
params:
- name: url
value: https://github.com/nodeshift-starters/react-pipeline-example
- name: revision
value: master
Di sini PipelineResource adalah jenis git. Kunci url dalam bahagian params menghala ke repositori tertentu dan menentukan cawangan induk (ini adalah pilihan, tetapi kami menulisnya untuk kesempurnaan).
Sekarang kita perlu mencipta sumber untuk imej di mana hasil tugas s2i-web-app akan disimpan, ini dilakukan seperti ini:
# This resource is the result of running "npm run build", the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: built-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest
Di sini PipelineResource adalah daripada jenis imej, dan nilai parameter url menghala ke OpenShift Image Registry dalaman, khususnya yang terletak dalam ruang nama saluran paip web. Jangan lupa untuk menukar tetapan ini jika anda menggunakan ruang nama yang berbeza.
Dan akhirnya, sumber terakhir yang kami perlukan juga ialah imej jenis dan ini akan menjadi imej NGINX terakhir yang kemudiannya akan digunakan semasa penggunaan:
# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: runtime-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest
Sekali lagi, ambil perhatian bahawa sumber ini menyimpan imej dalam pendaftaran OpenShift dalaman dalam ruang nama saluran paip web.
Untuk mencipta semua sumber ini sekaligus, kami menggunakan arahan cipta:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Anda boleh memastikan bahawa sumber telah dibuat seperti ini:
$ tkn resource ls
Saluran paip penghantar
Sekarang kita mempunyai semua komponen yang diperlukan, mari kita kumpulkan saluran paip daripada mereka dengan menciptanya dengan arahan berikut:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Tetapi sebelum kita menjalankan arahan ini, mari kita lihat komponen ini. Yang pertama ialah nama:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Kemudian dalam bahagian spec kami melihat petunjuk sumber yang kami buat sebelum ini:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Kami kemudian membuat tugasan yang perlu diselesaikan oleh saluran paip kami. Pertama sekali, ia mesti melaksanakan tugas s2i-web-app yang telah kami buat:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Tugas ini mengambil parameter input (sumber gir) dan output (sumber imej-aplikasi-web terbina). Kami juga memberikannya parameter khas supaya ia tidak mengesahkan TLS kerana kami menggunakan sijil yang ditandatangani sendiri:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Tugas seterusnya adalah hampir sama, hanya di sini tugas kluster webapp-build-runtime yang telah kami buat dipanggil:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Seperti tugas sebelumnya, kami memasukkan sumber, tetapi kini ia adalah imej-aplikasi-web terbina (output tugas kami yang terdahulu). Dan sebagai output, kami sekali lagi menetapkan imej. Memandangkan tugas ini mesti dilaksanakan selepas yang sebelumnya, kami menambah medan runAfter:
resources:
inputs:
- name: image
resource: built-web-application-image
outputs:
- name: image
resource: runtime-web-application-image
params:
- name: TLSVERIFY
value: "false"
runAfter:
- build-web-application
Dua tugas seterusnya bertanggungjawab untuk menggunakan fail YAML perkhidmatan, laluan dan penggunaan yang terdapat dalam direktori k8s aplikasi web kami, dan juga untuk mengemas kini penggunaan ini apabila mencipta imej baharu. Kami mentakrifkan dua tugas kelompok ini pada permulaan artikel.
Memulakan penghantar
Jadi, semua bahagian saluran paip kami dibuat, dan kami akan menjalankannya dengan arahan berikut:
$ tkn pipeline start build-and-deploy-react
Pada peringkat ini, baris arahan digunakan secara interaktif dan anda perlu memilih sumber yang sesuai sebagai tindak balas kepada setiap permintaannya: untuk sumber git, pilih web-application-repo, kemudian untuk sumber imej pertama, built-web-application -imej, dan akhirnya, untuk sumber imej kedua βruntime-web-application-image:
? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr
Sekarang mari kita semak status saluran paip menggunakan arahan berikut:
$ tkn pipeline logs -f
Setelah saluran paip dimulakan dan aplikasi telah digunakan, kami boleh meminta laluan yang diterbitkan dengan arahan berikut:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Untuk visualisasi yang lebih baik, anda boleh melihat saluran paip kami dalam mod Pembangun konsol web dalam bahagian tersebut Talian Paip, seperti yang ditunjukkan dalam Rajah. 1.
Rajah 1. Semakan saluran paip yang sedang berjalan.
Mengklik pada saluran paip yang sedang berjalan memaparkan butiran tambahan, seperti ditunjukkan dalam Rajah 2.
nasi. 2. Maklumat tambahan tentang saluran paip.
Selepas maklumat lanjut, anda boleh melihat aplikasi yang sedang berjalan dalam paparan Topologi, seperti yang ditunjukkan dalam Rajah.3.
Rajah 3. Dilancarkan pod.
Mengklik pada bulatan di penjuru kanan sebelah atas ikon membuka aplikasi kami, seperti yang ditunjukkan dalam Rajah 4.
nasi. 4. Menjalankan aplikasi React.
Kesimpulan
Jadi, kami menunjukkan cara untuk menjalankan pelayan pembangunan untuk aplikasi anda pada OpenShift dan menyegerakkannya dengan sistem fail tempatan. Kami juga melihat cara untuk mensimulasikan templat binaan berantai menggunakan OpenShift Pipelines. Semua contoh kod daripada artikel ini boleh didapati .
Sumber tambahan (EN)
- E-book percuma
- Lanjut mengenai di laman web Red Hat
Pengumuman webinar akan datang
Kami memulakan satu siri webinar Jumaat tentang pengalaman asli menggunakan Platform Kontena OpenShift Red Hat dan Kubernetes:
Sumber: www.habr.com