Ubuntu16/CentOS7/RedHat7 Customize The docker0 Bridge ile Kurulum

Şimdiki makalemizde özelleştirilmiş network ile Docker kurulumunu ele alacağız. Öncesinde neden böyle birşeye ihtiyaç duyabileceğimizden bahsedeyim, hemde başımdan geçen durumu da anlatmış olurum.

Bildiğiniz gibi Docker kurulumda docker0 bridge‘inin default ip range‘i olarak 172.17.0.1/16‘yı vererek kurulum gerçekleştirmektedir. Bu durumda sizin bağlantı sağladığınız lokal ağ tercihini hali hazırda 172 li subnet ise kurulum aşamasında Docker Run olduğunda bağlantınız koparacak ve bir daha uzaktan bağlantı sağlayamayacaksınız. Benim başımada böyle bir durum geldi, lokal ağım 172 li /24 subnet’indeydi ve /16 lı subnet benim subnet’i yuttuğundan, çakışma gerçekleşti ve bağlantımı kopardı. Bu durumda konsol aracılığı ile sizin kendi belirlediğiniz subnet ile kurulum yapmanız gerekli yada subnet’i editlemelisiniz. Ben aşağıdaki göstereceğim yöntemle “systemd” kullanarak istediğim ortamı ayağa kaldırdım. Şimdi sırasıyla Ubuntu16’da ve Centos7/RedHat7 de bunu nasıl yapabiliriz, buna değinelim.

*Ubuntu16 da customize subnet ile Docker kurulumu

İlk önce “etc/systemd/system/” altına “docker.service.d” dizinini, “mkdir” komutunu kullanarak oluşturalım.

> sudo mkdir /etc/systemd/system/docker.service.d

İkinci olarak “/etc/systemd/system/docker.service.d/” altına “docker.conf” dizinini “touch” komutunu kullanarak oluşturalım.

> sudo touch /etc/systemd/system/docker.service.d/docker.conf

Ardından “docker.conf” dosyasının içine bir editör aracılığı(vim) ile aşağıdaki gibi doldurup, kaydedin.

docker.conf
[Service]

ExecStart=

ExecStart=/usr/bin/dockerd -H fd:// --bip=10.10.100.1/24

 

Gerekli systemd ayarlamalarını yaptık ve şimdi normal akışında kurulumu yaparak işlemleri tamamlayacağız.

Önce, resmi Docker repository için GPG anahtarını sisteme ekleyelim.

> curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add –

Ardında Docker repo’sunu ekleyelim.

> sudo add-apt-repository “deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable”

Şimdi repolarımızı güncelleyelim.

> sudo apt-get update

Ve şimdi aşağıdaki komutla Docker’ı kuralım.

> sudo apt-get install -y docker-ce

Ardından gerekli kontrolleri sırasıyla yapıp, işlemlerimizi teyit edelim.

*CentOS7/RedHat7 da customize subnet ile Docker kurulumu

Gene “systemd” yi kullanarak işlemleri gerçekleştireceğiz.

İlk önce “etc/systemd/system/” altına “docker.service.d” dizinini, “mkdir” komutunu kullanarak oluşturalım.

> mkdir /etc/systemd/system/docker.service.d

İkinci olarak “/etc/systemd/system/docker.service.d/” altına “docker.conf” dizinini “touch” komutunu kullanarak oluşturalım.

> touch /etc/systemd/system/docker.service.d/docker.conf

Ardından “docker.conf” dosyasının içine bir editör aracılığı(vim) ile aşağıdaki gibi doldurup, kaydedin.

docker.conf
[Service]

ExecStart=

ExecStart=/usr/bin/dockerd --bip=10.10.100.1/24

Gerekli systemd ayarlamalarını yaptık ve şimdi normal akışında kurulumu yaparak işlemleri tamamlayacağız.

Docker’ı kurmadan önce aşağıdaki komutla gerekli paketleri indirip, kuralım.

> yum install yum-utils device-mapper-persistent-data lvm2 -y

Ardında Docker repo’sunu ekleyelim.

> yum-config-manager –add-repo https://download.docker.com/linux/centos/docker-ce.repo

Şimdi aşağıdaki komutla Docker’ı kuralım.

> yum install docker-ce –y

Docker kurulduktan sonra sevisi çalıştırmak ve enable etmek lazım. Aşağıdaki komut ile yapabilirsiniz.

> systemctl enable docker.service

> systemctl start docker.service

Status’ ile son durumu kontrol edelim.

> systemctl status docker.service

Ardından gerekli kontrolleri sırasıyla yapıp, işlemlerimizi teyit edelim.

