آموزش جامع: اجرای کانتینر داکر در AWS Lambda

پیش‌نیازها و ملزومات شروع

برای موفقیت در استقرار کانتینرهای داکر در AWS Lambda، فراهم آوردن مجموعه‌ای از پیش‌نیازهای فنی و نرم‌افزاری ضروری است. این بخش به تفصیل ابزارها، دانش و تنظیمات لازم را توضیح می‌دهد تا بتوانید گام‌به‌گام این راهنما را دنبال کرده و کانتینر داکر خود را با موفقیت در محیط سرورلس AWS مستقر کنید. هدف این است که با درک کامل این ملزومات، فرآیند پیاده‌سازی روان‌تر و بدون چالش‌های ناخواسته پیش برود. اطمینان از آمادگی کامل در این مراحل اولیه، تجربه یادگیری و پیاده‌سازی شما را به میزان قابل توجهی بهبود می‌بخشد و مسیر استقرار را هموارتر می‌سازد.

آشنایی با داکر و محیط توسعه محلی

اولین و شاید مهم‌ترین پیش‌نیاز، داشتن دانش کافی در مورد داکر (Docker) و نصب آن به صورت محلی است. داکر ابزاری قدرتمند است که به شما امکان می‌دهد تا برنامه‌ها یا نرم‌افزارها را در واحدهای قابل حمل، استاندارد شده و قابل اشتراک‌گذاری بسته‌بندی کنید. این واحدها که “کانتینر” نامیده می‌شوند، شامل تمام آنچه یک برنامه برای اجرا نیاز دارد، از جمله کتابخانه‌ها، زمان اجرا (runtime)، ابزارهای سیستمی و کد برنامه، هستند. این مفهوم بسته‌بندی، اطمینان می‌دهد که برنامه شما بدون توجه به محیطی که در آن اجرا می‌شود، به طور یکسان عمل خواهد کرد. این مزیت، چالش‌های معمول استقرار برنامه‌ها را به حداقل می‌رساند.

برای دنبال کردن این آموزش، شما باید داکر را بر روی سیستم عامل خود نصب کرده باشید. این نصب به شما اجازه می‌دهد تا ایمیج‌های داکر را به صورت محلی بسازید، کانتینرها را اجرا کنید و عملکرد آن‌ها را پیش از استقرار در فضای ابری تست نمایید. توانایی ساخت و تست محلی، یک گام حیاتی در چرخه توسعه و استقرار است، زیرا به شما امکان می‌دهد هرگونه خطا یا مشکل را قبل از اینکه به محیط تولید برسد، شناسایی و برطرف کنید. در واقع، درک چگونگی ساخت یک ایمیج داکر از یک Dockerfile که شامل دستورالعمل‌های مورد نیاز برای ایجاد قالب کانتینر است، از اصول اساسی است که در این مسیر به آن نیاز خواهید داشت. به عنوان مثال، برای یک برنامه پایتون، نیاز به یک ایمیج پایه پایتون از ECR عمومی AWS خواهید داشت و سپس فایل‌های کد خود را به مسیر مشخصی در آن کپی می‌کنید تا کانتینر شما آماده اجرا شود.

حساب کاربری AWS و ابزارهای خط فرمان

گام بعدی، داشتن یک حساب کاربری فعال در سرویس‌های وب آمازون (AWS) است. این حساب باید دارای اعتبارنامه‌هایی باشد که اجازه دسترسی مدیریتی برای انجام فراخوانی‌های API از طریق رابط خط فرمان (CLI) را می‌دهد. با این حال، به عنوان یک بهترین تمرین (best practice) امنیتی، توصیه می‌شود که دسترسی‌ها را دقیقاً به آنچه برای انجام وظایف ضروری است، محدود کنید. این رویکرد به حداقل رساندن سطح حمله (attack surface) کمک می‌کند و امنیت کلی حساب شما را افزایش می‌دهد و از ریسک‌های غیرضروری جلوگیری می‌کند.

نصب و پیکربندی AWS CLI (رابط خط فرمان AWS) به صورت محلی نیز از الزامات اصلی است. AWS CLI ابزاری است که به شما امکان می‌دهد تا با سرویس‌های AWS از طریق ترمینال یا خط فرمان ارتباط برقرار کنید و دستورات مختلفی را اجرا نمایید. این دستورات شامل ایجاد مخازن ECR (Amazon Elastic Container Registry)، احراز هویت برای ارسال ایمیج‌ها، و مدیریت توابع Lambda می‌شود. برای مثال، برای ایجاد یک مخزن ECR یا احراز هویت داکر با ECR، از دستورات CLI استفاده خواهد شد. اطمینان حاصل کنید که اعتبارنامه‌های AWS شما به درستی در AWS CLI پیکربندی شده‌اند (معمولاً با اجرای دستور aws configure و ارائه کلیدهای دسترسی). این پیکربندی امکان تعامل بدون وقفه با سرویس‌های ابری را فراهم می‌کند و شما را قادر می‌سازد تا منابع خود را به راحتی مدیریت کنید.

