Docker context, Docker CLI'nin hangi Docker daemon'a bağlanacağını belirleyen adlandırılmış bir ayar kümesidir. Kendi bilgisayarınızdan bir VPS'teki Docker'ı yönetmek için docker context create uzak --docker host=ssh://kullanici@sunucu ile bir context oluşturur, docker context use uzak ile ona geçersiniz; bundan sonra çalıştırdığınız docker ps, docker compose up gibi komutlar uzak sunucudaki daemon'a gider. Yerel daemon'a dönmek için docker context use default yeterlidir.

Bu yazıda bir context'in nelerden oluştuğunu, ls, inspect, create, use, export, import ve update alt komutlarını, DOCKER_CONTEXT ve DOCKER_HOST ortam değişkenleriyle --context bayrağının hangi sırayla geçerli olduğunu ve Compose'un context'leri nasıl kullandığını anlatıyoruz. Daemon soketini SSH ve TLS ile korumanın ayrıntıları Docker daemon uzak erişim yazısında, serinin tamamı Docker öğrenme rehberinde.

Context neden kullanılır?

Context neden kullanılır?

Tek bir Docker istemcisi birden fazla daemon'u yönetebilir. Belgelerdeki tipik örnekte bir istemcide iki context vardır: yerelde çalışan varsayılan context ve uzaktaki, paylaşılan bir context. Context'ler tanımlandıktan sonra docker context use <ad> ile aralarında geçiş yaparsınız.

Sunucu yöneticisi için pratik karşılığı şudur: her seferinde sunucuya SSH ile girip komut çalıştırmak yerine, kendi makinenizdeki Docker CLI ile üretim, test ve yerel ortamlar arasında tek komutla geçiş yaparsınız. Compose dosyalarınız, Dockerfile'larınız ve betikleriniz yerel makinenizde kalır; komutların hedefi değişir.

Bir context neyden oluşur?

Bir context birkaç özelliğin birleşimidir: ad ve açıklama, uç nokta (endpoint) yapılandırması ve TLS bilgileri. Mevcut context'leri docker context ls ile listelersiniz. Belgelerdeki çıktıda tek bir context vardır:

bash
docker context ls
NAME        DESCRIPTION                               DOCKER ENDPOINT               ERROR
default *                                             unix:///var/run/docker.sock

default adlı bu context yerel /var/run/docker.sock Unix soketi üzerinden daemon ile konuşur. NAME sütunundaki yıldız etkin context'i gösterir: aksi belirtilmedikçe tüm docker komutları bu context'e gider. Daha ayrıntılı bilgi için docker context inspect kullanılır; belgelerdeki çıktı uç noktanın adresini ve TLS doğrulamasının atlanıp atlanmadığını gösterir:

bash
docker context inspect default
[
    {
        "Name": "default",
        "Metadata": {},
        "Endpoints": {
            "docker": {
                "Host": "unix:///var/run/docker.sock",
                "SkipTLSVerify": false
            }
        },
        "TLSMaterial": {},
        "Storage": {
            "MetadataPath": "\u003cIN MEMORY\u003e",
            "TLSPath": "\u003cIN MEMORY\u003e"
        }
    }
]

Yeni context oluşturmak

Context'ler docker context create ile oluşturulur. Uç nokta --docker bayrağına host=... biçiminde verilir. Belgelerdeki ilk örnek TCP soketine işaret eden bir context oluşturur:

bash
docker context create docker-test --docker host=tcp://docker:2375
docker-test
Successfully created context "docker-test"

Yeni context ~/.docker/contexts/ altında, kendine ait bir alt dizindeki meta.json dosyasında saklanır. Her context kendi dizinini ve meta.json dosyasını alır. Yani context'ler istemci tarafında tutulan ayarlardır; uzak sunucuda bir şey oluşturmaz.

SSH ile uzak sunucu context'i

Uzak bir sunucuyu yönetmenin en sade yolu SSH'tir. Daemon soketini koruma belgesindeki örnek, host1.example.com üzerindeki daemon'a docker-user kullanıcısıyla bağlanan bir context oluşturur:

