Not: Dosya daha uzun, dikkatlice okuyun veya toplayın

1 Konteyner ve Docker ve sanal makine

Konteyner (konteyner) hafif bir sanallaştırma teknolojisidir, sanal bir makine oluşturmak için donanımı simüle etmesine gerek yoktur. Linux sisteminde, Linux çekirdeği cgroups, namespace (ipc, network, user, pid, mount), capability ve diğer teknolojiler, kapsayıcı dediğimiz işletim ortamını ve kaynak kısıtlamalarını izole etmek için kullanılır. Konteyner teknolojisi uzun zamandır ortaya çıktı. Örneğin, Solaris Bölgeleri ve BSD hapishanesi, Linux olmayan işletim sistemlerindeki konteynerlerdir ve Linux için Linux-Vserver, OpenVZ ve FreeVPS gibi birçok konteyner teknolojisi vardır. Bu teknolojiler olgunlaşmış olsa da, bu çözümler konteyner desteğini henüz genel Linux çekirdeğine entegre etmedi. Genel olarak, Kapsayıcılar Docker ile eşdeğer değildir ve kapsayıcılar sanal makineler değildir .

LXC projesi, bir Linux çekirdek yaması ve bazı kullanıcı alanı araçlarından oluşur.Sanal ortam izolasyonu, kaynak kısıtlaması ve izin kontrolü için kapsayıcıları korumak için bir dizi basitleştirilmiş araç sağlar. LXC, chroot'a biraz benzer, ancak chroot'tan daha fazla izolasyon sağlar.

Docker'ın ilk hedefi, özel bir LXC açık kaynak sistemi yapmaktı ve sonunda yavaş yavaş kendi konteyner çalışma zamanı ortamına dönüştü. Docker, eksiksiz bir sanal işletim ortamı seti sağlamak için Linux çekirdeğinin CGroups, Namespace, UnionFileSystem ve diğer teknolojilere dayalı özel bir konteyner biçiminde paketlenmiştir. Resmi web sitesinde tanıtıldığı üzere Docker'ın son yıllarda konteyner teknolojisi ile eş anlamlı hale geldiğine şüphe yok. Docker, dünyanın önde gelen yazılım konteynerleştirme platformudur . Bu makale önce kısaca Docker'ın temel kavramlarını tanıtacak ve ardından Docker'ın arkasındaki teknolojiyi analiz edecektir. Docker'ı Debian'a yüklemek için, bkz. Docker-ce-installation-in-debian.

2 Docker temelleri

2.1 Docker Motoru

Docker, konteyner adı verilen uygulamaları paketleme ve çalıştırma için yalıtılmış bir ortam sağlar. Docker'ın izolasyon ve güvenlik özellikleri, bir ana bilgisayarda aynı anda birden fazla kapsayıcı çalıştırmanıza olanak tanır ve sanal makine kadar ağır değildir. Konteynerler ana makineye dayanır. Ana bilgisayarın çekirdeği çalışır, hafiftir, ubuntu, debian veya diğer Linux sistemlerini çalıştırıyor olsanız da, kullanılan çekirdek ana bilgisayar çekirdeğidir. Docker, kapsayıcıları yönetmek için araçlar ve platformlar sağlarken, Docker Engine, işlevsel bileşenlerin çoğunu sağlayan bir CS mimarisi uygulamasıdır. Mimari diyagramda gösterildiği gibi, Docker Engine, görüntüleri, kapsayıcıları, ağları ve veri hacimlerini yönetmekten sorumludur.

2.2 Docker mimarisi

Docker'ın daha ayrıntılı mimarisi şekilde gösterilmiştir. CS mimarisi benimsenmiştir. İstemci, docker daemon sürecine RESTFUL API aracılığıyla docker komutları gönderir. Docker daemon süreci, görüntü derlemeyi, kapsayıcıyı başlatma ve durdurma ve dağıtımı, veri hacmi yönetimini vb. Yürütür. Docker daemon iletişimi.

• Docker Daemon: Görüntüleri, kapsayıcıları ve veri hacimlerini yönetmek için kullanılan Docker arka plan işlemi.

• Docker Client: Docker Daemon ile etkileşim için kullanılır.

• Docker Registry: Github'a benzer şekilde Docker görüntülerini depolamak için kullanılır. Public Registry'de Docker Hub ve Docker Cloud bulunur.

• Resimler: Görüntü, kapsayıcılar oluşturmak için kullanılan salt okunur bir şablondur. Yansıtma genellikle ek yazılımın yüklendiği temel bir yansıtmaya dayanır. Örneğin, nginx görüntünüz Debian'a dayalı olabilir ve ardından nginx'i kurabilir ve yapılandırma ekleyebilirsiniz.Docker Hub'dan mevcut bir görüntüyü çekebilir veya Dockerfile aracılığıyla bir görüntüyü kendiniz derleyebilirsiniz.

• Kapsayıcılar: Bir kapsayıcı, bir görüntünün çalıştırılabilir bir örneğidir.Docker istemcisi veya API'si aracılığıyla kapsayıcılar oluşturabilir, başlatabilir, durdurabilir veya silebiliriz. Varsayılan olarak, konteyner ana bilgisayardan ve diğer konteynerlerden izole edilmiştir.Tabii ki, izole edilmiş konteynerin ağını veya depolama yöntemini kontrol edebilirsiniz.

• Hizmetler: Hizmet, docker swarm tarafından tanıtılan ve çoklu ana bilgisayarlar arasındaki kapsayıcı sayısını ölçeklendirmek ve yük dengeleme ve hizmet yönlendirme işlevlerini desteklemek için kullanılabilen bir kavramdır.

2.3 Docker temelindeki teknolojiye genel bakış

Aşağıdaki komutlarla bir debian kapsayıcısı çalıştırın, yerel bir komut satırına ekleyin ve / bin / bash komutunu çalıştırın.

docker run -i -t debian / bin / bash

Bu komutun arkasında ne yapılır?

1. Makinenin bir debian aynası yoksa, yapılandırdığınız kayıt defterinden debian'ın en son sürümünün bir yansımasını çeker, bu da docker pull debian'ı çalıştırmakla aynı etkiye sahiptir.

