🥇ความรู้เบื้องต้นเกี่ยวกับ GitOps สำหรับ OpenShift

วันนี้เราจะพูดถึงหลักการและโมเดลของ GitOps รวมถึงวิธีการนำโมเดลเหล่านี้ไปใช้งานบนแพลตฟอร์ม OpenShift มีคำแนะนำแบบโต้ตอบในหัวข้อนี้ ลิงค์.

โดยสรุป GitOps คือชุดแนวทางปฏิบัติสำหรับการใช้คำขอดึง Git เพื่อจัดการโครงสร้างพื้นฐานและการกำหนดค่าแอปพลิเคชัน พื้นที่เก็บข้อมูล Git ใน GitOps ถือเป็นแหล่งข้อมูลเดียวเกี่ยวกับสถานะของระบบ และการเปลี่ยนแปลงใดๆ ในสถานะนี้สามารถติดตามและตรวจสอบได้อย่างสมบูรณ์

แนวคิดในการติดตามการเปลี่ยนแปลงใน GitOps ไม่ใช่เรื่องใหม่ วิธีการนี้ใช้กันมานานแล้วในระดับสากลเมื่อทำงานกับซอร์สโค้ดของแอปพลิเคชัน GitOps ใช้คุณสมบัติที่คล้ายกัน (การตรวจสอบ คำขอดึง แท็ก ฯลฯ) ในการจัดการโครงสร้างพื้นฐานและการกำหนดค่าแอปพลิเคชัน และให้ประโยชน์ที่คล้ายคลึงกันในกรณีของการจัดการซอร์สโค้ด

ไม่มีคำจำกัดความทางวิชาการหรือชุดกฎเกณฑ์ที่ได้รับอนุมัติสำหรับ GitOps มีเพียงชุดหลักการที่ใช้สร้างแนวปฏิบัตินี้เท่านั้น:

คำอธิบายที่เปิดเผยของระบบจะถูกจัดเก็บไว้ในที่เก็บ Git (การกำหนดค่า การตรวจสอบ ฯลฯ)
การเปลี่ยนแปลงสถานะเกิดขึ้นผ่านการร้องขอการดึง
สถานะของระบบที่ทำงานอยู่จะถูกปรับให้สอดคล้องกับข้อมูลในพื้นที่เก็บข้อมูลโดยใช้คำขอพุช Git

หลักการ GitOps

คำจำกัดความของระบบอธิบายไว้เป็นซอร์สโค้ด

การกำหนดค่าระบบจะถือเป็นโค้ดเพื่อให้สามารถจัดเก็บและกำหนดเวอร์ชันโดยอัตโนมัติในพื้นที่เก็บข้อมูล Git ซึ่งทำหน้าที่เป็นแหล่งความจริงแหล่งเดียว แนวทางนี้ทำให้ง่ายต่อการเปิดตัวและย้อนกลับการเปลี่ยนแปลงในระบบ

สถานะและการกำหนดค่าของระบบที่ต้องการได้รับการตั้งค่าและกำหนดเวอร์ชันใน Git

ด้วยการจัดเก็บและกำหนดเวอร์ชันสถานะของระบบที่ต้องการใน Git เราจึงสามารถเผยแพร่และย้อนกลับการเปลี่ยนแปลงในระบบและแอปพลิเคชันได้อย่างง่ายดาย นอกจากนี้เรายังสามารถใช้กลไกการรักษาความปลอดภัยของ Git เพื่อควบคุมการเป็นเจ้าของโค้ดและตรวจสอบความถูกต้องได้

การเปลี่ยนแปลงการกำหนดค่าสามารถนำไปใช้โดยอัตโนมัติผ่านการร้องขอการดึง

เมื่อใช้คำขอดึง Git เราสามารถควบคุมวิธีนำการเปลี่ยนแปลงไปใช้กับการกำหนดค่าในพื้นที่เก็บข้อมูลได้อย่างง่ายดาย ตัวอย่างเช่น สามารถมอบให้สมาชิกในทีมคนอื่นๆ เพื่อตรวจสอบหรือดำเนินการทดสอบ CI เป็นต้น

