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

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

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

فهرست مطالب

مفاهیم مهم برای درک

رابط برنامه نویسی کاربردی (API)

روش های HTTP

دروازه API آمازون

آمازون DynamoDB

برنامه CRUD بدون سرور

چارچوب بدون سرور

اقدامات GitHub

پستچی

پیش نیازها

مورد استفاده ما

اهداف آموزش

نحوه شروع: مخزن Git را کلون کنید

مرحله 1: محیط چارچوب بدون سرور را تنظیم کنید

مرحله 2: API را در فایل YAML بدون سرور تعریف کنید

مرحله 3: توابع لامبدا را برای عملیات CRUD توسعه دهید

عملکرد لامبدا قهوه را ایجاد کنید

عملکرد لامبدا را دریافت کنید

عملکرد قهوه لامبدا را به روز کنید

عملکرد قهوه لامبدا را حذف کنید

مرحله 4: راه‌اندازی چند مرحله‌ای خط لوله CI/CD برای محیط‌های توسعه‌دهنده و تولیدکننده

مرحله 5: خطوط لوله Dev و Prod را آزمایش کنید

مرحله 6: API های Prod و Dev را با استفاده از Postman آزمایش و اعتبار سنجی کنید

نتیجه گیری

قبل از پرداختن به جزئیات فنی، به برخی از مفاهیم کلیدی پس زمینه خواهیم پرداخت.

مفاهیم مهم برای درک

رابط برنامه نویسی کاربردی (API)

رابط برنامه نویسی برنامه (Application Programming Interface) به نرم افزارهای مختلف اجازه می دهد تا با یکدیگر ارتباط برقرار کرده و با یکدیگر تعامل داشته باشند. روش ها و فرمت های داده ای را که برنامه ها می توانند برای درخواست و تبادل اطلاعات برای یکپارچه سازی و به اشتراک گذاری داده ها بین سیستم های مختلف استفاده کنند، تعریف می کند.

روش های HTTP

روش‌های HTTP یا روش‌های درخواست جزء حیاتی سرویس‌های وب و APIها هستند. آنها عمل مورد نظر را که باید روی یک منبع در یک URL درخواست داده شده انجام شود را نشان می دهند.

متداول ترین روش های مورد استفاده در API های RESTful عبارتند از:

GET : برای بازیابی داده ها از یک سرور استفاده می شود

POST : داده های موجود در متن درخواست را برای ایجاد یا به روز رسانی یک منبع ارسال می کند

PUT : یک منبع موجود را به روز می کند یا جایگزین می کند یا در صورت عدم وجود منبع جدیدی ایجاد می کند

DELETE : داده های مشخص شده را از سرور حذف می کند.

دروازه API آمازون

Amazon API Gateway یک سرویس کاملاً مدیریت شده است که ایجاد، انتشار، نگهداری، نظارت و ایمن کردن APIها را در مقیاس برای توسعه دهندگان آسان می کند. این به عنوان یک نقطه ورودی برای چندین API عمل می کند و تعاملات بین کلاینت ها (مانند برنامه های کاربردی وب یا تلفن همراه) و خدمات باطن را مدیریت و کنترل می کند.

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

آمازون DynamoDB

DynamoDB یک سرویس پایگاه داده NoSQL کاملاً مدیریت شده است که برای مقیاس پذیری بالا، تأخیر کم و تکرار داده ها در چندین منطقه طراحی شده است.

DynamoDB داده ها را در قالبی بدون طرح واره ذخیره می کند و امکان ذخیره سازی انعطاف پذیر و سریع و بازیابی داده های ساختار یافته و نیمه ساختار یافته را فراهم می کند. معمولاً برای ساخت برنامه های مقیاس پذیر و پاسخگو در محیط های مبتنی بر ابر استفاده می شود.

برنامه CRUD بدون سرور

برنامه CRUD بدون سرور به توانایی ایجاد، خواندن، به روز رسانی و حذف داده ها اشاره دارد. اما معماری و اجزای درگیر با برنامه های کاربردی مبتنی بر سرور سنتی متفاوت است.

Create شامل گفت ن ورودی های جدید به جدول DynamoDB است. عملیات Read داده ها را از جدول DynamoDB بازیابی می کند. به روز رسانی داده های موجود در DynamoDB. و عملیات Delete داده ها را از DynamoDB حذف می کند.

چارچوب بدون سرور

چارچوب بدون سرور یک ابزار منبع باز است که استقرار و مدیریت برنامه های بدون سرور را در چندین ارائه دهنده ابر از جمله AWS ساده می کند. این پیچیدگی تهیه و مدیریت زیرساخت را با اجازه دادن به توسعه دهندگان برای تعریف زیرساخت خود به عنوان کد با استفاده از یک فایل YAML از بین می برد.

