Using Custom domain, URL mask with CloudRun services and a NEG - serverless

I am having issue using the Serverless NEG and URL Masks with Custom domains. Here is some background:
I have multiple services deployed as CloudRun services (login service, search service, feedback service). I am trying to setup a custom domain mapping and use URL Masking so the requests are routed to appropriate services.
I followed the steps outlined here - https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless
I have created a Load Balancer, Backend Service and a Serverless NEG with a Serverless Network Endpoint Group type as "Cloud Run" and selected "use URL mask" checkbox and provided my custom domain URL like this mycompany.com/ where mycompany.com is the custom domain I have.
NOTE: I am planning to use just one Serverless NEG and leverage URL mask so it can route the requests to appropriate CloudRun service in the backend.
I have updated mycompany.com to use the Public IP address created by the LB from the above steps.
Now, When I type mycompany.com/login or mycompany.com/search, it is not directing me to the appropriate CloudRun services and instead get an error - "This site can’t be reached"
My question: Do I need to setup Custom Domains and add mappings on the CloudRun page specifying mycompany.com and select one of the CloudRun service for me to leverage URL masks ?
I am slightly confused here and the documentation is not helping me here.
Please help.
Regards,
Raj

Related

GCP Cloud Run: Disable default URL and use Custom Domain only?

Is it possible to disable the default URL like this https://my-app-332mpca-uc.a.run.app and only use my custom domain as defined in domain mapping?
You can't achieve that with custom domain. You can achieve something similar by adding a Load Balancer in front of Cloud Run thanks to serverless NEG.
As you do that, you have an IP that you can add to your registrar (similar to custom domain in fact). To remove the public access of the Cloud Run default URL, you can set the ingress parameter of Cloud Run service to Internal and Cloud Load Balancer.
And then, you have it.
No.
The Cloud Run service URL is the definitive address for the service.
Your DNS CNAME needs a unique identifier for the service and the endpoint is it.
The only alternative to a URL would be for Google to publish IP addresses for Cloud Run services but that's impractical (with IPv4) and still provides an alternative way to access the service.

API gateway to my elastic beanstalk docker deployed app

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

How to bring two Cloud Run Apps under one domain to avoid CORS

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.

Redirect from non www to www, do I need two app services in azure?

I'm using this solution in redirecting my domain from non www to www. I'm using azure for hosting.
I have created app service for www.domain.com
when I try to access domain.com I get this error:
Should I have to create two app services one for domain.com and one for www.domain.com? or is there a way to accomplish this using one app service?
Should I have to create two app services one for domain.com and one
for www.domain.com? or is there a way to accomplish this using one app
service?
No, you don't need two app services to accomplish this.
Assuming you have configured domain mapping correctly in your DNS provider (e.g. GoDaddy), all you need to do is add both www.domain.com and domain.com in the Hostname mapping in Custom DNS section for your Web App in Azure Portal.
All you need to do it set it up in the DNS section of your domain provider and add custom domains in App Service in Azure Portal as well:
Type Name Value
A # Ip Address of your App Service ( this will cover your main domain )
TXT # yourwebsite.azurewebsites.net ( this will cover your main domain )
CNAME www yourwebsite.azurewebsites.net ( this will conver www section)
Now in the app service side you need to add the custom bindings.
Go to Azure Portal | App Service | settings | custom domains | add host name as below
yourdomain.com
Now you have both domain pointing to same App Service.
More info on step by step guide, I have prepared a post for custom domain check it out.

Zuul and Ribbon integration

I have trouble understanding the connection between Zuul and Ribbon.
I think I got Zuul clear. It's a reverse proxy I can contact to reach one of my several instances of a service. It will pick the right server using a round-robin algorithm or whatever you configure it to do. It's a traditional load-balancer. To know the instances available it can use a registry like Eureka.
But I've got more trouble with Ribbon. It's sold as a client-side load balancer but what does it mean ? It doesn't need an external server ? Ribbon is embedded in the client the same way an Eureka client is ? If so how does it work ? Do I need Zuul when I use Ribbon, and vice-versa ?
On some articles, I saw that in fact, Zuul uses Ribbon by default for the load balancing part and it got me even more confused. If this is true what does "client-side" mean ? What does Zuul do except routing ?
I hope you can help me.
Client and Server is always relative. Zuul is a client for your service instances and your service instances are servers for Zuul.
When we are using traditional load balancer (server-side load balancer), API caller (client) only knows a single endpoint that is a load balancer and the client doesn't know the list of servers. Load balancer chooses a server from the list.
When we are using client-side load balancer like Ribbon, API caller (client) should know the list of servers and choose one of them from the list. That's why we call it client-side load balancer.
As you know, Ribbon is a client-side load balancer module and is integrated to many http client modules. As an example, Feign and Load-balanced RestTemplate support Ribbon. Namely Feign and Load-balanced RestTemplate can choose a server from the given list or the list from eureka when used with ribbon.
Regarding Zuul, there is a RibbonRoutingFilter that routes your request to an actual service instance. RibbonRoutingFilter is using Ribbon to choose a server from the list that is given from your configuration or from Eureka. So if you want to use Zuul as a load-balanced reverse proxy, Zuul needs Ribbon.

Resources