2026'da CloudBeaver Nasıl Self-Host Edilir: Veritabanı Sürücüleri, Workspace ve Erişim

En kısa CloudBeaver demosu, bir process'in 8978 portunu dinlediğini kanıtlar. Production ortamı daha güçlü kanıtlar gerektirir. Container değiştirildikten sonra bile şu senaryoyu başarıyla tamamlamalıdır: administrator setup'ını tamamlamak, gereken driver'ı yüklemek, private hostname üzerinden bağlanmak ve salt okunur bir query çalıştırmak.

CloudBeaver belirli bir amaçla deploy edilir: Postgres, MySQL ve daha fazlası için browser tabanlı bir database client. En yaygın deployment tuzağı, workspace izinlerinin başarısız olması veya container DNS'inin database host'larını çözememesidir. Bu nedenle public URL yönetimi ve kalıcı state, image startup'ı kadar dikkat gerektirir.

Boş bir host üzerinde CloudBeaver'ı geri yükleme

İlk gerçek kayıt oluşturulmadan önce state'i listeleyin: workspace, kullanıcılar, connection tanımları ve credentials storage. Bootstrap işleminden önce /opt/cloudbeaver/workspace dizinini mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Zararsız veriler yazarak, CloudBeaver'ı değiştirerek ve verileri yeniden okuyarak mount'u doğrulayın.

Snapshot'lar hızlı rollback için değerlidir; ancak host veya volume ortadan kalktığında bağımsız bir backup gerekir. Pinned image ile boş bir environment'a restore edin ve her underlying database kendi backup planını uygularken workspace, kullanıcılar, driver'lar ve connection'ların geri geldiğini doğrulayın. Bu iki recovery mekanizmasını birbirinden ayrı tutmak için persistent volume ve snapshot'larını kullanın.

CloudBeaver'ı gözlemlenebilir varsayılanlarla başlatma

Aşağıdaki komut, her external service'i provision ediyormuş gibi davranmadan container sınırını görünür kılar.

docker run -d \
  --name cloudbeaver \
  --restart unless-stopped \
  -p 127.0.0.1:8978:8978 \
  -v cloudbeaver-data:/opt/cloudbeaver/workspace \
  -e CB_SERVER_NAME=CloudBeaver \
  dbeaver/cloudbeaver:latest

Ingress'i açmadan önce çözümlenmiş environment'ı, mount'ları ve listener'ı inceleyin. Private route'lar için gözden geçirilmiş connection ayarlarını ve her target database için database driver'larını ekleyin; private service'ler için private name'ler kullanın. Başarılı bir launch, docker ps çıktısında Up görünmesiyle değil, administrator setup'ını tamamlayabildiğiniz, gereken driver'ı yükleyebildiğiniz, private hostname üzerinden bağlanabildiğiniz ve salt okunur bir query çalıştırabildiğiniz anda tamamlanır.

CloudBeaver'ın bağımlılıkları

CloudBeaver HTTP process'i 8978 portunu dinler; bu portu application network üzerinde tutun ve yalnızca platform route'unu publish edin. CloudBeaver için network contract, her target database'e yönelik private route'lar ve database driver'larıdır. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve CloudBeaver'a kapsamı sınırlandırılmış bir service credential verin.

Sınırı kısa bir contract olarak yazılı hâle getirin: gereksinimin sahibi kim, hangi credential kullanılıyor, kabul edilebilir timeout ne ve hata nasıl görünüyor? Ardından şu transaction'ı çalıştırın: administrator setup'ını tamamlamak, gereken driver'ı yüklemek, private hostname üzerinden bağlanmak ve salt okunur bir query çalıştırmak. Çalışma sırasında workspace state'ini, driver download'larını, eşzamanlı session'ları ve her database'e giden network latency'yi gözlemleyin; çünkü bu workload, boşta çalışan bir container'dan daha kullanışlı bir başlangıç boyutu sunar.

Internal ve external URL'leri birbirinden ayırma

CloudBeaver için public boundary; tek bir canonical hostname, automatic TLS ve 8978 üzerindeki tek bir internal target olmalıdır. Server URL'yi ve proxy header'larını public HTTPS origin için ayarlayın; böylece client'lar service'in tanıdığı bir adrese geri döner.

Acceptance transaction başarısız olursa ilk hatayı sınıflandırın. DNS, certificate ve 502 sorunları TLS doğrulama kontrol listesine aittir. “Workspace izinleri başarısız oluyor veya container DNS'i database host'larını çözemiyor” durumu ise bir request CloudBeaver'a başarıyla ulaştıktan sonraki application tarafına aittir.

CloudBeaver için production acceptance çalıştırması

CloudBeaver için ilk kullanıcı trafiğini acceptance test'i olarak kullanmayın. Zararsız örnek state hazırlayın ve şu işlemin tamamını çalıştırın: “administrator setup'ını tamamlamak, gereken driver'ı yüklemek, private hostname üzerinden bağlanmak ve salt okunur bir query çalıştırmak”. Çalıştırmayla ilişkili tam public URL'yi, sonucu, image reference'ını ve log aralığını not edin.

Container'ı değiştirin ve data'yı yeniden oluşturmadan tekrarlayın. Ardından boş bir host üzerinde recovery gerçekleştirin; recovery koşulu, her underlying database kendi backup planını uygularken workspace, kullanıcılar, driver'lar ve connection'ların geri gelmesidir. Her geçişte workspace state'ini, driver download'larını, eşzamanlı session'ları ve her database'e giden network latency'yi gözlemleyin; idle container metric'leri yerine transaction'daki bozulma etrafında bir alert tanımlayın.

