cleanup: remove Docker, Ansible, and deployment infrastructure

Removes unused deployment and packaging infrastructure:
- Dockerfile and docker-compose.yml (Docker deployment not used)
- ansible/ directory (playbooks, inventory, config)
- packages/@ansible/example/ (npm package for Ansible example)
- docs/deployment/ansible-package-deploy.md
- docs/plans/2026-04-24-002-fix-docker-compose-scheduler-plan.md (obsolete)
- .github/workflows/publish-ansible-example.yml
- .github/workflows/ci-node-packages.yml (only tested packages/)

Updates:
- README.md: remove Deployment section
- docs/plans/2026-04-24-ROADMAP-stemwijzer-improvements.md: mark P1-002 as removed, update sprint 1
This commit is contained in:
2026-05-04 19:11:37 +02:00
parent 1f053f7d91
commit a634ceba2d
19 changed files with 4 additions and 517 deletions
-42
View File
@@ -1,42 +0,0 @@
# Ansible package deploy (defaults)
This document describes the default values and recommended steps for deploying the `packages/@ansible/example` package to a server using the provided Ansible playbooks.
Defaults
- DEPLOY_HOST: `motief.sgeboers.nl`
- DEPLOY_USER: `webapps`
- Recommended systemd service name: `motief`
Secrets / environment variables
- DEPLOY_SSH_KEY: private SSH key used by CI to connect to the host
- DEPLOY_HOST: (override) host to deploy to
- DEPLOY_USER: (override) user to use for deployment (default: `webapps`)
- DEPLOY_PATH: (optional) path on the remote host to deploy the package to. If unset, the playbook will use its configured default. Set this value in CI if your installation directory differs from the playbook default.
Granting access (server-side steps)
1. As the server administrator, ensure the `webapps` user exists:
sudo useradd -m -s /bin/bash webapps
2. Create the `.ssh` directory and add the public key that matches your CI `DEPLOY_SSH_KEY`:
sudo -u webapps mkdir -p /home/webapps/.ssh
sudo -u webapps chmod 700 /home/webapps/.ssh
# paste the public key from your CI into /home/webapps/.ssh/authorized_keys
sudo -u webapps sh -c 'cat >> /home/webapps/.ssh/authorized_keys'
sudo -u webapps chmod 600 /home/webapps/.ssh/authorized_keys
3. If the playbook requires sudo operations, add the necessary sudoers entry (use with care):
echo "webapps ALL=(ALL) NOPASSWD: /bin/systemctl restart motief" | sudo tee /etc/sudoers.d/webapps-motief
Deployment notes
- The playbooks assume the above defaults. If your host, user or install path differ, set the appropriate environment variables in your CI (DEPLOY_HOST, DEPLOY_USER, DEPLOY_PATH) before running the deploy job.
- The recommended systemd service name is `motief`. If you change the service name in the playbook or systemd unit, ensure any helper scripts or CI steps refer to the same name.
Security
- Only add trusted public keys to `/home/webapps/.ssh/authorized_keys`.
- Limit sudo privileges to only the commands required for deploy/service restart.
Troubleshooting
- If the CI runner cannot connect, verify the private key in `DEPLOY_SSH_KEY` matches the public key on the server and the `DEPLOY_HOST`/`DEPLOY_USER` values are correct.
@@ -1,92 +0,0 @@
---
title: "fix: docker-compose.yml references missing scheduler.py"
type: fix
status: active
date: 2026-04-24
---
# Fix: docker-compose.yml Missing scheduler.py
## Overview
`docker-compose.yml` defines a `scheduler` service that runs `python scheduler.py`, but no `scheduler.py` exists in the repo. This causes `docker-compose up` to fail for the scheduler service.
## Problem Frame
- The scheduler service is a deployment bug
- Either the file was never created, or it was removed and the compose file was not updated
- The `schedule` dependency in pyproject.toml suggests automated scheduling was intended
## Requirements Trace
- R1. docker-compose.yml must reference only existing files
- R2. If scheduling is desired, create scheduler.py; if not, remove the service
## Scope Boundaries
**Included:**
- Fix docker-compose.yml
**Excluded:**
- Implementing actual scheduling logic (unless user confirms)
## Implementation Units
- [ ] U1. **Determine scheduler intent**
**Goal:** Decide whether to create scheduler.py or remove the service.
**Requirements:** R1, R2
**Dependencies:** None
**Files:**
- Read: `docker-compose.yml`, `pyproject.toml`
**Approach:**
- Check if `schedule` dependency is used anywhere
- Check if there's a scheduling script under another name
- Decision: If scheduling is not implemented, remove the service for now and create a plan for it later
**Test expectation:** none — decision unit.
**Verification:**
- Clear decision documented in this plan
---
- [ ] U2. **Apply fix**
**Goal:** Make docker-compose.yml valid.
**Requirements:** R1
**Dependencies:** U1
**Files:**
- Modify: `docker-compose.yml`
**Approach:**
- Option A: Remove scheduler service (if scheduling is deferred)
- Option B: Create minimal scheduler.py (if scheduling is desired now)
**Test scenarios:**
- Integration: `docker-compose config` validates without error
- Happy path: `docker-compose up motief` works (existing service unchanged)
**Verification:**
- `docker-compose config` passes
- No reference to missing scheduler.py
---
## Risks & Dependencies
| Risk | Mitigation |
|------|------------|
| Removing service breaks someone's workflow | Only remove if confirmed unused; otherwise create stub |
## Sources & References
- `docker-compose.yml`
- `pyproject.toml` (schedule dependency)
@@ -14,7 +14,7 @@ This roadmap captures 17 improvement opportunities identified during a codebase
| # | Improvement | Priority | Effort | Plan | TDD |
|---|------------|----------|--------|------|-----|
| 1 | Fix broken CI test workflow (mindmodel-schedule.yml references missing requirements.txt) | High | Small | P1-001 | Yes |
| 2 | Fix docker-compose.yml (missing scheduler.py) | High | Small | P1-002 | No (config) |
| 2 | ~~Fix docker-compose.yml (missing scheduler.py)~~*Removed: Docker deployment not used* | — | — | — | — |
| 3 | Consolidate duplicate config sources (config.py vs analysis/config.py) | Medium | Small | P1-003 | Yes |
| 4 | Rewrite README.md (22 lines → proper quickstart) | High | Small | P1-004 | No (docs) |
| 5 | Add pyright type-checking to CI | Medium | Small | P1-005 | Yes |
@@ -98,7 +98,7 @@ Phase 1 must come first. Phase 2 makes Phase 3/4 safer. Phase 3 unlocks some Pha
## Recommended Execution Order
**Sprint 1:** Items 1, 2, 4, 6 (CI + docs + pre-commit)
**Sprint 1:** Items 1, 4, 6 (CI + docs + pre-commit)
**Sprint 2:** Items 5, 7, 8 (type checking + logging + errors)
**Sprint 3:** Item 10 (explorer decomposition)
**Sprint 4:** Items 12, 15, 17 (pipeline automation + health checks)
@@ -111,7 +111,7 @@ Phase 1 must come first. Phase 2 makes Phase 3/4 safer. Phase 3 unlocks some Pha
| Plan ID | File | Status |
|---------|------|--------|
| P1-001 | docs/plans/2026-04-24-001-fix-ci-test-workflow-plan.md | Planned |
| P1-002 | docs/plans/2026-04-24-002-fix-docker-compose-scheduler-plan.md | Planned |
| P1-002 | ~~docs/plans/2026-04-24-002-fix-docker-compose-scheduler-plan.md~~ | Removed |
| P1-003 | docs/plans/2026-04-24-003-consolidate-config-sources-plan.md | Planned |
| P1-004 | docs/plans/2026-04-24-004-rewrite-readme-plan.md | Planned |
| P1-005 | docs/plans/2026-04-24-005-add-pyright-ci-plan.md | Planned |
@@ -127,5 +127,5 @@ Phase 1 must come first. Phase 2 makes Phase 3/4 safer. Phase 3 unlocks some Pha
## Notes
- All implementation plans use TDD (test-first) for code-bearing units.
- Config-only units (README, docker-compose fix) skip TDD but include verification checklists.
- Config-only units (README) skip TDD but include verification checklists.
- Existing plans (e.g., explorer decomposition) are referenced rather than duplicated.