-
Notifications
You must be signed in to change notification settings - Fork 158
Upgrading to 0.11.0
As of 0.11.0, the default scheduling backend in Empire uses CloudFormation to provision AWS resources. The existing non-CloudFormation scheduler is now deprecated and will be removed in the 1.0 release of Empire. Existing users are encouraged to migrate their applications to the new CloudFormation backend using the Scheduler Migration Guide.
When we first built Empire, ECS had just been made generally available and CloudFormation didn't have support for any of the ECS resources, so we had to use the raw AWS api's to provision services and task definitions.
Over time, this has grown increasingly cumbersome to maintain, and forced Empire to become a state manager, like Terraform and CloudFormation. Moving resource state management to CloudFormation opens up a lot of possibilities for Empire moving forward, since it reduces the scope of what we have to build and maintain. It also fixes a number of long standing annoyances when using Empire, like the inability to easily find ECS services and ELB's for an application.
With the 0.11.0 release, CloudFormation becomes the default backend for new apps, but existing applications will continue to use the old backend, until you migrate those applications to the CloudFormation backend. You can follow the steps outlined in the Scheduler Migration Guide to migrate applications.
Moving to the CloudFormation backend will require some addition IAM permissions and AWS resources:
-
EMPIRE_S3_TEMPLATE_BUCKET: This should be the name of an S3 bucket that Empire can use to store CloudFormation templates. -
EMPIRE_CUSTOM_RESOURCES_TOPIC: This should be the ARN of an SNS topic that the CloudFormation backend will use to send requests to createCustom::InstancePortresources. -
EMPIRE_CUSTOM_RESOURCES_QUEUE: This should be the queue url of an SQS queue that is subscribed to the SNS topic above. Empire will poll this queue for custom resources to provision. NOTE: This queue should have a visibility timeout of 30 minutes or more to give Empire ample time to provision resources.
It's recommended that you also set the EMPIRE_ENVIRONMENT variable to something meaningful (e.g. production or staging). Empire will use this a prefix to the names of CloudFormation stacks that get created. If you're running multiple environments in a single AWS account, be sure to set this.
Additionally, you'll need to add some extra permissions to Empire's IAM policy. Refer to the EmpirePolicy resource in the example CloudFormation stack for details on the exact IAM permissions that Empire requires.
In addition, to use the new native scheduled tasks, you must ensure that the ecsServiceRole provided to Empire (EMPIRE_ECS_SERVICE_ROLE) allows extra permissions for AWS Lambda and CloudWatch Events. See the ServiceRole and ServiceRolePolicies resources in the example CloudFormation stack