bash
docker context create \
    --docker host=ssh://docker-user@host1.example.com \
    --description="Remote engine" \
    my-remote-engine

Buradaki kullanıcının uzak makinede Docker soketine erişim izni olmalıdır. Bu genellikle kullanıcıyı uzak sunucuda docker grubuna eklemek anlamına gelir; bu grubun root düzeyinde yetki verdiğini unutmayın. Ayrıntılar için sudo olmadan Docker çalıştırma yazısına ve kullanıcı yönetimi için Linux kullanıcı ve grup yönetimi yazısına bakın.

Belgeler SSH ile en iyi deneyim için ~/.ssh/config dosyasında bağlantının yeniden kullanılmasını önerir. Böylece her docker komutu yeni bir SSH bağlantısı açmaz:

bash
ControlMaster     auto
ControlPath       ~/.ssh/control-%C
ControlPersist    yes

TLS ile bağlanmak isterseniz --docker değerine uç noktanın yanında CA, sertifika ve anahtar dosyaları da eklenebilir; yerel docker context create --help çıktısı ca, cert, key ve skip-tls-verify alanlarını listeler. Sertifikaların nasıl üretileceği ve daemon'un nasıl yapılandırılacağı SSH ve TLS ile daemon erişimi yazısında anlatılıyor.

Context değiştirmek ve öncelik sırası

Context değiştirmek ve öncelik sırası: docker context use AD, DOCKER_CONTEXT ortam değişkeni, --context bayrağı, DOCKER_HOST veya --host

docker context use komutu CLI'nin varsayılan context'ini değiştirir. Belgelerdeki örnekte geçişten sonra docker context ls çıktısında yıldız docker-test satırına taşınır:

bash
docker context use docker-test
docker-test
Current context is now "docker-test"

Bundan sonra docker komutları bu context'te tanımlı uç noktaya gider. SSH context'i için de aynı geçerlidir: docker context use my-remote-engine sonrasında docker info uzak motorun bilgilerini verir. Yerel daemon'a docker context use default ile dönersiniz.

Etkin context'i geçici olarak değiştirmenin üç yolu daha vardır ve hangisinin kazandığını bilmek önemlidir:

YöntemKapsamNot
docker context use ADKalıcı, sonraki tüm komutlarCLI yapılandırmasındaki varsayılanı değiştirir
DOCKER_CONTEXT ortam değişkeniO kabuk oturumudocker context use ile seçilen context'i geçersiz kılar
--context bayrağıTek komutGlobal bayrak; komut satırında verilir
DOCKER_HOST veya --hostOturum ya da tek komutContext oluşturmadan doğrudan bir daemon adresine bağlanır
bash
export DOCKER_CONTEXT=docker-test

docker --context production container ls

Belgelere göre etkin context, DOCKER_HOST ve DOCKER_CONTEXT gibi ortam değişkenleri ya da komut satırındaki --context ve --host bayraklarıyla geçersiz kılınmadıkça tüm komutlarda kullanılır. DOCKER_CONTEXT değişkeninin docker context use ile yapılan seçimi geçersiz kıldığı da belgede açıkça yazılıdır. PowerShell'de aynı değişken $env:DOCKER_CONTEXT='docker-test' ile ayarlanır.

Context oluşturmadan DOCKER_HOST

Kısa süreli bir bağlantı için context oluşturmak zorunda değilsiniz. Belgeler DOCKER_HOST değişkeniyle CLI'yi geçici olarak SSH üzerinden uzak sunucuya yönlendirmeyi gösterir:

bash
export DOCKER_HOST=ssh://docker-user@host1.example.com
docker info

Bu yöntemin bir yan etkisi vardır: değişken kabuk başlangıç dosyalarınızda kalırsa tüm komutlarınız beklenmedik şekilde uzak sunucuya gider. Daemon sorunlarını giderme belgesi, istemcinin nereye bağlandığını görmek için değişkeni kontrol etmeyi ve yanlışlıkla ayarlanmışsa kaldırmayı önerir; kalıcı olarak ayarlanmasını önlemek için ~/.bashrc veya ~/.profile gibi dosyaları düzenlemeniz gerekebilir.

