Neuen Host provisionieren

Schritt-für-Schritt-Anleitung für das vollständige Aufsetzen einer neuen Kunden-Instanz — vom leeren Container bis zur laufenden Anwendung. Verlinkt zurück auf die architektonischen Detail-Dokumente (Foreman, Webhost, Applikation, Automation-Übersicht).

Voraussetzungen

Bevor der erste Host provisioniert wird, müssen folgende Komponenten existieren — pro Infrastruktur einmalig:

Komponente	Wo	Was muss da sein
Foreman + Puppet-Server	foreman.iteas.tools:8140	Läuft, signiert Zertifikate, klassifiziert Hosts
puppet-control Puppetfile	Branch development (bzw. production)	Verweist auf puppet-module-iteasapps und puppet-module-services
Hiera/Vault-Mounts	puppet-control/hiera.yaml	petems-hiera_vault mit den drei Mount-Pfaden aus Foreman → Lookup-Key-Konvention
Vault-Secrets (host-übergreifend)	siehe unten	gitlab_deploy_auth, github_deploy_auth, geoip

Host-übergreifende Vault-Secrets

Müssen pro Vault-Instanz nur einmal angelegt werden, gelten dann für alle Hosts:

# Git-Auth für Clone + Composer (Username + Passwort vom GitLab-Group-Deploy-Token)
vault kv put secret/puppet/common/gitlab_deploy_auth \
    username='gitlab+deploy-token-XX' \
    password='<token-value>'

# GitHub-Token für private composer-Deps
vault kv put secret/puppet/common/github_deploy_auth \
    token='ghp_xxxxxxxxxxxxxxxxxxxx'

# MaxMind-Credentials für GeoIP-Datenbank (optional, aber empfohlen)
vault kv put secret/puppet/common/geoip \
    account_id=123456 \
    license_key='XXXXXX_AbCdEfGhIjKlMnOpQrStUvWxYz0123456'

Schritt-für-Schritt: Neuer Kunde

Schritt 1 — Host bereitstellen

Je nach Plattform unterscheidet sich der Vorgang. Siehe Anhang: Plattform-Unterschiede weiter unten.

Mindestanforderungen für den Host:

Ressource	Minimum	Empfohlen	Wofür
RAM	1 GB	2 GB	Yii-Bootstrap, MariaDB, FPM-Pool, Docker-Container für App und Docs
CPU	1 vCPU	2 vCPU	PHP-FPM + nginx + MariaDB parallel
Disk	10 GB	20 GB	OS + Pakete + App-Quellcode + Node-Module

Memory

1 GB reicht für reine App-Hosts (native iScan + MariaDB). Mit Docker (containerized iScan, oder Docs aktiviert) sind 2 GB komfortabel — pro Container ~50–150 MB Resident.

Schritt 2 — Puppet-Agent bootstrappen

Bootstrap entweder via Cloud-Init (Hosting-Provider mit voller Cloud-Init-Unterstützung) oder manuell (Proxmox LXC). Beides ist in Foreman → Cloud-Init Bootstrap bzw. Manuelles Bootstrapping unter Proxmox im Detail beschrieben.

Nach dem Bootstrap läuft der Puppet-Agent, hat sein Zertifikat beim Foreman angefragt und wartet auf Klassifizierung.

Schritt 3 — Zertifikat signieren

Bei deaktiviertem Auto-Sign liegt der eingehende CSR nicht unter Hosts, sondern auf dem Puppet-CA-Smart-Proxy. So findest du ihn:

1. Infrastruktur → Smart Proxys im linken Menü.

   

2. Auf den Puppet-CA-Smart-Proxy klicken (in unserem Setup foreman.iteas.tools) → Tab Puppet-CA → Zertifikate. Nach Status "ausstehend" filtern. Der CSR des neuen Hosts erscheint mit Status "ausstehend" und einer Signieren-Action.

   

3. Signieren klicken → bestätigen.

Bei aktiviertem Auto-Sign passiert das automatisch, sobald der CSR ankommt — die Liste ist dann immer leer. Aktueller Default in unserem Setup ist kein Auto-Sign, weil Cert-Signaturen einem manuellen Approval-Schritt entsprechen sollen.

Nach der Signierung greift der wartende puppet agent --test --waitforcert aus Schritt 2 das Cert beim nächsten Poll-Intervall (10s) ab und compilet den ersten Catalog.

Schritt 4 — DNS einrichten

