0 Fork 0

mirror of https://github.com/kevinveenbirkenbach/computer-playbook.git synced 2026-11-06 10:59:59 +00:00

Files

T

kevinveenbirkenbachandClaude Opus 4.7 79409ebf10 test(tooling): integrate markdownlint-cli2, ansible-lint, galaxy-importer + fix the resulting baseline

Tooling integration
* add .markdownlint-cli2.jsonc, .ansible-lint, .ansible-lint-ignore
  configs (permissive day-1: cosmetic rules disabled, semantic ones on)
* extend scripts/install/lint.sh with generic install_pip_pkg helper +
  ensure_ansible_lint / ensure_galaxy_importer / ensure_markdownlint_cli2
  ensure_* functions (pip / npm with sudo / --user / --break-system-packages
  fallbacks). install_ansible_tools now also pulls ansible-lint and
  galaxy-importer; new `markdown` install group.
* extend scripts/lint/ansible.sh to run ansible-lint after the existing
  syntax-check.
* add scripts/lint/markdown.sh and scripts/lint/galaxy.sh runners. The
  galaxy runner parallelizes via xargs (-P=$(nproc)), prints OK/FAIL per
  role, and treats `bare-name dependency` errors as success since our
  roles/ tree is not a Galaxy collection layout. All other Galaxy schema
  errors still fail.
* Makefile: new lint-markdown and lint-galaxy targets, both wired into
  `make lint`.
* CI: new workflows lint-markdown.yml and lint-galaxy.yml; lint-ansible.yml
  now installs ansible-core + ansible-lint; ci-orchestrator wires both
  new lint workflows into lint-gate.

Galaxy schema fixes
* shorten the canonical `galaxy_info.company` block from three lines to
  two ("Kevin Veen-Birkenbach\nhttps://www.veen.world", 45 chars) so it
  stays under Galaxy's hard 50-char limit. Updated everywhere: 229 role
  meta/main.yml plus _CANONICAL_COMPANY in
  tests/lint/repository/test_role_meta_main_galaxy_schema.py.
* shorten 19 over-long role descriptions to <=255 chars.
* add stub READMEs for sys-svc-compose-ca and sys-utils-service-loader.

Markdown baseline fixes
* markdownlint-cli2 --fix run repo-wide (formatting normalization
  across CHANGELOG, role READMEs, docs).
* manual MD041 fixes: prepend H1 in 15 files (CHANGELOG, LICENSE,
  TODO.md helpers, role README templates, etc.).
* MD025 / MD003 / MD001 / MD032 manual fixes for heading-style and
  list-spacing edge cases.
* role README content polish: "## Single Point of Truth (SPOT)" headings
  renamed to "## User data resolution" (D3 self-label rule).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-08 23:46:37 +02:00

3.2 KiB

Raw Permalink Blame History

NGINX vHost Templates: Basic vs. WebSocket (ws_generic)

This directory provides two NGINX server templates for reverse proxying Dockerized applications behind NGINX:

basic.conf.j2
ws_generic.conf.j2

When to Use Which Template?

1. `basic.conf.j2`

Use this template for standard HTTP/S applications.
It is optimized for typical web applications (e.g., static sites, PHP, Node.js, Django, etc.) that do not require persistent, bidirectional WebSocket connections.

Features:
- HTTP/2 support, TLS/SSL integration
- Reverse proxy with buffering enabled (proxy_buffering on)
- Allows advanced content filtering (e.g., via Lua body/headers)
- Suitable for most REST APIs, web frontends, and admin panels
Pros:
- Enables HTML/body manipulation (for injecting snippets, analytics, CSP, etc.)
- Optimized for efficient caching and GZIP compression
- Good default for "normal" web traffic
Cons:
- Not suitable for WebSocket endpoints (buffering can break WS)
- Slightly more latency for streaming data due to buffering

2. `ws_generic.conf.j2`

Use this template for applications requiring WebSocket support.
Designed for services (e.g., chat servers, real-time dashboards) needing fast, persistent connections using the WebSocket protocol.

Features:
- WebSocket-aware: proxy_buffering off, special upgrade headers
- Supports standard HTTP/S traffic alongside WebSockets
- Proper handling of connection upgrades and protocol switching
Pros:
- Required for all WebSocket endpoints
- Allows instant, low-latency bidirectional traffic
- Prevents data loss or connection drops due to proxy buffering
Cons:
- Disables body/content filtering and response manipulation
- No buffering means less effective for caching/optimization
- Not suitable for scenarios requiring Lua/JS content injection

Summary Table

Use Case	Template	Buffering	WebSocket?	Can Filter Content?
Static/Classic Website	`basic.conf.j2`	On	No	Yes
REST API	`basic.conf.j2`	On	No	Yes
Real-Time Chat/App	`ws_generic.conf.j2`	Off	Yes	No
Dashboard w/Live Data	`ws_generic.conf.j2`	Off	Yes	No
Needs HTML Injection	`basic.conf.j2`	On	No	Yes

Good to Know

Never enable buffering for true WebSocket connections!
Use proxy_buffering off; (as in ws_generic.conf.j2) or connections may fail.
For most classic web applications, use the basic template.
For apps where you want to inject or modify HTML (e.g., analytics scripts), only the basic template supports this.

Author & Project

By Kevin Veen-Birkenbach
Part of the Infinito.Nexus Project
Licensed under the Infinito.Nexus Community License (Non-Commercial)

3.2 KiB Raw Permalink Blame History