และในขณะเดียวกันก็ไม่จำเป็นต้องกระจายอำนาจผู้ดูแลระบบไปทางซ้ายและขวา ในการดำเนินการเปลี่ยนแปลงการกำหนดค่า ผู้ใช้จำเป็นต้องมีเพียงสิทธิ์ที่เหมาะสมในพื้นที่เก็บข้อมูล Git ซึ่งเป็นที่จัดเก็บการกำหนดค่าเหล่านั้น

แก้ไขปัญหาการเคลื่อนตัวของการกำหนดค่าที่ไม่สามารถควบคุมได้

เมื่อสถานะระบบที่ต้องการถูกจัดเก็บไว้ในที่เก็บ Git สิ่งที่เราต้องทำคือค้นหาซอฟต์แวร์ที่จะทำให้แน่ใจว่าสถานะปัจจุบันของระบบตรงกับสถานะที่ต้องการ หากไม่เป็นเช่นนั้น ซอฟต์แวร์นี้ควร (ขึ้นอยู่กับการตั้งค่า) กำจัดความคลาดเคลื่อนด้วยตัวมันเอง หรือแจ้งให้เราทราบเกี่ยวกับการกำหนดค่าที่ลอยไป

โมเดล GitOps สำหรับ OpenShift

ตัวกระทบยอดทรัพยากรบนคลัสเตอร์

ตามโมเดลนี้ คลัสเตอร์มีตัวควบคุมที่รับผิดชอบในการเปรียบเทียบทรัพยากร Kubernetes (ไฟล์ YAML) ในพื้นที่เก็บข้อมูล Git กับทรัพยากรจริงของคลัสเตอร์ หากตรวจพบความคลาดเคลื่อน ผู้ควบคุมจะส่งการแจ้งเตือนและอาจดำเนินการเพื่อแก้ไขความคลาดเคลื่อน โมเดล GitOps นี้ใช้ใน Anthos Config Management และ Weaveworks Flux

ผู้กระทบยอดทรัพยากรภายนอก (พุช)

โมเดลนี้ถือได้ว่าเป็นรูปแบบของรุ่นก่อนหน้า เมื่อเรามีตัวควบคุมตั้งแต่หนึ่งตัวขึ้นไปที่รับผิดชอบในการซิงโครไนซ์ทรัพยากรในคู่ "พื้นที่เก็บข้อมูล Git - คลัสเตอร์ Kubernetes" ข้อแตกต่างก็คือแต่ละคลัสเตอร์ที่ได้รับการจัดการไม่จำเป็นต้องมีตัวควบคุมแยกกัน คู่คลัสเตอร์ Git - k8s มักถูกกำหนดให้เป็น CRD (คำจำกัดความทรัพยากรที่กำหนดเอง) ซึ่งสามารถอธิบายวิธีที่คอนโทรลเลอร์ควรทำการซิงโครไนซ์ ภายในโมเดลนี้ ตัวควบคุมจะเปรียบเทียบพื้นที่เก็บข้อมูล Git ที่ระบุใน CRD กับทรัพยากรคลัสเตอร์ Kubernetes ซึ่งระบุไว้ใน CRD เช่นกัน และดำเนินการที่เหมาะสมตามผลลัพธ์ของการเปรียบเทียบ โดยเฉพาะโมเดล GitOps นี้ใช้ใน ArgoCD

GitOps บนแพลตฟอร์ม OpenShift

การดูแลระบบโครงสร้างพื้นฐาน Kubernetes แบบหลายคลัสเตอร์

ด้วยการแพร่กระจายของ Kubernetes และความนิยมที่เพิ่มขึ้นของกลยุทธ์มัลติคลาวด์และการประมวลผลแบบ Edge จำนวนคลัสเตอร์ OpenShift โดยเฉลี่ยต่อลูกค้าก็เพิ่มขึ้นเช่นกัน

