2026'da Shlink Kendi Sunucunuzda Nasıl Barındırılır: Alan Adları, API Anahtarları ve İstatistikler

Shlink'i kendi sunucunuzda barındırmanın asıl faydası ilk docker run komutunda değil, ilk yeniden dağıtımda ortaya çıkar. Oluşturulan linkler HTTP kullanıyorsa veya migration'lar veritabanına ulaşamıyorsa Docker yine tamamen sağlıklı bir process bildirimi yapabilir. Aşağıdaki deployment, gözlemlenebilir davranışlar etrafında düzenlenmiştir: API üzerinden kısa bir URL oluşturmak, yönlendirmesini takip etmek, ziyaretleri kaydetmek ve web client üzerinden istatistikleri incelemek.

Shlink'in temel amacı nettir: istatistiklere sahip, API-first bir link kısaltıcı. Bu tanım, hangi bileşenlerin public kalması, hangilerinin private tutulması ve bir yedeklemenin neleri yeniden oluşturması gerektiğini gösterir.

Shlink'in bağımlılıkları

Shlink için process sağlığı ile ürün sağlığı birbirinden ayrıdır. 8080 portu yanıt verirken kullanıcıya görünen işlem yine de başarısız olabilir. Shlink'in network sözleşmesi, production için Postgres veya MariaDB ile isteğe bağlı Redis'ten oluşur. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Shlink'e kapsamı sınırlandırılmış bir service credential sağlayın.

Anlamlı configuration değişikliklerinden sonra şu readiness çalışmasını gerçekleştirin: API üzerinden kısa bir URL oluşturun, yönlendirmesini takip edin, ziyaretleri kaydedin ve web client üzerinden istatistikleri inceleyin. Pahalı external check'leri liveness probe'larından uzak tutun; böylece bir provider kesintisi restart loop'a neden olmaz. Capacity çalışmaları; page request'lerinden ziyade Shlink'in gerçek yükünü daha iyi yansıtan redirect throughput, veritabanı yazma işlemleri, geolocation download'ları ve cache davranışını takip etmelidir.

Volumes yalnızca ilk recovery katmanıdır

Standart Shlink image'ı içinde yazılabilir bir application state bulunması beklenmez. Boş bir container filesystem'ını yedeklemek yerine veritabanını, API anahtarlarını ve içe aktarılmış visit data'yı; pinned digest'i ve gözden geçirilmiş route configuration'ı da kapsayacak şekilde koruyun.

Shlink'i başka bir host üzerinde sıfırdan oluşturun ve domain'lerin, short code'ların, tag'lerin ve visit record'larının geri döndüğünü; örneklenen her kısa URL'nin aynı şekilde yönlendirildiğini doğrulayın. Ayrı bir database, room server veya authentication layer eklenirse bu bileşene kendi açık recovery sorumlusunu atayın. Git-to-production rehberi, tekrarlanabilir bir artifact'in container backup'ının yerini nasıl aldığını gösterir.

Rebuild komutunu ve beklenen çıktıyı doğrulayan testi release ile birlikte kaydedin. Stateless bir recovery planı, davranışı güvenilir input'lar üzerinden yeniden oluşturarak başarılı olur; çalışan, içeriği belirsiz bir container'ın kopyalanmasına bağlı olmamalıdır.

Shlink'in değerli kısmını koruyun

Güvenli bir Shlink deployment'ı authority'yi azaltarak başlar. REST API key'i açığa çıkarmaktan veya link'ler yayınlandıktan sonra public domain'i değiştirmekten kaçının; bunun yerine API key'lerini browser code'dan uzak tutun, HTTPS kullanın ve redirect'leri public bırakırken administration'ı kısıtlayın.

DEFAULT_DOMAIN bir secret değil, configuration değeridir; değerini açıkça belirtirken Shlink tarafından kullanılan ayrı credential'ları koruyun. Administrative route'ları kısıtlayın, dependency'ler için private DNS kullanın ve her bind mount'u gözden geçirin. Log'lar merkezi olarak gönderildiğinde, server'dan çıkmadan önce secret'ları ve private content'i filtreleyin.

Shlink smoke test'ini release kontrolüne dönüştürün

Shlink için launch öncesinde bilinen ve doğru çalışan bir transaction tanımlayın: API üzerinden kısa bir URL oluşturun, yönlendirmesini takip edin, ziyaretleri kaydedin ve web client üzerinden istatistikleri inceleyin. Prerequisite'lerini, beklenen response'u ve cleanup adımlarını secret değerleri içermeden version control'de tutun. Bu reference'ı oluşturmak için kullanılan image'ı pin'leyin.

Bir replacement'ı ve bağımsız bir restore işlemini doğrulamak için bu transaction'ı kullanın. Restore edilen service ancak domain'ler, short code'lar, tag'ler ve visit record'ları geri döndüğünde ve örneklenen her kısa URL aynı şekilde yönlendirildiğinde kabul edilebilir. Aynı zamanda redirect throughput'u, veritabanı yazma işlemlerini, geolocation download'larını ve cache davranışını gözlemleyin; en yavaş veya en kısıtlı bileşeni service-level alert'e dönüştürün.

Gate'in bir negative case'e de ihtiyacı vardır: test identity'sinin Postgres veya MariaDB ile production için isteğe bağlı Redis'e erişimini geçici olarak engelleyin. Shlink'in verileri koruyarak actionable bir error ürettiğini doğrulayın, geçerli koşulu geri yükleyin ve bilinen doğru transaction'ı tekrarlayın. Her iki sonucu da saklamak, yüzeysel bir health endpoint'inin production'daki tek kanıta dönüşmesini engeller.

