b06c994c9d
The pod was crash-looping because Stalwart's security configuration blocks the kubelet's IP (10.244.4.1) from accessing the HTTP health endpoints. The kubelet's health checks were failing, causing the startup probe to fail after 6 attempts, leading to pod restarts. Changed all three health probes (startup, liveness, readiness) from httpGet to exec with curl localhost. This bypasses the IP blocking since the health check runs from inside the container using localhost, which is not subject to Stalwart's external IP blocking rules. This fix is non-destructive to Stalwart's configuration and state. The pod will restart once with the new probe configuration, but no data or configuration will be lost. Root cause: Stalwart logs showed "Blocked IP address (security.ip-blocked) listenerId=http, remoteIp=10.244.4.1" followed by "Shutting down Stalwart Server (server.shutdown) causedBy=SIGTERM" in a repeating pattern. Fixes: DEV-420 Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|---|---|---|
| .. | ||
| argocd | ||
| basicstack-org | ||
| bookstack | ||
| directus | ||
| dozzle | ||
| forgejo | ||
| forgejo-runner | ||
| harbor | ||
| headlamp | ||
| opencloud | ||
| pangolin | ||
| paperclip | ||
| passbolt | ||
| platform-prod | ||
| pocket-id | ||
| stalwart | ||
| app-argocd.yaml | ||
| app-basicstack-org.yaml | ||
| app-bookstack.yaml | ||
| app-directus.yaml | ||
| app-dozzle.yaml | ||
| app-forgejo-runner.yaml | ||
| app-forgejo.yaml | ||
| app-harbor.yaml | ||
| app-headlamp.yaml | ||
| app-opencloud.yaml | ||
| app-pangolin.yaml | ||
| app-paperclip.yaml | ||
| app-passbolt.yaml | ||
| app-platform-prod.yaml | ||
| app-pocket-id.yaml | ||
| app-stalwart.yaml | ||
| ARGOCD-MIGRATION.md | ||
| README.md | ||
Applications
This directory contains deployment configurations for all applications running on the basicstack.de cluster.
ArgoCD Application Management
Each application has two types of files:
app-<name>.yaml: ArgoCD Application manifest that tells ArgoCD to sync the app subdirectory<name>/: Application-specific Kubernetes manifests and configuration
The app-*.yaml files are synced by ArgoCD and create/manage the corresponding Application resources.
Each application's manifests in its subdirectory are then synced by its Application resource.
Structure
Each application should have its own subdirectory containing:
- Kubernetes manifests: Deployment, StatefulSet, Service, ConfigMap, Secret definitions
- Helm values: If using Helm charts, include values.yaml files
- Configuration files: Application-specific configs (TOML, JSON, YAML)
- Documentation: README or guide specific to the application deployment
- Patches: Any kubectl patches or modifications needed
Example: Stalwart
The stalwart/ directory serves as a reference implementation, containing:
- Multiple deployment variants (basic, with OIDC, etc.)
- Helm values files
- Monitoring dashboard configurations
- Backup/restore procedures
- Operational documentation
Adding a New Application
- Create a new directory:
apps/<application-name>/ - Add your Kubernetes manifests
- Include a README.md explaining:
- What the application does
- How to deploy it
- Configuration options
- Troubleshooting steps
- Test the deployment in a dev environment
- Commit with a descriptive message
Naming Conventions
- Directory names: lowercase, hyphen-separated (e.g.,
my-app) - Manifest files: descriptive names indicating resource type (e.g.,
deployment.yaml,service.yaml) - Use consistent naming across applications