I just started hosting a legacy classic ASP app on AWS Beanstalk. When I created the environment, I used RDP to remote into the Windows machine and configure IIS with classic ASP, server includes etc.
Funny thing (or not) is that sometimes the Autoscaler adds an instance (scales up) and then removes an instance (scales down). If it removes my originally configured server, I loose the changes I made via RDP and my website goes down.
Is there a way to specify how the scaled EC2 instance is configured?
Many thanks,
Thanks for the comments that set me onto this. I used the AWS console for all of this and solved my issue.
From the EC2 instance page, create an AMI of your configured EC2 instance
Under EC2 > Auto Scaling > Launch Configuration create a new launch configuration using your AMI. You will see a previously created configuration created by Beanstalk but you are creating your own.
Under EC2 > Auto Scaling > Auto Scaling Groups you will see a group already created by Beanstalk. Edit this Auto Scaling group and specify your new launch configuration.
Hope this helps,
Related
The Elastic Beanstalk docs say:
Web server environments have ... one of the following two resources.
AWSEBAutoScalingLaunchConfiguration (AWS::AutoScaling::LaunchConfiguration) – The launch configuration attached to your environment's Auto Scaling group.
AWSEBEC2LaunchTemplate (AWS::EC2::LaunchTemplate) – The Amazon EC2 launch template used by your environment's Auto Scaling group.
AWS is in the process of deprecating Launch Configurations, as Launch Templates are strictly more featured. In particular, AWS has sent a notice to customers saying:
After December 31, 2022 no new Amazon Elastic Compute Cloud (Amazon EC2) instance types will be added to launch configurations.
How do I convert an Elastic Beanstalk environment that is currently using a Launch Configuration to use a Launch Template instead?
I have contacted AWS support about this issue. As of December 31 2022 AWS will deprecate launch configurations. So we have to use launch templates instead of launch configurations. And this is their response.
Firstly, the current guidance is that no action will be needed on your
end regarding the launch configuration deprecation. Beanstalk will use
launch configurations when needed, and will automatically use launch
templates for new instances and newer features as needed. However, I
will be sure to update you if this guidance changes.
However, if you wish to change your Elastic Beanstalk environments to
make use of launch templates instead of a launch configuration, I
suggest to enable the 'Disable IMDSv1' option in your EB environments
configuration [2]. IMDS is instance metadata service and is used by
code to access instance metadata. Disabling IMDSv1 requires using
Amazon EC2 launch templates. When you configure this feature during
environment creation or updates, Elastic Beanstalk attempts to
configure your environment to use Amazon EC2 launch templates (if the
environment isn't using them already).If you have custom scripts which
communicates with the IMDSv1 endpoint, then you will need to ensure
those are migrated to the newer IMDSv2 [3].
Additionally, please note that this may introduce some downtime while
the configuration changes are being applied to the environment. I
recommend creating a new environment and performing a Blue/Green
deployment [4] to minimize this potential downtime. Please test this
is in your non production and proceed to production based on the
results in non-production.
Please refer the provided documentation and let me know if you need
any help.
References:
[1] Managing environments - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.html
[2] Configuring IMDS using the Elastic Beanstalk console - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-ec2-imds.html#environments-cfg-ec2-imds.console
[3] IMDSv2 - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
[4] Blue/Green deployments with Elastic Beanstalk - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html
I was in this exact position. I connected with AWS support and the answer I received is that launch configurations being used in Elastic beanstalk apps will be migrated automatically behind the scenes. So if your only launch configurations are generated as part of an elastic beanstalk then you have nothing to do, and the notice only applies to configurations created outside of Elastic Beanstalk.
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'm new to AWS, and I want to deploy a web application on an EC2 instance,
So far I've tried Elastic Beanstalk, but AWS always requires me to create a new Environment for the application instead of letting me choose an existing EC2 instance that I've created before.
Actually my main purpose is to set a policy group that allow HTTPS access, and idk how to set it to the "Environment" instance.
Any help is greatly welcome. :)
That is not currently viable, as you'd need to set up an AMI based on your instance and use a custom AMI for beanstalk, and that is not a trivial task. If you need to run a custom environment in Elastic Beanstalk, using Docker would be much easier.
But none of that is required to set a security group allowing HTTPS, you can configure security groups and HTTP/s listeners for ELBs on you Environment configuration.
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.
I need to use on Elastic Beanstalk a Java application written for Glassfish server.
Beacuse of Amazon doesn't let me choose an AMI with Glassfish, I choosed one with Tomcat and i modified my application to work properly on Tomcat.
Now, I've seen I also needed to use a Sun JDK, while by default Elastic Beanstalk AMI comes with openjdk. I googled a lot, finding some (not so many resources) interesting posts like this answer on StackOverflow
What I can't understand is this part of the answer:
Create your custom AMI from a running instance of Amazon's beanstalk
AMI that you manually launch from EC2, NOT one that was launched from
starting your application through beanstalk.
So, my question is: does anyone how to use a custom AMI with Glassfish on Elastic Beanstalk?
If it's not possible, can someone explain me how to create the custom AMI?
Thanks,
Andrea
That answer just means "Don't start a beanstalk application and cut an AMI directly from one of those instances. Instead, launch an instance based on the beanstalk AMIs (which are available in the public AMI listing)." I.e., use one of these; note there are 84 of them:
Cut your own private AMI when you're done configuring that instance, and specify it in your beanstalk environment.
I personally found the selected answer confusing for me to follow, maybe because I am still climbing up the AWS learning curve. Maybe this answer will help other newbies. Having just figured out how to successfully launch an Elastic Beanstalk instance with my own custom AMI, what I believe this quote is saying, is to do the following totally non-obvious steps which just worked for me:
Go to the EC2 services (not Elastic Beanstalk services) and launch an instance based on the Elastic Beanstalk AMI that you would like to use as a starting point for your custom AMI. You will throw this away in a minute.
Select the instance and choose "Create Image / EBS AMI". Once created, you can delete the temporary EC2 instance you created. It's only purpose was to create the custom AMI.
Now go to Elastic Beanstalk services and edit your configuration to reference your custom AMI.
#Danger It would speed up the scaling up process.
I'm using a docker app on EB but "docker pull" from Docker Hub is so slow so when all instances are unhealthy my site would be down in 15-30 minutes. Create a customize AMI and pull a base Docker image will save time.