介绍
技术世界一直在不断发展，随之而来的是需要高效且可扩展的解决方案。由于其能够处理工作负载而无需基础架构管理，因此无服务器的体系结构获得了巨大的知名度。在本文中，我们将探讨使用Terraform构建AWS无服务器图像识别电报机器人的过程。
使用付费的定价模型，您只有在执行功能时就会产生成本，从而确保成本效益。此外，AWS免费层的可用性意味着对于小型工作量，您什么都不付钱。
此机器人利用电报中的网络钩，使其能够以反应性的方式操作，并迅速响应特定事件。通过利用Webhooks，机器人保持空闲直到触发为止。
解决方案图
下图说明了完整的解决方案，采用了一系列AWS服务以确保其无缝功能。
架构的核心是Lambda功能，在执行所需的操作中起着关键作用。为了优化Lambda部署的效率并加速初始化，采用了Lambda层。这些层包含所有必要的依赖项，简化了部署过程并促进了更快的开发迭代。
为了确保敏感信息的安全性，例如机器人令牌，我使用秘密经理。该安全库使所有lambdas都能直接访问令牌，从而消除了将其存储在环境变量中的需求。
用户量图像的存储由S3存储桶促进。这允许AWS重新认知访问和图像的检索，只需定义铲斗中的图像路径。
API网关充当Lambda功能调用的代理，提供了无缝的通信渠道。除了其直接角色外，API Gateway还提供了潜在的未来收益，例如交通路线和为API创建开发环境的能力。这种多功能性将产品定位为未来的可伸缩性，并易于与不断发展的要求集成。
对于简单的统计存储，DynamoDB用作有效的解决方案。通过利用DynamoDB，该解决方案有效地存储并检索统计数据，确保可靠的数据管理而无需不必要的复杂性。
最后，AWS重新认知用于检测图片上的标签。尽管实施利用了由于开发时间限制而导致的服务的最小功能，但它可以证明其功能。 AWS重新认知提供了强大的图像分析功能，可以在将来的迭代中进一步探索和增强。
机器人功能
机器人的功能围绕三个简单实体旋转：
- 文本处理
- 图像识别
- 统计请求
最初，为了简化实现，我在一个lambda函数中合并了这些功能。但是，随着逻辑越来越复杂，我倾向于通过将这些功能分离为单个lambda函数来采用模块化方法。
机器人设置
设置新机器人是一个直接的过程，仅需要三个简单的步骤，所有这些步骤都可以在Botfather的帮助下完成。让我们深入研究过程：
步骤1：请求新的机器人
步骤2：选择一个机器人名称
步骤3：分配帐户名
可选步骤：设置Bot Avatar Image
您可以在屏幕截图中看到它：
Terraform项目
为了确保平稳有效的设置流程，我将Terraform（一种行业领先的基础架构作为代码（IAC）工具）使用。使用Terraform，我可以轻松地提供项目所需的整个基础架构。
这是整个存储库：
user@ubuntu:~/aws-telegram-bot-serverless$ tree
.
├── LICENSE
├── lambda
│ ├── bot-dependencies-layer
│ │ └── requirements.txt
│ ├── bot-function
│ │ └── bot.py
│ └── webhook-function
│ └── webhook.py
└── terraform
├── 00-provider.tf
├── 01-roles.tf
├── 02-secrets.tf
├── 03-lambda-layer-with-dependencies.tf
├── 04-lambda-bot.tf
├── 05-lambda-webhook.tf
├── 06-api-gateway.tf
├── 07-bucket-images.tf
├── 08-dynamodb-stats.tf
├── 98-output.tf
├── 99-data.tf
├── create_bucket.sh
├── terraform.tfvars
└── variables.tf
5 directories, 18 files
让我们仔细研究一下资源提供的全面列表：
user@ubuntu:~/aws-telegram-bot-serverless/terraform$ terraform state list
data.archive_file.lambda-bot-zip-file
data.archive_file.layer-zip-file
data.archive_file.webhook-function-zip-file
data.aws_caller_identity.current-account
data.aws_lambda_invocation.webhook-lambda-invocation
aws_apigatewayv2_api.call-back-api
aws_apigatewayv2_integration.api-gw-to-lambda
aws_apigatewayv2_route.post-callback-route
aws_apigatewayv2_stage.prod
aws_cloudwatch_log_group.call-back-api-gw
aws_cloudwatch_log_group.lambda-log-bot
aws_cloudwatch_log_group.lambda-log-webhook
aws_dynamodb_table.aws-telegram-bot-statistics
aws_iam_policy.custom-policy
aws_iam_role.lambdaRole
aws_iam_role_policy_attachment.custom-policy-attachment
aws_iam_role_policy_attachment.policy-attachment["arn:aws:iam::aws:policy/AWSLambdaExecute"]
aws_iam_role_policy_attachment.policy-attachment["arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess"]
aws_iam_role_policy_attachment.policy-attachment["arn:aws:iam::aws:policy/AmazonRekognitionReadOnlyAccess"]
aws_iam_role_policy_attachment.policy-attachment["arn:aws:iam::aws:policy/service-role/AmazonS3ObjectLambdaExecutionRolePolicy"]
aws_lambda_function.bot-lambda
aws_lambda_function.webhook-lambda
aws_lambda_layer_version.lambda-layer-for-packages
aws_lambda_permission.api_gw
aws_s3_bucket.images-bucket
aws_s3_bucket_lifecycle_configuration.images-bucket-name-lifecycle_configuration
aws_secretsmanager_secret.bot-token-secret
aws_secretsmanager_secret_version.sversion
null_resource.pip-install
在使用Terraform提供基础架构时，我遇到了与环境依赖关系有关的挑战。为了确保成功执行我的Terraform代码，我依靠一个本地供应商，该供应人员涉及执行Python Pip安装命令并将结果存储在 /TMP文件夹中。为了解决此问题并确保在环境之间进行一致的设置，我已经在GitHub上实施了以下解决方案。
github动作
为了确保便利性和灵活性，我设计了可以使用两种不同方法部署的机器人：GitHub Action和本地设置。这使您可以选择最适合您的偏好和要求的方法。
为了促进这种部署的灵活性，我对Terraform后端部分进行了某些修改。由于我在这个项目中不使用Terragrunt，因此我将A sed 命令纳入了我的管道。这使我可以动态地重写Terraform后端部分，并指定适当的AWS区域。尽管它可能不是最优雅的解决方案，但它有效地确保了后端的正确配置。
...
jobs:
terraform:
name: 'Deploy the bot on AWS'
runs-on: ubuntu-latest
...
- name: Replace the Region in the Provider section of Terraform
run: sed -i 's/us-east-1/${{ env.AWS_REGION }}/g' $TERRAFORM_PATH/00-provider.tf
- name: Terraform Init
run: terraform -chdir=$TERRAFORM_PATH init
...
我将一些秘密和一个变量牢固地存储在github上。如果您想使用我的代码，也应该这样做。
我提供了三个简化机器人的部署和管理过程的工作流程：
1-创建Terraform状态存储桶和DynamoDB表：
此工作流程可以创建Terraform状态存储桶和DynamoDB表。重要的是要注意，这些对象将不会由Terraform本身管理，并且需要在必要时进行手动删除。
2-基本机器人服务的配置：
第二个工作流程自动化机器人所需的所有服务的配置。
3-托管基础架构的破坏：
最终工作流程的重点是Terraform管理的基础设施的受控破坏。此过程可确保不再需要资源的有效清理。
使用步骤1时，要谨慎行事至关重要。由于S3存储桶具有一个全局名称空间，因此选择存储桶名称时可能会出现冲突。为了减轻这种情况，可能有必要修改前缀的存储桶名称。这样可以确保唯一性并防止在全局S3名称空间内命名冲突。
演示时间
为了更清楚地了解机器人的操作，我提供了一些屏幕，以展示其在作用中的功能。
图像识别：
统计请求：
如果您有电报帐户，我邀请您尝试该机器人并亲身探索其功能。我提供此机器人，直到2023年7月底。不能保证进一步的服务，因为我不想超越AWS免费层。
结论
AWS无服务器堆栈为您提供了一个功能强大且可扩展的解决方案。该项目展示了无服务器体系结构的潜力，并强调了使用Terraform的易于开发。
希望您喜欢这篇文章。
您可以在我的github存储库中找到我的所有代码：https://github.com/andygolubev/aws-telegram-bot-serverless
您可以自己尝试此机器人：http://t.me/AWS_Image_Rekognition_Bot
随意在LinkedIn上与我建立联系：https://www.linkedin.com/in/andy-golubev/