'" t .nh .TH podman-pod-clone 1 .SH "نام (NAME)" podman-pod-clone \- ایجاد یک رونوشت از یک پاد موجود .SH "خلاصه دستور (SYNOPSIS)" \fBpodman pod clone\fP [\fIگزینه‌ها\fP] \fIپاد\fP [\fIنام\fP] .SH "توضیحات (DESCRIPTION)" دستور \fBpodman pod clone\fP با کپی کردن پیکربندی یک پاد موجود و کانتینرهای درون آن، یک پاد جدید ایجاد می‌کند. این کار به کاربر امکان می‌دهد تا به سادگی یک پاد مشابه را با همان تنظیمات یا با تغییرات جزئی بازتولید کند. .SH "گزینه‌ها (OPTIONS)" .SS \fB--blkio-weight\fP=\fIweight\fP ورودی/خروجی بلوکی (وزن نسبی)، بین 10 تا 1000، یا 0 برای غیرفعال‌سازی (پیش‌فرض 0) .SS \fB--blkio-weight-device\fP=\fIdevice:weight\fP وزن ورودی/خروجی بلوکی (وزن نسبی دستگاه) .SS \fB--cgroup-parent\fP=\fIpath\fP گروه کنترلی (cgroup) والد اختیاری برای کانتینر .SS \fB--cpu-shares\fP, \fB-c\fP=\fIshares\fP .PP سهم‌های پردازنده (وزن نسبی) .PP به‌طور پیش‌فرض، همه کانتینرها سهم یکسانی از چرخه‌های پردازنده دریافت می‌کنند. این نسبت می‌تواند با تغییر وزن سهم پردازنده کانتینر نسبت به وزن سایر کانتینرهای در حال اجرا اصلاح شود. .PP برای تغییر نسبت از مقدار پیش‌فرض 1024، از پرچم \fB--cpu-shares\fP برای تنظیم وزن به 2 یا بالاتر استفاده کنید. .PP این نسبت تنها زمانی اعمال خواهد شد که فرایندهای با بار پردازشی بالا در حال اجرا باشند. هنگامی که وظایف در یک کانتینر بیکار هستند، کانتینرهای دیگر می‌توانند از زمان پردازنده باقی‌مانده استفاده کنند. مقدار واقعی زمان پردازنده بسته به تعداد کانتینرهای در حال اجرا روی سیستم متغیر خواهد بود. .PP به عنوان مثال، سه کانتینر را در نظر بگیرید که یکی دارای cpu-share معادل 1024 و دو کانتینر دیگر دارای تنظیم cpu-share برابر با 512 هستند. هنگامی که فرایندها در هر سه کانتینر تلاش می‌کنند از %100 پردازنده استفاده کنند، کانتینر اول %50 از کل زمان پردازنده را دریافت خواهد کرد. اگر کانتینر چهارمی با cpu-share معادل 1024 اضافه کنید، کانتینر اول تنها %33 از پردازنده را دریافت می‌کند. کانتینرهای باقی‌مانده %16.5، %16.5 و %33 از پردازنده را دریافت خواهند کرد. .PP روی یک سیستم چند‌هسته‌ای، سهم‌های زمان پردازنده میان تمام هسته‌های پردازنده توزیع می‌شود. حتی اگر یک کانتینر به کمتر از %100 زمان پردازنده محدود شده باشد، می‌تواند از %100 هر هسته پردازنده به صورت جداگانه استفاده کند. .PP به عنوان مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر یک کانتینر \fB{C0}\fP را با \fB-c=512\fP در حال اجرای یک فرایند، و کانتینر دیگری \fB{C1}\fP را با \fB-c=1024\fP در حال اجرای دو فرایند راه‌اندازی کنید، این کار می‌تواند منجر به تقسیم سهم‌های پردازنده به شکل زیر شود: .EX PID container CPU CPU share 100 {C0} 0 100% of CPU0 101 {C1} 1 100% of CPU1 102 {C1} 2 100% of CPU2 .EE .SS \fB--cpus\fP تعداد پردازنده‌ها .SS \fB--cpuset-cpus\fP=\fInumber\fP پردازنده‌های مجاز برای اجرا (0-3, 0,1) .SS \fB--cpuset-mems\fP=\fInodes\fP گره‌های حافظه مجاز برای اجرا (0-3, 0,1) .SS \fB--destroy\fP .PP حذف پاد اصلی پس از ایجاد رونوشت از آن. .SS \fB--device\fP=\fIhost-device[:container-device][:permissions]\fP افزودن دستگاه میزبان به کانتینر .SS \fB--device-read-bps\fP=\fIpath:rate\fP محدود کردن نرخ خواندن (بایت در ثانیه) از یک دستگاه .SS \fB--device-write-bps\fP=\fIpath:rate\fP محدود کردن نرخ نوشتن (بایت در ثانیه) روی یک دستگاه .SS \fB--gidmap\fP=\fIcontainer_gid:from_gid[:amount]\fP .PP نگاشت شناسه‌های گروه کاربری (GID) میزبان به کانتینر در حالت بدون ریشه (rootless). .SS \fB--gpus\fP=\fIENTRY\fP دستگاه‌های پردازنده گرافیکی (GPU) جهت افزودن به کانتینر ('all' برای ارسال همه GPUها) .SS \fB--help\fP, \fB-h\fP چاپ نحوه استفاده .PP \fB-h\fP, \fB--hostname\fP="" نام میزبان کانتینر .SS \fB--hostname\fP=\fIname\fP .PP تنظیم نام میزبان (hostname) سفارشی برای کانتینر. .SS \fB--infra-command\fP=\fIcommand\fP .PP دستور جایگزین برای اجرای کانتینر زیرساخت در پاد. .SS \fB--infra-conmon-pidfile\fP=\fIfile\fP .PP مسیر فایل برای ثبت شناسه فرآیند (PID) مانیتور conmon کانتینر زیرساخت. .SS \fB--infra-name\fP=\fIname\fP .PP نام سفارشی برای کانتینر زیرساخت پاد. .SS \fB--label\fP, \fB-l\fP=\fIkey=value\fP .PP افزودن یک برچسب تصویر \fIlabel\fP (برای نمونه label=\fIvalue\fP) به متاداده تصویر. این گزینه می‌تواند چندین بار استفاده شود. اگر نام \fIlabel\fP ذکر شود، اما نه \fB=\fR و نه یک \fBvalue\fR ارائه نشود، آنگاه \fIlabel\fP روی یک مقدار خالی تنظیم می‌شود. .PP کاربران می‌توانند یک LABEL ویژه به صورت \fBio.containers.capabilities=CAP1,CAP2,CAP3\fP در یک Containerfile تنظیم کنند که فهرست قابلیت‌های (capabilities) لینوکس مورد نیاز برای اجرای درست کانتینر را مشخص می‌کند. این برچسب تعیین‌شده در تصویر کانتینر به موتورهای کانتینر، مانند Podman، که این برچسب را می‌شناسند می‌گوید تا کانتینر را فقط با همین قابلیت‌ها اجرا کنند. موتور کانتینر کانتینر را فقط با قابلیت‌های مشخص‌شده راه‌اندازی می‌کند، تا زمانی که این فهرست از قابلیت‌ها زیرمجموعه‌ای از فهرست پیش‌فرض باشد. .PP اگر قابلیت‌های مشخص‌شده در مجموعه پیش‌فرض نباشند، موتورهای کانتینر باید یک پیام خطا چاپ کنند و کانتینر را با قابلیت‌های پیش‌فرض اجرا خواهند کرد. .SS \fB--label-file\fP=\fIfile\fP خواندن فایلی از برچسب‌ها که با خط جدا شده‌اند .SS \fB--memory\fP, \fB-m\fP=\fInumber[unit]\fP .PP محدودیت حافظه (قالب: []، که در آن واحد می‌تواند b، k، m یا g باشد) .PP به شما امکان می‌دهد حافظه در دسترس کانتینر را محدود کنید\&. اگر میزبان از حافظه swap پشتیبانی کند، تنظیم حافظه \fB-m\fP می‌تواند بزرگ‌تر از رم (RAM) فیزیکی باشد\&. اگر محدودیت 0 مشخص شود (عدم استفاده از \fB-m\fP)، حافظه کانتینر محدود نمی‌شود\&. محدودیت واقعی ممکن است به ضریبی از اندازه صفحه سیستم‌عامل گرد شود (این مقدار بسیار بزرگ خواهد بود، یعنی میلیون‌ها تریلیون)\&. .SS \fB--memory-swap\fP=\fInumber[unit]\fP حد حافظه مبادله‌ای (swap) برابر با مجموع حافظه به‌علاوه swap؛ مقدار '-1' برای فعال کردن swap نامحدود .SS \fB--name\fP, \fB-n\fP اختصاص یک نام به کانتینر .SS \fB--pid\fP=\fIpid\fP فضای نام PID مورد استفاده .SS \fB--restart\fP=\fIpolicy\fP سیاست راه‌اندازی مجدد هنگام خروج کانتینر .SS \fB--security-opt\fP=\fIoption\fP گزینه‌های امنیتی .SS \fB--shm-size\fP=\fInumber[unit]\fP اندازه مسیر /dev/shm .SS \fB--shm-size-systemd\fP=\fInumber[unit]\fP .PP اندازه سیستم‌فایل موقت /dev/shm در زمان فعال بودن حالت systemd. .SS \fB--start\fP .PP شروع خودکار پاد جدید پس از اتمام شبیه‌سازی. .SS \fB--subgidname\fP=\fIname\fP .PP نام کاربری در /etc/subgid برای تخصیص شناسه‌های گروه کاربری در حالت بدون ریشه. .SS \fB--subuidname\fP=\fIname\fP .PP نام کاربری در /etc/subuid برای تخصیص شناسه‌های کاربری در حالت بدون ریشه. .SS \fB--sysctl\fP=\fIname=value\fP گزینه‌های sysctl .SS \fB--uidmap\fP=\fIcontainer_uid:from_uid[:amount]\fP .PP نگاشت شناسه‌های کاربری (UID) سیستم میزبان به کانتینر در حالت بدون ریشه. .SS \fB--userns\fP=\fImode\fP فضای نام کاربر مورد استفاده .SS \fB--uts\fP=\fImode\fP فضای نام UTS مورد استفاده .PP \fB-v\fP, \fB--volume\fP= سوار کردن یک حجم به‌صورت bind mount .SS \fB--volume\fP, \fB-v\fP=\fI[[SOURCE-VOLUME|HOST-DIR:]CONTAINER-DIR[:OPTIONS]]\fP .PP ایجاد یک اتصال پیوندی (bind mount). اگر مشخص کنید \fB-v /HOST-DIR:/CONTAINER-DIR\fR، ابزار Podman مسیر \fB/HOST-DIR\fR در میزبان را به \fB/CONTAINER-DIR\fR درون کانتینر Podman پیوند می‌زند. مقادیر \fBOPTIONS\fR فهرستی جداشده با کاما هستند و می‌توانند شامل موارد زیر باشند: .RS .IP \(bu 2 [rw|ro] .IP \(bu 2 [U] .IP \(bu 2 [z|Z|O] .IP \(bu 2 [\fB[r]shared\fR|\fB[r]slave\fR|\fB[r]private\fR|\fB[r]unbindable\fR] [1] \[la]#Footnote1\[ra] .RE .PP مسیر \fBCONTAINER-DIR\fR باید یک مسیر مطلق مانند \fB/src/docs\fR\& باشد. مسیر \fBHOST-DIR\fR نیز باید یک مسیر مطلق باشد. Podman مسیر \fBHOST-DIR\fR را به مسیری که مشخص می‌کنید bind-mount می‌کند. برای نمونه، اگر \fB/foo\fR را به‌عنوان مسیر میزبان بدهید، Podman محتویات \fB/foo\fR را در سیستم‌فایل کانتینر روی میزبان کپی کرده و آن را به درون کانتینر bind-mount می‌کند. .PP می‌توانید چندین گزینه \fB-v\fP را برای سوار کردن یک یا چند اتصال به یک کانتینر مشخص کنید. .PP \fBاتصال‌های جلد حفاظت‌شده در برابر نوشتن (Write Protected Volume Mounts)\fR .PP می‌توانید پسوند \fB:ro\fR یا \fB:rw\fR را به یک جلد اضافه کنید تا به ترتیب در حالت فقط‌خواندنی یا خواندنی-نوشتنی متصل شود. به‌طور پیش‌فرض، جلدها به‌صورت خواندنی-نوشتنی سوار می‌شوند. مثال‌ها را ببینید. .PP \fBتغییر مالکیت اتصال‌های جلد (Chowning Volume Mounts)\fR .PP به‌طور پیش‌فرض، Podman مالک و گروه دایرکتوری‌های جلد منبع متصل‌شده به کانتینرها را تغییر نمی‌دهد. اگر کانتینری در یک فضای‌نام کاربری (user namespace) جدید ایجاد شود، UID و GID درون کانتینر ممکن است با UID و GID متفاوتی روی میزبان متناظر باشند. .PP پسوند \fB:U\fR به Podman اعلام می‌کند تا بر پایه UID و GID درون کانتینر، از UID و GID درست میزبان استفاده کرده و مالک و گروه جلد منبع را تغییر دهد. .PP \fBبرچسب‌گذاری اتصال‌های جلد (Labeling Volume Mounts)\fR .PP سامانه‌های برچسب‌گذاری مانند SELinux نیازمند قرارگیری برچسب‌های مناسب روی محتوای جلد متصل‌شده به کانتینر هستند. بدون برچسب، سامانه امنیتی ممکن است از استفاده فرایندهای در حال اجرا درون کانتینر از محتوا جلوگیری کند. به‌طور پیش‌فرض، Podman برچسب‌های تنظیم‌شده توسط سیستم‌عامل را تغییر نمی‌دهد. .PP برای تغییر یک برچسب در بستر کانتینر، می‌توانید یکی از دو پسوند \fB:z\fR یا \fB:Z\fR را به اتصال جلد اضافه کنید. این پسوندها به Podman می‌گویند که اشیای فایل روی جلدهای اشتراکی را دوباره برچسب‌گذاری کند. گزینه \fBz\fR به Podman می‌گوید که دو کانتینر محتوای جلد را به اشتراک می‌گذارند. در نتیجه، Podman محتوا را با یک برچسب محتوای مشترک برچسب‌گذاری می‌کند. برچسب‌های جلد مشترک به همه کانتینرها اجازه خواندن/نوشتن محتوا را می‌دهند. گزینه \fBZ\fR به Podman می‌گوید که محتوا را با یک برچسب خصوصی غیرمشترک برچسب‌گذاری کند. تنها کانتینر فعلی می‌تواند از یک جلد خصوصی استفاده کند. .PP \fBاتصال‌های جلد اورلی (Overlay Volume Mounts)\fR .PP پرچم \fB:O\fR به Podman اعلام می‌کند دایرکتوری را از میزبان با استفاده از سیستم‌فایل Overlay به‌عنوان یک فضای ذخیره‌سازی موقت سوار کند. کانتینرهای دستور \fBRUN\fR مجاز هستند محتویات درون نقطه اتصال را تغییر دهند و این تغییرات در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شوند. در اصطلاحات سامانه فایل Overlay، دایرکتوری منبع lower و دایرکتوری ذخیره‌سازی کانتینر upper خواهد بود. اصلاحات انجام‌شده در نقطه اتصال هنگام پایان اجرای دستور \fBRUN\fR از بین می‌روند، شبیه به یک نقطه اتصال tmpfs. .PP هر اجرای بعدی دستورهای \fBRUN\fR محتوای دایرکتوری منبع اصلی را می‌بیند؛ و هر تغییری از دستورات RUN قبلی دیگر وجود نخواهد داشت. .PP یک مورد استفاده از اتصال \fBoverlay\fR، به اشتراک گذاشتن حافظه نهان بسته‌ها (package cache) از میزبان به درون کانتینر برای افزایش سرعت ساخت است. .PP نکته: .RS .IP \(bu 2 پرچم \fBO\fR مجاز نیست همراه با پرچم‌های \fBZ\fR یا \fBz\fR مشخص شود. محتوای متصل‌شده به درون کانتینر با برچسب خصوصی برچسب‌گذاری می‌شود. در سامانه‌های SELinux، برچسب‌های موجود در دایرکتوری منبع باید برای برچسب کانتینر قابل‌خواندن باشند. در غیر این صورت، تفکیک کانتینر SELinux باید غیرفعال شود تا کانتینر کار کند. .IP \(bu 2 تغییر دایرکتوری جلدی که با یک اتصال overlay به درون کانتینر متصل شده است می‌تواند خطاهای غیرمنتظره به وجود آورد. توصیه می‌شود تا پایان اجرای کانتینر این دایرکتوری را تغییر ندهید. .RE .PP به‌طور پیش‌فرض جلدهای bind-mount شده \fBprivate\fR\& هستند. بدین معنا که هرگونه اتصالی که درون کانتینر انجام شود روی میزبان قابل مشاهده نخواهد بود و برعکس. این رفتار را می‌توان با مشخص کردن ویژگی انتشار اتصال جلد تغییر داد. .PP هنگامی که خط‌مشی انتشار اتصال روی \fBshared\fR تنظیم شود، هرگونه اتصال انجام‌شده درون کانتینر روی آن جلد هم برای میزبان و هم کانتینر قابل مشاهده خواهد بود. هنگامی که خط‌مشی انتشار اتصال روی \fBslave\fR تنظیم شود، انتشار یک‌طرفه اتصال فعال شده و هرگونه اتصال انجام‌شده روی میزبان برای آن جلد تنها در داخل کانتینر قابل مشاهده خواهد بود. برای کنترل ویژگی انتشار اتصال جلد، از پرچم‌های انتشار \fB:[r]shared\fR، \fB:[r]slave\fR، \fB[r]private\fR یا \fB[r]unbindable\fR استفاده کنید. ویژگی انتشار را فقط می‌توان برای جلدهای bind-mount شده تعیین کرد و نه جلدهای داخلی یا جلدهای نام‌گذاری‌شده. برای کارکرد انتشار اتصال روی نقطه اتصال منبع (نقطه اتصالی که دایرکتوری منبع روی آن سوار شده است)، باید ویژگی‌های انتشار مناسب را داشته باشد. برای جلدهای shared، نقطه اتصال منبع باید shared باشد. و برای جلدهای slave، اتصال منبع باید shared یا slave باشد. [1] \[la]#Footnote1\[ra] .PP از دستور \fBdf \fR برای تعیین اتصال منبع و سپس از دستور \fBfindmnt -o TARGET,PROPAGATION \fR برای تعیین ویژگی‌های انتشار اتصال منبع استفاده کنید؛ اگر ابزار \fBfindmnt\fR در دسترس نیست، نقطه اتصال منبع را می‌توان با بررسی مدخل mount در فایل \fB/proc/self/mountinfo\fR\& مشخص کرد. \fBoptional fields\fR را بررسی کنید و ببینید آیا ویژگی انتشاری مشخص شده است یا خیر. \fBshared:X\fR به معنای \fBshared\fR بودن اتصال است، \fBmaster:X\fR به معنای \fBslave\fR بودن اتصال است و اگر چیزی وجود نداشته باشد به این معناست که اتصال \fBprivate\fR\& است. [1] \[la]#Footnote1\[ra] .PP برای تغییر ویژگی‌های انتشار یک نقطه اتصال از دستور \fBmount\fR استفاده کنید. برای نمونه، برای bind-mount کردن دایرکتوری منبع \fB/foo\fR دستورهای \fBmount --bind /foo /foo\fR و \fBmount --make-private --make-shared /foo\fR\& را اجرا کنید. این کار /foo را به یک نقطه اتصال \fBshared\fR تبدیل می‌کند. ویژگی‌های انتشار نقطه اتصال منبع را می‌توان مستقیماً تغییر داد. برای نمونه اگر \fB/\fR نقطه اتصال منبع برای \fB/foo\fR باشد، دستور \fBmount --make-shared /\fR را برای تبدیل \fB/\fR به یک اتصال \fBshared\fR به کار ببرید. .PP نکته: اگر کاربر تنها از طریق یک گروه دارای مجوز دسترسی باشد، دسترسی به حجم از درون یک پاد بدون ریشه ناموفق خواهد بود. .PP \fBاتصال‌های نگاشت شناسه (Idmapped mount)\fR .PP در صورت تعیین \fBidmap\fR، یک اتصال با شناسه نگاشت‌شده به فضای‌نام کاربری مقصد در کانتینر ایجاد می‌شود. گزینه idmap از نگاشت سفارشی که می‌تواند با فضای‌نام کاربری کانتینر متفاوت باشد پشتیبانی می‌کند. این نگاشت را می‌توان بعد از گزینه idmap به این صورت تعیین کرد: \fBidmap=uids=0-1-10#10-11-10;gids=0-100-10\fR\&. برای هر سه‌گانه، مقدار اول آغاز شناسه‌های سیستم‌فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم مشخص می‌گردد. محدوده‌های چندگانه با نماد # از یکدیگر تفکیک می‌شوند. .SS \fB--volumes-from\fP=\fICONTAINER[:OPTIONS]\fP سوار کردن حجم‌ها از کانتینر(های) مشخص‌شده. برای به اشتراک‌گذاری حجم‌ها میان کانتینرها و پادها استفاده می‌شود. \fIoptions\fP فهرستی جداشده با کاما از موارد زیر است: .IP \(bu 2 \fBrw\fP|\fBro\fP .IP \(bu 2 \fBz\fP .PP حجم‌های از قبل سوارشده از یک کانتینر مبدأ را روی یک پاد دیگر سوار می‌کند. \fICONTAINER\fP می‌تواند نام یا شناسه کانتینر باشد. برای اشتراک‌گذاری حجم، هنگام اجرای کانتینر مقصد از گزینه --volumes-from استفاده کنید. حتی اگر کانتینر مبدأ در حال اجرا نباشد، حجم‌ها می‌توانند به اشتراک گذاشته شوند. .PP به‌طور پیش‌فرض، Podman حجم‌ها را در همان حالت (خواندنی-نوشتنی یا فقط‌خواندنی) که در کانتینر مبدأ سوار شده‌اند، سوار می‌کند. این رفتار را می‌توان با افزودن گزینه \fBro\fR یا \fBrw\fR تغییر داد. .PP سامانه‌های برچسب‌گذاری امنیتی مانند SELinux نیازمند قرارگیری برچسب‌های مناسب روی محتوای حجم سوارشده در پاد هستند. بدون برچسب، سامانه امنیتی ممکن است از دسترسی فرآیندهای درون کانتینر به محتوا جلوگیری کند. به‌طور پیش‌فرض، Podman برچسب‌های تنظیم‌شده توسط سیستم‌عامل را تغییر نمی‌دهد. .PP برای تغییر برچسب در بافت پاد، پسوند \fBz\fR را به سوار کردن حجم اضافه کنید. این پسوند به Podman اعلام می‌کند تا اشیای فایل را روی حجم‌های مشترک مجدداً برچسب‌گذاری کند. گزینه \fBz\fR به Podman می‌گوید که دو موجودیت محتوای حجم را به اشتراک می‌گذارند. در نتیجه، Podman محتوا را با یک برچسب محتوای مشترک نشانه‌گذاری می‌کند. برچسب‌های مشترک به همه کانتینرها اجازه خواندن و نوشتن روی محتوا را می‌دهند. .PP اگر محل حجم ناشی از کانتینر مبدأ با داده‌های موجود در پاد مقصد همپوشانی داشته باشد، حجم مذکور داده‌های موجود در مقصد را پنهان می‌کند. .SH "مثال‌ها (EXAMPLES)" .PP شبیه‌سازی پاد مشخص‌شده در یک پاد جدید: .EX # podman pod clone pod-name 6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584 .EE .PP شبیه‌سازی پاد مشخص‌شده در یک پاد جدید با نام جدید: .EX # podman pod clone pod-name --name=cloned-pod d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7 6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584 .EE .PP شبیه‌سازی و حذف پاد اصلی و تغییر تعداد پردازنده‌ها: .EX # podman pod clone --destroy --cpus=5 d0cf1 6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584 .EE .PP شبیه‌سازی پاد مشخص‌شده با شناسه و نام جدید: .EX # podman pod clone 2d4d4fca7219b4437e0d74fcdc272c4f031426a6eacd207372691207079551de new_name 5a9b7851013d326aa4ac4565726765901b3ecc01fcbc0f237bc7fd95588a24f9 .EE .PP شبیه‌سازی یک پاد با اعمال محدودیت حافظه: .EX # podman pod clone --memory=1g --memory-swap=2g pod-name 6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584 .EE .PP شبیه‌سازی یک پاد با اعمال محدودیت پردازنده: .EX # podman pod clone --cpus=2.5 --cpu-shares=1024 pod-name 6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584 .EE .SH "همچنین ببینید (SEE ALSO)" \fBpodman(1)\fP, \fBpodman-pod(1)\fP, \fBpodman-pod-create(1)\fP .SH "تاریخچه (HISTORY)" مه ۲۰۲۲، در ابتدا توسط Charlie Doern نگاشته شد. .SH "پانویس‌ها (FOOTNOTES)" .PP ۱: پروژه Podman به فراگیری، از ارزش‌های بنیادین متن‌باز، متعهد است. اصطلاحات انتشار سوارکردن (mount propagation) شامل \fBmaster\fR و \fBslave\fR که در این‌جا استفاده شده، مشکل‌ساز و تفرقه‌افکن است و باید دگرگون شود. با این حال، این اصطلاحات هم‌اکنون درون هسته لینوکس استفاده می‌شوند و در این مقطع زمانی باید به همان صورت به کار روند. هنگامی که نگه‌دارندگان هسته این کاربرد را اصلاح کنند، Podman بی‌درنگ از آن پیروی خواهد کرد.