'\" t
.nh
.TH podman-container-clone 1
.SH "نام (NAME)"
podman-container-clone \- ایجاد یک رونوشت از یک کانتینر موجود

.SH "خلاصه دستور (SYNOPSIS)"
\fBpodman container clone\fP [\fIoptions\fP] \fIcontainer\fP \fIname\fP \fIimage\fP

.SH "توضیحات (DESCRIPTION)"
دستور \fBpodman container clone\fP یک رونوشت از یک کانتینر ایجاد می‌کند و با بازآفرینی کانتینر اصلی، کانتینری با پیکربندی یکسان می‌سازد\&. این دستور سه آرگومان دریافت می‌کند: اولی شناسه (ID) یا نام کانتینری است که باید شبیه‌سازی شود؛ آرگومان دوم در این دستور می‌تواند نام رونوشت را از مقدار پیش‌فرض \fB$ORIGINAL_NAME-clone\fP تغییر دهد؛ و سومی یک ایمیج جدید برای استفاده در کانتینر شبیه‌سازی‌شده است\&.

.SH "گزینه‌ها (OPTIONS)"
.SS \fB--blkio-weight\fP=\fIweight\fP
وزن نسبی ورودی/خروجی بلوکی (Block IO)\&. مقدار \fIweight\fP عددی بین \fB10\fP و \fB1000\fP است\&.

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

.SS \fB--blkio-weight-device\fP=\fIdevice:weight\fP
وزن نسبی دستگاه برای ورودی/خروجی بلوکی (Block IO)\&.

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

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

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

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

.SS \fB--cpu-quota\fP=\fIlimit\fP
محدود کردن سهمیه زمان‌بند کاملاً منصفانه (CFS) پردازنده\&.

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

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

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

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

.SS \fB--cpu-rt-period\fP=\fImicroseconds\fP
محدود کردن دوره زمانی بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه\&.

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

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

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

.SS \fB--cpu-rt-runtime\fP=\fImicroseconds\fP
محدود کردن زمان اجرای بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه\&.

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

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

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

.SS \fB--cpu-shares\fP, \fB-c\fP=\fIshares\fP
سهم‌های پردازنده (وزن نسبی)\&.

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

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

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

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

.PP
برای مثال، سیستمی با بیش از سه هسته را در نظر بگیرید\&. اگر کانتینر \fIC0\fP با گزینه \fB--cpu-shares=512\fP همراه با اجرای یک فرآیند آغاز به کار کند، و کانتینر دیگری \fIC1\fP با گزینه \fB--cpu-shares=1024\fP همراه با اجرای دو فرآیند آغاز شود، می‌تواند به تقسیم سهم‌های پردازنده به صورت زیر منجر شود:

.TS
allbox;
l l l l 
l l l l .
\fBPID\fP	\fBcontainer\fP	\fBCPU\fP	\fBCPU share\fP
100	C0	0	100% of CPU0
101	C1	1	100% of CPU1
102	C1	2	100% of CPU2
.TE

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

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

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

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

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

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

.SS \fB--cpuset-cpus\fP=\fInumber\fP
پردازنده‌هایی که اجازه اجرا در آنها داده می‌شود\&. می‌توان آن را به صورت فهرستی جداشده با کاما (مانند \fB0,1\fP)، به صورت یک بازه (مانند \fB0-3\fP) یا هر ترکیبی از آنها (مانند \fB0-3,7,11-15\fP) مشخص کرد\&.

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

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

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

.SS \fB--cpuset-mems\fP=\fInodes\fP
گره‌های حافظه (MEMها) که اجازه اجرا در آنها داده می‌شود (مانند 0-3 یا 0,1)\&. فقط روی سیستم‌های NUMA موثر است\&.

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

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

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

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

.SS \fB--destroy\fP
حذف کانتینر اصلی که در حال شبیه‌سازی آن هستیم، پس از آنکه برای الگوبرداری از پیکربندی استفاده شد\&.

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

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

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

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

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

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

.SS \fB--force\fP, \fB-f\fP
حذف اجباری کانتینر اصلی که در حال شبیه‌سازی آن هستیم\&. این گزینه تنها همراه با \fB--destroy\fP قابل استفاده است\&.

.SS \fB--memory\fP, \fB-m\fP=\fInumber[unit]\fP
محدودیت حافظه\&. یک واحد (\fIunit\fP) می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت) یا \fBg\fP (گیبی‌بایت) باشد\&.

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

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

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

.SS \fB--memory-reservation\fP=\fInumber[unit]\fP
حد نرم حافظه (Memory soft limit)\&. یک واحد (\fIunit\fP) می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت) یا \fBg\fP (گیبی‌بایت) باشد\&.

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

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

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

.SS \fB--memory-swap\fP=\fInumber[unit]\fP
یک مقدار حدی برابر با حافظه به همراه فضای swap\&. یک واحد (\fIunit\fP) می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت) یا \fBg\fP (گیبی‌بایت) باشد\&.

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

.PP
برای فعال‌سازی swap نامحدود، مقدار \fInumber\fP را روی \fB-1\fP قرار دهید\&.

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

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

.SS \fB--memory-swappiness\fP=\fInumber\fP
تنظیم رفتار تمایل به استفاده از swap حافظه (swappiness) برای کانتینر\&. عددی صحیح بین \fI0\fP و \fI100\fP می‌پذیرد\&.

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

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

.SS \fB--pod\fP=\fIname\fP
شبیه‌سازی کانتینر در یک پاد موجود\&. این گزینه برای انتقال یک کانتینر به پادی موجود سودمند است\&. کانتینر به فضاهای نام مشترک پاد می‌پیوندد و آن بخش از پیکربندی خود را که با فضاهای نام مشترک تداخل دارد از دست می‌دهد\&.

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

.SH "مثال‌ها (EXAMPLES)"
شبیه‌سازی کانتینر مشخص‌شده در یک کانتینر جدید:

.EX
# podman container clone d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584
.EE

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

.EX
# podman container clone --name=clone d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584
.EE

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

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

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

.EX
# 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
.EE

.SH "همچنین ببینید (SEE ALSO)"
\fBpodman-create(1)\fP, \fBcgroups(7)\fP

.SH "تاریخچه (HISTORY)"
ژانویه ۲۰۲۲، در ابتدا توسط چارلی دورن (Charlie Doern) نوشته شد cdoern@redhat.com
\[la]mailto:cdoern@redhat.com\[ra]