admin widget zu dokploy geswitched
This commit is contained in:
Codex Agent
@@ -1,93 +0,0 @@
|
||||
# Coolify Deployment Guide
|
||||
|
||||
Coolify provides a managed Docker host with service orchestration, logs, metrics, CI hooks, and secret management. This document outlines how to run Fotospiel (including the Photobooth FTP stack) on Coolify and how to prepare for SuperAdmin observability.
|
||||
|
||||
## 1. Services to deploy
|
||||
|
||||
| Service | Notes |
|
||||
|---------|-------|
|
||||
| **Laravel App** | Build from this repo. Expose port 8080. Attach environment variables from `.env`. |
|
||||
| **Scheduler** | Clone the app container; command `php artisan schedule:work`. |
|
||||
| **Queue workers** | Use `docs/queue-supervisor/queue-worker.sh` scripts (default, media-storage, media-security). |
|
||||
| **Horizon (optional)** | Add service executing `docs/queue-supervisor/horizon.sh`. |
|
||||
| **Redis / Database** | Use Coolify managed services or bring your own (RDS/Aurora). |
|
||||
| **vsftpd container** | Host FTP on port 2121 and mount the shared Photobooth volume. |
|
||||
| **Photobooth Control Service** | Lightweight API (Go/Node/Laravel Octane) that Coolify can redeploy alongside vsftpd. |
|
||||
|
||||
### Volumes
|
||||
|
||||
- `storage-app` (Laravel `storage`, uploads, compiled views).
|
||||
- `photobooth` (shared between vsftpd, control-service, and Laravel).
|
||||
- Database/Redis volumes if self-hosted.
|
||||
|
||||
Mount these volumes in Coolify under “Persistent Storage” for each service.
|
||||
|
||||
## 2. Environment & Secrets
|
||||
|
||||
Configure the following keys inside Coolify’s “Environment Variables” panel:
|
||||
|
||||
- All standard Laravel vars (`APP_KEY`, `DB_*`, `QUEUE_CONNECTION`, `AWS_*` etc.).
|
||||
- Photobooth block (as documented in `.env.example`): `PHOTOBOOTH_CONTROL_*`, `PHOTOBOOTH_FTP_HOST/PORT`, `PHOTOBOOTH_IMPORT_*`.
|
||||
- New Coolify integration vars (planned for SuperAdmin widgets):
|
||||
|
||||
```
|
||||
COOLIFY_API_BASE_URL=https://coolify.example.com/api/v1
|
||||
COOLIFY_API_TOKEN=... # generated per project
|
||||
COOLIFY_SERVICE_IDS={"app":"svc_xxx","ftp":"svc_yyy"}
|
||||
```
|
||||
|
||||
Store the JSON mapping so Laravel knows which Coolify “service” controls the app, queue, vsftpd, etc.
|
||||
|
||||
## 3. Deploy steps
|
||||
|
||||
1. Add the Git repository to Coolify (build hook). Configure the Dockerfile build args if needed.
|
||||
2. Define services:
|
||||
- **App**: HTTP worker (build & run). Health check `/up`.
|
||||
- **Scheduler**: same image, command `php artisan schedule:work`.
|
||||
- **Queue**: command `/var/www/html/docs/queue-supervisor/queue-worker.sh default`.
|
||||
- Additional queue types as separate services.
|
||||
3. Configure networks so all services share the same internal bridge, allowing Redis/DB connectivity.
|
||||
4. Attach the `photobooth` volume to both vsftpd and the Laravel app.
|
||||
5. Run `php artisan migrate --force` from Coolify’s “One-off command” console after the first deploy.
|
||||
6. Seed storage targets if necessary (`php artisan db:seed --class=MediaStorageTargetSeeder --force`).
|
||||
|
||||
## 4. Metrics & Controls for SuperAdmin
|
||||
|
||||
To surface Coolify data inside the platform:
|
||||
|
||||
1. **API Token** – create a Coolify PAT with read access to services and optional “actions” scope.
|
||||
2. **Laravel config** – introduce `config/coolify.php` with base URL, token, and service IDs.
|
||||
3. **Service client** – wrap Coolify endpoints:
|
||||
- `GET /services/{id}` → CPU/RAM, status, last deploy, git SHA.
|
||||
- `POST /services/{id}/actions/restart` for restart buttons.
|
||||
- `GET /deployments/{id}/logs` for tailing last deploy logs.
|
||||
4. **Filament widgets** – in SuperAdmin dashboard add:
|
||||
- **Platform Health**: per service status (App, Queue, Scheduler, vsftpd, Control Service).
|
||||
- **Recent Deploys**: table of the last Coolify deployments and commit messages.
|
||||
- **Actions**: buttons (with confirmations) to restart vsftpd or re-run `photobooth:ingest` service.
|
||||
|
||||
Ensure all requests are audited (database table) and require SuperAdmin role.
|
||||
|
||||
## 5. FTP container controls
|
||||
|
||||
Coolify makes it easier to:
|
||||
|
||||
- View vsftpd metrics (CPU, memory, network) directly; replicate those values in SuperAdmin via the API.
|
||||
- Trigger redeploys of the vsftpd service when Photobooth settings change (Laravel can call Coolify’s redeploy endpoint).
|
||||
- Inspect container logs from SuperAdmin by proxying `GET /services/{id}/logs?tail=200`.
|
||||
|
||||
## 6. Monitoring & Alerts
|
||||
|
||||
- Configure Coolify Webhooks (Deploy succeeded/failed, service unhealthy) → point to a Laravel route, mark incidents in `photobooth_metadata`.
|
||||
- Use Coolify’s built-in notifications (Slack, email) for infrastructure-level alerts; complement with Laravel notifications for application-level events (e.g., ingest failures).
|
||||
|
||||
## 7. Production readiness checklist
|
||||
|
||||
1. All services built and running in Coolify with health checks.
|
||||
2. Volumes backed up (database snapshots + `storage` tarball).
|
||||
3. Photobooth shared volume mounted & writeable by vsftpd + Laravel.
|
||||
4. Environment variables set (APP_KEY, DB creds, Photobooth block, Coolify API token).
|
||||
5. Scheduler & queue services logging to Coolify.
|
||||
6. SuperAdmin Filament widgets wired to Coolify API (optional but recommended).
|
||||
|
||||
With this setup you can manage deployments, restarts, and metrics centrally while still using Laravel’s built-in scheduler and worker scripts. The next step is implementing the `CoolifyClient` + Filament widgets described above.
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
This guide describes the recommended, repeatable way to run the Fotospiel platform in Docker for production or high-fidelity staging environments. It pairs a multi-stage build (PHP-FPM + asset pipeline) with a Compose stack that includes Nginx, worker processes, Redis, and MySQL.
|
||||
|
||||
> **Coolify users:** see `docs/deployment/coolify.md` for service definitions, secrets, and how to wire the same containers (web, queue, scheduler, vsftpd) inside Coolify. That document builds on the base Docker instructions below.
|
||||
> **Dokploy users:** see `docs/deployment/dokploy.md` for service definitions, secrets, and how to wire the same containers (web, queue, scheduler, vsftpd) inside Dokploy. That document builds on the base Docker instructions below.
|
||||
|
||||
## 1. Prerequisites
|
||||
|
||||
|
||||
122
docs/deployment/dokploy.md
Normal file
122
docs/deployment/dokploy.md
Normal file
@@ -0,0 +1,122 @@
|
||||
# Dokploy Deployment Guide
|
||||
|
||||
Dokploy is our self-hosted PaaS for orchestrating the Fotospiel stack (Laravel app, scheduler, queue workers, Horizon, and the Photobooth FTP pipeline). This guide explains how to provision the services in Dokploy and how to wire the SuperAdmin observability widgets that now talk to the Dokploy API.
|
||||
|
||||
## 1. Services to provision
|
||||
|
||||
| Service | Notes |
|
||||
|---------|-------|
|
||||
| **Laravel App** | Build from this repository. Expose port 8080 (or Dokploy HTTP service). Attach the production `.env`. Health check `/up`. |
|
||||
| **Scheduler** | Clone the app container; command `php artisan schedule:work`. |
|
||||
| **Queue workers** | Use `docs/queue-supervisor/queue-worker.sh` scripts (default, media-storage, media-security). Deploy each as a dedicated Dokploy application or Docker service. |
|
||||
| **Horizon (optional)** | Run `docs/queue-supervisor/horizon.sh` for dashboard + metrics. |
|
||||
| **Redis / Database** | Use managed offerings or self-host in Dokploy. Configure network access for the app + workers. |
|
||||
| **vsftpd container** | Expose port 2121 and mount the shared Photobooth volume. |
|
||||
| **Photobooth Control Service** | Lightweight API (Go/Node/Laravel Octane) that can be redeployed together with vsftpd for ingest controls. |
|
||||
|
||||
### Volumes
|
||||
|
||||
Create persistent volumes inside Dokploy and mount them across the services:
|
||||
|
||||
- `storage-app` – Laravel `storage`, uploads, compiled views.
|
||||
- `photobooth` – shared by vsftpd, the control service, and Laravel for ingest.
|
||||
- Database / Redis volumes if you self-manage those containers.
|
||||
|
||||
## 2. Environment & secrets
|
||||
|
||||
Every Dokploy application should include the regular Laravel secrets (see `.env.example`). Important blocks:
|
||||
|
||||
- `APP_KEY`, `APP_URL`, `DB_*`, `CACHE_DRIVER`, `QUEUE_CONNECTION`, `MAIL_*`.
|
||||
- Photobooth integration (`PHOTOBOOTH_CONTROL_*`, `PHOTOBOOTH_FTP_*`, `PHOTOBOOTH_IMPORT_*`).
|
||||
- AWS / S3 credentials if the tenant media is stored remotely.
|
||||
|
||||
### Dokploy integration variables
|
||||
|
||||
Add the infrastructure observability variables to the Laravel app environment:
|
||||
|
||||
```
|
||||
DOKPLOY_API_BASE_URL=https://dokploy.example.com/api
|
||||
DOKPLOY_API_KEY=pat_xxxxxxxxxxxxxxxxx
|
||||
DOKPLOY_WEB_URL=https://dokploy.example.com
|
||||
DOKPLOY_APPLICATION_IDS={"app":"app_123","queue":"app_456","scheduler":"app_789","ftp":"app_abc"}
|
||||
DOKPLOY_API_TIMEOUT=10
|
||||
```
|
||||
|
||||
- `DOKPLOY_APPLICATION_IDS` is a JSON object mapping human labels to Dokploy `applicationId` values. Those IDs drive the SuperAdmin widget buttons.
|
||||
- The API key needs permission to read the project, query deployments, and trigger `application.redeploy` / `application.reload`.
|
||||
|
||||
## 3. Project & server setup
|
||||
|
||||
1. **Register the Docker host** in Dokploy (`Servers → Add Server`). Install the Dokploy agent on the target VM.
|
||||
2. **Create a Project** (e.g., `fotospiel-prod`) to group all services.
|
||||
3. **Attach repositories** using Dokploy Git providers (GitHub / Gitea / GitLab / Bitbucket) or Docker images. Fotospiel uses the source build (Dockerfile at repo root).
|
||||
4. **Networking** – keep all services on the same internal network so they can talk to Redis/DB. Expose the public HTTP service only for the Laravel app (behind Traefik/Let’s Encrypt).
|
||||
|
||||
## 4. Deploy applications
|
||||
|
||||
Follow these steps for each component:
|
||||
|
||||
1. **Laravel HTTP app**
|
||||
- Build from the repo.
|
||||
- `Dockerfile` already exposes port `8080`.
|
||||
- Set branch (e.g. `main`) for automatic deployments.
|
||||
- Add health check `/up`.
|
||||
- Mount `storage-app` and `photobooth` volumes.
|
||||
|
||||
2. **Scheduler**
|
||||
- Duplicate the image.
|
||||
- Override command: `php artisan schedule:work`.
|
||||
- Disable HTTP exposure.
|
||||
|
||||
3. **Queue workers**
|
||||
- Duplicate the image.
|
||||
- Commands:
|
||||
- `docs/queue-supervisor/queue-worker.sh default`
|
||||
- `docs/queue-supervisor/queue-worker.sh media-storage`
|
||||
- `docs/queue-supervisor/queue-worker.sh media-security`
|
||||
- Optionally create a dedicated container for Horizon using `docs/queue-supervisor/horizon.sh`.
|
||||
|
||||
4. **vsftpd + Photobooth control**
|
||||
- Deploy the ftp image (see `docker-compose` setup) or reuse Dokploy’s Docker Compose support.
|
||||
- Mount `photobooth` volume read-write.
|
||||
|
||||
5. **Database/Redis**
|
||||
- Dokploy can provision standard MySQL/Postgres/Redis apps. Configure credentials to match `.env`.
|
||||
|
||||
6. **Apply migrations**
|
||||
- Use Dokploy one-off command to run `php artisan migrate --force` on first deploy.
|
||||
- Seed storage targets if required: `php artisan db:seed --class=MediaStorageTargetSeeder --force`.
|
||||
|
||||
## 5. SuperAdmin observability (Dokploy API)
|
||||
|
||||
The SuperAdmin dashboard now uses the Dokploy API to fetch health data and trigger actions:
|
||||
|
||||
1. **Config file** – `config/dokploy.php` reads the environment variables above.
|
||||
2. **Client** – `App\Services\Dokploy\DokployClient` wraps key endpoints:
|
||||
- `GET /application.one?applicationId=...` → status + metadata.
|
||||
- `GET /application.readAppMonitoring?appName=...` → CPU & memory metrics.
|
||||
- `GET /deployment.all?applicationId=...` → latest deployments for history.
|
||||
- `POST /application.reload` (requires `applicationId` + `appName`).
|
||||
- `POST /application.redeploy` (redeploy latest commit).
|
||||
3. **Widgets / pages** – `DokployPlatformHealth` widget displays the mapped applications, and the `DokployDeployments` page exposes reload/redeploy buttons plus a log table (`InfrastructureActionLog`).
|
||||
4. **Auditing** – all actions persist to `infrastructure_action_logs` with user, payload, response, and status code.
|
||||
|
||||
Only SuperAdmins should have access to these widgets. If you rotate the API key, update the `.env` and deploy the app to refresh the cache.
|
||||
|
||||
## 6. Monitoring & alerts
|
||||
|
||||
- Dokploy already produces container metrics and deployment logs. Surface the most important ones (CPU, memory, last deployment) through the widget using the monitoring endpoint.
|
||||
- Configure Dokploy webhooks (Deploy succeeded/failed, health alerts) to call a Laravel route that records incidents in `photobooth_metadata` or sends notifications.
|
||||
- Use Dokploy’s Slack/email integrations for infrastructure-level alerts. Application-specific alerts (e.g., ingest failures) still live inside Laravel notifications.
|
||||
|
||||
## 7. Production readiness checklist
|
||||
|
||||
1. All applications deployed in Dokploy with health checks and attached volumes.
|
||||
2. `photobooth` volume mounted for Laravel + vsftpd + control service.
|
||||
3. Database/Redis backups scheduled (Dokploy snapshot or external tooling).
|
||||
4. `.env` contains the Dokploy API credentials and application ID mapping.
|
||||
5. Scheduler, workers, and Horizon logging visible in Dokploy.
|
||||
6. SuperAdmin widgets show green health states and allow reload/redeploy actions.
|
||||
7. Webhooks/alerts configured for failed deployments or unhealthy containers.
|
||||
|
||||
With this setup the Fotospiel team can manage deployments, restarts, and metrics centrally through Dokploy while Laravel’s scheduler and workers continue to run within the same infrastructure.
|
||||
@@ -118,14 +118,14 @@ When deploying new code:
|
||||
3. Recreate worker/horizon containers: `docker compose up -d --force-recreate queue-worker media-storage-worker horizon`.
|
||||
4. Tail logs to confirm workers boot cleanly and start consuming jobs.
|
||||
|
||||
### 8. Running inside Coolify
|
||||
### 8. Running inside Dokploy
|
||||
|
||||
If you host Fotospiel on Coolify:
|
||||
If you host Fotospiel on Dokploy:
|
||||
|
||||
- Create separate Coolify “services” for each worker type using the same image and command snippets above (`queue-worker.sh default`, `media-storage`, etc.).
|
||||
- Create separate Dokploy applications for each worker type using the same image and command snippets above (`queue-worker.sh default`, `media-storage`, etc.).
|
||||
- Attach the same environment variables and storage volumes defined for the main app.
|
||||
- Use Coolify’s “One-off command” feature to run migrations or `queue:retry`.
|
||||
- Expose the Horizon service through Coolify’s HTTP proxy (or keep it internal and access via SSH tunnel).
|
||||
- Enable health checks so Coolify restarts workers automatically if they exit unexpectedly.
|
||||
- Use Dokploy’s one-off command feature to run migrations or `queue:retry`.
|
||||
- Expose the Horizon service through the Dokploy HTTP proxy (or keep it internal and access via SSH tunnel).
|
||||
- Enable health checks so Dokploy restarts workers automatically if they exit unexpectedly.
|
||||
|
||||
These services can be observed and restarted from Coolify’s dashboard; the upcoming SuperAdmin integration will surface the same metrics/actions through a dedicated Filament widget.
|
||||
These services can be observed, redeployed, or reloaded from Dokploy’s dashboard and from the SuperAdmin integration powered by the Dokploy API.
|
||||
|
||||
Reference in New Issue
Block a user