نحوه ساخت و تست یک ژنراتور PDF Lambda با استفاده از LocalStack در دستگاه محلی خود (قسمت 2: با استفاده از Terraform)

این مقاله پیگیری پست قبلی من ، مقاله است نحوه ساخت و تست یک ژنراتور PDF Lambda با استفاده از LocalStack در دستگاه محلی خود

در آن مقاله ، من شما را از طریق نحوه ساخت و تست یک عملکرد Lambda ژنراتور PDF با استفاده از خدمات Mock AWS پیاده روی کردم.AWS Lambda ، رجیستری کانتینر الاستیک (ECR) و سطل S3—via محل کاربشر ما استفاده کردیم awslocal CLI برای تهیه زیرساخت های مورد نیاز.

در این پیگیری ، ما رویکرد متفاوتی خواهیم داشت. به جای استفاده از CLI ، ما استفاده خواهیم کرد شکل، یک زیرساخت به عنوان ابزار کد (IAC) ، برای تأمین منابع ما. این راهنما ساده و ساده خواهد بود ، بنابراین تجربه اساسی Terraform تمام آنچه شما نیاز دارید دنبال کردن

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

بیایید شروع کنیم

پیش نیازهای

قبل از انجام ، اطمینان حاصل کنید که موارد زیر را نصب کرده اید:

1. اسکله
2. پایتون 3.9+
3. حساب محلی
4. CLI LocalStack
5. دسک تاپ محلی
6. شکل

1: ظرف محلی را مجدداً راه اندازی کنید

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

با فشار دادن می توانید ظرف در حال اجرا را خاتمه دهید CTRL + C فرمان ، یا می توانید ظرف را مستقیماً با استفاده از آن متوقف کنید دسک تاپ محلی برنامه سپس با اجرای این دستور ، ظرف را مجدداً راه اندازی کنید DEBUG=1 localstack startبشر

2. بسته بندی Terraform-local را نصب کنید
در فهرست ریشه نامگذاری شده است localstack، اگر قبلاً فعال نیست ، لطفاً محیط مجازی خود را فعال کنید.

سپس ، نصب کنید terraform-local بسته ، که یک اسکریپت بسته بندی است که به شما امکان می دهد از Terraform برای استقرار منابع به محیط محلی خود استفاده کنید. این ابزار با استفاده از Terraform به صورت محلی با LocalStack ساده می شود و یک ادغام صاف بین این دو را فراهم می کند.

pip install terraform-local

3. ایجاد زیرساخت

بعد ، یک پوشه جدید به نام ایجاد کنید infrastructureبشر این پوشه پرونده های زیر را در خود جای می دهد:

1. locals.tf
2. versions.tf
3. main.tf
4. scripts/build_and_push_lambda_image.sh

بیایید نگاهی دقیق تر به هر یک از این پرونده ها و نقش های آنها در تنظیم زیرساخت ها بیندازیم.

1. افراد محلی. tf

locals {
  aws_region      = "eu-west-1"
  pdf_bucket_name = "my-pdf-bucket"
  pdf_ecr_name    = "pdf-generator-image"
  pdf_generator_lambda = {
    function_name = "pdf-generator-lambda"
  }
}

در پرونده محلی. tf ، ما برخی از متغیرهای اساسی را تعریف می کنیم که در کل پیکربندی Terraform ما استفاده می شود. در اینجا ، ما منطقه AWS ، نام سطل S3 ، نام مخزن ECR و نام عملکرد Lambda را مشخص می کنیم.

2. نسخه ها. tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.59.0"
    }

    random = {
      source  = "hashicorp/random"
      version = "~> 3.6.2"
    }
  }
}

provider "aws" {
  region = local.aws_region

}

در versions.tf پرونده ، ما ارائه دهندگان مورد نیاز را برای پیکربندی Terraform خود مشخص می کنیم. ما ارائه دهنده AWS (HashicorP/AWS) را برای تعامل با خدمات AWS تعریف می کنیم و ارائه دهنده تصادفی (Hashicorp/Random) برای تولید مقادیر تصادفی مانند شناسه های منحصر به فرد. ما همچنین ارائه دهنده AWS را برای استفاده از منطقه تعریف شده در locals.tf پرونده (local.aws_region). این پرونده تضمین می کند که Terraform هنگام تهیه زیرساخت از ارائه دهندگان و نسخه های صحیح استفاده می کند.

3. main.tf

# Generate random string for the bucket name
resource "random_id" "pdf_bucket_suffix" {
  byte_length = 6
}

# S3 bucket for storing the generated PDF files
resource "aws_s3_bucket" "pdf_bucket" {
  bucket        = "${local.pdf_bucket_name}-${random_id.pdf_bucket_suffix.hex}"
  force_destroy = true

  lifecycle {
    prevent_destroy = false
  }

  tags = {
    Name = "${local.pdf_bucket_name}"
  }
}

