p24-infra Docs

w4-rollback-2026-07-09

4 min read

W4 bms-1 Rollback Playbook — 2026-07-09

Aktualny działający stan: tag w4-working-2026-07-09 Preview (getSignedUrl): DZIAŁA Obraz ECR digest: sha256:35b49e52361692e328d7eb96ea83f6296b0b304c732534f3706f35b58ba40bfb

UPDATE 2026-07-29 — PM2 cluster mode (3 instances) sformalizowany jako aktualny stan. 2026-07-12 przywrócono ecosystem.config.js: instances: 1, exec_mode: "fork" → instances: 3, exec_mode: "cluster" (live test na bms-1), monitorowane jako stabilne do 2026-07-29 (issue #2542 — restart count płaski 1/worker na wszystkich 3 workerach, brak nawrotu crash-loopa). Zmiana sformalizowana w GitLab MR !792 (commit 04642325, branch fix/v42-prod-compose-persistent-config, target development — czeka na merge). To odwraca fix z issue #3161 (2026-07-07/08) opisany poniżej — sekcja “Co teraz działa” i weryfikacja (min. 2 workery) poniżej odnosi się do STANU HISTORYCZNEGO (fork/1-instance). Patrz zaktualizowany krok weryfikacji PM2 (min. 3 workery) w sekcji “Weryfikacja po rollbacku”. Reference copy configu: bms-1/v42-prod-ecosystem.config.js w tym repo. Residual risk (NIE naprawiony tą zmianą, zaakceptowane ryzyko): socket.io 2.2.0 nie ma sticky-session ani socket.io-redis adaptera — PM2 cluster mode round-robinuje połączenia między procesami z niezależnymi mapami socketów w pamięci, więc cross-worker realtime delivery pozostaje architektonicznie niepewny mimo braku crashy przez 17 dni.

Co teraz działa i dlaczego

ElementMechanizm
Inline PDF previewWasabi key W4AR w backend-environment.env (via secrets-sync)
Auth file downloadNiezależne od s3Bucket — działa od początku
PostbookspostbookReport.helper.js persistent-patch
s3-v2-v42-prodGitLab CI używa --env-file /opt/p24-infra/bms-1/pinbox24-w4.env
v42-proddocker-compose z env_file: backend-environment.env
redis-v42redis:7-alpine, STATYCZNY — brak CI/CD, brak SOPS; deployment v42-prod NIE rusza Redis

Architektura CI/CD (po review 2026-07-09)

v42-prod NIE ma standardowego .gitlab-ci.yml. Deploy odbywa się przez git-deploy-v42-prod — kontener na bms-1 reagujący na git push (mechanizm trigger-based). Plan #3171 zastąpi to normalnym CI.

.gitlab-ci.yml istnieje tylko dla mikrousług:

  • pinbox24/pinbox24-ms-s3-v2 → s3-v2-v42-prod (deploy manual, czeka na Phase 0 #3171)
  • pinbox24/p24-ms-mailgun → mailgun-prod (pipeline OK)

Redis: W4 używa redis-v42, W3 używa redis-v32. Oba są statyczne — żaden CI/CD ich nie dotyka. RabbitMQ/AMQP: NIE używany ani przez W3, ani W4.

Scenariusz A — CI deploy zaktualizował obraz, preview nie działa

Przyczyna: nowy GitLab CI build uruchomił kontener bez --env-file → stary klucz 5F1B z obrazu.

Rollback (2 minuty):

gh workflow run secrets-sync.yml --repo radieu/p24-infra -f target=pinbox24-w4

To przywraca backend-environment.env z kluczem W4AR i robi docker-compose up -d backend s3.

Scenariusz B — Nowy obraz ma bug, kontener nie startuje

Rollback do działającego obrazu (digest pinowany):

# SSH na bms-1 (94.23.26.113)
cd /root/builds/7N4sbbrB/0/pinbox24/p24-back-ts
 
GOOD_IMAGE="563740926945.dkr.ecr.eu-central-1.amazonaws.com/v42-prod@sha256:35b49e52361692e328d7eb96ea83f6296b0b304c732534f3706f35b58ba40bfb"
CONTAINER_NAME=$(grep '^V42_CONTAINER_NAME=' /opt/p24-infra/bms-1/pinbox24-w4.env | cut -d= -f2-)
 
CONTAINER_NAME="$CONTAINER_NAME" IMAGE_NAME="$GOOD_IMAGE" docker-compose up -d backend s3

Weryfikacja po rollbacku

# 1. Klucz Wasabi — pierwsze 4 znaki powinny być W4AR
docker exec v42-prod printenv s3Bucket_api_accessKeyId | cut -c1-4
 
# 2. Redis działa
docker inspect redis-v42 --format '{{.State.Status}}'
# Oczekiwane: running
 
# 3. PM2 workers online (min. 3 — AKTUALNY stan to cluster/3-instances, patrz UPDATE 2026-07-29 wyżej)
docker exec v42-prod pm2 jlist | python3 -c \
  "import json,sys; p=json.load(sys.stdin); print(sum(1 for x in p if x.get('pm2_env',{}).get('status')=='online'))"
# Oczekiwane: 3+
# UWAGA (odwrócone założenie vs. stan historyczny fork/1-instance z 2026-07-08):
# jeśli ten check zwróci 1 worker w fork mode, to NIE jest już "working state" — to oznacza,
# że ktoś/coś cofnęło config do fork/1-instance (niechciany rollback poza tym playbookiem),
# bo od 2026-07-12/sformalizowane 2026-07-29 aktualny stan to cluster/3-instances.
# Zweryfikuj `docker exec v42-prod cat /app/ecosystem.config.js` i porównaj z
# `bms-1/v42-prod-ecosystem.config.js` w tym repo przed dalszą diagnozą.
 
# 4. API health
curl -s -o /dev/null -w "%{http_code}" https://api.w4.pinbox24.com/api/i18n/langs
# Oczekiwane: 200
 
# 5. Persistent patches w kontenerze
docker exec v42-prod grep -l ResponseContentDisposition /app/dist/globalHelpers/uploadAwsS3.helper.js
# Oczekiwane: plik znaleziony (patch aktywny)
 
# 6. Test preview (wymaga JWT tokena)
# curl -H "Authorization: Bearer <token>" "https://api.w4.pinbox24.com/api/office/getSignedUrl?..."
# Oczekiwane: 200 + presigned URL

Pełny health check: scripts/health_check_v42.sh (czyta env z /home/p24-server-scripts/v4/v42/backend-environment.env)

Dane referencyjne

ParametrWartość
ECR image (working)563740926945.dkr.ecr.eu-central-1.amazonaws.com/v42-prod:latest
Image digestsha256:35b49e52361692e328d7eb96ea83f6296b0b304c732534f3706f35b58ba40bfb
Git tagw4-working-2026-07-09
Wasabi IAM userpinbox24-bms1-s3
Wasabi key prefixW4AR...ZRH4
bms-1 IP94.23.26.113
BUILD dir/root/builds/7N4sbbrB/0/pinbox24/p24-back-ts/
Env file/opt/p24-infra/bms-1/pinbox24-w4.env (80 kluczy)

Plan wieczorny (po 22:00)

v42-prod używa git-deploy-v42-prod (trigger-based, nie standardowy GitLab CI). Push do p4-back-ts master uruchamia ten kontener, który buduje i deployuje.

  1. Triggerować build przez push do p4-back-ts master (lub manualne wyzwolenie git-deploy-v42-prod)
  2. Po deploy sprawdzić: 
    docker exec v42-prod printenv s3Bucket_api_accessKeyId | cut -c1-4
  3. Jeśli W4AR → deploy używa docker-compose z env_file → wszystko OK
  4. Jeśli 5F1B → git-deploy-v42-prod uruchamia kontener bez --env-file → patrz fix poniżej

Quick fix jeśli 5F1B po deploy (2 minuty, bez dostępu do kodu):

# Natychmiastowy rollback env — wystarczy re-deploy env, bez zmiany kodu
gh workflow run secrets-sync.yml --repo radieu/p24-infra -f target=pinbox24-w4
# secrets-sync nadpisuje backend-environment.env i robi docker-compose up -d backend s3

Długoterminowy fix (jeśli git-deploy-v42-prod nie używa docker-compose):

Znaleźć skrypt deploy w kontenerze git-deploy-v42-prod na bms-1 i zmienić na:

# W skrypcie deploy git-deploy-v42-prod:
cd /root/builds/7N4sbbrB/0/pinbox24/p4-back-ts
CONTAINER_NAME=v42-prod IMAGE_NAME=$NEW_IMAGE docker-compose up -d backend s3
# docker-compose pobiera env_file: backend-environment.env automatycznie

redis-v42 — NIE dotykamy przy żadnym rollbacku

Redis jest statyczny. Żaden scenariusz nie wymaga jego restartu ani rollbacku.

Śledzenie

Issue: https://github.com/radieu/p24-infra/issues/3542

Graph View

Backlinks