مقدمه
من مدتی است که می خواهم چالش رزومه ابر AWS را امتحان کنم و سرانجام ، این عکس من در آن است! این فقط یک پروژه آخر هفته دیگر نیست. این چیزی است که من با احتیاط (و چند فنجان قهوه) ساخته ام ، و سعی می کنم مانند یک مهندس فکر کنم.
هدف اصلی من از ابتدا ایجاد یک مجموعه استقرار پایدار بود که به AWS Free Forever Tier می چسبد ، زیرا بیایید صادق باشیم ، چیزهای رایگان بسیار جذاب است ، به خصوص وقتی که از AWS است! من می خواستم این مقرون به صرفه ، قابل اعتماد و چیزی باشد که می تواند برای همیشه اجرا شود (خوب ، حداقل تا زمانی که AWS قیمت خود را تغییر دهد).
اما چالش فقط مربوط به پایین نگه داشتن هزینه ها نیست. بنابراین من فکر کردم ، چرا نسخه گسترده ای را نیز نمی سازیم؟ یکی که خدمات AWS بیشتری را در بالای تنظیمات اساسی اضافه می کند. به این ترتیب ، من می توانم بیشتر بیاموزم و آن را برای به روزرسانی های آینده انعطاف پذیر کنم.
همچنین ، FUN FACT: من یک وب سایت نمونه کارها نداشتم. بنابراین من فهمیدم ، چرا اجازه نمی دهم این نسخه پایدار نیز نمونه کارها من باشد؟ دو پرنده ، یک شلیک.
معماری
مجموعه فوق برای شبیه سازی از نزدیک محیط تولید طراحی شده است. جلوی آن روی یک سطل S3 میزبانی شده و از طریق Cloudfront برای دسترسی کم تأخیر تحویل داده می شود. CloudFront با استفاده از AWS WAF ایمن است و HTTPS از طریق مدیر گواهی AWS (ACM) فعال می شود. در پس زمینه ، API Gateway به عنوان نقطه ورود درخواست ها عمل می کند ، که توسط توابع Lambda پردازش می شوند و در DynamoDB ذخیره می شوند. CloudWatch مصرف منابع را کنترل می کند و هنگام فراتر رفتن از آستانه ها ، از طریق SNS هشدارهایی می فرستد و از مدیریت فعال اطمینان می دهد. IAM مرزهای مجوز بین خدمات را اداره می کند. خوب ، این یک مجموعه درجه تولید است ، اما بیایید واقعی باشیم ، این مجموعه مانند هر چیزی پول می خورد.
اکنون این نسخه برای دانش آموزانی مثل من است که بدون نیاز به فروش کلیه می خواهند یک مجموعه ابر خوب داشته باشند. در اینجا ، من با استفاده از فقط خدمات AWS رایگان ، همه چیز را کاهش داده ام. جبهه در NetLify با پشتیبانی DNS مستقر شده است ، در حالی که در پس زمینه از Lambda و DynamoDB مانند گذشته استفاده می کند. CloudWatch و SNS هنوز برای هشدار استفاده می شوند و IAM مجوزهای خدمات را مدیریت می کند. با استفاده از Terraform ، زیرساخت ها را می توان به راحتی از تنظیمات گسترده به این نسخه حداقل با یک دستور واحد تغییر داد.
IAC: Terraform
کل زیرساخت ها با استفاده از Terraform با جدایی تمیز بین محیط ها و ماژول های قابل استفاده مجدد اداره می شوند. هر مدل استقرار (اساسی یا گسترده) در پوشه خود تعریف شده است environments/، جایی که به عنوان یک ماژول ریشه خدمت می کند. این ماژول های ریشه ای اجزای مشترک را از modules/ دایرکتوری ، عبور از متغیرهای خاص محیط. به عنوان مثال ، basic/ Setup بر استقرار حداقل منابع مانند عملکرد لامبدا و DynamoDB تمرکز دارد ، در حالی که extended/ Setup مؤلفه هایی مانند API Gateway ، S3 ، Cloudfront و WAF را اضافه می کند. هر دو محیط را حفظ می کنند پرونده های دولتی مستقل (terraform.tfstate) و پرونده های قفل برای اطمینان از استقرار مداوم و منزوی. این ساختار مدولار باعث می شود تغییر بین تنظیمات (فقط از بین بردن مادون قرمز قبلی ، تغییر دایرکتوری و اعمال) آسان شود ، در حالی که Terraform قوام حالت و تأمین قابل اعتماد را در سراسر تنظیمات تضمین می کند.
terraform/
├── environments/
│ ├── basic/ # Minimal setup environment
│ └── extended/ # Full setup environment
├── modules/
│ ├── base/ # Shared infra (Lambda, IAM, CloudWatch, etc.)
│ └── extended/ # Add-ons (S3, API Gateway, CloudFront, WAF)
من این مجموعه را انتخاب کردم زیرا جدایی روشنی بین محیط ها ارائه می دهد ، و مدیریت زیرساخت ها را آسان تر می کند ، استدلال می کند و تکرار می شود. با حفظ پوشه های مستقل و پرونده های دولتی برای هر محیط (basic/وت extended/) ، من می توانم با اطمینان و بدون خطر تغییرات ناخواسته در استقرار موجود ، ویژگی های جدید را توسعه داده و آزمایش کنم. این ساختار پیچیدگی را کاهش می دهد ، احتمال فساد دولت را کاهش می دهد، و به خوبی با شیوه های دنیای واقعی که محیط ها اغلب در ویژگی ها متفاوت هستند ، تراز می شود. این همچنین باعث ایجاد اشکال زدایی و گردش کار CI/CD می شود ، زیرا هر محیط می تواند به طور مستقل مستقر شود بدون اینکه به منطق مشروط یا ضامن دولت مشترک باشد. به طور کلی ، این رویکرد در اولویت ایمنی ، وضوح و حفظ پیچیدگی قرار دارد.
گردش کار CI/CD
راه اندازی پس زمینه
گردش کار استقرار پس زمینه برای هر دو مدل استقرار اساسی و گسترده ، همانطور که در نمودار نشان داده شده است ، یکسان است. هنگامی که تغییرات کد به مخزن GitHub منتقل می شود ، اقدامات GitHub باعث ایجاد خط لوله CI/CD می شود که از AWS CLI برای استقرار یا به روزرسانی توابع Lambda استفاده می کند. این توابع منطق پس زمینه را اداره می کنند ، و فرایند استقرار تضمین می کند که هرگونه به روزرسانی پس زمینه به طور خودکار در محیط صحیح AWS اعمال می شود. این تنظیم مداوم ، تعمیر و نگهداری را ساده می کند و تضمین می کند که هر دو مدل در همگام سازی باقی بمانند.
راه اندازی Frontend
برای مدل استقرار گسترده ، خط لوله اقدامات GitHub وظیفه بارگذاری پرونده های جلوی استاتیک را به یک سطل S3 بر عهده دارد. پس از بارگذاری ، پرونده ها به طور خودکار از طریق آمازون S3 ارائه می شوند و برای تحویل جهانی در CloudFront ادغام می شوند. با این حال ، در مدل استقرار اساسی ، کد Frontend بر روی یک خط لوله ساخت خود NetLify ، که روند ساخت و استقرار را انجام می دهد ، بر روی یک شاخه تعیین شده Trrigger Netlify تعهد می کند. سپس محتوا از طریق شبکه Edge NetLify سرو می شود و این روند را بدون پیکربندی زیرساخت های اضافی یکپارچه می کند.
پایان
این چالش چیزی بیش از سیم کشی سرویس های ابری بود ، بلکه در مورد ساختن چیزی معنی دار از زمین به بالا بود ، یاد گرفت که چگونه استقرار در دنیای واقعی کار می کند ، و محدودیت های من را در یک زمان یک برنامه Terraform فشار می آورد. از زیرساخت های مدولار گرفته تا CI/CD خودکار و معماری آگاه از بودجه ، سعی کردم کاربردی را با طراحی ابر خوب تعادل برقرار کنم.
“از آنجا که هستید شروع کنید. از آنچه دارید استفاده کنید. آنچه می توانید انجام دهید.” – آرتور آش
و این دقیقاً همان کاری است که من انجام دادم ، بدون ابزار گران قیمت ، خط لوله فانتزی ، فقط کنجکاوی ، قوام و ابر.
با تشکر از خواندن ، و اگر به فکر شروع سفر ابر خود هستید ، اکنون همیشه زمان خوبی است. 🚀
پیوندهای پروژه
اگر این وبلاگ را مفید یا آموخته اید یا چیز جدیدی یاد گرفته اید ، احساس راحتی کنید که مانند ❤ ❤ را ترک کنید و ستاره را ستاره کنید ، واقعاً کمک می کند و باعث می شود من انگیزه خود را برای به اشتراک گذاشتن مطالب جالب تر حفظ کنم!
