My questions is pretty straightforward, I have an Amazon Elastic Beanstalk application and I want to attach an existing EBS instance everytime that my elastic autoscaling creates a new instance.
How can I do that?
THanks.
If you are talking about the "main" EBS from which your app instance was booting, then as far as I know, the elastic load balancer destroys that EBS when the instance is terminated. It isn't saved. It sounds like this is what you are describing.
If you are talking about a different EBS which is attached to the instance in addition to (and after) the one from which it is booting, then it should be easy enough to re-attach it to the new instance by using elastic beanstalk configuration files. I assume this kind of EBS could be saved. It's an interesting solution for ensuring that data persists between instances in some ways, but like you said, an EBS can't be mounted by multiple instances simultaneously.
I think most people use S3 or a separate instance(s) with an NFS (that's what I do) to keep data that shouldn't die with an unhealthy instance.
You need script that will on bootstrap of new ec2 instance will attach ebs. You need to add yo your bundle .ebextentions, create config file which will contains command for mounting of ebs to instance.
Following links will be useful:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html
http://www.hudku.com/blog/configuration-setup-customizing-aws-elastic-beanstalk/
Related
I am deploying Wordpress site using LAMP AMI on EBS-backed EC2. Wordpress database will be stored in EBS.
Amazon keeps on updating base configuration of EC2 for better performance & security.
If I have to upgrade my EC2 then my EBS will get deleted.
How can I ensure that my EC2 gets updated without affecting my EBS?
EBS Snapshot is not of any help as new EC2 already has a EBS attached.
Do I have to always migrate my Wordpress site using backup & do this upgradtion?
Amazon EC2 instances use EBS volumes as their disk volumes. They are populated from an Amazon Machine Image (AMI) when the instance is launched.
When AWS releases updated AMIs, any new instance launched from the AMI will contain the updated disk content. However, existing EC2 instances will not be changed (since they have a copy of the AMI at the time that the instance was launched).
You can also change the Instance Type of an EC2 instance, which gives it different hardware (CPU, Memory). This can be done by stopping the instance, changing the type and starting it again. This will not affect the contents of EBS volumes.
If you wish to keep your instance "current", simply run sudo yum update (Linux) or run the Windows Update utility to update your operating system and associated utilities rather than launching a whole new instance.
I am looking to migrate an application from one vpc to another. Currently, the application's ec2 instances utilize a nfs which I created from another ec2 instance and ebs volumes. These application related instances (web and app) as well as the nfs instance reside in one VPC (Let's call it VPC "A").
My question is how would I go about transferring the ebs data from the existing nfs in VPC "A" into an efs in VPC "B"? Additionally, the rate of data transfer is not relevant, so the file system's performance mode is just defined as general purpose. Thanks!
Not sure if this answer was technically possible at the time the above answer was given, but a much easier way to achieve a solution providing that the asker did not to run both applications concurrently (ie. duplicate the data instead of just switch the VPC it was available from).
My company was switching to a new VPC, so I merely wanted to make the data available in the new VPC. Rather than copy it to EBS, unmount, remount, copy to EFS, I switched the mount points as described here:
http://docs.aws.amazon.com/efs/latest/ug/manage-fs-access-change-vpc.html
IMO this is much simpler if you don't need to actually duplicate the data.
For backing up the data, AWS has a workflow outlined:
http://docs.aws.amazon.com/efs/latest/ug/efs-backup.html
It sounds like your requirement is to transfer the contents of an Amazon EBS volume in one VPC to a different VPC. It is unclear whether your NFS server is hosted from EC2+EBS, or whether it is running from Amazon EFS. I'll assume it is EC2+EBS.
A few different options for you (pick one!):
Create an AMI: Create an AMI of the Amazon EC2 instance running the server. Then launch a new instance in VPC B using that AMI.
Move the disk: Turn off the EC2 instance. Detach the EBS volume, the attach it to a different instance running in VPC B. Configure as necessary.
Use an EBS Snapshot: Snapshot the EBS volume that holds the data, create a new EBS volume from the snapshot (in the desired AZ), attach the EBS volume to the EC2 instance in VPC B.
However, if your server is running on Amazon Elastic File System (EFS), then you would need to copy the data to an EBS volume, detach the volume and attach it to an instance in the VPC B, then copy the data from the EBS volume to a new EFS share in VPC B.
I had to stop my m3.medium EC2 instance from the AWS console to resize it to m3.large. However, after it stopped, it automatically created a new instance.
Any idea why this is happening? It caused some big troubles for me.
Your AutoScaling group with minimum size = 1 spun up a new instance because there were no instances in the 'running' state available to respond to requests, particularly health checks. Your instance was deemed 'unhealthy' and replaced by the ASG.
If your instance storage was ephemeral, I'm afraid it is gone forever unless you recently saved an AMI. If your instance storage was backed by EBS, you can recover it by attaching the EBS volume to a new instance.
In the future, consider configuring your autoscaling group's launch configuration to have everything you need ahead of time, by either bootstrapping the instance or by baking an AMI.
For 'bootstrapping' an instance:
Create a new launch configuration with a standard AMI avaialble from Amazon.
Add user data to the launch configuration to handle installation and configuration of your desired programs.
For 'baking' an AMI:
Install your desired programs and configuration on a new EC2 instance.
Take an image (AMI) of that EC2 instance.
Use that image in your new launch configuration.
Manually working on an instance within an ASG and expecting the instance to persist indefinitely is dangerous, as you've just discovered.
Further Reading:
EC2 Documentation - AutoScaling Health Checks
EC2 Documentation - Amazon Machine Images
I have a running Amazon Elastic Beanstalk environment.
Sometimes it runs into problems and the load balancer kills my ec2 instance and starts a new one. I don't know how to create an "AMI" or template so the load balancer starts a new ec2 instance which is exactly like the one that I have configured.
Also, I attached some EBS blocks and I want to be able to create a new instance with a EBS block attached.
How can I do that?
I read the documentation but I cannot find what I need, and I think this is a common scenario.
Thanks
You should use .ebextensions to configure your Elastic Beanstalk instances. http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers.html
These configurations and dependencies are handled on instance start-up.
I have an Amazon EC2 instance with AutoScaling and Load balancer.
I deployed an application and configured Apache.
Everything went fine but Amazon for some reason terminated my instance and started a new one. I lost all the code and configuration there?
What should I do?
Maybe attach a EBS volume and deploy everything there? But my Apache server is installed on the main volume.
Can anyone help me?
If you are using autoscaling, instances will be terminated if they become unhealthy. In order to use autoscaling effectively, you should not keep any persistant data on the instance itself. This is called Shared Nothing architecture.
What you want to do, is create an AMI that has all your application and or tools to bootstrap your application. You would use this AMI as part of the launch configuration for your autoscale group. So if a new instance gets launched, either due to failure or needing to scale, your application will be back up without any interaction from you.