ตัวอย่างเช่น เมื่อใช้ Edge Computing คลัสเตอร์ของลูกค้าหนึ่งรายสามารถนำไปใช้งานเป็นร้อยหรือเป็นพันได้ เป็นผลให้เขาถูกบังคับให้จัดการคลัสเตอร์ OpenShift อิสระหรือที่มีการประสานงานหลายรายการในระบบคลาวด์สาธารณะและในองค์กร

ในกรณีนี้ต้องแก้ไขปัญหาหลายอย่าง โดยเฉพาะ:

ควบคุมว่าคลัสเตอร์อยู่ในสถานะเดียวกัน (การกำหนดค่า การตรวจสอบ พื้นที่เก็บข้อมูล ฯลฯ)
สร้างคลัสเตอร์ใหม่ (หรือกู้คืน) ตามสถานะที่ทราบ
สร้างคลัสเตอร์ใหม่ตามสถานะที่ทราบ
เปิดตัวการเปลี่ยนแปลงไปยังคลัสเตอร์ OpenShift หลายคลัสเตอร์
ย้อนกลับการเปลี่ยนแปลงในหลายคลัสเตอร์ OpenShift
เชื่อมโยงการกำหนดค่าเทมเพลตกับสภาพแวดล้อมที่แตกต่างกัน

การกำหนดค่าแอปพลิเคชัน

ในช่วงวงจรการใช้งาน แอปพลิเคชันมักจะผ่านกลุ่มคลัสเตอร์ (dev, ระยะ ฯลฯ) ก่อนที่จะจบลงในคลัสเตอร์ที่ใช้งานจริง นอกจากนี้ เนื่องจากข้อกำหนดด้านความพร้อมใช้งานและความสามารถในการปรับขนาด ลูกค้าจึงมักจะปรับใช้แอปพลิเคชันบนคลัสเตอร์ภายในองค์กรหลายแห่งหรือหลายภูมิภาคของแพลตฟอร์มคลาวด์สาธารณะ

ในกรณีนี้ งานต่อไปนี้จะต้องได้รับการแก้ไข:

ตรวจสอบความเคลื่อนไหวของแอปพลิเคชัน (ไบนารี การกำหนดค่า ฯลฯ) ระหว่างคลัสเตอร์ (dev สเตจ ฯลฯ)
เปิดตัวการเปลี่ยนแปลงในแอปพลิเคชัน (ไบนารี การกำหนดค่า ฯลฯ) ในหลายคลัสเตอร์ OpenShift
ย้อนกลับการเปลี่ยนแปลงแอปพลิเคชันไปเป็นสถานะที่ทราบก่อนหน้านี้

กรณีการใช้งาน OpenShift GitOps

1. การใช้การเปลี่ยนแปลงจากที่เก็บ Git

ผู้ดูแลระบบคลัสเตอร์สามารถจัดเก็บการกำหนดค่าคลัสเตอร์ OpenShift ไว้ในที่เก็บ Git และนำไปใช้โดยอัตโนมัติเพื่อสร้างคลัสเตอร์ใหม่ได้อย่างง่ายดาย และนำการกำหนดค่าเหล่านั้นไปสู่สถานะที่เหมือนกับสถานะที่รู้จักซึ่งจัดเก็บไว้ในที่เก็บ Git

2. การซิงโครไนซ์กับ Secret Manager

ผู้ดูแลระบบยังจะได้รับประโยชน์จากความสามารถในการซิงโครไนซ์ออบเจ็กต์ลับของ OpenShift กับซอฟต์แวร์ที่เหมาะสม เช่น ห้องนิรภัย เพื่อจัดการโดยใช้เครื่องมือที่สร้างขึ้นเป็นพิเศษสำหรับสิ่งนี้

3. การควบคุมการกำหนดค่าดริฟท์

ผู้ดูแลระบบจะได้รับประโยชน์ก็ต่อเมื่อ OpenShift GitOps ระบุและเตือนเกี่ยวกับความแตกต่างระหว่างการกำหนดค่าจริงกับการกำหนดค่าที่ระบุในที่เก็บ เพื่อให้พวกเขาสามารถตอบสนองต่อการเลื่อนได้อย่างรวดเร็ว

