.nh .TH podman-generate-systemd 1 .SH "نام (NAME)" podman-generate-systemd \- [منسوخ‌شده] تولید فایل(های) واحد systemd برای یک کانتینر یا پاد .SH "خلاصه دستور (SYNOPSIS)" \fBpodman generate systemd\fP [\fIگزینه‌ها\fP] \fIکانتینر|پاد\fP .SH "توضیحات (DESCRIPTION)" منسوخ‌شده: نکته: دستور \fBpodman generate systemd\fP منسوخ شده است. توصیه می‌کنیم هنگام اجرای کانتینرها یا پادهای پادمن تحت systemd از فایل‌های [Quadlet] استفاده کنید. برنامه‌ای برای حذف این دستور وجود ندارد. این دستور رفع اشکال‌های اضطراری را دریافت خواهد کرد اما هیچ قابلیت جدیدی به آن افزوده نخواهد شد. .PP دستور \fBpodman generate systemd\fP یک فایل واحد systemd ایجاد می‌کند که می‌تواند برای کنترل یک کانتینر یا پاد مورد استفاده قرار گیرد. به طور پیش‌فرض، این دستور محتوای فایل‌های واحد را در خروجی استاندارد (stdout) چاپ می‌کند. .PP تولید فایل‌های واحد برای یک پاد مستلزم آن است که پاد همراه با یک کانتینر زیرساخت (infra container) ایجاد شده باشد (به \fB--infra=true\fR مراجعه کنید). یک کانتینر زیرساخت در کل طول عمر پاد اجرا می‌شود و از این رو برای مدیریت چرخه حیات واحد اصلی پاد توسط systemd الزامی است. .IP \(bu 2 نکته: هنگام استفاده از این دستور با کلاینت راه دور، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2)، فایل‌های واحد تولیدشده را در سیستم راه دور قرار دهید. علاوه بر این، اطمینان حاصل کنید که متغیر محیطی \fBXDG_RUNTIME_DIR\fR مقداردهی شده باشد. در صورت تنظیم نبودن، آن را با دستور \fBexport XDG_RUNTIME_DIR=/run/user/$(id -u)\fR تنظیم کنید. .IP \(bu 2 نکته: دستور تولیدشده \fBpodman run\fR شامل گزینه \fB--sdnotify\fR با مقداری برگرفته از کانتینر است. اگر کانتینر مقدار مشخصی نداشته باشد یا مقدار آن روی \fBignore\fP تنظیم شده باشد، مقدار \fBconmon\fP استفاده می‌شود. دلیل بازنویسی مقدار پیش‌فرض \fBcontainer\fP این است که تقریباً هیچ‌یک از بارهای کاری کانتینر پیام‌های اطلاع‌رسانی ارسال نمی‌کنند. اگر از مقدار \fBcontainer\fP برای کانتینری استفاده شود که پیام اعلان نمی‌فرستد، systemd منتظر پیام آماده‌باش می‌ماند که هرگز ارسال نخواهد شد. ممکن است استفاده از مقدار پیش‌فرض بدون قصد قبلی کاربر رخ داده باشد، از این رو مقدار پیش‌فرض بازنویسی شده است. .SS "یکپارچه‌سازی با کوبرنتیز (Kubernetes Integration)" یک فایل YAML کوبرنتیز را می‌توان از طریق قالب systemd به نام \fBpodman-kube@.service\fR در systemd اجرا کرد. آرگومان این قالب مسیر فایل YAML است. با فرض وجود فایل \fBworkload.yaml\fR در دایرکتوری خانگی، می‌توان آن را به شکل زیر اجرا نمود: .EX $ escaped=$(systemd-escape ~/workload.yaml) $ systemctl --user start podman-kube@$escaped.service $ systemctl --user is-active podman-kube@$escaped.service active .EE .SH "گزینه‌ها (OPTIONS)" .SS \fB--after\fP=\fIنام_وابستگی\fP افزودن گزینه بعد از (\fBAfter=\fR) به واحد systemd، که ترتیب وابستگی‌ها را میان فهرست وابستگی‌ها و این سرویس تعیین می‌کند. این گزینه می‌تواند بیش از یک بار مشخص شود. .PP وابستگی‌های تعریف‌شده توسط کاربر به فایل واحد تولیدشده ضمیمه می‌شوند، اما گزینه‌های موجودِ مورد نیاز یا تعریف‌شده به صورت پیش‌فرض (مانند \fBonline.target\fR) حذف یا بازنویسی \fBنمی‌شوند\fP. .SS \fB--container-prefix\fP=\fIپیشوند\fP تنظیم پیشوند نام واحد systemd برای کانتینرها. پیش‌فرض \fIcontainer\fP است. .SS \fB--env\fP, \fB-e\fP=\fIمتغیر_محیطی\fP تنظیم متغیرهای محیطی در فایل‌های واحد systemd. .PP اگر یک متغیر محیطی بدون مقدار مشخص شود، پادمن مقدار آن را در محیط میزبان جستجو می‌کند و تنها در صورتی که روی میزبان تنظیم شده باشد، متغیر را ست می‌کند. به عنوان یک حالت ویژه، اگر متغیر محیطیِ خاتمه‌یافته با \fB*\fP بدون مقدار مشخص شود، پادمن محیط میزبان را برای متغیرهایی که با آن پیشوند شروع می‌شوند جستجو کرده و آن متغیرها را به فایل‌های واحد systemd اضافه می‌کند. .SS \fB--files\fP, \fB-f\fP تولید فایل به جای چاپ در خروجی استاندارد. فایل‌های تولیدشده با الگوی {container,pod}-{ID,name}.service نام‌گذاری شده و در دایرکتوری کاری فعلی قرار می‌گیرند. .PP نکته: در سامانه‌ای با SELinux فعال، فایل‌های تولیدشده بافت‌های امنیتی را از دایرکتوری کاری فعلی به ارث می‌برند. بسته به پیکربندی SELinux، ممکن است تغییر فایل‌های تولیدشده با استفاده از \fBrestorecon\fR، \fBchcon\fR، یا \fBsemanage\fR برای دسترسی systemd به این فایل‌ها لازم باشد. به عنوان راهکار دیگر، هنگام اجرای \fBmv\fR یا \fBcp\fR از گزینه \fB-Z\fR استفاده کنید. .SS \fB--format\fP=\fIقالب\fP چاپ واحدهای ایجادشده در قالب مشخص‌شده (json). اگر گزینه \fB--files\fR مشخص شده باشد، مسیر فایل‌های ایجادشده به جای محتوای واحد چاپ می‌شود. .SS \fB--name\fP, \fB-n\fP استفاده از نام کانتینر برای شروع، توقف و توضیحات در فایل واحد. .SS \fB--new\fP این گزینه فایل‌های واحدی تولید می‌کند که انتظار وجود قبلی کانتینرها و پادها را ندارند. در عوض، کانتینرها و پادهای جدید بر اساس فایل‌های پیکربندی‌شان ایجاد می‌شوند. فایل‌های واحد با بیشترین تلاش ممکن (best effort) ایجاد می‌شوند و ممکن است به ویرایش بیشتری نیاز داشته باشند؛ لطفاً پیش از استفاده در محیط عملیاتی، فایل‌های تولیدشده را با دقت بررسی نمایید. .PP توجه داشته باشید که \fB--new\fR تنها بر روی کانتینرها و پادهایی کار می‌کند که مستقیماً از طریق پادمن ایجاد شده‌اند (یعنی \fBpodman [container] {create,run}\fR یا \fBpodman pod create\fR). این گزینه بر روی کانتینرها یا پادهای ایجادشده از طریق REST API یا از طریق \fBpodman kube play\fR کار نمی‌کند. برای \fBpodman kube play\fR، به جای آن از قالب systemd به نام \fBpodman-kube@.service\fR استفاده کنید. .SS \fB--no-header\fP عدم تولید سرآیند شامل فراداده‌هایی مانند نسخه پادمن و برچسب زمانی. .SS \fB--pod-prefix\fP=\fIپیشوند\fP تنظیم پیشوند نام واحد systemd برای پادها. مقدار پیش‌فرض \fIpod\fP است. .SS \fB--requires\fP=\fIنام_وابستگی\fP تنظیم گزینه نیازمندی‌های واحد systemd (\fBRequires=\fR). شبیه به wants است، اما وابستگی الزامی قوی‌تری را اعلام می‌کند. .SS \fB--restart-policy\fP=\fIخط‌مشی\fP تنظیم خط‌مشی راه‌اندازی مجدد در systemd. خط‌مشی باید یکی از موارد زیر باشد: "no"، "on-success"، "on-failure"، "on-abnormal"، "on-watchdog"، "on-abort"، یا "always". خط‌مشی پیش‌فرض \fIon-failure\fP است، مگر اینکه کانتینر با خط‌مشی راه‌اندازی مجدد سفارشی ایجاد شده باشد. .PP توجه داشته باشید که تولید یک واحد بدون \fB--new\fR بر روی کانتینری با خط‌مشی راه‌اندازی مجدد سفارشی می‌تواند هنگام خاموش شدن سیستم منجر به بروز مشکل شود؛ زیرا systemd تلاش می‌کند واحد را متوقف کند در حالی که پادمن سعی در راه‌اندازی مجدد آن دارد. توصیه می‌شود کانتینر بدون \fB--restart\fR ایجاد شده و از گزینه \fB--restart-policy\fR هنگام تولید فایل واحد استفاده شود. .SS \fB--restart-sec\fP=\fIزمان\fP تنظیم مقدار RestartSec سرویس در systemd. مدت‌زمان توقف پیش از راه‌اندازی مجدد یک سرویس را پیکربندی می‌کند (همان‌گونه که با restart-policy تنظیم شده است). مقداری بر حسب ثانیه می‌گیرد. .SS \fB--separator\fP=\fIجداساز\fP تنظیم جداکننده نام واحد systemd بین نام/شناسه کانتینر/پاد و پیشوند. مقدار پیش‌فرض \fI-\fP است. .SS \fB--start-timeout\fP=\fIمقدار\fP بازنویسی مهلت زمانی شروع پیش‌فرض برای کانتینر با مقدار داده‌شده بر حسب ثانیه. .SS \fB--stop-timeout\fP=\fIمقدار\fP بازنویسی مهلت زمانی توقف پیش‌فرض برای کانتینر با مقدار داده‌شده بر حسب ثانیه. .SS \fB--template\fP افزودن مشخص‌کننده‌های قالب برای اجرای چندین سرویس از روی فایل واحد systemd. .PP توجه داشته باشید که اگر \fB--new\fR روی true تنظیم نشده باشد، به طور پیش‌فرض روی true تنظیم می‌شود. با این حال، اگر \fB--new\fR به طور صریح روی \fBfalse\fR تنظیم شود، دستور با خطا مواجه خواهد شد. .SS \fB--wants\fP=\fIنام_وابستگی\fP افزودن گزینه خواسته‌ها (\fBWants=\fR) به واحد systemd که این سرویس وابستگی (ضعیف) به آن دارد. این گزینه می‌تواند بیش از یک بار مشخص شود. این گزینه ترتیبی را که سرویس‌ها در آن شروع یا متوقف می‌شوند تحت تأثیر قرار نمی‌دهد. .PP وابستگی‌های تعریف‌شده توسط کاربر به فایل واحد تولیدشده ضمیمه می‌شوند، اما گزینه‌های موجودِ مورد نیاز یا تعریف‌شده به صورت پیش‌فرض (مانند \fBonline.target\fR) حذف یا بازنویسی \fBنمی‌شوند\fP. .SH "مثال‌ها (EXAMPLES)" .SS "تولید و چاپ فایل واحد systemd برای یک کانتینر" تولید یک فایل واحد systemd برای یک کانتینر مجری nginx با خط‌مشی راه‌اندازی مجدد \fIalways\fP و مهلت ۱ ثانیه در خروجی استاندارد. توجه داشته باشید که گزینه \fBRequiresMountsFor\fP در بخش \fBUnit\fP تضمین می‌کند فضای ذخیره‌سازی کانتینر برای هر دو مسیر GraphRoot و RunRoot قبل از شروع سرویس سوار (mount) شده باشد. در سامانه‌هایی با ذخیره‌سازی کانتینر بر روی دیسک‌هایی نظیر iSCSI یا سایر پروتکل‌های بلوکی راه دور، این گزینه اطمینان می‌دهد پادمن پیش از در دسترس قرار گرفتن عملیات ذخیره‌سازی لازم اجرا نشود. .EX $ podman create --name nginx nginx:latest $ podman generate systemd --restart-policy=always -t 1 nginx # container-de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6.service # autogenerated by Podman 1.8.0 # Wed Mar 09 09:46:45 CEST 2020 [Unit] Description=Podman container-de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6.service Documentation=man:podman-generate-systemd(1) Wants=network-online.target After=network-online.target RequiresMountsFor=/var/run/container/storage [Service] Restart=always ExecStart=/usr/bin/podman start de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6 ExecStop=/usr/bin/podman stop -t 1 de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6 KillMode=none Type=forking PIDFile=/run/user/1000/overlay-containers/de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6/userdata/conmon.pid [Install] WantedBy=default.target .EE .SS "تولید فایل واحد systemd برای یک کانتینر با پرچم \fB--new\fR" پرچم \fB--new\fR فایل‌های واحد systemd را به گونه‌ای تولید می‌کند که در دستورات شروع و توقف سرویس، کانتینرها را ایجاد و حذف نمایند (به اقدامات سرویس در ExecStartPre و ExecStopPost مراجعه کنید). چنین فایل‌های واحدی وابسته به یک ماشین خاص نیستند و می‌توان به سادگی آن‌ها را به اشتراک گذاشت و در سایر ماشین‌ها استفاده کرد. .EX $ sudo podman generate systemd --new --files --name bb310a0780ae # container-busy_moser.service # autogenerated by Podman 1.8.3 # Fri Apr 3 09:40:47 EDT 2020 [Unit] Description=Podman container-busy_moser.service Documentation=man:podman-generate-systemd(1) Wants=network-online.target After=network-online.target RequiresMountsFor=/var/run/container/storage [Service] Environment=PODMAN_SYSTEMD_UNIT=%n Restart=on-failure ExecStartPre=/bin/rm -f %t/%n-pid %t/%n-cid ExecStart=/usr/local/bin/podman run --conmon-pidfile %t/%n-pid --cidfile %t/%n-cid --cgroups=no-conmon -d -dit alpine ExecStop=/usr/local/bin/podman stop --ignore --cidfile %t/%n-cid -t 10 ExecStopPost=/usr/local/bin/podman rm --ignore -f --cidfile %t/%n-cid PIDFile=%t/%n-pid KillMode=none Type=forking [Install] WantedBy=default.target .EE .SS "تولید فایل‌های واحد systemd برای یک پاد با دو کانتینر ساده alpine" توجه داشته باشید که \fBsystemctl\fR تنها باید بر روی واحد پاد استفاده شود و نباید برای شروع یا توقف تکی کانتینرها به کار رود. کانتینرها همراه با کانتینر زیرساخت داخلی توسط سرویس پاد مدیریت می‌شوند. .PP برای بررسی فایل‌های واحد کانتینر یا پاد از \fBsystemctl status\fR یا \fBjournalctl\fR استفاده کنید. .EX $ podman pod create --name systemd-pod $ podman create --pod systemd-pod alpine top $ podman create --pod systemd-pod alpine top $ podman generate systemd --files --name systemd-pod /home/user/pod-systemd-pod.service /home/user/container-amazing_chandrasekhar.service /home/user/container-jolly_shtern.service $ cat pod-systemd-pod.service # pod-systemd-pod.service # autogenerated by Podman 1.8.0 # Wed Mar 09 09:52:37 CEST 2020 [Unit] Description=Podman pod-systemd-pod.service Documentation=man:podman-generate-systemd(1) Requires=container-amazing_chandrasekhar.service container-jolly_shtern.service Before=container-amazing_chandrasekhar.service container-jolly_shtern.service Wants=network-online.target After=network-online.target RequiresMountsFor=/var/run/container/storage [Service] Restart=on-failure ExecStart=/usr/bin/podman start 77a818221650-infra ExecStop=/usr/bin/podman stop -t 10 77a818221650-infra KillMode=none Type=forking PIDFile=/run/user/1000/overlay-containers/ccfd5c71a088768774ca7bd05888d55cc287698dde06f475c8b02f696a25adcd/userdata/conmon.pid [Install] WantedBy=default.target .EE .SS "نصب فایل‌های واحد systemd تولیدشده" فایل‌های واحد تولیدشده توسط پادمن شامل بخش \fB[Install]\fR هستند که اطلاعات نصب واحد را در بر دارد. این بخش توسط دستورات enable و disable در systemctl(1) هنگام نصب مورد استفاده قرار می‌گیرد. .PP پس از تولید فایل واحد systemd، آن را برای اجرا توسط کاربر ریشه (root) در \fI/etc/systemd/system\fP و برای نصب به عنوان کاربر غیرریشه در \fI$HOME/.config/systemd/user\fP قرار دهید. فایل یا فایل‌های کپی‌شده را با استفاده از \fBsystemctl enable\fR فعال کنید. .PP نکته: کپی کردن فایل‌های واحد در \fI/etc/systemd/system\fP و فعال‌سازی آن باعث می‌شود فایل واحد به طور خودکار هنگام بالا آمدن سیستم (boot) آغاز به کار کند. به همین ترتیب، کپی کردن فایل واحد در \fI$HOME/.config/systemd/user\fP و فعال‌سازی آن باعث شروع خودکار واحد هنگام ورود کاربر به سیستم خواهد شد. .EX # Generated systemd files. $ podman pod create --name systemd-pod $ podman create --pod systemd-pod alpine top $ podman generate systemd --files --name systemd-pod # Copy all the generated files. $ sudo cp pod-systemd-pod.service container-great_payne.service /etc/systemd/system $ systemctl enable pod-systemd-pod.service Created symlink /etc/systemd/system/multi-user.target.wants/pod-systemd-pod.service → /etc/systemd/system/pod-systemd-pod.service. Created symlink /etc/systemd/system/default.target.wants/pod-systemd-pod.service → /etc/systemd/system/pod-systemd-pod.service. $ systemctl is-enabled pod-systemd-pod.service enabled .EE .PP برای اجرای سرویس‌های کاربری قرارگرفته در \fB$HOME/.config/systemd/user\fR در نخستین ورود آن کاربر، سرویس را با پرچم --user فعال کنید: .EX $ systemctl --user enable <.service> .EE .PP نمونه کاربری systemd پس از بسته شدن آخرین نشست کاربر متوقف می‌شود. می‌توان نمونه کاربری systemd را با فعال‌سازی ماندگاری (\fBlingering\fR) هنگام بوت سیستم آغاز کرد و حتی پس از خروج کاربر فعال نگه داشت: .EX $ loginctl enable-linger .EE .SS "استفاده از \fBsystemctl\fR برای انجام عملیات بر روی فایل‌های واحد نصب‌شده" با استفاده از مثال‌های بالا به عنوان مرجع، فایل‌های واحد systemd را برای یک پاد ایجاد و فعال کنید و از \fBsystemctl\fR برای انجام عملیات بهره ببرید. .PP از آنجا که systemctl به طور پیش‌فرض با کاربر ریشه کار می‌کند، تمامی تغییرات اعمال‌شده از طریق systemctl با افزودن sudo به دستورات پادمن قابل مشاهده است. برای انجام اقدامات \fBsystemctl\fR به عنوان کاربر غیرریشه، هنگام کار با \fBsystemctl\fR از پرچم \fB--user\fR استفاده کنید. .PP نکته: اگر کانتینرها یا پادهای قبلاً ایجادشده از منابع مشترکی مانند پورت‌ها استفاده می‌کنند، اطمینان حاصل کنید که پیش از شروع واحدهای تولیدشده systemd آن‌ها را حذف کرده‌اید. .EX $ systemctl --user start pod-systemd-pod.service $ podman pod ps POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID 0815c7b8e7f5 systemd-pod Running 29 minutes ago 2 6c5d116f4bbe $ sudo podman ps # 0 Number of pods on root. CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES $ systemctl stop pod-systemd-pod.service $ podman pod ps POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID 272d2813c798 systemd-pod Exited 29 minutes ago 2 6c5d116f4bbe .EE .PP ایجاد یک کانتینر ساده alpine و تولید فایل واحد systemd با پرچم \fB--new\fR: فعال‌سازی سرویس و کنترل عملیات با استفاده از دستورات systemctl. .PP نکته: هنگام شروع کانتینر با استفاده از \fBsystemctl start\fR، به جای دست‌کاری کانتینر در حال اجرا، یک کانتینر "جدید" با پیکربندی مشابه ایجاد و راه‌اندازی می‌شود. .EX # Enable the service. $ sudo podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES bb310a0780ae docker.io/library/alpine:latest /bin/sh 2 minutes ago Created busy_moser $ sudo systemctl start container-busy_moser.service $ sudo podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 772df2f8cf3b docker.io/library/alpine:latest /bin/sh 1 second ago Up 1 second distracted_albattani bb310a0780ae docker.io/library/alpine:latest /bin/sh 3 minutes ago Created busy_moser .EE .SH "همچنین ببینید (SEE ALSO)" \fBpodman(1)\fP, \fBpodman-container(1)\fP, \fBsystemctl(1)\fP, \fBsystemd.unit(5)\fP, \fBsystemd.service(5)\fP, \fBconmon(8)\fP, \fBpodman-systemd.unit(5)\fP .SH "تاریخچه (HISTORY)" آوریل ۲۰۲۰، به‌روزرسانی جزئیات و افزودن مورد کاربرد برای استفاده از فایل‌های service. تولیدشده به عنوان کاربر ریشه (root) و غیرریشه، توسط Sujil Shah (sushah at redhat dot com) .PP اوت ۲۰۱۹، به‌روزرسانی با پشتیبانی از پاد توسط Valentin Rothberg (rothberg at redhat dot com) .PP آوریل ۲۰۱۹، در ابتدا توسط Brent Baude گردآوری شد (bbaude at redhat dot com)