สวัสดีทุกคนในบล็อกนี้! นี่เป็นโพสต์ที่สามในชุดที่เราแสดงวิธีการปรับใช้เว็บแอปพลิเคชันสมัยใหม่บน Red Hat OpenShift
ในสองโพสต์ก่อนหน้านี้ เราได้แสดงวิธีการปรับใช้เว็บแอปพลิเคชันสมัยใหม่ในไม่กี่ขั้นตอน และวิธีการใช้อิมเมจ S2I ใหม่พร้อมกับอิมเมจเซิร์ฟเวอร์ HTTP ที่มีจำหน่ายทั่วไป เช่น NGINX โดยใช้บิลด์แบบลูกโซ่เพื่อประสานการปรับใช้งานจริง .
วันนี้เราจะแสดงวิธีรันเซิร์ฟเวอร์การพัฒนาสำหรับแอปพลิเคชันของคุณบนแพลตฟอร์ม OpenShift และซิงโครไนซ์กับระบบไฟล์ในเครื่อง และยังพูดคุยเกี่ยวกับว่า OpenShift Pipelines คืออะไร และวิธีที่สามารถใช้เป็นทางเลือกแทนแอสเซมบลีที่เชื่อมโยงได้
OpenShift เป็นสภาพแวดล้อมการพัฒนา
ขั้นตอนการพัฒนา
ดังที่ได้กล่าวไปแล้วใน กระบวนการพัฒนาทั่วไปสำหรับเว็บแอปพลิเคชันสมัยใหม่เป็นเพียง "เซิร์ฟเวอร์การพัฒนา" บางประเภทที่ติดตามการเปลี่ยนแปลงในไฟล์ในเครื่อง เมื่อเกิดขึ้น บิลด์แอปพลิเคชันจะถูกทริกเกอร์ จากนั้นอัปเดตเป็นเบราว์เซอร์
ในเฟรมเวิร์กที่ทันสมัยที่สุด “เซิร์ฟเวอร์การพัฒนา” ดังกล่าวถูกสร้างขึ้นในเครื่องมือบรรทัดคำสั่งที่เกี่ยวข้อง
ตัวอย่างท้องถิ่น
ขั้นแรก เรามาดูวิธีการทำงานเมื่อเรียกใช้แอปพลิเคชันภายในเครื่อง ลองใช้แอปพลิเคชันเป็นตัวอย่าง จากบทความก่อนหน้านี้ แม้ว่าแนวคิดเวิร์กโฟลว์เดียวกันเกือบทั้งหมดจะนำไปใช้กับเฟรมเวิร์กสมัยใหม่อื่นๆ ทั้งหมดก็ตาม
ดังนั้น เพื่อเริ่ม "เซิร์ฟเวอร์ dev" ในตัวอย่าง React เราจะป้อนคำสั่งต่อไปนี้:
$ npm run start
จากนั้นในหน้าต่าง Terminal เราจะเห็นสิ่งนี้:
และแอปพลิเคชันของเราจะเปิดในเบราว์เซอร์เริ่มต้น:
ตอนนี้หากเราทำการเปลี่ยนแปลงไฟล์ แอปพลิเคชันควรอัปเดตในเบราว์เซอร์
ตกลง ทุกอย่างชัดเจนกับการพัฒนาในโหมดโลคัล แต่จะบรรลุเป้าหมายเดียวกันบน OpenShift ได้อย่างไร
เซิร์ฟเวอร์การพัฒนาบน OpenShift
ถ้าจำได้ก็อิน. เราดูที่ระยะการทำงานที่เรียกว่าอิมเมจ S2I และพบว่าตามค่าเริ่มต้น โมดูลให้บริการมีหน้าที่รับผิดชอบในการให้บริการเว็บแอปพลิเคชันของเรา
อย่างไรก็ตาม หากพิจารณาให้ละเอียดยิ่งขึ้น จากตัวอย่างนั้น มันมีตัวแปรสภาพแวดล้อม $NPM_RUN ซึ่งช่วยให้คุณสามารถดำเนินการคำสั่งของคุณได้
ตัวอย่างเช่น เราสามารถใช้โมดูล nodeshift เพื่อปรับใช้แอปพลิเคชันของเรา:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
หมายเหตุ: ตัวอย่างข้างต้นเป็นคำย่อเพื่อแสดงแนวคิดทั่วไป
ที่นี่เราได้เพิ่มตัวแปรสภาพแวดล้อม NPM_RUN ลงในการปรับใช้ของเรา ซึ่งจะบอกรันไทม์ให้รันคำสั่ง Yarn Start ซึ่งจะสตาร์ทเซิร์ฟเวอร์การพัฒนา React ภายในพ็อด OpenShift ของเรา
หากคุณดูบันทึกของพ็อดที่กำลังรันอยู่ มันจะมีลักษณะดังนี้:
แน่นอนว่าทั้งหมดนี้จะไม่เกิดขึ้นจนกว่าเราจะสามารถซิงโครไนซ์โค้ดท้องถิ่นกับโค้ดซึ่งได้รับการตรวจสอบการเปลี่ยนแปลงด้วย แต่จะอยู่บนเซิร์ฟเวอร์ระยะไกล
การซิงโครไนซ์รหัสระยะไกลและท้องถิ่น
โชคดีที่ nodeshift สามารถช่วยในการซิงโครไนซ์ได้อย่างง่ายดาย และคุณสามารถใช้คำสั่ง watch เพื่อติดตามการเปลี่ยนแปลงได้
ดังนั้นหลังจากที่เรารันคำสั่งเพื่อปรับใช้เซิร์ฟเวอร์การพัฒนาสำหรับแอปพลิเคชันของเราแล้ว เราจึงสามารถใช้คำสั่งต่อไปนี้ได้อย่างปลอดภัย:
$ npx nodeshift watch
เป็นผลให้มีการเชื่อมต่อกับพ็อดที่ทำงานอยู่ซึ่งเราสร้างขึ้นก่อนหน้านี้เล็กน้อย การซิงโครไนซ์ไฟล์ในเครื่องของเรากับคลัสเตอร์ระยะไกลจะถูกเปิดใช้งาน และไฟล์ในระบบโลคัลของเราจะเริ่มได้รับการตรวจสอบการเปลี่ยนแปลง
ดังนั้น หากตอนนี้เราอัปเดตไฟล์ src/App.js ระบบจะตอบสนองต่อการเปลี่ยนแปลงเหล่านี้ คัดลอกการเปลี่ยนแปลงเหล่านั้นไปยังคลัสเตอร์ระยะไกล และเริ่มเซิร์ฟเวอร์การพัฒนา ซึ่งจะอัปเดตแอปพลิเคชันของเราในเบราว์เซอร์
เพื่อให้ภาพสมบูรณ์ เรามาแสดงว่าคำสั่งทั้งหมดเหล่านี้มีลักษณะอย่างไร:
$ 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
คำสั่ง watch เป็นนามธรรมที่อยู่ด้านบนของคำสั่ง oc rsync คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการทำงาน .
นี่คือตัวอย่างสำหรับ React แต่สามารถใช้วิธีการเดียวกันนี้กับเฟรมเวิร์กอื่นๆ ได้ เพียงตั้งค่าตัวแปรสภาพแวดล้อม NPM_RUN ตามความจำเป็น
ไปป์ไลน์ Openshift
ต่อไป เราจะพูดถึงเครื่องมืออย่าง OpenShift Pipelines และวิธีที่เครื่องมือดังกล่าวสามารถใช้เป็นทางเลือกแทนการสร้างแบบลูกโซ่
OpenShift Pipelines คืออะไร
OpenShift Pipelines คือระบบบูรณาการและจัดส่ง CI/CD อย่างต่อเนื่องบนคลาวด์ ซึ่งออกแบบมาเพื่อจัดระเบียบไปป์ไลน์โดยใช้ Tekton Tekton เป็นเฟรมเวิร์ก CI/CD ดั้งเดิมของ Kubernetes แบบโอเพ่นซอร์สที่ยืดหยุ่น ซึ่งช่วยให้คุณปรับใช้อัตโนมัติบนแพลตฟอร์มต่างๆ (Kubernetes, ไร้เซิร์ฟเวอร์, เครื่องเสมือน ฯลฯ) โดยการสรุปจากเลเยอร์พื้นฐาน
การทำความเข้าใจบทความนี้ต้องอาศัยความรู้เกี่ยวกับ Pipelines ดังนั้นเราขอแนะนำให้คุณอ่านก่อน .
การตั้งค่าสภาพแวดล้อมการทำงานของคุณ
หากต้องการลองใช้ตัวอย่างในบทความนี้ คุณต้องเตรียมสภาพแวดล้อมการทำงานก่อน:
- ติดตั้งและกำหนดค่าคลัสเตอร์ OpenShift 4 ตัวอย่างของเราใช้ CodeReady Containers (CRD) สำหรับสิ่งนี้ ดูคำแนะนำในการติดตั้งได้ .
- หลังจากที่คลัสเตอร์พร้อมแล้ว คุณจะต้องติดตั้ง Pipeline Operator บนคลัสเตอร์นั้น อย่ากลัวเลย คำแนะนำในการติดตั้งทำได้ง่าย .
- ดาวน์โหลด (ทีเคเอ็น) .
- เรียกใช้เครื่องมือบรรทัดคำสั่ง create-react-app เพื่อสร้างแอปพลิเคชันที่คุณจะปรับใช้ (นี่เป็นแอปพลิเคชันธรรมดา ).
- (ทางเลือก) โคลนที่เก็บเพื่อรันแอปพลิเคชันตัวอย่างแบบโลคัลด้วยการติดตั้ง npm จากนั้นเริ่มต้น npm
พื้นที่เก็บข้อมูลแอปพลิเคชันจะมีโฟลเดอร์ k8s ซึ่งจะมี Kubernetes/OpenShift YAML ที่ใช้ในการปรับใช้แอปพลิเคชัน จะมี Tasks, ClusterTasks, Resources และ Pipelines ซึ่งเราจะสร้างขึ้นในนี้ .
มาเริ่มกันเลย
ขั้นตอนแรกสำหรับตัวอย่างของเราคือการสร้างโปรเจ็กต์ใหม่ในคลัสเตอร์ OpenShift ลองเรียกโปรเจ็กต์นี้ว่า webapp-pipeline และสร้างมันขึ้นมาด้วยคำสั่งต่อไปนี้:
$ oc new-project webapp-pipeline
ชื่อโปรเจ็กต์นี้จะปรากฏในโค้ดในภายหลัง ดังนั้นหากคุณตัดสินใจตั้งชื่อเป็นอย่างอื่น อย่าลืมแก้ไขโค้ดตัวอย่างตามนั้น จากจุดนี้ เราจะไม่ไปจากบนลงล่าง แต่จากล่างขึ้นบน นั่นคือเราจะสร้างส่วนประกอบทั้งหมดของสายพานลำเลียงก่อน จากนั้นจึงสร้างเฉพาะสายพานลำเลียงเท่านั้น
ก่อนอื่นเลย...
งาน
มาสร้างงานสองสามงานกัน ซึ่งจะช่วยปรับใช้แอปพลิเคชันภายในไปป์ไลน์ของเรา งานแรก Apply_manifests_task มีหน้าที่รับผิดชอบในการใช้ YAML ของทรัพยากร Kubernetes เหล่านั้น (บริการ การปรับใช้ และเส้นทาง) ที่อยู่ในโฟลเดอร์ k8s ของแอปพลิเคชันของเรา ภารกิจที่สอง – update_deployment_task – รับผิดชอบในการอัปเดตอิมเมจที่ปรับใช้แล้วไปเป็นอิมเมจที่สร้างโดยไปป์ไลน์ของเรา
ไม่ต้องกังวลหากยังไม่ชัดเจนนัก อันที่จริงงานเหล่านี้เป็นเหมือนยูทิลิตี้และเราจะดูรายละเอียดเพิ่มเติมในภายหลัง สำหรับตอนนี้ เรามาสร้างมันกันดีกว่า:
$ 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
จากนั้น เมื่อใช้คำสั่ง tkn CLI เราจะตรวจสอบว่ามีการสร้างงานแล้ว:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
หมายเหตุ: งานเหล่านี้เป็นงานท้องถิ่นสำหรับโปรเจ็กต์ปัจจุบันของคุณ
งานคลัสเตอร์
งานคลัสเตอร์โดยพื้นฐานแล้วจะเหมือนกับงานง่ายๆ นั่นคือเป็นชุดของขั้นตอนที่นำมาใช้ซ้ำได้ซึ่งรวมกันไม่ทางใดก็ทางหนึ่งเมื่อรันงานเฉพาะ ข้อแตกต่างก็คืองานคลัสเตอร์สามารถใช้ได้ทุกที่ภายในคลัสเตอร์ หากต้องการดูรายการงานคลัสเตอร์ที่สร้างขึ้นโดยอัตโนมัติเมื่อเพิ่ม Pipeline Operator เราจะใช้คำสั่ง 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
ตอนนี้เรามาสร้างงานคลัสเตอร์สองงานกัน อันแรกจะสร้างอิมเมจ S2I และส่งไปยังรีจิสทรี OpenShift ภายใน อย่างที่สองคือการสร้างอิมเมจของเราโดยใช้ NGINX โดยใช้แอปพลิเคชันที่เราสร้างไว้เป็นเนื้อหา
สร้างและส่งภาพ
เมื่อสร้างงานแรก เราจะทำซ้ำสิ่งที่เราทำไปแล้วในบทความก่อนหน้าเกี่ยวกับแอสเซมบลีที่เชื่อมโยง จำได้ว่าเราใช้อิมเมจ S2I (ubi8-s2i-web-app) เพื่อ “สร้าง” แอปพลิเคชันของเรา และจบลงด้วยอิมเมจที่จัดเก็บไว้ในรีจิสทรีภายในของ OpenShift ตอนนี้เราจะใช้อิมเมจเว็บแอป S2I นี้เพื่อสร้าง DockerFile สำหรับแอปของเรา จากนั้นใช้ Buildah เพื่อสร้างบิลด์จริงและพุชอิมเมจผลลัพธ์ไปยังรีจิสทรีภายในของ OpenShift เนื่องจากนั่นคือสิ่งที่ OpenShift ทำเมื่อคุณปรับใช้แอปพลิเคชันของคุณโดยใช้ NodeShift .
คุณถามเรารู้ทั้งหมดนี้ได้อย่างไร? จาก เราก็แค่คัดลอกมาแก้ไขเอง
ตอนนี้เรามาสร้างงานคลัสเตอร์ s2i-web-app กันดีกว่า:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
เราจะไม่วิเคราะห์สิ่งนี้โดยละเอียด แต่จะเน้นไปที่พารามิเตอร์ OUTPUT_DIR เท่านั้น:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
ตามค่าเริ่มต้น พารามิเตอร์นี้จะเท่ากับ build ซึ่งเป็นที่ที่ React ใส่เนื้อหาที่ประกอบไว้ เฟรมเวิร์กอื่นๆ ใช้พาธที่แตกต่างกัน เช่น ใน Ember จะเป็น dist ผลลัพธ์ของงานคลัสเตอร์แรกของเราจะเป็นรูปภาพที่มี HTML, JavaScript และ CSS ที่เรารวบรวม
สร้างภาพโดยใช้ NGINX
สำหรับงานคลัสเตอร์ที่สองของเรา ควรสร้างอิมเมจที่ใช้ NGINX ให้เรา โดยใช้เนื้อหาของแอปพลิเคชันที่เราสร้างไว้แล้ว โดยพื้นฐานแล้ว นี่คือส่วนหนึ่งของส่วนก่อนหน้าที่เราดูที่การสร้างแบบเชื่อมโยง
ในการทำเช่นนี้ เราเหมือนกับด้านบนทุกประการ - จะสร้างงานคลัสเตอร์ webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
หากคุณดูโค้ดสำหรับงานคลัสเตอร์เหล่านี้ คุณจะเห็นว่าโค้ดไม่ได้ระบุพื้นที่เก็บข้อมูล Git ที่เรากำลังร่วมงานด้วยหรือชื่อของอิมเมจที่เรากำลังสร้าง เราระบุเฉพาะสิ่งที่เราจะถ่ายโอนไปยัง Git หรือภาพบางภาพที่ควรส่งออกภาพสุดท้าย นี่คือสาเหตุที่งานคลัสเตอร์เหล่านี้สามารถนำมาใช้ซ้ำได้เมื่อทำงานกับแอปพลิเคชันอื่น
และที่นี่เราก้าวไปสู่จุดต่อไปอย่างสง่างาม ...
Ресурсы
ดังนั้น ตามที่เรากล่าวไป งานคลัสเตอร์ควรเป็นเรื่องทั่วไปที่สุดเท่าที่จะเป็นไปได้ เราจึงต้องสร้างทรัพยากรที่จะใช้เป็นอินพุต (พื้นที่เก็บข้อมูล Git) และเป็นเอาต์พุต (อิมเมจสุดท้าย) ทรัพยากรแรกที่เราต้องการคือ Git ซึ่งเป็นที่ที่แอปพลิเคชันของเราอยู่ บางอย่างเช่นนี้:
# 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
ที่นี่ PipelineResource เป็นประเภท git คีย์ URL ในส่วนพารามิเตอร์ชี้ไปที่พื้นที่เก็บข้อมูลเฉพาะและระบุสาขาหลัก (นี่เป็นทางเลือก แต่เราเขียนเพื่อความสมบูรณ์)
ตอนนี้เราจำเป็นต้องสร้างทรัพยากรสำหรับรูปภาพที่จะบันทึกผลลัพธ์ของงาน s2i-web-app ซึ่งทำได้ดังนี้:
# 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
ในที่นี้ PipelineResource เป็นประเภทอิมเมจ และค่าของพารามิเตอร์ url ชี้ไปที่ OpenShift Image Registry ภายใน โดยเฉพาะอันที่อยู่ในเนมสเปซ webapp-pipeline อย่าลืมเปลี่ยนการตั้งค่านี้หากคุณใช้เนมสเปซอื่น
และสุดท้าย ทรัพยากรสุดท้ายที่เราต้องการก็คือประเภทอิมเมจด้วย และนี่จะเป็นอิมเมจ NGINX สุดท้ายที่จะใช้ในระหว่างการปรับใช้:
# 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
โปรดทราบว่าทรัพยากรนี้จัดเก็บรูปภาพไว้ในรีจิสทรี OpenShift ภายในในเนมสเปซ webapp-pipeline
ในการสร้างทรัพยากรทั้งหมดนี้ในครั้งเดียว เราใช้คำสั่ง create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
คุณสามารถตรวจสอบให้แน่ใจว่าทรัพยากรได้ถูกสร้างขึ้นดังนี้:
$ tkn resource ls
ท่อลำเลียง
ตอนนี้เรามีส่วนประกอบที่จำเป็นทั้งหมดแล้ว มาประกอบไปป์ไลน์จากส่วนประกอบเหล่านั้นโดยสร้างมันขึ้นมาด้วยคำสั่งต่อไปนี้:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
แต่ก่อนที่เราจะรันคำสั่งนี้ เรามาดูส่วนประกอบเหล่านี้ก่อน อันแรกคือชื่อ:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
จากนั้นในส่วนข้อมูลจำเพาะ เราจะเห็นข้อบ่งชี้ของทรัพยากรที่เราสร้างไว้ก่อนหน้านี้:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
จากนั้นเราจะสร้างงานที่ไปป์ไลน์ของเราต้องทำให้เสร็จ ก่อนอื่น มันจะต้องรันงาน s2i-web-app ที่เราสร้างไว้แล้ว:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
งานนี้ใช้พารามิเตอร์อินพุต (ทรัพยากร gir) และเอาต์พุต (ทรัพยากรรูปภาพที่สร้างขึ้นบนเว็บแอปพลิเคชัน) นอกจากนี้เรายังส่งพารามิเตอร์พิเศษเพื่อไม่ให้ตรวจสอบ TLS เนื่องจากเราใช้ใบรับรองที่ลงนามด้วยตนเอง:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
งานถัดไปเกือบจะเหมือนเดิม เฉพาะที่นี่เท่านั้นที่งานคลัสเตอร์ webapp-build-runtime ที่เราสร้างไว้แล้วเรียกว่า:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
เช่นเดียวกับงานก่อนหน้านี้ เราจะส่งทรัพยากร แต่ตอนนี้เป็น build-web-application-image (ผลลัพธ์ของงานก่อนหน้าของเรา) และเพื่อเป็นผลลัพธ์ เราก็ตั้งค่ารูปภาพอีกครั้ง เนื่องจากงานนี้จะต้องดำเนินการหลังจากภารกิจก่อนหน้า เราจึงเพิ่มฟิลด์ 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
งานสองงานถัดไปมีหน้าที่รับผิดชอบในการใช้บริการ กำหนดเส้นทาง และการปรับใช้ไฟล์ YAML ที่อยู่ในไดเร็กทอรี k8s ของเว็บแอปพลิเคชันของเรา และยังรับผิดชอบในการอัปเดตการปรับใช้นี้เมื่อสร้างอิมเมจใหม่ เราได้กำหนดงานคลัสเตอร์ทั้งสองนี้ไว้ที่ตอนต้นของบทความ
กำลังดำเนินการไปป์ไลน์
ดังนั้นทุกส่วนของไปป์ไลน์ของเราจึงถูกสร้างขึ้น และเราจะรันมันด้วยคำสั่งต่อไปนี้:
$ tkn pipeline start build-and-deploy-react
ในขั้นตอนนี้ บรรทัดคำสั่งจะถูกใช้แบบโต้ตอบ และคุณต้องเลือกทรัพยากรที่เหมาะสมเพื่อตอบสนองคำขอแต่ละรายการ: สำหรับทรัพยากร git ให้เลือก web-application-repo จากนั้นสำหรับทรัพยากรรูปภาพแรก build-web-application -image และสุดท้ายสำหรับทรัพยากรรูปภาพที่สอง –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
ตอนนี้เรามาตรวจสอบสถานะของไปป์ไลน์โดยใช้คำสั่งต่อไปนี้:
$ tkn pipeline logs -f
เมื่อไปป์ไลน์เริ่มต้นและปรับใช้แอปพลิเคชันแล้ว เราสามารถขอเส้นทางที่เผยแพร่ด้วยคำสั่งต่อไปนี้:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
เพื่อให้เห็นภาพมากขึ้น คุณสามารถดูไปป์ไลน์ของเราในโหมดนักพัฒนาซอฟต์แวร์ของเว็บคอนโซลได้ในส่วนนี้ ท่อดังแสดงในรูป 1.
รูปที่ 1. ทบทวนการเดินท่อ
การคลิกที่ไปป์ไลน์ที่ทำงานอยู่จะแสดงรายละเอียดเพิ่มเติม ดังแสดงในรูปที่ 2
ข้าว. 2. ข้อมูลเพิ่มเติมเกี่ยวกับไปป์ไลน์
หลังจากข้อมูลเพิ่มเติม คุณสามารถดูแอปพลิเคชันที่กำลังรันอยู่ในมุมมอง โทโพโลยีดังแสดงในรูปที่ 3
รูปที่ 3. เปิดตัวพ็อด
การคลิกที่วงกลมที่มุมขวาบนของไอคอนจะเป็นการเปิดแอปพลิเคชันของเรา ดังแสดงในรูปที่ 4
ข้าว. 4. การรันแอปพลิเคชั่น React
ข้อสรุป
ดังนั้นเราจึงแสดงวิธีรันเซิร์ฟเวอร์การพัฒนาสำหรับแอปพลิเคชันของคุณบน OpenShift และซิงโครไนซ์กับระบบไฟล์ในเครื่อง นอกจากนี้เรายังดูวิธีการจำลองเทมเพลตการสร้างแบบลูกโซ่โดยใช้ OpenShift Pipelines โค้ดตัวอย่างทั้งหมดจากบทความนี้สามารถพบได้ .
แหล่งข้อมูลเพิ่มเติม (EN)
- ฟรีอีบุ๊ค
- ข้อมูลเพิ่มเติมเกี่ยวกับ บนเว็บไซต์เรดแฮท
ประกาศเกี่ยวกับการสัมมนาผ่านเว็บที่กำลังจะมีขึ้น
เรากำลังเริ่มชุดการสัมมนาผ่านเว็บในวันศุกร์เกี่ยวกับประสบการณ์ดั้งเดิมโดยใช้ Red Hat OpenShift Container Platform และ Kubernetes:
ที่มา: will.com