این فریم ورک استقرار، مقیاس‌بندی و به‌روزرسانی توابع بدون سرور، APIها و سایر منابع را مدیریت می‌کند.

اقدامات GitHub

GitHub Actions یک ابزار قدرتمند خودکارسازی CI/CD است که به توسعه دهندگان اجازه می دهد تا گردش کار نرم افزار خود را مستقیماً از مخزن GitHub خود خودکار کنند.

با GitHub Actions، می‌توانید خطوط لوله سفارشی ایجاد کنید که توسط رویدادهایی مانند فشار کد، درخواست‌های کششی یا ادغام شاخه‌ها ایجاد می‌شوند. این گردش‌ها در فایل‌های YAML درون مخزن تعریف شده‌اند و می‌توانند وظایفی مانند آزمایش، ساختن و استقرار برنامه‌ها در محیط‌های مختلف را انجام دهند.

پستچی

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

بسیار خوب، اکنون که با ابزارها و فناوری‌هایی که در اینجا استفاده خواهیم کرد آشنا شدید، بیایید وارد آن شویم.

پیش نیازها

Node.js و npm نصب شده است

AWS CLI با دسترسی به حساب AWS شما پیکربندی شده است

یک حساب فریم ورک بدون سرور

چارچوب بدون سرور به صورت جهانی در CLI محلی شما نصب شده است

مورد استفاده ما

با Alyx، کارآفرینی آشنا شوید که اخیراً در مورد معماری بدون سرور یاد گرفته است. او در مورد اینکه چگونه این یک راه قدرتمند و کارآمد برای ایجاد backend برای برنامه های کاربردی وب است، که رویکرد مدرن تری را برای توسعه برنامه های کاربردی وب ارائه می دهد، خوانده است.

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

بیایید تحلیل کنیم که چگونه Alyx، صاحب یک کافی شاپ پر رونق، شروع به استفاده از معماری بدون سرور برای باطن برنامه وب خود می کند.

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

مدیریت سرورها و حصول اطمینان از اینکه برنامه می تواند از پس افزایش ترافیک برآید، برای Alyx به یک چالش تبدیل شد. او متوجه شد که دائماً نگران ظرفیت سرور، مقیاس پذیری و هزینه نگهداری زیرساخت است.

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

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

Alyx که از این ایده هیجان زده شده بود، تصمیم گرفت با استفاده از AWS Lambda، AWS API Gateway و Amazon DynamoDB، باطن کافی شاپ خود را به یک پلتفرم بدون سرور منتقل کند. این تنظیم به او اجازه می‌دهد تا بیشتر روی ایجاد ترکیب‌ها و خوراکی‌های عالی قهوه برای مشتریانش تمرکز کند.

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

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

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

علاوه بر این، او GitHub Actions را برای یکپارچگی و تحویل مداوم (CI/CD) راه‌اندازی می‌کند، به طوری که هر تغییری که انجام می‌دهد به طور خودکار از طریق یک خط لوله مستقر می‌شود، خواه یک ویژگی جدید در حال توسعه باشد یا یک اصلاح داغ برای تولید.

اهداف آموزش

محیط Serverless Framework را تنظیم کنید

در فایل YAML یک API تعریف کنید

توابع AWS Lambda را برای پردازش عملیات CRUD توسعه دهید

استقرارهای چند مرحله ای را برای Dev و Prod تنظیم کنید

خطوط لوله Dev و Prod را آزمایش کنید

APIهای Dev و Prod را با استفاده از Postman آزمایش و تأیید کنید

نحوه شروع: مخزن Git را کلون کنید

برای اینکه درک خود را افزایش دهید و بتوانید این آموزش را به طور موثرتری دنبال کنید، به پیش بروید و مخزن پروژه را از GitHub من شبیه سازی کنید. با رفتن به اینجا می توانید این کار را انجام دهید. همانطور که به جلو می رویم، با خیال راحت فایل ها را در صورت لزوم ویرایش کنید.

پس از کلون سازی مخزن، همانطور که در تصویر زیر مشاهده می کنید، متوجه وجود چندین فایل در پوشه خود خواهید شد. ما از همه این فایل ها برای ساخت API کافی شاپ بدون سرور خود استفاده خواهیم کرد.

این پروژه." class="image--center mx-auto" width="600" height="400" loading="lazy">

مرحله 1: محیط چارچوب بدون سرور را تنظیم کنید

برای راه‌اندازی محیط چارچوب بدون سرور برای استقرار خودکار، باید حساب چارچوب بدون سرور خود را از طریق CLI تأیید اعتبار کنید.

