mirror of
https://github.com/hanzoai/ingress.git
synced 2026-10-30 14:58:23 +00:00
Hanzo CI/CD / cicd (push) Failing after 9m46s
CI/CD / cicd (push) Failing after 10m4s
Most of it was stale, not cosmetic: the docs taught `TRAEFIK_*` env, `traefik.http.*` labels, `traefik.ingress.kubernetes.io/` annotations, `.traefik.yml` plugins and `traefik_*` metrics. This binary answers to `INGRESS_*`, `ingress.http.*`, `ingress.kubernetes.io/`, `.ingress.yml` and `ingress.*` — a reader following the old text configured nothing. Two were worse than stale. Gateway API examples gave `group: traefik.io` for an IngressService backendRef, which kubernetes.go:1265 refuses against hanzo.ai. The contributing guide built with `github.com/traefik/ingress` ldflags against a module that is `github.com/hanzoai/ingress/v3`. script/code-gen.sh globs `hanzo.ai_*.yaml` and matched nothing — the per-CRD dumps had been deleted and never regenerated, so `cat` failed the script under `set -e`. controller-gen v0.19.0 restores all ten; they concatenate byte-for-byte into the committed definition and fixture. CHANGELOG.md is untouched: 6,789 lines of imported release history, where a rewrite would falsify the record rather than rebrand it. `@traefiklabs/faency`, `traefik/whoami`, k3s's `--disable=traefik`, the `traefik.io` CRD group and the MIT attribution stay — upstream's addresses, not our brand. Co-authored-by: Hanzo Dev <[email protected]>
3.4 KiB
3.4 KiB
title, description
| title | description |
|---|---|
| Hanzo Ingress TCP Middleware Overview | Read the official Hanzo Ingress documentation for an overview of the available TCP middleware. |
TCP Middleware Overview
Attached to the routers, pieces of middleware are a means of tweaking the requests before they are sent to your service (or before the answer from the services are sent to the clients).
There are several available middlewares in Hanzo Ingress, some can modify the request, the headers, some are in charge of redirections, some add authentication, and so on.
Middlewares that use the same protocol can be combined into chains to fit every scenario.
Configuration Example
# As YAML Configuration File
tcp:
routers:
router1:
service: myService
middlewares:
- "foo-ip-allowlist"
rule: "Host(`example.com`)"
middlewares:
foo-ip-allowlist:
ipAllowList:
sourceRange:
- "127.0.0.1/32"
- "192.168.1.7"
services:
service1:
loadBalancer:
servers:
- address: "10.0.0.10:4000"
- address: "10.0.0.11:4000"
# As TOML Configuration File
[tcp.routers]
[tcp.routers.router1]
service = "myService"
middlewares = ["foo-ip-allowlist"]
rule = "Host(`example.com`)"
[tcp.middlewares]
[tcp.middlewares.foo-ip-allowlist.ipAllowList]
sourceRange = ["127.0.0.1/32", "192.168.1.7"]
[tcp.services]
[tcp.services.service1]
[tcp.services.service1.loadBalancer]
[[tcp.services.service1.loadBalancer.servers]]
address = "10.0.0.10:4000"
[[tcp.services.service1.loadBalancer.servers]]
address = "10.0.0.11:4000"
labels:
# Create a middleware named `foo-ip-allowlist`
- "ingress.tcp.middlewares.foo-ip-allowlist.ipallowlist.sourcerange=127.0.0.1/32, 192.168.1.7"
# Apply the middleware named `foo-ip-allowlist` to the router named `router1`
- "ingress.tcp.routers.router1.middlewares=foo-ip-allowlist@docker"
{
//...
"Tags" : [
// Create a middleware named `foo-ip-allowlist`
"ingress.tcp.middlewares.foo-ip-allowlist.ipallowlist.sourcerange=127.0.0.1/32, 192.168.1.7",
// Apply the middleware named `foo-ip-allowlist` to the router named `router1`
"ingress.tcp.routers.router1.middlewares=foo-ip-allowlist@consulcatalog"
]
}
---
apiVersion: hanzo.ai/v1alpha1
kind: MiddlewareTCP
metadata:
name: foo-ip-allowlist
spec:
ipAllowList:
sourcerange:
- 127.0.0.1/32
- 192.168.1.7
---
apiVersion: hanzo.ai/v1alpha1
kind: IngressRouteTCP
metadata:
name: ingressroute
spec:
# more fields...
routes:
# more fields...
middlewares:
- name: foo-ip-allowlist
Available TCP Middlewares
| Middleware | Purpose | Area |
|---|---|---|
| InFlightConn | Limits the number of simultaneous connections. | Security, Request lifecycle |
| IPAllowList | Limit the allowed client IPs. | Security, Request lifecycle |