nomad driver containerd
Version 0.9.4
نحن نبحث بنشاط عن المساهمين والمحافظة على هذا المشروع. إذا كان لديك خبرة في الحاويات الداخلية ، فإن مجموعات الأسماء أو مساحات الأسماء أو ساهمت في أي مشاريع مفتوحة المصدر حول الحاويات على سبيل المثال ، docker ، containerd ، nerdctl ، podman ، إلخ أو إنشاء أدوات تتضمن التعامل مع الحاويات الداخلية ، وأهتم بالمساهمة في هذا المشروع ، أود التحدث إليكم! تجربة Golang مفضلة ولكن ليست مطلوبة.
يرجى التواصل معي @_shishir_m أو فتح مشكلة في هذا المستودع مع تفاصيل الاتصال الخاصة بك ، إذا كنت مهتمًا بالمساهمة في هذا المشروع.
برنامج تشغيل مهمة Nomad لإطلاق الحاويات باستخدام ContainerD.
Containerd (containerd.io) هو خفي حاوية خفيفة الوزن لتشغيل وإدارة دورة حياة الحاويات.
يستخدم 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 وتشغيله ، يمكنك التحقق من برامج تشغيل المهام المسجلة (والتي ستظهر أيضًا containerd-driver ) باستخدام:
$ nomad node status (Note down the <node_id>)
$ nomad node status <node_id> | grep containerd-driver
ملاحظة: setup.sh جزء من الإعداد المتشرد ويجب عدم تنفيذها مباشرة.
هناك القليل من الوظائف على سبيل المثال في دليل example .
$ nomad job run <job_name.nomad>
سيتم إطلاق الوظيفة.
المزيد من الإرشادات التفصيلية موجودة في example README.md
للتفاعل مع images containers مباشرة ، يمكنك استخدام nerdctl وهو CLI متوافق مع Docker containerd . تم تثبيت nerdctl بالفعل في Vagrant VM AT /usr/local/bin .
تكوين برنامج التشغيل
| خيار | يكتب | مطلوب | تقصير | وصف |
|---|---|---|---|---|
| تمكين | بول | لا | حقيقي | تمكين/تعطيل سائق المهمة. |
| حاوية | خيط | نعم | ن/أ | وقت التشغيل لـ Containerd على سبيل المثال io.containerd.runc.v1 أو io.containerd.runc.v2 . |
| STATS_INTERVAL | خيط | لا | 1S | الفاصل الزمني لجمع TaskStats . |
| left_privileged | بول | لا | حقيقي | إذا تم ضبطها على false ، فإن Driver سيفكر في تشغيل وظائف متميزة. |
| مصادقة | حاجز | لا | ن/أ | توفير المصادقة للتسجيل الخاص. انظر المصادقة لمزيد من التفاصيل. |
تكوين المهمة
| خيار | يكتب | مطلوب | وصف |
|---|---|---|---|
| صورة | خيط | نعم | صورة OCI (Docker هي أيضًا متوافقة مع OCI) للحاوية الخاصة بك. |
| image_pull_timeout | خيط | لا | مدة زمنية تتحكم في المدة التي ستنتظر فيها containerd-driver قبل إلغاء سحب صورة OCI على النحو المحدد في image . الإعدادات الافتراضية إلى "5m" . |
| يأمر | خيط | لا | الأمر لتجاوز الأمر المحدد في الصورة. |
| args | []خيط | لا | الحجج إلى الأمر. |
| نقطة الدخول | []خيط | لا | قائمة سلسلة تتجاوز نقطة إدخال الصورة. |
| 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 | خيط | لا | مسار إلى ملف تعريف SecComp المخصص. يجب ضبط seccomp على true من أجل استخدام seccomp_profile . يمكن استخدام ملف تعريف docker SecComp الافتراضي الموجود here كمرجع ، وتعديله لإنشاء ملف تعريف SecComp مخصص. |
| shm_size | خيط | لا | حجم /dev /shm على سبيل المثال "128m" إذا كنت تريد 128 ميجابايت من /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 FTSTAB. ملاحظة : للتركيبات الربط ، مطلوب على الأقل rbind و ro .
}
ربط مثال جبل
mounts = [
{
type = "bind"
target = "/target/t1"
source = "/src/s1"
options = ["rbind", "ro"]
}
]
في Additon to the mounts في Task Config ، يمكنك أيضًا تثبيت وحدات التخزين الخاصة بك في الحاوية باستخدام Nomad volume_mount stanza
انظر example job لـ volume_mount .
مثال ملف تعريف seccomp مخصص
يمكن تنزيل ملف تعريف docker SecComp الافتراضي الموجود here ، وتعديله (عن طريق إزالة/إضافة syscalls) لإنشاء ملف تعريف SecComp مخصص.
يمكن بعد ذلك حفظ ملف تعريف SECCOMP المخصص Under /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 and bridge هي خيارات حصرية بشكل متبادل ، ويجب استخدام واحد منهم فقط في وقت واحد.
يمكن تمكين شبكة المضيف عن طريق تعيين host_network إلى true في تكوين المهمة لمواصفات المهمة (انظر ضمن Supported options ).
يمكن تمكين شبكة Bridge عن طريق ضبط network stanza في قسم مجموعة المهام في مواصفات الوظيفة.
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. يمكن تعيين هذه الأنفاق على النحو التالي:
$ 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 رسم خرائط للمنفذ الثابت والديناميكي .
يمكن إضافة رسم خرائط للمنفذ الثابت في 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 مع Consul لتوفير اكتشاف الخدمة والمراقبة.
يمكن إضافة service إلى مواصفات وظيفتك ، لتمكين اكتشاف الخدمة.
تقوم خدمة Stanza بتوجيه Nomad إلى تسجيل خدمة مع القنصل.
إذا كنت تقوم بإجراء الاختبارات محليًا ، فاستخدم vagrant VM المتوفر في المستودع.
$ vagrant up
$ vagrant ssh containerd-linux
$ sudo make test
ملاحظة : هذه اختبارات مدمرة ويمكن أن تترك النظام في حالة تم تغييرها.
يوصى بشدة بتشغيل هذه الاختبارات إما كجزء من نظام CI/CD على سبيل المثال circleci أو على بنية تحتية غير قابلة للتغيير مثل vms vagrant.
يمكنك أيضًا إجراء اختبار فردي عن طريق تحديد اسم الاختبار. على سبيل المثال
$ cd tests
$ sudo ./run_tests.sh 001-test-redis.sh
make clean
سيؤدي هذا إلى حذف ثنائي: containerd-driver
vagrant destroy
هذا سوف يدمر Vagrant VM الخاص بك.
Ubuntu (> = 16.04)
حقوق الطبع والنشر 2020 شركة Roblox
مرخصة بموجب ترخيص Apache ، الإصدار 2.0 ("الترخيص"). لمزيد من المعلومات ، اقرأ الترخيص.