مدیریت محیط‌های پایتون و ابزارهای کمکی

در این راهنما، از یک برنامه ساده پایتون به عنوان نمونه استفاده می‌شود. بنابراین، آشنایی با مدیریت محیط‌های مجازی پایتون بسیار مفید خواهد بود. ابزارهایی مانند uv (که در متن مرجع ذکر شده است) یا venv استاندارد پایتون، به شما کمک می‌کنند تا وابستگی‌های پروژه خود را به صورت ایزوله مدیریت کنید. این ایزوله‌سازی از تداخل نسخه‌های مختلف کتابخانه‌ها جلوگیری می‌کند و اطمینان می‌دهد که پروژه شما در یک محیط کنترل‌شده و پایدار اجرا می‌شود. اگرچه استفاده از یک مدیر محیط مجازی پایتون اختیاری است، اما اکیداً برای حفظ نظم و جلوگیری از مشکلات احتمالی در هنگام نصب کتابخانه‌های خارجی مانند requests توصیه می‌شود، به‌ویژه زمانی که با پروژه‌های متعددی سر و کار دارید.

وقتی یک برنامه پایتون را در کانتینر داکر خود قرار می‌دهید و آن را در Lambda اجرا می‌کنید، این محیط مجازی به شما اجازه می‌دهد تا برنامه‌تان را با تمام وابستگی‌های صحیح، محلی تست کنید. مثلاً، برای تست عملکرد کانتینر داکر که بر روی پورت 8080 اجرا می‌شود، نیاز به ارسال یک درخواست HTTP POST با یک payload JSON خواهید داشت. کتابخانه requests پایتون ابزار مناسبی برای این کار است و با استفاده از یک محیط مجازی، می‌توانید آن را بدون تأثیر بر سایر پروژه‌های پایتون خود نصب و استفاده کنید. این گام پایانی در بخش آماده‌سازی محلی، به شما اطمینان می‌دهد که کانتینر شما قبل از ارسال به ECR و استقرار نهایی در Lambda، به درستی کار می‌کند و هرگونه اشکالی شناسایی و رفع شده است. با این آمادگی، می‌توانید با اطمینان خاطر به مراحل بعدی استقرار وارد شوید.

مقدمه‌ای بر Serverless و AWS Lambda

در دنیای پرشتاب توسعه نرم‌افزار، انتخاب بهترین روش برای استقرار اپلیکیشن‌ها همواره یک چالش اساسی بوده است. کانتینرها، به‌ویژه Docker، با ارائه یک محیط سبک، سازگار و با منابع بهینه برای اجرای اپلیکیشن‌ها، تحولی بزرگ ایجاد کرده‌اند. با این حال، حتی با وجود مزایای فراوان کانتینرها، تصمیم‌گیری در مورد نحوه استقرار آن‌ها، به‌خصوص برای سناریوهای ساده‌ای که شامل اجرای تنها یک کانتینر می‌شوند، می‌تواند پیچیده باشد. بسیاری از راه‌حل‌های ارکستراسیون و مدیریت کانتینرها، ممکن است برای یک مورد استفاده ساده، بیش از حد پیچیده و سنگین باشند. در این میان، رویکرد Serverless به همراه سرویس‌هایی مانند AWS Lambda، پاسخی کارآمد و اقتصادی به این چالش‌ها ارائه می‌دهد. این ترکیب قدرتمند، نه تنها برای اپلیکیشن‌های پیچیده و بک‌اندهای سنگین، بلکه برای وب‌سایت‌های مدرن و مقیاس‌پذیر، از جمله پلتفرم‌های محبوبی مانند وردپرس که نیاز به انعطاف‌پذیری بالا و مدیریت ساده زیرساخت دارند، فرصت‌های بی‌نظیری ایجاد می‌کند و به توسعه‌دهندگان اجازه می‌دهد تا تمرکز خود را بر روی ارزش‌آفرینی اصلی معطوف سازند.

فلسفه و مزایای Serverless در توسعه نرم‌افزار

مفهوم Serverless، انقلابی در نحوه تفکر ما درباره زیرساخت‌ها و استقرار اپلیکیشن‌ها به وجود آورده است. فلسفه اصلی Serverless، حذف سربار ناشی از مدیریت زیرساخت‌های پنهان (underlying infrastructures) است که کانتینرها یا کدهای شما بر روی آن‌ها اجرا می‌شوند. به عبارت دیگر، در مدل Serverless، توسعه‌دهندگان دیگر نگران تامین سرور، به‌روزرسانی سیستم‌عامل، مقیاس‌بندی منابع یا نگهداری سخت‌افزار نیستند. این مسئولیت‌ها به ارائه‌دهنده سرویس ابری واگذار می‌شود و به تیم‌های توسعه‌دهنده این امکان را می‌دهد تا تمام تمرکز خود را بر روی منطق کسب‌وکار، نوآوری در محصول و ویژگی‌هایی که مزیت رقابتی ایجاد می‌کنند، معطوف سازند. این رویکرد، برای هر نوع پروژه، از APIهای کوچک گرفته تا بک‌اندهای پیچیده برای اپلیکیشن‌های موبایل یا وب‌سایت‌های وردپرسی با ترافیک متغیر، ایده‌آل است و به تیم‌ها کمک می‌کند تا با چابکی بیشتری محصول را به بازار عرضه کنند.

