podman-container-clone(1) General Commands Manual podman-container-clone(1)

podman-container-clone - ایجاد یک رونوشت از یک کانتینر موجود

podman container clone [options] container name image

دستور podman container clone یک رونوشت از یک کانتینر ایجاد می‌کند و با بازآفرینی کانتینر اصلی، کانتینری با پیکربندی یکسان می‌سازد. این دستور سه آرگومان دریافت می‌کند: اولی شناسه (ID) یا نام کانتینری است که باید شبیه‌سازی شود؛ آرگومان دوم در این دستور می‌تواند نام رونوشت را از مقدار پیش‌فرض $ORIGINAL_NAME-clone تغییر دهد؛ و سومی یک ایمیج جدید برای استفاده در کانتینر شبیه‌سازی‌شده است.

وزن نسبی ورودی/خروجی بلوکی (Block IO). مقدار weight عددی بین 10 و 1000 است.

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

وزن نسبی دستگاه برای ورودی/خروجی بلوکی (Block IO).

دوره زمانی پردازنده (CPU period) را برای زمان‌بند کاملاً منصفانه (CFS) مشخص می‌کند که مدت‌زمانی بر حسب میکروثانیه است. پس از اتمام سهمیه (quota) پردازنده کانتینر، تا پایان دوره زمانی جاری پردازنده برای اجرا در نظر گرفته نخواهد شد. مقدار پیش‌فرض 100000 میکروثانیه است.

در برخی سیستم‌ها، تغییر محدودیت منابع برای کاربران غیرریشه ممکن است مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

در صورت مشخص نشدن، از دوره زمانی پردازنده کانتینر اصلی استفاده می‌شود.

محدود کردن سهمیه زمان‌بند کاملاً منصفانه (CFS) پردازنده.

میزان مصرف پردازنده کانتینر را محدود می‌کند. به‌طور پیش‌فرض، کانتینرها با تمام منابع پردازنده اجرا می‌شوند. این محدودیت عددی بر حسب میکروثانیه است. در صورت ارائه یک عدد، به کانتینر اجازه داده می‌شود تا زمان پایان دوره پردازنده (که با --cpu-period قابل کنترل است)، همان مقدار زمان از پردازنده را استفاده کند.

در برخی سیستم‌ها، تغییر محدودیت منابع برای کاربران غیرریشه ممکن است مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

در صورت مشخص نشدن، از سهمیه پردازنده کانتینر اصلی استفاده می‌شود.

محدود کردن دوره زمانی بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه.

مصرف بی‌درنگ پردازنده توسط کانتینر را محدود می‌کند. این گزینه به هسته اعلام می‌کند تا مصرف بی‌درنگ پردازنده توسط کانتینر را به دوره زمانی مشخص‌شده محدود سازد.

این گزینه فقط در سیستم‌های دارای ریشه (rootful) مبتنی بر cgroups V1 پشتیبانی می‌شود.

در صورت مشخص نشدن، از دوره زمانی اجرای پردازنده کانتینر اصلی استفاده می‌شود.

محدود کردن زمان اجرای بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه.

مصرف بی‌درنگ پردازنده توسط کانتینر را محدود می‌کند. این گزینه به هسته اعلام می‌کند میزان زمانی را که وظایف بی‌درنگ در یک دوره زمانی مشخص پردازنده می‌توانند مصرف کنند محدود سازد. برای مثال: دوره زمانی 1,000,000 میکروثانیه و زمان اجرای 950,000 میکروثانیه بدین معناست که این کانتینر می‌تواند ۹۵٪ از پردازنده در دسترس را مصرف کرده و ۵٪ باقیمانده را برای وظایف با اولویت عادی بگذارد.

مجموع کل زمان‌های اجرا در تمام کانتینرها نمی‌تواند از مقدار اختصاص‌یافته به cgroup والد فراتر رود.

این گزینه فقط در سیستم‌های دارای ریشه (rootful) مبتنی بر cgroups V1 پشتیبانی می‌شود.

سهم‌های پردازنده (وزن نسبی).

به‌طور پیش‌فرض، همه کانتینرها سهم یکسانی از چرخه‌های پردازنده دریافت می‌کنند. این نسبت را می‌توان با تغییر دادن وزن سهم پردازنده کانتینر نسبت به وزن مجموع تمام کانتینرهای در حال اجرا اصلاح کرد. وزن پیش‌فرض 1024 است.

این نسبت تنها زمانی اعمال می‌شود که فرآیندهای پرمصرف از نظر پردازنده در حال اجرا باشند. هنگامی که وظایف درون یک کانتینر غیرفعال (idle) هستند، سایر کانتینرها می‌توانند از زمان باقیمانده پردازنده استفاده کنند. مقدار واقعی زمان پردازنده بسته به تعداد کانتینرهای در حال اجرا روی سیستم متغیر است.

