Murat ÖZDEMİR
bf8f011e43
This commit introduces a reordered and renumbered set of setup documentation files to better reflect the deployment stages for both test and production environments. Key changes include: * A new `setup-vs-roadmap-map.md` file to provide a clear mapping between roadmap tasks and their corresponding setup phases. * Significantly expanded Ansible bootstrap documentation for both test and production, detailing Docker, Swarm, security hardening, and StorageBox SSH key management roles. * Formalized database Docker and Swarm cluster setup instructions for test and production, including explicit steps for Swarm worker integration of DB nodes. * Updated roadmap documentation (`roadmap/prod-env/*`) to align with the refined setup, incorporating correct private IP addresses for Swarm joins, new node labels, and floating IP usage for GoDaddy DNS records.
159 lines
5.7 KiB
Markdown
159 lines
5.7 KiB
Markdown
# 09 - Prod Runner HA ve Swarm Deploy Modeli
|
||
|
||
Bu asamanin amaci prod ortaminda Gitea Actions runner'lari HA calisacak sekilde kurmak ve Swarm uzerinde servislerin 3 node'a dagitilmasina uygun on kosullari tanimlamaktir.
|
||
|
||
## Runner Sayisi
|
||
|
||
Tek runner fonksiyonel olarak yeterlidir, ancak HA degildir. Prod hedefi HA oldugu icin `act_runner` 3 Swarm manager node'unun tamamına systemd servisi olarak kurulacak:
|
||
|
||
| Host | Runner |
|
||
| --- | --- |
|
||
| `iklim-app-01` | `act_runner` systemd |
|
||
| `iklim-app-02` | `act_runner` systemd |
|
||
| `iklim-app-03` | `act_runner` systemd |
|
||
|
||
Bu modelde herhangi bir manager/runner kaybedilirse diger runner'lar pipeline job'larini alabilir.
|
||
|
||
## Runner Kurulum Modeli
|
||
|
||
Runner Docker container olarak calismayacak. Docker socket mount yok.
|
||
|
||
Kurulum:
|
||
|
||
- `gitea-runner` sistem kullanicisi
|
||
- `/usr/local/bin/act_runner`
|
||
- `/etc/gitea-act-runner/config.yaml`
|
||
- `/var/lib/gitea-runner`
|
||
- `gitea-act-runner.service`
|
||
|
||
Runner job'lari deploy icin Docker CLI kullanacaksa `gitea-runner` kullanicisinin Docker daemon erisimi gerekir. Docker group uyeligi root seviyesine yakin yetki kabul edilir; sadece guvenilir repo/job'lar bu runner label'larini kullanmalidir.
|
||
|
||
## Runner Label PolitikasI
|
||
|
||
Tum prod runner'larda ortak label:
|
||
|
||
```text
|
||
prod-runner
|
||
docker
|
||
swarm-manager
|
||
ubuntu-24.04
|
||
```
|
||
|
||
Node-spesifik label'lar:
|
||
|
||
```text
|
||
iklim-app-01
|
||
iklim-app-02
|
||
iklim-app-03
|
||
```
|
||
|
||
Mevcut prod workflow'lari `runs-on: prod-runner` kullaniyorsa 3 runner'dan herhangi biri job'u alabilir. Belirli bir node'a sabitlemek gerekirse node-spesifik label kullanilir.
|
||
|
||
## Deploy Yarismasi Riski
|
||
|
||
Birden fazla runner oldugunda ayni anda birden fazla deploy job'u calisabilir. Bu HA icin iyidir ama ortak kaynaklarda yarisma riski yaratabilir.
|
||
|
||
Riskli alanlar:
|
||
|
||
- Ayni stack uzerinde es zamanli `docker stack deploy`
|
||
- Ayni servis icin es zamanli `docker service update`
|
||
- StorageBox'ta ayni `.env` veya manifest dosyasinin es zamanli guncellenmesi
|
||
- Root altyapi pipeline'i ile mikroservis deploy pipeline'inin ayni anda calismasi
|
||
|
||
Gerekli onlem:
|
||
|
||
- Prod root altyapi deploy'u manuel/onayli calismali.
|
||
- Ayni servis icin prod deploy ayni anda birden fazla kez tetiklenmemeli.
|
||
- Prod deploy workflow'lari StorageBox uzerinde otomatik deploy lock kullanmalidir.
|
||
|
||
## StorageBox Deploy Lock Modeli
|
||
|
||
Prod'da 3 runner oldugu icin deploy lock zorunlu kabul edilir. Lock lokal dosya
|
||
sisteminde tutulmayacak; cunku runner'lar farkli makinelerde calisir ve birbirlerinin
|
||
`/tmp` veya `/var/lock` dizinlerini gormez.
|
||
|
||
Lock konumu StorageBox olacaktir:
|
||
|
||
```text
|
||
prod/locks/prod-deploy.lock
|
||
prod/locks/prod-infra.lock
|
||
prod/locks/services/<service-name>.lock
|
||
```
|
||
|
||
Baslangic modeli:
|
||
|
||
```text
|
||
prod/locks/prod-deploy.lock
|
||
```
|
||
|
||
Bu tek global lock tum prod deploy'lari siraya sokar ve en az karmasik modeldir.
|
||
Ileride deploy sureleri uzarsa servis bazli lock'a gecilebilir.
|
||
|
||
Lock dosyasi/klasoru manuel olusturulmaz. Workflow basinda atomik `mkdir` ile lock
|
||
alinir, workflow sonunda `rmdir` ile lock birakilir.
|
||
|
||
Ornek:
|
||
|
||
```bash
|
||
LOCK_DIR="prod/locks/prod-deploy.lock"
|
||
LOCK_META="owner.txt"
|
||
|
||
ssh "$STORAGEBOX_SSH" "mkdir -p prod/locks && mkdir '$LOCK_DIR'"
|
||
ssh "$STORAGEBOX_SSH" "printf '%s\n' 'runner=${GITEA_RUNNER_NAME:-unknown}' 'run=${GITHUB_RUN_ID:-unknown}' 'created_at=$(date -u +%FT%TZ)' > '$LOCK_DIR/$LOCK_META'"
|
||
|
||
# deploy islemleri
|
||
|
||
ssh "$STORAGEBOX_SSH" "rm -f '$LOCK_DIR/$LOCK_META' && rmdir '$LOCK_DIR'"
|
||
```
|
||
|
||
Davranis:
|
||
|
||
- `mkdir '$LOCK_DIR'` basariliysa lock alinmistir.
|
||
- `mkdir '$LOCK_DIR'` fail olursa baska deploy calisiyor kabul edilir.
|
||
- Job fail olsa bile cleanup adimi `rm/rmdir` calistirmalidir.
|
||
- Stale lock temizligi manuel/onayli olmalidir; otomatik zorla silme ilk asamada uygulanmamalidir.
|
||
|
||
Lock seviyesi:
|
||
|
||
| Lock | Ne icin |
|
||
| --- | --- |
|
||
| `prod/locks/prod-deploy.lock` | Ilk asama: tum prod deploy'lar icin global lock |
|
||
| `prod/locks/prod-infra.lock` | Ileride root infra deploy'u mikroservis deploy'larindan ayirmak icin |
|
||
| `prod/locks/services/<service-name>.lock` | Ileride servis bazli paralel deploy'a gecmek icin |
|
||
|
||
## Swarm Servis Dagilimi
|
||
|
||
Prod'da 3 node da manager + app worker oldugu icin servisler 3 node'a dagitilabilir.
|
||
|
||
Uygulama servisleri icin ileride `docker-stack-service.yml` deploy ayarlari su prensiplere gore revize edilebilir:
|
||
|
||
- Stateless servislerde `replicas: 3`
|
||
- `placement` ile sadece app-capable node'lar secilir
|
||
- `update_config` rolling update olacak sekilde ayarlanir
|
||
- `restart_policy` aktif kalir
|
||
- State tutan servisler app worker uzerinde cogaltilmaz; stateful katman DB node'larinda ayridir
|
||
|
||
Mevcut repo durumunda mikroservis stack dosyalari servis bazli deploy ediliyor. Bu dokuman, prod HA hedefi icin runner ve Swarm on kosullarini tanimlar; her mikroservisin replica sayisi ayri uygulama deploy refaktoru olarak ele alinmalidir.
|
||
|
||
## Gateway ve Public Trafik
|
||
|
||
Public internet sadece `80/tcp` ve `443/tcp` ile gateway katmanina girmelidir.
|
||
|
||
Mevcut stack dosyalarinda APISIX `8080/8443` publish ediyor olabilir. Prod hedef mimaride public firewall sadece `80/443` acik oldugu icin iki secenekten biri secilmelidir:
|
||
|
||
1. APISIX/SWAG host publish portlari `80/443` ile uyumlu hale getirilir.
|
||
2. Hetzner Load Balancer veya reverse proxy `80/443` alip Swarm gateway portlarina private network uzerinden aktarir.
|
||
|
||
Bu karar Terraform/Ansible bootstrap'tan ayridir; uygulama altyapi manifest revizyonu gerektirir.
|
||
|
||
## Kabul Kriterleri
|
||
|
||
- 3 prod runner Gitea UI'da online gorunur.
|
||
- Her runner `prod-runner` label'ina sahiptir.
|
||
- Runner'lardan herhangi biri basit Docker komutu calistirabilir.
|
||
- `docker node ls` 3 manager gosterir.
|
||
- Bir runner/node kapatildiginda diger runner yeni job alabilir.
|
||
- Prod workflow'lari StorageBox uzerindeki `prod/locks/prod-deploy.lock` global lock'unu kullanir.
|
||
- Lock manuel degil, workflow tarafindan `mkdir/rmdir` ile otomatik yonetilir.
|
||
- Public ingress sadece `22`, `80`, `443` ile sinirlidir.
|