ما ابتدا یک ایجاد می کنیم random_id منبع برای تولید یک رشته تصادفی ، که به نام سطل S3 ضمیمه می شود و اطمینان حاصل می شود که بی نظیر است. در byte_length = 6 طول رشته تصادفی را مشخص می کند. سپس aws_s3_bucket منبع با استفاده از نام سطل تعریف شده توسط متغیر محلی ایجاد می شود (local.pdf_bucket_name) همراه با پسوند تصادفی. ما همچنین سطل را پیکربندی می کنیم تا اجازه تخریب اجباری (force_destroy = true) این بدان معنی است که حتی اگر حاوی اشیاء باشد می توان آن را حذف کرد. سرانجام ، بلوک چرخه عمر شامل می شود prevent_destroy = false تنظیم ، که تضمین می کند که Terraform در صورت لزوم تخریب سطل را مسدود نخواهد کرد.

• Elastic Container Registry

# ECR repository for storing the Docker images
resource "aws_ecr_repository" "pdf_generator_ecr" {
  name = local.pdf_ecr_name
}

در aws_ecr_repository از منبع برای ایجاد مخزن ECR استفاده می شود که در آن تصویر Docker برای عملکرد Lambda ذخیره می شود. نام مخزن با استفاده از متغیر محلی تعریف شده است local.pdf_ecr_nameبشر

• Build and Push Image to ECR

# Run your existing image push script using null_resource
resource "null_resource" "run_build_and_push_image_script" {
  provisioner "local-exec" {
    command = "bash ${path.module}/scripts/build_and_push_lambda_image.sh"
    environment = {
      ECR_REPO_URI = aws_ecr_repository.pdf_generator_ecr.repository_url
    }
  }

  depends_on = [
    aws_ecr_repository.pdf_generator_ecr # Ensure the repository exists before running the script
  ]
}

از آنجا که ما نمی توانیم یک عملکرد لامبدا خالی ایجاد کنیم ، باید اطمینان حاصل کنیم که قبل از ایجاد عملکرد لامبدا ، یک تصویر موجود داریم. بنابراین ما می توانیم این کار را با استفاده از null_resource بلوک برای تماس با اسکریپت ما scripts/build_and_push_lambda_image.sh این تصویر Docker را برای عملکرد ژنراتور PDF ما ایجاد می کند و آن را به مخزن ECR که در پیکربندی تعریف شده است ، مستقر می کند. ما بعد از تکمیل پرونده اصلی. tf ، محتوا را به اسکریپت اضافه خواهیم کرد.

در این null_resource بلوک ، ما عبور می کنیم ECR_REPO_URI متغیر محیط به build_and_push_lambda_image.sh اسکریپت ، که به آن اجازه می دهد تا به صورت پویا از URL صحیح مخزن ECR آمازون برای فشار دادن تصویر Docker ساخته شده استفاده کند. در depends_on آرایه تضمین می کند که اسکریپت فقط پس از مخزن ECR اجرا می شود (aws_ecr_repository.pdf_generator_ecr) ایجاد شده است ، و جلوگیری از هرگونه مشکل برای فشار آوردن تصویر به یک مخزن غیر موجود است.

سلب مسئولیت: رویکرد مورد استفاده در این آموزش فقط برای اهداف آموزشی است. در حالی که Terraform ابزاری قدرتمند برای تهیه زیرساخت ها است ، استفاده از آن برای ساخت و فشار تصاویر Docker برای محیط های تولید توصیه نمی شود. در تولید ، بهتر است از یک خط لوله CI/CD اختصاصی برای مدیریت مصنوعات برنامه خود استفاده کنید.

# IAM Role for Lambda Execution
resource "aws_iam_role" "pdf_generator_lambda_role" {
  name = "ExecRole-${local.pdf_generator_lambda.function_name}"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = ""
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      },
    ]
  })
}

در aws_iam_role.pdf_generator_lambda_role نقش IAM به عملکرد لامبدا اجازه می دهد مجوزهای لازم برای اجرای را فرض کند. این مجوز خدمات لامبدا را برای تعامل با منابع AWS به طور ایمن با تعریف assume_role_policy با مجوزهای مناسب

# Lambda Function for PDF Generation
resource "aws_lambda_function" "pdf_generator" {
  function_name = local.pdf_generator_lambda.function_name
  role          = aws_iam_role.pdf_generator_lambda_role.arn
  package_type  = "Image"
  image_uri     = aws_ecr_repository.pdf_generator_ecr.repository_url
  timeout       = 60
  memory_size   = 128
  architectures = ["arm64"]

  environment {
    variables = {
      S3_BUCKET_NAME = aws_s3_bucket.pdf_bucket.bucket
    }
  }

  depends_on = [
    aws_ecr_repository.pdf_generator_ecr,         # Ensure the ECR repo exists before pushing the image
    null_resource.run_build_and_push_image_script # Ensure the script runs before Lambda is created
  ]
}

