Graham McIntire
d92443d91b
Enhanced base image build system with: Container Engine Support: - Auto-detect podman or docker (prefers podman if both installed) - All scripts work with either engine seamlessly - No configuration needed Docker Hub Integration: - Push to both GitLab and Docker Hub registries - GitLab: registry.gitlab.com/towerops/towerops/elixir-runtime - Docker Hub: docker.io/gmcintire/elixir-runtime - Both versioned and :latest tags pushed to each Build Script: - Detect and use $CONTAINER_CMD for all operations - Show which container engine is being used in output - Tag and push to both registries automatically Makefile: - Add CONTAINER_CMD variable with auto-detection - Add DOCKERHUB_REGISTRY configuration - Update all targets to use detected container engine - Add login-dockerhub target for Docker Hub authentication - Update push target to push to both registries Documentation: - Document podman/docker auto-detection - Update login instructions for both registries - Update troubleshooting with examples for both engines This makes the build system more flexible and accessible to users who prefer podman over docker, while also publishing to the public Docker Hub registry for easier access. |
||
|---|---|---|
| .. | ||
| base-image | ||
| certificate.yaml | ||
| deployment.yaml | ||
| Dockerfile | ||
| ingressroute.yaml | ||
| kustomization.yaml | ||
| namespace.yaml | ||
| poddisruptionbudget.yaml | ||
| README.md | ||
| service-headless.yaml | ||
| service.yaml | ||
Kubernetes Deployment
Secrets Management
Secrets are managed directly in the cluster and must be created before deploying the application.
Required secrets in the towerops namespace:
gitlab-registry- Docker registry credentials for pulling imagestowerops-secrets- Application secrets (RELEASE_COOKIE, SECRET_KEY_BASE)towerops-db- Database connection credentialstowerops-aws- AWS credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION)
For local development, the project root .envrc is used by direnv.
Deployment Timestamp
The application footer displays the deployment timestamp to track when the current version was deployed. This is automatically set by GitLab CI during deployment:
# GitLab CI sets this during deploy
- kubectl set env deployment/towerops DEPLOY_TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ") -n towerops
All pods in the deployment share the same timestamp (when the deployment was initiated), regardless of when individual pods were created. This is displayed in the footer as "Last deployed X ago · YYYY-MM-DD HH:MM:SS UTC".
For manual deployments without GitLab CI, set the timestamp:
kubectl set env deployment/towerops DEPLOY_TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ") -n towerops
Deploying
Apply all resources using kustomize:
kubectl apply -k k8s/
Or individually:
kubectl apply -f k8s/namespace.yaml
kubectl apply -f k8s/secret.yaml
kubectl apply -f k8s/deployment.yaml
kubectl apply -f k8s/service.yaml
kubectl apply -f k8s/service-headless.yaml
kubectl apply -f k8s/certificate.yaml
kubectl apply -f k8s/ingressroute.yaml