I have received an email from AWS that states
We have important news about your account (AWS Account ID: XXXXX). EC2
has detected degradation of the underlying hardware hosting your
Amazon EC2 instance (instance-ID: i-XXXX) in the eu-west-1 region. Due
to this degradation, your instance could already be unreachable. After
2017-05-25 10:00 UTC your instance, which has an EBS volume as the
root device, will be stopped.
I'm actually using Elastic Beanstalk with a load balancer with an elastic IP address on what is currently the only instance running (manually associated). In addition I have a reverse DNS for email purposes.
The email continues to say the following...
You may still be able to access the instance. We recommend that you
replace the instance by creating an AMI of your instance and launch a
new instance from the AMI. For more information please see Amazon
Machine Images
(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) in the
EC2 User Guide. In case of difficulties stopping your EBS-backed
instance, please see the Instance FAQ
(http://aws.amazon.com/instance-help/#ebs-stuck-stopping).
So how do I get Elastic Beanstalk to re-provision to new hardware?
Some options seem to be...
rebuild environment
save configuration -> terminate -> load configuration
clone environment -> manually change DNS -> Terminate old environment
'Terminate'environment -> 'Restore terminated environment'?
I'm not sure which variant would restore the environment, in particular it would be ideal if I don't loose the hostname / reverse DNS stuff that was done for email (SNS?) configuration.
It would be nice if I kept all of this (I don't care about the EC2 instance or data - the data is held in MongoDb external to all of this) ...
EC2 configuration (i.e. hardware box size, VM parameters etc)
Security Groups
Load balancer
Elastic IP associated to EC2 (easy enough to do manually after)
Hostname (whatever is required for the reverse DNS)
Thoughts would be appreciated! - It's a shame their email / documentation only discusses EC2 and not beanstalk configurations.
Just terminate the instance and let Elastic Beanstalk automatically spin up a new one. Any changes you are making to your EC2 instances in your beanstalk environment should be done through .ebextensions configuration files (you aren't making changes directly over ssh, right?) so you don't need to worry about "saving" your EC2 setup via creating an AMI.
As for all the items you listed that you need to save, those are all part of the EB environment configuration, not part of the EC2 instance that is being retired.
A load balanced Elastic Beanstalk environment is configured to terminate and create new EC2 instances as needed. There's no need to completely rebuild/replace your entire EB environment just because you need to replace one of the EC2 instances.
Related
I'm new to AWS and having a web server environment on elastic beanstalk with EC2 (t1.micro) with RDS (db.t1.micro). Now the db.t1.micro instance is deprecated, no more new instance can be created and no support in near future.
I would be helpful if anybody refers me steps to do create the t2 clone of the machine and switch over (Or) how to handle the depreciation of the instance.
Change Instance Type: You can change the Instance type by following the AWS documentation here
Next, Creating RDS instance in the Elastic Beanstalk environment is not ideal for production environments, because the lifecycle of the database instance is tied to the lifecycle of your application's environment. Hence it is always recommended to create RDS instance outside of the Elastic Beanstalk environment and configure your Elastic Beanstalk application to connect it on launch, which will provide the benefits of performing blue/green deployments, and tear down your Beanstalk environment without affecting the database instance. Refer to the documentation here to know more information.
For now, if you would like to modify the RDS instance type, you can do so by going to the RDS section in Configuration tab.
I have created a new Elastic Beanstalk environment with the source of the "db.t1.micro" snapshot, within the VPC. This helped me to launch the clone. Once this is done I have to swap the cname with the t1 and t2 setup. The new instance is up and running with t2 configuration.
You can add an RDS instance to an Elastic Beanstalk environment, but there is no option when you do this to have the RDS instance be encrypted. You can modify the RDS instance after it's launched, but you can't modify whether or not it's encrypted.
The amazon docs discuss creating an independent RDS instance and modifying security groups but this seems antithetical to Elastic Beanstalk.
Is there a way to get an encrypted RDS instance that is attached to an Elastic Beanstalk environment?
I do not recommend to create RDS instances from EB configuration panel. For most of the cases that may happen on your setup, it may won't be an issue, but when it comes to serious production setup, it may become a serious problem. RDS instances created from EB config panel are kind of merged to EB environment they were created in. It means that every time you delete your environment, system forces you to remove RDS instance as well. And that's not the way you want it to be, as environment should be the part you're not afraid to delete at any time.
Let's say you want to update your Multicontainer Docker setup, because there's an update going on. You would just clone current environment, then switch url and you're done. With RDS instances created as described above, you simply can't.
My advise is to create separate RDS instance, then add specific security group for this instance, and finally, add this security group in Configuration -> Instances -> EC2 security groups for EB environment, so it have access there. With that you can create encrypted instance of database and you can easily switch environment with no risk your database will be thrown away.
And if you're ok with standard environment variables for RDS, like RDS_DB_NAME etc. you can add the same in Configuration -> Software Configuration -> Environment Properties. That's how we do this for each production and serious server we're taking care of at work.
Yes. There is currently the following workaround:
Create a new encrypted RDS instance
Take a snapshot of this instance
Add an RDS instance to your Elastic Beanstalk environment based on this snapshot. The snapshot is encrypted, and thus the database created based on it is encrypted as well
I'm using clamscan to check content on my elastic beanstalk instance, however, I'm having an issue where AWS either moves the instance to another IP and then clam scan is suddenly uninstalled. Is there a good way to prevent this from happening?
Thanks.
Alex
If AWS is "moving the instance to a new IP" what is actually happening is that Elastic Beanstalk is deleting your instance and spinning up an entirely new instance. I assume you manually configured ClamAV on your EB EC2 instance via SSH, which is the wrong way to configure EB instances. You even get a warning on the screen when you SSH into the instance telling you not to make any changes to the server because they won't be persisted across EB instances.
You have to use the appropriate methods provided by Elastic Beanstalk to configure your instances so that Elastic Beanstalk knows how to configure new instances when it automatically creates them for you. The method for doing this is documented here.
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.
My goal is to automatically assign an elastic IP to an auto-scaled EC2 instance.
I have done the following:
- Configured EC2 instance w/ startup script to assign IP
- Configured launch config and auto-scale group per spec.
The issue is that when deploying the auto-scaled launch config I lose the ability to allow it to automatically assign a public address (at first) before it picks up the elastic IP assignment.
When I deploy the AMI manually, provided that I check that "assign public IP address" box, the instance will deploy, temporarily assign the xxxx.amazon.xxxx address, then roll over to my elastic IP assignment.
however..
when deployed through the auto-scale command line utilities (as-create-launch-config + as-create-auto-scaling-group) the IP will not work. I feel it could be fixed if there was an option when setting up the launch config to temporarily grab a public IP in order to communicate with the amazon API to pull the elastic assignment.
I greatly appreciate your help!
You may want to use cloud-init to run a command on the local autoscaled server that attaches the EIP. Here is an example of a local command running on a server on first boot: http://cloudinit.readthedocs.org/en/latest/topics/examples.html#run-commands-on-first-boot
In that local command you could use amazon's built in tools to associate the address: http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-AssociateAddress.html
In the launch config, add that cloud-init syntax to the user-data attribute as base64 encoded and all future autoscaled instances will do exactly what the cloud-init states it will do.
I usually base64 encode by doing:
base64 <filename>