OpenShift routes with path results in ignoring sub routes - rest

I'm currently using OpenShift for the depoloyment of a node.js-Application. This application exposes a REST api.
As long as i don't use a path in Openshift and the route is something like
www.app.host.com
the API works fine. Now I want to host multiple apps on one host, as i don't want to have to make a certificate signing request everytime I add a new one. But when I use a path in OpenShift routes like
www.host.com/app/
all the trafic will be sent to the apps root route. So
www.host.com/app/request/something
will still result the traffic ending up on the welcome page. Do you have any ideas how to get OpenShift to still accept the subroutes?

Ok, here's what you'll have to do. You have to include your path into the node.js application.
So if you're using /yourapp/ (be sure to include the slash at the end) you'll have to change your routes from
/api/dosomething to /yourapp/api/dosomething
In my case I used an environment varible as I didn't want to hardcode the path into my app. so now it basically looks like this
var requestPath = (process.env.ROUTE_PATH || '') + '/request';
var authPath = (process.env.ROUTE_PATH || '') + '/auth';
app.use(requestPath, routesRequest);
app.use(authPath, routesAuth);
After that, just set your ROUTE_PATH environment variable in the deployment to /yourapp and you're good to go

Related

Azure Front Door route to app service subdirectory

I have an Azure Front Door environment that I would like to use to route a domain to an app service sub directory. But im having some issues setting it up
Domain: portal.example.com
Back End Pool: App Service - xxx.azurewebsites.net
I would like portal.example.com to route to xxxx.azurewbesites.net/portal
But for some reason im not able to do that and getting errors if i try to have it redirect with the slash " / "
"The domain and subdomains can be between 1 to 63 alphanumeric characters, must start and end with an alphanumeric character, and additionally can contain the '-' character in between. The top level domain must be between 2 to 61 alphabetical characters."
I have tried creating a routing rule and also tried using rule engine configuration.
seems there will be wrong route configuration. I have tried to replicate the same scenario.
Step1:
Created a front door environment with backend endpoint as
*****.azurewebsites.net
Step2:
Applying rule configuration to update route rule as
if request URL is "portal.example.com" then route the traffic to xxxx.azurewbesites.net/portal
refer this tutorial for more information. Found another similar post for reference.

Alter auto-generation of host for routes in openshift on namespace basis

I try to adjust the template for generating routes within a single namespace.
So basically what openshift does, when I enter a route without settng the host via yaml is generate a route in the following way:
${name}-${namespace}.myapps.mycompany.com
I would prefer to have a base domain for many routes which differs in the path, e.g.:
${namespace}.myapps.mycompany.com/${name}
Is this possible? Especially If I am not an admin of openshift at my company but a dev whose team is responsible just for a few namespaces?
For context: We want to use ArgoCD + Git to use gitops, but do not want to hardcode any infrastructure knowledge like the host or domain in our git repo. We came from using ingresses, but if we omit the host there no routes are generated at all...
Thanks in advance for any help!
You can have path-based routes, e.g., [host]/[path]. If you don't provide your own value for [host], it will use the same OpenShift ${name}-${namespace}.myapps.mycompany.com based values.
I'm not sure that you can change OpenShift's default route template, but you can definitely provide your own path values.

Axios BaseURL not working on certain hosts

Below is how I configured Axios based on the example given on Nuxt.js' website:
.env:
BASE_URL=https://path.to.endpoint
nuxt.config.js:
publicRuntimeConfig: {
axios: {
baseURL: process.env.BASE_URL
}
},
On page load I make this call:
this.$axios.get(`/endpoint`)
Once I deploy my app as a static site it works both on my personal host and on GitHub pages. But on my employer's host, the path to endpoint specified in .env becomes https://localhost:3000 so the API call fails.
Why is the most likely cause of this behaviour?
Alright, from the comments, it looks like you configuration is totally fine from what you've provided and that the team on the other side does have an incorrect setup of the environment variables.
You need to ask where they do host your code and what are the actual values of their env variables. Actually, you will probably need to give it to them since they (usually) cannot guess it by themselves.
Human communication is the next step. ^^

Traefik redirect from one host to another

We decided to move from the subdomain structure to one root domain with path prefixes, but we got many old URLs on the internet. So is there any way to add a redirect from the old URL to the new one?
For example,
We got subdomain test.example.com switched to example.com/test, I can access correctly site with the string in docker-swarm YAML file
traefik.frontend.rule: Host:example.com;PathPrefixStrip:/test
but when I'm trying to add to Traefik config redirects like:
[http.middlewares]
[http.middlewares.test-redirectregex.redirectRegex]
regex = "^https://(*).example.com/)"
replacement = "^https://example.com/${1}"
Traefik says that it doesn't know where to forward this request
If I'm trying to add:
traefik.frontend.rule: Host:test.example.com,example.com;PathPrefixStrip:/test
Traefik adds a prefix to both hosts. Is there any way to resolve this without adding a second reverse proxy?
Assuming that you are using Traefik 2.1, you can use the below middleware for Traefik
[http.middlewares]
[http.middlewares.blog-redirect.redirectRegex]
regex = "^(https?://)(.*).example.com/(.*)$"
replacement = "${1}example.com/${2}/${3}"
permanent = true
The important step to activate the above middleware is to add the below label on the corresponding router and service. For instance, if you a a blog service and you defined a blog router for it, then you need to add the below table to the services
traefik.http.routers.blog.middlewares=blog-redirect
In addition, your route rule should look like the below rule to be able to handle both domains (or you define multiple routes per service)
- traefik.http.routers.blog.rule=Host(`example.com`) && Path(`/test`) || Host(`api.example.com``)
in this post, you can find more info about traffic and redirection

Setting up load-balancer based on authenticated users

I'm trying to set up a loadbalancer that would redirect to specific version of an application certein users. So far i was using Blue/Green deployment strategy (so once i made new version of an app i created new environment and redirected traffic there). Now i would like to change this approach. I want to be able to specify users (more experienced or whatever) that would see new site after authentication while the others would still be redirected to old one. If something goes wrong with new version all users will see old version. Currently my loadbalancing is made in apache and authentication is done on application level. So is this even possible? I know i could hardcode it in application but what if there is a bug in new feature and new users are still being redirected there? I would then need to stop application for all users and rollback to old version and that's bad i guess. I was thinking about using external CAS however didnt find any information if it would be possible then. So i would like to ask is it possible and are there any tools (maybe some apache plugin) for that purpose?
Here's a working solution with nginx
create conf.d/balancer.conf
put the code into it (see below)
docker run -p8080:8080 -v ~/your_path/conf.d:/etc/nginx/conf.d openresty/openresty:alpine
use curl to play with it
balancer.conf:
map $cookie_is_special_user $upstream {
default http://example.com;
~^1$ http://scooterlabs.com/echo;
}
server {
listen 8080;
resolver 8.8.8.8;
location / {
proxy_pass $upstream;
}
}
testing
curl --cookie "is_special_user=1" http://localhost:8080
It would return the contents of scooterlabs.com dumping the request it receives
curl http://localhost:8080
Produces the contents of example.com
explanation
the idea is that you set a special cookie to the users you treat as special by the backend app after they get authorized as usual
of course it would only work if both app versions are served on the same domain so that the cookie is seen by both versions
after that you balance them to a desired server depending on the cookie value
you can easily disable such routing by tweaking your nginx config file
with this approach you can come up with even more complex scenarios like setting random cookie values in the range 1-10 and then gradually switching some of the special users in your config file i.e. start with those having value 1, after that 1-2 etc