این امر مستلزم ایجاد یک کلید دسترسی است که خط لوله CI/CD را قادر می سازد و از چارچوب بدون سرور برای احراز هویت ایمن در حساب شما بدون افشای اعتبار شما استفاده می کند. با ورود به حساب سرور بدون سرور و ایجاد یک کلید دسترسی، خط لوله می تواند برنامه بدون سرور شما را به طور خودکار از فایل پیکربندی ساخت، مستقر کند.

برای انجام این کار، به حساب کاربری بدون سرور خود بروید و به بخش کلیدهای دسترسی بروید . روی «+add» کلیک کنید، نام آن را SERVERLESS_ACCESS_KEY بگذارید و سپس کلید را ایجاد کنید.

هنگامی که کلید دسترسی خود را ایجاد کردید، مطمئن شوید که آن را به صورت ایمن کپی و ذخیره کنید. شما از این کلید به عنوان یک متغیر مخفی در مخزن GitHub خود برای احراز هویت و مجوز خط لوله CI/CD خود استفاده خواهید کرد.

در طول فرآیند استقرار، دسترسی به حساب Framework بدون سرور شما را فراهم می کند. بعداً این کلید را به اسرار مخزن GitHub خود اضافه خواهید کرد، پس خط لوله شما می تواند به طور ایمن از آن برای استقرار منابع بدون سرور بدون افشای اطلاعات حساس در پایگاه کد شما استفاده کند.

حالا بیایید منابع AWS را به عنوان کد در فایل severless.yaml تعریف کنیم.

مرحله 2: API را در فایل YAML بدون سرور تعریف کنید

در این فایل، زیرساخت اصلی و عملکرد API کافی شاپ را با استفاده از پیکربندی YAML بدون سرور تعریف می‌کنید.

این فایل سرویس های AWS مورد استفاده را تعریف می کند، از جمله API Gateway، توابع Lambda برای عملیات CRUD، و DynamoDB برای ذخیره سازی داده ها.

شما همچنین یک نقش IAM را پیکربندی خواهید کرد تا توابع Lambda مجوزهای لازم برای تعامل با سرویس DynamoDB را داشته باشند.

دروازه API با روش‌های HTTP مناسب ( POST ، GET ، PUT و DELETE ) برای رسیدگی به درخواست‌های دریافتی و راه‌اندازی عملکردهای Lambda مربوطه تنظیم شده است.

بیایید کد را تحلیل کنیم:

 service: coffee-shop-api frameworkVersion: '4' provider: name: aws runtime: nodejs20.x region: us-east-1 stage: ${opt:stage} iam: role: statements: - Effect: Allow Action: - dynamodb:PutItem - dynamodb:GetItem - dynamodb:Scan - dynamodb:UpdateItem - dynamodb:DeleteItem Resource: arn:aws:dynamodb:${self:provider.region}:*:table/CoffeeOrders-${self:provider.stage} functions: createCoffee: handler: createCoffee.handler environment: COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage} events: - http: path: coffee method: post getCoffee: handler: getCoffee.handler environment: COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage} events: - http: path: coffee method: get updateCoffee: handler: updateCoffee.handler environment: COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage} events: - http: path: coffee method: put deleteCoffee: handler: deleteCoffee.handler environment: COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage} events: - http: path: coffee method: delete resources: Resources: CoffeeTable: Type: AWS::DynamoDB::Table Properties: TableName: CoffeeOrders-${self:provider.stage} AttributeDefinitions: - AttributeName: OrderId AttributeType: S - AttributeName: CustomerName AttributeType: S KeySchema: - AttributeName: OrderId KeyType: HASH - AttributeName: CustomerName KeyType: RANGE BillingMode: PAY_PER_REQUEST

پیکربندی serverless.yml نحوه اجرای API کافی شاپ Alyx را در یک محیط بدون سرور در AWS تعریف می‌کند. بخش ارائه دهنده مشخص می کند که برنامه از AWS به عنوان ارائه دهنده ابر و Node.js به عنوان محیط زمان اجرا استفاده می کند.

منطقه روی us-east-1 تنظیم شده است و متغیر مرحله امکان استقرار پویا در محیط‌های مختلف مانند dev و prod را می‌دهد. این به این معنی است که یک کد می تواند در محیط های مختلف مستقر شود، با نامگذاری منابع برای جلوگیری از درگیری.

در بخش iam ، مجوزهایی به توابع Lambda داده می شود تا با جدول DynamoDB تعامل داشته باشند. دستور ${self:provider.stage} به صورت پویا جدول DynamoDB را نامگذاری می کند، به طوری که هر محیط منابع جداگانه خود را دارد، مانند CoffeeOrders-dev برای محیط توسعه و CoffeeOrders-prod برای تولید. این نامگذاری پویا به مدیریت چندین محیط بدون پیکربندی دستی جداول جداگانه برای هر یک کمک می کند.

