使用Terraform通过亚马逊管理的工作流和使用GitHub Actions的自动DAG同步来构建无服务器的Airflow
在这篇文章中，我们将再次通过Terraform建立无服务器的基础设施：使用亚马逊管理工作流的Airflow部署，加上GitHub Actions自动同步DAG代码到S3。
作为基线，我们将分叉Claudio Bizzotto的伟大仓库claudiobizzotto/aws-mwaa-terraform，其中已经包括所有亚马逊管理工作流的Terraform代码。我们将在上面添加S3同步功能。这将使我们能够将我们的GitHub代码部署到Airflow服务上。你可以在这里找到分叉的仓库：stelsemeyer/aws-mwaa-terraform。
Terraform设置
使用Terraform创建管理的Airflow大约需要30分钟。该设置不在免费级别之内，每小时的成本约为1美元。
我们将在terraform.tfvars 中使用以下变量。
region = "eu-central-1"profile = "airflow" # we use an AWS profile in ~/.aws/credentialsprefix = "airflow"vpc_cidr = "10.192.0.0/16"public_subnet_cidrs = [ "10.192.10.0/24", "10.192.11.0/24"]private_subnet_cidrs = [ "10.192.20.0/24", "10.192.21.0/24"]mwaa_max_workers = 2
我们可以使用terraform plan ，计划我们的基础设施，如果我们对结果感到满意，我们可以terraform apply 。
Plan: 31 to add, 0 to change, 0 to destroy.Changes to Outputs: + access_key_id = (known after apply) + mwaa_environment_arn = (known after apply) + mwaa_webserver_url = (known after apply) + private_subnets_ids = [ + (known after apply), + (known after apply), ] + public_subnets_ids = [ + (known after apply), + (known after apply), ] + region = "eu-central-1" + s3_bucket_id = (known after apply) + s3_bucket_name = (known after apply) + secret_access_key = (known after apply) + vpc_id = (known after apply)
Airflow webserver
一旦一切创建完毕，我们可以访问我们的Airflow webserver实例。为此，我们需要登录到AWS控制台。然后我们可以通过Amazon Managed Workflows ，或者使用terraform output 的链接来访问它。
AWS控制台中的亚马逊管理的工作流程，包括Airflow用户界面的URL - 图片由作者完成。
我们应该看到Airflow UI，包括dags 文件夹中的两个DAG，这些DAG最初是由Terraform上传到S3的。
带有激活的教程DAG的Airflow界面--图片由作者完成。
如果我们点击一个DAG，我们可以看到图形视图。一旦我们把DAG设置为激活状态，任务就会开始运行，以赶上进度。
单个DAG视图 - 图片由作者完成。
使用GitHub Actions进行DAG同步
为了设置GitHub Actions来自动同步我们的dags 文件夹中的实际DAG代码到S3，我们可以使用access_key_id,secret_access_key,region 和s3_bucket_name 从terraform output 。我们把这些值作为Secrets 添加到存储库中。
工作流yaml文件.github/workflows/sync.yml 定义了我们要执行的动作：一旦我们合并到main 分支，我们就使用jakejarvis/s3-sync-action将文件夹dags 同步到S3。我们可以自定义触发器，只在标签或类似情况下执行该动作。
name: Sync dags
通过GitHub上的Workflow 标签，我们可以查看工作流程的状态。每当我们合并到main ，文件就会被同步到S3，我们应该能在几秒钟内看到Airflow用户界面上的更新DAG（你可能需要点击刷新按钮）。
销毁
要销毁基础设施，你需要先删除桶中的所有文件。
# BUCKET_NAME = $(terraform output -json | jq -r .s3_bucket_name.value)# aws s3 rm s3://${BUCKET_NAME} --recursive
然后我们可以通过terraform destroy ，销毁所有基础设施，这同样需要20-30分钟左右。
# terraform destroy
总结
像往常一样，在使用无服务器基础设施时，我们需要在维护、控制和成本之间做出妥协。这篇文章很好地讨论了亚马逊托管工作流的优势和劣势，我们可以将其总结在这里。
优点
- 易于与其他AWS服务（如Redshift、EMR、SageMaker）整合
- 自动缩放，实现时间和成本效益的调度
- 使用CloudWatch进行监控和记录
- AWS管理的安全性，包括VPC
- 通过Fargate的容器化工作流程
劣势
- 我们不能ssh进入我们的Airflow实例或访问Airflow数据库本身
- 依赖于AWS提供的Airflow版本
- 局限于云提供商
总而言之，在我们自己的硬件或云实例上部署Airflow比MWAA的设置更复杂，但它将使我们更容易定制，使用KubernetesPodOperator ，在Kubernetes上运行任务等。对于个人的使用情况，我们必须权衡利弊。如果你想先测试Airflow，使用管理版本可能是一个好主意，因为一旦你想迁移离开它，你可以很容易地将你的dags转移到自己的部署中。
