I have an application deployed to Heroku. I'm using a service that requires me to access their SFTP server using a static ip address. I know Heroku dynos are unreliable in this regard. I have successfully achieved this using the Proximo addon, however, its too expensive for the amount of traffic that I'll be sending (around 500 MB/month). Is there an alternate to this? I'm inclined towards using an EC2 instance but not quite sure what's required to create a proxy or whatever.
I'd go with an EC2 micro instance; pushing bits around doesn't really consume much CPU, so it's unlikely to get throttled. I would then give that instance an elastic IP address and communicate that address to the other service. (Whatever I choose to do later, I can always spin up another instance and associate it to that IP.) I would then deploy a SOCKS proxy (Dante?); SOCKS has pretty widespread application support, and it can handle SFTP just fine.
From here, there are a couple details specific to Heroku -- for one, you'll want to configure your proxy server's EC2 security group such that Heroku can access it (see Dynos and the Dyno Manifold). You'll also want to enable authentication on the SOCKS server, since granting Heroku access to your proxy grants everyone in Heroku access to your proxy. Then, heroku config:set SOME_SERVICE_SOCKS_PROXY=socks://user:pass#ip-10-1-2-3.ec2.internal, and have your application look for that environment variable and do the right thing.
You'll likely be paying $0.01/GB for intra-region data transfer between your proxy and Heroku, since statistically, your application will be in a different availability zone most of the time. Heroku dynos last about 24 hours in production, so while the exact location will dance around unpredictably, it'll probably land in the $0.008/GB range in aggregate. You'll also be paying for the micro instance itself (though reserved instances make them stupid cheap) as well as the usual AWS Internet data transfer rates.
Related
I want to host a production Rails application on Heroku but have some doubts. Can there be any problems with accessing application from Russia because of the Roskomnadzor ban?
Heroku runs on Amazon Web Services, and it looks like many AWS IP addresses have been blocked in the past:
On 13 April 2018, messaging service Telegram was banned... The ban has been enforced via the blockage of over 15.8 million IP addresses. IPs associated with Amazon Web Services and Google Cloud Platform are included in the block, due to Telegram's use of these platforms; this measure resulted in collateral damage due to usage of the platforms by other services in the country, including... many other unknown websites being blocked for no reason for a month.
I'm not sure that any host would be completely safe from this kind of block.
I have an application that uses spring boot for a backend and Vue.js as a front end. I have packaged the app into a jar file and deployed to PCF with ease. The problem is the application uses API Keys from https://developer.clashroyale.com/#/getting-started ...these keys require you to input the IP Address that will be used...
Obviously my key will not work unless I give the correct IP address, so how do I retrieve the IP Address for my PCF application so I can generate the proper API Key?
Also, the documentation says that the IP will change with every deployment of my application... Which prompts the question :
Is it impossible to use API Keys that require static IP Addresses with PCF applications?
I have deployed this same application to amazon AWS and it worked because I have a static IP Address that I can use to register a key. I prefer to use PCF, but am having trouble setting it up.
I don't think you will be able to use that API on the PCF platform. Every time you either cf restage or anything to cause the container to be rebuilt/redeployed, the IP will change.
So in short yes, it's impossible: https://docs.run.pivotal.io/marketplace/external-ips.html
Your app will be run on any number of Diego Cells, which all have different IP addresses. There are a couple ways that traffic can leave your app and the Cell.
In some cases, outbound traffic may go through a NAT, in which case the number of possible IPs may be small and the IPs may not change often (or at all). In other cases, traffic may leave directly from the Diego Cell on which your application is running. In this case, there's a lot more IPs & the IPs will change any time your app is restarted.
If you're talking about some general installation of Cloud Foundry, it will depend on how the operators for that environment have set up the traffic to flow so you'd need to confirm with your operator to be certain.
If you're talking about Pivotal Web Services, outbound traffic will originate from the IP of the Cell on which your app is running. See the link in Francisco's post.
Having said all that, there's a hack that you can use to work around the behavior above. Route your traffic through a proxy. Traffic coming out of the proxy can be made to have a fixed IP address.
On PWS, there is a service in the marketplace available to do exactly this. It's called QuotaGuard.
https://docs.run.pivotal.io/marketplace/services/quotaguard.html
You don't have to use that service though, you could use any other service provider or you could even set up your own proxy. I would recommend using a service unless you know exactly what you are doing though. Setting up & securing a proxy is not trivial and an improperly secured proxy is bad not just for you as the owner but the whole Internet.
Say I deploy an API, the database etc. to a t2.micro EC2 instance to serve traffic for the period of prototyping and beta testing. Let's say the domain pointing to the API is api.exampleapp.com.
Now traffic begins to grow beyond the instance's limits and we deploy the API to a bunch of instances that we want to stand behind a load balancer. After setting the fleet up, how do we make api.exampleapp.com point now to the load balancer's IP address so that traffic is served by the newly launched instances without any downtime? Is this possible at all? Or with minimal downtime? Or is this approach of starting up with a new API itself faulty?
I assume you either don't need auto-scaling or have it already configured.
start the LB and attach your first EC2 to it. The instance still work, can be directly accessible via its IP (thus, accessible from the World).
check the LB hostname, try to access the instance using LB, make sure it works
switch DNS to the LB using either CNAME or ALIAS record type (if ALIAS is supported by your DNS server)
add another instances to the LB.
Done!
I am developing an app (RoR + Heroku) which allows users create their own websites either using my subdomain (pagename.myapp.com) or using their own domain (pagename.com).
An important point of this is that this option is the key of my business: subdomains are the free plans and custom domains are the paid ones. So I have a table where I store the custom domains of each user and check if this page is active (exists and has paid the quota).
For that I need to give users the capability of point their domain to my servers. All we know that Heroku don't recommend the use of DNS A-Records.
Also I would like to abstract as much as possible this feature to being able to switch my infrastructure (Heroku to AWS) in the future without having to ask all my users to change their DNS Zone. Taking this into account, I think that the best option would be run something like an EC2 proxy (using AWS Elastic IP) which give me the ownership of this IP. This proxy I think that should redirect to proxy.myapp.com, and I would resolve the request in the app level.
Due to I didn't find clear information about that, I am not sure if this hypotesis is the best solution and how to setup the proxy (which type of proxy use? Nginx maybe?).
Said that, I would like to ask recommendations/best practices to solve this "common" feature.
Thanks
What you are wanting to do is fairly straight forward to implement. Your assumptions are correct about setting up the proxy. Nginx or haproxy will both work great for this (I personally would use haproxy). Here are some of the gotchas that you will run into though:
Changing the host header at a proxy server can cause the end web application to generate incorrect links. You can use relative paths to fix this, but it requires that the web application developer to be aware of the environment that they are running in.
user connects to www.example.com (proxy server)
proxy server connects to www.realdomain.com (web app)
the web app has a link for a shopping cart. www.realdomain.com/shoppingcart
the end user clicks on the link but the link is www.realdomain.com/shoppingcart instead of www.example.com/shoppingcart
The cost of the host acting as the proxy server. This can spiral out of control really quickly. For example, do you want redundancy, if so how are you planning on implementing that? Do you plan on having ssl termination? If so you will have to increase the CPU count to accommodate the additional load. Do you want to have a secure connection to heroku from your proxy? If you do then you will need to increase the CPU count for that as well. You may have to add additional ram as well depending on the number of concurrent connections.
Heroku also changes their load balancers regularly. This is important because your proxy service will need to reload the config / update the ip addresses of the heroku instances every 60 seconds. In my experience they may change once or twice a day, but the DNS entry that they use has a 60 second TTL. That means that you should make sure that you are capable of updating your config up to every 60 seconds.
My company has been doing something very similar to this for almost a year now. We use haproxy and simply have it reload the config regularly. We have never had an outage or an interruption to our end users. Nginx is also a very good product. It has built in DNS caching so if you go that route you will need to make sure that you configure it correctly so that the DNS cache TTL is 60 seconds.
Will many of your clients want to use your app on their domain apex? E.g. example.com rather than theapp.example.cpm? If not, I would recommend having them CNAME to proxy.myapp.com which CNAMEs to myapp.herokuapp.com. Then, you can update proxy.myapp.com without customer interruption.
If you do need apex or A record support, you would want to set up Nginx as a reverse proxy for your Heroku app. Keep in mind that if you need HTTPS support for client domains, you will need to do some sort of certificate management on your proxy.
I like the answer dtorgo gave and that he mentioned the TLS termination, which many online tutorials on custom domains don't touch at all.
I'll go into more detail on how to implement the custom domains feature for your SaaS while also handling the TLS/HTTPS.
If your customers just CNAME to your domain or create the A record to your IP and you don't handle TLS termination for these custom domains, your app will not support HTTPS, and without it, your app won't work in modern browsers on these custom domains.
You need to set up a TLS termination reverse proxy in front of your webserver. This proxy can be run on a separate machine but you can run it on the same machine as the webserver.
CNAME vs A record
If your customers want to have your app on their subdomain, e.g. app.customer.com they can create a CNAME app.customer.com pointing to your proxy.
If they want to have your app on their root domain, e.g. customer.com then they'll have to create an A record on customer.com pointing to your proxy's IP. Make sure this IP doesn't change, ever!
How to handle TLS termination?
To make TLS termination work, you'll have to issue TLS certificates for these custom domains. You can use Let's Encrypt for that. Your proxy will see the Host header of the incoming request, e.g. app.customer1.com or customer2.com etc., and then it will decide which TLS certificate to use by checking the SNI.
The proxy can be set up to automatically issue and renew certificates for these custom domains. On the first request from a new custom domain, the proxy will see it doesn't have the appropriate certificate. It will ask Let's Encrypt for a new certificate. Let's Encrypt will first issue a challenge to see if you manage the domain, and since the customer already created a CNAME or A record pointing to your proxy, that tells Let's Encrypt you indeed manage the domain, and it will let you issue a certificate for it.
To issue and renew certificates automatically, I'd recommend using Caddyserver, greenlock.js, OpenResty (Nginx).
tl;dr on what happens here;
Caddyserver listens on 443 and 80, it receives requests, issues, and renews certificates automatically, proxies traffic to your backend.
How to handle it on my backend
Your proxy is terminating TLS and proxying requests to your backend. However, your backend doesn't know who is the original customer behind the request. This is why you need to tell your proxy to include additional headers in proxied requests to identify the customer. Just add X-Serve-For: app.customer.com or X-Serve-For: customer2.com or whatever the Host header is of the original request.
Now when you receive the proxied request on the backend, you can read this custom header and you know who is the customer behind the request. You can implement your logic based on that, show data belonging to this customer, etc.
More
Put a load balancer in front of your fleet of proxies for higher availability. You'll also have to use distributed storage for certificates and Let's Encrypt challenges. Use AWS ECS or EBS for automated recovery if something fails, otherwise, you may be waking up in the middle of the night restarting machines, or your proxy manually.
If you need more detail you can DM me on Twitter #dragocrnjac
Heroku offers US and EU servers and I want my users to connect to the server which is closer to them, so if someone connects from the EU, I will redirect them to the EU server and the same for the US.
My idea was to have them connect to main domain name, example.com that would connect to the US server, which would check where the users are coming from, and then redirect them to where I want them to be, and all this while they are looking at the same domain "example.com". Heroku wont let me add the same domain twice, and I don't know where I should configure what for the DNS. My domain provider has a nameserver section and I'm not sure what to add there. Basically I want all the request and server load to go onto the Heroku page, and not onto the default DNS server which only redirects or loads the Heroku page inside a frame.
They way it seems correct, is to connect to example.com, which is the US Heroku page and then redirect inside a frame or something to the EU page... not sure if this is the best way, and like I mentioned, I'm not sure how to setup the namespace and stuff so they connect directly to the Heroku server instead of the default domain server.
Could someone explain to me what I need to do to achieve what I want?
It is currently not possible to run a multi-region application on Heroku and I'd caution against trying to work your way around this limitation. Some areas that cause users problems when trying to attempt this are:
You can't have the same custom domain on two apps (as you've already identified).
There is no way to setup a multi-master database configuration so each app has a db in its own region. Likewise, maintaining a single master for both apps results in very high latency for one of the apps.
The connection overhead of any other trickery, like what you propose here, often negates any latency improvement the user sees from accessing the app in their closest region.
Using a CDN for static assets, and having a proper http cache header strategy often gets you 90% of the way to the performance of a truly geo-distributed app.
To drill further into your question, I'm not sure what you mean here?
how to setup the namespace and stuff so they connect directly to the Heroku server instead of the default domain server
Hope that helps!