بخش توابع چهار تابع هسته لامبدا را تعریف می‌کند، createCoffee ، getCoffee ، updateCoffee و deleteCoffee . اینها عملیات CRUD را برای API کافی شاپ انجام می دهند.

هر تابع به یک روش HTTP خاص در دروازه API مانند POST ، GET ، PUT و DELETE متصل است. این توابع با جدول DynamoDB که به صورت پویا بر اساس مرحله فعلی نامگذاری شده است، تعامل دارند.

آخرین بخش منابع ، خود جدول DynamoDB را تعریف می کند. جدول را با ویژگی های OrderId و CustomerName تنظیم می کند که به عنوان کلید اصلی استفاده می شود. جدول به گونه ای پیکربندی شده است که از حالت صورتحساب پرداخت به ازای درخواست استفاده کند، که آن را برای کسب و کار رو به رشد Alyx مقرون به صرفه می کند.

با خودکار کردن استقرار این منابع با استفاده از چارچوب بدون سرور، Alyx می تواند به راحتی زیرساخت خود را مدیریت کند و او را از بار تهیه دستی و مقیاس بندی منابع رها کند.

مرحله 3: توابع لامبدا را برای عملیات CRUD توسعه دهید

در این مرحله، با ایجاد توابع Lambda با جاوا اسکریپت که عملیات ضروری CRUD را ایجاد می‌کند ، getCoffee ، updateCoffee و deleteCoffee را انجام می‌دهد، منطق اصلی API کافی شاپ Alyx را پیاده‌سازی می‌کنیم.

این توابع از AWS SDK برای تعامل با سرویس های AWS، به ویژه DynamoDB استفاده می کنند. هر تابع مسئول رسیدگی به درخواست‌های API خاص مانند ایجاد سفارش، بازیابی سفارشات، به‌روزرسانی وضعیت سفارش و حذف سفارش‌ها خواهد بود.

عملکرد لامبدا قهوه را ایجاد کنید

این تابع یک سفارش ایجاد می کند:

 const AWS = require('aws-sdk'); const dynamoDb = new AWS.DynamoDB.DocumentClient(); const { v4: uuidv4 } = require('uuid'); module.exports.handler = async (event) => { const requestBody = JSON.parse(event.body); const customerName = requestBody.customer_name; const coffeeBlend = requestBody.coffee_blend; const orderId = uuidv4(); const params = { TableName: process.env.COFFEE_ORDERS_TABLE , Item: { OrderId: orderId , CustomerName: customerName , CoffeeBlend: coffeeBlend , OrderStatus: 'Pending' } } ; try { await dynamoDb.put(params).promise(); return { statusCode: 200 , body: JSON.stringify( { message: 'Order created successfully!' , OrderId: orderId } ) } ; } catch (error) { return { statusCode: 500 , body: JSON.stringify( { error: `Could not create order: $ { error.message } ` } ) } ; } } ;

این تابع Lambda ایجاد یک سفارش قهوه جدید را در جدول DynamoDB انجام می دهد. ابتدا AWS SDK را وارد می کنیم و یک DynamoDB.DocumentClient را برای تعامل با DynamoDB مقداردهی اولیه می کنیم. کتابخانه uuid نیز برای تولید شناسه های سفارش منحصر به فرد وارد می شود.

در داخل تابع کنترل کننده ، بدنه درخواست ورودی را برای استخراج اطلاعات مشتری، مانند نام مشتری و ترکیب قهوه ترجیحی، تجزیه می کنیم. یک orderId منحصر به فرد با استفاده از uuidv4() تولید می شود و این داده برای درج در DynamoDB آماده می شود.

شئ params جدولی را که داده‌ها در آن ذخیره می‌شوند، با TableName به صورت پویا روی مقدار متغیر محیطی COFFEE_ORDERS_TABLE تعیین می‌کند. سفارش جدید شامل فیلدهایی مانند OrderId ، CustomerName ، CoffeeBlend و وضعیت اولیه در انتظار است .

در بلوک try ، کد تلاش می کند تا با استفاده از متد put() ترتیب را به جدول DynamoDB اضافه کند. در صورت موفقیت آمیز بودن، این تابع کد وضعیت 200 را با پیام موفقیت آمیز و OrderId برمی گرداند. اگر خطایی وجود داشته باشد، کد آن را می گیرد و کد وضعیت 500 را همراه با یک پیام خطا برمی گرداند.

عملکرد لامبدا را دریافت کنید

