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.
Related
I am currently looking into deploying Traefik/Træfik on our service fabric cluster.
Basically I have a setup where I have any number of Applications (services), defined with a tenant name and each of these services is in fact a separate Web UI.
I am trying to figure out if I can configure a single frontend to target a backend so I don't have to define a new frontend each time I deploy a new UI app. Something like
[frontend.tenantui]
rule = "HostRegexp:localhost,{tenantName:[a-z]+}.example.com"
backend = "fabric:/WebApp/{tenantName}"
The idea is to have it such that I can just deploy new UI services without updating the frontend configuration.
I am currently using the Service Fabric provider for my backend services, but I am open to using the file provider or something else if that is required.
Update:
The servicemanifset contains labels, so as to let traefik create backends and frontends.
The labels are defined for one service, lets call it WebUI as an example. Now when I deploy an instance of WebUI it gets a label and traefik understands it.
Then I deploy ANOTHER instance with a DIFFERENT set of parameters, its still the WebUI service and it uses the same manifest, so it gets the same labels, and the same routing. But what I would really want was to let it have a label containing some sort of rule so I could route to the name of the service instance (determine at runtime not design time). Specifically I would like for the runtime part to be part of the domainname (thus the suggestion of a HostRegexp style rule)
I don't think it is possible to use the matched group from the HostRegexp to determine the backend.
A possibility would be to use the Property Manager API to dynamically set the frontend rule for the service instance after creating it. Also, see this for a complete example on using the API.
I have a cluster in Azure AKS with 1 node.
On that cluster I have two back-end services.
Each back-end service is a web app.
I have a domain mydomain.com.
Each app will need to be configured with its own path rule in the ingress object.
Web app 1s (let's call this one the homepage app) target URL needs to be either of the following:
US version of the site: mydomain.com
Swedish version of the site: mydomain.com/se/sv-sv/hem
Any other location/language version of the site: mydomain.com/xx/yy-xx/abcdefgh
Web app 2s (let's call this one the whitepony app) target URL needs to be either of the following:
US version of the site: mydomain.com/us/en-us/whitepony
Swedish version of the site: mydomain.com/se/sv-sv/whitepony
Any other location/language version of the site: mydomain.com/xx/yy-xx/whitepony
(The whitepony apps target path segment is called whitepony regardless of location/language)
Now to my question.
How can I configure these rules in an ingress API object?
Can I use prefixes in the path rules?
Or do I need to use regular expressions?
And what about the special case of the US version of the homepage app, where I'm not using any prefixes/extra URL segments?
Can I use conditions in the ingress object?
Or how would you configure the ingress resource object to meet all the above requirements?
Note that I know and have successfully configured multiple back-end services using path rules in an ingress object.
But without prefixes or extra URL segments.
I won't give you fully working example on how to specify rules in ingress resource to meet your requirements, I would rather like to share with you some hints:
Yes, you will need regular expressions to achieve it, and here is the example of doing it directly with NGINX directives based on example of wordpress multi-language site.
You don't need to define these re-write rules with annotations, you can use for that pure NGINX config style, by supplying appropriate inline NGINX config file inside ConfigMap, here is the example on how to achieve this.
I hope this will help you
I am using kubespray for the deployment of a kubernetes cluster and
want to set some API Server parameters for the deployment. In specific I want to configure the authentication via OpenID Connect (e.g set the oidc-issuer-url parameter). I saw that kubespray has some vars to set (https://github.com/kubernetes-sigs/kubespray/blob/master/docs/vars.md), but not the ones I am looking for.
Is there a way to set these parameters via kubespray? I don't want to configure each master manually (e.g by editing the /etc/kubernetes/manifests/kube-apiserver.yaml files).
Thanks for your help
On the bottom of the page you are referring to there is description how to define custom flags for various components of k8s:
kubelet_custom_flags:
- "--eviction-hard=memory.available<100Mi"
- "--eviction-soft-grace-period=memory.available=30s"
- "--eviction-soft=memory.available<300Mi"
The possible vars are:
apiserver_custom_flags
controller_mgr_custom_flags
scheduler_custom_flags
kubelet_custom_flags
kubelet_node_custom_flags
The k8s-cluster.yml file has some parameters which allow to set the OID configuration:
kube_oidc_auth: true
...
kube_oidc_url: https:// ...
kube_oidc_client_id: kubernetes
kube_oidc_ca_file: "{{ kube_cert_dir }}/ca.pem"
kube_oidc_username_claim: sub
kube_oidc_username_prefix: oidc:
kube_oidc_groups_claim: groups
kube_oidc_groups_prefix: oidc:
These parameters are the counter parts to the oidc api server parameters
Just realized that geoip was present by default within the nginx-ingress in the context of kubernetes; that is, looked around, being new into nginx geoip, I don't have much clue about how to benefit from this
Firstly, is there any declarative setup to effectively have it working ? A configmap setup, or so ?
Secondly, how such info is passed from the nginx-ingress to an app ? Is the info present in the headers ? is there any extra setup to apply ?
thanks a lot for any experienced input; best
Find usefull documentation about how to configure Geoip2 for nginx ingress kubernetes deployment.
Example Nginx Configuration ConfigMap
You will find the expected ConfigMap name at the nginx controller container entrypoint or environment variables. Furthermore you can override this name, the way to do so will depend on your nginx installation/deployment method.
ConfiMap Nginx supported configurations
You will find there a listed all the supported configs/properties plus a sort description about them and how to use them.
For this specific question, the property to configure Geoip2 is "use-geoip2" (link below)
Enable GeoIP2
remark: you will need a license and add a flag at nginx entry command providing it
The nginx_http_geoip_module module creates variables with values depending on the client IP address, using the precompiled MaxMind databases.
This module is not built by default, it should be enabled with the --with-http_geoip_module configuration parameter.
The module analyze headers, next connect to defined database, fetch the localization information and offers a variables regarding to them like
country or city of connection origin. Some examples:
$geoip_country_code - two-letter country code
$geoip_city - city name
$geoip_postal_code - postal code
I've been setting up CloudFormation templates for some new infrastructure for a project and I've made it to Route 53 Hosted Zones.
Now ideally I'd like to create a "core-domains" stack with all our hosted zones and base configuration. Thing is we already have these created manually using the AWS console (and they're used for test/live infrastructure), is there any way to supply the existing "HostedZoneId" as a property to the resource definition and essentially have it introspect what we already have and then apply the diff? (If I've done my job there shouldn't be a diff hopefully so should just be a no-op!).
I can't see a "HostedZoneId" property in the docs: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-route53-hostedzone.html
Any suggestions?
PS. I'm assuming this isn't possible and I'll have to recreate all the HostedZones under CloudFormation but I thought I'd check :)
Found it. It's fine to make other HostedZones, they're issued with new Nameservers, just use the "HostedZoneConfig: Comment" field to note down which hosted zone is which and then you can switch the nameservers over when you're ready!