bash
env | grep DOCKER_HOST

unset DOCKER_HOST

Context dışa ve içe aktarma, güncelleme

Bir context'i başka bir makineye taşımak için docker context export ve docker context import kullanılır. Dışa aktarılan dosya, docker istemcisi kurulu herhangi bir makinede içe aktarılabilir. Belgelerdeki örnekler ve çıktıları şöyledir:

bash
docker context export docker-test
Written file "docker-test.dockercontext"

docker context import docker-test docker-test.dockercontext
docker-test
Successfully imported context "docker-test"

İçe aktarma komutunun biçimi docker context import <ad> <dosya> şeklindedir. Var olan bir context'in alanlarını değiştirmek için docker context update kullanılır; belgelerdeki örnek açıklama alanını günceller:

bash
docker context update docker-test --description "Test context"
docker-test
Successfully updated context "docker-test"

Yerel CLI yardımında bunlara ek olarak docker context show ve docker context rm alt komutları da listelenir. Kullanmadığınız context'leri silmeden önce hangisinin etkin olduğunu docker context ls ile kontrol edin.

Compose ve context'ler

Docker Compose, DOCKER_HOST ve DOCKER_CONTEXT gibi yaygın Docker CLI ortam değişkenlerini devralır. Yani bir context'e geçtiğinizde docker compose up -d de o context'in daemon'unda çalışır. Compose'un üretim belgesi de tek bir sunucuya dağıtım için DOCKER_HOST, DOCKER_TLS_VERIFY ve DOCKER_CERT_PATH değişkenlerini uygun şekilde ayarlamayı, sonrasında normal docker compose komutlarının ek yapılandırma olmadan çalışacağını anlatır.

bash
docker context use my-remote-engine
docker compose up -d
docker context use default

Compose ile üretim düzeninin genel kuralları için Docker Compose rehberine, CI üzerinden imaj üretip dağıtmak için GitHub Actions CI/CD rehberine göz atabilirsiniz.

Uygulamalı örnek: yerel makineden VPS yönetimi

Belgelerdeki parçaları bir araya getirerek yerel makinenizden bir VPS'i yönetmek için izleyeceğiniz yol şöyle özetlenebilir. Önce sunucuda Docker'ı kurar ve bağlanacağınız kullanıcıya soket erişimi verirsiniz; kurulum için Ubuntu kurulum yazısına bakabilirsiniz. Sonra yerel makinenizde, SSH anahtarınızla zaten bağlanabildiğiniz kullanıcıyla bir context oluşturursunuz:

bash
docker context create vps \
    --docker host=ssh://deploy@sunucu.example.com \
    --description="Üretim VPS"

Context'e geçmeden önce tek komutluk --context bayrağıyla bağlantıyı denemek iyi bir alışkanlıktır; böylece etkin context'iniz değişmez ve bir hata olursa yerel ortamınız etkilenmez:

bash
docker --context vps info

docker --context vps container ls

Bağlantı çalışıyorsa ister docker context use vps ile kalıcı olarak geçer, ister kritik komutlarda --context vps yazmaya devam edersiniz. Birden fazla sunucunuz varsa her biri için açıklaması dolu bir context oluşturmak, docker context ls çıktısını okunur kılar.

Context kullanırken güvenlik

Context yalnızca bir adres defteridir; güvenlik, arkasındaki bağlantının nasıl korunduğuna bağlıdır. Docker Engine güvenlik belgesi daemon API'sini HTTP üzerinden açmanın riskini açıkça anlatır: bir güvenlik duvarı API'ye diğer makinelerden erişimi sınırlasa bile uç nokta container'lardan erişilebilir kalabilir ve bu kolayca yetki yükseltmeye yol açabilir. Bu yüzden API uç noktalarını HTTPS ve sertifikalarla korumak zorunludur ve uç noktanın yalnızca güvenilir bir ağdan ya da VPN'den erişilebilir olması önerilir. SSH'yi TLS'e tercih ediyorsanız belge DOCKER_HOST=ssh://USER@HOST kullanımını ya da ssh -L ile soket yönlendirmeyi alternatif olarak gösterir.