این تابع تمام موارد قهوه را بازیابی می کند:

 const AWS = require ( 'aws-sdk' ); const dynamoDb = new AWS.DynamoDB.DocumentClient(); module .exports.handler = async () => { const params = { TableName : process.env.COFFEE_ORDERS_TABLE }; try { const result = await dynamoDb.scan(params).promise(); return { statusCode : 200 , body : JSON .stringify(result.Items) }; } catch (error) { return { statusCode : 500 , body : JSON .stringify({ error : `Could not retrieve orders: ${error.message} ` }) }; } };

این تابع Lambda مسئول بازیابی تمام سفارشات قهوه از جدول DynamoDB است و نمونه ای از رویکرد بدون سرور برای بازیابی داده ها از DynamoDB به روشی مقیاس پذیر است.

ما دوباره از AWS SDK برای مقداردهی اولیه یک نمونه DynamoDB.DocumentClient برای تعامل با DynamoDB استفاده می کنیم. تابع handler شی params را می سازد و TableName را مشخص می کند که به صورت پویا با استفاده از متغیر محیطی COFFEE_ORDERS_TABLE تنظیم می شود.

متد scan() تمام موارد را از جدول بازیابی می کند. مجدداً، اگر عملیات موفقیت آمیز باشد، تابع کد وضعیت 200 را به همراه موارد بازیابی شده در قالب JSON برمی گرداند. در صورت بروز خطا کد وضعیت 500 و پیغام خطا برگردانده می شود.

عملکرد قهوه لامبدا را به روز کنید

این تابع یک مورد قهوه را با شناسه خود به روز می کند:

 const AWS = require ( 'aws-sdk' ); const dynamoDb = new AWS.DynamoDB.DocumentClient(); module .exports.handler = async (event) => { const requestBody = JSON .parse(event.body); const { order_id, new_status, customer_name } = requestBody; const params = { TableName : process.env.COFFEE_ORDERS_TABLE, Key : { OrderId : order_id, CustomerName : customer_name }, UpdateExpression : 'SET OrderStatus = :status' , ExpressionAttributeValues : { ':status' : new_status } }; try { await dynamoDb.update(params).promise(); return { statusCode : 200 , body : JSON .stringify({ message : 'Order status updated successfully!' , OrderId : order_id }) }; } catch (error) { return { statusCode : 500 , body : JSON .stringify({ error : `Could not update order: ${error.message} ` }) }; } };

این تابع Lambda به روز رسانی وضعیت یک سفارش قهوه خاص را در جدول DynamoDB انجام می دهد.

تابع handler دستور_id ، new_status و customer_name را از بدنه درخواست استخراج می کند. سپس شیء params را می سازد تا نام جدول و کلید اصلی سفارش را مشخص کند (با استفاده از OrderId و CustomerName ). UpdateExpression وضعیت جدید سفارش را تنظیم می کند.

در بلوک try ، کد تلاش می کند تا با استفاده از متد update() ترتیب را در DynamoDB به روز کند. یک بار دیگر، البته در صورت موفقیت آمیز بودن، این تابع یک کد وضعیت 200 را با یک پیام موفقیت آمیز برمی گرداند. اگر خطایی رخ دهد، خطا را دریافت می کند و کد وضعیت 500 را به همراه یک پیام خطا برمی گرداند.

عملکرد قهوه لامبدا را حذف کنید

این تابع یک مورد قهوه را با شناسه خود حذف می کند:

 const AWS = require ( 'aws-sdk' ); const dynamoDb = new AWS.DynamoDB.DocumentClient(); module .exports.handler = async (event) => { const requestBody = JSON .parse(event.body); const { order_id, customer_name } = requestBody; const params = { TableName : process.env.COFFEE_ORDERS_TABLE, Key : { OrderId : order_id, CustomerName : customer_name } }; try { await dynamoDb.delete(params).promise(); return { statusCode : 200 , body : JSON .stringify({ message : 'Order deleted successfully!' , OrderId : order_id }) }; } catch (error) { return { statusCode : 500 , body : JSON .stringify({ error : `Could not delete order: ${error.message} ` }) }; } };

تابع Lambda یک سفارش قهوه خاص را از جدول DynamoDB حذف می کند. در تابع handler، کد بدنه درخواست را برای استخراج order_id و customer_name تجزیه می‌کند. این مقادیر به عنوان کلید اصلی برای شناسایی موردی که باید از جدول حذف شود استفاده می شود. شی params نام جدول و کلید موردی را که باید حذف شود مشخص می کند.

در بلوک try ، کد تلاش می کند تا با استفاده از روش delete() دستور را از DynamoDB حذف کند. در صورت موفقیت، دوباره یک کد وضعیت 200 را با یک پیام موفقیت آمیز برمی گرداند که نشان می دهد سفارش حذف شده است. اگر خطایی رخ دهد، کد آن را می گیرد و کد وضعیت 500 را به همراه یک پیام خطا برمی گرداند.