4. การแจ้งเตือนเกี่ยวกับการกำหนดค่าดริฟท์

ซึ่งจะมีประโยชน์ในกรณีที่ผู้ดูแลระบบต้องการเรียนรู้อย่างรวดเร็วเกี่ยวกับกรณีของการกำหนดค่าที่ลอยไป เพื่อดำเนินมาตรการที่เหมาะสมอย่างรวดเร็วด้วยตนเอง

5. การซิงโครไนซ์การกำหนดค่าด้วยตนเองเมื่อดริฟท์

อนุญาตให้ผู้ดูแลระบบซิงโครไนซ์คลัสเตอร์ OpenShift กับที่เก็บ Git ในกรณีที่การกำหนดค่าลอยไป เพื่อให้คลัสเตอร์กลับสู่สถานะที่ทราบก่อนหน้านี้อย่างรวดเร็ว

6. การซิงโครไนซ์การกำหนดค่าอัตโนมัติเมื่อดริฟท์

ผู้ดูแลระบบยังสามารถกำหนดค่าคลัสเตอร์ OpenShift ให้ซิงโครไนซ์กับพื้นที่เก็บข้อมูลโดยอัตโนมัติเมื่อตรวจพบการเบี่ยงเบน เพื่อให้การกำหนดค่าคลัสเตอร์ตรงกับการกำหนดค่าใน Git เสมอ

7. หลายคลัสเตอร์ - ที่เก็บเดียว

ผู้ดูแลระบบสามารถจัดเก็บการกำหนดค่าของคลัสเตอร์ OpenShift ต่างๆ ไว้ในที่เก็บ Git เดียว และเลือกนำไปใช้ได้ตามต้องการ

8. ลำดับชั้นของการกำหนดค่าคลัสเตอร์ (สืบทอด)

ผู้ดูแลระบบสามารถตั้งค่าลำดับชั้นของการกำหนดค่าคลัสเตอร์ในพื้นที่เก็บข้อมูล (ระยะ ผลิตภัณฑ์ ผลงานแอป ฯลฯ พร้อมการสืบทอด) กล่าวอีกนัยหนึ่ง มันสามารถกำหนดได้ว่าควรใช้การกำหนดค่ากับคลัสเตอร์ตั้งแต่หนึ่งคลัสเตอร์ขึ้นไป

ตัวอย่างเช่น หากผู้ดูแลระบบตั้งค่าลำดับชั้น “คลัสเตอร์การผลิต (prod) → คลัสเตอร์ System X → คลัสเตอร์การผลิตของระบบ X” ในที่เก็บ Git การรวมกันของการกำหนดค่าต่อไปนี้จะถูกนำไปใช้กับคลัสเตอร์การผลิตของระบบ X:

การกำหนดค่าทั่วไปสำหรับคลัสเตอร์การผลิตทั้งหมด
กำหนดค่าสำหรับคลัสเตอร์ System X
กำหนดค่าสำหรับคลัสเตอร์การผลิตระบบ X

9. แทนที่เทมเพลตและการกำหนดค่า

ผู้ดูแลระบบสามารถแทนที่ชุดการกำหนดค่าที่สืบทอดมาและค่าต่างๆ ได้ เช่น เพื่อปรับแต่งการกำหนดค่าสำหรับคลัสเตอร์เฉพาะที่จะนำไปใช้

10. เลือกรวมและยกเว้นสำหรับการกำหนดค่า การกำหนดค่าแอปพลิเคชัน

ผู้ดูแลระบบสามารถกำหนดเงื่อนไขสำหรับแอปพลิเคชันหรือการไม่ใช้งานการกำหนดค่าบางอย่างกับคลัสเตอร์ที่มีคุณสมบัติบางอย่างได้

11. การสนับสนุนเทมเพลต