در اینجا ما تعریف می کنیم pdf_generator تابع Lambda ، مشخص کردن نام عملکرد ، نقش IAM و تصویر کانتینر از مخزن ECR. Lambda با استفاده از 128 مگابایت حافظه و یک زمان 60 ثانیه ای اختصاص داده شده است. arm64 معماری ما یک متغیر محیط را برای نام سطل S3 تنظیم می کنیم. در depends_on بلوک تضمین می کند که لامبدا تنها پس از وجود مخزن ECR ایجاد شده و تصویر Docker ساخته و تحت فشار قرار می گیرد.

توجه: اگر دستگاه توسعه محلی شما یا محیطی که در آن در حال ساخت عملکرد لامبدا هستید از معماری متفاوتی استفاده می کند ، مانند x86_64 (مشترک برای بسیاری از ماشین های لینوکس یا ویندوز) ، می توانید تنظیم کنید architectures مقدار آرایه از arm64 به x86_64بشر

4. اسکریپت ها/build_and_push_lambda_image.sh

#!/bin/bash

# Get the ECR URI from the environment variable
ECR_REPO_URI=$ECR_REPO_URI

# Now you can use the $ECR_REPO_URI in the script
echo "ECR URI: $ECR_REPO_URI"

# get the current directory
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

# Navigate to the lambda function directory
echo "Navigating to lambda function directory..."
cd $SCRIPT_DIR/../../pdf-generator-lambda || exit 1

echo "Current directory: $(pwd)"

# Build the docker image
echo "Building the docker image..."
docker build --no-cache -t lambda-container-image .

# Tag the image with the ECR repository URI
echo "Tagging the docker image with the ECR repository URI..."
docker tag lambda-container-image $ECR_REPO_URI

# Push the image to the ECR repository
echo "Pushing the docker image to the ECR repository..."
docker push $ECR_REPO_URI

echo "Script execution completed."

این اسکریپت عملکرد PDF Generator Lambda را به عنوان یک تصویر Docker می سازد ، آن را برچسب می زند و آن را به مخزن ECR مشخص می کند. در ECR_REPO_URI به عنوان یک متغیر محیط از null_resource مسدود کردن در main.tf پرونده

این پیکربندی لازم را انجام می دهد. قبل از اینکه ما با استفاده از نصب شده ، زیرساخت ها را ایجاد کنیم tflocal بسته ، بیایید یک تغییر کوچک در upload_file.py اسکریپت که بارگذاری فایل PDF تولید شده را به سطل S3 انجام می دهد. پیش از این ، ما را سخت گرفتیم bucket-name؛ اکنون ، به جای آن ، آن را از محیط به عنوان یک متغیر محیط بازیابی خواهیم کرد.

upload_file.py

import os

.....
S3_BUCKET_NAME = os.environ.get("S3_BUCKET_NAME")

.....

وارد کردن os ماژول و خط بالا را اصلاح کنید تا اسکریپت از آن استفاده کند S3_BUCKET_NAME متغیر محیط به جای تکیه بر یک مقدار کدگذاری شده.

اکنون ما آماده ایجاد زیرساخت های خود هستیم. از داخل infrastructure دایرکتوری ، اجرا

tflocal init

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

tflocal plan

این یک نمای کلی از تمام منابع AWS که در ظرف فعال محلی فعال تهیه و تنظیم می شوند ، باز می گردد. شما باید یک خط مشابه با: برنامه: 6 برای افزودن ، 0 برای تغییر ، 0 برای از بین بردنبشر

سرانجام ، اجرا کنید

tflocal apply

برای ایجاد منابع این یک مرور کلی شبیه به آنچه قبلاً هنگام اجرا دیدید نشان می دهد tflocal plan، و از شما می خواهد تا تأیید کنید که آیا می خواهید ادامه دهید یا خیر. به سادگی تایپ کنید yes، و تمام منابع شما در LocalStack ایجاد می شود. برای بررسی عقل ، می توانید از AWS CLI یا دسک تاپ LocalStack استفاده کنید تا تأیید کنید که منابع زیر ایجاد شده است: S3 bucketبا ECR repoوت Lambda functionبشر

حال ، بیایید عملکرد لامبدا خود را فراخوانی کنیم. دوباره به pdf-generator-lambda دایرکتوری و دستور زیر را اجرا کنید:

awslocal lambda invoke --function-name pdf-generator-lambda --payload file://event.json /tmp/lambda.out

شما باید یک پیام موفقیت آمیز مانند این دریافت کنید:

{
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST"
}

می توانید تأیید کنید که PDF با حرکت در سطل S3 با حرکت به سطل از طریق دسک تاپ LocalStack و بارگیری PDF در سطل S3 تولید و ذخیره شد.

تبریک می گویم! 🎉
شما با موفقیت زیرساخت های خود را با استفاده از Terraform و LocalStack تنظیم و آزمایش کرده اید. از خواندن شما متشکرم!