1回答
- 新しい順
- 投票が多い順
- コメントが多い順
0
As you are currently running a single instance, beanstalk performs an in-place update when you update your application versions, and as such your application might become unavailable for a short period of time. To avoid this considered switching deployment strategies to better support future needs. For example, with a blue/green approach all you would need to do is swap the CNAMEs of the two environments to redirect to the new version instantly.
There are some caveats in that the your environment must run independently of any beanstalk provisioned database.
Refer to Blue/Green deployments with Elastic Beanstalk
The following table compares deployment method properties.
Method | Impact of failed deployment | Deploy time | Zero downtime | No DNS change | Rollback process | Code deployed to |
---|---|---|---|---|---|---|
All at once | Downtime | * | No | Yes | Manual redeploy | Existing instances |
Rolling | Single batch out of service; any successful batches before failure running new application version | ** | Yes | Yes | Manual redeploy | Existing instances |
Rolling with an additional batch | Minimal if first batch fails; otherwise, similar to Rolling | *** | Yes | Yes | Manual redeploy | New and existing instances |
Immutable | Minimal | **** | Yes | Yes | Terminate new instances | New instances |
Traffic splitting | Percentage of client traffic routed to new version temporarily impacted | **** | Yes | Yes | Reroute traffic and terminate new instances | New instances |
Blue/green | Minimal | **** | Yes | No | Swap URL | New instances |
回答済み 2年前
関連するコンテンツ
- AWS公式更新しました 4ヶ月前
Thanks for the response - this is good info. Basically our goal is to move towards the rolling deployment strategy to minimize downtime and allow scalability in the future. At this point my question is primarily about how to go about creating an AMI that will be appropriate for this configuration (eg the AMI creation process).