นักพัฒนาจะได้รับประโยชน์จากความสามารถในการเลือกวิธีกำหนดทรัพยากรแอปพลิเคชัน (Helm Chart, Kubernetes yaml ล้วนๆ ฯลฯ) เพื่อใช้รูปแบบที่เหมาะสมที่สุดสำหรับแอปพลิเคชันเฉพาะแต่ละรายการ

เครื่องมือ GitOps บนแพลตฟอร์ม OpenShift

อาร์โกซีดี

ArgoCD ใช้โมเดล External Resource Reconcile และนำเสนอ UI แบบรวมศูนย์สำหรับประสานความสัมพันธ์แบบหนึ่งต่อกลุ่มระหว่างคลัสเตอร์และที่เก็บ Git ข้อเสียของโปรแกรมนี้ ได้แก่ ไม่สามารถจัดการแอปพลิเคชันได้เมื่อ ArgoCD ไม่ทำงาน

เว็บไซต์อย่างเป็นทางการ

การไหล

Flux ใช้โมเดลการกระทบยอดทรัพยากรบนคลัสเตอร์ และด้วยเหตุนี้ จึงไม่มีการจัดการที่เก็บคำจำกัดความแบบรวมศูนย์ ซึ่งเป็นจุดอ่อน ในทางกลับกัน เนื่องจากขาดการรวมศูนย์ ความสามารถในการจัดการแอปพลิเคชันจึงยังคงอยู่ แม้ว่าคลัสเตอร์หนึ่งจะล้มเหลวก็ตาม

เว็บไซต์อย่างเป็นทางการ

การติดตั้ง ArgoCD บน OpenShift

ArgoCD มีอินเทอร์เฟซบรรทัดคำสั่งและเว็บคอนโซลที่ยอดเยี่ยม ดังนั้นเราจะไม่กล่าวถึง Flux และทางเลือกอื่นๆ ในที่นี้

หากต้องการปรับใช้ ArgoCD บนแพลตฟอร์ม OpenShift 4 ให้ทำตามขั้นตอนเหล่านี้ในฐานะผู้ดูแลระบบคลัสเตอร์:

การปรับใช้ส่วนประกอบ ArgoCD บนแพลตฟอร์ม OpenShift

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

การปรับปรุงเซิร์ฟเวอร์ ArgoCD เพื่อให้สามารถมองเห็นได้โดย OpenShift Route

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

การปรับใช้เครื่องมือ ArgoCD Cli

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

การเปลี่ยนรหัสผ่านผู้ดูแลระบบเซิร์ฟเวอร์ ArgoCD

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

หลังจากทำตามขั้นตอนเหล่านี้แล้ว คุณสามารถทำงานกับ ArgoCD Server ผ่านทางเว็บคอนโซล ArgoCD WebUI หรือเครื่องมือบรรทัดคำสั่ง ArgoCD Cli
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - มันไม่สายเกินไป

“ รถไฟออกไปแล้ว” - นี่คือสิ่งที่พวกเขาพูดเกี่ยวกับสถานการณ์เมื่อพลาดโอกาสในการทำอะไรบางอย่าง ในกรณีของ OpenShift ความปรารถนาที่จะเริ่มใช้แพลตฟอร์มใหม่สุดเจ๋งนี้ทันทีมักจะสร้างสถานการณ์เช่นนี้ขึ้นมาด้วยการจัดการและการบำรุงรักษาเส้นทาง การปรับใช้ และออบเจ็กต์ OpenShift อื่นๆ แต่โอกาสมักจะหายไปหมดเลยเหรอ?

ต่อเนื่องชุดบทความเกี่ยวกับ GitOpsวันนี้เราจะแสดงวิธีแปลงแอปพลิเคชันที่ทำด้วยมือและทรัพยากรของแอปพลิเคชันให้เป็นกระบวนการที่เครื่องมือ GitOps จัดการทุกอย่าง ในการดำเนินการนี้ ขั้นแรกเราจะปรับใช้แอปพลิเคชัน httpd ด้วยตนเอง ภาพหน้าจอด้านล่างแสดงวิธีที่เราสร้างเนมสเปซ การปรับใช้ และบริการ จากนั้นแสดงบริการนี้เพื่อสร้างเส้นทาง

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

