Docker i kontenery

• Wersja komercyjna jest przygotowana do kompilacji (PyInstaller, Nuitka) z obfuskacją i ukrywaniem konsoli — to główny kierunek pakietu końcowego opisany w dokumentacji, a nie obraz OCI.
• Runtime: Python 3.10+ na hoście Windows z dostępem do SimConnect, SAPI5, Pygame — w kontenerze bez GPU/passthrough i bez MSFS te komponenty nie odtwarzają pełnego produktu.

• CI/CD — budowanie artefaktów, testy lint, skan zależności.
• Usługi satelitarne — jeśli w przyszłości pojawią się workery (np. przetwarzanie logów, webhook gateway) oddzielone od exe Julii.
• Pilot Hangar — deployment Next.js często jako kontener lub usługa zarządzana (Vercel, Cloud Run, Kubernetes) — inne niż exe Julii.

# Przykład: usługa pomocnicza lub batch — dostosuj do repo
FROM python:3.12-slim
ENV PYTHONDONTWRITEBYTECODE=1 PYTHONUNBUFFERED=1
WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY src/ ./src/
USER nobody
CMD ["python", "-m", "julia.tooling.example"]

Zasady

• Kopiuj requirements.txt przed kodem — cache warstw.
• Non-root tam, gdzie możliwe.
• Brak sekretów w obrazie — tylko env / secrets store w runtime.

Jeśli zespół używa MQTT dla komponentów JET/Hangar (patrz mqtt.md), typowy szkielet nie obejmuje pełnego klienta Julia+SimConnect — tylko usługi satelitarne. Poniżej referencyjny Compose łączący rdzeń workerowy z brokerem (dostosuj ścieżki do repo).

services:
  julia-core:
    build: ./services/julia-core
    env_file: .env.runtime
    restart: unless-stopped
    depends_on: [mqtt]
    networks: [hangar-internal]
    healthcheck:
      test: ["CMD", "python", "-c", "import sys; sys.exit(0)"]
      interval: 30s
      timeout: 5s
      retries: 3

  mqtt:
    image: eclipse-mosquitto:2
    volumes:
      - ./deploy/mosquitto.conf:/mosquitto/config/mosquitto.conf:ro
      - mosquitto-data:/mosquitto/data
    networks: [hangar-internal]
    ports:
      - "127.0.0.1:1883:1883"

volumes:
  mosquitto-data:

networks:
  hangar-internal:
    driver: bridge

Uwaga: usługa julia-core w powyższym szablonie oznacza worker/konsumenta MQTT lub narzędzie Python w kontenerze — nie zamienia aplikacji desktopowej Julii z PDF.

• Broker MQTT (jeśli używany) — nie wystawiaj na 0.0.0.0 w dev; produkcja za TLS/VPN.
• Hangar — port aplikacji web zgodnie z platformą hostingu.

• Sekrety: Docker / Kubernetes Secrets, nie warstwa obrazu.
• Logi: stdout → agregator; rotacja jeśli pliki lokalne.

• Liveness — proces żyje.
• Readiness — zależności (baza, broker) osiągalne — osobno od liveness.

1. docker build --pull
2. Skan CVE (Trivy, Grype)
3. Tagi: git sha → semver na release
4. Rollback: historia tagów w rejestrze

• Pinowanie digestów baz FROM python@sha256:… po walidacji.
• Bazy slim / distroless tam, gdzie możliwe.
• Regularne rebuildy z patchami OS.

deploy:
  resources:
    limits:
      cpus: "1.0"
      memory: 512M
    reservations:
      memory: 256M

Dostosuj pod profil edge vs serwer centralny.

• Kubernetes / Nomad / ECS — manifesty z limitami, PDB, affinity dla brokera.
• Restart policy: unless-stopped w Compose; w Kubernetes Deployment z replicas.

• Obraz nie zawiera kluczy API ani certyfikatów prywatnych.
• Zidentyfikowano, który komponent jest w kontenerze (Hangar vs worker vs nie pełny klient Julia+SimConnect).
• Healthcheck odzwierciedla realną gotowość usługi.
• Non-root tam, gdzie runtime pozwala; read-only root FS tam, gdzie możliwe.
• Logi na stdout; poziom logów konfigurowalny.
• Wersja obrazu identyfikowalna (/version lub APP_VERSION).