
HashiCorp แสดงโครงการใหม่ บน . ใช้ไฟล์ตาม HCL เพื่ออธิบายการสร้าง การจัดส่ง และการเผยแพร่แอปพลิเคชันสำหรับแพลตฟอร์มคลาวด์ต่างๆ ตั้งแต่ Kubernetes ไปจนถึง AWS และ Google Cloud Run ให้นึกถึง Waypoint ที่ Terraform และ Vagrant รวบรวมเพื่ออธิบายกระบวนการสร้าง จัดส่ง และเผยแพร่แอปพลิเคชันของคุณ
ตามรูปแบบ HashiCorp ได้เปิดตัว Waypoint เป็นโอเพ่นซอร์สและมาพร้อมกับตัวอย่างมากมาย ระดับของ orchestrator นั้นขึ้นอยู่กับคุณ Waypoint มาพร้อมกับไฟล์ปฏิบัติการที่คุณสามารถเรียกใช้งานได้โดยตรงบนแล็ปท็อปหรือจากเครื่องมือ CI/CD orchestration ที่คุณเลือก เป้าหมายการปรับใช้แอปพลิเคชันก็ขึ้นอยู่กับคุณเช่นกัน เนื่องจาก Waypoint รองรับ Kubernetes, Docker, Google Cloud Run, AWS ECS และอื่นๆ
อ่านแล้วสุดยอดครับ และที่ชิคที่สุด แอปพลิเคชันที่จัดทำโดย HashiCorp เราตัดสินใจที่จะตรวจสอบการประสาน Waypoint ด้วย GitLab CI/CD ให้ละเอียดยิ่งขึ้น ในการทำเช่นนี้ เราจะนำแอปพลิเคชัน Node.js แบบธรรมดาที่ทำงานบน AWS ECS จากที่เก็บตัวอย่าง
หลังจากโคลนที่เก็บแล้ว มาดูโครงสร้างของแอปพลิเคชันที่แสดงหน้าเดียว:

ดังที่คุณอาจสังเกตเห็นว่าไม่มี Dockerfile ในโปรเจ็กต์นี้ พวกมันไม่ได้ถูกเพิ่มเข้ามาในตัวอย่างเพราะเราไม่ต้องการมันจริงๆ เพราะ Waypoint จะดูแลพวกมันแทนเรา มาดูไฟล์กันดีกว่า waypoint.hclเพื่อทำความเข้าใจว่ามันจะทำอะไร:
project = "example-nodejs"
app "example-nodejs" {
labels = {
"service" = "example-nodejs",
"env" = "dev"
}
build {
use "pack" {}
registry {
use "aws-ecr" {
region = "us-east-1"
repository = "waypoint-gitlab"
tag = "latest"
}
}
}
deploy {
use "aws-ecs" {
region = "us-east-1"
memory = "512"
}
}
}ในระหว่างขั้นตอนการสร้าง Waypoint จะใช้ Cloud Native Buildpacks () เพื่อกำหนดภาษาการเขียนโปรแกรมของโปรเจ็กต์และสร้างอิมเมจ Docker โดยไม่ต้องใช้ Dockerfile โดยหลักการแล้ว นี่เป็นเทคโนโลยีเดียวกับที่ใช้โดย GitLab ในบางส่วน ในขั้นตอนการสร้างอัตโนมัติ เป็นเรื่องดีที่เห็นว่า CNB ของ CNCF ได้รับการยอมรับจากผู้ใช้ในอุตสาหกรรมมากขึ้นเรื่อยๆ
เมื่อสร้างอิมเมจแล้ว Waypoint จะอัปโหลดไปยังรีจิสทรี AWS ECR ของเราโดยอัตโนมัติเพื่อให้พร้อมจัดส่ง ในตอนท้ายของการประกอบขั้นตอนการจัดส่งใช้ เพื่อปรับใช้แอปพลิเคชันของเรากับบัญชี AWS ของเรา
จากแล็ปท็อปของฉันมันง่าย ฉันใส่ Waypoint ซึ่งได้รับการตรวจสอบสิทธิ์แล้วในบัญชี AWS ของฉัน และมัน "ใช้งานได้จริง" แต่จะเกิดอะไรขึ้นหากฉันต้องการไปไกลกว่าแล็ปท็อป หรือบางทีฉันต้องการทำให้การปรับใช้นี้เป็นไปโดยอัตโนมัติโดยเป็นส่วนหนึ่งของไปป์ไลน์ CI/CD โดยรวมของฉันที่การทดสอบการรวมปัจจุบัน การทดสอบความปลอดภัย และอื่น ๆ ของฉันทำงานอยู่ นี่คือส่วนหนึ่งของเรื่องราวที่ GitLab CI/CD เข้ามา!
NB หากคุณเพียงแค่วางแผนที่จะใช้ CI / CD หรือต้องการเริ่มใช้แนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างไปป์ไลน์ โปรดให้ความสนใจกับหลักสูตร Slurm ใหม่ . ตอนนี้มีจำหน่ายในราคาพรีออเดอร์
Waypoint ใน GitLab CI/CD
เพื่อจัดการทั้งหมดนี้ใน GitLab CI/CD มาดูกันว่าเราต้องการอะไรในไฟล์ของเรา .gitlab-ci.yml:
- ก่อนอื่น คุณต้องมีอิมเมจพื้นฐานสำหรับใช้งาน Waypoint สามารถทำงานได้บนระบบปฏิบัติการใดก็ได้ Linuxมันต้องการแค่ Docker เท่านั้น ดังนั้นเราจึงสามารถเรียกใช้จากอิมเมจ Docker ทั่วไปได้
- ถัดไป คุณต้องติดตั้ง Waypoint ลงในภาพนี้ ในอนาคตเราอาจรวบรวม และบรรจุกระบวนการนี้ด้วยตัวคุณเอง
- ในที่สุดเราจะเรียกใช้คำสั่ง Waypoint
ข้างต้นคือทุกสิ่งที่ไปป์ไลน์ของเราต้องใช้เพื่อเรียกใช้สคริปต์ที่จำเป็นในการดำเนินการปรับใช้ แต่หากต้องการปรับใช้กับ AWS เราต้องการอีกสิ่งหนึ่ง: เราต้องลงชื่อเข้าใช้บัญชี AWS ของเรา ในคำอธิบาย Waypoint เกี่ยวกับการรับรองความถูกต้องและการอนุญาต HashiCorp ยังเปิดตัวโครงการที่น่าประทับใจในสัปดาห์นี้ . แต่สำหรับตอนนี้ เราสามารถรับและจัดการการรับรองความถูกต้องและการให้สิทธิ์ได้เอง
มีหลายตัวเลือกสำหรับการรับรองความถูกต้อง GitLab CICD บน AWS ตัวเลือกแรกคือการใช้ในตัว . ไม่เป็นไร ถ้าทีมของคุณใช้ห้องนิรภัยสำหรับการจัดการข้อมูลประจำตัวอยู่แล้ว อีกวิธีหนึ่งที่ใช้ได้ผลหากทีมของคุณจัดการการอนุญาตโดยใช้ AWS IAM คือการตรวจสอบว่ามีการเรียกใช้งานการส่งมอบผ่าน ที่ได้รับอนุญาตให้เริ่มการปรับใช้ผ่าน IAM แต่ถ้าคุณต้องการทำความคุ้นเคยกับ Waypoint และต้องการทำอย่างรวดเร็ว ตัวเลือกสุดท้ายคือเพิ่ม AWS API และรหัสลับของคุณไปยัง AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY.
วางทั้งหมดเข้าด้วยกัน
เมื่อเราทราบการยืนยันตัวตนแล้ว ก็เริ่มได้เลย! สุดท้ายของเรา .gitlab-ci.yml มีลักษณะเช่นนี้:
waypoint:
image: docker:latest
stage: build
services:
- docker:dind
# Define environment variables, e.g. `WAYPOINT_VERSION: '0.1.1'`
variables:
WAYPOINT_VERSION: ''
WAYPOINT_SERVER_ADDR: ''
WAYPOINT_SERVER_TOKEN: ''
WAYPOINT_SERVER_TLS: '1'
WAYPOINT_SERVER_TLS_SKIP_VERIFY: '1'
script:
- wget -q -O /tmp/waypoint.zip https://releases.hashicorp.com/waypoint/${WAYPOINT_VERSION}/waypoint_${WAYPOINT_VERSION}_linux_amd64.zip
- unzip -d /usr/local/bin /tmp/waypoint.zip
- rm -rf /tmp/waypoint*
- waypoint init
- waypoint build
- waypoint deploy
- waypoint releaseคุณจะเห็นว่าเราเริ่มต้นด้วยภาพ docker:latest และตั้งค่าตัวแปรสภาพแวดล้อมบางอย่างที่จำเป็นสำหรับ Waypoint ในบท script เราดาวน์โหลดไฟล์ปฏิบัติการ Waypoint ล่าสุดและใส่เข้าไป /usr/local/bin. เนื่องจากนักวิ่งของเราได้รับอนุญาตใน AWS แล้ว เราจึงเรียกใช้ waypoint init, build, deploy и release.
ผลลัพธ์ของงานบิลด์จะแสดงจุดสิ้นสุดที่เราเรียกใช้แอปพลิเคชัน:

Waypoint หนึ่งใน ซึ่งทำงานได้ดีกับ GitLab ตัวอย่างเช่น นอกเหนือจากการส่งมอบแอปพลิเคชันแล้ว เรายังสามารถจัดการโครงสร้างพื้นฐานพื้นฐานด้วย . เพื่อสร้างมาตรฐานความปลอดภัย SDLC เรายังสามารถนำไปใช้ได้ สำหรับการจัดการความลับและโทเค็นในไปป์ไลน์ CI/CD มอบโซลูชันที่สมบูรณ์สำหรับนักพัฒนาและผู้ดูแลระบบที่พึ่งพาการจัดการความลับในการพัฒนา ทดสอบ และใช้งานจริง
โซลูชันร่วมกันที่พัฒนาโดย HashiCorp และ GitLab ช่วยให้บริษัทต่าง ๆ ค้นพบวิธีที่ดีที่สุดในการพัฒนาแอปพลิเคชัน โดยรับประกันการจัดการห่วงโซ่อุปทานและโครงสร้างพื้นฐานที่สอดคล้องกัน Waypoint ได้ก้าวไปอีกขั้นในทิศทางที่ถูกต้อง และเราหวังว่าจะพัฒนาโครงการต่อไป คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับ Waypoint ยังควรค่าแก่การสำรวจ и โครงการ. เราได้เพิ่มความรู้ของเราไปที่ . หากอยากลองทำเองสามารถดูตัวอย่างการทำงานฉบับสมบูรณ์ได้ที่ .
คุณสามารถเข้าใจหลักการของ CI / CD เชี่ยวชาญรายละเอียดปลีกย่อยทั้งหมดของการทำงานกับ Gitlab CI และเริ่มใช้แนวทางปฏิบัติที่ดีที่สุดโดยจบหลักสูตรวิดีโอ ... เข้าร่วมกับเรา!
ที่มา: will.com