ดังนั้นเราจึงมีแอปพลิเคชันที่ทำด้วยมือ ตอนนี้จำเป็นต้องถ่ายโอนภายใต้การจัดการ GitOps โดยไม่สูญเสียความพร้อมใช้งาน กล่าวโดยย่อคือ:

สร้างที่เก็บ Git สำหรับโค้ด
เราส่งออกออบเจ็กต์ปัจจุบันของเราและอัปโหลดไปยังที่เก็บ Git
การเลือกและปรับใช้เครื่องมือ GitOps
เราเพิ่มพื้นที่เก็บข้อมูลของเราลงในชุดเครื่องมือนี้
เรากำหนดแอปพลิเคชันในชุดเครื่องมือ GitOps ของเรา
เราทำการทดสอบการทำงานของแอปพลิเคชันโดยใช้ชุดเครื่องมือ GitOps
เราซิงโครไนซ์วัตถุโดยใช้ชุดเครื่องมือ GitOps
เปิดใช้งานการตัดและการซิงโครไนซ์ออบเจ็กต์อัตโนมัติ

ดังที่ได้กล่าวไปแล้วในครั้งก่อน статьеใน GitOps มีแหล่งข้อมูลเดียวเท่านั้นเกี่ยวกับออบเจ็กต์ทั้งหมดในคลัสเตอร์ Kubernetes - ที่เก็บ Git ต่อไป เราจะดำเนินการต่อจากสมมติฐานที่ว่าองค์กรของคุณใช้พื้นที่เก็บข้อมูล Git อยู่แล้ว อาจเป็นสาธารณะหรือส่วนตัวก็ได้ แต่ต้องเข้าถึงได้โดยคลัสเตอร์ Kubernetes นี่อาจเป็นพื้นที่เก็บข้อมูลเดียวกันกับรหัสแอปพลิเคชัน หรือพื้นที่เก็บข้อมูลแยกต่างหากที่สร้างขึ้นเพื่อการปรับใช้โดยเฉพาะ ขอแนะนำให้มีสิทธิ์ที่เข้มงวดในพื้นที่เก็บข้อมูล เนื่องจากความลับ เส้นทาง และสิ่งที่เกี่ยวข้องกับความปลอดภัยอื่นๆ จะถูกจัดเก็บไว้ที่นั่น

ในตัวอย่างของเรา เราจะสร้างพื้นที่เก็บข้อมูลสาธารณะใหม่บน GitHub คุณสามารถเรียกมันว่าอะไรก็ได้ที่คุณต้องการ เราใช้ชื่อบล็อกโพสต์

หากไฟล์อ็อบเจ็กต์ YAML ไม่ได้ถูกจัดเก็บไว้ในเครื่องหรือใน Git คุณจะต้องใช้ไบนารี oc หรือ kubectl ในภาพหน้าจอด้านล่าง เรากำลังขอ YAML สำหรับเนมสเปซ การปรับใช้ บริการ และเส้นทางของเรา ก่อนหน้านี้ เราได้โคลนพื้นที่เก็บข้อมูลที่สร้างขึ้นใหม่และใส่ซีดีลงไป

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

ตอนนี้เรามาแก้ไขไฟล์ Deployment.yaml เพื่อลบฟิลด์ที่ Argo CD ไม่สามารถซิงค์ได้

sed -i '/sgeneration: .*/d' deployment.yaml

นอกจากนี้จำเป็นต้องเปลี่ยนเส้นทาง ก่อนอื่นเราจะตั้งค่าตัวแปรหลายบรรทัดแล้วแทนที่ ingress: null ด้วยเนื้อหาของตัวแปรนั้น

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

ดังนั้นเราจึงแยกไฟล์ออก เหลือเพียงบันทึกลงในที่เก็บ Git หลังจากนั้นพื้นที่เก็บข้อมูลนี้จะกลายเป็นแหล่งข้อมูลเพียงแห่งเดียว และไม่ควรทำการเปลี่ยนแปลงออบเจ็กต์ด้วยตนเองโดยเด็ดขาด