2. Bir kap oluşturun. Docker create çalıştırma ile aynı.

3. Kabın son katmanı olarak kaba bir okuma-yazma dosya sistemi atayın ve kap kendi dosya sisteminde dosyalar oluşturup değiştirebilir.

4. Docker, kapsayıcı için bir dizi ağ arabirimi oluşturur ve kapsayıcıya bir ip atar. Varsayılan olarak, konteyner harici ağa varsayılan ağ üzerinden bağlanabilir.

5. Docker, konteyneri başlatır ve / bin / bash komutunu çalıştırır. Başlangıçta -i -t parametresi belirtildiğinden, konteyner etkileşimli modda çalıştığı ve yerel terminale eklendiğinden, terminalde komutlar girebilir ve çıktıyı görebiliriz.

6. Konteynerden çıkmak için exit'i çalıştırın, ancak konteyner şu anda silinmez, tekrar çalıştırabilir veya silebiliriz.

Kabın çekirdek sürümünün ana bilgisayarla aynı olduğu görülebilir. Aradaki fark, kabın ana bilgisayar adının bağımsız olması ve varsayılan olarak ana bilgisayar adı olarak kapsayıcı kimliğini kullanmasıdır. Konteyner sürecinin izole edildiğini, ana makine işleminin konteynerde görülemediğini ve PID 1 ile kendi sürecine sahip olduğunu bulmak için ps -ef çalıştırabiliriz. Ek olarak, ağ da izole edilmiştir ve ana bilgisayardan bağımsız bir IP'ye sahiptir. Dosya sistemi de yalıtılır. Konteynırın kendi sistemi ve yazılım dizini vardır Konteynırdaki dosyaları değiştirmek, ana bilgisayarın karşılık gelen dizinindeki dosyaları etkilemez.

root @ stretch: / home / vagrant # uname -r4.9.0-6-amd64 root @ stretch: / home / vagrant # docker run -it --name demo alpine / bin / ash / # uname -r ## Kapsayıcı içinde 4.9.0-6-amd64 / # ps -ef PID KULLANICI ZAMAN KOMUTU 1 kök 0:00 / bin / kül 7 kök 0:00 ps -ef / # ip a 1: lo: < LOOPBACK, UP, LOWER_UP > mtu 65536 qdisc noqueue durumu BİLİNMİYOR qlen 1 bağlantı / geri döngü 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00 inet 127.0.0.1/8 kapsam ana bilgisayarı lo sonsuza kadar valid_lft tercih edilen_lft sonsuza dek6: eth0 @ if7: < YAYIN, MULTICAST, UP, LOWER_UP, M-DOWN > mtu 1500 qdisc noqueue state UP bağlantı / eter 02: 42: ac: 11: 00: 02 brd ff: ff: ff: ff: ff: ff inet 172.17.0.2/16 brd 172.17.255.255 genel eth0 kapsamı sonsuza kadar valid_lft sonsuza kadar tercih edilen_lft

Bu izolasyon mekanizmaları Docker tarafından yeni geliştirilen teknolojiler değil, Linux çekirdeğine ve aşağıdakiler dahil bazı mevcut teknolojilere güvenerek uygulanıyor:

• Linux Ad Alanları (Linux 2.6.24'ten sonra sunulur): Ad alanları, işlem (PID), ağ (NET), bağlama noktası (MNT), UTS, IPC, vb. İzolasyon için kullanılır.

• Linux Kontrol Grupları (CGroups): Bellek, CPU vb. Dahil olmak üzere konteyner tarafından kullanılan kaynakları sınırlamak için kullanılır.

• Birleşik Dosya Sistemleri: UnionFS, harici kullanım için birden fazla dizini tek bir dizinde birleştirir.Üst dizin, okuma-yazma katmanıdır (genellikle yalnızca bir). Aşağıda bir veya daha fazla salt okunur katman olabilir, kapsayıcı ve ayna katmanlı diyagrama bakın. Docker, OverlayFS, AUFS, DeviceMapper ve btrfs gibi ortak dosya sistemlerini destekler.

• Kapsayıcı Biçimi: Docker Engine, Ad Alanlarını, CGroups ve UnionFS'yi bir kapsayıcı biçiminde birleştirir. Varsayılan biçim libcontainer'dır ve BSD Jails veya Solaris Zones kapsayıcı biçimleri desteği daha sonra eklenebilir.

3 Docker teknolojisi

3.1 Ad alanları

Ad alanları, ortam izolasyonu için kullanılır. Linux çekirdeği tarafından desteklenen Ad alanları arasında UTS, IPC, PID, NET, NS, USER ve yeni eklenen CGROUP vb. Yer alır. UTS, CLONE_NEWUTS logosunu kullanarak ana bilgisayar adlarını ve alan adlarını izole etmek için kullanılır ve IPC, süreçler arası iletişim kaynaklarını izole etmek için kullanılır. Mesaj kuyrukları gibi, CLONE_NEWIPC tanımlayıcısını, işlemi izole etmek için PID'yi, ağı izole etmek için NET'i, bağlama noktasını izole etmek için NS'yi ve kullanıcı grubunu izole etmek için KULLANICI'yı kullanın. Varsayılan olarak, klon sistem çağrısı aracılığıyla oluşturulan alt sürecin ad alanı, ana işlemle aynıdır ve izole etmek için klon sistem çağrısındaki bayrak parametresi aracılığıyla izole edilmiş ad alanını ayarlayabilirsiniz, tabii ki, doğrudan paylaşma komutunu kullanmak da daha uygundur. Yeni bir ad alanı oluşturun. Bir işlemi görüntülemek için ad alanı komutları aşağıdaki gibidir:

kök @ streç: / home / vagrant # ls -ls / proc / self / ns / 0 lrwxrwxrwx 1 kök kök 0 Mayıs 1722:04 cgroup- > cgroup: 0 lrwxrwxrwx 1 kök kök 017 Mayıs 22:04 ipc- > ipc: 0 lrwxrwxrwx 1 kök kök 017 Mayıs 22:04 mnt- > mnt: 0 lrwxrwxrwx 1 kök kök 017 Mayıs 22:04 net- > ağ: 0 lrwxrwxrwx 1 kök kök 017 Mayıs 22:04 pid- > pid: 0 lrwxrwxrwx 1 kök kök 017 Mayıs 22:04 kullanıcı- > kullanıcı: 0 lrwxrwxrwx 1 kök kök 0 Mayıs 1722:04 uts- > uts:

PID Ad Alanı

Kapta kendi Pid ad alanı vardır, bu nedenle gördüğümüz şey sadece PID 1 ve onun alt süreçleri olan ilk süreçtir, ancak ana bilgisayardaki diğer işlemler konteynerde görülemez. Genel olarak konuşursak, Linux başladıktan sonra, önce sistem işlem ağacının kök işlemi olan PID 1 ile bir işlem başlatacak ve ardından kök süreç sistem hizmetlerini başlatmak için çocuk süreçler oluşturacaktır. PID ad alanı, yeni ad alanında yeni bir işlem ağacı oluşturmaya izin verir, PID 1 ile kendi işlemine sahip olabilir. PID ad alanının izolasyonu altında, alt süreç ad alanı üst süreç ad alanındaki süreçleri bilemez.Örneğin, ana süreç Docker konteynerinde görülemezken, üst süreç ad alanı alt süreç ad alanındaki tüm işlemleri görebilir. resim gösterdiği gibi:

pid ad alanı diyagramı

Linux çekirdeği PID Ad Alanına katıldıktan sonra, pid yapısı değiştirilir ve yeni eklenen upid yapısı ad alanını ve pid'i izlemek için kullanılır.

## pid yapısını PID Namespace struct pid { atomic_t count; / * referans sayacı * / int nr; / * pid değeri * / struct hlist_node pid_chain; / * karma zinciri * / ... }; ## PID Namespace struct upid eklendikten sonraki pid yapısı { int nr; / * struct pid'den taşındı * / struct pid_namespace * ns; struct hlist_node pid_chain; / * struct pid'den taşındı * /}; struct pid { ... int level; / * upids sayısı * / struct upid numaraları;};

Paylaşımı kaldırma yoluyla PID ad alanını test edebilirsiniz ve yeni bash sürecinin pid ad alanının ana sürecinkinden farklı olduğunu ve pid'inin 1 olduğunu görebilirsiniz.

root @ stretch: / home / vagrant # unshare --fork --pid bash kök @ streç: / home / vagrant # echo $$ 1 kök @ streç: / home / vagrant # ls -ls / proc / self / ns / 0 lrwxrwxrwx 1 kök kök 0 Mayıs 1915:24 cgroup- > cgroup: 0 lrwxrwxrwx 1 kök kök 0 Mayıs 1915:24 ipc- > ipc: 0 lrwxrwxrwx 1 kök kök 0 Mayıs 1915:24 mnt- > mnt: 0 lrwxrwxrwx 1 kök kök 0 Mayıs 1915:24 net- > ağ: 0 lrwxrwxrwx 1 kök kök 0 Mayıs 1915:24 pid- > pid: 0 lrwxrwxrwx 1 kök kök 0 Mayıs 1915:24 kullanıcı- > kullanıcı: 0 lrwxrwxrwx 1 kök kök 0 Mayıs 1915:24 uts- > uts:

NS Ad Alanı

NS Ad Alanı, bağlama noktalarını izole etmek için kullanılır ve farklı NS Ad Alanlarının bağlama noktaları birbirini etkilemez. Yeni bir Bağlama Ad Alanı oluşturmanın etkisi, chroot'a biraz benzer, ancak chroot'tan daha tamamen izole eder. Bu, Mount yerine NS adının alındığı tarihteki ilk Linux Ad Alanıdır.

NS Ad Alanı'nın orijinal sürümünde, bağlama noktası tamamen yalıtılmıştır. Başlangıç durumunda, alt süreç tarafından görülen bağlama noktası, üst süreç ile aynıdır. Yeni Ad Alanında, alt süreç ana Ad Alanını etkilemeden herhangi bir dizini istediği zaman bağlayabilir / umount edebilir. Bağlama noktasını tamamen izole etmek için NS Ad Alanı kullanmanın orijinal amacı iyidir, ancak bazı durumlarda da rahatsızlık verir.Örneğin, yeni bir disk ekledik. Tamamen izole edilmişse, tüm ad alanlarına monte edilmesi gerekir. Bu nedenle Linux, Yayılma belirtilerek bağlama olaylarının nasıl yayılacağını belirlemek için 2.6.15 sürümüne paylaşılan bir alt ağaç özelliği ekledi. Örneğin, bağlama noktasının bir eş grupta paylaşılmasına izin vermek için MS_SHARED belirtilerek (alt ad alanı ve ana ad alanı aynı gruba aittir), bağlama / umount olayı eş grup üyelerine yayılacaktır. Bağlama noktalarını paylaşmamak ve bağlama olaylarını yaymamak için MS_PRIVATE kullanın. MS_SLAVE ve NS_UNBINDABLE gibi başka seçenekler de vardır. Cat / proc / self / mountinfo görüntüleyerek bağlama noktası bilgilerini görüntüleyebilirsiniz.Eğer yayılma parametresi yoksa MS_PRIVATE seçeneğidir.

Ad alanı bağlama türü diyagramı bağlama

Örneğin, ilk ad alanında iki bağlama noktanız varsa, / mn'yi mount --make-shared / dev / sda1 / mntS aracılığıyla paylaşılan tür olarak ve özel tür olarak mount --make-private / dev / sda1 / mntP set / mntP'yi ayarlayın . Yeni bir ad alanı oluşturmak ve alt dizinleri bağlamak için unshare -m bash kullandığınızda, / mntS altındaki alt dizinlerin mount / umount olaylarının ana ad alanına yayılacağını, ancak / mntP'nin yayılmayacağını görebilirsiniz.

Önceki örnekte Pid ad alanının izolasyonundan sonra, yeni ad alanında ps -ef çalıştırarak host sürecini görebiliriz.Bunun nedeni ps komutunun / proc dosya sisteminden verileri okuması ve dosya sisteminin henüz izole edilmemiş olmasıdır. Bu nedenle, bir Docker konteynerinin işlevini simüle etmek için proc dosya sistemini yeni NS Ad Alanında yeniden bağlamamız gerekir.

root @ stretch: / home / vagrant # unshare --pid --fork --mount-proc bash kök @ streç: / home / vagrant # ps -ef UID PID PPID C STIME TTY TIME CMD kök 10 015:36 puan / 100:00:00 bash kök 21 015:36 puan / 100:00:00 ps -ef

NS ad alanını izole ettikten ve proc'u yeniden bağladıktan sonra, ps komutunun Docker konteynerinde gördüklerimizle tutarlı olan sadece 2 işlemi görebildiği görülebilir.

NET Ad Alanı

Docker konteynerlerinin bir diğer önemli özelliği ağ bağımsızlığıdır (izolasyon teriminin kullanılmamasının nedeni konteyner ağının hala ana bilgisayarın ağı üzerinden iletişim kurması gerektiğidir), Linux'un NET Ad Alanı ve veterinerini kullanarak. Veth'in temel amacı, NET ad alanlarında Linux süreçler arası iletişimine benzer bir teknoloji sağlamaktır, bu nedenle veth her zaman aşağıdaki veth0 ve veth1 gibi çiftler halinde görünür. Farklı NET ad alanlarında bulunurlar ve veth cihazının her iki ucundan alınan veriler diğer uçtan gönderilecektir. veth, farklı ad alanlarının ağ veri iletimini gerçekleştirir.

Docker köprü ağ diyagramı

Docker'da, ana bilgisayarın veth ucu köprüye köprülenecek.Konteynırın veth ucundan gönderilen verileri aldıktan sonra, köprü docker0 aracılığıyla ana ağ kartına eth0 iletilecek ve sonunda eth0 aracılığıyla veri gönderilecektir. Elbette, verileri göndermeden önce, iptables MASQUERADE Kural, yanıt paketinin alınabilmesi için kaynak adresini ana bilgisayar IP'sine değiştirir. Ana ağ kartı tarafından alınan veriler geçecek iptables DNAT Hedef adresini ve bağlantı noktasını, bağlantı noktası numarasına göre kapsayıcının ip ve bağlantı noktasına değiştirin ve ardından yönlendirme kurallarına göre köprü docker0'a gönderin ve son olarak köprü docker0 ile ilgili kapsayıcıya gönderin.

Docker'daki ağ modu, köprü, ana bilgisayar, yer paylaşımı ve diğer modlara bölünmüştür.Varsayılan, şekilde gösterildiği gibi köprü modu ağını kullanmaktır. Ana bilgisayar modu kullanılıyorsa, ana bilgisayar ağı, izolasyon olmaksızın doğrudan kullanılır. Yer paylaşımı ağı, ana bilgisayarlar arası konteyner iletişimini gerçekleştirebilen daha gelişmiş bir moddur.Docker ağının konusu daha sonra ayrı ayrı özetlenecektir.

KULLANICI Ad Alanı

Kullanıcı ad alanı, kullanıcı ve grup bilgilerini izole etmek için kullanılır.Kullanıcılar farklı ad alanlarında aynı UID ve GID'ye sahip olabilir ve birbirlerini etkilemezler. Kullanıcı eşlemesi, üst ad alanının (ana bilgisayar) sıradan kullanıcılarını, alt ad alanının kök kullanıcısının ana ad alanını çalıştırma riskini azaltmak için alt ad alanının (kapsayıcı) kök kullanıcısıyla eşleştirmek gibi üst ve alt ad alanları arasında gerçekleştirilebilir. Kullanıcı ad alanı işlevi çok erken ortaya çıkmış olsa da, bu işlevin mükemmel olma eğiliminde olduğu Linux çekirdek 3.8 sonrasına kadar değildi.

Yeni bir kullanıcı ad alanı oluşturduktan sonraki ilk adım, kullanıcı ve grup arasındaki eşleme ilişkisini kurmaktır. Bu eşleme, / proc / PID / uid_map (gid_map) ayarlanarak elde edilir, format aşağıdaki gibidir, ID-inside-ns, kabın içindeki uid / gid ve ID-dış-ns, kabın dışında eşlenen gerçek uid / gid'dir. gibi 010001 Gerçek uid = 1000'in kapsayıcıdaki uid = 0 ile eşlendiğini ve uzunluğun eşlemenin aralığı olduğunu belirtir.

ID-inside-ns ID-dış-ns uzunluğu

Tüm işlemler eşleme dosyasını istediği gibi değiştiremez ve aşağıdaki koşulların aynı anda karşılanması gerekir:

• Eşleme dosyasını değiştirme işlemi, PID işleminin bulunduğu kullanıcı ad alanına sahip olmalıdır. CAP_SETUID / CAP_SETGID İzinler.

• Eşleştirme dosyasını değiştirme işlemi, PID veya PID'nin ana ad alanı ile aynı kullanıcı ad alanında olmalıdır.

• Eşleme dosyaları uid_map ve gid_map yalnızca bir kez yazılabilir ve yeniden yazılırsa bir hata bildirilir.

Docker1.10'dan sonraki sürümler, docker daemon Başlangıçta ekle --userns-remap = KULLANICI Ad Alanı izolasyonunu elde etmek için. Dockerd'i başlatmak için username = ssj belirledik ve subuid dosyasına baktığımızda, ssj eşlemesinin uid aralığının 165536 ila 165536 + 65536 = 231072 olduğunu ve docker dizini altında ssj'ye karşılık gelen 165536.165536 ayrı bir dizin olduğunu bulabiliriz.

root @ streç: / home / vagrant # cat / etc / subuid serseri: 100000: 65536 ssj: 165536: 65536 root @ stretch: / home / vagrant # ls /var/lib/docker/165536.165536/ oluşturucu / containerd / kapsayıcılar / görüntü / ağ / ...

Çalıştırmak docker görüntüleri -a Komutu bekledikten sonra, kullanıcı ad alanını etkinleştirmeden önce aynanın görünmediğini görebilirsiniz. Şu anda, yalnızca yeni kullanıcı ad alanında oluşturulan docker görüntülerini ve kapsayıcıları görebilirsiniz. Şu anda bir test konteyneri oluşturuyoruz. Konteynır işleminin uid_map'inin ssj olarak ayarlandığını konteynerin dışında görebilirsiniz, böylece konteynerdeki kök kullanıcı ssj kullanıcısı olarak ana bilgisayarla eşleştirilir. Şu anda, / Bin dizinindeki dosyalarda herhangi bir izne sahip olmaması istenir ve bu da güvenliği artırır.

### dockerd başladığında --userns-remap = ssj eklendi root @ stretch: / home / vagrant # docker run -it -v / bin: / host / bin --name demo alpine / bin / ash / # rm / host / bin / hangi rm: '/ ana bilgisayar / bin / hangisini' kaldır? y rm: '/ host / bin / hangi' kaldırılamıyor: İzin reddedildi ### Ana bilgisayar, kapsayıcı işlemi uid_map dosyasını görüntüler root @ stretch: / home / vagrant # CPID = `` ps -ef | grep '/ bin / ash' | awk '{printf $ 2}' ' root @ streç: / home / vagrant # cat / proc / $ CPID / uid_map 016553665536

Diğer Ad Alanı

UTS ad alanı, ana bilgisayar adlarını vb. İzole etmek için kullanılır. Yeni uts ad alanındaki ana bilgisayar adını değiştirmenin, orijinal ad alanının ana bilgisayar adını etkilemediğini görebilirsiniz.

root @ stretch: / home / vagrant # unshare --uts --fork bash kök @ streç: / home / vagrant # hostnamestretch root @ stretch: / home / vagrant # hostname değiştirildi root @ streç: / home / vagrant # hostnamemodified root @ stretch: / home / vagrant # exit kök @ streç: / home / vagrant # hostnamestretch

IPC Ad Alanı, IPC mesaj kuyruklarını vb. İzole etmek için kullanılır. Yeni ve eski ipc isim alanlarının mesaj kuyruklarının birbirini etkilemediği görülebilir.

kök @ streç: / home / vagrant # ipcmk -Q Mesaj sıra kimliği: 0 root @ streç: / home / vagrant # ipcs -q ------ Mesaj Kuyrukları -------- anahtar msqid sahibi, kullanılan bayt iletilerine izin verir 0x26c3371c 0 kök 6440 0 root @ stretch: / home / vagrant # unshare --ipc --fork bash root @ streç: / home / vagrant # ipcs -q ------ Mesaj Kuyrukları -------- anahtar msqid sahibi, kullanılan bayt iletilerine izin verir

CGROUP Ad Alanı, yalnızca Linux4.6'dan sonra desteklenen yeni bir ad alanıdır. Konteyner teknolojisi, çevresel izolasyonu ve kaynak kısıtlamasını sağlamak için ad alanı ve cgroup kullanır, ancak cgroup için izolasyon yoktur. Cgroup ad alanından önce, cgroup dosya sistemi konteynere monte edildikten sonra, tüm global cgroup yapılandırması değiştirilebilir. Cgroup ad alanıyla, ad alanındaki her işlemin kendi cgroup dosya sistemi görünümü vardır, bu da güvenliği artırır ve konteyner geçişini daha kolay hale getirir. Test ettiğim Docker18.03.1-ce sürümünde, konteyner şimdilik cgroup ad alanını kullanmıyor, bu yüzden burada genişletmeyeceğim.

3.2 Gruplar

Linux CGrupları, CPU, bellek, blkio ve ağın sınırlandırılması dahil olmak üzere kaynak sınırlaması için kullanılır. Araç cgroup-bin ( sudo apt-get install cgroup-bin ) Bir CGroup oluşturabilir ve komutları yürütmek için CGroup'a girebilirsiniz.

root @ stretch: / home / vagrant # cgcreate -a vagrant -g cpu: cg1 kök @ streç: / home / vagrant # ls / sys / fs / cgroup / cpu / cg1 / cgroup.clone_children cpu.cfs_period_us cpu.shares cpuacct.stat cpuacct.usage_all cpuacct.usage_percpu_sys cpuacct.usage_sys notify_on_release cgroup.procs cpu.cfs_quota_us cpu.stat cpuacct.usage cpuacct.usage_percpu cpuacct.usage_percpu_user cpuacct.usage_user görevleri

cpu.cfs_period_us ve cpu.cfs_quota_us, gruptaki tüm işlemlerin birim zamanda kullanabileceği cpu süresini sınırlamak için kullanılırlar, burada cfs (Tamamen Adil Zamanlayıcı) tam bir adil zamanlayıcı anlamına gelir. cpu.cfs_period_us zaman periyodudur, varsayılan değer 100000, yani 100 milisaniyedir. Ve cpu.cfs_quota_us, zaman periyodunda kullanılabilen zamandır, varsayılan -1'dir, yani sınır yoktur. cpu.shares, cpu kullanımını sınırlamak için kullanılır, her grup arasındaki kotayı kontrol etmek için kullanılır. Örneğin, cg1 grubunun cpu.shares'i 1024'tür ve cg2 grubunun cpu.shares'i de 1024'tür. Tüm işlemler çalışıyorsa, kotanın% 50'sine kadar kullanabilirler. Cg2 grubundaki süreç göreceli olarak boşta ise, o zaman cg1 grubu neredeyse tüm cpu'yu kullanabilir ve görevler işlem kimliğini grupta depolar. ( Not: Debian8 varsayılan olarak cfs ve bellek cgroup desteğine sahip değildir. Çekirdeği yeniden derlemeniz ve başlangıç parametrelerini değiştirmeniz gerekir.Debian9 zaten varsayılan olarak bunu desteklemektedir. )

Önce varsayılan grupta sonsuz bir döngü programı çalıştıralım loop.py Çünkü varsayılan gruplama /sys/fs/cgroup/cpu/cpu.cfs_period_us ile cfs_quota_us Varsayılan değerdir, dolayısıyla cpu kullanımında herhangi bir kısıtlama yoktur. 1 cpu us'un anında% 100'e yakın olduğu görülebilir.

# loop.py True iken: pass

Cg1 grubunun cfs_quota_us bitini 50000 olarak ayarlayın, bu, gruptaki işlemlerin cpu zamanının% 50'sini kullanacağı anlamına gelir. Cg1 cpu grubuna girmek için cgexec komutunu çalıştırın ve ardından loop.py'yi çalıştırın. CPU'nun% 50 içinde olduğunu görebilirsiniz. Cgexec tarafından oluşturduğumuz işlem kimliğini görevler dosyasında görebilirsiniz.

kök @ streç: / home / vagrant # echo 50000 > /sys/fs/cgroup/cpu/cg1/cpu.cfs_quota_us root @ stretch: / home / vagrant # cgexec -g cpu: cg1 / bin / bash

Docker'da bellek ve CPU kullanımını sınırlamak için, başlangıçta ilgili parametreleri belirtebilirsiniz. Örneğin, cpu kullanım oranını sınırlayın, cpu-period ve cpu-quota parametrelerini ekleyin, yürütülen cpu core'u sınırlayın, --cpuset-cpus parametresini ekleyin. Bellek kullanımını sınırlamak için --memory parametresini ekleyin. Tabii ki görebiliriz / sys / fs / cgroup / cpu / docker / Dizinin altında containerid isimli bir grup var, bu grup altındaki cpu.cfs_period_us ve cpu.cfs_quota_us'un değerleri, konteyneri başlattığımızda belirttiğimiz değerlerdir.

root @ stretch: / home / vagrant # docker run -i -t --cpu-period = 100000 --cpu-quota = 50000 --memory = 512000000 alpine / bin / ash

3.3 Yetenekler

Konteyneri başlatırken sık sık bu tür parametreleri görüyoruz --cap-add = NET_ADMIN Bu, Linux'un yetenek özelliğidir. Daha rafine izin kontrolü elde etmek için yetenek eklendi. Dosyanın SUID bitini ayarlayarak, root olmayan kullanıcının çalıştırılabilir dosyasından sonraki euid'in dosyanın sahip kimliği olacağını biliyorduk.Örneğin, passwd komutu çalıştırıldıktan sonra, root ayrıcalıklarına sahip olur.SUID ayrıcalığına sahip yürütülebilir dosya savunmasız ise, Güvenlik riskleri olacaktır. (Dosyanın yeteneğini görüntüleme komutu filecap -a Ve işlem kapasitesini görüntüleme komutu pscap -a , Pscap ve filecap araçlarının yüklenmesi gerekiyor libcap-ng-utils Bu paket).

Yetenek için, kolay anlaşılması için basit bir örneğe bakabilirsiniz. Örneğin, Debian sistemiyle birlikte gelen ping aracı SUID bit setine sahiptir. Buradaki kopyalama pingi başka bir ping olarak yeniden adlandırılmıştır, başka bir ping'in SUID biti ayarlanmamıştır ve işlem izin hatası verecektir. Burada sadece cap_net_raw iznini eklememiz gerekiyor ve izni SUID bit kadar büyük ayarlamaya gerek yok.

vagrant @ streç: ~ $ ls -ls / bin / ping 60 -rwsr-xr-x 1 kök kök 6124010 Kasım 2016 / bin / ping vagrant @ stretch: ~ $ cp / bin / ping otherping vagrant @ stretch: ~ $ ls -ls başka bir şey 60 -rwxr-xr-x 1 serseri serseri 61240 Mayıs 1910:18 anotherping vagrant @ stretch: ~ $ ./anotherping -c1 yue.uu.163.com ping: soket: İşleme izin verilmiyor vagrant @ stretch: ~ $ sudo setcap cap_net_raw + ep ./anotherping vagrant @ stretch: ~ $ ./anotherping -c1 yue.uu.163.com PING yue.uu.163.com (59.111.137.252) 56 (84) bayt veri. 59.111.137.252'den 64 bayt (59.111.137.252): icmp_seq = 1 ttl = 63 zaman = 53,9 ms --- yue.uu.163.com ping istatistikleri --- 1 paket iletildi, 1 alındı,% 0 paket kaybı, süre 0ms rtt min / ortalama / maks / mdev = 53.919 / 53.919 / 53.919 / 0.000 ms

3.4 Union Dosya Sistemi

UnionFS (Union File System), farklı dizinlerin aynı dizine bağlanmasını destekleyen bir teknolojidir. Docker tarafından desteklenen UnionFS, OverlayFS, AUFS, cihaz eşleştiricisi, vfs ve btrfs vb. İçerir. Mevcut UnionFS sürümünü kontrol edin docker bilgisi İlgili çıktıyı kontrol edin Depolama Docker'ın ilk sürümlerinde AUFS ve aygıt eşleştiriciyi kullanabilirsiniz.Docker'ın yeni sürümü temelde Linux 3.18'den sonra varsayılan olarak OverlayFS kullanır. Burada analiz için OverlayFS kullanıyoruz.

OverlayFS, daha önce kullanılan AUFS'ye benzer, ancak AUFS'den daha basittir ve daha iyi okuma ve yazma performansına sahiptir Docker-ce18.03 sürümünde, varsayılan depolama sürücüsü overlay2'dir. Overlay'in eski sürümü resmi olarak önerilmez. Birleştirilmiş bir görünüm sağlamak için birleştirilmiş bir dizine üst dizin ve alt dizin olmak üzere iki dizini bağlar. Üst dizin okunabilir ve yazılabilir katmandır.Kapsayıcıda yapılan değişiklikler bu dizine yazılır ve aynı dosyaları alt dizinde de gizler. Lowdir salt okunur bir katmandır ve Docker görüntüsü bu katmandadır.

Docker görüntüsüne ve konteyner depolama yapısına bakmadan önce, temel kavramları görmek için OverlayFS'yi çalıştırabilirsiniz. Alt dizin ve üst dizin olmak üzere iki dizin oluşturun ve bunları overlayfs ile birleştirilmiş dizine bağlayın, böylece birleştirilmiş dizindeki hem.txt hem de yalnızca.txt olan tüm dosyaları görebilirsiniz. Üst dizin okunabilir ve yazılabilir, alt dizin ise salt okunurdur. Dosyaları birleştirilmiş dizinde değiştirerek bulabilirsiniz:

• Bir dosya okurken, dosya üst dizinde yoksa, doğrudan alt dizinden okunacaktır.

• Dosyayı değiştirmek, salt okunur olduğu için alt dizindeki dosyayı etkilemez.

• Değiştirilen dosya üst dizinde yoksa, alt dizinden üst dizine kopyalanır ve ardından alt dizindeki dosyaları etkilemeden üst dizindeki dosyayı değiştirir.

• Bir dosyayı silmek için, üst dizindeki ilgili dosyayı c türüne, yani silinen dosyayı gizlemek için karakter aygıt türüne (AUFS bir beyazlatma dosyası oluşturmadan biraz farklı) ayarlamaktır.

root @ stretch: / home / vagrant / overlaytest # tree -a. | - lowerdir | | - both.txt | `- only.txt | - birleştirilmiş | - Upperdir | `- both.txt`-- iş dizini `- work5 dizini, 3 dosya root @ stretch: / home / vagrant / overlaytest # mount -t overlay overlay -olowerdir =. / lowerdir, Upperdir =. / Upperdir, workdir =. / workdir ./mergedroot@stretch:/home/vagrant/overlaytest# tree. | - lowerdir | | - both.txt | `- only.txt | - birleştirilmiş | | - both.txt | `- only.txt | - üst dizin | `- her ikisi.txt `- workdir` - iş 5 dizin, 5 dosya root @ stretch: / home / vagrant / overlaytest # tree -a . | - lowerdir | | - both.txt | `- only.txt | - birleştirilmiş | | - both.txt | `- only.txt | - Upperdir | `- both.txt`-- iş dizini `- work5 dizini, 5 dosya root @ stretch: / home / vagrant / overlaytest # echo "her ikisini de değiştirdi" > birleştirilmiş / both.txt root @ stretch: / home / vagrant / overlaytest # cat upperdir / both.txt ikisini de değiştirdi root @ stretch: / home / vagrant / overlaytest # cat lowerdir / both.txt both.txt dosyasını düşür root @ stretch: / home / vagrant / overlaytest # echo "sadece değiştirildi" > birleştirilmiş / only.txt root @ stretch: / home / vagrant / overlaytest # tree . | - lowerdir | | - both.txt | `- only.txt | - birleştirilmiş | | - both.txt | `- only.txt | - üst dizin | | - both.txt | `- only.txt `- workdir` - iş 5 dizin, 6 dosya root @ stretch: / home / vagrant / overlaytest # cat upperdir / only.txt sadece değiştirildi root @ stretch: / home / vagrant / overlaytest # cat lowerdir / only.txt alt only.txt root @ stretch: / home / vagrant / overlaytest # tree -a . | - lowerdir | | - both.txt | `- only.txt | - birleştirilmiş | | - both.txt | `- only.txt | - Upperdir | | - both.txt | `- only.txt`-- iş dizini `- work5 dizinleri, 6 dosya root @ stretch: / home / vagrant / overlaytest # rm birleştirilmiş / both.txt root @ stretch: / home / vagrant / overlaytest # tree -a . | - lowerdir | | - both.txt | `- only.txt | - birleştirilmiş | `- only.txt | - üst dizin | | - both.txt | `- only.txt `- workdir` - iş root @ stretch: / home / vagrant / overlaytest # ls -ls upperdir / both.txt 0 c --------- 1 kök kök 0, 0 Mayıs 1902:31 üst dizin / both.txt

Docker'a geri dönersek, bir nginx görüntüsü çekiyoruz, üç görüntü katmanı var, overlay2'de her katmana karşılık gelen bir dizin olduğunu görebilirsiniz (bu dizinin adı ve görüntü katmanının adının artık docker1.10'dan sonraki ada karşılık gelmediğini unutmayın. ), diğer l dizini, ayna katmanına yumuşak bir bağlantıdır. En alt katman, temel görüntü debian / alpine, üst katman, nginx tarafından eklenen çalıştırılabilir dosya ve yapılandırma dosyasıdır ve üst katman, nginx günlük dosyasına bağlantı / dev / stdout'tur. Her bir alt dizinin altındaki diff dizini, yansıtma içeriğini depolamak için kullanılır, çalışma dizini dahili olarak OverlayFS tarafından kullanılır, bağlantı dosyası ayna katmanına karşılık gelen kısa adı depolar ve alttaki dosya sonraki katmanın kısa adını depolar.

root @ stretch: / home / vagrant # docker pull nginx Varsayılan etiketi kullanma: en son en son: Kitaplık / nginx'ten çekiliyor f2aa67a397c4: Çekme tamamlandı 3c091c23e29d: Çekme tamamlandı 4a99993b8636: Çekme tamamlandı Özet: sha256: 0fb320e2a1b1620b4905facb3447e3d84ad36da0b2c8aa8fe3a5a81d1187b884 Durum: nginx için daha yeni resim indirildi: en son root @ streç: / home / vagrant # ls -ls / var / lib / docker / overlay2 / toplam 164 drwx ------ 4 kök kök 4096 Mayıs 1904:1709495e5085bced25e8017f558147f82e61b012a8f632a0b6aac363462b1db8b04 drwx ------ 3 kök kök 4096 Mayıs 1904:178af95287a343b26e9c3dd679258773880e7bdbbe914198ba63a8ed1b4c5f55544 drwx ------ 4 kök kök 409619 Mayıs 04:17 f311565fe9436eb8606f846e1f73f38287841773e8d041933a41259fe6f96afe 4 drwx ------ 2 kök kök 409619 Mayıs 04:17 l root @ stretch: / var / lib / docker / overlay2 # ls 09495e5085bced25e8017f558147f82e61b012a8f632a0b6aac363462b1db8b0 / diff bağlantısı daha düşük iş

Örneğimizden, f311'in üç katmanın en üst katmanı olduğunu ve aşağıdaki iki katmanın 0949 ve 8af9 olduğunu görebiliriz.

root @ stretch: / var / lib / docker / overlay2 # cat f311565fe9436eb8606f846e1f73f38287841773e8d041933a41259fe6f96afe / lower l / 7B2WM6DC226TCJU6QHJ4ABKRI6: l / 4FHO2G5SWWRIX44IFDHU62Z7X2 root @ stretch: / var / lib / docker / overlay2 # cat 09495e5085bced25e8017f558147f82e61b012a8f632a0b6aac363462b1db8b0 / lower l / 4FHO2G5SWWRIX44IFDHU62Z7X2 root @ stretch: / var / lib / docker / overlay2 # cat 8af95287a343b26e9c3dd679258773880e7bdbbe914198ba63a8ed1b4c5f5554 / link 4FHO2G5SWWRIX44IFDHU62Z7X2

Bu noktada, bir nginx konteyneri başlatıyoruz ve overlay2 dizininin iki tane daha dizine sahip olduğunu görebiliyoruz.Ekstra olanlar, konteyner katmanı dizini ve salt okunur konteyner init katmanıdır. Kapsayıcı dizini altında birleştirilen, daha önce bahsettiğimiz ortak bağlama dizini ve lowdir alt dizini. Kapsayıcı başlatma katmanı, bu kapsayıcıdaki ortamla ilgili içeriği depolamak için kullanılır. / etc / hosts ve /etc/resolv.conf Dosya, diğer ayna katmanlarının üstünde ve kap katmanının altında bulunur.

root @ stretch: / var / lib / docker / overlay2 # docker run -idt --name nginx nginx 01a873eeba41f00a5a3deb083adf5ed892c55b4680fbc2f1880e282195d3087b root @ stretch: / var / lib / docker / overlay2 # ls -ls 4 drwx ------ 4 kök kök 4096 Mayıs 1904:1709495e5085bced25e8017f558147f82e61b012a8f632a0b6aac363462b1db8b04 drwx ------ 5 kök kök 4096 Mayıs 1909:1111b7579a1f1775ad71fe0f0f45fcb74c241fce319f5125b1b92cb442385065b14 drwx ------ 4 kök kök 4096 Mayıs 1909:1111b7579a1f1775ad71fe0f0f45fcb74c241fce319f5125b1b92cb442385065b1-init 4 drwx ------ 3 kök kök 4096 Mayıs 1904:178af95287a343b26e9c3dd679258773880e7bdbbe914198ba63a8ed1b4c5f55544 drwx ------ 4 kök kök 409619 Mayıs 04:17 f311565fe9436eb8606f846e1f73f38287841773e8d041933a41259fe6f96afe 4 drwx ------ 2 kök kök 409619 Mayıs 09:11 l root @ stretch: / home / vagrant # ls -ls / var / lib / docker / overlay2 / 11b7579a1f1775ad71fe0f0f45fcb74c241fce319f5125b1b92cb442385065b1 / 4 drwxr-xr-x 4 kök kök 409619 Mayıs 09:11 fark 4 -rw-r - r-- 1 kök kök 26 Mayıs 1909:11 bağlantı 4 -rw-r - r-- 1 kök kök 115 Mayıs 1909:11 daha düşük 4 drwxr-xr-x 1 kök kök 409619 Mayıs 09:11 birleştirildi 4 drwx ------ 3 kök kök 409619 Mayıs 09:11 çalışma root @ stretch: / var / lib / docker / overlay2 # ls 11b7579a1f1775ad71fe0f0f45fcb74c241fce319f5125b1b92cb442385065b1 / birleştirilmiş / bin boot dev vb ev lib lib64 media mnt opt proc root run sbin srv sys tmp usr var root @ stretch: / var / lib / docker / overlay2 # ls 11b7579a1f1775ad71fe0f0f45fcb74c241fce319f5125b1b92cb442385065b1 / diff / var çalıştır

Kaptaki dosyayı değiştirirsek, kapsayıcı katmanının birleştirilmiş dizinindeki ilgili dosyaları yansıtır Kap katmanının diff dizini üst dizine eşdeğerdir ve diğer katmanlar alt dizindir. Dosya önceki konteyner katmanı diff dizininde mevcut değilse, dosya diff dizinine kopyalanacak ve değiştirilecektir. Dosyaları okurken, üst dizin dizini bulunamazsa, doğrudan alt yansıtma katmanından okur.

4 özet

Sürümün sürekli güncellenmesiyle birlikte, Docker'ın ayna katmanı depolama dizininin değiştirilmesi, varsayılan UnionFileSystem'in yerini OverlayFS ve yeni Ad Alanı desteği gibi bazı teknik ayrıntıları da değişiyor. Bu makale temel olarak önceki çalışma notlarını ve Docker'daki bazı yeni değişiklikleri özetlemektedir.Daha fazla ayrıntı öğrenmek istiyorsanız, referans materyalleri ve Docker ile ilgili resmi belgeleri kontrol edebilirsiniz.

Şimdiye kadarki en iyi selfie kamerası olan Redmi S2 resmi olarak piyasaya sürüldü: 999 yuan'dan başlayan fiyatlarla

Tek cümlelik bir aşk hikayesi de kalbi bu şekilde delebilir .. "Like a Shadow" filminin tanıtım şarkısı yorum bölümü çekildi!

Öğrencilerin üç alıntı şiirleri! Netizen: Okumadan aşk şiirlerini bile okuyamazsınız!

Bazı küçük ekiplerin otomatikleştirilmiş işletim ve bakımdaki pratik deneyimi

Elasticsearch günlük senaryoları için en iyi uygulamalar

Doğuda "StarCraft" ta transseksüelden sonra yenilmeyen Güney Kore'yi mağlup ederek altın madalya kazandı.

Pekin Üniversitesi bir bütün olarak Xiongan Yeni Bölgesi'ne taşınacak mı? Müdür Lin Jianhua cevap verdi

"Mutlu Kamp" ın başrolünü üstlendiği "Rüzgarda Yağmurdan Oluşan Bir Bulut", herkes zekayla savaşır ve cesurca "Gizemli Gece" oynar

Görünüşe göre NIKE Presto hala böyle görünebilir mi? ! Ancak yukarıdaki modelin böyle bir hikayesi olduğu ortaya çıkıyor ...

E-sigara nasıl seçilir? Neden bu EVOVE e-sigara deneyimine bir göz atmıyorsunuz?

Kapsayıcı günlükleri için teknik uygulama

Süperstar düştü! Onun bu 8 kelimesi hatırlamaya değer!