nomad driver containerd
Version 0.9.4
เรากำลังมองหาผู้มีส่วนร่วมและผู้ดูแลโครงการนี้อย่างแข็งขัน หากคุณมีประสบการณ์ในคอนเทนเนอร์ภายในเช่น cgroups เนมสเปซหรือมีส่วนร่วมในโครงการโอเพนซอร์ซรอบ ๆ คอนเทนเนอร์เช่น docker , containerd , nerdctl , podman ฯลฯ หรือสร้างเครื่องมือที่เกี่ยวข้องกับการจัดการกับตู้คอนเทนเนอร์และมีความสนใจในการสนับสนุนโครงการนี้ เป็นที่ต้องการประสบการณ์ของ Golang แต่ไม่จำเป็น
โปรดติดต่อฉัน @_shishir_m หรือเปิดปัญหาในที่เก็บนี้พร้อมรายละเอียดการติดต่อของคุณหากคุณสนใจที่จะมีส่วนร่วมในโครงการนี้
ไดรเวอร์งาน Nomad สำหรับการเปิดตัวคอนเทนเนอร์โดยใช้ containerd
containerd (containerd.io) เป็น daemon คอนเทนเนอร์ที่มีน้ำหนักเบาสำหรับการทำงานและการจัดการวงจรชีวิตคอนเทนเนอร์
Docker Daemon ยังใช้ containerd
dockerd (docker daemon) --> containerd --> containerd-shim --> runc
Nomad-Driver-Containerd ช่วยให้ไคลเอนต์ Nomad เปิดตัวคอนเทนเนอร์โดยตรงโดยใช้ containerd โดยไม่ต้อง Docker!
Docker Daemon ไม่จำเป็นต้องใช้ในระบบโฮสต์
ตรวจสอบให้แน่ใจว่า $ Gopath ของคุณติดตั้งอย่างถูกต้อง
$ mkdir -p $GOPATH/src/github.com/Roblox
$ cd $GOPATH/src/github.com/Roblox
$ git clone [email protected]:Roblox/nomad-driver-containerd.git
$ cd nomad-driver-containerd
$ make build (This will build your containerd-driver binary)
หากคุณต้องการรวบรวม arm64 คุณสามารถเรียกใช้:
make -f Makefile.arm64
$ vagrant up
หรือ vagrant provision หาก Vagrant VM กำลังทำงานอยู่แล้ว
เมื่อการตั้งค่า ( vagrant up หรือ vagrant provision ) เสร็จสมบูรณ์และ Nomad Server เปิดใช้งานแล้วคุณสามารถตรวจสอบไดรเวอร์งานที่ลงทะเบียนได้ (ซึ่งจะแสดง containerd-driver ) โดยใช้:
$ nomad node status (Note down the <node_id>)
$ nomad node status <node_id> | grep containerd-driver
หมายเหตุ: setup.sh เป็นส่วนหนึ่งของการตั้งค่า Vagrant และไม่ควรดำเนินการโดยตรง
มีตัวอย่างงานน้อยในไดเรกทอรี example
$ nomad job run <job_name.nomad>
จะเปิดงาน
คำแนะนำโดยละเอียดเพิ่มเติมอยู่ใน example README.md
ในการโต้ตอบกับ images และ containers โดยตรงคุณสามารถใช้ nerdctl ซึ่งเป็น CLI ที่เข้ากันได้กับ Docker สำหรับ containerd nerdctl ได้รับการติดตั้งแล้วใน Vagrant VM AT /usr/local/bin
กำหนดค่าไดรเวอร์
| ตัวเลือก | พิมพ์ | ที่จำเป็น | ค่าเริ่มต้น | คำอธิบาย |
|---|---|---|---|---|
| เปิดใช้งาน | บูล | เลขที่ | จริง | เปิดใช้งาน/ปิดการใช้งานไดรเวอร์งาน |
| containerd_runtime | สาย | ใช่ | N/A | รันไทม์สำหรับ containerd เช่น io.containerd.runc.v1 หรือ io.containerd.runc.v2 |
| Stats_interval | สาย | เลขที่ | 1s | ช่วงเวลาสำหรับการรวบรวม TaskStats |
| allow_privileged | บูล | เลขที่ | จริง | หากตั้งค่าเป็น false ไดรเวอร์จะปฏิเสธงานที่ได้รับสิทธิพิเศษ |
| รับรองความถูกต้อง | ปิดกั้น | เลขที่ | N/A | ให้การรับรองความถูกต้องสำหรับรีจิสทรีส่วนตัว ดูการรับรองความถูกต้องสำหรับรายละเอียดเพิ่มเติม |
การกำหนดค่างาน
| ตัวเลือก | พิมพ์ | ที่จำเป็น | คำอธิบาย |
|---|---|---|---|
| ภาพ | สาย | ใช่ | OCI Image (Docker ยังเข้ากันได้กับ OCI) สำหรับคอนเทนเนอร์ของคุณ |
| image_pull_timeout | สาย | เลขที่ | ระยะเวลาที่ควบคุมระยะเวลาที่ containerd-driver จะรอก่อนที่จะยกเลิกการดึงภาพ OCI ที่ก้าวหน้าตามความคืบหน้าตามที่ระบุไว้ใน image ค่าเริ่มต้นเป็น "5m" |
| สั่งการ | สาย | เลขที่ | คำสั่งเพื่อแทนที่คำสั่งที่กำหนดไว้ในภาพ |
| อาร์กอน | [] สตริง | เลขที่ | อาร์กิวเมนต์กับคำสั่ง |
| จุดเข้า | [] สตริง | เลขที่ | รายการสตริงแทนที่จุดเข้าใช้ของภาพ |
| CWD | สาย | เลขที่ | ระบุไดเรกทอรีการทำงานปัจจุบันสำหรับกระบวนการคอนเทนเนอร์ของคุณ หากไดเรกทอรีไม่มีอยู่จะมีการสร้างขึ้นสำหรับคุณ |
| มีสิทธิพิเศษ | บูล | เลขที่ | เรียกใช้คอนเทนเนอร์ในโหมดพิเศษ คอนเทนเนอร์ของคุณจะมีความสามารถทั้งหมดของ Linux เมื่อทำงานในโหมดที่ได้รับการยกเว้น |
| pids_limit | INT64 | เลขที่ | ค่าจำนวนเต็มที่ระบุขีด จำกัด PID สำหรับคอนเทนเนอร์ ค่าเริ่มต้นเป็นไม่ จำกัด |
| pid_mode | สาย | เลขที่ | host หรือไม่ตั้งค่า (ค่าเริ่มต้น) ตั้งค่าเป็น host เพื่อแบ่งปันเนมสเปซ PID กับโฮสต์ |
| ชื่อโฮสต์ | สาย | เลขที่ | ชื่อโฮสต์เพื่อกำหนดให้กับคอนเทนเนอร์ เมื่อเปิดตัวงานมากกว่าหนึ่งงาน (โดยใช้ count ) กับชุดตัวเลือกนี้คอนเทนเนอร์ทุกรายการที่เริ่มงานจะมีชื่อโฮสต์เดียวกัน |
| host_dns | บูล | เลขที่ | ค่าเริ่มต้น ( true ) โดยค่าเริ่มต้นคอนเทนเนอร์ที่เปิดตัวโดยใช้ containerd-driver จะใช้โฮสต์ /etc/resolv.conf สิ่งนี้คล้ายกับ docker behavior อย่างไรก็ตามหากคุณไม่ต้องการใช้โฮสต์ DNS คุณสามารถปิดการตั้งค่าสถานะนี้ได้โดยการตั้งค่า host_dns=false |
| seccomp | บูล | เลขที่ | เปิดใช้งานโปรไฟล์ SECCOMP เริ่มต้น รายการของ allowed syscalls |
| seccomp_profile | สาย | เลขที่ | PATH ไปยังโปรไฟล์ SECCOMP ที่กำหนดเอง seccomp จะต้องตั้งค่าเป็น true เพื่อใช้ seccomp_profile โปรไฟล์ docker SECCOMP เริ่มต้น here สามารถใช้เป็นข้อมูลอ้างอิงและแก้ไขเพื่อสร้างโปรไฟล์ SECCOMP ที่กำหนดเอง |
| shm_size | สาย | เลขที่ | ขนาดของ /dev /shm เช่น "128m" หากคุณต้องการ 128 MB /dev /shm |
| sysctl | แผนที่ [สตริง] สตริง | เลขที่ | แผนที่คีย์-ค่าของการกำหนดค่า SYSCTL เพื่อตั้งค่าไปยังคอนเทนเนอร์เมื่อเริ่มต้น |
| READONLY_ROOTFS | บูล | เลขที่ | ระบบไฟล์รูทคอนเทนเนอร์จะอ่านอย่างเดียว |
| host_network | บูล | เลขที่ | เปิดใช้งานเครือข่ายโฮสต์ สิ่งนี้เทียบเท่ากับ --net=host ใน Docker |
| extra_hosts | [] สตริง | เลขที่ | รายการโฮสต์ที่กำหนดเป็นโฮสต์: IP เพื่อเพิ่ม /etc /hosts |
| cap_add | [] สตริง | เลขที่ | เพิ่มความสามารถของแต่ละบุคคล |
| cap_drop | [] สตริง | เลขที่ | ลดความสามารถในการ Invidual |
| อุปกรณ์ | [] สตริง | เลขที่ | รายการอุปกรณ์ที่จะสัมผัสกับคอนเทนเนอร์ |
| รับรองความถูกต้อง | ปิดกั้น | เลขที่ | ให้การรับรองความถูกต้องสำหรับรีจิสทรีส่วนตัว ดูการรับรองความถูกต้องสำหรับรายละเอียดเพิ่มเติม |
| ติดตั้ง | []ปิดกั้น | เลขที่ | รายการของเมานต์ที่จะติดตั้งในคอนเทนเนอร์ รองรับการติดตั้งประเภทระดับเสียงการผูกและ TMPFS รองรับ mount options สไตล์ FSTAB |
ติดตั้งบล็อก
-
- พิมพ์ (สตริง) (ไม่บังคับ): ค่าที่รองรับคือ volume , bind หรือ tmpfs ค่าเริ่มต้น: ระดับเสียง
- เป้าหมาย (สตริง) (จำเป็น): เส้นทางเป้าหมายในคอนเทนเนอร์
- แหล่งที่มา (สตริง) (ไม่บังคับ): เส้นทางต้นทางบนโฮสต์
- ตัวเลือก ([] สตริง) (ไม่บังคับ): mount options สไตล์ FSTAB หมายเหตุ : สำหรับการติดตั้งผูกจำเป็นต้องใช้ rbind และ ro อย่างน้อย
-
ผูกตัวอย่างเมาท์
mounts = [
{
type = "bind"
target = "/target/t1"
source = "/src/s1"
options = ["rbind", "ro"]
}
]
ใน additon volume_mount stanza ยังตัวเลือก mounts Task Config
ดู example job สำหรับ volume_mount
ตัวอย่างโปรไฟล์ Seccomp ที่กำหนดเอง
โปรไฟล์ docker SecComp เริ่มต้นที่พบ here สามารถดาวน์โหลดได้และแก้ไข (โดยการลบ/เพิ่ม SyScalls) เพื่อสร้างโปรไฟล์ SECCOMP ที่กำหนดเอง
โปรไฟล์ SECCOMP ที่กำหนดเองสามารถบันทึกได้ภายใต้ /opt/seccomp/seccomp.json บนโหนดไคลเอนต์ NOMAD
งาน Nomad สามารถเปิดใช้งานได้โดยใช้โปรไฟล์ SECCOMP ที่กำหนดเองนี้
config {
seccomp = true
seccomp_profile = "/opt/seccomp/seccomp.json"
}
ตัวอย่าง sysctl
config {
sysctl = {
"net.core.somaxconn" = "16384"
"net.ipv4.ip_forward" = "1"
}
}
auth Stanza อนุญาตให้คุณตั้งค่าข้อมูลรับรองสำหรับรีจิสทรีส่วนตัวของคุณเช่นหากคุณต้องการดึงภาพจากที่เก็บส่วนตัวใน Docker Hub
auth Stanza สามารถตั้งค่าได้ทั้งใน Driver Config หรือ Task Config หรือทั้งสองอย่าง
หากตั้งค่าไว้ที่ทั้งสองสถานที่ Task Config Auth จะมีความสำคัญกว่า Driver Config
หมายเหตุ : ในตัวอย่างด้านล่าง user และ pass เป็นเพียงค่าตัวยึดตำแหน่งซึ่งจำเป็นต้องถูกแทนที่ด้วย username และ password ผ่านจริงเมื่อระบุข้อมูลรับรอง ด้านล่าง auth Stanza สามารถใช้สำหรับทั้ง Driver Config และ Task Config
auth {
username = "user"
password = "pass"
}
nomad-driver-containerd รองรับเครือข่าย โฮสต์ และ สะพาน
หมายเหตุ: host และ bridge เป็นตัวเลือกพิเศษร่วมกันและควรใช้เพียงอย่างเดียวเท่านั้น
เครือข่าย โฮสต์ สามารถเปิดใช้งานได้โดยการตั้งค่า host_network เป็น true ในการกำหนดค่างานของข้อมูลจำเพาะของงาน (ดูภายใต้ Supported options )
Bridge Network สามารถเปิดใช้งานได้โดยการตั้งค่า stanza network ในส่วนกลุ่มงานของข้อมูลจำเพาะงาน
network {
mode = "bridge"
}
คุณต้องติดตั้งปลั๊กอิน CNI บนโหนดไคลเอนต์ Nomad ภายใต้ /opt/cni/bin ก่อนที่คุณจะสามารถใช้เครือ bridge
คำแนะนำสำหรับการติดตั้งปลั๊กอิน CNI
$ curl -L -o cni-plugins.tgz https://github.com/containernetworking/plugins/releases/download/v0.8.6/cni-plugins-linux-amd64-v0.8.6.tgz
$ sudo mkdir -p /opt/cni/bin
$ sudo tar -C /opt/cni/bin -xzf cni-plugins.tgz
นอกจากนี้ตรวจสอบให้แน่ใจว่าการกระจายระบบปฏิบัติการ Linux ของคุณได้รับการกำหนดค่าเพื่ออนุญาตให้มีการรับส่งข้อมูลคอนเทนเนอร์ผ่านเครือข่ายบริดจ์ที่จะถูกกำหนดเส้นทางผ่าน iptables tunables เหล่านี้สามารถตั้งค่าได้ดังนี้:
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-arptables
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
ในการรักษาการตั้งค่าเหล่านี้เมื่อเริ่มต้นโหนดไคลเอนต์ Nomad ให้เพิ่มไฟล์รวมถึงไฟล์ต่อไปนี้ถึง /etc/sysctl.d/ หรือลบไฟล์การแจกแจง Linux ของคุณใส่ในไดเรกทอรีนั้น
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
Nomad รองรับการทำแผนที่พอร์ตทั้ง แบบคงที่ และ แบบไดนามิก
สามารถเพิ่มการทำแผนที่พอร์ตแบบคงที่ใน Stanza network
network {
mode = "bridge"
port "lb" {
static = 8889
to = 8889
}
}
ที่นี่พอร์ต host 8889 ถูกแมปกับพอร์ต container 8889
หมายเหตุ : พอร์ตคงที่มักไม่แนะนำยกเว้น system หรืองานพิเศษเช่นโหลดบัลแลนเซอร์
การแมปพอร์ตแบบไดนามิกยังเปิดใช้งานใน network บท
network {
mode = "bridge"
port "http" {
to = 8080
}
}
ที่นี่ Nomad จะจัดสรรพอร์ตแบบไดนามิกบน host และพอร์ตนั้นจะถูกแมปกับ 8080 ในคอนเทนเนอร์
นอกจากนี้คุณยังสามารถอ่านเพิ่มเติมเกี่ยวกับ network stanza ใน nomad official documentation
Nomad กำหนดการเวิร์กโหลดประเภทต่าง ๆ ในกลุ่มโฮสต์ทั่วไป ด้วยเหตุนี้จึงไม่ทราบตำแหน่งล่วงหน้าและคุณจะต้องใช้การค้นพบบริการเพื่อเชื่อมต่องานกับบริการอื่น ๆ ที่ปรับใช้ในคลัสเตอร์ของคุณ Nomad รวมเข้ากับกงสุลเพื่อให้บริการการค้นพบและการตรวจสอบ
สามารถเพิ่มสแตนซ่า service ลงในข้อมูลจำเพาะงานของคุณเพื่อเปิดใช้งานการค้นหาบริการ
Service Stanza สั่งให้ Nomad ลงทะเบียนบริการด้วยกงสุล
หากคุณกำลังทำการทดสอบในเครื่องให้ใช้ vagrant VM ที่ให้ไว้ในที่เก็บ
$ vagrant up
$ vagrant ssh containerd-linux
$ sudo make test
หมายเหตุ : สิ่งเหล่านี้เป็นการทดสอบการทำลายล้างและสามารถออกจากระบบในสถานะที่เปลี่ยนแปลงได้
ขอแนะนำอย่างยิ่งให้เรียกใช้การทดสอบเหล่านี้เป็นส่วนหนึ่งของระบบ CI/CD เช่น circleci หรือในโครงสร้างพื้นฐานที่ไม่เปลี่ยนรูปเช่น Vagrant VM
นอกจากนี้คุณยังสามารถเรียกใช้การทดสอบแต่ละครั้งโดยระบุชื่อทดสอบ เช่น
$ cd tests
$ sudo ./run_tests.sh 001-test-redis.sh
make clean
สิ่งนี้จะลบไบนารีของคุณ: containerd-driver
vagrant destroy
สิ่งนี้จะทำลาย Vagrant VM ของคุณ
ubuntu (> = 16.04)
ลิขสิทธิ์ 2020 Roblox Corporation
ได้รับใบอนุญาตภายใต้ใบอนุญาต Apache เวอร์ชัน 2.0 ("ใบอนุญาต") สำหรับข้อมูลเพิ่มเติมอ่านใบอนุญาต
