Yükseltmeler
Orbtrace'i yeni bir sürüme Docker Compose, Helm ve Ansible'da güvenle taşımak — neyin otomatik göç ettiği, önce neyi yedeklemeli ve nasıl geri alınır.
Orbtrace yükseltmeleri kasıtlı olarak sıkıcıdır: yeni image'ı çekin, yeniden başlatın, şema migration'ları kendiliğinden çalışır. Onları sıkıcı tutan disiplin, önce yedek al ve atladığınız sürümün sürüm notlarını oku'dur.
Migration'lar yalnızca ileri yönlüdür — tek geri-dönüş yolunuz yedek
Daha yeni bir Orbtrace, açılışta veritabanı şemasını yükseltir ve onu eski bir sürüme geri okuyamaz. Yani "geri almak", eski image'ı yeniden dağıtmak değil, yükseltme öncesi yedeği geri yüklemektir. Yedeği her seferinde yükseltmeden önce alın.
Herhangi bir yükseltmeden önce
- PostgreSQL'i yedekleyin (geçmiş tutuyorsanız Doris'i de) — bkz. Yedekleme ve geri yükleme. Bu sizin geri-alma yolunuz.
- Hedef sürümün changelog'unu okuyun. Kırıcı değişiklikler (Doris ana sürüm sıçraması, kaldırılan bir ayar, values yeniden adlandırması) orada belirtilir.
latestyerine taşındığınız tam sürümü sabitleyin, böylece her düğüm aynı yapıya iner.
Neyin otomatik göç ettiği
- PostgreSQL şeması — Flyway, açılışta yeni
V*migration'larını çalıştırır. Migration'lar yalnız ileri yönlüdür: daha yeni bir Orbtrace daha eski bir veritabanını okuyabilir, tersi olmaz. Geri-almanın yeniden-deploy değil, yedek geri yükleme demek olmasının sebebi budur. - Doris şeması — migration runner (
applymodunda) sunucu hazır raporlamadan önce yeni telemetri-şeması değişikliklerini uygular.validatemodunda doğrular, değişikliği bir DBA bant-dışı uygular.
Sunucu, ikisi de bitene kadar portunu bağlamaz, dolayısıyla yükseltmeden sonra sağlıklı bir sunucu, migration'ların başarılı olduğu demektir.
Docker Compose
# 1. yedek al (bkz. Yedekleme ve geri yükleme)
# 2. yeni sürümü sabitle
export ORBTRACE_VERSION=vX.Y.Z # .env'nizde
# 3. çek ve yalnız uygulamayı yeniden oluştur
docker compose pull orbtrace
docker compose up -d orbtrace
# 4. sağlıklı döndüğünü izle
docker compose ps
docker compose logs -f orbtraceDepolama konteynerleri (Doris, Postgres, Valkey) yalnızca bir sürüm notu söylediğinde yeniden oluşturulur. Yeni sürümdeki ilk açılış, migration'lar çalışırken her zamankinden uzun sürebilir.
Kubernetes (Helm)
helm upgrade orbtrace oci://ghcr.io/nivorbit/charts/orbtrace \
-n orbtrace -f values.yaml --version <chart-sürümü>
kubectl -n orbtrace rollout status deploy/orbtrace-appDeployment pod'ları teker teker döndürür; readiness probe'u, migration'ları bitene kadar bir pod'dan trafiği uzak tutar. Yükseltmeden önce yeniden adlanmış key'ler için chart'ın sürümler arası values.yaml farkını gözden geçirin (chart, yeniden adlandırmaları Chart.yaml yükseltme notunda belirtir).
Ansible
Inventory/vars'ta sabitlenmiş sürümü yükseltin, sonra playbook'u yeniden çalıştırın — idempotenttir, yeni image'ı çeker ve systemd birimi üzerinden yığını yeniden oluşturur:
ansible-playbook -i inventory.ini site.yml --ask-vault-passGeri alma
PostgreSQL migration'ları yalnız-ileri olduğundan, geri-alma geri yükleme, düşürme değildir:
- Önceki Orbtrace sürümünü yeniden deploy edin (eski image tag'i / chart sürümü).
- Yükseltmeden önce aldığınız PostgreSQL yedeğini geri yükleyin.
- Yükseltme Doris'i uyumsuz bir şekilde göç ettirdiyse, Doris snapshot'ını da geri yükleyin.
Sonra Collector'ınızı tekrar yönlendirip doğrulayın. Her yükseltmenin 1. adımının taze bir yedek olmasının sebebi budur.
Doris ana sürüm geçişleri
Bir Doris ana sürüm değişikliği (ör. 3.x → 4.1) tek-yön bir geçiştir: 4.1 metadata'sı 3.x tarafından okunamaz. Bunlar nadirdir ve changelog'da ayrı bir migration notuyla her zaman işaretlenir. Onları rutin bir docker compose pull değil, planlı bir bakım penceresi olarak ele alın.
Sırada: Güvenlik sıkılaştırma.