Last modified May 20, 2020
Create code snippets in the web app, or use the browser extension to snip code blocks directly from the pages you visit. PRO Power up your account Be in full control of your code snippets. Create private lists and collections and keep things to yourself. Snippets in Forestry are pre-defined chunks of text that can be inserted into your content. You can put anything in a snippet that you might normally insert into your content, but they are especially useful in conjunction with shortcodes in Hugo or certain Liquid tags in Jekyll. Creating Snippets To create a snippet, add a.snippet file to the.forestry/snippets directory in your repository. Run Settings; Language: Plaintext: Snippet Metadata; Owner: d3ddy.alex: Created: Modified: Visibility: Public.
This page is a list of all commands, subcommands, and valid arguments that Avrae can parse. Avrae's command system is split into distinct modules. Snippets lets you run any R code through your browser. No installation, no downloads, no accounts, no payments. Over three thousand packages come preinstalled.
The NGINX-based Ingress Controller has additional configuration options and features that can be customized. The functionality is split into two categories:
- Per-Service options in each Ingress' YAML definition either directly or via Annotations.
- Global options that influence all Ingresses of a cluster via a ConfigMap.
Note: Some Giant Swarm clusters do not come with an ingress controller pre-installed. See our guide on how to install an ingress from the Giant Swarm Catalog.
Per-Service options
Aggregating Ingresses
You can aggregate several Ingress rules into a single Ingress definition like following:
Note: If you are using TLS you also need each of the hosts in the tls section (see below) of the yaml.
Path Based Fanout
You can route an Ingress to different Services based on the path:
Note: Your applications need to be capable of running on a non-root path either by default or by setting the base path in their configuration.
TLS
If your cluster has TLS enabled, you can terminate TLS either in your application itself by enabling SSL passthrough or let the Ingress Controller terminate for you.
SSL passthrough
Warning: This feature was disabled by default in Nginx ingress controller managed by Giant Swarm. Reason is a potential crash of internal TCP proxier. We recommend to terminate TLS in ingress controller instead.
For SSL passthrough you need to set an annotation and enable TLS for the host:
Note: SSL passthrough cannot work with path based routing based on the nature of SSL.
Terminating TLS in Ingress Controller
For terminating TLS in the Ingress Controller you need to first create a TLS secret containing your certificate and private key in the same namespace as the Ingress object:
Note: the data keys must be named tls.crt and tls.key!
Referencing this secret in an Ingress will tell the Ingress Controller to secure the channel from the client to the loadbalancer using TLS:
Warning: When enabling TLS with the NGINX Ingress Controller, some more configuration settings become important. Notably HSTS will be enabled by default with a duration of six month for your specified domain. Once a browser retrieved these HSTS instructions it will refuse to read any unencrypted resource from that domain and un-setting HSTS on your server will not have any affect on that browser for half a year. So you might want to disable this at first to avoid unwanted surprises. Please contact our support team to find out details on how to disable HSTS in your cluster.
Tip: If you want to use Let's Encrypt certificates with your domains you can automate their creation and renewal with the help of cert-manager. After configuring cert-manager there is only an annotation with your Ingresses needed and your web page will be secured by a valid TLS certificate.
Authentication
The Ingress Controller includes support for adding authentication to an Ingress rule. You have the choice between basic or digest http authentication types.
First, you need to create a file called auth containing your usernames and passwords (one per line). You can do this either by using the htpasswd command line tool (like in the following example) or an online htpasswd generator.
You can add users to the same file with:
Next, we create a secret containing our auth file:
Last, we create the Ingress with the according annotations:
External Authentication
To use an existing service that provides authentication the Ingress rule can be annotated with nginx.ingress.kubernetes.io/auth-url to indicate the URL where the HTTP request should be sent. Additionally it is possible to set nginx.ingress.kubernetes.io/auth-method to specify the HTTP method to use (GET or POST).
This functionality is based on the auth_request module, which expects a 2xx response code from the external service if the access is allowed and 401 or 403 if denied.
CORS
To enable Cross-Origin Resource Sharing (CORS) in an Ingress rule add the annotation ingress.kubernetes.io/enable-cors: 'true'.
Rewrite
Code Snippet Ios
In some scenarios the exposed URL in the backend service differs from the specified path in the Ingress rule. Without a rewrite any request will return 404. To circumvent this you can set the annotation ingress.kubernetes.io/rewrite-target to the path expected by the service.
This can for example be used together with path based routing, when the application expects to be on /:
If the application contains relative links it is possible to add an additional annotation ingress.kubernetes.io/add-base-url that will prepend a base tag in the header of the returned HTML from the backend.
Rate limiting
The annotations ingress.kubernetes.io/limit-connections and ingress.kubernetes.io/limit-rps define a limit on the connections that can be opened by a single client IP address. This can be used to mitigate DDoS Attacks.
nginx.ingress.kubernetes.io/limit-connections: number of concurrent connections allowed from a single IP address.
nginx.ingress.kubernetes.io/limit-rps: number of connections that may be accepted from a given IP each second.
If you specify both annotations in a single Ingress rule, limit-rps takes precedence.
Secure backends
By default NGINX uses http to reach the services. Adding the annotation nginx.ingress.kubernetes.io/backend-protocol: 'HTTPS' in the Ingress rule changes the protocol to https.
Server-side HTTPS enforcement through redirect
By default the controller redirects (301) to HTTPS if TLS is enabled for that Ingress. If you want to disable that behaviour, you can use the nginx.ingress.kubernetes.io/ssl-redirect: 'false' annotation.
Whitelist source range
You can specify the allowed client IP source ranges through the nginx.ingress.kubernetes.io/whitelist-source-range annotation. The value is a comma separated list of CIDRs, e.g. 10.0.0.0/24,172.10.0.1.
Note: Adding an annotation to an Ingress rule overrides any global restrictions set in the NGINX Ingress Controller.
Custom max body size
A 413 error will be returned to the client when the size in a request exceeds the maximum allowed size of the client request body. This size can be configured by the parameter client_max_body_size and is set to 1m (1 Megabyte) by default.
To configure this setting globally for all Ingress rules, the proxy-body-size value may be set in the NGINX ConfigMap.
To use custom values in a specific Ingress add following annotation:
Session Affinity
The annotation nginx.ingress.kubernetes.io/affinity enables and sets the affinity type in all upstreams of an Ingress. This way, a request will always be directed to the same upstream server.
Cookie affinity
If you use the cookie type you can also specify the name of the cookie that will be used to route the requests with the annotation nginx.ingress.kubernetes.io/session-cookie-name. The default is to create a cookie named route.
The annotation nginx.ingress.kubernetes.io/session-cookie-hash defines which algorithm will be used to hash the used upstream. Default value is md5 and possible values are md5, sha1 and index.
The index option is not hashed, an in-memory index is used instead, it's quicker and the overhead is shorter. Warning: The matching against the upstream servers list is inconsistent. So, at reload, if upstreams servers have changed, index values are not guaranted to correspond to the same server as before! Use with caution and only if you need to!
This feature is implemented by the third party module nginx-sticky-module-ng. The workflow used to define which upstream server will be used is explained in the module documentation (PDF).
Configuration snippets
The NGINX Ingress Controller creates an NGINX configuration file. You can directly pass chunks of configuration, so-called configuration snippets, into any ingress manifest. These snippets will be added to the NGINX configuration.
Here is an example adding an Expires header to every response:
Make sure to use the exact annotation scheme nginx.ingress.kubernetes.io/configuration-snippet in the metadata section of the manifest.
Check out the ingress-nginx repository for more information.
In case you want to set up a general http snippet you can define it at NGINX ConfigMap level.
Global (per cluster) options
Your Giant Swarm installation comes with a default configuration for the Ingress Controller.
You can override these defaults by setting your per cluster configuration in the form of a ConfigMap named nginx-ingress-controller-user-values.
Macbooster 8 key. Depending on the release version of your Tenant Cluster, this ConfigMap is located either in the Tenant Cluster or in the Control Plane.
Where is the user values ConfigMap
Given the cluster you are trying to configure has id: 123ab
Release Version 9.0.1 and greater:
If your cluster is on release version 9.0.1 or greater then you will find the nginx-ingress-controller-user-values ConfigMap on the Control Plane in the 123ab namespace:
Upgrading from 9.0.0 to a higher release will automatically migrate these user values from the Tenant Cluster to theControl Plane for you. If you have any automation or existing workflows you should keep this location change in mind.
Release Version 9.0.0 and below:
If the cluster has a release version equal to 9.0.0 or lower, then you will find the nginx-ingress-controller-user-values ConfigMap on the Tenant Cluster itself in the kube-system namespace:
Warning:
Please do not edit any of the other NGINX ingress related ConfigMaps.
Microsoft Snippet Download
Only the user ConfigMap is safe to edit.
How to set configuration options using the user values ConfigMap
The values that you are allowed to configure will depend on the release version of your cluster.As of 9.0.1 and above, you have much more freedom to configure any option available, however keep in mindthat with great power comes great responsibility.
9.0.1 and greater
On release version 9.0.1 and greater you are able to set any value from the upstream documentation by including them in the user values ConfigMap under the data.values field like so:
Any defaults that we override are visible in the following values.yaml file, under the configmap key. Check this values.yaml file in v1.6.10 as an example.
Do make sure you look at the right tag of that repository, when reading this file check that the tagcorresponds to the version of the nginx-ingress-controller-app running on your cluster.
9.0.0 and below
On release version 9.0.0 and below you can only configure a specific subset of the standard nginx configuration options, which we default as follows. If you need any other upstream documented option added to this list, please contact support.
To edit one of these values, include it in the data field of the nginx-ingress-controller-user-values ConfigMap in thekube-system namespace of the tenant cluster:
Do not copy all the defaults if you do not need to change them, that way we can adjust them in case they need to change.
On cluster creation the ConfigMap is empty and the above defaults will be applied to the final Ingress Controller deployment.
Warning:
We also allow setting use-proxy-protocol: 'true'/'false'. This setting always applies globally for the nginx-ingress-controller. All applications providing services behind ingresses need to understand this protocol or they will fail. Furthermore, the load balancer in front of the ingress controller also needs to be set up correctly. So currently, customizing this setting only makes sense on bare metal installations and will require a matching configuration on the load balancers.
When you want to have the default server on the nginx controller support TLS you need to provide a certificate. This is configured using the flag --default-ssl-certificate. Now you can provide this value in the user values ConfigMap to force the component to be restarted with the provided certificate. The value of the property should be the namespace and secret name which holds the certificate content.
Text Snippet Ios
By default we use the standard annotation prefix nginx.ingress.kubernetes.io in the ingress controller. In case the customer needs to have a specific one this can be done via the user values ConfigMap. This is recommended when there is more than one ingress controller. So in the ingress resource the prefix can be used to distinguish between controllers.
Snippet Io Games
Further reading
Need help, got feedback?Code Snippet Ios App
We listen in your Slack support channel. You can also reach us at support@giantswarm.io. And of course, we welcome your pull requests!
