Google's CloudRun is capable of redirecting http to https without any configuration. I was not able to find any solution that would instruct CloudRun to respond 301 Permanent Redirect to all non-www requests.
I was able to instruct CloudRun to handle both www and non-www but without redirection.
I am familiar with how to set up the required logic with nginx and a traditional server. I could also do this in the application itself but since CloudRun is a serverless product, it would be better to handle this state before the app is even invoked.
Thank you.
When you reach Cloud Run, you first lands on GFE (Google Front End). This layer ensure the security (if you set your Cloud Run service in no-allow-authenticated mode, perform DDoS mitigation at Google grade, expose and manage the SSL certificates, route the request to the correct services,...). So, a lot of job for this layer but you can't customize it.
If you want to add customization, you have to add a new layer, a HTTPS Global Load Balancer. Now you can define serverless NEG backends to reach serverless product (Cloud Run, Cloud Functions, App Engine).
It doesn't offer as much as customization as a NGINX managed by yourselves, but you can perform more things.
Related
My backend is a simple dockerized Node.js express app deployed onto elastic beanstalk. It is exposed on port 80. It would be located somewhere like
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
I can call my APIs on the backend
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/hello
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/postSomeDataToMe
and they work! Yay.
The URL is not very user friendly so I was hoping to set up API gateway to allow to me simply forward API requests from
api.myapp.com/apiFamily/ to mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
so I can call api.myapp.com/apiFamily/hello or api.myapp.com/apiFamily/postMeSomeData
Unfortunately, I can't figure out (i) if I can do this (ii) how to actually do it.
Can anybody point me to a resource that explains clearly how to do this?
Thanks
Yes, you can do this. For this to happen you need two things:
a custom domain that you own and control, e.g. myapp.com.
a valid, public SSL certificate issued for that domain.
If you don't have them, and want to stay within AWS ecosystem, you can use Route53 to buy and manage your custom domain. For SSL you can use AWS ACM which will provide you with free SSL certificate for the domain.
AWS instructions on how to set it up all is:
Setting up custom domain names for REST APIs
I'm currently trying to create a tracing tool for fun (which supports gRPC tracing) and was confused as to whether or not I was thinking about this architecture properly. A tracing tool keeps track of the entire workflow/journey of the request (from the moment a user clicks the button, to when the request goes to the API gateway, between microservices, and back.
Let's say the application is a bookstore, and it is broken up to 2 microservices, maybe account and books. Let's say that there is a User Interface, and when you click a button, it allows a user to favorite a book. I'm only using 2 microservices to keep this example simple.
**Different parts of the Fake/Mock up application**
UI ->
nginx -> I wanted to use this as an API Gateway.
microservice 1 -> (Contains data for all Users of a bookstore)
microservice 2 -> (Contains data for all the books)
**So my goal is to figure a way to trace that request. So we can imagine the request goes to nginx
Concern #1: When the request goes to nginx, it is HTTP. Cool, but when the request is sent to the microservice, it is a grpc call (or over http2). Can nginx get an http request and then send that request over http2...? Not sure if I'm wording this correctly or not. I know nginx plus supports http2. I also know that grpc has a grpc gateway too.
Concern #2: Containerization. Do I have to containerize both microservices individually, or would I have to containerize the entire docker container itself. Is it simple to link nginx and docker?
Concern #3: When tracing gRPC requests (finding out how much time a request is fulfilled), I'm considering using a middleware logger or a tracing API (opentracing, jaegar, etc.) to do this. How else would I figure out how long it takes for gRPC to make requests?
I was wondering if it was possible to address these concerns, if my thought process is correct, and if this architecture is feature.
Most solutions in the industry are implemented on top of a container orchestration solution (Kubernetes, Docker Swarm, etc).
It is usually not a good idea to "containerize" and manage reverse proxy yourself.
The reverse proxy should be aware of all the containers status (by hooking to orchestrator) and dynamically update its configuration when a container created, crashed, or relocated (due to a machine gets out of service).
Kubernetes handles GRPC using the mesh networks. Please take a look at kubernetes service mesh.
If you decided to use Traefik and Docker Swarm check out traefik h2c support.
In conclusion, consider more modern alternatives to Nginx when you want to load balance GRPC.
I have two apps I wanted to have "fully managed" by Cloud Run. One is a pure Vue.js SPA and the other is the belonging backend server for it that is connected to a MySQL and also fetches some other API endpoints.
Now I have deployed both apps but am totally unaware on how I can give the frontend app access to the backend app. They should be both running on the same domain to avoid the frontend from.
Current URL of the frontend app: https://myapp-xl23p3zuiq-ew.a.run.app
So I'd love to have the server accessible by: https://myapp-xl23p3zuiq-ew.a.run.app/api
Is this somewhat possible to achieve with Cloud Run?
I was having the same issue. The general idea that one usually has is to use path mapping and map / to your client and /server to your backend. After googling for a while I found this:
https://cloud.google.com/run/docs/mapping-custom-domains
Base path mapping: not supported
The term base path refers to the URL
path name that is after the domain name. For example, users is the
base path of example.com/users. Cloud Run only allows you to map a
domain to /, not to a specific base path. So any path routing has to
be handled by using a router inside the service's container or by
using Firebase Hosting.
Option1:
I ended up creating an "all in one" docker image with an nginx as reverse proxy and the client (some static files) and server (in my case a python application powered by uwsgi).
If you are looking for inspiration, you can check out the public repository here: https://gitlab.com/psono/psono-combo
Opttion2:
An alternative would be to host your client on client.example.com, your server on server.example.com and then create a third docker run instance with a reverse proxy under example.com.
All requestes would be "proxied" to the client and server. Your users will only interact with example.com so CORS won't be an issue.
Option3:
Configure CORS, so people accessing example.com can also connect to server.example.com
Currently this is not possible in Cloud Run, as already said on the comments to your question.
You could check if there are any Feature Request for this functionality on Buganizer (Google Issue Tracker), currently there seems to be none, and if that is indeed the case, you can create a new Feature Request by changing the request type from Bug to Feature Request and as Google develops it on their road map, you will be informed.
Hope this helped you.
I want to replace haproxy with traefik. But in order to that, I have to replace a Lua script which handles authentication (via auth token calling a rest API) and custom redirect (certain docker service) depending on headers and authentication from before.
Is there an (easy) way to that?
Right now as for migrating I was thinking to leave haproxy for now and routing all valid traffic to traefik.
Authentication and Traefik is not an easy thing. At my company, we just switched back from Traefik to nginx since handling ldap/kerberos/pki etc. With Traefik can be painfully awkward. There is the possibility to pass authentication on from Traefik to a 3rd party and collect the session token or other relevant information using Forward Auth, so maybe take a look at that. You can also use BasicAuth
Although getting it to run with your setup might prove hacky.
I'm running a ASP.NET MVC website hosted on Azure and using Traffic Manager as load balancer, thus the users can not only visit the website by custom domain like foobar.yourcompany.com, but also endpoint provided by Azure Traffic Manager like foobar.trafficmanager.net. So do Search Engine crawlers.
Is there any feasible solution to hide the Traffic Manager endpoint from crawlers and expose the custom domain endpoint?
P.S. I know robots.txt.
If you setup your app to return an HTTP 301 permanent redirect to your custom domain when accessed over the Traffic Manager domain, it should stop it from showing up in search results. As far as I know, you can't fully disable the TM domain. Similarly like you can't fully disable the App Service domains.
So e.g. if your app gets a request for:
http://foobar.trafficmanager.net/foo/bar
Redirect it with an HTTP 301 to:
http://foobar.yourcompany.com/foo/bar