مزایای کلیدی رویکرد Serverless فراتر از کاهش بار مدیریتی است. این مدل، امکان مقیاس‌پذیری خودکار و بی‌درنگ را فراهم می‌آورد؛ به این معنی که اپلیکیشن شما می‌تواند به‌سرعت و با انعطاف‌پذیری بالا، به تقاضاهای متغیر پاسخ دهد، بدون آنکه نیازی به پیش‌بینی ظرفیت یا تنظیمات دستی باشد. این مقیاس‌پذیری پویا، به‌ویژه برای وب‌سایت‌ها و سرویس‌هایی که با نوسانات شدید ترافیک مواجه هستند (مانند وب‌سایت‌های خبری یا فروشگاهی در زمان رویدادهای خاص)، یک مزیت بی‌بدیل محسوب می‌شود. علاوه بر این، مدل Serverless معمولاً با کاهش هزینه‌ها همراه است، زیرا شما تنها به ازای میزان مصرف واقعی منابع پرداخت می‌کنید و نیازی به پرداخت هزینه برای منابع بیکار (idle resources) ندارید. این بهینه‌سازی عملکرد و مدیریت منابع، راهکاری جذاب برای کسب‌وکارهایی است که به دنبال افزایش بهره‌وری و کاهش هزینه‌های عملیاتی هستند.

AWS Lambda: ابزاری قدرتمند برای رویکرد Serverless

در اکوسیستم گسترده خدمات ابری آمازون (AWS)، Lambda به‌عنوان یکی از برجسته‌ترین ابزارها برای پیاده‌سازی معماری Serverless شناخته می‌شود. AWS Lambda یک سرویس محاسباتی کاملاً Serverless است که به شما امکان می‌دهد کد خود را بدون نیاز به تامین یا مدیریت سرورها اجرا کنید. با Lambda، شما کد خود را در قالب «توابع» (functions) آپلود می‌کنید و این توابع تنها زمانی «زنده می‌شوند» که توسط یک درخواست یا رویداد خاص فعال شوند. این رویکرد رویدادمحور (event-driven) به این معنی است که توابع شما تنها در صورت لزوم اجرا می‌شوند و پس از اتمام کار، منابع آزاد می‌شوند. این ویژگی برای توسعه‌دهندگان اپلیکیشن‌های وب و موبایل، از جمله کسانی که به دنبال بهینه‌سازی عملکرد و کاهش بار مدیریتی برای وب‌سایت‌های وردپرسی خود هستند، بسیار سودمند است.

یکی از جذاب‌ترین جنبه‌های AWS Lambda، مدل پرداخت آن است. بر خلاف مدل‌های سنتی که در آن شما برای سرورهای همیشه روشن هزینه می‌پردازید، حتی زمانی که استفاده‌ای از آن‌ها نمی‌شود، با Lambda تنها به ازای موارد زیر صورت‌حساب دریافت می‌کنید: تعداد دفعاتی که کد در تابع شما اجرا می‌شود (تعداد فراخوانی‌ها)، میزان حافظه‌ای که در زمان راه‌اندازی سرویس انتخاب کرده‌اید، و مدت زمان هر فراخوانی تابع. این مدل پرداخت «Pay-per-Execution» به شما کمک می‌کند تا هزینه‌های عملیاتی را به میزان قابل توجهی کاهش دهید، زیرا دیگر نگران منابع بیکار و پرداخت هزینه برای آن‌ها نخواهید بود. این شفافیت در هزینه و بهینه‌سازی منابع، برای کسب‌وکارهایی که به دنبال مدیریت دقیق هزینه‌های ابری خود هستند، یک مزیت استراتژیک محسوب می‌شود و امکان صرفه‌جویی مالی قابل توجهی را فراهم می‌آورد.

هم‌افزایی کانتینرها و Serverless: استقرار بهینه Docker در Lambda

کانتینرها، همانطور که پیشتر اشاره شد، راهی سبک‌وزن، سازگار و کارآمد برای اجرای اپلیکیشن‌ها فراهم می‌کنند. آن‌ها اپلیکیشن‌ها و نرم‌افزارها را در واحدهای قابل حمل، استاندارد شده و قابل اشتراک‌گذاری بسته‌بندی می‌کنند که شامل هر آنچه اپلیکیشن برای اجرا نیاز دارد، از جمله کتابخانه‌ها، زمان اجرا (runtime)، ابزارهای سیستمی و کد اپلیکیشن می‌شود. این واحدها، فارغ از محیطی که در آن اجرا می‌شوند، رفتار یکسانی خواهند داشت و به توسعه‌دهندگان امکان تکرارپذیری و اطمینان در استقرار را می‌دهند.

