If I change the default "t1.micro" selection to "t2.nano" it throws a bunch of errors telling me I can only run this environment in a VPC. I see I have a VPC running but I don't know how to put the elastic beanstalk environment in it.
Sorry if what you just read made you cringe. I'm new to this :(
Once an Elastic Beanstalk environment has been created, it can't be moved in/out of a VPC.
You can create a new Environment for the same Application, then at the "Additional Resources" step, tick the "Create this environment inside a VPC" box. An extra step will then be added to let you select the VPC & Availability Zone.
Related
I want to create 3 AWS Elastic Beanstalk instances and assign them to VPC with internal IP addresses. As you can see I have a default VPC created and running:
When I try to create a new AWS Elastic Beanstalk instance under the same Ohio region into the menu I see just see empty list of VPC:
Do you know what configuration I need to do in order to assign AWS Elastic Beanstalk instances to VPC?
EDIT:
I use this form to create VPC:
It seems like you did not select the Application Platform in Elastic Beanstalk's application creation process.
Try picking a platform before configuring more options.
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.
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.
I created an Elastic Beanstalk environment with a VPC. Sometimes the environment will lock up on a code version deploy and have to be rebuilt. When this happens I lose my Elastic IP.
I tried disassociating the EIP before the rebuild, but it is still replaced. What can I do to make the EIP permanent!? (Yes, I need an EIP and a CNAME is not sufficient for my purposes)
Replace Root Volume
You can use the "Replace root volume" feature (available since Apr/2021).
From the CLI:
aws ec2 create-replace-root-volume-task --instance-id INSTANCEID
From the Console:
EC2 > Right click on instance > Monitor and troubleshoot > Replace root volume
Leave the snapshot ID blank.
If you spin up a elastic beanstalk environment in an VPC's subnet with an NAT gateway which already exists. I believe if Elastic beanstalk did not configure your EIP it should not automatically release it. Just saying that I have never experienced this issue you are raising here; My deployments never result in random crashes. You should check out why this happens and resolve that aswell.
I think this is maybe the difference between you and my setup: I configured elastic beanstalk in an already created VPC. I used this guide to create my VPC and subnets; maybe this is helpful for you too:
https://spinupwp.com/scaling-laravel-using-aws-elastic-beanstalk-part-2-setting-up-vpc-rds-elasticache/
What you can also do is a Green/Blue deployment on major software releases. You create a new EB environment you can copy the configuration of your current environment or with help of .ebextensions and hooks predeploy/postdeploy configure your environment for you. This will help you test/wait until the new deployment is stable and switch the DNS of your EB environments:
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html
I want to change my RDS Instance that is connected to my Elastic Beanstalk Application, from a db.t1.micro to a db.m1.small. If I go to my Elastic Beanstalk Application and go to "Configuration", I can only see the current settings, but I'm unable to change them.
I then went into the Console -> RDS -> Instances, and updated my Instance from the RDS Menu, and set it as a db.m1.small. On RDS it now says that it's an db.m1.small, however on the Elastic Beanstalk Configuration Page, it still says that the application is running a db.t1.micro instance.
So a few questions:
Did I upgrade my instance in the "correct" way? Or is there another way I'm suppose to configure my RDS Instance that is set up with my Elastic Beanstalk App?
Any ideas why the different pages are saying different configurations?
If RDS console says that the RDS instance type is m1.small then it has been changed to m1.small. The two pages are showing different values because beanstalk provisioned a t1.micro instance instance for you and hence thinks you have a t1.micro db instance. If you rebuild your environment then the new environment should have the same configuration and hence a t1.micro instance.
Changing it via the RDS console does not change the configuration on Beanstalk, hence you see different values.
However if the RDS instance was created via Beanstalk then the correct way to update your db instance type would be using Elastic Beanstalk option settings.
You can make the change using AWS CLI if not using the console.
http://docs.aws.amazon.com/cli/latest/reference/
Just run the following command:
aws elasticbeanstalk --update-environment --environment-name <your-env-name> --option-settings Namespace=aws:rds:dbinstance,OptionName=DBInstanceClass,Value=db.m1.small
Try the above command.
More information on update-environment via aws cli:
http://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/update-environment.html
Read more about option settings and ebextensions here.