EC2 init.d script - what's the best practice

Question

I'm creating an init.d script that will run a couple of tasks when the instance starts up.

• it will create a new volume with our code repository and mount it if it doesn't exist already.
• it will tag the instance

The tasks above being complete will be crucial for our site (i.e. without the code repository mounted the site won't work). How can I make sure that the server doesn't end up being publicly visible? Should I start my init.d script with de-registering the instance from the ELB (I'm not even sure if it will be registered at that point), and then register it again when all the tasks finished successfully? What is the best practice? Thanks!

Answer 1

You should have a health check on your ELB. So your server shouldn't get in unless it reports as happy. And it shouldn't report happy if the boot script errors out.

(Also, you should look into using cloud-init. That way you can change the boot script without making a new AMI.)

Answer 2

I suggest you use CloudFormation instead. You can bring up a full stack of your system by representing it in a JSON format template.

For example, you can create an autoscale group that has an instances with unique tags and the instances have another volume attached (which presumably has your code)

Here's a sample JSON template attaching an EBS volume to an instance:

https://s3.amazonaws.com/cloudformation-templates-us-east-1/EC2WithEBSSample.template

And here many other JSON templates that you can use for your guidance and deploy your specific Stack and Application.

http://aws.amazon.com/cloudformation/aws-cloudformation-templates/

Of course you can accomplish the same using init.d script or using the rc.local file in your instance but I believe CloudFormation is a cleaner solution from the outside (not inside your instance)

You can also write your own script that brings up your stack from the outside by why reinvent the wheel.

Hope this helps.