هنگامی که این ویژگی‌های کانتینرها را با مزایای Serverless و به‌طور خاص AWS Lambda ترکیب می‌کنید، به یک راهکار قدرتمند برای استقرار اپلیکیشن‌های خود دست می‌یابید. ترکیب این دو ابزار به شما کمک می‌کند تا اپلیکیشن‌ها را به گونه‌ای استقرار دهید که بر روی منطق کسب‌وکار، عملکرد و مزیت رقابتی محصول خود متمرکز شوید، نه بر روی پیچیدگی‌های زیرساختی. به عنوان مثال، می‌توانید یک کانتینر Docker را که حاوی اپلیکیشن شماست، در AWS Lambda مستقر کنید. این رویکرد، به‌ویژه برای استقرار یک کانتینر تنها، راهی ساده‌تر و کارآمدتر از راه‌اندازی کل پلتفرم‌های ارکستراسیون پیچیده کانتینرها است که ممکن است برای چنین سناریوهایی بیش از حد سنگین باشند. با این روش، سازگاری و قابلیت حمل کانتینرها حفظ می‌شود، در حالی که از مزایای Serverless نظیر عدم نیاز به مدیریت سرور و مدل پرداخت بر اساس مصرف، بهره‌مند می‌شوید. این مدل می‌تواند برای استقرار بخش‌هایی از یک وب‌سایت وردپرسی که نیاز به پردازش‌های سنگین و رویدادمحور دارد یا میکروسرویس‌های مکمل آن، راهگشا باشد و بهینه‌سازی عملکرد و مقیاس‌پذیری بی‌سابقه‌ای را به ارمغان بیاورد.

ساخت، اجرا و تست داکر لوکال

داکر ابزاری قدرتمند برای بسته‌بندی برنامه‌ها و نرم‌افزارها به واحدهای قابل حمل، استاندارد و قابل اشتراک‌گذاری است که کانتینر نامیده می‌شوند. این کانتینرها شامل تمام نیازمندی‌های یک برنامه از جمله کتابخانه‌ها، زمان اجرا، ابزارهای سیستمی و کد برنامه هستند و تضمین می‌کنند که برنامه در هر سیستمی که داکر نصب باشد، به شکلی یکسان عمل کند. در این بخش، با نحوه ساخت ایمیج داکر، اجرای آن به عنوان یک کانتینر و سپس تست عملکرد کانتینر در محیط محلی خود آشنا خواهید شد.

درک نحوه کار با داکر به صورت محلی، پایه و اساس استقرار کانتینرها در محیط‌های ابری مانند AWS Lambda را فراهم می‌کند و به تیم‌های توسعه کمک می‌کند تا فرآیند استقرار و مدیریت برنامه‌ها را ساده‌تر کنند.

ساخت ایمیج داکر

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

به عنوان مثال، فرض کنید یک برنامه ساده پایتون به نام lambda_function.py داریم که یک درخواست POST HTTP را با یک payload JSON حاوی کلید name دریافت می‌کند و یک پیام خوش‌آمدگویی برمی‌گرداند. کد آن به شکل زیر است:

# lambda_function.py
def lambda_handler(event, context):
    name = event["name"]
    message = f"Hello, {name}!"
    try:
        return {
            "statusCode": 200,
            "body": message
        }
    except Exception as e:
        return {
            "statusCode": 400,
            "body": {"error": str(e)}
        }

برای ساخت ایمیج داکر برای این برنامه، از یک Dockerfile ساده استفاده می‌کنیم:

# Dockerfile
FROM public.ecr.aws/lambda/python:3.12
COPY lambda_function.py ${LAMBDA_TASK_ROOT}
CMD ["lambda_function.lambda_handler"]

یک Dockerfile معمولاً با یک ایمیج پایه شروع می‌شود. برای استقرار برنامه به عنوان کانتینر داکر در AWS Lambda، ایمیج پایه باید از نوع خاصی باشد که بستگی به زمان اجرای برنامه دارد. در این مورد، ما به زمان اجرای پایتون نیاز داریم، بنابراین ایمیج پایه public.ecr.aws/lambda/python:3.12 است. دستور COPY فایل lambda_function.py را به مسیر /var/task در ایمیج پایه کپی می‌کند که توسط متغیر محیطی LAMBDA_TASK_ROOT مشخص شده است. در نهایت، دستور CMD مشخص می‌کند که برنامه هنگام اجرای کانتینر چگونه باید آغاز شود.

پس از آماده‌سازی این فایل‌ها، می‌توانید دستور build را از مسیر ریشه پروژه خود اجرا کنید:

docker build -t <IMAGE_NAME>:<IMAGE_TAG> .

اجرای کانتینر داکر

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

docker run -it --rm -p 8080:8080 lambda_docker:1.0.0

این دستور چندین کار کلیدی را انجام می‌دهد:

