یک الگوی اساسی CloudFormation برای وظایف برنامه ریزی شده قوی در ECS در EC2

معرفی

این یک داستان واقعی است.

یک روز

من: باشه، برنامه دسته ای کامل شد. این پردازش دسته ای بسیار مهم است، بنابراین باید بی عیب و نقص کار کند.

من:اگه اجرا نمیشه…

من: فایده نداره الان بهش فکر کنم.

من: ثبت آن با وظایف برنامه ریزی شده ECS…، انجام شد!

من: حتی اگر برنامه از کار بیفتد، من در حال نظارت بر خطاهای برنامه و خرابی وظایف هستم، پس باید خوب باشد!

چند ماه بعد

رئیس: هی! برنامه دسته ای ظاهرا کار نمی کند!!

من چی…؟

من: هیچ اعلان خطا یا شکست وظیفه ای دریافت نکرده ام!

رئیس: مهم نیست! درستش کن!!

من: بله قربان! فعلا تسک امروز رو به صورت دستی اجرا کردم!!

بعد از کار

من: تعجب می کنم که چرا اجرا نشد. بیایید نگاهی به CloudTrail بیندازیم… وظایف ECS از طریق RunTask API راه اندازی می شوند، بنابراین اجازه دهید نام رویداد RunTask را جستجو کنیم…

من: اونجا هست. و دلیل شکست این است که …؟

"failures": [
    {
        "arn": "arn:aws:ecs:ap-northeast-1:xxx:container-instance/xxx",
        "reason": "AGENT"
    }
]

من: دلیلش اینه که…عامل؟

انگیزه

آیا تا به حال این ضرب المثل را شنیده اید که “شما نمی توانید امواج را متوقف کنید، اما می توانید موج سواری را یاد بگیرید”؟
خب، در مورد من، «امواج» شکست‌های کاری در یک ECS در محیط EC2 بود و «یادگیری موج‌سواری» مستلزم سرکشی‌های زیاد، جستجوی دیوانه‌وار در گوگل، و در نهایت، یک تاریخ با الگوهای CloudFormation و توابع مرحله بود.
این پست شرح وقایع درس‌های «موج‌سواری» من است: مبارزاتی که با آن روبرو شدم و اینکه چگونه در نهایت «امواج» را رام کردم.

علت ریشه ای

در محیط ECS در EC2، سه الگوی شکست برای وظایف برنامه ریزی شده وجود دارد:

1. خرابی ناشی از یک برنامه: این اتفاق زمانی رخ می دهد که یک کار به دلیل خطا در برنامه با شکست مواجه شود. اگر یک stack trace در خروجی استاندارد کار وجود داشته باشد که نشان دهنده خطای برنامه باشد، این مورد است.

2. شکست به دلیل تنظیمات کار: این نشان دهنده موقعیت هایی مانند حافظه ناکافی است. اگر حافظه کافی برای راه اندازی تسک ECS و اجرای برنامه وجود نداشته باشد، کار پیش از موعد خاتمه می یابد.

3. شکست به دلیل ناتوانی در راه اندازی کار: این مشکلی است که این مقاله به آن می پردازد. زمانی اتفاق می‌افتد که ارتباط با ECS Agent قطع شود، یا زمانی که حافظه کافی روی EC2 برای راه‌اندازی کار باقی نمانده باشد. تشخیص این مورد دشوار است زیرا کار بدون اجرا به پایان می رسد.

همانطور که در این مقاله بر روی نوع سوم شکست تمرکز می کنیم، بیایید عمیق تر به علت اصلی آن بپردازیم.

در یک EC2 که به عنوان نمونه کانتینری اجرا می شود، ECS Agent دائماً فعال است تا با ECS ارتباط برقرار کند. با این حال، این Agent هر چند ساعت یک بار به روز می شود و اگر این زمان بندی با راه اندازی یک کار ECS همپوشانی داشته باشد، عملیات منجر به خطا می شود. این به دلیل یک خطای برنامه یا خاتمه غیرعادی کار ECS نیست، بلکه به این دلیل است که در وهله اول حتی نمی تواند EC2 را سوار کند.

بنابراین، بهترین راه برای مقابله با این موضوع چیست؟»

راه حل

اولاً، یک راه حل ممکن، قرار دادن توابع Step است.
این روش بسیار عالی است، زیرا امکان تلاش مجدد با StepFunctions از طریق RunTask را فراهم می کند و تغییرات حداقل هستند. (در حالی که تلاش های مجدد با قوانین EventBridge امکان پذیر است، به نظر می رسد که این مورد خاص را شناسایی نمی کند.)