اکنون که هر تابع لامبدا را توضیح دادیم، بیایید یک خط لوله CI/CD چند مرحله ای راه اندازی کنیم.

مرحله 4: راه‌اندازی چند مرحله‌ای خط لوله CI/CD برای محیط‌های توسعه‌دهنده و تولیدکننده

برای تنظیم مخازن AWS در مخزن GitHub خود، ابتدا به تنظیمات مخزن بروید. تنظیمات را در بالا سمت راست انتخاب کنید، سپس به پایین سمت چپ بروید و Secrets and variables را انتخاب کنید.

را در مخزن GitHub در بالا سمت راست انتخاب کنید." class="image--center mx-auto" width="600" height="400" loading="lazy">

در مرحله بعد، همانطور که در تصویر زیر مشاهده می کنید، روی Actions کلیک کنید:

را انتخاب کنید." class="image--center mx-auto" width="600" height="400" loading="lazy">

از آنجا، New repository Secret را برای ایجاد Secrets انتخاب کنید.

برای ایجاد خط لوله خود به سه راز نیاز است، AWS_ACCESS_KEY_ID ، AWS_SECRET_ACCESS_KEY و SERVERLESS_ACCESS_KEY .

برای ایجاد SERVERLESS_ACCESS_KEY از اعتبارنامه کلید دسترسی به حساب AWS خود برای دو متغیر اول و سپس کلید دسترسی بدون سرور که قبلاً ذخیره شده است استفاده کنید. این اسرار به طور ایمن خط لوله CI/CD شما را همانطور که در تصویر زیر مشاهده می کنید تأیید می کند.

به AWS و حساب فریم ورک سرور بدون نیاز است. " class="image--center mx-auto" width="600" height="400" loading="lazy">

مطمئن شوید که شعبه اصلی شما " main " نامگذاری شده است، زیرا این شاخه به عنوان شعبه تولید عمل می کند. بعد، یک شعبه جدید به نام " dev " برای کارهای توسعه ایجاد کنید.

همچنین می‌توانید شاخه‌های ویژه‌ای مانند « dev/feature » را برای توسعه ریزتر ایجاد کنید. GitHub Actions از این شاخه‌ها برای پیاده‌سازی تغییرات به‌طور خودکار استفاده می‌کند که توسعه‌دهنده محیط توسعه را نشان می‌دهد و تولید را نمایندگی می‌کند.

این استراتژی انشعاب به شما امکان می دهد خط لوله CI/CD را به طور موثر مدیریت کنید و هر زمان که ادغام در محیط های توسعه دهنده یا prod وجود دارد، تغییرات کد جدید را اعمال کنید.

نحوه استفاده از GitHub Actions برای استقرار فایل YAML

برای خودکار کردن فرآیند استقرار برای کافی شاپ API، از GitHub Actions استفاده خواهید کرد که با مخزن GitHub شما یکپارچه می شود.

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

حالا بیایید کد را تحلیل کنیم:

 name: deploy-coffee-shop-api on: push: branches: - main - dev jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Setup Node.js uses: actions/setup-node@v3 with: node-version: '20.x' - name: Install dependencies run: | cd coffee-shop-api npm install - name: Install Serverless Framework run: npm install -g serverless - name: Deploy to AWS (Dev) if: github.ref == 'refs/heads/dev' run: | cd coffee-shop-api npx serverless deploy --stage dev env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} SERVERLESS_ACCESS_KEY: ${{secrets.SERVERLESS_ACCESS_KEY}} - name: Deploy to AWS (Prod) if: github.ref == 'refs/heads/main' run: | cd coffee-shop-api npx serverless deploy --stage prod env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} SERVERLESS_ACCESS_KEY: ${{secrets.SERVERLESS_ACCESS_KEY}}

پیکربندی GitHub Actions YAML چیزی است که فرآیند استقرار API کافی شاپ به AWS را با استفاده از چارچوب بدون سرور خودکار می کند. هر زمان که تغییرات به شاخه‌های اصلی یا توسعه‌دهنده منتقل شوند، گردش کار فعال می‌شود.

با تحلیل کد مخزن شروع می شود، سپس Node.js را با نسخه 20.x تنظیم می کند تا با زمان اجرا استفاده شده توسط توابع Lambda مطابقت داشته باشد. پس از آن، با پیمایش به دایرکتوری کافی شاپ-api و اجرای npm install ، وابستگی های پروژه را نصب می کند.