Bevor irgendwas weiter läuft, müssen folgende DNS-Records öffentlich auflösbar sein und auf die öffentliche IP des Hosts zeigen:

Record	Beispiel	Pflicht?	Wofür
Der Wert des SCP domain der App	goessl.iscan.iteas.at, transfer.acme.iteas.at	ja	Haupt-VHost + Let's-Encrypt-Cert via HTTP-01
Der Wert des SCP docs_domain (falls die App Docs unterstützt)	docs.goessl.iscan.iteas.at	nur wenn docs_domain gesetzt	Docs-VHost + separates Let's-Encrypt-Cert

Welche FQDNs konkret verwendet werden, entscheidet der Operator beim Setzen der SCPs in Schritt 7 — es gibt kein hartcodiertes Schema. Bei mehreren Apps pro Host (z.B. iScan + iTransfer auf demselben Container) braucht jede ihren eigenen DNS-Record; sie teilen sich denselben nginx, aber jede App hat ihren eigenen VHost und eigenes Cert.

DNS muss vor dem ersten Agent-Run stehen

Let's Encrypt validiert die Domains via HTTP-01 von außen. Ohne DNS-Eintrag bricht Certbot mit NXDOMAIN ab, der ganze Deploy-Lauf hängt am Cert-Schritt. Port 80 muss von außen erreichbar sein — beim Hosting-Provider die Firewall/Security-Group prüfen.

Schritt 5 — Kunden-Vault-Secrets anlegen

Pro Kunde / pro App-Instanz die anwendungs-spezifischen Secrets in Vault hinterlegen. Der genaue Pfad und die Felder sind in Foreman → Vault-Integration dokumentiert. Beispiel iScan:

vault kv put secret/puppet/common/iteasapps/iscan/secrets \
    db_password='<random-strong-password>' \
    cookie_validation_key="$(openssl rand -hex 32)" \
    edbs_db_password='<edbs-db-password>' \
    deploy_token='glpat-<gitlab-project-deploy-token>' \
    mailer_dsn='smtp://user:pass@mail.example.com:587' \
    sp_mailer_dsn='smtp://user:pass@mail.example.com:587'

Soll dieser Kunde ein anderes Passwort haben als die globalen Defaults? Dann denselben Pfad-Aufbau unter secret/puppet/<env>/<certname>/iteasapps/iscan/secrets ablegen — der host-spezifische Pfad gewinnt vor puppet/common/.

Schritt 6 — EDBS-Anbindung

Dies dient für den EDBS-Server, in die Datenbank der Applikationen zu schreiben.

1. EDBS-Passwort in Vault:

   vault kv put secret/puppet/common/iteas_services/edbs/secrets \
       password='<edbs-mariadb-password>'

2. In Foreman zusätzlich die Klasse iteas_services::edbs zuweisen mit:
   • source_ip = öffentliche IP des EDBS-Servers
   • target_database = iscan (= App-Name)

Details: Foreman → EDBS-Anbindung.

Schritt 7 — Foreman-Klassifizierung

In der Foreman-UI:

1. Hosts → All Hosts → <neuer Host> → Edit

2. Tab Host → Puppet Environment → auf development setzen (bzw. production für Live-Hosts). Der Wert muss exakt einem von r10k deployten Environment-Verzeichnis unter /etc/puppetlabs/code/environments/<name>/ entsprechen.

3. Tab Puppet ENC (bzw. die Klassenzuweisung deiner Foreman-Version) → die App-Klasse zuweisen, z.B. iteasapps::iscan oder iteasapps::itransfer.

4. Tab Parameters → Puppet Class Parameters → die Pflichtparameter setzen:

   Parameter	Wert	Erklärung
   domain	<customer>.iscan.iteas.at	Der DNS-Name aus Schritt 4
   edbs_db_user	<edbs-username>	Username für die remote EDBS-Verbindung
   edbs_db_host	<edbs-host>	Hostname/IP des Remote-EDBS-Servers
   edbs_db_name	<edbs-db-name>	DB-Name der Remote-EDBS-DB
   mode	native oder containerized	siehe Deployment-Modi
   application_port	4001	TCP-Port im Bereich 4000–5000. Containerized: docker-Mapping. Native: nur als Basis für den Docs-Port (<application_port>1, also 4001 → 40011). Pflichtwert, auch bei rein nativem Setup ohne Docs
   yii_environment	dev oder prod	siehe Versionsauflösung
   docs_domain	docs.<customer>.iscan.iteas.at	leer lassen = keine Docs