Son bir kontrol kasıtlı olarak başarısız olmalıdır: test identity'sinin her target database için private route'lara ve database driver'larına erişimini geçici olarak engelleyin. Ortaya çıkan CloudBeaver mesajının, data silme veya sonsuz bir restart tetiklemek yerine ilgili sınırı belirlediğini doğrulayın. Geçerli koşulu geri yükleyin ve aynı örnek transaction'ın başarılı olduğunu onaylayın. Bu kısa drill'i release checklist'inde tutun.

Sağlıklı görünen bir CloudBeaver'ı teşhis etme

CloudBeaver için ilk yararlı operational metric, administrator setup'ını tamamlayıp tamamlayamadığı, gereken driver'ı yükleyip yükleyemediği, private hostname üzerinden bağlanıp bağlanamadığı ve salt okunur bir query çalıştırıp çalıştıramadığıdır. Buna workspace state'i, driver download'ları, eşzamanlı session'lar ve her database'e giden network latency için saturation sinyallerini ekleyin. Yalnızca process'i kontrol eden bir probe, pahalı dependency'leri çağırmamalı veya upstream kısa süreliğine kullanılamadığında container'ı restart etmemelidir.

CloudBeaver workspace migration'ları ve driver uyumluluğu image version'ları değiştirilmeden önce test edilmesi gerektiği için upgrade'leri data değişikliği olarak ele alın. Version'ları pinleyin, restore edilmiş state üzerinde prova yapın ve rollback geçerli kaldığı sürece önceki image'ı hazır tutun. Workspace izinleri başarısız olduğunda veya container DNS'i database host'larını çözemediğinde restart öncesindeki log'ları koruyun; bu log'lar genellikle nedensel mesajı içerir.

CloudBeaver'a özgü security kararları

Security varsayımlarını local bir tutorial'dan devralmayın. CloudBeaver'a özgü temel konu, production database connection'larına anonymous access izni verilmesidir. Bu nedenle production'da anonymous administration'ı devre dışı bırakın, bireysel kullanıcılar kullanın ve database account'larına yalnızca her connection'ın ihtiyaç duyduğu izinleri verin.

CB_SERVER_NAME gizlilikten çok davranışı kontrol eder; type'ını ve değerini doğrulayın, gerçek CloudBeaver credential'larını ayrı saklayın. Filesystem ve network erişimini kapsamlandırın, setup endpoint'lerini koruyun ve workspace state'i, driver download'ları, eşzamanlı session'lar ve her database'e giden network latency etrafında upload, request veya execution limit'leri tanımlayın.

Dockup deployment'ı hâlâ bir CloudBeaver acceptance testi gerektirir

Dockup'ın tek tıklamalı CloudBeaver deployment'ı replacement işlemini güvenli hâle getirmelidir: route 8978'i hedeflemeye devam etmeli, secret'lar image içine gömülmemeli ve kalıcı path'ler yeni container'da geri gelmelidir. Aynı deployment, Dockup compute üzerinde veya bağlı bir machine'de çalışabilir.

Private route'lara ve her target database için database driver'larına bağlanıp test ederek, canonical public address'i uygulayarak ve şu acceptance kontrolünü çalıştırarak app'e özgü işlemleri tamamlayın: administrator setup'ını tamamlamak, gereken driver'ı yüklemek, private hostname üzerinden bağlanmak ve salt okunur bir query çalıştırmak. Gerçek kullanıcılar gelmeden önce restore sonucunu runbook'a ekleyin.

Sık sorulan sorular

Production deployment için CloudBeaver'ın neye ihtiyacı vardır?

CloudBeaver container'ını 8978 portu üzerinden tek bir HTTPS origin'e route edin. Destekleyici network gereksinimi, her target database için private route'lar ve database driver'larıdır. Administrator setup'ını tamamlayıp gereken driver'ı yükleyemediğiniz, private hostname üzerinden bağlanamadığınız ve salt okunur bir query çalıştıramadığınız sürece CloudBeaver'ı hazır kabul etmeyin.

Hangi CloudBeaver verileri backup'a dahil edilmelidir?

/opt/cloudbeaver/workspace dizinini persist edin ve workspace, kullanıcılar, connection tanımları ile credentials storage'ı aynı recovery manifest'ine dahil edin. Temiz bir CloudBeaver restore'u yalnızca her underlying database kendi backup planını uygularken workspace, kullanıcılar, driver'lar ve connection'lar geri geldiğinde başarılı sayılır.

CloudBeaver reverse proxy arkasında HTTPS gerektirir mi?

Public CloudBeaver origin'i için HTTPS kullanın ve 8978 portunu internal route üzerinde tutun. CloudBeaver ayarını doğru şekilde uygulayın: server URL'yi ve proxy header'larını public HTTPS origin için ayarlayın. CloudBeaver için HTTPS, credentials veya user content'in transit sırasında korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Bir CloudBeaver upgrade'i nasıl test edilmelidir?

Mevcut CloudBeaver state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. CloudBeaver workspace migration'ları ve driver uyumluluğu image version'ları değiştirilmeden önce test edilmesi gerektiğinden özellikle bu noktaya dikkat edin. Data migration ve rollback sınırı anlaşılana kadar önceki CloudBeaver image'ını saklayın.