Reputation: 451
I'm migrating an application to Amazon and ElasticBeanstalk seems to be the right tool.
This application requires some packages that are not installed in the default AMI and I found two ways to generate the full environment for my application:
Custom AMI: Just add some packages to the default AMI and save it as my custom AMI.
Docker Container: Use the Amazon image with Docker support, providing Dockerfile and let Amazon build and deploy the image.
My question is, What is the recommended option?
I'm worried about things like performance or deploying time related to autoscaling (there will be multiple instances)
I want to know if someone know real pros and const or every option (in theory both options are "equals"). I also know both methods (custom AMI and Docker) but never tried in a high load environment.
Upvotes: 2
Views: 744
Reputation: 4075
The AWS documentation on creating custom AMIs for Elastic Beanstalk has steps on how to properly create a custom AMI. The intro discusses the pros and cons of AMI vs configuration files pretty well:
A custom AMI can improve provisioning times when instances are launched in your environment if you need to install a lot of software that isn't included in the standard AMIs.
Using configuration files is great for configuring and customizing your environment quickly and consistently. Applying configurations, however, can start to take a long time during environment creation and updates. If you do a lot of server configuration in configuration files, you can reduce this time by making a custom AMI that already has the software and configuration that you need.
A custom AMI also allows you to make changes to low level components, such as the Linux kernel, that are difficult to implement or take a long time to apply in configuration files. To create a custom AMI, launch an Elastic Beanstalk platform AMI in Amazon EC2, customize the software and configuration to your needs, and then stop the instance and save an AMI from it.
It obviously varies by use case, but it sounds like in general the recommended approach is to use configuration unless you need to modify your environment heavily enough that spin up time becomes a factor. One should also consider the possible need for their team to separate config files from application code.
Upvotes: 1
Reputation: 451
After some time trying different options I have enough information for answer to myself.
Instead of using a custom AMI, the better I found is Elastic Beanstalk and then customize the instance using ebextensions With ebextensions you can fully customize your instance (packages, files.. everything). The benefits are that your instance will be updated automatically and you don't lose the control of you instance. The cons is that you are bound to amazon elastic beanstalk.
I also noticed that docker is an unnecessary extra layer. Very useful for development but a little headache for production because you lose the control of your instance.
My choose (based on my personal experience) is use a default amazon ami and then use ebextensions for customize them automatically.
Upvotes: 1