Bu arada servisi daha önceden kurduysanız “systemd” yapılandırmasını yaptıktan sonra aşağıdaki komutları çalıştırdığınızda sizin belirlediğiniz subnet overwrite olacak.

> systemctl daemon-reload

> systemctl restart docker.service

warning: remote host identification has changed

Ssh protokolü ile uzaktaki bir makinanıza bağlanmaya çalıştığınızda “warning: remote host identification has changed” uyarısını alıyorsanız muhtemelen ayını ip ile başka bir kurulum gerçekleştirmiş olabilirsiniz. Bu durumda ssh in çalışma prensibi doğrultusunda daha önceden ilgili ip için atanan public key numarası doğal olarak değiştiğinden ve sizin(yani ilgili kullanıcının) /.ssh/known_hosts dosyasında bulunan eski identification eşleşmediğinden bu hatayı almanız gayet doğal. Uyarıda genelde çalıştırmanız gereken komutu söyler, yukarıdaki resimde olduğu gibi fakat aşağıdaki screenshottan anlaşılacağı üzere ilgili komutu bildirmeye bilir de. Bu durumda da belirteceğimiz komutu yürütmeniz çözüm olacaktır.

> ssh-keygen -f “/home/fatihaslan/.ssh/known_hosts” -R 192.168.1.100

systemd-analyze blame Komutunu Keşfedelim – Redhat7, CentOS7, Ubuntu16

Bu makalemde çok hoş bir şekilde deneyimsellediğim bir durum ve komuttan bahsedeceğim. Bir komut nedir.? Diyebilirsiniz. Fakat sistem yöneticileri için özellikle de Linux Admin’leri için bir komut bile yeri geldi mi can kurtarıcı bir duruma dönüşebilir. Uzun süredir bakmadığınız yada başkası tarafından kurulup çalışan, sonradan yönetimi devraldığınız bir sunucuda yaşayabileceğiniz bir durum olabilir. Bende böyle bir durum oluştu ve RedHat Enterprise Linux 7 de açılışta bir problem yaşadım. Neydi bu problem.?

Sunucu RHEL 7 ama GUI de kurulu ve sunucu açılışta çok yavaş açılıyordu. User’lar, login ekranı dakikalar sonra geldi. Bir sorun olduğu belliydi ama onun dışında herhangi bir sorun yok sunucu canavar gibi çalışıyordu. Neyse tam bu noktada nedir problem.? Nasıl çözerim.? derken, bir komut keşfettim. Bu komut “system-analyze blame”. Bu komut kısaca analyze system boot-up performance, sistemin boot olmasında açılan servis ve uygulamaların başlangıç performansı olarak time bazında size yansıtacaktır ve sizde oradan alacağınız ip ucuyla sorunu giderebilirsiniz ki ben bu şekilde, belki de uzun süre uğraştıracak bir sorunu saniyeler içinde hallettim.

Bu komutun üzerinde durmamım bir diğer sebebi ise RedHat 7 de çalışmasıdır. Yani altı sürümlerde bu komut mevcut değil. Bu da tabi RHEL 7’nin kullanış seviyesini yansıtmaktadır. Tabi aynı şekilde CentOS 7 ve Ubuntu 16 ve üzerinde de bu komut mevcut.

Şimdi aşağıdaki screenshot’larla durumu daha detaylı inceleyelim.

Sistemi bir kere açmayı başarınca system-analyze blame komutunu çalıştırdım ve en geç açılan nfs.mount servisinin olduğunu gördüm.

> system-analyze blame

Ardından “/etc/fstab” dosyasını incelemeye aldım. Zaten açılışta bu problemin olması ve sistem boot olduğundan fstab dosyasını okuması şüpheyi kendi üzerine çekmeye yetiyordu. Ve en son satırda bir makinadan mount işleminin olduğunu gördüm. Tabi ki sistem boot olduğunda fstab dosyasını okuyup mount ediyor ve o hedefteki ip’li makinayı bulamadığı için açılış problemi olduğunu netti.

İnsert modda bu satırın başına # işareti koyup, kaydedip çıktım. Böylelikle o satırı yorum satırı olarak algılamasını sağladık. Ve sistemi reboot ettiğimde problemin çözüldüğünü gözlemledim. İyi çalışmalar.

NFS(Network File System) nedir.? NFS Server ve Kullanıcı Yapılandırması

Sun Microsystems tarafından geliştirilen Unix/Linux dosya paylaşım servisi olup, Linux sistemler arasında dosya paylaşamını sağlayan ve stabil çalışan bir teknolojidir. Tabi ki açık kaynak kodludur deyip bu kadar teorik bilgide noktalasak yeter herhalde.

