'\" t .nh .TH podman-auto-update 1 .SH "نام (NAME)" podman-auto-update \- به‌روزرسانی خودکار کانتینرها بر اساس خط‌مشی به‌روزرسانی خودکار آن‌ها .SH "خلاصه دستور (SYNOPSIS)" \fBpodman auto-update\fP [\fIگزینه‌ها\fP] .SH "توضیحات (DESCRIPTION)" دستور \fBpodman auto-update\fP ایمیج‌های جدید کانتینر را دریافت کرده و کانتینرهایی را که برای به‌روزرسانی خودکار پیکربندی شده‌اند مجدداً راه‌اندازی می‌کند. برای استفاده از قابلیت به‌روزرسانی خودکار، کانتینر یا بارهای کاری کوبرنتیز باید درون یک واحد systemd اجرا شوند. پس از به‌روزرسانی موفقیت‌آمیز یک ایمیج، کانتینرهایی که از آن ایمیج استفاده می‌کنند با راه‌اندازی مجدد واحدهای systemd که در آن‌ها اجرا می‌شوند، به‌روزرسانی خواهند شد. لطفاً برای نحوه اجرای پادمن تحت systemd به \fBpodman-systemd.unit(5)\fR مراجعه کنید. .PP برای پیکربندی یک کانتینر جهت به‌روزرسانی خودکار، کانتینر باید با برچسب \fBio.containers.autoupdate\fR یا فیلد \fBAutoUpdate\fR در \fBpodman-systemd.unit(5)\fR با یکی از دو مقدار زیر ایجاد شود: .IP \(bu 2 \fBregistry\fR: اگر این برچسب وجود داشته باشد و روی \fBregistry\fR تنظیم شده باشد، پادمن با رجیستری مربوطه تماس می‌گیرد تا بررسی کند آیا ایمیج به‌روزرسانی شده است یا خیر. برچسب \fBimage\fR جایگزینی برای \fBregistry\fR است که جهت سازگاری با نسخه‌های پیشین حفظ شده است. یک ایمیج در صورتی به‌روزرسانی‌شده تلقی می‌شود که دایجست آن در ذخیره‌ساز محلی با دایجست ایمیج از راه دور متفاوت باشد. اگر ایمیجی باید به‌روزرسانی شود، پادمن آن را دریافت کرده و واحد systemd مجری کانتینر را مجدداً راه‌اندازی می‌کند. خط‌مشی رجیستری نیازمند استفاده از یک ارجاع کامل ایمیج (fully-qualified، مانند quay.io/podman/stable:latest) برای ساخت کانتینر است. این الزام برای این است که مشخص شود دقیقاً کدام ایمیج باید بررسی و دریافت شود. اگر از شناسه ایمیج استفاده می‌شد، پادمن دیگر نمی‌دانست کدام ایمیج را بررسی یا دریافت کند. .IP \(bu 2 \fBlocal\fR: اگر برچسب autoupdate روی \fBlocal\fR تنظیم شود، پادمن دایجست ایمیج کانتینر را با دایجست موجود در ذخیره‌ساز کانتینر محلی مقایسه می‌کند. اگر متفاوت باشند، ایمیج محلی جدیدتر تلقی شده و واحد systemd مجدداً راه‌اندازی می‌شود. .SS "به‌روزرسانی خودکار و YAML کوبرنتیز (Auto Updates and Kubernetes YAML)" پادمن از به‌روزرسانی خودکار برای بارهای کاری کوبرنتیز پشتیبانی می‌کند. خط‌مشی به‌روزرسانی خودکار را می‌توان مستقیماً از طریق \fBpodman-systemd.unit(5)\fR یا در داخل YAML کوبرنتیز با حاشیه‌نویسی‌های مخصوص پادمن که در ادامه ذکر شده، پیکربندی کرد: .IP \(bu 2 \fBio.containers.autoupdate\fR: مقدار "registry|local" برای اعمال خط‌مشی به‌روزرسانی خودکار به تمام کانتینرها .IP \(bu 2 \fBio.containers.autoupdate/$container\fR: مقدار "registry|local" برای اعمال خط‌مشی به‌روزرسانی خودکار تنها به \fB$container\fR .IP \(bu 2 \fBio.containers.sdnotify\fR: مقدار "conmon|container" برای اعمال خط‌مشی sdnotify به تمام کانتینرها .IP \(bu 2 \fBio.containers.sdnotify/$container\fR: مقدار "conmon|container" برای اعمال خط‌مشی sdnotify تنها به \fB$container\fR .PP به‌طور پیش‌فرض، خط‌مشی autoupdate روی "disabled" و خط‌مشی sdnotify روی "conmon" تنظیم شده است. .SS "واحد و تایمر Systemd (Systemd Unit and Timer)" پادمن همراه با یک واحد systemd به نام \fBpodman-auto-update.service\fR ارائه می‌شود. این واحد روزانه در نیمه‌شب توسط تایمر systemd با نام \fBpodman-auto-update.timer\fR فعال می‌شود. در صورت تمایل می‌توان این تایمر را برای به‌روزرسانی‌های سفارشی مبتنی بر زمان تغییر داد. همچنین این واحد می‌تواند توسط سایر واحدهای systemd (مثلاً از طریق درخت وابستگی) یا به صورت دستی با دستور \fBsystemctl start podman-auto-update.service\fP فراخوانی شود. .SH "گزینه‌ها (OPTIONS)" .SS \fB--authfile\fP=\fIمسیر\fP مسیر فایل احراز هویت. پیش‌فرض در لینوکس \fB${XDG_RUNTIME_DIR}/containers/auth.json\fR و در ویندوز/مک‌او‌اس \fB$HOME/.config/containers/auth.json\fR است. این فایل توسط \fBpodman login\fP ایجاد می‌شود. اگر وضعیت احراز هویت در آنجا یافت نشود، \fB$HOME/.docker/config.json\fR که با \fBdocker login\fP تنظیم می‌شود، بررسی خواهد شد. .PP نکته: همچنین این گزینه وجود دارد که با تنظیم متغیر محیطی \fBREGISTRY_AUTH_FILE\fR مسیر پیش‌فرض فایل احراز هویت بازنویسی شود. این کار با دستور \fBexport REGISTRY_AUTH_FILE=\fIpath\fP\fP امکان‌پذیر است. .PP به عنوان روش دیگر، می‌توان برچسب کانتینر \fBio.containers.autoupdate.authfile\fR را پیکربندی کرد. در این صورت، پادمن از مقدار برچسب مشخص‌شده استفاده خواهد کرد. .SS \fB--dry-run\fP بررسی در دسترس بودن ایمیج‌های جدید بدون انجام هیچ‌گونه عملیات دریافت یا راه‌اندازی مجدد سرویس یا کانتینر. فیلد \fBUPDATED\fR در دسترس بودن ایمیج جدید را با وضعیت "pending" نشان می‌دهد. .SS \fB--format\fP=\fIقالب\fP تغییر قالب خروجی پیش‌فرض. این مقدار می‌تواند نوعی پشتیبانی‌شده مانند 'json' یا یک قالب Go باشد. جای‌نگهدارهای معتبر برای قالب Go در زیر فهرست شده‌اند: .TS allbox; l l l l . \fB\fBجای‌نگهدار\fP\fP \fB\fBتوضیحات\fP\fP \&.Container شناسه و نام کانتینر \&.ContainerID شناسه کانتینر \&.ContainerName نام کانتینر \&.Image نام ایمیج \&.Policy T{ خط‌مشی به‌روزرسانی خودکار کانتینر T} \&.Unit نام واحد systemd \&.Updated T{ وضعیت به‌روزرسانی: true، false، failed، pending T} .TE .SS \fB--rollback\fP اگر راه‌اندازی مجدد یک واحد systemd پس از به‌روزرسانی ایمیج با شکست مواجه شود، به ایمیج قبلی بازگردانی (rollback) انجام شده و واحد یک بار دیگر راه‌اندازی مجدد می‌شود. مقدار پیش‌فرض true است. .PP توجه داشته باشید که تشخیص شکست یک واحد systemd به بهترین نحو زمانی انجام می‌شود که کانتینر پیام READY را از طریق SDNOTIFY ارسال کند. به این ترتیب، راه‌اندازی مجدد واحد منتظر دریافت این پیام مانده یا مهلت زمانی (timeout) فرا می‌رسد. بدون آن، راه‌اندازی مجدد واحد systemd ممکن است با موفقیت ثبت شود، حتی اگر کانتینر اندکی پس از آن با شکست مواجه شده باشد. .PP برای اینکه یک کانتینر پیام READY را از طریق SDNOTIFY ارسال کند، باید با گزینه \fB--sdnotify=container\fR ایجاد شود (به \fBpodman-run(1)\fP مراجعه کنید). برنامه‌ای که درون کانتینر اجرا می‌شود می‌تواند در زمان آماده بودن دستور \fBsystemd-notify --ready\fR را اجرا کند یا از بایندرهای sdnotify زبان برنامه‌نویسی خاص (مانند \fBsd_notify(3)\fP) استفاده نماید. .SS \fB--tls-verify\fP الزام HTTPS و تایید گواهی‌ها هنگام ارتباط با رجیستری‌ها (پیش‌فرض: \fBtrue\fP). اگر به صراحت روی \fBtrue\fP تنظیم شود، اعتبارسنجی TLS اعمال می‌شود. اگر روی \fBfalse\fP تنظیم شود، اعتبارسنجی TLS اعمال نمی‌شود. اگر مشخص نشده باشد، اعتبارسنجی TLS استفاده می‌شود مگر اینکه رجیستری هدف در \fBcontainers-registries.conf(5)\fP به عنوان یک رجیستری ناامن ذکر شده باشد. .SH "مثال‌ها (EXAMPLES)" ایجاد یک فایل Quadlet پیکربندی‌شده برای به‌روزرسانی‌های خودکار: .EX $ cat ~/.config/containers/systemd/sleep.container [Container] Image=registry.fedoraproject.org/fedora:latest Exec=sleep infinity AutoUpdate=registry .EE .PP تولید یک سرویس systemd از فایل Quadlet با بارگذاری مجدد دیمن کاربری systemd: .EX $ systemctl --user daemon-reload .EE .PP شروع سرویس systemd و اطمینان از در حال اجرا بودن کانتینر: .EX $ systemctl --user start sleep.service $ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f8e4759798d4 registry.fedoraproject.org/fedora:latest sleep infinity 2 seconds ago Up 2 seconds systemd-sleep .EE .PP بررسی در دسترس بودن ایمیج جدید از طریق \fB--dry-run\fR: .EX $ podman auto-update --dry-run --format "{{.Image}} {{.Updated}}" registry.fedoraproject.org/fedora:latest pending .EE .PP به‌روزرسانی سرویس: .EX $ podman auto-update UNIT CONTAINER IMAGE POLICY UPDATED sleep.service f8e4759798d4 (systemd-sleep) registry.fedoraproject.org/fedora:latest registry true .EE .SH "همچنین ببینید (SEE ALSO)" \fBpodman(1)\fP, \fBpodman-generate-systemd(1)\fP, \fBpodman-run(1)\fP, \fBpodman-systemd.unit(5)\fP, \fBsd_notify(3)\fP, \fBsystemd.unit(5)\fP