5. Submit.

Optional anpassen: customer, yii_debug, enable_logging, allowed_countries, dev_branch, version etc. — der Standardfall ist, version leer zu lassen: dann löst die Klasse selbst auf, was deployt werden soll (siehe Versionsauflösung). version nur dann setzen, wenn du auf eine bestimmte Tag/Branch/Image-Version pinnen oder zurückrollen willst.

Schritt 8 — Agent-Run abwarten

Der Puppet-Agent fragt alle 30 Minuten von sich aus an. Sofortiger Lauf:

sudo /opt/puppetlabs/bin/puppet agent --test

Der erste Lauf dauert je nach Modus 2–8 Minuten:

• Basis-Setup (nginx, php-fpm, mariadb, fail2ban) — einmalig pro Host
• Let's-Encrypt-Cert-Issuance — einmalig pro Domain
• (native) Git-Clone + Composer-Install + Yii-Migrate — bei jedem Versions-Update
• (containerized) Docker-Install + Image-Pull + Container-Start
• (mit Docs) Node 20 Install + NPM ci + VitePress-Build

Bei späteren Agent-Runs wird nur das neu gemacht, was sich verändert hat (Idempotenz).

Schritt 9 — Verifikation

Sobald puppet agent --test ohne Fehler durchläuft, smoketesten:

# HTTPS antwortet mit Status 200
curl -fsSI https://<customer>.iscan.iteas.at/

# Cert ist von Let's Encrypt
openssl s_client -connect <customer>.iscan.iteas.at:443 -servername <customer>.iscan.iteas.at \
    < /dev/null 2>/dev/null | openssl x509 -noout -issuer

# (native) FPM-Pool läuft als der App-User
ps -ef | grep "php-fpm.*${customer:-iscan}"

# (containerized) Container läuft
sudo docker ps --filter "name=iscan-current"

# (mit Docs) Docs-Site antwortet
curl -fsSI https://docs.<customer>.iscan.iteas.at/

In Foreman: Der Host zeigt "Active" mit grünem Reportstatus.

---

Anhang: Deployment-Modi

Pro App-Instanz wählt der mode-Parameter zwischen zwei grundsätzlich verschiedenen Deployment-Strategien. Siehe auch Webhost → Betriebsmodi.

Native (mode = native)

• App-Code wird direkt auf dem Host installiert (Git-Clone der iScan-Repo, composer install, yii migrate).
• PHP-FPM mit eigenem Pool unter dem System-User f01_<app> läuft den Code.
• nginx → fastcgi_pass auf einen Unix-Socket → PHP-FPM-Worker.
• MS-SQL-Stack (msodbcsql18 + pdo_sqlsrv) wird einmalig durch iteas_services::php_mssql installiert.

Vorteile	Nachteile
Volle Kontrolle über PHP-Extensions auf Host-Ebene	PHP-Stack muss auf jedem Host installiert + aktuell gehalten werden
Schneller Restart (FPM reload) ohne Container-Start	Längeres Erst-Setup (Pakete + Composer)
Direkter Zugriff auf Logs, Strace, Debugger	Plattform-Abhängigkeit (Distro-Pakete)

Containerized (mode = containerized)

• App läuft im offiziellen Docker-Container (git.styrion.net:4567/iteas/iscan/iscan-webapp:<version>).
• Container exponiert intern Port 80 → wird auf 127.0.0.1:<application_port> gemappt.
• nginx → proxy_pass auf den Container-Port.
• MariaDB läuft weiterhin auf dem Host; Container erreicht sie via host.docker.internal.
• Persistente Pfade (data/, web/{apk,user,img/data}/) werden als Bind-Mounts in den Container reingereicht.

Vorteile	Nachteile
App-Image enthält den gesamten PHP-Stack inkl. MS-SQL	Docker muss installiert sein (iteas_services::docker::docker)
Sauber abgegrenzte Lifecycles für App und Host	Bisschen overhead durch Container-Layer
Keine direkten PHP-Extension-Installs auf dem Host	Debugging etwas indirekter (Container exec)

Wann was wählen?

Szenario	Empfehlung
Produktion mit standardisiertem App-Image	containerized
Schnelles Iterieren, Hotfixes auf einer Test-VM	native mit yii_environment = dev (tracked develop-Branch)
Kunde will exakte App-Versions-Pinning	beides geht, aber native mit yii_environment = prod (Latest-Tag) ist transparenter
Heterogenes Host-OS (z.B. Mix aus Debian/Ubuntu)	containerized (Container-Layer abstrahiert OS-Unterschiede weg)