• -it: کانتینر را در حالت تعاملی (interactive mode) اجرا می‌کند تا لاگ‌های تولید شده توسط برنامه داخل کانتینر را مشاهده کنید.
• --rm: این پرچم باعث می‌شود که کانتینر به صورت خودکار پس از توقف فرآیند اجرا (مثلاً با CTRL + C) حذف شود و از انباشت کانتینرهای بلااستفاده جلوگیری می‌کند.
• -p 8080:8080: این بخش پورت 8080 میزبان (سیستم شما) را به پورت 8080 کانتینر (که پورت پیش‌فرض برای درخواست‌های AWS Lambda است) نگاشت می‌کند.

پس از اجرای این دستور، کانتینر شما شروع به کار می‌کند و برنامه پایتون شما منتظر دریافت درخواست‌ها خواهد بود. مشاهده لاگ‌ها در ترمینال به شما کمک می‌کند تا از وضعیت سلامت و عملکرد اولیه برنامه اطمینان حاصل کنید. می‌توانید با فشردن CTRL + C کانتینر را متوقف کنید.

تست کانتینر در حال اجرا

پس از اجرای موفقیت‌آمیز کانتینر، نوبت به تأیید عملکرد برنامه درون آن می‌رسد. شما باید مطمئن شوید که برنامه قادر به دریافت و پردازش درخواست‌ها طبق انتظار است. برای این منظور، می‌توانیم یک اسکریپت ساده پایتون به نام test.py بنویسیم که یک درخواست POST به کانتینر در حال اجرا ارسال می‌کند:

# test.py
import requests
url = "http://localhost:8080/2015-03-31/functions/function/invocations"
data = { "name": "Janet" }
response = requests.post(url, json=data)
print("Status Code:", response.status_code)
print("Response Body:", response.json())

برای اجرای این کد، نیاز به کتابخانه requests پایتون دارید. توصیه می‌شود که این کتابخانه را در یک محیط مجازی (virtual environment) نصب کنید تا وابستگی‌های پروژه شما از بقیه سیستم ایزوله بماند و از تداخل نسخه‌ها جلوگیری شود. اگر از ابزاری مانند uv برای مدیریت محیط‌های مجازی استفاده می‌کنید، مراحل به صورت زیر خواهد بود:

1. نصب کتابخانه requests در محیط مجازی:

   uv add requests
           

2. اجرای اسکریپت test.py از داخل محیط مجازی:

   uv run python3 test.py
           

پس از اجرای دستور دوم، باید پاسخ مورد انتظار را در ترمینال خود مشاهده کنید. این پاسخ شامل Status Code: 200 و Response Body: {'body': 'Hello, Janet!'} خواهد بود که نشان‌دهنده موفقیت‌آمیز بودن ارتباط و پردازش درخواست توسط برنامه داخل کانتینر داکر است. این مرحله تأیید می‌کند که کانتینر شما به درستی پیکربندی و اجرا شده است و آماده مراحل بعدی استقرار در محیط‌های تولیدی یا ابری است.

پوش ایمیج داکر به Amazon ECR

پس از آماده‌سازی یک ایمیج داکر عملیاتی برای استقرار در AWS Lambda، گام بعدی حیاتی، ارسال این ایمیج به یک رجیستری داکر است. در سناریوی فعلی، این رجیستری Amazon ECR (Elastic Container Registry) خواهد بود؛ سرویسی اختصاصی در اکوسیستم AWS برای ذخیره‌سازی ایمیج‌های داکر. استفاده از ECR تضمین می‌کند که ایمیج شما به شکلی امن، با دسترسی بالا و بهینه‌سازی‌شده برای سرویس‌های AWS مانند Lambda در دسترس قرار گیرد. این فرآیند از چند گام کلیدی تشکیل شده است: تنظیم متغیرهای محیطی، ایجاد مخزن ECR، احراز هویت داکر و در نهایت تگ‌گذاری و ارسال ایمیج. این رویکرد به توسعه‌دهندگان، از جمله افرادی که بر روی بهینه‌سازی پلتفرم‌ها و سیستم‌های مدیریت محتوا تمرکز دارند، امکان می‌دهد تا با دغدغه‌های کمتر زیرساختی، بر منطق کسب‌وکار و ارائه ارزش به کاربران نهایی تمرکز کنند.

آماده‌سازی محیط و پیکربندی AWS CLI