گردش کار همچنین چارچوب بدون سرور را به صورت سراسری نصب می کند و به CLI بدون سرور اجازه می دهد تا برای استقرار استفاده شود. بسته به اینکه کدام شاخه به روز می شود، گردش کار به صورت مشروط در محیط مناسب مستقر می شود.

اگر تغییرات به شاخه dev فشار داده شود، به مرحله dev مستقر می شود. اگر آنها را به شاخه اصلی هل دهند، به مرحله prod مستقر می شود. دستورات استقرار، npx serverless deploy --stage dev یا npx serverless deploy --stage prod در دایرکتوری coffee-shop-api اجرا می شوند.

برای استقرار ایمن، گردش کار به اعتبارنامه AWS و کلید دسترسی بدون سرور از طریق متغیرهای محیطی ذخیره شده در GitHub Secrets دسترسی دارد. این به خط لوله CI/CD اجازه می دهد تا با AWS و چارچوب بدون سرور بدون افشای اطلاعات حساس در مخزن احراز هویت شود.

اکنون، می توانیم به آزمایش خط لوله ادامه دهیم.

مرحله 5: خطوط لوله Dev و Prod را آزمایش کنید

ابتدا، باید تحلیل کنید که شاخه اصلی (prod) " main " نامیده می شود. سپس یک شاخه توسعه دهنده به نام dev ایجاد کنید. هنگامی که تغییرات معتبری در شاخه توسعه دادید، آنها را متعهد کنید که خط لوله اقدامات GitHub را راه اندازی کنند. این به طور خودکار منابع به روز شده را در محیط توسعه مستقر می کند. پس از تأیید همه چیز در dev، سپس می توانید شاخه dev را در شاخه اصلی ادغام کنید.

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

می‌توانید فرآیند استقرار را زیر نظر داشته باشید و گزارش‌های دقیق هر GitHub Actions اجرا شده را با رفتن به برگه Actions در مخزن GitHub خود تحلیل کنید.

را در سمت راست بالای گزینه های مخزن GitHub انتخاب کنید." class="image--center mx-auto" width="600" height="400" loading="lazy">

گزارش‌ها دید را در هر مرحله از خط لوله فراهم می‌کنند و به شما کمک می‌کنند تا تحلیل کنید که همه چیز طبق انتظار کار می‌کند.

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

همانطور که در تصویر زیر نشان داده شده است، به اجرای ساخت خاص در GitHub Actions بروید. در آنجا، می توانید جزئیات اجرا و نتایج را برای خطوط لوله توسعه یا تولید مشاهده کنید.

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

مرحله 6: API های Prod و Dev را با استفاده از Postman آزمایش و اعتبار سنجی کنید

اکنون که APIها و منابع مستقر و پیکربندی شده‌اند، برای شروع درخواست‌ها برای آزمایش عملکرد، باید نقاط پایانی API (URL) منحصربه‌فرد تولید شده توسط AWS را پیدا کنیم.

این URL ها می توانند عملکرد API را با چسباندن آنها در یک مرورگر وب آزمایش کنند. URL های API در نتایج خروجی ساخت CI/CD شما یافت می شوند.

برای بازیابی آن‌ها، به گزارش ‌های GitHub Actions بروید، آخرین ساخت موفق محیط را انتخاب کنید و روی deploy کلیک کنید تا جزئیات استقرار برای نقاط پایانی API ایجاد شده را تحلیل کنید.

که به شما امکان می دهد جزئیات گزارش را مشاهده کنید." class="image--center mx-auto" width="600" height="400" loading="lazy">

روی مرحله Deploy to AWS برای محیط انتخاب شده (Prod یا Dev) در گزارش‌های GitHub Actions خود کلیک کنید. پس از آن، URL API ایجاد شده را خواهید یافت.

تحلیل خطاها یا موفقیت اجرا می شوند." class="image--center mx-auto" width="600" height="400" loading="lazy">

این URL را کپی و ذخیره کنید، زیرا هنگام آزمایش عملکرد API شما به آن نیاز است. این URL دروازه شما برای تأیید اینکه آیا API مستقر شده مطابق انتظار کار می کند.

اکنون یکی از URL های API تولید شده را کپی کرده و در مرورگر خود پیست کنید. یک آرایه یا فهرست خالی در پاسخ نمایش داده می شود. این در واقع تأیید می کند که API به درستی کار می کند و شما با موفقیت داده ها را از جدول DynamoDB بازیابی می کنید.

حتی اگر فهرست خالی است، نشان می دهد که API می تواند به پایگاه داده متصل شود و اطلاعات را برگرداند.

است. " class="image--center mx-auto" width="600" height="400" loading="lazy">

برای تأیید اینکه API شما در هر دو محیط کار می کند، مراحل را برای محیط API دیگر (Prod و Dev) تکرار کنید.