برای مثال، سه کانتینر را در نظر بگیرید که یکی از آنها دارای سهم پردازنده 1024 و دو کانتینر دیگر دارای تنظیم 512 هستند. هنگامی که فرآیندهای درون هر سه کانتینر تلاش کنند ۱۰۰٪ پردازنده را استفاده کنند، کانتینر اول ۵۰٪ از کل زمان پردازنده را دریافت می‌کند. اگر کانتینر چهارمی با سهم پردازنده 1024 اضافه شود، کانتینر اول تنها ۳۳٪ از پردازنده را به دست می‌آورد. کانتینرهای باقیمانده به ترتیب ۱۶.۵٪، ۱۶.۵٪ و ۳۳٪ از پردازنده را دریافت می‌کنند.

در یک سیستم چند‌هسته‌ای، سهم‌های زمان پردازنده در تمام هسته‌های پردازنده توزیع می‌شوند. حتی اگر یک کانتینر به کمتر از ۱۰۰٪ زمان پردازنده محدود شده باشد، می‌تواند از ۱۰۰٪ هر یک از هسته‌های پردازنده به صورت مجزا استفاده کند.

برای مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر کانتینر C0 با گزینه --cpu-shares=512 همراه با اجرای یک فرآیند آغاز به کار کند، و کانتینر دیگری C1 با گزینه --cpu-shares=1024 همراه با اجرای دو فرآیند آغاز شود، می‌تواند به تقسیم سهم‌های پردازنده به صورت زیر منجر شود:

PID container CPU CPU share
100 C0 0 100% of CPU0
101 C1 1 100% of CPU1
102 C1 2 100% of CPU2

در برخی سیستم‌ها، تغییر محدودیت منابع برای کاربران غیرریشه ممکن است مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

در صورت مشخص نشدن، از سهم‌های پردازنده کانتینر اصلی استفاده می‌شود.

تعیین تعداد پردازنده‌ها برای کانتینر که محدودیت‌های پردازنده کانتینر اصلی را بازنویسی می‌کند. در صورت مشخص نشدن، از نانوپردازنده‌های (Nano CPUs) کانتینر اصلی استفاده می‌شود.

این گزینه معادل کوتاه‌شده --cpu-period و --cpu-quota است، بنابراین فقط می‌توان یا --cpus را تنظیم کرد یا هر دو گزینه --cpu-period و --cpu-quota را با هم به کار برد.

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

پردازنده‌هایی که اجازه اجرا در آنها داده می‌شود. می‌توان آن را به صورت فهرستی جداشده با کاما (مانند 0,1)، به صورت یک بازه (مانند 0-3) یا هر ترکیبی از آنها (مانند 0-3,7,11-15) مشخص کرد.

در برخی سیستم‌ها، تغییر محدودیت منابع برای کاربران غیرریشه ممکن است مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

در صورت مشخص نشدن، از مجموعه‌پردازنده (CPUset) کانتینر اصلی استفاده می‌شود.

گره‌های حافظه (MEMها) که اجازه اجرا در آنها داده می‌شود (مانند 0-3 یا 0,1). فقط روی سیستم‌های NUMA موثر است.

اگر چهار گره حافظه روی سیستم وجود داشته باشد (0-3)، با استفاده از --cpuset-mems=0,1، فرآیندهای درون کانتینر تنها از حافظه دو گره نخست استفاده می‌کنند.

در برخی سیستم‌ها، تغییر محدودیت منابع برای کاربران غیرریشه ممکن است مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

در صورت مشخص نشدن، از گره‌های حافظه کانتینر اصلی استفاده می‌شود.

حذف کانتینر اصلی که در حال شبیه‌سازی آن هستیم، پس از آنکه برای الگوبرداری از پیکربندی استفاده شد.

محدود کردن نرخ خواندن (بر حسب بایت بر ثانیه) از یک دستگاه (مانند --device-read-bps=/dev/sda:1mb).

در برخی سیستم‌ها، تغییر محدودیت منابع برای کاربران غیرریشه ممکن است مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

محدود کردن نرخ نوشتن (بر حسب بایت بر ثانیه) روی یک دستگاه (مانند --device-write-bps=/dev/sda:1mb).

در برخی سیستم‌ها، تغییر محدودیت منابع برای کاربران غیرریشه ممکن است مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

حذف اجباری کانتینر اصلی که در حال شبیه‌سازی آن هستیم. این گزینه تنها همراه با --destroy قابل استفاده است.

