Move all Application manifests (app-*.yaml) out of apps/argocd/ to apps/ to avoid chicken-and-egg issue where Applications couldn't update themselves. Architecture: - apps/app-stack-basicstack-de.yaml: manages apps/** excluding argocd/** - apps/app-argocd.yaml: manages apps/argocd/** via kustomize - apps/app-basicstack-org.yaml: manages basicstack.org repo This enables full self-management: all Applications can sync their own configurations from git. Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|---|---|---|
| .. | ||
| argocd | ||
| backup | ||
| bookstack | ||
| directus | ||
| forgejo | ||
| opencloud | ||
| paperclip | ||
| passbolt | ||
| platform-prod | ||
| pocket-id | ||
| stalwart | ||
| app-argocd.yaml | ||
| app-basicstack-org.yaml | ||
| app-stack-basicstack-de.yaml | ||
| README.md | ||
Applications
This directory contains deployment configurations for all applications running on the basicstack.de cluster.
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