برای آزمایش جامع‌تر، از Postman برای آزمایش همه روش‌های API، ایجاد ، خواندن ، به‌روزرسانی و حذف و انجام این آزمایش‌ها برای محیط‌های توسعه و تولید استفاده می‌کنیم.

برای آزمایش روش GET ، از Postman برای ارسال درخواست GET به نقطه پایانی API با استفاده از URL استفاده کنید. شما همان پاسخ را دریافت خواهید کرد، یک فهرست خالی از سفارشات قهوه همانطور که در پایین تصویر زیر مشاهده می شود. همانطور که در تصویر زیر نشان داده شده است، این توانایی API برای بازیابی با موفقیت داده ها را تایید می کند.

از Postman." class="image--center mx-auto" width="600" height="400" loading="lazy">

برای ایجاد یک سفارش، بیایید روش POST را آزمایش کنیم. مجدداً از Postman برای ایجاد یک درخواست POST به نقطه پایانی API استفاده کنید و نام مشتری و ترکیب قهوه را در بدنه درخواست ارائه کنید، همانطور که در زیر نشان داده شده است:

 { "customer_name" : "REXTECH" , "coffee_blend" : "Black" }

پاسخ یک پیام موفقیت آمیز با یک OrderId منحصر به فرد سفارش ثبت شده خواهد بود.

از Postman." class="image--center mx-auto" width="600" height="400" loading="lazy">

با تحلیل موارد موجود در جدول خاص محیط، تأیید کنید که سفارش جدید در جدول DynamoDB ذخیره شده است:

برای آزمایش روش PUT ، با ارائه شناسه سفارش قبلی و وضعیت سفارش جدید در بدنه درخواست، مطابق شکل زیر، یک درخواست PUT به نقطه پایانی API ارائه دهید:

 { "order_id" : "42a81c27-1421-4025-9bef-72b14e723c34" , "new_status" : "Ready" , "customer_name" : "REXTECH" }

پاسخ یک پیام به‌روزرسانی موفقیت‌آمیز سفارش با OrderId سفارش ثبت‌شده خواهد بود.

از Postman." class="image--center mx-auto" width="600" height="400" loading="lazy">

همچنین می توانید تأیید کنید که وضعیت سفارش از آیتم جدول DynamoDB به روز شده است.

به روز رسانی وضعیت سفارش در جدول DynamoDB." class="image--center mx-auto" width="600" height="400" loading="lazy">

برای آزمایش روش DELETE ، با استفاده از Postman، درخواست DELETE را با ارائه شناسه سفارش قبلی و نام مشتری در بدنه درخواست مطابق شکل زیر انجام دهید:

 { "order_id": "42a81c27-1421-4025-9bef-72b14e723c34", "customer_name": "REXTECH" }

پاسخ یک پیام موفقیت آمیز حذف شده با شناسه سفارش سفارش داده شده خواهد بود.

از Postman." class="image--center mx-auto" width="600" height="400" loading="lazy">

مجدداً می توانید تأیید کنید که سفارش در جدول DynamoDB حذف شده است.

نتیجه گیری

همین - تبریک می گویم! شما تمام مراحل را با موفقیت انجام دادید. ما یک REST API بدون سرور ساخته‌ایم که از عملکرد CRUD ( ایجاد، خواندن، به‌روزرسانی، حذف) با API Gateway، Lambda، DynamoDB، Serverless Framework و Node.js پشتیبانی می‌کند، و به‌طور خودکار استقرار تغییرات کد تایید شده با Github Actions را انجام می‌دهد.

اگر تا اینجا پیش رفته اید، ممنون که خواندید! امیدوارم براتون ارزشمند بوده باشه

Ifeanyi Otuonye یک مهندس ابر خبره 6X AWS است که در DevOps، نگارش فنی و تخصص آموزشی به عنوان یک مربی فنی مهارت دارد. او از اشتیاق خود برای یادگیری و پیشرفت انگیزه دارد و در محیط های مشارکتی پیشرفت می کند. او قبل از انتقال به ابر ، شش سال را به عنوان یک ورزشکار حرفه ای و میدانی می گذراند.

در اوایل سال 2022 ، او از نظر استراتژیک از طریق خود مطالعه و پیوستن به یک برنامه ابری شتاب 6 ماهه ، به یک مأموریت برای مهندس Cloud/DevOps رسید.

در ماه مه سال 2023 ، او این هدف را به دست آورد و اولین نقش مهندسی ابر خود را به دست آورد و اکنون مأموریت شخصی دیگری را برای توانمندسازی افراد دیگر در سفر به ابر تعیین کرده است.

خبرکاو