محدودیت حافظه. یک واحد (unit) می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت) یا g (گیبی‌بایت) باشد.

امکان محدود کردن حافظه در دسترس کانتینر را فراهم می‌سازد. اگر میزبان از حافظه swap پشتیبانی کند، تنظیم حافظه --memory می‌تواند بزرگتر از RAM فیزیکی باشد. اگر حد 0 تعیین شود (عدم استفاده از --memory)، حافظه کانتینر محدود نمی‌شود. حد واقعی ممکن است به مضربی از اندازه صفحه سیستم‌عامل گرد شود (که مقدار بسیار بزرگی است، یعنی میلیون‌ها تریلیون).

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

در صورت مشخص نشدن محدودیت حافظه، از محدودیت‌های حافظه کانتینر اصلی استفاده می‌شود.

حد نرم حافظه (Memory soft limit). یک واحد (unit) می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت) یا g (گیبی‌بایت) باشد.

پس از تنظیم رزرو حافظه، هنگامی که سیستم با کمبود حافظه یا رقابت بر سر حافظه مواجه شود، کانتینرها وادار می‌شوند مصرف خود را به مقدار رزرو محدود کنند. بنابراین همیشه این مقدار را کمتر از --memory تنظیم کنید؛ در غیر این صورت، حد سخت اولویت خواهد داشت. به‌طور پیش‌فرض، رزرو حافظه برابر با همان محدودیت حافظه است.

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

در صورت عدم تعیین، رزرو حافظه برابر با همان محدودیت حافظه کانتینر در حال شبیه‌سازی خواهد بود.

یک مقدار حدی برابر با حافظه به همراه فضای swap. یک واحد (unit) می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت) یا g (گیبی‌بایت) باشد.

باید همراه با فلگ -m (--memory) استفاده شود. مقدار آرگومان باید بزرگتر از مقدار -m (--memory) باشد. به‌طور پیش‌فرض، این مقدار روی دو برابر مقدار --memory تنظیم شده است.

برای فعال‌سازی swap نامحدود، مقدار number را روی -1 قرار دهید.

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

در صورت عدم تعیین، مقدار swap از کانتینر در حال شبیه‌سازی مشتق می‌شود.

تنظیم رفتار تمایل به استفاده از swap حافظه (swappiness) برای کانتینر. عددی صحیح بین 0 و 100 می‌پذیرد.

این فلگ فقط در سیستم‌های دارای ریشه (rootful) مبتنی بر cgroups V1 پشتیبانی می‌شود.

تنظیم یک نام سفارشی برای کانتینر شبیه‌سازی‌شده. مقدار پیش‌فرض در صورت مشخص نشدن به ساختار زیر است: <ORIGINAL_NAME>-clone

شبیه‌سازی کانتینر در یک پاد موجود. این گزینه برای انتقال یک کانتینر به پادی موجود سودمند است. کانتینر به فضاهای نام مشترک پاد می‌پیوندد و آن بخش از پیکربندی خود را که با فضاهای نام مشترک تداخل دارد از دست می‌دهد.

هنگامی که روی true تنظیم شود، این فلگ کانتینر تازه‌ساخته‌شده را پس از تکمیل فرآیند شبیه‌سازی اجرا می‌کند؛ این کار یک حالت اجرای پس‌زمینه (detached) را تعیین می‌نماید.

شبیه‌سازی کانتینر مشخص‌شده در یک کانتینر جدید:

# podman container clone d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584

شبیه‌سازی کانتینر مشخص‌شده در یک کانتینر با نام جدید:

# podman container clone --name=clone d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584

جایگزینی کانتینر مشخص‌شده با محدودیت‌های منابع انتخاب‌شده در یک کانتینر جدید، همراه با حذف کانتینر اصلی:

# podman container clone --destroy --cpus=5 d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584

شبیه‌سازی کانتینر مشخص‌شده با اختصاص یک نام جدید و سپس جایگزین کردن ایمیج کانتینر اصلی با نام ایمیج مشخص‌شده:

# podman container clone 2d4d4fca7219b4437e0d74fcdc272c4f031426a6eacd207372691207079551de new_name fedora
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob c6183d119aa8 done
Copying config e417cd49a8 done
Writing manifest to image destination
Storing signatures
5a9b7851013d326aa4ac4565726765901b3ecc01fcbc0f237bc7fd95588a24f9

podman-create(1), cgroups(7)

ژانویه ۲۰۲۲، در ابتدا توسط چارلی دورن (Charlie Doern) نوشته شد cdoern@redhat.com ⟨mailto:cdoern@redhat.com⟩