معماری خود ویرانگر خود را در AWS بسازید

چقدر شگفت‌انگیز است که برنامه‌ای را تهیه کنیم که هر وقت دیگر از آن استفاده نمی‌شود، خود به خود از بین می‌رود؟! 🤯

اگر ترجیح می دهید این مقاله را به زبان اسپانیایی بخوانید، اینجا را کلیک کنید!

در این پست، موارد استفاده، نمودار معماری و هر سرویس مورد نیاز برای زیرساخت های خود تخریب شونده در AWS را مرور خواهم کرد. بخش سرگرم کننده این است که می توانید هر منبع اضافی را که نیاز دارید به معماری اضافه کنید!

انگیزه

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

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

در چه سناریوهایی به این نیاز دارم؟

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

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

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

چگونه کار می کند؟

این معماری با AWS CloudFormation، ابزاری برای ارائه بارهای کاری با استفاده از زیرساخت به عنوان کد، ارائه شده است. نکته مهم در مورد این، این است که با داشتن تمام منابع و وابستگی ها بر روی a قالب و در الف مستقر شد پشته، حذف همه آنها به عنوان یک واحد بسیار آسان می شود.

نمودار معماری

بیایید روی اجزای اصلی معماری: نمونه EC2، زنگ ساعت CloudWatch، قانون EventBridge، عملکرد Lambda و نقش مربوطه IAM، سیاست IAM و مجوز Lambda. منابع بی اهمیت دیگری مانند گروه امنیتی، نقش نمونه و نمایه نمونه مورد نیاز هستند. اینها قرار نیست در اینجا پوشش داده شوند.

پشته CloudFormation معماری زیر را ایجاد می کند:

در اینجا معماری در حال حرکت است:

اکنون، اجازه دهید به عمق هر یک از عناصر معماری شیرجه بزنیم! 🤓

نمونه وب سرور

اول از همه، ما به یک اپلیکیشن نیاز داریم. این در یک نمونه EC2 ارائه خواهد شد. شما می توانید این را همانطور که می خواهید پیکربندی کنید. در مورد من، من برنامه را با استفاده از تنظیمات پیکربندی می کنم UserData بخش.

این تعریف منبع است:

"WebServerInstance": {
      "Type" : "AWS::EC2::Instance",
      "Properties": {
        "ImageId"            : "ami-0ab4d1e9cf9a1215a",
        "InstanceType"       : "t3.small",
        "KeyName"            : "YOUR_KEY_PAIR",
        "IamInstanceProfile" : "YOUR_INSTANCE_PROFILE",
        "BlockDeviceMappings" : [
          {
            "DeviceName" : "/dev/xvda",
            "Ebs" : {
              "VolumeType"           : "gp2",
              "VolumeSize"           : "25",
              "Encrypted"            : "true",
              "KmsKeyId"             : "YOUR_KMS_KEY",
              "DeleteOnTermination"  : "true"
            }
          }],

        "NetworkInterfaces" : [{
            "AssociatePublicIpAddress"  : "true",
            "DeleteOnTermination"       : "true",
            "SubnetId"                  : "YOUR_SUBNET_ID",
            "GroupSet"                  :  ["YOUR_SECURITY_GROUP"],
            "DeviceIndex"               : 0
          }],

         "UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
            "#!/bin/bash\n",
            "SOME_CONFIGURATION_FOR_YOUR_APP"
            ]]}}
      }
    }

هشدار عدم فعالیت

بر اساس متریک استفاده از CPU، می توانیم بدانیم که آیا برنامه هنوز در حال استفاده است یا خیر.

زنگ هشدار برای این برنامه ریزی شده است: هنگامی که حداکثر استفاده از CPU نمونه به مدت 1 ساعت کمتر از 12٪ باشد، زنگ آن را متوقف می کند.

✏️توجه: مقدار آستانه برای استفاده از CPU باید با توجه به برنامه شما تعریف شود. در مورد من، برنامه ای که در نمونه EC2 مستقر کردم داشبورد Splunk بود، بنابراین تنظیم آن آستانه بهترین گزینه من بود.

