‫Bu bölüm için gereklilikler arasında bir konteynerin nasıl başlatılacağının anlaşılması yer almaktadır. Ardından alt ağlar ve IP'ler, bağlantı noktaları
‫ve güvenlik duvarları gibi temel TCP/IP ağ kavramları.
‫Tüm bunları bilmek zorunda değilsiniz, ancak bir sonraki derste komut
‫satırı konularına girmeden önce kavramsal şeylere
‫odaklanan bu bölümü anlamanızı kesinlikle çok daha kolay hale getirecektir.
‫Sadece konteyner çalıştırma komutlarınızda makinenizdeki portu açığa çıkaran -p seçeneğini
‫hatırlatmak istiyorum.
‫Aslında Docker ağının arka planında konuşacağımız çok daha fazla şey var.
‫Docker, piller dahil ancak çıkarılabilir konseptine sahiptir; bu da temelde varsayılanların oldukça kolay ve
‫yaygın olduğu, ancak kaputun altındaki birçok seçeneği değiştirebileceğiniz anlamına gelir.
‫Bu derste, ağınızda o konteyner için hangi portların açık olduğuna dair hızlı
‫bir çıktı veren konteyner port komutuna hızlıca göz atacağız.
‫Daha sonra Docker ağı, sanal ağlar ve paketlerin ağda nasıl aktığı ile ilgili
‫bazı kavramları açıklayacağız.
‫Ve konteynerlerin birbirleriyle nasıl konuştuğunu ve bunun fiziksel ağa maruz kalmalarından
‫nasıl farklı olduğunu gösteren bir ağ diyagramı ile bitireceğiz.
‫Bir konteyneri gerçekten başlattığınızda, arka planda belirli bir Docker ağına
‫bağlanırsınız. Varsayılan olarak, bir dakika içinde kontrol edeceğimiz gibi, bu köprü ağıdır. Daha sonra bağlanacağınız bu ağların
‫her biri aslında bir NAT güvenlik duvarı üzerinden yönlendirilir, bu da aslında Docker arka plan programının
‫varsayılan arayüzünde ana bilgisayar IP adresini yapılandırmasıdır, böylece konteynerleriniz İnternet'e
‫veya ağınızın geri kalanına gidebilir ve sonra geri dönebilir.
‫Ancak, ana bilgisayarımızın içinde birbirleriyle konuşmak isteyen belirli konteynerlerimiz olduğunda
‫aslında -p'yi kullanmamıza gerek yoktur.
‫Örneğin, bir devam sunucusu ve PHP Apache konteynerine sahip bir uygulamanız varsa, bu iki konteyner
‫aynı ağ üzerinde olmalı ve portlarını fiziksel ağınızın geri kalanına açmadan
‫birbirleriyle konuşabilmelidirler.
‫Diyelim ki Mongo ve Node kullanan ilgisiz başka bir uygulamanız olsaydı. js, bunun için bir ağ oluşturabilirsiniz,
‫böylece onları ağa maruz bırakmak için -p kullanmadan birbirleriyle
‫konuşabilirler. Ancak, ilgisiz bir uygulamanın çalıştığı diğer
‫ağla gerçekten konuşamazlardı.
‫Ancak mesele şu ki, tarif ettiğim tüm bu ayarlar aslında değiştirilebilir.
‫Bu da Docker'ın kullanmayı sevdiği güzel bir sözü gündeme getiriyor... piller dahil ama çıkarılabilir.
‫Bu kurs boyunca çoğu zaman kutudan çıktığı gibi çalışan varsayılanlar olduğunu göreceksiniz.
‫Bunları belirtmenize bile gerek yok. Her şeyin standart bir şekilde yapılandırıldığını fark
‫ediyorsunuz.
‫Ancak bu seçeneklerin birçoğu çalışma zamanında yapılandırılabilir veya hatta daha sonra değiştirilebilir. Ve ağlarla oynadığımızda bunun bir kısmının
‫burada gerçekleştiğini göreceğiz.
‫Aslında değiştirebileceğiniz şeylerden bazıları, uygulama başına bir tane veya farklı
‫güvenlik gereksinimlerine göre farklı birden fazla sanal ağ oluşturmak olabilir.
‫Tıpkı fiziksel dünyada olduğu gibi, gerçek bir bilgisayarda iki fiziksel NIC'ye sahip olabilirsiniz. Aslında bir konteynere bağlı
‫iki sanal ağınız olabilir veya konteynerin hiçbir ağla konuşmamasını
‫sağlayabilirsiniz.
‫Kutudan çıkan sanal ağ yapılandırmasını atlayabilir ve aslında -- net=host kullanabilirsiniz,
‫ancak konteynerleştirme
‫avantajlarından bazılarını kaybedersiniz.
‫Ancak bazı durumlarda gerekli olabilir.
‫Daha sonra, aslında Docker ağ sürücülerine gireceğiz. Docker'ın etrafında Docker'ın
‫yeteneklerini birçok üçüncü parti araca genişleten bir eklenti ekosistemi var.
‫Ancak bu durumda birkaç farklı Docker ağ sürücüsüne ve bunların ağımızı nasıl değiştirebileceğine
‫ve bize yeni yetenekler kazandırabileceğine bakacağız.
‫Bu gerçekten sadece yüzeyi çiziyor.
‫Aslında bu kurs boyunca çoklu ana bilgisayar özel ağları ve alt arayüzler
‫gibi daha gelişmiş konular hakkında konuşacağımız ağ kavramları var.
‫Ama şimdilik, biraz komut satırı işlerine dalalım.
‫Hızlı bir inceleme
‫olarak, konteyner çalıştırma komutlarımızın -p'sine bakalım... docker konteyner çalıştır.
‫Bir konteyneri ilk çalıştırdığımız zamanı hatırlarsanız, Nginx'imizin 80 numaralı portunu açığa çıkarmak için -p'yi kullanmıştık.
‫Bu, ana bilgisayar bağlantı noktası olan sol tarafı alır ve trafiği bu bağlantı noktasından konteynerin 80 numaralı bağlantı
‫noktasına iletir.
‫Eğer docker container port webhost yaparsak, aslında bunu güzel, kolay bir formatta hangi portların ana bilgisayardan
‫konteynerin içine doğru trafiği yönlendirdiğini gösterir.
‫Konteynerin IP adresi hakkında konuşmadık.
‫Bu yüzden konteynerin ana bilgisayarla aynı IP'yi kullandığını varsayabilirsiniz. Ancak varsayılan olarak bu doğru
‫değildir.
‫Bu konteynerin Docker IP'sini inceleyerek kolayca alabiliriz ve format komutunu ya da seçeneğini
‫kullanacağız, aslında gelen şeylerin nasıl filtreleneceğine dair oldukça özel bir formatı olduğunu fark
‫edeceksiniz.
‫Metin çıktınızı filtrelemek için daha önce kullandığımız grep komutunu her zaman kullanabilirsiniz,
‫ancak biçim, --format, aslında biraz daha temiz ve tutarlıdır. İki küme parantezi yaparsınız ve ardından yapılandırma
‫dosyasının biçimini bilmeye alıştığımızda, NetworkSettings. IP Adresi, bakmak istediğimiz
‫JSON çıktısının gerçek düğümüdür.
‫Ve sonra webhost. Demek ki doğru yazmamışım.
‫I P A d.
‫Ve beklediğim bu değildi.
‫Yerel ağımdaki Mac'lerimi bildiğim için ana bilgisayarımın IP'sini kullanacak olsaydım ve
‫Mac'imde bir ifconfig yaparsam, IP adresinin ev ağımda veya 1 9 2 1 6 8 Alt Ağında olduğunu bilirdim.
‫Aynı şebeke olmamaları ilginç.
‫Neden peki?
‫Bakalım çizersem daha anlamlı olacak mı?
‫Ana işletim sistemim ağıma bağlıysa... Bu benim ağım. fiziksel ağ. Bu da ana makinemdeki Ethernet
‫arayüzüdür, benim durumumda bu benim Mac'imdir.
‫Orada birkaç şey yapan küçük bir güvenlik duvarı var. Ağdan gelen tüm trafiği engeller, böylece varsayılan olarak
‫her şey engellenmiş olur. Ben buna güvenlik duvarı derdim. Konteynerlerimden gelen
‫tüm trafik varsayılan olarak NAT'lanacaktır.
‫Bir ağdaki oldukça yaygın bir uç güvenlik duvarı gibi davranıyor.
‫Ancak sanal ağ kavramı vardır ve varsayılan olarak bridge ya
‫da docker0 adında bir ağ görürsünüz.
‫Yeni bir konteyner başlattığınızda, buna C1 diyeceğiz, bu konteyner bu ağa, bu sanal ağa bağlanır ve bu sanal
‫ağ otomatik olarak ana bilgisayarınızdaki Ethernet arayüzünüze bağlanır, böylece dışarı çıkabilir.
‫Bizim durumumuzda, Nginx'i yeni başlattığımızda, ona -p 80:80 verdik. Bu, Mac'imdeki Ethernet arayüzümde 80 numaralı bağlantı
‫noktasını açmasını ve bu sanal ağ üzerinden 80 numaralı bağlantı noktasına gelen her şeyi bu kapsayıcıdaki
‫80 numaralı bağlantı noktasına yönlendirmesini
‫söyledi.
‫Varsayılan olarak, ikinci bir konteyner oluşturduğumda, aynı köprü ağına yerleştirilir.
‫Bu iki konteyner, açıkta kalan bağlantı noktaları üzerinden serbestçe ileri geri konuşabilir.
‫p'yi belirtmediğim sürece, buradaki dahili ağlarıma gelen hiçbir trafik konteynerlerime
‫ulaşmayacak.
‫Aslında daha fazla sanal ağ oluşturabilir ve bunlara istediğim adı verebilirim. Buna net uygulamam diyeceğim,
‫diyelim. Diyelim ki iki konteyneri buraya bağladım. MySQL var.
‫Sonra bir Apache aldım.
‫MySQL'de herhangi
‫bir port açmadım ve -p belirtmedim. Ancak Apache'de -p değerini
‫8080:80 olarak verdim.
‫Bu, sağ tarafta, ana bilgisayarımdaki Ethernet arayüzümde 8080 numaralı bağlantı noktasını dinlemeye başlayacağı
‫anlamına gelir.
‫Trafik 8080 numaralı bağlantı noktasındaki ana bilgisayarıma gelir gelmez, onu oluşturduğum bu yeni
‫sanal ağa ve 80 numaralı bağlantı noktasındaki Apache sunucusuna yönlendirecek.
‫Bu sanal ağın içinde, Apache sunucusu MySQL sunucusuyla kendi dinleme portu üzerinden konuşmakta
‫serbesttir.
‫Docker'daki sanal ağları ve konteynerlerin nereye ait olduğunu düşündüğünüzde, uygulamalarında ilişkili oldukları
‫için farklı konteynerleri birbirlerine nasıl yakın yerleştireceğinizi düşünün.
‫Gördüğünüz gibi, bu iki örnekte, üstte bir konteyner bir ve bir konteyner iki farklı
‫bir şey sıralıyorsa, aşağıdaki bu ağdaki hizmetlerle konuşmayacaklarsa, bunları ayrı sanal
‫ağlarda tutmak mantıklı olacaktır.
‫Eğer birbirleriyle konuşmak zorunda kalsalardı, yayınlanmış bağlantı noktalarından dışarı
‫çıkıp tekrar içeri girmeleri gerekecekti.
‫Bir hatırlatma olarak, ana bilgisayarınızdaki herhangi bir arayüzde, birden fazla konteyner için birden fazla bağlantı noktasını dinleyemezsiniz.
‫Dolayısıyla, ana bilgisayar düzeyinde 80 numaralı bağlantı noktasını dinleyen iki konteynere sahip olamazsınız.
‫Bunu sadece bir kişi yapabilir.
‫Başka bir konteyner başlatmaya çalışırsanız, aslında hata verir ve o bağlantı noktasında
‫zaten başka bir şey olduğunu söyler. Bu bir Docker sınırlaması değildir; bu sadece IP ağının tipik olarak nasıl çalıştığının
‫bir sınırlamasıdır.
‫Bu bölümle ilgili kısa bir özet. Aslında -p kullanarak ana bilgisayarınızdaki bağlantı noktalarının
‫fiziksel ağa açılması da dahil olmak üzere Docker ağ kavramları üzerinde çok zaman harcadık. Docker'ın aklı başında varsayılanlara odaklanma
‫fikri, piller dahil ancak çıkarılabilir olarak adlandırılıyor.
‫Yerel geliştirme ve test için muhtemelen varsayılanlarla idare edebilirsiniz, ancak her şey değiştirilebilir.
‫Ardından, belirli konteynerleriniz için açık olan portlara bakmanın hızlı bir yolu olan
‫konteyner port komutunu öğrendik.
‫Daha sonra sanal ağlarda dolaşan paketleri ve bunların diğer sanal ağlarla nasıl ilişkili olduğunu
‫ve Docker makinenize nasıl girip çıktıklarını inceledik.
‫Dolayısıyla, bir sonraki derste gerçek CLI konularına geçerken bunların hepsi anlamak için gerçekten iyi kavramlardır.