The Docker revolution was based on the promise to add automation and customizability to both application development cycles and deployments. Microservices, which in Docker words means each container in a cluster performs only one specific task, is in fashion now. However, managing large numbers of containers may become a very complex and time-consuming task in the long run. Enter AWS Elastic Beanstalk.
Elastic Beanstalk service can abstract away several system administration levels, as AWS itself will take care of hardware provisioning and administration, networking, and more. But while running Docker Engine on a local machine, and to some extent exposing some public service to the web, is not necessarily going to be all that difficult. The real power of launching automated clusters of containers is a different story, and particularly if there is a need to launch those clusters into a public cloud like AWS. Technologies such as Ansible, Chef, Puppet, and ECS can help hiding the complexity. Nevertheless, the learning curve for such tools can sometimes be as complex as manually managing clusters.
Elastic Beanstalk is a service that accepts your application code as input, and then invisibly embeds the code within a complete network and compute infrastructure. All that is needed is for users to select platform like Java, .NET, Python or Docker, and the service does the rest. This means that the EC2 and database instances, security groups, load balancers, auto scaling and other services the application needs, will be automatically added, integrated, and continuously maintained for you. Elastic Beanstalk can always be used from the web console, but as a developer, perhaps the command window would make more sense. Besides, everything always looks much more interesting from the command window. To be able to do that, the EB CLI needs to be install, which is fairly easy. All that is needed is to have pip, the Python package manager, and from there install the EB CLI. A detailed article on installing EB can be found on here. Once it is finished, typing EB alone should bring up the help page.
From the application root directory, typing “eb init” will initialize a new EB application. Regions, name, platform (Docker and Docker version), as well as SSH access options, will be prompted for the selection. Behind the scenes when you initialize an application locally and push it to AWS, what really happens is AWS creates two entities. A space to hold your application files called a framework, and secondly, it creates an environment, which is the infrastructure automatically created by Beanstalk. This means everything from EC2 instance, a load balancer, auto scaling rules, CloudWatch alarms, and security groups are created as part of the supporting infrastructure, depending on how the questions after the “eb init” were answered. A useful command is eb platform show as it will display some of the platform and environment values that will be used to create subsequent applications.
There are three ways to prepare an environment in Beanstalk. Two are primarily based on the version used in the Dockerrun.aws.json. Version 1 is the simplest one; It is used to run single containers and as a result, there is no setup or need for load balancing or auto-scaling. As expected version 2 is designed for multiple container architectures. A very interesting option is the “preconfigured” option. AWS makes Amazon machine images available that are preloaded with fully configured versions of popular deployment profiles on top of Amazon Linux. This is a rather convenient way to get developers a head start in building the application environment.
AWS documentation provides a simple, yet popular, example of a pre configured environment. On the folder, the application was initialized, simply create a Dockerfile and copy-paste the details found in the AWS documentation here. Next step is pulling the trigger and executing eb create and the name for the environment i.e. eb create DEV. That’s it! It’s all done. After a good 15 minutes, a pre-configured Docker platform for Glassfish and Python should have been created.The console will show you log messages throughout the creation. But, for curious developers, you can always go to the browser console and see the EC2 and everything that is being created at runtime.