در اینجا تعریف آلارم آمده است:

 "MyEC2Alarm": {
        "Type": "AWS::CloudWatch::Alarm",
        "Properties": {
          "AlarmDescription": "Alarm to stop Instance",
          "AlarmName": "Inactivity Alarm",
          "AlarmActions": 
            [ "arn:aws:automate:us-east-1:ec2:stop" ],
          "MetricName": "CPUUtilization",
          "Namespace": "AWS/EC2",
          "Statistic": "Maximum",
          "Period": "1800",
          "Threshold": "3",
          "ComparisonOperator": "LessThanOrEqualToThreshold",
          "EvaluationPeriods": "2",
          "Dimensions": [
            {
              "Name": "InstanceId",
              "Value": {  "Ref" :  "WebServerInstance" }
            }
          ]
        }
    }

قانون رویداد

قانون EventBridge منتظر توقف برنامه شما خواهد بود، بنابراین می تواند عملی را انجام دهد. این عمل به این صورت است که یک تابع Lambda را فعال می کند که حاوی کد حذف پشته CloudFormation است.

"EventRule": {
      "DependsOn": ["ADLambda", "WebServerInstance"],
      "Type": "AWS::Events::Rule",
      "Properties": {
        "Description": "EventRule for EC2 Stopping",
        "EventPattern": {
          "source": [
            "aws.ec2"
          ],
          "detail-type": [
            "EC2 Instance State-change Notification"
          ],
          "detail": {
            "state": [
              "stopped"
            ],
            "instance-id": [{
              "Ref": "WebServerInstance"
            }]
          }
        },
        "State": "ENABLED",
        "Targets": [{
          "Arn": {"Fn::GetAtt": ["ADLambda", "Arn"] },
          "Id": "ADLambda"
        }]
      }
    }

تابع لامبدا

هنگامی که تابع توسط قانون رویداد راه‌اندازی می‌شود، یک اسکریپت پایتون را برای حذف پشته CloudFormation که همه چیز را ایجاد کرده است اجرا می‌کند… منظورم این است که چقدر عالی است؟! 🤯

در اینجا تعریف لامبدا آمده است:

"ADLambda": {
      "Type": "AWS::Lambda::Function",
      "Properties": {
        "Handler": "index.handler",
        "Role": {
          "Fn::GetAtt": [
              "LambdaExecutionRole",
              "Arn"
          ]
        },
        "Code": {
          "ZipFile": "import boto3 \nimport os \nimport json \nstack_name = os.environ['stackName'] \n\ndef delete_cfn(stack_name):\n  try:\n   cfn = boto3.resource('cloudformation')\n   stack = cfn.Stack(stack_name)\n   stack.delete()\n   return \"SUCCESS\"\n  except:\n   return \"ERROR\" \ndef handler(event, context):\n  print(\"Received event:\")\n  print(json.dumps(event))\n  return delete_cfn(stack_name)"
        },
        "Environment": {
          "Variables": {
            "stackName": {
              "Ref" : "AWS::StackName"
            }
          }
        },
        "Runtime": "python3.9"
      }
}

کد پایتون

موردی که در خط “ZipFile” در بخش قبلی قرار دارد.

import boto3 
import os 
import json 
stack_name = os.environ['stackName']
def delete_cfn(stack_name):
 try:
 cfn = boto3.resource('cloudformation')
 stack = cfn.Stack(stack_name)
 stack.delete()
 return "SUCCESS"
 except:
 return "ERROR" 
def handler(event, context):
 print("Received event:")
 print(json.dumps(event))
 return delete_cfn(stack_name)

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

نقش اجرای لامبدا

عملکردی که عملکرد لامبدا را انجام می دهد و به تابع Lambda اجازه می دهد تا تمام منابع را از پشته حذف کند، همانطور که در سیاست بیان شده است.