git commit -am ‘initial commit of objects’
git push origin master

นอกจากนี้ เรายังดำเนินการต่อจากข้อเท็จจริงที่ว่าคุณได้ปรับใช้ ArgoCD แล้ว (วิธีดำเนินการ - ดูก่อนหน้า เสา). ดังนั้น เราจะเพิ่มพื้นที่เก็บข้อมูลที่เราสร้างขึ้นลงใน Argo CD ซึ่งมีโค้ดแอปพลิเคชันจากตัวอย่างของเรา เพียงตรวจสอบให้แน่ใจว่าคุณระบุพื้นที่เก็บข้อมูลที่แน่นอนที่คุณสร้างไว้ก่อนหน้านี้

argocd repo add https://github.com/cooktheryan/blogpost

ตอนนี้เรามาสร้างแอปพลิเคชันกันดีกว่า แอปพลิเคชันจะตั้งค่าเพื่อให้ชุดเครื่องมือ GitOps เข้าใจว่าพื้นที่เก็บข้อมูลและเส้นทางใดที่จะใช้ OpenShift ใดที่จำเป็นในการจัดการอ็อบเจ็กต์ จำเป็นต้องใช้สาขาเฉพาะของพื้นที่เก็บข้อมูล และทรัพยากรควรซิงค์อัตโนมัติหรือไม่

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

เมื่อระบุแอปพลิเคชันใน Argo CD แล้ว ชุดเครื่องมือจะเริ่มตรวจสอบอ็อบเจ็กต์ที่ปรับใช้แล้วโดยเทียบกับคำจำกัดความในที่เก็บ ในตัวอย่างของเรา การซิงค์อัตโนมัติและการล้างข้อมูลถูกปิดใช้งาน ดังนั้นองค์ประกอบจึงยังไม่เปลี่ยนแปลง โปรดทราบว่าในอินเทอร์เฟซ Argo CD แอปพลิเคชันของเราจะมีสถานะ "ไม่ซิงค์กัน" เนื่องจาก ArgoCD ไม่มีป้ายกำกับให้
นี่คือสาเหตุที่เมื่อเราเริ่มการซิงโครไนซ์ในภายหลังเล็กน้อย ออบเจ็กต์จะไม่ถูกปรับใช้อีกครั้ง

ตอนนี้เรามาทำการทดสอบเพื่อให้แน่ใจว่าไม่มีข้อผิดพลาดในไฟล์ของเรา

argocd app sync simple-app --dry-run

หากไม่มีข้อผิดพลาด คุณสามารถดำเนินการซิงโครไนซ์ต่อไปได้

argocd app sync simple-app

หลังจากรันคำสั่ง argocd get บนแอปพลิเคชันของเราแล้ว เราควรเห็นว่าสถานะแอปพลิเคชันเปลี่ยนเป็น Healthy หรือ Synced ซึ่งหมายความว่าทรัพยากรทั้งหมดในที่เก็บ Git จะสอดคล้องกับทรัพยากรที่ถูกปรับใช้แล้ว

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...

ตอนนี้คุณสามารถเปิดใช้งานการซิงค์อัตโนมัติและการล้างข้อมูลเพื่อให้แน่ใจว่าไม่มีการสร้างสิ่งใดด้วยตนเอง และทุกครั้งที่สร้างหรืออัปเดตออบเจ็กต์ไปยังที่เก็บ การปรับใช้จะเกิดขึ้น

argocd app set simple-app --sync-policy automated --auto-prune

ดังนั้นเราจึงประสบความสำเร็จในการนำแอปพลิเคชันภายใต้การควบคุม GitOps ซึ่งในตอนแรกไม่ได้ใช้ GitOps แต่อย่างใด

ที่มา: will.com

ข้อมูลเบื้องต้นเกี่ยวกับ GitOps สำหรับ OpenShift