मैंने सोचा था कि docker कंटेनरों ने इन गुणों को मेजबान के साथ साझा किया है। हालांकि, एक docker होस्ट पर, ये ulimit सेटिंग हैं:

ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63399
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63399
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

लेकिन एक कंटेनर के भीतर, एक मिलता है:

ulimit -a
-f: file size (blocks)             unlimited
-t: cpu time (seconds)             unlimited
-d: data seg size (kb)             unlimited
-s: stack size (kb)                8192
-c: core file size (blocks)        unlimited
-m: resident set size (kb)         unlimited
-l: locked memory (kb)             64
-p: processes                      unlimited
-n: file descriptors               65536
-v: address space (kb)             unlimited
-w: locks                          unlimited
-e: scheduling priority            0
-r: real-time priority             0

विशेष रूप से -n सेटिंग को देखते हुए - क्या कंटेनर 1024 खुली फाइलों तक सीमित है क्योंकि होस्ट इतना सीमित है? क्या कोई कृपया कंटेनर के भीतर से ulimit के अर्थ और अंतर्निहित docker होस्ट के बीच के अंतरों को समझा सकता है?

4
JoeG 6 नवम्बर 2018, 17:14

1 उत्तर

सबसे बढ़िया उत्तर

कंटेनर स्टार्टअप के दौरान डॉकर द्वारा संसाधन सीमा निर्धारित की जा सकती है, और आप कंटेनर को लॉन्च करते समय --ulimit तर्क का उपयोग करके इन सेटिंग्स को ट्यून कर सकते हैं। इसे कंटेनर स्टार्टअप के दौरान strace containerd प्रक्रिया द्वारा आसानी से सत्यापित किया जा सकता है, उदाहरण के लिए, निम्न आदेश

$ docker run -it --ulimit nofile=1024 alpine

निम्नलिखित ट्रेस का उत्पादन करेगा:

prlimit64(7246, RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024},  <unfinished ...>

और कंटेनर में ulimit की जाँच करने से अपेक्षित सीमा मान मिलता है:

-n: file descriptors               1024

स्पष्ट रूप से निर्दिष्ट किए बिना कंटेनर चलाते समय --ulimit, यह चेक अलग मान देता है (शायद containerd से विरासत में मिला), उदाहरण:

-n: file descriptors               1048576

डॉकर को आपके होस्ट पर ulimit की जाँच करके आपके द्वारा देखी जाने वाली सीमाएँ अधिक निर्धारित करने की अनुमति क्यों है? आइए खोलें man 2 prlimit:

A privileged process (under Linux: one with the CAP_SYS_RESOURCE capability
in the initial user namespace) may make arbitrary changes to either limit value.

इसका मतलब है कि CAP_SYS_RESOURCE क्षमता वाली कोई भी प्रक्रिया किसी भी संसाधन सीमा को निर्धारित कर सकती है, और डॉकर में यह क्षमता है। आप /proc/$PID/status फ़ाइल के CapEff फ़ील्ड का निरीक्षण करके इसकी जांच कर सकते हैं, जहां $PID containerd प्रक्रिया का एक PID है, और capsh --decode का उपयोग करके इस मान को डिकोड कर सकते हैं:

$ pidof docker-containerd
675
$ cat /proc/675/status | grep CapEff
CapEff: 0000003fffffffff
$ capsh --decode=0000003fffffffff
0x0000003fffffffff=cap_chown,<...>,cap_sys_resource,<...>

संक्षेप में: हाँ, डॉकर कंटेनरों के लिए संसाधन सीमा बढ़ा सकता है, क्योंकि उसके पास ऐसा करने के विशेषाधिकार हैं, और आप --ulimit तर्क का उपयोग करके इन सीमाओं को समायोजित कर सकते हैं।

6
Danila Kiver 6 नवम्बर 2018, 15:23