Does Creating an Image of an Amazon EC2 Linux instance cause any downtime? Can I image a running server?
Already answered correctly, but I wanted to add a couple of caveats:
--no-reboot, no guarantee: When you create an image of a AMI with EBS backed root device, you may opt for --no-reboot, but AWS warns about this. It does not guarantee integrity of the file system. If it's really busy instance and heavy RW operations going on, you may get a corrupted image.
Instance Store, no reboot: Creating an instance store backed image never required reboot to me. It's three simple steps -- bundle-image, upload to S3, and register the image without any rebooting in this whole process.
It is my opinion that No Reboot should prevent the image creation from rebooting.
If you are the api user, it also provides argument --no-reboot to do it.
Related
I have a golden image pipeline running without problem backed by an EBS volume, but trying to create the same for an instance store backed ami seems to always produce the same error. The issue is that the imagebuilder pipeline continuously attempts to tag a non-existent EBS volume and therefore fails;
Reason for failure:
You cannot specify tags for EBS volumes if there are no EBS volumes being created by the request.
The base image is ami-08d82c356d670cf9c which has the root device type INSTANCE-STORE, and there are no tags applied anywhere in the pipeline (not in the configuration, distribution, recipe or infrastructure). There is little documentation regarding a golden image using instance storage and any attempt to create one results in the same failure.
Does anyone have an idea on where this application of tags is taking place in the process in order to avoid it?
Thanks
Confirmed with AWS that Image Builder does not support the use of AMIs backed by instance store, as they use ec2:CreateImage which does not support it, and also requires the instance to be shut down to create an image.
I have a Windows 2008 EC2 instance to which I have done some customizing on the EBS boot drive.
I started the instance as m1.small (or m1.large) and the instance storage does not appear as an additional drive.
I've read that the -b switch in the ec2-run-instances command allows you to create mappings for the ephymeral instance storage. The ec2-run-instances command creates a new instance, however, in my case, the instance already exists and therefore I start it as ec2-start-instances, which does not have a -b switch for ephymeral instance storage.
Is there any way I can get to the ephymeral instance storage that comes with an m1.small instance for my existing EBS-booted instance?
UPDATE: It seems that nowadays (Feb 2015) Windows machines mount ephymeral instance storage in the Z: drive.
I'm afraid this functionality isn't available (yet) for Amazon EC2, but it's a very good question in fact - the common answer used to refer to the explicated launch time requirement, see e.g. ec2-modify-instance-attribute:
Note
If you want to add ephemeral storage to an Amazon EBS-backed instance,
you must add the ephemeral storage at the time you launch the
instance. For more information, go to Overriding the AMI's Block
Device Mapping in the Amazon Elastic Compute Cloud User Guide, or to
Adding A Default Instance Store in the Amazon Elastic Compute Cloud
User Guide. [emphasis mine]
That hasn't been that much of an issue in the past, but given the recent introduction of 64-bit ubiquity implies a significant improvement of vertical scaling versatility (see EC2 Updates: New Medium Instance, 64-bit Ubiquity, SSH Client), this is suddenly a topic indeed - your question yields even more questions in turn:
What happens for the converse case, i.e. when I start a sufficiently large instance with lots of ephemeral storage and scale it down (and possibly up again) thereafter?
In case the initial block device mapping is retained somehow, should we always start with a large instance therefore? (I actually doubt that this is the case though.)
This question can only be addressed by the AWS team I guess, so you may want to file a support request or relay the question to the Amazon Elastic Compute Cloud forum at least.
I think what you're asking (but correct me if I'm wrong) is "how do I add additional storage to an EC2 instance?".
In which case, the answer is:
Select the Volumes panel in the AWS console and create a new volume of the size you want, making sure it's in the same Availability Zone as the instance you want to attach it to. Then select that new Volume, and click 'Attach' - select the instance you want to attach it to, and click OK.
Now log-on to the instance, and in Computer Management select the Disk Management plugin, format the new unassigned partition, and give it whatever drive letter you wish. It will then show up in Explorer as a standard Windows drive.
What is the different between starting an AWS Image and Instances?
Example:
I do notice when I am running AWS image using boto, I can only stop the Image while running AWS instance using boto, I can only terminate.
Think of an EC2 instance as a single running server with CPU, memory, hard disk, networking, etc. Any changes you make to that instance affect only that instance.
Think of an AMI (Amazon Machine Image) as an exact copy of the root file system that gets copied to the hard disk when you start a new instance. The AMI is a hard disk sitting on a shelf. You make an exact copy of the hard disk on the shelf, install the new hard disk in a server, and turn the server on. You can do this for as many servers as you'd like to start without affecting the master copy.
The AMI defines the initial state of each instance. Each instance changes as it runs, but you can never change the original AMI once it has been created (other than to delete it).
There are more details that refine this conceptual model, but that's the basics.
Specific to the wording in your question:
Sometimes we say we're "starting an AMI" sometimes we say we're "starting an instance". We mean the same thing. We're really starting an instance using an AMI as the template.
We never say we're "stopping/terminating an image" or "stopping an ami" as, once started, it's really the instance that's running.
You can have one or more instances running that are derived from an image (AMI). Here is a good little tutorial, that's a bit old mind you, talking about how you can convert an Instance to an AMI ... which you can then redeploy one or many times:
http://webkist.wordpress.com/2010/03/16/creating-an-amazon-ec2-ebs-ami-from-a-running-instance/
What is an AMI: Amazon Machine Image
http://en.wikipedia.org/wiki/Amazon_Machine_Image
Technically, you can't start an AMI. You can start an instance that is derived from an AMI.
I am trying to understand how Amazon implements the auto scaling feature. I can understand how it is triggered but I don't know what exactly happens during the auto scaling. How does it expand. For instance,
If I set the triggering condition as cpu>90. Once the vm's cpu usage increases above 90:
Does it have a template image which will be copied to the new machine and started?
How long will it take to start servicing the new requests ?
Will the old vm have any downtime ?
I understand that it has the capability to provide load balancing between the VMs. But, I cannot find any links/paper which explains how Amazon auto scaling works. It will be great if you can provide me some information regarding the same. Thank you.
Essentially, in the set up you register an AMI, and a set of EC2 start parameters - a launch configuration (Instance size, userdata, security group, region, availability zone etc) You also set up scaling policies.
Your scaling trigger fires
Policies are examined to determine which launch configuration pplies
ec2 run instance is called with the registered AMI and the launch configuration parameters.
At this point, an instance is started which is a combination of the AMI and the launch configuration. It registers itself with an IP address into the AWS environment.
As part of the initial startup (done by ec2config or ec2run - going from memory here) - the newly starting instance can connect to instance meta data and run the script stored in "userdata". This script can bootstrap software installation, operating system configuration, settings, anything really that you can do with a script.
Once it's completed, you've got a newly created instance.
Now - if this process was kicked off by auto-scale and elastic-load-balancing, at the point that the instance is "Windows is ready" (Check ec2config.log), the load balancer will add the instance to itself. Once it's responding to requests, it will be marked healthy, and the ELB will start routing traffic.
The gold standard is to have a generic AMI, and use your bootstrap script to install all the packages / msi's / gems or whatever you need onto the server. But what often happens is that people build a golden image, and register that AMI for scaling.
The downside to the latter method is that every release requires a new AMI to be created, and the launch configurations to be updated.
Hope that gives you a bit more info.
may be this can help you
http://www.cardinalpath.com/autoscaling-your-website-with-amazon-web-services-part-2/
http://www.cardinalpath.com/autoscaling-your-website-with-amazon-web-services-part-1/
this post helped me achiving this
Have a read of this chaps blog, it helped me when I doing some research on the subject.
http://www.codebelay.com/blog/2009/08/02/how-to-load-balance-and-auto-scale-with-amazons-ec2/
Or is it absolutely necessary to have an EBS backed storage? Does anyone have manuals/Howtos?
I am following the manual given on this site.
You can create an AMI from either an EBS or S3-backed running instance. The simplest way is to use the AWS Management Console to select the instance and click 'Create Image' from the Instance Actions menu.
This will create either an EBS or S3-backed AMI, depending on the type of instance.
Be aware that creating an AMI from a Running instance is inherently potentially unsafe - the storage is not imaged as a hard 'point-in-time' snapshot, so changes to the filesystem whilst the image is being created may not be recorded, and may even result in a compromised image. You should quiesce the OS as far as possible before starting.
Note also that your instance will reboot during the image-creation process, so make sure you're prepared for any temporary loss of service from the VM.
If you bundle a Windows EBS instance while it is running, its Administrator password will be reset by Amazon's rebundling tools - so you'll have to use the EC2 "get Admin password" function with instances launched from the new AMI.
If you stop your Windows instance before rebundling, its Administrator password will remain intact through the rebundling process.
I don't know if this is documented anywhere, but it's certainly been my experience with Windows 2003 instances.
you will to refer the manual for the three commands:
ec2-bundle-vol, ec2-upload-bundle, ec2-register.
Keep at hand your private and certificate key (eg. pk.pem, cert.pem files) and your access and shared key. Download the ec2 ami tools and setup the environment variables for the ec2 ami tools. This site might give you the details on how to bundle the volume, create the images, upload them to S3 and finally register it as your own ami.
http://alestic.com/2009/06/ec2-ami-bundle
It is possible to create an AMI from an EBS running instance using the AWS management console. as mentioned by Eight-Bit Guru by clicking 'Create Image' from the Instance Actions menu.
For the S3 backed instance it is currently not possible without bundling the instance.
If you are using a linux ami then you have two ways as explained in this guide:
Creating an AMI from S3 backed instance - For Linux
For windows based S3 backed instance you can follow other guide
Creating an AMI from S3 backed instance - For Windows
Hope this will help for creating an AMI for S3 backed intances.