پیش از ارسال ایمیج داکر به ECR، ضروری است که محیط محلی و ابزار AWS CLI (Command Line Interface) پیکربندی شوند. این پیکربندی، امکان برقراری ارتباط CLI با حساب AWS شما و اجرای دستورات مدیریت سرویس‌ها را فراهم می‌کند. برای این منظور، نیاز به یک حساب AWS با اعتبارنامه‌های دارای مجوزهای مدیریتی برای فراخوانی‌های API از طریق CLI است. توجه داشته باشید که محدود کردن مجوزها به حداقل لازم، بهترین روش امنیتی محسوب می‌شود. برای شروع، متغیرهای محیطی کلیدی شامل نام پروفایل AWS، منطقه (Region) AWS، شناسه حساب کاربری (Account ID)، نام مخزن (Repository Name) و تگ ایمیج (Image Tag) را تنظیم می‌کنیم. این متغیرها به دستورات CLI کمک می‌کنند تا به‌درستی هدف‌گذاری شده و خطاهای احتمالی کاهش یابد. پیکربندی صحیح AWS CLI از طریق دستور aws configure، پیش‌نیاز اصلی این مرحله است. این مرحله برای هر پروژه‌ای که با خدمات ابری سروکار دارد، از جمله پروژه‌های توسعه وب یا پشتیبانی از یک وب‌سایت با ترافیک بالا، حیاتی است.

export AWS_PROFILE=<PROFILE_NAME>
export AWS_REGION=<AWS_REGION>
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REPO_NAME=lambda-docker
TAG=1.0.0

این دستورات، پروفایل AWS را برای هدایت فراخوانی‌های API به حساب AWS صحیح تنظیم می‌کنند. سایر متغیرها نیز شناسه حساب، منطقه، نام مخزن ECR و تگ ایمیج را مشخص می‌کنند. این گام ابتدایی، شبیه به تنظیمات اولیه برای استفاده از هر سرویس ابری است.

ایجاد مخزن ECR و احراز هویت داکر

با تنظیم متغیرهای محیطی، گام بعدی ایجاد مخزن ECR است که ایمیج داکر ما در آن ذخیره خواهد شد. این مخزن یک فضای ذخیره‌سازی امن و مدیریت‌شده در AWS برای کانتینر ایمیج‌ها فراهم می‌کند. برای ایجاد این مخزن، از دستور aws ecr create-repository استفاده می‌کنیم:

aws ecr create-repository \
  --repository-name "$REPO_NAME" \
  --region "$AWS_REGION"

پس از ایجاد مخزن، لازم است داکر را برای احراز هویت با Amazon ECR تنظیم کنیم. این احراز هویت به داکر اجازه می‌دهد تا ایمیج‌ها را به مخزن شما در ECR ارسال یا از آن دریافت کند. این یک گام امنیتی مهم است که تضمین می‌کند تنها کاربران و سرویس‌های مجاز می‌توانند با مخزن شما تعامل داشته باشند. احراز هویت با استفاده از دستور زیر انجام می‌شود:

aws ecr get-login-password --region "$AWS_REGION" \
| docker login \
  --username AWS \
  --password-stdin "$ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com"

این دستور یک رمز عبور موقت از ECR دریافت کرده و آن را به دستور docker login ارسال می‌کند. این روش، احراز هویت امن و کوتاه‌مدت را فراهم می‌آورد و از مدیریت دستی رمزهای عبور طولانی جلوگیری می‌کند. این فرایند برای هر توسعه‌دهنده‌ای که با کانتینرها در محیط ابری کار می‌کند، از اهمیت بالایی برخوردار است، زیرا امنیت و دسترسی آسان به منابع را تضمین می‌کند. برای پلتفرم‌های وب که نیاز به مدیریت ایمیج‌های کانتینری برای سرویس‌های بک‌اند خود دارند، این مرحله اساسی است.

تگ‌گذاری و ارسال ایمیج داکر به ECR

اکنون که مخزن ECR ایجاد شده و داکر برای احراز هویت آماده است، آخرین مرحله تگ‌گذاری ایمیج داکر محلی و ارسال آن به ECR است. تگ‌گذاری به معنای اختصاص یک نام منحصربه‌فرد به ایمیج است که به AWS امکان می‌دهد آن را در مخزن ECR شما شناسایی کند. ایمیج شما در حال حاضر تگی مانند lambda-docker:1.0.0 دارد. برای ارسال به ECR، باید آن را با فرمت مورد انتظار AWS تگ‌گذاری کنید:

docker tag $REPO_NAME:$TAG \
$ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO_NAME:$TAG

این دستور، ایمیج محلی شما را با یک تگ جدید شامل شناسه حساب AWS، منطقه و نام مخزن ECR تگ‌گذاری می‌کند. این تگ جدید، مسیر کامل ایمیج را در ECR مشخص و آن را برای ارسال آماده می‌سازد. پس از تگ‌گذاری موفقیت‌آمیز، می‌توانید ایمیج را به مخزن ECR که قبلاً ایجاد کرده‌اید، ارسال کنید:

docker push $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO_NAME:$TAG

با اجرای این دستور، ایمیج داکر شما با موفقیت به Amazon ECR ارسال می‌شود و اکنون آماده است تا توسط سرویس‌های دیگر AWS مانند Lambda برای استقرار و اجرای برنامه شما استفاده شود. این فرایند یک گام حیاتی در چرخه عمر توسعه نرم‌افزار مدرن است و استقرار برنامه‌ها را در محیط‌های سرورلس مانند AWS Lambda تسهیل می‌کند. این گام نهایی، پایه‌های یک استراتژی استقرار قوی را فراهم می‌آورد که به توسعه‌دهندگان امکان می‌دهد تا بر توسعه ویژگی‌ها و بهینه‌سازی عملکرد تمرکز کنند، نه بر پیچیدگی‌های مدیریت زیرساخت. این امر به‌ویژه برای سیستم‌هایی که نیاز به مقیاس‌پذیری بالا و عملکرد بهینه دارند، مانند بک‌اند یک وب‌سایت پربازدید یا یک پلتفرم جامع، بسیار مفید است.

