We shall kick start the complete automation of AWS Elastic Beanstalk application. For that we are going to make use of the customization facility provided by the configuration files. You can read more about them here and here.
What is this automation we are talking about and what do we intend to achieve?
Our website hudku.com is an AWS Elastic Beanstalk application. Let me outline all the important tasks we have automated.
The automation mainly includes creation of new beanstalk environments, termination of environments, reusing an existing environment but deploying a new application into it, swapping of staging and production environments, etc. These are some of the main tasks we intend to accomplish using scripts instead of operating from AWS Elastic Beanstalk console.
Creation of New AWS Beanstalk Environment
We should be able to create a new environment which could either be a development environment or a staging environment. Once an environment is created it would be nice if DNS records are automatically updated so that the application becomes available at dev.myDomain.com or staging.myDomain.com. That way we could access our application at this URL and test it.
It would also be nice if the main EC2 instance which is the leader of the Auto Scaling Group, automatically becomes available at ec2.dev.myDomain.com or ec2.staging.myDomain.com so that we could SSH into it.
These DNS updates would be done using AWS Route53.
Swapping of Staging and Production Environment
Once we test our new version of the application at staging.myDomain.com and are satisfied with it then with just one command we should be able to swap the staging with the production so that staging becomes production and production becomes staging. That means after the swap, if we access the top level domain at myDomain.com then we should be accessing the new version of our application and the old production becomes available at staging.myDomain.com. Let us say after some time if we discover any serious flaw in the new version we can execute the swap again and run the old production version until we rectify the problem in the new version.
Termination of Environment
Definitely we do not want to terminate the production environment at any time. If you need that facility then you will have to write your own script. But we do need commands to terminate development or staging environment and we shall definitely provide them.
Deployment of application to an existing environment
Normally this is the script that gets used instead of creating new environments every time. We must be able to deploy a new version of application to an existing environment such as development or staging without creating it from scratch. We should also be able to deploy a version to production environment after ensuring that secondary tomcat instance is running.
Other General Tasks
Then there are several general tasks that need to be executed. They can be classified into two categories.
1. Tasks that need to be executed only once
These include mounting instance storages if available on a given EC2 machine, creating and setting up swap space (very critical if EC2 micro instance is being used), download and install all the required packages, download the files containing security credentials as well as other essential files from S3 and copy them to appropriate locations, etc.
2. Tasks that need to be executed each time the application is deployed
These include copying the configuration files of apache or tomcat, setting up the daily routine jobs which could include database backup, log files backup and any other similar tasks which might vary from one application to another.
This is the broad outline of what we want to achieve. To accomplish this we need several utility scripts which we shall see as the future blog posts unfurl.
In the next post let us discuss "elastic-beanstalk.config" which is the name we have given for our main configuration file. Hope you would find our next post useful and informative if not exhilarating.
What is this automation we are talking about and what do we intend to achieve?
Our website hudku.com is an AWS Elastic Beanstalk application. Let me outline all the important tasks we have automated.
The automation mainly includes creation of new beanstalk environments, termination of environments, reusing an existing environment but deploying a new application into it, swapping of staging and production environments, etc. These are some of the main tasks we intend to accomplish using scripts instead of operating from AWS Elastic Beanstalk console.
Creation of New AWS Beanstalk Environment
We should be able to create a new environment which could either be a development environment or a staging environment. Once an environment is created it would be nice if DNS records are automatically updated so that the application becomes available at dev.myDomain.com or staging.myDomain.com. That way we could access our application at this URL and test it.
It would also be nice if the main EC2 instance which is the leader of the Auto Scaling Group, automatically becomes available at ec2.dev.myDomain.com or ec2.staging.myDomain.com so that we could SSH into it.
These DNS updates would be done using AWS Route53.
Swapping of Staging and Production Environment
Once we test our new version of the application at staging.myDomain.com and are satisfied with it then with just one command we should be able to swap the staging with the production so that staging becomes production and production becomes staging. That means after the swap, if we access the top level domain at myDomain.com then we should be accessing the new version of our application and the old production becomes available at staging.myDomain.com. Let us say after some time if we discover any serious flaw in the new version we can execute the swap again and run the old production version until we rectify the problem in the new version.
Termination of Environment
Definitely we do not want to terminate the production environment at any time. If you need that facility then you will have to write your own script. But we do need commands to terminate development or staging environment and we shall definitely provide them.
Deployment of application to an existing environment
Normally this is the script that gets used instead of creating new environments every time. We must be able to deploy a new version of application to an existing environment such as development or staging without creating it from scratch. We should also be able to deploy a version to production environment after ensuring that secondary tomcat instance is running.
Other General Tasks
Then there are several general tasks that need to be executed. They can be classified into two categories.
1. Tasks that need to be executed only once
These include mounting instance storages if available on a given EC2 machine, creating and setting up swap space (very critical if EC2 micro instance is being used), download and install all the required packages, download the files containing security credentials as well as other essential files from S3 and copy them to appropriate locations, etc.
2. Tasks that need to be executed each time the application is deployed
These include copying the configuration files of apache or tomcat, setting up the daily routine jobs which could include database backup, log files backup and any other similar tasks which might vary from one application to another.
This is the broad outline of what we want to achieve. To accomplish this we need several utility scripts which we shall see as the future blog posts unfurl.
In the next post let us discuss "elastic-beanstalk.config" which is the name we have given for our main configuration file. Hope you would find our next post useful and informative if not exhilarating.