3
votes

I seem to not understand one central point of AWS Autoscaling:

I created an AMI of an (Ubuntu) EC2 instance having my web-server installed, and I use this AMI as the launch-configuration for my Autoscaling group.

But when Autoscaling decides to Spin up a new instance, how am I supposed to launch my webserver on that instance. Am I supposed to write some start-up scripts or what is best practice to start a process of a newly spun-up instance from Autoscaling?

1
The AMI needs to be configured to launch the web server on startup somehow. The way that is done will be different depending on what web server you are using.Mark B
@Mark B So you are advocating to use a startup script, something along the line of adding the webserver to /etc/rc.local . in linux?user695652
Yes, generally speaking, I configure any needed services, such as the web server, to start on boot via /etc/rc.local or /etc/init.d, or whatever works on the flavor of Linux I'm using.Mark B

1 Answers

3
votes

When I deploy an application (PostgreSQL, Elasticsearch, whatever) to an EC2 instance, I usually do it intending on being able to repeat the process. So my first step is to create an initial deployment script which will do as much of the install and setup process as possible, without needing to know the IP address, hostname, amount of memory, number of processors, etc. Basically, as much as I can without needing to know anything that can change from one instance to the next or upon shutdown / restart.

Once that is stable, I create an AMI of it.

I then create an initialization script which I use in the launch-configuration and have it execute that script on the previously created AMI.

That's for highly configured applications. If you're just going with default settings (e.g. IP address = 0.0.0.0), than yes, I would simply set 'sudo update-rc.d <> defaults 95 10', so that it runs on startup.

Then create the AMI. When you create a new instance from that AMI, the webserver should startup by default. If it doesn't, I would look at whether or not you really set the init.d script to do so.

Launching a new instance from an AMI should be no different than booting up a previously shutdown instance.

By the way, as a matter of practice when creating these scripts, I also do a few things to make things much cleaner for me:

1) create modules in separate bash scripts (e.g. creating user accounts, set environment variables, etc) for repeatability

2) Each deployment script starts by downloading and installing the AWS CLI

3) Every EC2 instance is launched with an IAM role that has S3 read access, IAM SSH describe rights, EC2 Address allocation/association, etc.

4) Load all of the scripts onto S3 and then have the deployment / initialization scripts download the necessary bash module scripts, chmod +x and execute them. It's as close to OOP I can get without overdoing it, but it creates really clean bash scripts. The top level launch / initialization scripts for the most part just download individual scripts from S3 and execute them.

5) I source all of the modules instead of simply executing them. That way bash shares variables.

6) Make the linux account creation part of the initialization script (not the AMI). Using the CLI, you can query for users, grep for their public SSH key requested from AWS, create their accounts and have it ready for them to login automagically.

This way, when you need to change something (i.e. change the version of an application, change a configuration, etc.) you simply modify the module script and if it changes the AMI, re-launch and re-AMI. Otherwise, if it just just changes the instance-specifically, than just launch the AMI with the new initialization script.

Hope that helps...