Documentation Refactor
This commit is contained in:
parent
3b8818e636
commit
a410b34521
47 changed files with 2065 additions and 3911 deletions
4
docs/concepts/_category_.json
Normal file
4
docs/concepts/_category_.json
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
{
|
||||
"label": "Concepts",
|
||||
"position": 3
|
||||
}
|
||||
103
docs/concepts/index.md
Normal file
103
docs/concepts/index.md
Normal file
|
|
@ -0,0 +1,103 @@
|
|||
---
|
||||
sidebar_position: 1
|
||||
sidebar_label: "Concepts"
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
This section explains how EasyHAProxy works under the hood — the mental models that help you understand why things are configured the way they are.
|
||||
|
||||
## Service Discovery
|
||||
|
||||
EasyHAProxy runs a polling loop every N seconds (default 10, configurable via `EASYHAPROXY_REFRESH_CONF`). On each tick it:
|
||||
|
||||
1. **Queries your runtime** — Docker API for containers/services, Kubernetes API for Ingress objects, or reads the static YAML file.
|
||||
2. **Filters by label/annotation prefix** — only resources that carry the `easyhaproxy` prefix (or your custom `EASYHAPROXY_LABEL_PREFIX`) are considered.
|
||||
3. **Builds an intermediate structure** — an in-memory list of (host, port, backend) tuples called `easymapping`.
|
||||
4. **Runs plugins** — global plugins run once; domain plugins run once per host entry.
|
||||
5. **Renders `haproxy.cfg`** from a Jinja2 template using the `easymapping` data.
|
||||
6. **Reloads HAProxy** if the rendered config differs from the previous one (zero-downtime reload).
|
||||
|
||||
### Discovery mode comparison
|
||||
|
||||
| Mode | Source polled | Auth required |
|
||||
|------|--------------|---------------|
|
||||
| `docker` | Docker socket `/var/run/docker.sock` | Socket access |
|
||||
| `swarm` | Docker socket (Swarm API) | Socket access |
|
||||
| `kubernetes` | Kubernetes API server | RBAC (`get`/`list` on Ingress, Secret) |
|
||||
| `static` | File on disk | None |
|
||||
|
||||
## Configuration Pipeline
|
||||
|
||||
```
|
||||
Labels / Annotations / YAML file
|
||||
↓
|
||||
Discovery (Docker / Swarm / K8s / Static)
|
||||
↓
|
||||
parsed_object { IP → label map }
|
||||
↓
|
||||
[GLOBAL PLUGINS] ← executed once
|
||||
↓
|
||||
easymapping [ list of domain configs ]
|
||||
↓
|
||||
For each domain:
|
||||
[DOMAIN PLUGINS] ← executed per domain
|
||||
↓
|
||||
PluginResult snippets collected
|
||||
↓
|
||||
Jinja2 template render → haproxy.cfg
|
||||
↓
|
||||
HAProxy reload (if config changed)
|
||||
```
|
||||
|
||||
The key insight: **you never write `haproxy.cfg` by hand**. You express intent through labels/annotations/YAML, and EasyHAProxy translates that into valid HAProxy configuration on every discovery cycle.
|
||||
|
||||
## Plugin Execution Model
|
||||
|
||||
Plugins are Python classes that implement `PluginInterface`. They are discovered automatically from:
|
||||
|
||||
1. `/src/plugins/builtin/` — bundled plugins
|
||||
2. `/etc/easyhaproxy/plugins/` — your custom plugins
|
||||
|
||||
**Two execution types:**
|
||||
|
||||
### GLOBAL plugins
|
||||
|
||||
- Run **once per discovery cycle**, before any domain processing.
|
||||
- Receive the full `parsed_object` (all discovered services).
|
||||
- Use cases: cleanup tasks, global monitoring, DNS updates.
|
||||
- Example: `cleanup` plugin.
|
||||
|
||||
### DOMAIN plugins
|
||||
|
||||
- Run **once per discovered domain/host**.
|
||||
- Receive domain-specific context: domain name, port, label/annotation map.
|
||||
- Return `PluginResult` containing HAProxy config snippets to inject into the backend section.
|
||||
- Use cases: IP whitelisting, JWT validation, Cloudflare IP restoration, path blocking.
|
||||
- Examples: `cloudflare`, `deny_pages`, `jwt_validator`, `ip_whitelist`, `fastcgi`.
|
||||
|
||||
**Configuration precedence** (highest to lowest):
|
||||
1. Container labels / Ingress annotations (per-domain)
|
||||
2. Static YAML `plugins.config` block
|
||||
3. Environment variables `EASYHAPROXY_PLUGIN_<NAME>_<KEY>`
|
||||
|
||||
See the [Plugin Developer Guide](../guides/plugin-development.md) for how to build your own plugin.
|
||||
|
||||
## SSL/TLS Termination Model
|
||||
|
||||
SSL termination happens **at HAProxy**, not in your backend containers.
|
||||
|
||||
```
|
||||
Internet → HAProxy (TLS decryption) → Backend container (plain HTTP)
|
||||
```
|
||||
|
||||
Your containers should only serve HTTP on their internal port. HAProxy handles all TLS on ports 80/443.
|
||||
|
||||
**Certificate sources** (evaluated in this order for each domain):
|
||||
1. **ACME/Certbot** — if `certbot=true` label is set, EasyHAProxy runs Certbot HTTP-01 challenge automatically.
|
||||
2. **Volume-mounted PEM** — files in `/etc/easyhaproxy/certs/haproxy/{domain}.pem`.
|
||||
3. **Label-embedded PEM** — base64 certificate in the `sslcert` label.
|
||||
|
||||
Both ACME and manual certificates can coexist. Per domain, whichever source is configured takes precedence as shown above.
|
||||
|
||||
See [SSL setup](../guides/ssl.md) and [ACME/Let's Encrypt](../guides/acme.md) for step-by-step configuration.
|
||||
39
docs/concepts/limitations.md
Normal file
39
docs/concepts/limitations.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
sidebar_label: "Limitations"
|
||||
---
|
||||
|
||||
# Limitations and Considerations
|
||||
|
||||
## EasyHAProxy will not work with --network=host
|
||||
|
||||
:::danger Network Mode Incompatibility
|
||||
The `--network=host` option **cannot** be used with EasyHAProxy due to its networking requirements.
|
||||
|
||||
EasyHAProxy needs to inspect and interact with Docker containers from within the Docker network where it's running. Using the `--network=host` option bypasses Docker networking, preventing EasyHAProxy from accessing and configuring containers effectively.
|
||||
:::
|
||||
|
||||
## Considerations for Multiple Replica Deployments in EasyHAProxy
|
||||
|
||||
:::warning Single Replica Deployment Recommended
|
||||
EasyHAProxy is designed for single replica deployment.
|
||||
:::
|
||||
|
||||
### What happens with multiple replicas?
|
||||
|
||||
EasyHAProxy can still operate with multiple replicas; however:
|
||||
|
||||
1. **Service Discovery**: Each replica will independently discover services, which may lead to temporary inconsistencies among replicas (out-of-sync for a few seconds).
|
||||
|
||||
2. **ACME/Certificate Issues**: Running multiple replicas creates significant problems with Let's Encrypt and other ACME certificate issuance:
|
||||
- Each replica will attempt to obtain its own certificate
|
||||
- ACME challenges may be directed to different replicas, causing failures
|
||||
- You may quickly hit certificate issuance rate limits
|
||||
- Certificate renewal may fail unpredictably
|
||||
|
||||
:::danger Recommendation
|
||||
If you need to run multiple replicas for high availability, **do not activate ACME/Let's Encrypt**. Instead, use manually managed certificates or an external certificate management solution.
|
||||
:::
|
||||
|
||||
----
|
||||
[Open source ByJG](http://opensource.byjg.com)
|
||||
Loading…
Add table
Add a link
Reference in a new issue