در نهایت، ایمیج شما اکنون در ECR قرار گرفته است. این رویکرد نه تنها امنیت و قابلیت اطمینان را برای ایمیج‌های کانتینری شما به ارمغان می‌آورد، بلکه با ادغام یکپارچه با سایر سرویس‌های AWS، فرآیند استقرار را نیز ساده‌تر می‌کند. این بدان معناست که تمرکز اصلی بر روی کدنویسی و ارائه ارزش به کاربران نهایی خواهد بود، که برای هر تیمی که بر روی توسعه و بهینه‌سازی پلتفرم‌های متنوع کار می‌کند، یک مزیت بزرگ محسوب می‌شود.

استقرار ایمیج داکر در AWS Lambda

اگرچه کانتینرها سبک‌وزن هستند و مزایای متعددی را ارائه می‌دهند، اما تصمیم‌گیری در مورد بهترین روش استقرار آن‌ها می‌تواند چالش‌برانگیز باشد. راه‌های مختلفی برای استقرار و اجرای کانتینرهای داکر وجود دارد، اما برخی از آن‌ها برای مدیریت و ارکستراسیون چندین کانتینر مناسب‌ترند و ممکن است برای یک مورد استفاده ساده از اجرای تنها یک کانتینر، ایده‌آل نباشند. در این بخش، ما چگونگی استقرار یک کانتینر داکر واحد را با استفاده از سرویس سرورلس AWS به نام Lambda بررسی خواهیم کرد.

پیش‌نیازها و ملزومات اساسی

برای دنبال کردن این راهنما و موفقیت در استقرار کانتینرهای داکر در محیط سرورلس AWS Lambda، داشتن ابزارها و مهارت‌های خاصی ضروری است. ابتدا، آشنایی با داکر و نصب آن به صورت محلی الزامی است تا بتوانید ایمیج‌ها را بسازید و به صورت محلی تست کنید. در مرحله بعد، شما به یک حساب AWS با دسترسی مدیریتی برای برقراری تماس‌های API از طریق AWS CLI نیاز خواهید داشت؛ هرچند، بهترین روش این است که دسترسی‌ها را دقیقاً به آنچه مورد نیاز است، محدود کنید. نصب AWS CLI به صورت محلی نیز برای تعامل با سرویس‌های AWS ضروری است. علاوه بر این، استفاده از مدیریت‌کننده‌های محیط مجازی پایتون مانند `uv` (اختیاری) می‌تواند به ایزوله نگه داشتن وابستگی‌های پروژه کمک کند و از تداخل‌های احتمالی در نسخه‌های کتابخانه‌ها جلوگیری نماید.

آماده‌سازی ایمیج داکر: ساخت، اجرا و تست محلی

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

کد مورد استفاده در این مثال یک برنامه پایتون بسیار ساده است که انتظار یک درخواست HTTP از نوع POST با یک payload JSON حاوی کلید «name» و یک مقدار متناظر را دارد. این کد سپس یک پیام خوش‌آمدگویی شامل نام دریافت شده را برمی‌گرداند. برای ساخت یک ایمیج داکر، به یک Dockerfile نیاز دارید تا نقشه‌ای برای ایمیج فراهم کند. Dockerfile شامل دستورالعمل‌هایی است که داکر باید هنگام ایجاد یک ایمیج از آن‌ها پیروی کند. هر خط در Dockerfile یک «Directive» نامیده می‌شود.

Dockerfile معمولاً با یک ایمیج پایه آغاز می‌شود. برای استقرار یک برنامه به عنوان کانتینر داکر در AWS Lambda، ایمیج پایه باید از نوع خاصی باشد که بستگی به زمان اجرای برنامه دارد. برای این مورد، از ایمیج `public.ecr.aws/lambda/python:3.12` استفاده می‌شود که برای زمان اجرای پایتون مناسب است. دستورالعمل بعدی، کپی کردن فایل `lambda_function.py` به مسیری خاص در ایمیج پایه است که با متغیر محیطی `LAMBDA_TASK_ROOT` مشخص شده و به `/var/task` اشاره دارد. این دایرکتوری، محلی است که کد شما از آن اجرا خواهد شد. آخرین دستورالعمل نیز یک فرمان ساده برای شروع برنامه هنگام اجرای کانتینر است.