Die Docs-Komponente (docs_domain gesetzt) ist immer containerized — unabhängig davon, in welchem Modus die Haupt-App läuft. iteasapps::docs zieht das vorgefertigte iscan-docs:<version>-Image aus der GitLab Container Registry und startet es als eigenen Container hinter nginx (proxy_pass http://127.0.0.1:<docs_container_port>). Folge: jeder Host mit aktivierten Docs braucht Docker, auch wenn die Haupt-App mode = native läuft. iteasapps::webhost zieht iteas_services::docker::docker deshalb automatisch rein, sobald docs_domain gesetzt ist — kein Node/npm mehr auf Host-Ebene nötig.

---

Anhang: Versionsauflösung

Der version-SCP ist optional. Leer lassen heißt: die Klasse löst zur Laufzeit selbst auf, was deployt werden soll. Die Quelle der Wahrheit hängt vom Deployment-Modus ab — git für native, Container-Registry für containerized — damit jeder Modus mit dem arbeitet, was er ohnehin braucht.

Automatische Auflösung (version leer)

Modus	yii_environment	Quelle	Auflöst zu
native	prod	git ls-remote --tags --sort=-v:refname	höchster Semver-Tag
native	dev	git ls-remote refs/heads/$dev_branch	HEAD von $dev_branch (Default develop)
containerized	prod	Docker Registry HTTP API v2 (/v2/<repo>/tags/list)	höchster Semver-Tag im Registry
containerized	dev	konstant	:latest (CI überschreibt diesen Tag bei jedem Push auf einer Branch ohne offene MR)

Idempotenz:

• Native: Marker enthält den aufgelösten Git-SHA. Bei jedem Agent-Run wird ls-remote befragt, SHA verglichen → nur bei Mismatch deployt.
• Containerized: Marker enthält <tag>@<digest>. check ruft docker manifest inspect ohne Pull auf und vergleicht den Digest. So wird auch ein überschriebener :latest-Tag erkannt, obwohl der Tag-String gleich bleibt.

Pinnen / Rollback (version gesetzt)

Sobald version nicht leer ist, überspringt der Deploy-Skript die Auto-Auflösung und nimmt den Wert wörtlich:

• Native: erst als Git-Tag, dann als Branch-Name, dann als 40-stelliger SHA versucht. feature/foo, v2.5.0, a1b2c3d4... sind alle gültig.
• Containerized: als Image-Tag verwendet. Beispiele: v2.5.0 (Release), dev-12345 (spezifischer CI-Build).

Wann pinnen?

• Rollback auf eine alte stabile Version, während ein Bug auf dem aktuellen Tag/Branch noch behoben wird.
• Reproduzierbarkeit in Test- oder Customer-spezifischen Hosts.

Wichtig zur Retention

Das Registry behält nur:

• :latest (immer)
• Den aktuellen <latest-version>-Tag (immer)
• Die letzten fünf Versions-Tags und letzten fünf dev-<pipeline_id>-Tags für 30 Tage

Ältere Pins führen beim docker pull zu HTTP 404 — der Puppet-Agent meldet das laut im Foreman-Report, das Deploy fällt fehl (kein stiller No-op). Wenn ein lang zurückliegender Stand gebraucht wird, am besten in CI einen frischen Tag auf den entsprechenden Commit setzen und auf diesen pinnen.

Beispiel-Workflow für ein Customer-Update

1. CI hat v2.5.1 gebaut und gepusht (iscan-webapp:v2.5.1 + iscan-docs:v2.5.1).
2. Foreman: Customer-Hosts laufen mit yii_environment = prod, version leer.
3. Beim nächsten Agent-Run resolve_desired_tag findet v2.5.1 als höchsten Semver → Pull + Restart.
4. Falls v2.5.1 einen Bug zeigt:
   • version = v2.5.0 in Foreman setzen → nächster Agent-Run rollt zurück.
   • Fix landet als v2.5.2. version wieder leer setzen → nächster Agent-Run zieht v2.5.2.

Dev-Branch (dev_branch)

Nur für native + yii_environment = dev relevant. Default ist develop; auf z.B. feature/foo setzen, um auf einem Test-Host einen Feature-Branch zu verfolgen.

Containerized Dev ignoriert dev_branch — die CI baut nur einen einzigen :latest-Image, unabhängig vom Branch. Wenn man einen spezifischen Container-Dev-Build verfolgen will: version = dev-<pipeline_id> setzen (CI veröffentlicht die Pipeline-ID als zusätzlichen Tag).

---

Anhang: Plattform-Unterschiede

Proxmox LXC

LXC unter Proxmox unterstützt nur ein eingeschränktes Cloud-Init-Subset (Hostname, SSH-Keys, Netzwerk). Das vollständige iteasapps-bootstrap.yaml (mit runcmd-Block) kann nicht als User-Data hinterlegt werden, weshalb die drei Bootstrap-Schritte einmalig von Hand ausgeführt werden müssen.

Vorgehen:

1. Container in Proxmox erstellen mit:
   • Template Ubuntu 24.04 oder Debian 12
   • Mindestens 2 GB RAM, besser 4 GB (sonst OOM beim Docs-Build)
   • 10 GB Disk
   • 1–2 vCPUs
   • Netzwerk-Bridge mit Internet-Zugang (für Apt-Repos + Vault + GitLab-Pull)
   • SSH-Key oder Root-Passwort
2. Container starten und SSH einrichten (über die Proxmox-Console oder direkt SSH).
3. Manuell den Bootstrap durchführen, wie in Foreman → Manuelles Bootstrapping unter Proxmox beschrieben — Locale-Setup + Puppet-Agent-Install + Konfig + erster Agent-Run.
4. Ab hier weiter mit Schritt 3 — Zertifikat signieren.

Cloud-Init-fähige Hosting-Provider (Hetzner Cloud, AWS EC2, OpenStack, …)

Diese Provider akzeptieren ein vollständiges #cloud-config-User-Data-File. Damit läuft der gesamte Bootstrap automatisch beim ersten Boot.

Vorgehen:

1. VM mit User-Data anlegen. Den Inhalt von cloud-init/iteasapps-bootstrap.yaml als User-Data eintragen.
   • Bei Hetzner Cloud: im VM-Creation-Form unter "Cloud-Init" einfügen.
   • Bei AWS EC2: als User-Data beim Launch-Konfig.
   • Bei OpenStack: via nova boot --user-data oder im Horizon-UI.
2. VM-Größen wählen: 2–4 GB RAM, mindestens 10 GB Disk.
3. Netzwerk konfigurieren: Public IP + Firewall öffnet TCP 80, 443, 22.
4. VM starten. Cloud-Init läuft beim ersten Boot, installiert den Puppet-Agent, registriert sich beim Foreman.
5. Ab hier weiter mit Schritt 3 — Zertifikat signieren.

Unterschiede in der Tabelle

Aspekt	Proxmox LXC	Cloud-Init-fähig (Hetzner etc.)
Bootstrap	Manuell (3 Befehlsblöcke per SSH)	Automatisch via User-Data
Zeitaufwand pro Host	~5 min manuelle Eingaben	~0 — VM startet, fertig
Eignet sich für	Test-/Entwicklungs-Container, On-Prem	Produktion, Cloud, schnelle Skalierung
RAM-Limit	Hard-Limit aus Container-Config	Hard-Limit aus VM-Größe
Netzwerk	meist Bridge auf internes LAN	meist direktes Public-IP
DNS-Setup	manuell (öffentlich auflösbar nötig für Let's Encrypt)	gleicher Aufwand

---

Anhang: Häufige Probleme

NXDOMAIN looking up A for <domain> beim Cert-Issuance

DNS für die konfigurierte Domain ist nicht öffentlich auflösbar. Let's Encrypt validiert von außen — interne DNS-Server zählen nicht. Lösung:

• Public DNS-A-Record anlegen, der auf die öffentliche IP des Hosts zeigt.
• Während der Iteration: Let's-Encrypt-Staging-Endpoint nutzen (iteas_services::letsencrypt::config mit server: 'https://acme-staging-v02.api.letsencrypt.org/directory'), um nicht ins Production-Rate-Limit zu laufen.

i/o timeout auf git.styrion.net:4567 (containerized mode)

Der Host kann den GitLab Container Registry nicht erreichen. Lösung:

• Firewall / Network-Policy für ausgehenden TCP 4567 zur GitLab-IP öffnen.
• Beim Hosting-Provider: Outbound-Default ist meist erlaubt, beim On-Prem-LAN oft restriktiv.

pull access denied oder manifest unknown beim Docs-Container-Pull

Docker findet das iscan-docs:<version>-Image nicht im Registry. Lösung:

• In GitLab → iScan-Projekt → Container Registry prüfen, ob dieses Tag tatsächlich gebaut wurde. Pro Tag muss die CI sowohl iscan-webapp:<tag> als auch iscan-docs:<tag> produzieren.
• Falls die Tag-Erstellung nur die webapp-Variante baut, ist das ein CI-Konfigurationsproblem in der iScan-Pipeline, kein Puppet-Issue.

Port-Kollision zwischen App- und Docs-Container

Der Docs-Port wird automatisch aus dem App-Port abgeleitet (application_port * 10 + 1). Wenn auf demselben Host zwei Apps deployt sind und deren application_port-Werte zu kollidierenden Docs-Ports führen, schlägt der zweite docker run -p ... fehl. Beispiel: iScan mit application_port = 4500 ergibt Docs-Port 45001; iTransfer mit application_port = 45001 würde am Docs-Port kollidieren. Lösung:

• Die application_port-Werte der Apps so wählen, dass weder die App-Ports noch deren * 10 + 1-Ableitungen kollidieren.
• In der Praxis: alle App-Ports nahe 4000–4099 halten, dann sind die Docs-Ports 40001–40991 und überlappen nicht mit anderen App-Ports.
• Alle Ports sind 127.0.0.1-only — kein Konflikt mit etwas Öffentlichem auf 80/443.

invalid byte sequence in US-ASCII

Locale-Problem im Puppet-Agent. Sollte mit der iteas_services::puppet_agent-Klasse auf neueren Hosts automatisch behoben sein. Bei alten Hosts:

sudo systemctl restart puppet     # systemd-Drop-in greifen lassen
# oder, falls Locale system-weit fehlt:
sudo update-locale LANG=C.UTF-8 LC_ALL=C.UTF-8

Details: siehe Foreman → Manuelles Bootstrapping (Locale-Block).

Another puppet instance is already running

Zwei Agent-Prozesse kollidieren am Lockfile. Tritt typischerweise auf, wenn ein manueller puppet agent --test gestartet wird während der systemd-getriggerte Lauf noch läuft. Lösung:

sudo systemctl stop puppet
sudo /opt/puppetlabs/bin/puppet agent --test
sudo systemctl start puppet

Could not retrieve catalog from remote server: Error 500 on SERVER mit "Could not find class …"

Foreman classifiziert eine Klasse, aber Puppet-Server findet sie nicht. Meist haben r10k oder das Puppet-Control-Repo die Module noch nicht. Lösung am Puppet-Server:

sudo /opt/puppetlabs/bin/r10k deploy environment <environment> -pv

Healthcheck schlägt fehl trotz funktionierender App

Der Deploy-Script-Exec ist mit Exit-Code != 0 abgebrochen (oft EDBS-Connection-Fehler im yii migrate). Das .deployed-version-Marker-File wird in dem Fall nicht geschrieben, also läuft jeder weitere Agent-Run das Script erneut. Manuell debuggen:

sudo /usr/local/sbin/iteasapps-deploy-iscan deploy <version>

Die letzten Zeilen vor dem Abbruch zeigen den eigentlichen Fehler.

---

Anhang: Checkliste zum Abhaken

Für die schnelle Provisionierung als kompakte Liste:

• [ ] Host erstellt (Proxmox LXC ODER Cloud-Hosting), ≥ 2 GB RAM
• [ ] Puppet-Agent bootstrappt (Cloud-Init oder manuell)
• [ ] Foreman-Cert signiert (auto-sign oder manuell)
• [ ] Public DNS-Record auf Host-IP zeigt, Port 80 erreichbar
• [ ] Vault-Secret secret/puppet/common/iteasapps/<app>/secrets mit db_password, cookie_validation_key, edbs_db_password, deploy_token befüllt
• [ ] (Optional) Vault-Secret secret/puppet/common/iteas_services/edbs/secrets mit password, wenn EDBS einkommend genutzt wird
• [ ] In Foreman: Puppet Environment auf development (bzw. production) gesetzt
• [ ] In Foreman: App-Klasse zugewiesen (iteasapps::iscan o.ä.) + Smart-Class-Parameters (domain, edbs_db_*, mode, application_port, optional docs_domain, version)
• [ ] (Optional) iteas_services::edbs zugewiesen mit source_ip + target_database
• [ ] puppet agent --test läuft sauber durch
• [ ] curl https://<domain>/ antwortet 200
• [ ] (Wenn Docs) curl https://docs.<domain>/ antwortet 200