Hemen yapılandırma ve kullanımına girmeliyiz. Ortamda Sunucu ve İstemci modeli ile çalışacağız. Yani Hem Server tarafında yapmamız gerekenler var hemde bunu Client ların kullanabilmesi için yapmamamız gerekenler var. Bunun için sanal ortamımı oluşturdum aşağıdaki gibi.

NFS Server’ımın ip bilgisi aşağıdaki gibidir.

NFS Client için de ip bilgisi aşağıdaki gibidir.

Herşeyden evvel genelde sunucular minimal kurulum yapıldığından NFS paketlerini kurmak gerek.

NOT : Bu paketleri hem sunucuda hem istemcide kurmalısınız. Aşağıdaki komut ile bu işlemi yapabilirsiniz.

> yum install nfs-utils nfs-utils-lib

Daha sonra servisin durumuna aşağıdaki komut ile bakın ve servisin hem çalışmadığını hemde disabled olduğunu görün.

> systemctl status nfs-server.service

Şimdi servisi alttaki komutla çalıştırın.

> systemctl start nfs-server.service

Daha sonra enabled durumuna çekin.

> systemctl enable nfs-server.service

Şimdi son duruma bakalım ve bu kısımın sağlıklı bir şekilde tamamlandığını görelim.

 

* Server – Sunucu tarafı

Şimdi sunucuda yapılandırmaya başlayalım. Tabi burada sizin ortamınıza göre planlama yapmanız gerekiyor. Yani NFS için ayıracağınız alanı belirleyip bunun için hususi ayrı bir disk, storage de kullanabilirsiniz ki bu yöntem her zaman daha sağlıklıdır. Ben sunucu tarafında belirlediğim disk alanına MePaylasNFS diye bir dizin oluşturuyorum.

Mkdir komut ile MePaylasNFS klasörünü oluşturuyorum. Ardından cd komutu ile içine girip test için dosya ve klasörler oluşturuyorum.

> mkdir MePaylasNFS

Paylaşım yapılandırmayı “/etc/exports” config dosyası yardımıyla gerçekleştireceğiz. Herhangi bir editör yardımıyla buraya girip oluşturduğumuz MePaylasNFS klasörünü herkes için(“*” işareti herkes bağlanıp kullanabilir manasına gelir, eğer belirli makinalar için yapacaksanız “*” yerine makinanın ip’ni girmelisiniz). Ardından nfs servisini yeniden başlatın.

> systemctl restart nfs-server.service

exportfs” komutu yardımıyla sunucudaki tüm paylaşımlarımızı listeleyebiliriz.

> exportfs

Birde “showmount -e localhost” komutunu çalıştırıp, burdan da paylaşımları gözlemleyelim.

 

* Client – Kullanıcı tarafı

Şimdi client tarafında yapılandırmaya girişelim. Paylaşımı kullanacak tarafta paylaşılan alanı mount edeceğiz. Mount için bir hedef yani klasör oluşturalım. Ben NFSKullan adında bir klasör oluşturuyorum.

> mkdir NFSKullan

Şimdi aşağıdaki gibi sunucunun ip(192.168.2.250) bigisiyle mount edelim.

> mount 192.168.2.250:/ MePaylasNFS /NFSKullan

Direk mount komutu ile durumu gözlemleyebilirsiniz. Ayrıca NFS servisinin de versiyon 4 olduğunu görün.

> mount

df -h komutu ile gözlemleyelim.

> df -h

Paylaşım noktasını ls -l ile listeleyelim, verileri kullanabildiğimizi gözlemleyelim. Bu bilgiler aslında sunucuda.

> ls -l /NFSKullan

Son kontrol amacı ile “showmount -e 192.168.2.250(Server ip bilgisi)” komutunu çalıştırıp değişimi gözlemleyelim.

> showmount –e 192.168.2.250

Herşey bittimi.? Tabi ki HAYIR.! Çünkü bu kullanıcı makinası reboot olduğunda mount bilgisi kaybolacak ve NFS paylaşımını kullanamayacak. Bunu sabit kılmak ve sürekli kullanıcı makinası reboot olsa da kullanabilir yapmak için/etc/fstab” dosyasına mount noktasını yazacağız. Herhangi bir editör yardımıyla bu yapılandırma dosyasına girelim ve aşağıdaki şekilde yapılandıralım(boşluklar tab tuşuyla oluşturuldu), kaydedip çıkalım.

# 192.168.2.250:/MePaylasNFS       /NFSKullan       nfs4       rw,sync       0 0

Hayırlı olsun.