Bir ayrıntı daha: Engine 29.0.0 sürüm notlarına göre Docker CLI, context meta verisinde "GODEBUG":"..." anahtar-değer çifti varsa GODEBUG ortam değişkenini ayarlayabiliyor. Bu, context'lerin yalnızca adres değil, bağlantıya özgü ayarlar da taşıyabildiğini gösterir; kimden geldiğini bilmediğiniz bir context dosyasını içe aktarmayın. Sunucu tarafındaki genel sertleştirme adımları için VPS güvenlik sertleştirme yazısına göz atın.

Sık yapılan hatalar

Sık yapılan hatalar: Hangi context'te olduğunu unutup üretim sunucusunda komut çalıştırmak. Kritik..., Kabuk dosyasında unutulmuş bir DOCKER_HOST değişkeni. Context seçiminiz...
  • Hangi context'te olduğunu unutup üretim sunucusunda komut çalıştırmak. Kritik işlemlerden önce docker context ls çıktısındaki yıldıza bakın ya da tek komutluk --context bayrağını tercih edin.
  • Kabuk dosyasında unutulmuş bir DOCKER_HOST değişkeni. Context seçiminiz beklediğiniz gibi çalışmıyorsa önce env | grep DOCKER_HOST çalıştırın.
  • docker context use ile seçim yapıp DOCKER_CONTEXT değişkeninin hâlâ başka bir context gösterdiğini fark etmemek. Değişken, docker context use ile yapılan seçimi geçersiz kılar.
  • Daemon'u şifrelenmemiş TCP ile açıp ona context oluşturmak. Güncel Engine bunu kabul etmez; SSH veya TLS kullanın.
  • SSH kullanıcısının uzak sunucuda soket iznine sahip olmaması.
  • Uzak context'te yerel dosya yollarıyla bind mount beklemek.

Sık Sorulan Sorular

Context bilgileri nerede saklanır?

Her context ~/.docker/contexts/ altında kendi alt dizinindeki bir meta.json dosyasında saklanır. default context ise belgelerdeki inspect çıktısında görüldüğü gibi bellekte tutulur.

Context mi kullanmalıyım, DOCKER_HOST mu?

Sürekli kullandığınız sunucular için context daha düzenlidir: adı, açıklaması ve TLS bilgileri bir arada durur ve ls ile görünür. Tek seferlik bir bağlantı için DOCKER_HOST pratiktir, ancak kalıcı hale gelirse kafa karıştırır.

Uzak context ile Docker Compose çalışır mı?

Evet. Compose, DOCKER_HOST ve DOCKER_CONTEXT değişkenlerini Docker CLI'den devralır; etkin context neyse Compose da o daemon'da çalışır.

SSH bağlantısı her komutta yavaşlıyor, ne yapabilirim?

Belgelerin önerdiği ControlMaster, ControlPath ve ControlPersist ayarlarını ~/.ssh/config dosyasına ekleyerek aynı SSH bağlantısının birden fazla docker komutunda yeniden kullanılmasını sağlayın.

Bir context'i silmek uzak sunucudaki container'ları etkiler mi?

Context'ler istemci makinede, ~/.docker/contexts/ altındaki meta.json dosyalarında tutulan bağlantı ayarlarıdır. Bir context'i kaldırmak bu yerel ayarı siler; uzak daemon'daki container'lar, imajlar ve volume'lar o daemon'da kalır. Aynı sunucuya daha sonra yeni bir context oluşturarak yeniden bağlanabilirsiniz.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Docker öğrenme rehberi · Daemon uzak erişim: SSH ve TLS · docker grubu ve izinler · Cannot connect to the Docker daemon · VPS güvenlik sertleştirme