We needed to change the DB tier, but when doing it via the EB console it gave an odd error message...
Updating RDS database named: ******** failed Reason: Cannot upgrade mysql from 5.6.22 to 5.5.41
However, I managed successfully to change the DB tier via the RDS console instead.
The problem is, is that the EB console still shows the old DB tier, whilst RDS now shows it on the new one!
It has upgraded, but how do I get the EB console to show the correct information?
Currently you can only specify the DB version on environment launch in elastic beanstalk. You may do this via the console or using the DBEngineVersion option setting. You cannot update it on an existing environment.
Since you changed the value out-of-band on the RDS directly, Elastic Beanstalk still thinks that the value hasn't changed. Hence it will continue to show you the old version. Your environment should continue to function correctly though. Let me know if you are facing any issues.
One caveat with making the change out-of-band is that if you save the environment configuration, clone or rebuild the environment you will get the old database version again on the new environment. So your change is not persisted across these operations.
Related
I'm building a simple web app on Elastic Beanstalk (Dockerized Python/Flask). I had it running successfully on one AWS account and wanted to migrate it to a new AWS account, so I'm recreating the Beanstalk app on the AWS console and trying to deploy the same code via eb deploy.
I noticed that when pushing a configuration update, Beanstalk will attempt the change but then roll it back if the app fails to start with the new change. This is true for several different kind of changes, and I need to make multiple to get my app fully working (basically I'm just recreating the Beanstalk settings I already have on my other AWS account):
Need to set a few environment variables
Need to set up a new RDS instance
Need to deploy my code (the new application version has been uploaded, but the deployed application version is still the old "sample application" that it started with)
All 3 must be done before this app will fully start. However, whenever I try one of these on its own, Beanstalk will attempt the change, then notice that the app fails to startup (it throws an exception on startup) and then beanstalk rolls back the change. The config rollback occurs even though I have "Ignore Health Check: true" under the deployment settings. (I would think at the very least it let me force update #3 above but apparently not.)
So I'm basically stuck because I can't do all of them at once. It there a way to --force a configuration update, so that Beanstalk doesn't rollback no matter what happens?
My other thought was that I could potentially make all the edits at once to the JSON config, but I figured that there must be a way to force config changes so people can respond quickly in a crisis without these well-intentioned guardrails.
Thanks for your help!
I've got development and production instances in EC2. I've been updating my app in Visual Studio 2019 and redeploying it to the dev instance, then creating an AMI of that instance and using that image to update the production instance(s).
Suddenly my app no longer updates when I deploy to the dev instance. The logs all show the update was applied, but when I look at the files on the server they have not changed for days. I suspect I may be using AMIs incorrectly, but I'm not sure what I'm doing wrong.
How do I get my updates to show again?
You are facing the issue because creating an AMI from running environment isn't the right approach since EB runs several scripts under the hood to attach instances to that particular environment.
Note: Custom AMIs are ideal only when you're installing a lot of dependencies or software that you want to be baked into your AMI so subsequent deployments go through quick. Here's the documentation that walks you through the steps, and here's the summary of the steps:
The best approach would be to launch a stand alone EC2 using an EB
AMI as base (ideally an AMI with HVM virtualization).
Connect to the instance with SSH or RDP.
Perform any customizations you want.
(Windows platforms) Run the EC2Config service Sysprep. For
information about EC2Config, see Configuring a Windows Instance Using
the EC2Config Service. Ensure that Sysprep is configured to generate
a random password that can be retrieved from the AWS Management
Console.
In the Amazon EC2 console, stop the EC2 instance. Then on the
Instance Actions menu, choose Create Image (EBS AMI).
I would like to make a step towards a no-downtime continuous deployment of my application.
I have an app running on an EC2 instance that connects to the aurora database. During the deployment I need to run the database migration scripts and update the app running on EC2. How can I update both of them without causing any down time? I probably can configure Elastic Beanstalk/CodeDeploy to update the EC2 instance in such a way that for a while I will in fact have 2 instances of my app running on 2 separate EC2 instances, but that still gives me only one instance of the database. If I run my migration scripts, this may assassinate one of the instances of my application and if the deployment for some reason fails, I might not be able to revert the changes done to the database.
So basically the question is: what is the right way to apply the SQL migration scripts without causing any downtime?
That would depend on your specific situation and type of DB migration. One route you can follow, taken directly from AWS documentation is :
Clone your Aurora DB, using AWS provided API
Apply your migration script to the new DB
Deploy your new source code version to a new Elastic Beanstalk environment
Test your new source code with new DB
Swap the two environment CNAME using the api provided by AWS or from your DNS, you may want to synchronize the data changes from old DB to new DB before doing so
The Elastic Beanstalk environment is running on t1.micro & db.t1.micro, where we tried to update the rds to db.m1.small instance. This configuration change has been made on the Elastic Beanstalk and it is on updating state for around 4 hours, we thought AWS stuck somewhere internally. In this meantime, the AWS has not updated the Trace information. In order to retain the environment back (rollback of configuration update operation), we have aborted the environment configuration update. This has ended up on invalid state with the health turned to grey. This because AWS will not allow creating t1 environment nowadays, however, the rollback is trying to bring back the older t1 setup with an error--> RDS does not support creating a DB instance with the following combination: DBInstanceClass=db.t1.micro, Engine=mysql, EngineVersion=5.6.37, LicenseModel=general-public-license. For supported combinations of instance class and database engine version.
Any suggestion to bring back the environment to green would be really helpful.
Yes, with the source of the snapshot we could able to create a new EBS instance. The only problem we faced during the snapshot to clone an instance is the application level configuration file change not done. BTW there is no proper root cause for the AWS DB upgrade failure from AWS.
I am new to AWS EB and I am trying to figure out how to backup and restore an entire EB environment. I created an AMI based on the EC2 instance generated by EB, and took a snapshot of RDS, also created by EB.
The problem I have is, how do I restore it, assuming that this is the correct approach of backup. Also, I am doing it manually, shouldn't there be an automated way of doing this within EB? By the way, when I created the AMI, it destroyed the source and the EB just created a new EC2 instance without all my changes.
How do I save & restore configuration changes to my application that impact both filesystem and database?
Unfortunately, Amazon AWS Elastic Beanstalk (EB) does not support restoring databases that contain live data, if those databases were created with EB. If you reload (AKA AWS "deploy") the EB saved configuration, you get a blank database!
I called them and they told me to create the RDS DB separately and update the application code to connect to the DB once you know it's name. If you restore the RDS DB it will have a new name too! So you have to update your code again to connect to it.
Also, if you code and environment is fine, but you want to restore your database, again it will have a new name and you will need to change your code.
How to change your code easily and automatically deploy it is a whole other question for which I don't have an answer yet.
So basically the RDS DB provisioning within Elastic Beanstalk has very limited uses, maybe coding and debugging and testing, but not live production use. :(
This is as of Jan 2015.
First go into your EB environment and save the current config. You should go to a running EC2 instance created by EB and make an Image. Then use that new AMI ID by going to the EB configuration and setting it. It will rebuild the environment tearing down all running instances and creating new ones.
For your RDS instance you should make a backup and restore with a new instance name as the docs say you will lose it if the environment is destroyed. You should probably just manually set the environment variables like RDS does and setup the proper security groups between RDS and EC2.
One option I think could work is just renaming the RDS instance name as the environment seems to break and then destroy the environment and create a new one with an attached RDS instance and then destroy that one and rename the old one to the new one's name which may work.
As always make proper backups before proceeding with any of these ideas.