با این حال، اگر بسیاری از وظایف در حال اجرا هستند، هزینه مهاجرت همه آنها می تواند کمی بالا باشد.

بنابراین، من در مورد ایجاد زیرساختی با قابلیت تشخیص خطا در راه‌اندازی و تلاش مجدد فکر کردم و در نهایت الگوی CloudFormation زیر را ایجاد کردم.

(منابع سمت راست نمودار معماری ایجاد خواهد شد. مخزن همچنین شامل Terraform برای ایجاد منابع سمت چپ است.)

این الگو با استفاده از EventBridge خرابی راه‌اندازی کار ECS را شناسایی می‌کند و از توابع مرحله برای امتحان مجدد کار استفاده می‌کند.

برخلاف زیرساختی که قبلا ذکر شد، نیازی نیست همه وظایف ECS موجود را به این الگو منتقل کنید.
فقط زمانی تلاش می‌کند که راه‌اندازی یک کار با شکست مواجه شود.

لینک ایجاد سریع اینجاست💁‍♂️

https://console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/create/review?templateURL=https://s3.ap-northeast-1.amazonaws.com/cd -template-okamos/ecs_rerun_cfn/main.yml

توضیحات الگو

همانطور که در نمودار معماری نشان داده شده است، الگو منابع زیر را ایجاد می کند:

• EventBridge (و قوانین)
• توابع مرحله
• موضوع SNS
• تابع لامبدا
• (و نقش ها و سیاست های IAM مرتبط.)

رویداد پل

ابتدا باید رویدادهای شکست را شناسایی کنیم. اینجاست که EventBridge وارد می‌شود. در اینجا قانونی است که من ایجاد کردم:

{
  "detail-type": ["AWS API Call via CloudTrail"],
  "source": ["aws.ecs"],
  "detail": {
    "responseElements": {
      "failures": {
        "reason": [{
          "exists": true
        }]
      }
    },
    "requestParameters": {
      "startedBy": [{
        "anything-but": "AWS Step Functions"
      }]
    },
    "eventSource": ["ecs.amazonaws.com"],
    "eventName": ["RunTask"]
  }
}

من توضیح ساده ای از این قانون ارائه خواهم کرد. «هر چیزی-به جز» به معنای نفی است، به این معنی که رویدادهای وظیفه ECS که توسط StepFunction ها آغاز می شوند برای جلوگیری از خطر یک حلقه نامحدود حذف می شوند. در واقع، من در حین آزمایش یک حلقه بی نهایت را تجربه کردم و مجبور شدم منابع را با عجله حذف کنم…

“وجود” شرط وجود است، به این معنی که در این مورد، زمانی که “شکست ها” یک آرایه خالی نباشند، آغاز می شود.

برای جزئیات بیشتر به سند رسمی مراجعه کنید.

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html

توابع مرحله

SNS با Lambda همکاری می کند و برای اعلان های Slack استفاده می شود. بررسی Reason علت شکست را تأیید می‌کند و اگر AGENT باشد، سعی می‌کند دوباره امتحان کند.

نتیجه

برنامه های دسته ای نقش مهمی در بسیاری از برنامه ها ایفا می کنند. هنگامی که اجرای آنها قطع شود، می تواند منجر به مشکلات اساسی شود. در این مقاله، ما راه حلی را برای زمانی که اجرای وظیفه در Amazon ECS به دلیل خطای AGENT ناموفق است، پیشنهاد کردیم.

به عنوان یک راه حل، ما یک الگوی CloudFormation ایجاد کردیم تا خطاهای راه اندازی ECS را شناسایی کرده و دوباره امتحان کنید. ما از EventBridge برای شناسایی رویدادهای شکست و توابع Step برای راه اندازی مجدد وظایف استفاده کردیم.

علاوه بر این، این روش نیازی به انتقال همه وظایف ECS موجود ندارد، و تنها زمانی که راه‌اندازی یک کار با شکست مواجه می‌شود، سعی می‌کند دوباره امتحان کند، و آن را تبدیل به یک منبع خارجی با قابلیت پیاده‌سازی آسان می‌کند.

امیدوارم این مقاله به شما در دستیابی به برنامه های دسته ای قابل اعتماد در Amazon ECS کمک کند.😉