我们正在为移动应用程序开发一个API,这应该有两个阶段:开发和生产。此外,这必须具有单独的环境变量才能连接到数据库并存储 SNS 密钥。如何使用 Circle CI 和 aws lambda 执行此操作。
在处理AWS lambdas
阶段时,您有两个(我能想到的)选项,单个AWS
帐户路径和AWS
帐户/阶段路径。两者都依赖于版本发布后环境变量的不变性。
基本上,一旦您对 lambda 代码的版本感到满意,您就可以发出命令以使用Circle CI
作业中的CLI
来创建版本AWS
。这有效地创建了 lambda 及其所有环境变量的快照。之后,您也可以使用Circle CI
创建一个别名以指向此新版本。依赖于此lambda
的所有服务都应指向别名,而不是指向特定版本,以避免为每个版本更新它们。
这适用于单帐户和多帐户解决方案。区别在于如何根据环境引用lambda
的版本。
单帐户路由:您将为每个阶段创建一个别名,在您的情况下,dev
和prod
。步骤如下所示:
-
更改新版本的
lambda
代码。 -
更新
dev
环境的新版本所需的环境变量。 -
发布新版本的
lambda
。这将修复您为该版本指定的环境变量。 -
更新您的开发别名以指向此新版本并对其进行测试。如果出现问题,您可以随时回滚到
dev
中使用的先前版本。 -
在
lambda
的$LATEST
版本中修改prod
环境的环境变量。 -
按照步骤 3 和 4 操作,但使用
prod
作为别名。多帐户路由:这里的别名基本上用于在新版本经过正确测试后指向新版本(例如,或使用
canary release
实际测试它),无论环境如何。 -
按照
dev
账户中单个账户路由中的步骤 1 到 4 进行操作。使用任何你喜欢的别名。prod
可以同时适用于两个帐户,或者,如果您使用blue/green deployment
,您可以使用蓝色和绿色作为别名来引用测试中的当前版本和当前实时版本。 -
按照
prod
账户中单个账户路由中的步骤 1 到 4 进行操作。与以前对别名的方法相同。
就个人而言,我更喜欢多帐户路线。如果您的环境变量来自另一个服务(如Systems Manager Parameter Store
),它将简化代码。在单个帐户选项中,您仍然需要将阶段作为变量传递,然后使用它从Parameter Store
中获取正确的值(类似于 dbpass_dev 和 dbpass_prod)。然后,您还必须在Parameter Store
中放置一些内容,以限制对每个变量的访问,具体取决于它们是用于开发还是用于生产环境。这可以使用策略和标签来完成,但更复杂。