Docker API’sini açmadan Linux VPS için arayüz

Kısıttan başla

Kural basit: Docker daemon’ı yerel UNIX soketinde, /var/run/docker.sock üzerinde kalır ve onun için hiçbir TCP portu açılmaz. Bu sokete erişim makinede root demektir; ona yalnızca zaten makinede olan süreçler ulaşmalıdır.

Kurala uyan her arayüzün iki şeye ihtiyacı var: sunucu tarafında soketle yerel olarak konuşan bir parça ve senin o parçaya kimliği doğrulanmış, şifreli bir yoldan ulaşman.

Tarayıcı bunu neden tek başına yapamaz

Bir web sayfası uzak bir makinede SSH bağlantısı ya da UNIX soketi açamaz; yalnızca bir adrese HTTP konuşabilir. Bu yüzden tarayıcı tabanlı bir arayüz, Docker kısmını onun yerine yapan bir web sunucusuna her zaman ihtiyaç duyar — ya Docker makinesinin kendisinde ya da makineye bir ajan üzerinden ulaşan başka bir yerde.

SSH ise sorunun ikinci yarısını zaten çözüyor. Bir anahtarın var, sunucu onu doğruluyor, kanal şifreli ve herkese açık bir portta yeni hiçbir şeyin dinlemesi gerekmiyor.

Biçim 1: yalnızca SSH tüneliyle ulaşılan bir web paneli

Sunucuda bir web paneli çalıştırıp portunu yalnızca loopback adresinde yayınlayarak onu internetten uzak tutabilirsin. Tarayıcın ona bir SSH port yönlendirmesiyle ulaşır.

Yeni kurulan bir Portainer, yönetici kullanıcısının birkaç dakika içinde oluşturulmasını bekler ve kimse oluşturmazsa kurulum ekranını kilitler. Önce tüneli aç; süreyi kaçırırsan konteyneri yeniden başlat.

# sunucuda
docker volume create portainer_data
docker run -d --name portainer --restart=always \
  -p 127.0.0.1:9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:lts

# kendi bilgisayarında; sonra https://localhost:9443 adresini aç
ssh -N -L 9443:127.0.0.1:9443 deploy@203.0.113.10

127.0.0.1: öneki göründüğünden daha önemli. Docker bir portu tüm arayüzlerde yayınladığında trafik, Docker’ın kendi yazdığı kurallarla yönlendirilir ve ufw gibi bir host güvenlik duvarı onu görmeden geçer.

Biçim 2: sunucuda bir ajan

Bazı araçlar Docker daemon’ının yanına küçük bir ajan kurar. Ajan soketle yerel olarak konuşur ve ya merkezi bir panelden bağlantı kabul eder ya da ona kendisi bağlanır. Birçok sunucu için tek bir arayüz elde edersin ve ona her tarayıcıdan ulaşılır.

Soketi tutan parça ajan olduğundan, onun kimlik doğrulaması ve güncelleme takvimi sunucunun güvenliğinin bir parçası olur. Bir ekip için makul bir takas; yaptığını bilmeye değer.

Biçim 3: SSH üzerinden masaüstü istemcisi

Bir masaüstü uygulaması SSH bağlantısını kendisi açıp sunucuda docker komutlarını tam terminalde yapacağın gibi çalıştırabilir. Daemon soketinde kalır; ağda dinleyen tek şey zaten sahip olduğun SSH sunucusudur.

Sınırlar avantajların aynadaki yansıması: arayüz yalnızca kurulu olduğu bilgisayarlarda ve yalnızca açıkken var.

Pencereyi kapattıktan sonra ne çalışmaya devam ediyor

1. 01Web paneline tünel: panel, Docker soketi bağlı hâlde sunucuda çalışmaya devam eder. Yalnızca tünel kapanır.
2. 02Ajan: ajan çalışmaya ve paneline bağlı kalmaya devam eder. Varlık sebebi bu.
3. 03Masaüstü istemcisi: istemciye ait hiçbir şey çalışmaya devam etmez — belirli bir iş için sunucuya bir bileşen kurmadıysa.

Hiçbiri yanlış değil. Asıl soru, sen yokken sunucunda bir şeyin uyanık olması gerekip gerekmediği — gerekiyorsa da hangi kimlik bilgilerini tuttuğu.

MihraOps nereye düşüyor

MihraOps biçim 3. Zaten kullandığın SSH anahtarı ya da parolayla bağlanır, sunucunun host parmak izini kontrol eder ve konteynerleri, logları ve canlı kullanımı hiçbir port açmadan gösterir. Sunucu kimlik bilgilerin işletim sisteminin şifreli deposunda kalır.

Biçim 2’den de bilerek küçük tutulmuş bir parçası var: dağıtım webhook’ları ile izleme ve e-posta uyarıları için kurabileceğin isteğe bağlı bir Agent. Bunlar bilgisayarın kapalıyken de çalışmak zorunda. Agent olmadan MihraOps sunucuda yalnızca sıradan Docker konteynerleri bırakır — uygulamaların ve bir domain yayınladıysan bir Caddy proxy’si.

Kabul edilmesi gereken sınır: uygulamanın kurulu olmadığı bir bilgisayardan içeri girmenin yolu yok.