Hareketli parçaları gizlemeden Shlink'i başlatın

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 shlink \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -e DEFAULT_DOMAIN=go.example.com \
  shlinkio/shlink:stable

Ingress'i açmadan önce resolve edilmiş environment'ı, mount'ları ve listener'ı inceleyin. Postgres veya MariaDB ile production için isteğe bağlı Redis'e yönelik gözden geçirilmiş connection setting'lerini 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; API üzerinden kısa bir URL oluşturabildiğinizde, yönlendirmesini takip edebildiğinizde, ziyaretleri kaydedebildiğinizde ve web client üzerinden istatistikleri inceleyebildiğinizde tamamlanır.

Shlink'e tek bir canonical adres verin

Shlink'in public sınırı tek bir canonical hostname, automatic TLS ve 8080 üzerindeki tek bir internal target olmalıdır. Kısa URL'ler oluşturmadan önce DEFAULT_DOMAIN ve IS_HTTPS_ENABLED değerlerini ayarlayın; böylece client'lar service'in tanıdığı bir adrese yönlendirilir.

Acceptance transaction başarısız olursa ilk hatayı sınıflandırın. DNS, certificate ve 502 sorunları TLS doğrulama checklist'ine aittir. “Oluşturulan linkler HTTP kullanıyor veya migration'lar veritabanına ulaşamıyor” koşulu, bir request Shlink'e başarıyla ulaştıktan sonraki application tarafına aittir.

Sağlıklı göründüğü hâlde sorunlu olan Shlink'i teşhis edin

Shlink için process yerine transaction'ı izleyin: API üzerinden kısa bir URL oluşturun, yönlendirmesini takip edin, ziyaretleri kaydedin ve web client üzerinden istatistikleri inceleyin. Alert'in kısıtlı bileşeni belirleyebilmesi için latency ve error rate'i redirect throughput, veritabanı yazma işlemleri, geolocation download'ları ve cache davranışıyla birlikte değerlendirin.

Upgrade rehearsal, database migration'larının ve API compatibility'nin aşamalı olarak uygulanması gerektiğini kapsamalıdır; çünkü yayınlanmış kısa link'ler manuel bir düzeltmeyi bekleyemez. Production replacement'tan önce restore edin, migration'ı uygulayın ve transaction'ı çalıştırın. Oluşturulan linkler HTTP kullanıyorsa veya migration'lar veritabanına ulaşamıyorsa startup'ı yeşile döndürmek için verileri silmeyin; version, variable, mount ve dependency erişilebilirliğini bu sırayla karşılaştırın.

Dockup routing'i yönetirken Shlink'i açık tutun

Dockup'ın one-click Shlink deployment'ı replacement işlemini güvenli hâle getirmelidir: route 8080'i hedeflemeye devam etmeli, secret'lar image'a gömülmemeli ve persistent path'ler yeni container'da geri gelmelidir. Aynı deployment Dockup compute üzerinde veya bağlı bir makinede çalışabilir.

App'e özel çalışmaları, Postgres veya MariaDB ile production için isteğe bağlı Redis'e bağlanıp test ederek, canonical public address'i uygulayarak ve şu acceptance check'i çalıştırarak tamamlayın: API üzerinden kısa bir URL oluşturun, yönlendirmesini takip edin, ziyaretleri kaydedin ve web client üzerinden istatistikleri inceleyin. Gerçek kullanıcılar gelmeden önce restore sonucunu runbook'a ekleyin.

Sık sorulan sorular

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

Shlink container'ını 8080 portu üzerinden tek bir HTTPS origin'e yönlendirin. Supporting network requirement, production için Postgres veya MariaDB ile isteğe bağlı Redis'tir. API üzerinden kısa bir URL oluşturamıyor, yönlendirmesini takip edemiyor, ziyaretleri kaydedemiyor ve web client üzerinden istatistikleri inceleyemiyorsanız Shlink'i hazır kabul etmeyin.

Hangi Shlink verileri yedeklenmelidir?

Standart Shlink image'ında zorunlu bir application-data mount'u yoktur. Deployment configuration'ını koruyun ve bağlı state'i ayrı olarak yedekleyin; domain'ler, short code'lar, tag'ler ve visit record'ları geri döndüğünde ve örneklenen her kısa URL aynı şekilde yönlendirildiğinde recovery başarılı olur.

Shlink reverse proxy arkasında HTTPS gerektirir mi?

Public Shlink origin'i için HTTPS kullanın ve 8080 portunu internal route üzerinde tutun. Shlink setting'ini doğru şekilde uygulayın: kısa URL'ler oluşturmadan önce DEFAULT_DOMAIN ve IS_HTTPS_ENABLED değerlerini ayarlayın. Shlink için HTTPS, credentials veya user content'in aktarım sırasında korunmasını sağlar ve origin'e duyarlı client davranışını tutarlı hâle getirir.

Shlink upgrade'i nasıl test edilmelidir?

Mevcut Shlink state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Özellikle dikkat edin; database migration'larının ve API compatibility'nin aşamalı olarak uygulanması gerekir, çünkü yayınlanmış kısa link'ler manuel bir düzeltmeyi bekleyemez. Data migration ve rollback sınırları anlaşılana kadar önceki Shlink image'ını saklayın.