پس از ساخت ایمیج، می‌توانید با دستور `docker run -it –rm -p 8080:8080 lambda_docker:1.0.0` یک کانتینر فعال از آن ایجاد کنید. این دستور کانتینر را در حالت تعاملی اجرا می‌کند تا بتوانید لاگ‌های تولید شده توسط برنامه را مشاهده کنید. پورت 8080 بر روی هاست نیز به پورت کانتینر (8080) نگاشت می‌شود. در نهایت، با استفاده از یک اسکریپت تست پایتون، می‌توانید تأیید کنید که برنامه در حال اجرا در کانتینر می‌تواند درخواست‌ها را دریافت و پردازش کند. این اسکریپت از کتابخانه `requests` پایتون استفاده می‌کند که می‌توانید آن را در یک محیط مجازی نصب کرده و اجرا نمایید تا پاسخ مطلوب را در ترمینال مشاهده کنید.

ارسال ایمیج داکر به Amazon Elastic Container Registry (ECR)

اکنون که یک ایمیج داکر آماده برای استقرار در Lambda دارید، گام بعدی ارسال این ایمیج به یک رجیستری داکر است. برای این مورد استفاده، ایمیج شما باید به Amazon ECR ارسال شود که یک رجیستری کانتینر برای ذخیره ایمیج‌های داکر است. برای ارسال ایمیج، ابتدا باید آن را تگ‌گذاری کنید، که به معنای نام‌گذاری ایمیج به روشی خاص است.

قبل از هر چیز، نیاز است تا متغیرهای محیطی مربوط به پروفایل AWS، منطقه (Region) و شناسه حساب کاربری (Account ID) را تنظیم کنید. این کار به AWS CLI کمک می‌کند تا درخواست‌های API را به حساب AWS صحیح هدف قرار دهد. سپس، می‌توانید با استفاده از AWS CLI یک ریپازیتوری ECR ایجاد کنید. پس از ایجاد ریپازیتوری، باید به Amazon ECR احراز هویت شوید. این کار با دریافت توکن لاگین و استفاده از آن برای لاگین به داکر انجام می‌شود.

در نهایت، ایمیج داکر خود را با فرمت ECR تگ‌گذاری می‌کنید. این تگ‌گذاری شامل شناسه حساب AWS، منطقه و نام ریپازیتوری است. پس از تگ‌گذاری صحیح، می‌توانید ایمیج را به ریپازیتوری ECR که ایجاد کرده‌اید، ارسال کنید. با انجام این مراحل، ایمیج داکر شما با موفقیت در ECR ذخیره شده و آماده استقرار در AWS Lambda خواهد بود.

پیاده‌سازی ایمیج داکر در AWS Lambda

پس از اینکه ایمیج داکر شما در ECR قرار گرفت، می‌توانید یک تابع Lambda ایجاد کنید. برای این کار، به کنسول Lambda بروید و روی گزینه «Create a Function» کلیک کنید. در این مرحله، باید گزینه «Container Image» را انتخاب کرده و سپس ریپازیتوری ECR که قبلاً ایجاد کرده‌اید را جستجو و ایمیج مورد نظر خود را از آنجا انتخاب نمایید. می‌توانید سایر تنظیمات را به صورت پیش‌فرض رها کنید و روی دکمه «Create» کلیک نمایید تا تابع Lambda شما ایجاد شود.

پس از ایجاد تابع، می‌توانید به صفحه آن هدایت شوید و استقرار را تست کنید. برای تست، کافی است از تب «Lambda Test» موجود استفاده کنید. تمام جزئیات مورد نیاز، از جمله payload برای درخواست POST خود را وارد کرده و تست را اجرا نمایید. با انجام این مراحل، شما با موفقیت یک کانتینر داکر را در AWS، با بهره‌گیری از ECR و Lambda، پیاده‌سازی کرده‌اید. برای گام بعدی، می‌توانید با ادغام API Gateway، تابع خود را از طریق اینترنت نیز قابل دسترسی کنید.

جمع‌بندی و توصیه نهایی

استقرار کانتینرهای داکر بر روی AWS Lambda یک راهکار کارآمد برای اجرای سریع برنامه‌های شما بدون نگرانی در مورد مدیریت سرورها یا پلتفرم‌های زیربنایی است. این رویکرد سرورلس، به توسعه‌دهندگان امکان می‌دهد تا بر منطق تجاری و بهبود عملکرد محصول خود تمرکز کنند، در حالی که بار عملیاتی مدیریت زیرساخت‌ها بر عهده AWS خواهد بود. Lambda با مدل پرداخت مبتنی بر مصرف، به شما کمک می‌کند تا در هزینه‌ها صرفه‌جویی کنید؛ زیرا فقط برای مدت زمان اجرا و میزان حافظه مصرفی تابع هزینه می‌پردازید و نیازی به پرداخت برای منابع بیکار نخواهید داشت. در پایان، فراموش نکنید که سرویس‌هایی که در AWS ECR و Lambda ایجاد کرده‌اید را پس از اتمام کار حذف نمایید تا از متحمل شدن هزینه‌های اضافی جلوگیری شود. این پاکسازی، بخش مهمی از مدیریت منابع ابری مسئولانه است.