"LambdaExecutionRole": {
"Type": "AWS::IAM::Role",
"DeletionPolicy": "Retain",
"Properties": {
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": ["lambda.amazonaws.com"]
},
"Action": ["sts:AssumeRole"]
}
]
},
"Path": "https://dev.to/"
}
}

خط مشی اجرای لامبدا

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

✏️توجه: اگر منابع دیگری را در پشته مستقر می کنید، فراموش نکنید که مجوزها را به خط مشی اضافه کنید.

"LambdaExecutionPolicy": {
"Type": "AWS::IAM::Policy",
"DeletionPolicy": "Retain",
"Properties": {
"PolicyName": "autodestruction-policy",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["logs:"],
"Resource": "arn:aws:logs:::"
},
{
"Effect": "Allow",
"Action": [  "cloudformation:DeleteStack" ],
"Resource": {
"Ref": "AWS::StackId"
}},
{
"Effect": "Allow",
"Action": [ "lambda:DeleteFunction" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [  "events:RemoveTargets" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [ "events:DeleteRule" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [ "lambda:RemovePermission" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": ["iam:DeleteRolePolicy","iam:DeleteRole"],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [  "ec2:TerminateInstances" ],
"Resource": [{ "Fn::Join": ["", [
"arn:aws:ec2:",{"Ref": "AWS::Region"},":",
{"Ref": "AWS::AccountId"}, ":instance/",
{"Ref": "WebServerInstance"}]]}]
},
{
"Effect": "Allow",
"Action": [  "iam:DeleteRolePolicy" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [  "cloudwatch:DeleteAlarms" ],
"Resource": [{"Fn::GetAtt" : ["MyEC2Alarm","Arn"]}]
}
]
},
"Roles": [{
"Ref" : "LambdaExecutionRole"
}]
}
}

مجوز لامبدا

منبعی که به قانون EventBridge اجازه می دهد تا تابع را فراخوانی کند. ⚡

"PermissionForADLambda": {
"Type": "AWS::Lambda::Permission",
"Properties": {
"FunctionName": {
"Ref": "ADLambda"
},
"Action": "lambda:InvokeFunction",
"Principal": "events.amazonaws.com",
"SourceArn": {
"Fn::GetAtt": [
"EventRule",
"Arn"
]
}
}
}

حالا قسمت جالب اینجاست…

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

حتی اگر برخی وابستگی ها را برای تغییر ترتیب حذف تنظیم کنیم، باز هم به نقطه ای می رسد که باید آن منابع را قبل از پشته کامل حذف کند. به همین دلیل است که این دو منبع ویژه کنار گذاشته خواهند شد تخریب با یک سیاست حذف “حفظ”.

می دانم که به چه می اندیشی… “آنا، این دیگر یک معماری خود ویرانگر نیست”. خب این نزدیکترین چیزی بود که میتونستم بدست بیارم! و خوبی در مورد این، نقش ها و سیاست هاست متحمل هزینه نشوید. بنابراین شما هنوز در حال صرفه جویی هستید!

💡واقعیت جالب: مدتی در تلاش برای کشف این موضوع بودم، تا اینکه به AWS Summit مکزیکو سیتی رفتم و این معماری را برای یک معمار AWS (در سالن Ask the Expert) توضیح دادم. او در واقع کسی بود که من را با راه حل حفظ روشن کرد!

پس از ایجاد همه چیز باید صفحه CloudFormation خود را به این صورت مشاهده کنید:

اکنون تنها کاری که باید انجام دهید این است که استفاده از برنامه را متوقف کنید و منتظر بمانید… ⏰

بنابراین پیش بروید و پشته خود را تهیه کنید، برنامه خود را باز کنید و سپس استفاده از آن را متوقف کنید. استفاده از CPU کاهش می یابد و در نهایت شروع به حذف خود می کند. باور کنید، دیدن اینکه چگونه به طور خودکار حذف می شود، احساس خوبی است. 🥲

نتیجه

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

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

👩‍💻بیایید به ساختن ادامه دهیم!