I've setup the infrastructure to do an environment variable swap for blue/green deployment, but the way we have our Route 53 setup it isn't working.
Currently, we have the root A record pointing at the EBS Load Balancer, is this correct? I think it should be pointing directly to the EBS, but I don't know enough to know for sure. I didn't set it up, and I'm not sure why this configuration was selected.
Is my assumption correct, or is there a better way to set this up?
Any articles or answers would be very appreciated!
You can do the following for a blue/green deployment. From Route 53:
Click "Create record"
Select "Simple routing"
Click "Define simple record"
Leave the subdomain blank for the root record
Choose "A record - Routes traffic to an IP4 address and some AWS resources"
Under Value/Route traffic to select "Alias to Elastic Beanstalk environment"
Choose your region
Select the environment you wish the record to point to.
Click "Define simple record"
You can then create a new A record with a subdomain to point to the environment you would like to do the blue-green deploy with. Then in the Elastic Beanstalk console:
Select one of the environments
Click Actions
Select "Swap environment URLs"
Select the environment for you would like to switch URLs
Related
I'm trying to set up an Elastic Beanstalk applciatoin using HTTP2. To do this, I have created an ALB.
Target group:
Weird thing is that even I have setup the load balancer as shared in the Beanstalk configuration, an additional listener has been created:
This is the listner of the ALB:
That's the one being used by the environment, but I do not know how to change it back to the correct one. Any idea?
The instances never reach a healthy state. I'm starting my node application (using the fully managed solution) like this: .listen(PORT) where PORT is an environment variable set by AWS. It usually is 8080, in case it helps.
As I'm nearing the end of my project, I'm setting up duplicate environments to easily manage dev and prod.
The backend is a NodeJS docker that runs on EB. The admin panel is a webserver that runs on NodeJS. The EB instance runs on a domain name that I manage on Route 53 (for this example : https://www.myproject.com)
What works :
When I go to https://www.myproject.com, I see my admin panel. It is exactly the same as if I click on my EB URL (minus the SSL certificate stuff which doesnt work on that URL, only the domain name)
What doesn't work :
This exact same setup, but instead of associating it to a domain name, I associate it to a subdomain like https://dev.myproject.com . In route 53, I created an A record that points to the EB loadbalancer (exactly what I did for the other one) but it doesn't work (always returns "server IP address could not be found. / DNS_PROBE_FINISHED_NXDOMAIN". I also tried associating the A record with the EB URL (the one from the screenshot) but this doesn't work either (same result). Accessing that EB URL directly does work so at least I'm 100% sure the EB instance is OK and it's most likely a config within Route 53.
Recap
myproject.us-east-1.elasticbeanstalk.com is set up to redirect to https://www.myproject.com. The A record in Route 53 points to the load balancer of that EB instance. This works.
myproject-dev.us-east-1.elasticbeanstalk.com is setup to redirect to https://www.dev.myproject.com. The A record in Route 53 points to the load balancer of that EB instance. This doesn't work.
What could I be doing wrong? Any clues?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
We have a few MySQL RDS instances in West-1 (N. California) and wanted to create some reports using QuickSight. First issue was that QuickSight was only available in West-2 (Oregon) and did not show our RDS, so I created a read-replica database into West-2.
I was still not able to connect to my instance, and it showed the following error:
Connection failed. Make sure your instance is accessible from the appropriate Amazon QuickSight IP address range.
I had already created a Security Group allowing IP 54.70.204.128/27 in the inbound rules and applied it to my instance. What eventually allowed me to connect to the instance was to set the 'Publicly Available' field of the instance to 'Yes'.
However, my boss prefers it to remain 'No' and we were also able to connect to the non-public instance via DOMO using MySQL SSH connection method.
Is it possible to get the connection between QuickSight and RDS working without setting Publicly Accessible to Yes?
I created a support request with AWS about this, their answer is below. I will give it a try.
Hi Alistair,
Thank you for contacting AWS Premium Support. I am happy to assist you today.
I understand that you would like to connect to your Prod RDS database from QuickSight, but you getting an error: "Not Validated". You also would like to know if there is a workaround seeing that your RDS instance in not Publicly accessible.
Amazon Web Services offers a service called CloudFormation, this service helps automate certain processes.
This service will allow your RDS instance to connect to QuickSight through a custom NAT instance. Therefore you will not have to put your Data Base in a public subnet.
Attached is a CloudFormation template (NAT_RDS_Provisioning.template), after launching the CloudFormation stack [1] an instance and a security group will be created, you then enter the required variables.
This will then give access from the source address on the source port you define to the endpoint of the EC2 instance which will then allow QuickSight to access your RDS instance server without making your RDS instance public.
To launch this CloudFormation stack please see the steps below… Please keep in mind that the region you create this in must be the same region that your database resides in.
1. From your AWS console navigate to " CloudFormation "
2. Click " create stack ", you will then be asked to Select Template, you will then select " Design template".
3. Next to Parameters - click " Mappings ", at the bottom of that page you will see: Components and Template.
4. Select " Template " and copy and paste the provided script in there. (see attached: NAT_RDS_Provisioning.template)(Please use case link below signature)
5. In the top right hand corner you will see a refresh button, click to refresh.
6. On the top left there is a square with a tick inside (clicking this validates the template).
7. Once validated - click the little cloud with the arrow in it , this will create the stack.
8. You will be taken back to the select template page, click "next" in the bottom right corner.
9. Under Specify Details, name your stack and then complete all Parameters, info on parameters provided below:
9.1 Stack name (Example: NAT-RDS-QuickSight)
9.2 DestinationAddress - Add your RDS instance Endpoint here. (That way when a fail-over occurs the endpoint should be updated in 60 seconds maximum).
9.3 DestinationPort - The service remote destination port:
9.4 InstanceType - The EC2 instance class. (The size of the NAT instance will depend on the amount of data you want to pull into QuickSight)
9.5 KeyName - Name of an existing EC2 KeyPair to enable SSH access to the instance:
9.6 SourceAddress - The source range you want to allow access from: example 0.0.0.0/0.
9.7 SourcePort - The port the service must listen on:
9.8 Subnet - a Public Subnet that is in the same VPC as your RDS instance:
10. Click " Next "
11. On the Options page - complete the desired fields and click " Next " (Optional)
12. Review all information - (Confirm the details for your NAT EC2 instance)
13. Under template you will see "Estimate cost - click on cost to give you an idea of the monthly estimate to have this service running)
14. Then select " Create " in the bottom right hand corner.
15. On the main CloudFormation Page, click "refresh" You will the notice the status of your Stack being created.
16. If you navigate to your EC2 console you will notice your NAT instance running / creating.
Please ensure that the NAT instance has access to your RDS instance, this includes Security Group settings.
This should be done by including the IP address of the NAT instance in the Security Group of the RDS instance database.
You should then be able to access the EC2 IP address and port as setup, this will then forward traffic to your Database.
When creating the above you would have seen the estimate costs involved however I have added two more links below for some more information on this and also the cost calculator for you too.
Costs will be the same as an EC2 instance, this launches the AWS Linux latest standard AMI, and throughput will be determined by the instance class [2] & [3]:
[1] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.Walkthrough.html
[2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html
[3] https://calculator.s3.amazonaws.com/index.html
I hope the above information and solution is helpful.
Should you run into any difficulties with any of the above or if you are unsure of anything, please free to reach out to me and I will be more than happy to assist.
To see the file named 'NAT-RDS-Provisioning-Template.template' included with this correspondence, please use the case link given below the signature.
Best regards,
Delene T.
Amazon Web Services
See the provided template file content here: https://pastebin.com/m67sz4bR
Things have changed, luckily.
It is possible to connect Amazon QuickSight to a DB in RDS which is in a VPC, although the AWS docs are not clear about all the necessary steps.
Basically, follow the steps here,
https://docs.aws.amazon.com/quicksight/latest/user/working-with-aws-vpc.html
but make sure you will create TWO security groups:
Security Group for the Instance in Your VPC
Security Group for Amazon
QuickSight's Elastic Network Interface
Let’s start with the second one:
It is the one which will QuickSight assign to a network interface (ENI), which will be automatically created in your VPC to access the DB. This is the one I missed to create at first and this is the one you use to create a VPC Connection in QuickSight. The details are in the above docs in the paragraph “Security Group Rules for Amazon QuickSight's Elastic Network Interface”.
The first one looks like this:
Inbound: TCP / port according to the DB – in the case of MySQL it is “MYSQL/Aurora, TCP,
3306”, Source: the previous security group.
Do not forget to add this one to your DB instance.
Good luck.
Does your RDS Replica is in a VPC or not?
Identify first and then accordingly create a security group and attach neccessary rules to it !
I would recommend you to read Authorizing Connections from Amazon QuickSight to Amazon RDS Instances
I am being billed for an unused IP address. I can't find the item that's
charging me.
I've gone through the project using console.cloud.google.com looking in Compute Engine and Networking settings, but I can't find any IP addresses.
I'm only using the project for Cloud Storage of 1 text file, and a git
repository. I run these commands on the terminal, and I am getting 0 items.
$ gcloud --project=PROJECTNAME compute addresses list
The above command listed 0 items.
$ gcloud --project=PROJECTNAME compute forwarding-rules list
The above command listed 0 items.
Is there a way of telling where this static IP address is, or how I
can disable it? I can't find it anywhere. I'd rather not delete the entire
project because some of the services are being used by my production app.
I know that it's a global IP address because I can see it listed in my
Compute Engine quota. For me to be able to use a command line option to delete the address, I think that I need the name of the address, but I can't find that listed anywhere.
I'm thinking this could be related to me having one of these two
things enabled for the project in the past:
I was running an AppEngine project, but have since terminated it.
For the AppEngine project, I registered a custom domain to point
to it.
I had used AppEngine Flexible (aef). The unused IP was from my stopped version. This blocks the releasing of the static IP and so it was advised to first delete this version before trying to release the IP address again.
You cannot delete your previous version if that's the only one you have as you need to have at least one version for the default module.
To fix you could deploy a new version, say a Flexible VM (deployed to another region), or a Standard VM. Then as a workaround, if you do not have any app to replace it right now, you can deploy an empty app instead. You would need to create an app.yaml that uses only static files that does not have any script to execute so you would not be charged for any instance.
For a more detailed guide in doing this workaround, you may check this documentation [1].
[1] http://stackoverflow.com/questions/37679552/cannot-delete-version
i've installed an arangodb instance on a virtual machine of Google Cloud (tcp://10.240.0.2). I would setup an asymmetrical cluster with another vm where i've installed arangodb (tcp://10.240.0.3).
I follow the official guide to config the production scenario: 1 coordinator and 1 DBServer on the same machine
I tried also a second configuration to cluster with two vm instances, but it doesn't work, showing this error in the GoogleChromeConsole :
{"error":true,"code":500,"errorNum":500,
"errorMessage":"Cannot check port on dispatcher tcp://10.240.0.3:8529"}
Here you can find the configurations that I have tried
What could be the error?
PS: I've open in the firewall the ports: 8529,8530,8629
Thanks in advance.
Daniele
Have you installed ArangoDB on both virtual machines and changed the configuration (on both) to set
[cluster]
disable-dispatcher-kickstarter = false
disable-dispatcher-frontend = false
and then restarted the database servers? I assume so, since you get "Connection OK" for both servers. Your browser would then talk to the first dispatcher, which in turn will contact the second one. The error message you get suggests that this latter step does not work, since checking ports is the first request the first dispatcher would send to the second one.
Is it possible that processes in the first VM cannot access tcp://10.240.0.3:8529 on the second VM? Maybe the respective other subnets are not routed from within the VMs?
Furthermore, when you have got this to work, you will almost certainly also need port 4001 on the first VM, because that is where our etcd (Agency) will listen. In addition, the ports 8530 and 8629 are the defaults which are tried first. If they are not usable for some reason, the dispatchers will use subsequent port numbers instead to assign them to the coordinators and DBservers. In that case you would have to open these as well, at least from the respective other VM.