[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fYyibF6O-yBAIzTM5YMNaFEwf9BVUCEEX9vOnRXi4oTE":3},{"data":4,"related":90},{"id":5,"title":6,"slug":7,"excerpt":8,"cover":9,"category":11,"author":14,"track":20,"level":23,"reading_minutes":26,"is_featured":27,"published_at":28,"updated_at":28,"body":29,"toc":30,"tags":63,"faqs":75,"related_services":85,"comments_enabled":88,"meta_title":19,"meta_description":89,"canonical_url":19,"noindex":27,"is_live":88},9,"پاد Kubernetes در وضعیت Terminating گیر کرده؛ آزادسازی امن","kubernetes-pod-stuck-terminating-finalizer","پاد در حالت Terminating گیر کرده و با kubectl delete پاک نمی‌شود؟ این مقاله علت واقعی (finalizer باقی‌مانده، نود NotReady، ولوم گیرکرده) و راه‌حل گام‌به‌گام امن را نشان می‌دهد.",{"url":10,"alt":6},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F8e6369a3-ad85-4e7e-8588-183bbd5a31f9.webp",{"name":12,"slug":13},"Kubernetes و کانتینر","kubernetes",{"name":15,"slug":16,"role":17,"bio":18,"linkedin_url":19,"avatar_url":19},"تحریریه کلودیکپ","cloudicap-editorial","تیم محتوای کلودیکپ","تیم فنی و محتوای کلودیکپ؛ مهندسانی که هر روز با DevOps، Kubernetes و زیرساخت ابری کار می‌کنند و تجربه‌هایشان را اینجا می‌نویسند.",null,{"value":21,"label":22},"engineers","مهندسان",{"value":24,"label":25},"intermediate","متوسط",6,false,"2026-10-10T09:34:08+00:00","\u003Cp>در محیط عملیاتی \u003Ca href=\"\u002Fservices\u002Fkubernetes\">Kubernetes\u003C\u002Fa> یکی از آزاردهنده‌ترین صحنه‌ها این است که \u003Ccode>kubectl delete pod\u003C\u002Fcode> با موفقیت برمی‌گردد، اما پاد نه‌فقط پاک نمی‌شود بلکه ساعت‌ها در وضعیت \u003Ccode>Terminating\u003C\u002Fcode> می‌ماند و مقدار AGE آن مدام بالا می‌رود. در این مقاله دقیقاً همین حالت را کالبدشکافی می‌کنیم: چرا رخ می‌دهد، چطور بدون خراب‌کردن چیزی آزادش کنیم، و چطور جلوی تکرارش را بگیریم.\u003C\u002Fp>\n\n\u003Ch2 id=\"شرح-مسئله-پادی-که-نمی‌خواهد-برود\">شرح مسئله: پادی که نمی‌خواهد برود\u003C\u002Fh2>\n\n\u003Cp>ماجرا معمولاً بعد از یک deploy یا یک عملیات مقیاس‌دهی شروع می‌شود. دستور حذف اجرا می‌شود، API Server هم تایید می‌کند، ولی پاد همچنان سر جایش است:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\">$ kubectl delete pod web-7d9f8c6b5-4xk2p -n production\npod \"web-7d9f8c6b5-4xk2p\" deleted\n\n$ kubectl get pods -n production\nNAME                   READY   STATUS        RESTARTS   AGE\nweb-7d9f8c6b5-4xk2p    1\u002F1     Terminating   0          3d2h\nweb-7d9f8c6b5-9qztv    1\u002F1     Running       0          4d\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>نشانه کلیدی این است که \u003Ccode>deletionTimestamp\u003C\u002Fcode> ثبت شده اما شیء پاد هنوز در etcd باقی مانده و کانتینر در نود هم ممکن است هنوز در حال اجرا باشد. نکته مهم‌تر اینکه \u003Ccode>kubectl describe pod\u003C\u002Fcode> معمولاً چیز جدیدی به شما نمی‌گوید؛ چون در این مرحله دیگر رویداد تازه‌ای تولید نمی‌شود و Events خشک شده است.\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\">$ kubectl get pod web-7d9f8c6b5-4xk2p -n production \\\n  -o jsonpath='{.metadata.deletionTimestamp}{\"\\n\"}{.metadata.finalizers}{\"\\n\"}{.spec.nodeName}{\"\\n\"}'\n2024-05-11T07:42:10Z\n[example.com\u002Fbackup-protection]\nip-10-0-14-23\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>همین سه خط معمولاً کل داستان را لو می‌دهد: زمان حذف ثبت شده، یک finalizer باقی مانده، و نودی که پاد روی آن اجرا می‌شود.\u003C\u002Fp>\n\n\u003Ch2 id=\"علت-ریشه‌ای-چرخه-حذف-پاد-کجا-می‌شکند\">علت ریشه‌ای: چرخه حذف پاد کجا می‌شکند\u003C\u002Fh2>\n\n\u003Cp>پاد زمانی از لیست خارج می‌شود که دو شرط هم‌زمان برقرار باشند:\u003C\u002Fp>\n\n\u003Col>\n\u003Cli>API Server مقدار \u003Ccode>metadata.deletionTimestamp\u003C\u002Fcode> را ثبت کند و بعد از آن، آرایه \u003Ccode>metadata.finalizers\u003C\u002Fcode> خالی شود.\u003C\u002Fli>\n\u003Cli>kubelet روی نود میزبان تایید کند که کانتینرهای پاد متوقف و منابعش آزاد شده‌اند.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cp>اگر هر کدام از این دو نیمه‌کاره بماند، پاد در وضعیت Terminating قفل می‌شود. رایج‌ترین دلایل در عمل این‌ها هستند:\u003C\u002Fp>\n\n\u003Cul>\n\u003Cli>\u003Cstrong>نود NotReady یا kubelet بی‌پاسخ:\u003C\u002Fstrong> kubelet نمی‌تواند SIGTERM را پردازش کند و تایید نهایی را به API Server برنگرداند. این حالت بعد از کرش‌کردن نود یا پرشدن دیسک نود خیلی شایع است.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>finalizer باقی‌مانده از یک اپراتور:\u003C\u002Fstrong> بعضی اپراتورها یا webhookها یک finalizer به پاد اضافه می‌کنند تا قبل از حذف، کار پاک‌سازی انجام دهند. اگر آن کنترلر خودش از کار افتاده باشد، finalizer هرگز برداشته نمی‌شود.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>گیرکردن attach\u002Fdetach ولوم:\u003C\u002Fstrong> اگر پاد از یک PVC استفاده کند و CSI driver یا \u003Ccode>VolumeAttachment\u003C\u002Fcode> در حالت detach بماند، پاد منتظر آزادسازی ولوم می‌ماند.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>preStop hook بلاک‌شده:\u003C\u002Fstrong> یک hook طولانی یا منتظر روی endpoint خارجی، کل مسیر خاتمه را متوقف می‌کند.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>هنگ‌کردن containerd:\u003C\u002Fstrong> گاهی خود runtime در تمیزکردن کانتینر گیر می‌کند.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"راه‌حل-گام‌به‌گام\">راه‌حل گام‌به‌گام\u003C\u002Fh2>\n\n\u003Cblockquote>قبل از هر چیز: بدون بررسی علت، \u003Ccode>--force\u003C\u002Fcode> نزنید. حذف اجباری می‌تواند پاد را از etcd پاک کند در حالی که کانتینر روی نود هنوز زنده است و همان پورت‌ها را گرفته — نتیجه‌اش یک نود zombie و خطای «address already in use» در پاد بعدی است.\u003C\u002Fblockquote>\n\n\u003Ch3 id=\"گام-۱-جمع‌آوری-شواهد\">گام ۱ — جمع‌آوری شواهد\u003C\u002Fh3>\n\n\u003Cp>اول مشخص کنید پاد روی کدام نود است و آن نود چه وضعیتی دارد:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl get pod web-7d9f8c6b5-4xk2p -n production -o wide\nkubectl get nodes\nkubectl describe node ip-10-0-14-23 | grep -i -E \"Conditions|Ready|NotReady\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>سپس رویدادهای مربوط به همان پاد را ببینید:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl get events -n production \\\n  --field-selector involvedObject.name=web-7d9f8c6b5-4xk2p \\\n  --sort-by=.lastTimestamp\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch3 id=\"گام-۲-اگر-نود-notready-است-اول-نود-را-درست-کنید\">گام ۲ — اگر نود NotReady است، اول نود را درست کنید\u003C\u002Fh3>\n\n\u003Cp>وقتی نود در وضعیت \u003Ccode>NotReady\u003C\u002Fcode> است، راه‌حل درست این نیست که پاد را force delete کنید؛ باید kubelet و runtime را روی نود سر حال برگردانید. روی خود نود:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\"># روی نود مشکل‌دار\nssh ip-10-0-14-23\n\nsystemctl status kubelet --no-pager\njournalctl -u kubelet -n 100 --no-pager\n\n# اگر containerd هنگ کرده باشد\nsystemctl restart containerd\nsystemctl restart kubelet\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>دقت کنید که \u003Ccode>systemctl restart containerd\u003C\u002Fcode> روی همه کانتینرهای آن نود اثر می‌گذارد؛ اگر نود پرترافیک است، اول آن را \u003Ccode>kubectl cordon\u003C\u002Fcode> کنید تا بار جدید نگیرد.\u003C\u002Fp>\n\n\u003Ch3 id=\"گام-۳-اگر-finalizer-گیر-کرده-است\">گام ۳ — اگر finalizer گیر کرده است\u003C\u002Fh3>\n\n\u003Cp>اگر نود سالم است و فقط یک finalizer باقی مانده، می‌توانید آن را از متادیتای پاد حذف کنید:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl patch pod web-7d9f8c6b5-4xk2p -n production \\\n  --type=merge -p '{\"metadata\":{\"finalizers\":null}}'\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>این کار باید با آگاهی انجام شود: اگر finalizer متعلق به یک کنترلر پاک‌سازی واقعی است، حذفش یعنی منابع پشت آن (بکاپ، رکورد DNS، رکورد ابری) ممکن است برای همیشه یتیم بمانند. اول بفهمید کدام اپراتور آن را گذاشته است.\u003C\u002Fp>\n\n\u003Ch3 id=\"گام-۴-اگر-ولوم-گیر-کرده-است\">گام ۴ — اگر ولوم گیر کرده است\u003C\u002Fh3>\n\n\u003Cp>پادهای دارای PVC وقتی نود از دسترس خارج شود، اغلب به خاطر ولوم در Terminating می‌مانند. وضعیت اتصال‌ها را ببینید:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl get volumeattachments\nkubectl describe volumeattachment \u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>اگر \u003Ccode>VolumeAttachment\u003C\u002Fcode> در حالت detach گیر کرده و مطمئنید پاد دیگر روی هیچ نودی اجرا نمی‌شود، finalizer آن را بردارید:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl patch volumeattachment \u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch3 id=\"گام-۵-حذف-اجباری-به‌عنوان-آخرین-راه\">گام ۵ — حذف اجباری به‌عنوان آخرین راه\u003C\u002Fh3>\n\n\u003Cp>اگر نود برای همیشه رفته (مثلاً ماشین ابری terminate شده) و می‌خواهید فقط شیء پاد را از etcd پاک کنید:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl delete pod web-7d9f8c6b5-4xk2p -n production \\\n  --grace-period=0 --force\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>این دستور فقط شیء API را می‌کوبد و هیچ کاری روی کانتینر واقعی انجام نمی‌دهد. اگر نود زنده است، قبلاً آن را cordon و drain کنید.\u003C\u002Fp>\n\n\u003Ch2 id=\"بررسی-اینکه-مشکل-واقعا-حل-شده-است\">بررسی اینکه مشکل واقعاً حل شده است\u003C\u002Fh2>\n\n\u003Cp>بعد از هر گام، بدون حدس‌زدن تاییدیه بگیرید:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\"># ۱. پاد باید کاملاً از لیست رفته باشد\nkubectl get pods -n production\n\n# ۲. نباید پاد مرده‌ای باقی مانده باشد\nkubectl get pods -A --field-selector status.phase!=Running | grep -i terminating\n\n# ۳. VolumeAttachmentهای یتیم نباید باقی بمانند\nkubectl get volumeattachments\n\n# ۴. روی نود نباید کانتینر یتیم باقی مانده باشد\nkubectl describe node ip-10-0-14-23 | grep -i -A5 \"Non-terminated Pods\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>در نهایت مطمئن شوید که Deployment جایگزین سالم بالا آمده و endpoints سرویس پر است:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-bash\">kubectl rollout status deployment\u002Fweb -n production\nkubectl get endpoints web -n production\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>اگر Endpoints سرویس پادهای سالم را نشان می‌دهد و هیچ پاد Terminating در کلاستر نمی‌بینید، کار تمام است.\u003C\u002Fp>\n\n\u003Ch2 id=\"پیشگیری-و-بهترین-روش‌ها\">پیشگیری و بهترین روش‌ها\u003C\u002Fh2>\n\n\u003Cul>\n\u003Cli>\u003Cstrong>مقدار مناسب برای \u003Ccode>terminationGracePeriodSeconds\u003C\u002Fcode>:\u003C\u002Fstrong> نه خیلی کوتاه (که باعث SIGKILL زودهنگام شود) و نه آن‌قدر بلند که drain نود را قفل کند. برای اکثر سرویس‌ها ۳۰ تا ۶۰ ثانیه کافی است.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>preStop hook کوتاه و بدون انتظار روی سرویس خارجی:\u003C\u002Fstrong> یک \u003Ccode>sleep 5\u003C\u002Fcode> برای تخلیه connection کافی است؛ انتظار روی health check یک API بیرونی، فقط چرخه حذف را شکننده می‌کند.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>مراقب finalizerهای سفارشی باشید:\u003C\u002Fstrong> هر اپراتوری که به پاد finalizer اضافه می‌کند باید خودش پایش شود. اپراتور از کار افتاده یعنی پادهای گیرکرده در آینده.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>برای تعمیرات از drain استفاده کنید، نه حذف نود:\u003C\u002Fstrong> \u003Ccode>kubectl drain <node> --ignore-daemonsets --delete-emptydir-data\u003C\u002Fcode> مسیر خاتمه را مرتب طی می‌کند و ولوم‌ها را تمیز detach می‌کند.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>هشدار \u003Ca href=\"\u002Fservices\u002Fmonitoring\">مانیتورینگ\u003C\u002Fa> برای پادهای گیرکرده:\u003C\u002Fstrong> با kube-state-metrics می‌توانید پادهایی را که مدت طولانی در حال حذف هستند هشدار دهید:\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cpre>\u003Ccode class=\"language-yaml\">- alert: PodStuckTerminating\n  expr: (time() - kube_pod_deletion_timestamp) > 600\n  for: 5m\n  labels:\n    severity: warning\n  annotations:\n    summary: \"پاد {{ $labels.namespace }}\u002F{{ $labels.pod }} بیش از ۱۰ دقیقه در حال حذف است\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>و در آخر، نسخه kubelet، containerd و CSI driver را به‌روز نگه دارید؛ بخش قابل توجهی از پادهای گیرکرده در Terminating ریشه در باگ‌های همین لایه‌ها دارد که در نسخه‌های بعدی رفع شده‌اند.\u003C\u002Fp>",[31,35,38,41,45,48,51,54,57,60],{"id":32,"text":33,"level":34},"شرح-مسئله-پادی-که-نمی‌خواهد-برود","شرح مسئله: پادی که نمی‌خواهد برود",2,{"id":36,"text":37,"level":34},"علت-ریشه‌ای-چرخه-حذف-پاد-کجا-می‌شکند","علت ریشه‌ای: چرخه حذف پاد کجا می‌شکند",{"id":39,"text":40,"level":34},"راه‌حل-گام‌به‌گام","راه‌حل گام‌به‌گام",{"id":42,"text":43,"level":44},"گام-۱-جمع‌آوری-شواهد","گام ۱ — جمع‌آوری شواهد",3,{"id":46,"text":47,"level":44},"گام-۲-اگر-نود-notready-است-اول-نود-را-درست-کنید","گام ۲ — اگر نود NotReady است، اول نود را درست کنید",{"id":49,"text":50,"level":44},"گام-۳-اگر-finalizer-گیر-کرده-است","گام ۳ — اگر finalizer گیر کرده است",{"id":52,"text":53,"level":44},"گام-۴-اگر-ولوم-گیر-کرده-است","گام ۴ — اگر ولوم گیر کرده است",{"id":55,"text":56,"level":44},"گام-۵-حذف-اجباری-به‌عنوان-آخرین-راه","گام ۵ — حذف اجباری به‌عنوان آخرین راه",{"id":58,"text":59,"level":34},"بررسی-اینکه-مشکل-واقعا-حل-شده-است","بررسی اینکه مشکل واقعاً حل شده است",{"id":61,"text":62,"level":34},"پیشگیری-و-بهترین-روش‌ها","پیشگیری و بهترین روش‌ها",[64,65,68,71,73],{"name":13,"slug":13},{"name":66,"slug":67},"Troubleshooting","troubleshooting",{"name":69,"slug":70},"Terminating","terminating",{"name":72,"slug":72},"finalizer",{"name":74,"slug":74},"kubectl",[76,79,82],{"question":77,"answer":78},"آیا حذف پاد با --force خطرناک است؟","بله. حذف اجباری فقط شیء پاد را از etcd پاک می‌کند و هیچ کاری با کانتینر واقعی روی نود ندارد. اگر نود زنده باشد، کانتینر همچنان پورت‌ها و volume mountها را نگه می‌دارد و ممکن است پاد بعدی با خطای پورت در حال استفاده یا ناسازگاری ولوم روبه‌رو شود. فقط وقتی مطمئن شدید نود مرده است یا قبلاً آن را drain کرده‌اید از --force استفاده کنید.",{"question":80,"answer":81},"تفاوت Terminating با CrashLoopBackOff چیست؟","CrashLoopBackOff یعنی کانتینر بالا می‌آید ولی مکرراً از کار می‌افتد و kubelet بین تلاش‌ها عقب‌نشینی می‌کند. Terminating یعنی پاد در حال حذف است اما فرایند حذف تمام نشده. این دو مشکل ریشه‌ای کاملاً متفاوت دارند و نباید با هم اشتباه گرفته شوند.",{"question":83,"answer":84},"چرا بعد از حذف، پاد دوباره ساخته می‌شود؟","چون پاد توسط یک کنترلر مثل Deployment یا ReplicaSet مدیریت می‌شود. آن کنترلر تعداد replica مورد انتظار را دوباره برقرار می‌کند و یک پاد جدید با نام متفاوت می‌سازد. اگر می‌خواهید پاد برای همیشه برود، باید خود Deployment را scale کنید یا حذف کنید، نه فقط پاد را.",[13,86,87],"cloud-migration","managed-devops",true,"راهنمای رفع گیرکردن پاد Kubernetes در وضعیت Terminating؛ بررسی finalizer، نود NotReady و volume attachment و آزادسازی امن بدون از دست دادن داده.",[91,105,119],{"id":44,"title":92,"slug":93,"excerpt":94,"cover":95,"category":97,"author":100,"track":101,"level":102,"reading_minutes":103,"is_featured":27,"published_at":104,"updated_at":104},"قطع شدن WebSocket در HAProxy هر ۵۰ ثانیه؛ علت و راه‌حل","haproxy-websocket-timeout-50s","اگر WebSocket یا SSE پشت HAProxy هر ۵۰ ثانیه قطع می‌شود، مقصر تایماوت‌های پیش‌فرض فایل نمونه است. در این مقاله علت ریشه‌ای و پیکربندی درست timeout tunnel را بررسی می‌کنیم.",{"url":96,"alt":92},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F26b583b4-d805-45d6-a265-a94d73b5a21d.webp",{"name":98,"slug":99},"Linux و مدیریت سرور","linux",{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},7,"2026-10-07T07:57:29+00:00",{"id":106,"title":107,"slug":108,"excerpt":109,"cover":110,"category":112,"author":115,"track":116,"level":117,"reading_minutes":26,"is_featured":27,"published_at":118,"updated_at":118},8,"رفع dkim=none در Postfix با راه‌اندازی OpenDKIM","postfix-opendkim-dkim-signing-fix","اگر ایمیل‌های سرور Postfix شما در Gmail به اسپم می‌روند و هدر پیام dkim=none نشان می‌دهد، یعنی هیچ امضای DKIM روی پیام‌ها درج نمی‌شود. در این مقاله OpenDKIM را نصب، پیکربندی و به Postfix وصل می‌کنیم و رکورد DNS را منتشر می‌کنیم.",{"url":111,"alt":107},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F1b1288db-c0ed-41f3-8ee5-01f7b997c11d.webp",{"name":113,"slug":114},"ابزارهای Self-Hosted","self-hosted",{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-10-09T13:30:31+00:00",{"id":103,"title":120,"slug":121,"excerpt":122,"cover":123,"category":125,"author":128,"track":129,"level":130,"reading_minutes":106,"is_featured":27,"published_at":131,"updated_at":131},"چرا همگام‌سازی JQL در Jira فقط ۵۰ ایشو برمی‌گرداند؟","jira-jql-search-nextpagetoken-pagination","اگر job همگام‌سازی Jira شما بدون خطا تمام می‌شود ولی فقط ۵۰ ایشو را می‌آورد یا در حلقه بی‌پایان گیر می‌کند، مشکل از JQL نیست؛ اندپوینت search به pagination مبتنی بر nextPageToken منتقل شده و startAt و total دیگر وجود ندارند.",{"url":124,"alt":120},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002Facfa9ea0-bda9-4ade-a1c3-0f1677851587.webp",{"name":126,"slug":127},"CI\u002FCD و اتوماسیون","cicd",{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-10-08T15:34:25+00:00"]