我为我的eb应用程序创建了一个工作环境,以便利用其周期性任务"使用cron.yaml
的功能(位于我的应用程序的根目录中)。它是一个简单的sinatra应用程序(现在),我想用它来向相应的Web服务器环境发出请求。
但是,我在通过eb cli部署时遇到了麻烦。以下是我运行eb deploy
的情况。
╰─➤ eb deploy
Creating application version archive "4882".
Uploading myapp/4882.zip to S3. This may take a while.
Upload Complete.
INFO: Environment update is starting.
ERROR: Service:AmazonCloudFormation, Message:Stack named 'awseb-e-1a2b3c4d5e-stack'
aborted operation. Current state: 'UPDATE_ROLLBACK_IN_PROGRESS'
Reason: The following resource(s) failed to create: [AWSEBWorkerCronLeaderRegistry].
我查看了CloudFormation信息中心,查看是否存在可能的错误。在阅读了一些关于AWSEBWorkerCronLeaderRegistry
的内容之后,我发现它最有可能是DynamoDB
表被更新/创建。但是,当我查看DynamoDB
仪表板时,没有列出表格。
与往常一样,任何帮助,反馈或指导都会受到赞赏。
答案 0 :(得分:2)
我正在使用Codepipeline来部署我的工作人员并且遇到了同样的错误。最后,我尝试向AWS-CodePipeline-Service提供AmazonDynamoDBFullAccess策略,这似乎解决了这个问题。
答案 1 :(得分:1)
我们遇到了同样的问题并通过将AmazonDynamoDBFullAccess附加到Elastic Beanstalk角色(在我们的例子中名为aws-elasticbeanstalk-ec2-role)来修复它。
答案 2 :(得分:1)
如果您不愿意添加完整的DynamoDB访问权限(就像我一样),Beanstalk现在提供了一个Managed Policy for Worker环境权限(AWSElasticBeanstalkWorkerTier)。您可以尝试将其中一个添加到实例配置文件角色中。
请参阅http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/iam-instanceprofile.html
答案 3 :(得分:0)
如Anthony所建议的那样,当从其他服务(如CodePileline)触发部署时,其服务角色需要dynamodb:CreateTable
权限才能在DynamoDB中创建Leader Registry表(下面有更多信息)。
添加完全访问权限是一种不良做法,应避免。另外,托管策略AWSElasticBeanstalkWorkerTier
没有适当的权限,因为它是工作人员访问DynamoDB并检查它们是否是当前领导者的权限。
AccessDenied
AWSCodePipelineServiceRole-us-east-1-dev
):{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CreateCronLeaderTable",
"Effect": "Allow",
"Action": "dynamodb:CreateTable",
"Resource": "arn:aws:dynamodb:*:*:table/*-stack-AWSEBWorkerCronLeaderRegistry*"
}
]
}
在不确定什么权限应该附加到什么上时,您可以使用此技术。
来自Periodic Tasks Documentation:
Elastic Beanstalk使用领导者选举来确定您的工作人员环境中的哪个实例将定期任务排队。每个实例都尝试通过写入Amazon DynamoDB表来成为领导者。成功的第一个实例是领导者,并且必须继续写入表以保持领导者状态。如果领导者退出服务,另一个实例将很快取代它。
对于那些想知道的人,此DynamoDB表使用10个RCU和5个WCU,它们始终处于免费层。