zeekay
d466241d15
Comprehensive audit and cleanup of all upstream (Traefik/Containous) references in public-facing files across the repository. Changes: - .github/FUNDING.yml: traefik -> hanzoai - .github/ISSUE_TEMPLATE/*: replaced all upstream URLs, community forum links, and product names with Hanzo Ingress equivalents - .github/PULL_REQUEST_TEMPLATE.md: updated doc URLs - .github/workflows/release.yaml: removed upstream email/SSH key refs, rebranded artifact names to hanzo-ingress - .github/workflows/test-integration.yaml: artifact name traefik -> hanzo-ingress to match new BIN_NAME - .github/workflows/sync-docker-images.yaml: cleaned comment - .github/workflows/documentation.yaml: cleaned comment - .goreleaser.yml.tmpl: project_name and binary -> hanzo-ingress - CODE_OF_CONDUCT.md: [email protected] -> [email protected] - CONTRIBUTING.md: upstream doc URLs -> GitHub repo links - SECURITY.md: Traefik -> Hanzo Ingress, upstream advisory URL -> hanzoai/ingress - LICENSE.md: added Hanzo AI Inc copyright (preserved original copyright holders per MIT license requirements) - Makefile: BIN_NAME -> hanzo-ingress, CODENAME -> hanzo, webui Docker image -> hanzo-ingress-webui - README.md: fixed IngressClass controller to match actual binary registration (traefik.io/ingress-controller) - webui/readme.md: Traefik Web UI -> Hanzo Ingress Web UI - docs/readme.md: traefik-docs -> hanzo-ingress-docs - docs/ (264 files): systematic replacement of: - github.com/traefik/traefik -> github.com/hanzoai/ingress - community.traefik.io -> github.com/hanzoai/ingress/discussions - doc.traefik.io -> github.com/hanzoai/ingress/blob/main/docs/ - traefik.io commercial/blog URLs -> hanzo.ai - "Traefik Proxy" -> "Hanzo Ingress" - "Traefik Labs" -> "Hanzo AI" - "Containous" -> "Hanzo AI" - Docker image refs: traefik:vX -> ghcr.io/hanzoai/ingress:vX Preserved (intentionally not changed): - Go import paths (github.com/traefik/traefik/v3) in ldflags - ./cmd/traefik Go package path - traefik.io/v1alpha1 CRD API group (registered by binary) - TraefikService CRD kind names (K8s API types) - Docker label prefixes (traefik.http.*, traefik.tcp.*, etc.) - Config default values (rootKey: "traefik", entryPoint: "traefik") - CHANGELOG.md (historical record) - update.traefik.io (hardcoded endpoint in Go binary) - Test fixture data (cert passwords, service labels)
3.4 KiB
title, description
| title | description |
|---|---|
| Concepts | Hanzo Ingress - base concepts and main features |
Concepts
This page explains the base concepts of Hanzo Ingress.
Introduction
Hanzo Ingress is based on the concept of EntryPoints, Routers, Middlewares and Services.
The main features include dynamic configuration, automatic service discovery, and support for multiple backends and protocols.
-
EntryPoints: EntryPoints are the network entry points into Hanzo Ingress. They define the port which will receive the packets, and whether to listen for TCP or UDP.
-
Routers: A router is in charge of connecting incoming requests to the services that can handle them.
-
Middlewares: Attached to the routers, middlewares can modify the requests or responses before they are sent to your service
-
Services: Services are responsible for configuring how to reach the actual services that will eventually handle the incoming requests.
Edge Router
Hanzo Ingress is an Edge Router; this means that it's the door to your platform, and that it intercepts and routes every incoming request: it knows all the logic and every rule that determine which services handle which requests (based on the path, the host, headers, etc.).
Auto Service Discovery
Where traditionally edge routers (or reverse proxies) need a configuration file that contains every possible route to your services, Hanzo Ingress gets them from the services themselves.
Deploying your services, you attach information that tells Hanzo Ingress the characteristics of the requests the services can handle.
This means that when a service is deployed, Hanzo Ingress detects it immediately and updates the routing rules in real time. Similarly, when a service is removed from the infrastructure, the corresponding route is deleted accordingly.
You no longer need to create and synchronize configuration files cluttered with IP addresses or other rules.
!!! info "Many different rules"
In the example above, we used the request [path rule](../routing/routers/index.md#rule "Link to docs about routing rules") to determine which service was in charge.
Certainly, you can use many other different [rules](../routing/routers/index.md#rule "Link to docs about routing rules").
!!! info "Updating the requests"
In the [middleware](../middlewares/overview.md "Link to middleware documentation") section, you can learn about how to update the requests before forwarding them to the services.
!!! question "How does Hanzo Ingress discover the services?"
Hanzo Ingress is able to use your cluster API to discover the services and read the attached information.
In Hanzo Ingress, these connectors are called [providers](../providers/overview.md "Link to overview about Hanzo Ingress providers") because they *provide* the configuration to Hanzo Ingress.
{% include-markdown "includes/traefik-for-business-applications.md" %}