jtcjtcc / dockeraaaaaa

Kablosuzkedi Kanalındaki Docker Serisi için Hazırlanmış Dokümantasyondur

Bu doküman kablosuzkedi Youtube Kanalı için hazırlanmıştır. Bu içerikte bulunan konular ve daha fazlası için video serisine de göz atabilirsiniz.

Docker Nedir Nasıl Kullanılır? | Part #1 | Image Nedir? Container Nedir? Docker Komutları

Docker Network Türleri | Dockerfile ile Image Nasıl Üretilir | Part #2

Docker Compose ile Servis Yönetimi Part #3 | Twitter, Asana, Wordpress, MongoDB NodeJS Uygulamaları

Linux'a Docker Kurulumu | Production | Nginx | Reverse Proxy ile 2 Domain 1 Host Yönetimi | Part #4

Klasik Senaryolar

Klasik Yöntem ile Yazılımcılar geliştirmiş oldukları yazılımı Production ortamına almak için DevOps ekibiyle görüşür ve dosyaları iletir. Bu dosyalar yazılım ve environment'in nasıl ayarlanacağına ait bilgileri de içerir. Devops yazılımı kendisi yazmadığı için doğal olarak bunun sıkıntısını çok fazla yaşarlar ve uygulamayı başarılı bir şekilde aynı development ve test envlerinde olduğu gibi çalıştırmak için uğraşırlar.

Docker ile Yazılımcılar bu uygulamalarını Docker Image haline getirip DevOps takımıyla paylaşırlar ve Devops'un yapacağı tek işlem bu image'i;

docker run imageName

ile container haline getirmek olacaktır. Bu da tamı tamına yazılımcının istediği envye sahip tüm ayarlar yapılmış halde uygulamanın çalışabileceği en iyi ortamı kurmak demektir.

Neden Docker'a İhtiyacımız var?

Tüm bu uygulamalar OS ile uyumlu olacak şekilde çalışır. Bizim bu uyumu OS sürümüne göre her bir servis için ayrı ayrı sağlamamız gerekir.

İşte burada problem ortaya çıkmaya başlıyor.

• Peki gerçekten bu uyum her bir servis için geçerli olabilir mi? Bazen mümkün bazen mümkün olmayabilir.
• Zamanla bu servisler güncellenir ya da servisler içerisinde kullanılan bağımlılıklar kullanmış olduğumuz servisler ile uyumlu olmayabilir.Tabi ki yapabileceğimiz en mantıklı çözüm bu servis için uygun bir işletim sistemini bulmak olacaktır. Peki bulacağımız uygun işletim sistemi diğer servisler için uyumlu olacak mıdır?
• Diğer problem ise bu bağımlılıkların birbirlerini etkilemesi.
• Uygulamanın çalışacağı ortamı, sürece dahil olan tüm ekibin sahip olması beklenemez (Development / Test / Production)

Doğal olarak bu şekilde uygulama geliştirmek bunları yönetmek ve sunucular arasında taşımak oldukça zor bir durumdur.

Neye İhtiyacımız Var?

Tam olarak burada bu servisler arasında iletişimi en iyi şekilde yapacak ve birbirlerinden etkilenmeden bunu başarılı bir şekilde yönetebilecek bir araca ihtiyacımız oluyor.

Burada Docker devreye giriyor. Docker'ın yapmış olduğu işlem her bir servisi aynı işletim sistemi üzerinde kendilerine ait bir dünyada çalışmasını sağlayarak kendilerine ait kütüphaneleri ve bağımlılıkları olmasını sağlıyor.(Elbette çok daha fazlasını da bize sağlıyor fakat şimdilik burada kalalım :))

Böylece herhangi bir developer kendi uygulamasının çalışması için gereken Docker konfigürasyon dosyasını oluşturduktan sonra, bu servisin ayağa kalması/çalışması için docker run demesi yetiyor. Bu sadece geliştirici için değil bu sürece dahil olan herkes için geçerli oluyor. Tek komut aynı environment (ortam).

Docker bunu yaparken container yapısından yararlanıyor. Peki Container Nedir?

Container Nedir?

Container, kendilerine ait prosesleri, servisleri, networkleri bulunan tamamen izole edilmiş ortamlardır (environment). Tıpkı VM gibi fakat her bir VM kendisine ait bir OS barındırırken her bir Container OS kernel'i paylaşmaktadır.

Ne Güzel Bir Teknoloji!

Bu ifade size oldukça devrimsel ve Docker ile yeni ortaya atılmış bir fikir gibi gelebilir fakat tam olarak öyle değil :) Container yaklaşık 10 yıldan beri kullanılmaktadır. Container'ların bir çok türü bulunmaktadır. Linux tarafında bunlardan bazıları;

• LXC
• LXD
• LXCFS

docker Linux'de bu container türlerinden LXC container türünü kullanmaktadır. Windows'da ise bu iş için kullanılan adı Windows Server Container Support*'dur. İşte bu container'ları yönetmek oldukça zor ve low level bir işlem olduğundan dolayı docker bize bu işleri kolaylaştırmak için high level birçok araç sunuyor. Böylece kullanıcılar container'ları istedikleri gibi kolaylıkla yönetebiliyor.

Docker Nasıl Çalışıyor?

Docker'ın nasıl çalıştığını anlamak istiyorsanız ilk olarak İşletim sisteminin nasıl çalıştığını biraz anlamanız gerekmektedir. Örnek vermek gerekirse Linux İşletim sistemini ele alalım.

Tüm Linux tabanlı işletim sistemlerine bakacak olursanız bu işleletim sistemleri temelde 2 farklı bileşeni içerisinde barındırır.

• OS Kernel
• Bir çok yazılım seti

OS Kernel donanum ile etikleşimden sorumludur. OS Kernel aynı kalır. Fakat üzerindeki yazılım setleri işletim sistemleri arasındaki farkları belirler. Bundan dolayı sürekli bir Linux dağıtımı gibi cümleler duyarsınız. Bu yazılım setleri bir çok farklılıklar içerebilir. Grafik arayüzleri, sürücüler, geliştiriciler için komut setleri ve çok daha fazlası.

Yukarıda söylediğim gibi Docker Container'ları ortak OS Kernel kullanır. Peki bu gerçekten ne anlama gelir?

Diyelim ki siz Linux üzerine Docker yüklediniz. Docker aynı kernele sahip herhangi bir linux sürümünü container olarak çalıştırabilir. Bu durumda kernel ortak olarak paylaşıldığında yazılım seti container içerisinde kullandığımız linux sürümünden gelir.

Eğer siz Linux OS üzerine yüklemiş olduğunuz bir Docker ile Windows işletim sistemine sahip bir contianer çalıştırmak isterseniz bunu yapamazsınız. Çünkü container'ların ortak bir kernel paylaştığını söylemiştik. Doğal olarak Linux Kerneli ile Windows'un kerneli farklı olduğu için bu container'ı çalıştıramazsınız.

O zaman Windows üzerine Docker yükleyebilirim ve Docker üzerinden Windows base container'lar çalıştırabilirim diye düşünebilirsiniz. Fakat bu da mümkün değil.

Buradaki durum sizi aldatmasın çünkü windows işletim sistemine Docker yükleyebiliyorsunuz ve linux base bir container çalıştırmış da olabilirsiniz fakat burada çok önemli bir nokta Docker Host tarafından bizim bilmemize ihtiyacımız olmadan yapılıyor.

Siz Windows üzerine docker yüklediğinizde Docker kendisi Linux bir VM üzerinden tüm yönetimini yapmaktadır. Doğal olarak siz yine Linux üzerinde Docker host çalıştırmış oluyorsunuz. Doğal olarak ortak kernel paylaşımı yine linux üzerinden olmaktadır. Bundan dolayı Windows işletim sistemi üzerinden yönettiğiniz docker host ile yine windows base bir container çalıştıramazsınız.

Bunu yapabilmek için Windows Server üzerine kurmuş olduğunuz Docker üzerinden windows base bir container çalıştırabilirsiniz.

VM vs Container

• VM Hypervisor üzerinde her bir VM container'ını yönetir. Fakat bu her bir VM kendine ait bir işletim sistemine sahiptir.

• Docker container'ları ise sadece bizim application dosyalarımız, kütüphaneler ve bağımlılıkları içerir. Sadece tek bir işletim sistemi olduğu için bu utilization adına oldukça performanslı bir çözümdür.

• VM içerisinde İşletim sistemi barındırdığı için doğal olarak Docker'a göre daha fazla alan kaplar.

• Uygulamayı ayağa kaldırmak istediğinizde VM OS içerdiğinden ilk olarak OS'in açılmasını beklemek gerekir. Docker'da ise direk uygulamanın gereksinimleri doğrultusunda ayağa kalkar. Yani çok daha hızlı boot süresine sahiptir.

• Sanal Makineler kendilerine ait OS'e sahip olduğu için ve bunlar arasındaki iletişim Hypervisor tarafından yapıldığı için doğal olarak bir sunucu üzerinde farklı işletim sistemlerine sahip VM'ler üretebilirsiniz. Fakat docker aynı OS üzerinde çalışan yapılar olduğu için bu mümkün değildir.

İkisinin de kendisine göre avantaj ve dezavantajları bulunmaktadır. Fakat genel olarak Docker bu konuda bayağı bir önde.

Aynı zamanda bu iki teknolojiyi beraber kullanarak da oldukça güçlü alt yapılar inşaa edebiliriz. 1 hypervisor üzerinden farklı VM'ler ve onların içerisinde Docker üzerinden yönetilen container'lar şeklinde.

Nasıl Yapılır?

Nasıl yapılacağını öğrenmek için ilk olarak Image konusunun ne olduğunu bir açıklağa kavuşturmamız gerekiyor.

Image Nedir?

• İçerisinde bir çok farklı yapıyı barındıran yapılardır. (OS, Application, ve daha fazlası)
• Template, plan, package
• Akılda kalması için;
  • Form tabanlı uygulamaların (WinForms vs) projesi image olarak düşünülebilir
  • Eskilere gidecek olursak Ahead Nero ile ne image’ler ürettik :)
• Peki bu image’ler nerede?
• Docker Hub (Docker’un public ve private olarak bize sunduğu resmî repository hesabı)

Container Nedir?

• Image’i çalıştırdığımızda elde ettiğimiz proses olarak düşünülebilir
• Akılda kalması için;
  • Form tabanlı uygulamanın, çalıştırılmış hali olarak düşünülebilir
    • Proje > exe

Docker'ı bilgisayarımıza kurduk. Peki Docker ile container'ları nasıl kullanacağız? Bunun için ilk olarak ihtiyacımız container'ımızın base yani temelini oluşturacak bir image elde etmek. Peki bu image'ı nereden alacağız?

Bir çok şirket kendisine ait bir çok uygulamayı containerized edip DockerHub üzerinden bunu public ya da private olarak sunuyor. Siz bunlardan birini kullanmak istediğinizde bunun sadece

docker run imageName

şeklinde yazarak kendi ortamınıza bir kopyasını (instance) alabiliyorsunuz. Mesela;

docker run nodejs
docker run redis
docker mongodb

gibi.. farklı farklı instance'ları kendi ortamınıza rahatlıkla çekebilirsiniz.

Container vs Image

Docker Image sizin projeniz gibi düşünebilirsiniz. Projelerinizin dosyaları tüm ayarlar yani bir paket, template, plan gibi.

Docker Container ise bu template'in çalıştırılmış hali bir instance'ı gibi. Bir Docker Image'den birden fazla Docker Container çalıştırabilirsiniz.

Ayrıca siz de kendinize ait image dosyalarınızı üretebilir ve bunu Docker Hub Repository'e gönderebilirsiniz. Böylece Public ya da Private olarak diğer geliştiriciler bundan yararlanabilirler.

## Docker Sürümleri

• Comminity Edition
  • Ücretsiz sürüm ve belirli ücretsiz yönetim sistemleri mevcut. Community edition linux, mac, windows, cloud olarak erişebiliyor. Eğer Mac ve Windows sahibiyseniz bunun için Docker Desktop yüklemeniz ya da Virtualization özelliği bulunan Linux VM yüklemeniz gerekebilir.
• Enterprise Edition
  • Ücretli

Docker Komutları

docker run

run komutu bir image'ı çalıştırmayı sağlar. Örneğin;

docker run node

dediğimizde node isimli container eğer bizim docker host'umuzda varsa çalıştırılır. Eğer yoksa Docker Hub Repository üzerinden bulunur indirilir ve çalıştırılır. Bir sonraki docker run node komutuyla beraber docker host üzerinden çalışmaya başlar.

docker ps

ps komutu çalışan tüm containerların listesini bilgileriyle beraber döker.

her bir container random isim ve id bilgisi alır. Eğer çalışan ya da çalışmayan tüm container'ların listesini görmek istersek. Bu durumda -a parametresini göndermemiz gerekir.

docker ps -a

aynı işlemi

docker container ls

docker container ls -a

ile de görebiliriz.

bu bize çalışan ve daha önce çalışmış ama durmuş tüm container'ların listesini verecektir.

docker stop containerName|containerID

çalışan bir container'ı durdurmak için kullanılır containerName ya da containerID bilgisini vermemiz yeterlidir.

Eğer çalışmayan docker container'larının boşuna yer kaplamasını istemiyorsak;

docker rm containerName|containerID

kullanabiliriz. Bu durumda sildiğimiz container'ları docker ps -a yaptığımızda listede görmeyeceğiz!

Aktif ve pasif olan tüm container'ları silmek için

docker container rm $(docker container ls -aq)

komutunu kullanabiliriz.

Peki indirdiğimiz ama kullanmadığımız image listesini nasıl görebiliriz? ya da image listesini nasıl görebiliriz?

docker images

bize docker hosts üzerinde bulunan tüm image listesini detayları ile getirir.

peki bu image listesinden bir image silmek istersek ne yapabiliriz?

docker rmi imageName|imageID

image'i silecektir.

Önemli Not Bir image'i silmek için, bu image'i kullanan herhangi bir container olmaması gerekir. Bundan dolayı ilk olarak bu image'e bağlı tüm container'ları silip sonrasında bu komutu çalıştırmalısınız.

Daha önceden docker run nginx ile beraber image'i bilgisayarımıza indirmiş ve bu sırada ubuntu image'ini yüklemesini beklemiştik. Tabi ki indirme ve çalıştırma esnasında bir bekleme süresi geçti. Bunu yapmak istemiyorsak? Yani sadece image'i indirip bırakmak istiyorsak bu durumda.

docker pull imageName (nginx)

diyebiliriz. Bu durumda sadece indirip bırakır. Image'i çalıştırmaz!

Attach and Detach

Normalde bir bir docker image run ettiğimizde bu container ile ilgili bilgileri ya da Logları ekrana basabilir. Burada container'ın gereksinimlerinden dolayı çalıştırdığımız terminal üzerinde bir çok loga rastlayabiliriz. Bu modun adına attach mode denilir. İstersek bunu arkaplanda yapabiliriz. Yani bir uygulamayı arkaplanda çalışmasını sağlayabilir ve bu bizim terminal üzerinde herhangi bir log görmemize engel olur bu modun adına da detach mode denilir. Bunu yapmak için;

docker run -d imageName

bu bize ayağa kaldırdığı container'in ID bilgisini verecektir.

Eğer detach yapılmış bir container'ı attach moda geri sokmak istersek bunu için attach komutunu kullanabilirz.

docker attach containerID

Not:

docker komutu ile tanımladığınız herhangi bir komutta eğer ID bilgisine ihtiyaç duyuyorsanız bu ID bilgisinin ilk bir kaç karakterini tanımlamanız yeterli. Yukarıdaki örnek üzerinden gidecek olursak;

docker attach a043d

yazdığımızda bu bizim için detach moda sokulan container'ın ID bilgisine eşittir.

docker run -d --name webapp nginx:1.14-alpine

## Docker Run Komutu ### run -tag Bir image pull ettiğimizde bu image belirli bir sürüme sahip olur. Bu sürümün adına tag denilir. Son sürüm indirildiğinde bu tag latest olacaktır.

### run -stdin (-it/interactive terminal)

Örneğin terminal üzerinde kullanıcıdan bir bilgi alan uygulamanız var ve bu uygulamayı dockerize ettiniz. Bu uygulamanın image adı testApp olsun;

docker run testApp

dediğinizde, çalışan uygulama sizden herhangi bir bilgi almadan sonlanacaktır. Çünkü Docker prompt default olarak kullanıcıdan bilgi almamaya programlıdır. Fakat bunu değiştirebiliriz.

docker run -i testApp

-it argümanını göndererek run ettiğiniz image'de bir user prompt varsa buna izin verir. -i = interactive terminal demektir.

### run -port mapping

Bir container ayaga kaldırdığımızda bu image bir porta sahip olur. Biz bu ayağa kaldırdığımız uygulamaya yani container'a dışarıdan erişmek istediğimizde bu portu kullanarak erişemeyiz. Bunun yerine port mapping yapmalıyız. Bunu yapmak oldukça basit.

docker run -p DIS_PORT:IC_PORT imageName

şeklinde düşünülebilir. yani

docker run -p 80:5000 webApp

şeklinde bir komut ile çalıştırdığımızda artık biz uygulamamıza (yani docker host/engine üzerindeki container'a) 80 portu üzerinden erişebiliriz. Fakat Docker Engine/Host içerisinde uygulamamız çalışırken 5000 üzerinden çalışmaya devam edecektir. Böylece portları maplemiş oluyoruz.

### run -volume mapping

Docker container içerisinde veriler herhangi bir şekilde kalıcı olamaz. Bundan dolayı dockerize ettiğiniz uygulamanız dosya sistemi üzerinde eğer veri saklamaya ihtiyaç duyuyorsa ya da container içerisinde veri tabanı barındıran bir sistem de olabilir (mysql, mongodb vs.). Bu durumda volume kullanarak persistency sağlıyoruz yani kalıcılık. Bunun için container dışında bir location seçerek run komutu ile beraber volume mapping yapıyoruz.

Bunu yapabilmek için;

docker run -v /opt/datadir:/var/lib/mysql mysql

dediğimizde mySQL'in kayıtları sakladığı dizin olan /var/lib/mysql'deki verileri docker host içerisinde /opt/datadir klasöründe tutacaktır. Bu /opt/datadir klasörü docker host/engine tarafından izin verilen klasörlerden olmalıdır. Verilen data klasörü Container silinse bile bilgiler docker engine üzerinde kalmaya devam eder.

### inspect

Docker ps komutu contariner'lar hakkinda birçok bilgiyi bizimle paylaşır. Fakat daha fazla bilgiye ihtiyaciniz olursa inspect komutu bu bilgileri bize sağlar.

docker inspect containerName

### Container logs Özellikle -d dettach mod ile çalışan bir container'a ait logları görmek için logs komutunu kullanabilirsiniz.

docker logs containerName

Image Tag

Bir image'e tag vermek istiyorsak bu oldukça kolay.

docker image tag imageID/imageName tagName

### Docker Images Kendimize ait bir docker image yaratmak istersek bunu yapabildiğimiz yollardan bir tanesi Dockerfile oluşturmak. Dockerfile docker tarafından bilinen image yaratırken bizim image'imizin içerisinde bulunmasını istediğimiz tüm yapıları barındıran bir dosyadır.

Genel olarak Dockerfile içerisinde yazdığımız komuların yapısı şu şekildedir.

KOMUT ARGUMAN

KOMUT docker tarafından bilinen Komut setlerinden bir tanesi olmalıdır. ARGUMAN ise, KOMUT un yapacağı işlevi belirtir. Örnek olarak bir Docker file dosyasına bakalım.

FROM ubuntu:18.04
RUN apt-get update
# RUN DEBIAN_FRONTEND="noninteractive" apt-get -y install tzdata
RUN apt-get install curl -y
RUN curl -sL https://deb.nodesource.com/setup_10.x | bash
RUN apt-get install nodejs -y

COPY . /opt/node-server/
WORKDIR /opt/node-server
RUN npm install
CMD ["node", "app.js"]

Bu dosyadaki komutlardan FROM, RUN, COPY, WORKDIR, CMD komutları docker engine'ine ne yapması gerektiğini söyler. Buradaki en önemli durum ise Her Dockerfile bir FROM komutu ile başlamalıdır.

FROM komutu o image'in hangi Image üzerinden Base alınacağını söyler. Yani Her bir image başka bir BaseImage üzerinden türetilir. Örneğimizdeki image ise ubuntu image'inin 18.04 isimli tag'i üzerinden türetilmiştir.

Build Image (Bir image'i oluşturmak)

Dockerfile üzerinden bir image üretmek için;

docker build Dockerfile

ya da aynı dizindeysek

docker build .

komutu kullanılabilir. Docker Engine hemen Dockerfile üzerindeki direktifleri yapmaya başlayacaktır. Bu sırada Dockerfile içerisindeki her bir satır ayrı ayrı işleme tâbi tutulur. Bu yapının adına Layered denilir.

Layered Structure

Dockerfile üzerindeki her bir satır Docker Host üzerinde Layer by layer çalışmaktadır. Yani

Layer 1

FROM ubuntu:18.04

Layer 2

RUN apt-get update

Layer 3

RUN apt-get install curl -y

Layer 4

RUN curl -sL https://deb.nodesource.com/setup_10.x | bash

Layer 5

RUN apt-get install nodejs -y

Layer 6

COPY . /opt/node-server/

Layer 7

WORKDIR /opt/node-server

Layer 8

RUN npm install

Layer 9

CMD ["node", "app.js"]

şeklinde 9 katmandan oluşan yapı şeklinde oluşturulur. Eğer herhangi bir step üzerinde hata alırsak, bundan önceki Layer'lar otomatik olarak geçilip hatanın bulunduğu Step üzerinden build işlemine devam edecektir.

Eğer buradaki Layer'lardan herhangi birine sahip başka bir image daha build edecek olursak Docker Engine o layer'ı build etmez onun yerine build edilmiş olanı tekrardan kullanır.

### Build Image With Tag Name (Bir image'e build anında isim vermek) Eğer bir image'e build edilirken bir isim (tag) vermek istiyorsak -t opsiyonu kullanılabilir. Tam olarak kullanımı ise şu şekilde.

docker build . -t tagName

#### Peki Dockerfile içerisindeki yapıları neye göre oluşturuyoruz?

Bu aslında tahmininizden çok kolay. Eğer docker komut setini aklınızda tutamıyorsanız ya da tam olarak nerede ne yapacağınızı bilmiyorsanız bunu herhangi OS üzerinde nasıl adım adım yapıyorsunuz ilk olarak onu düşünün. Daha sonrasında yaptığınız tüm adımları bir kenara not alın ve başlarına Docker Komut setlerini yerleştirin.

• Mesela sizin uygulamanız nerede çalışacak?
  • Ubuntu üzerinde
  • İlk başta İşletim sisteminin update edilmesi gerekir
    • apt-get update komutu çalıştırılır
  • Ardından Node.js'i indirmek için Curl'e ihtiyacımız olur
    • apt-get install curl -y
  • Sonrasında curl vasıtasıyla Node.js indirilir
    • curl -sL https://deb.nodesource.com/setup_10.x | bash
  • Node.js Yüklenir
    • apt-get install nodejs -y
  • Kaynak dosyalarınızı bir klasör altında oluşturursunuz veya buraya kopyalarsınız
  • Bağımlılıkları yüklersiniz
  • Uygulamayı çalıştırırsınız

İşte bunlar sizin kendi projenizi çalıştırmak için izlediğiniz bir yol. Bunu Docker'ın da yapabilmesi için bu adımları docker'a söylemeniz gerekir. Buradaki en önemli işlem burada işletim sisteminin yaptığı işleri RUN komutuyla yaptırmanız ve sizin manuel olarak yaptığınız işlemleri ise diğer komutlarla yapmanız. Mesela apt-get update işlemi işletim sistemi bazında olacak olan bir durum. Bunun için buna RUN apt-get update diyoruz. Fakat klasörlerinizin oluşturulması veya bir yerden dosyalarınızın kopyalanması ise sizin manuel olarak yaptığınız işlemler. Bundan dolayı bunu COPY komutuyla yapıyoruz. WORKDIR ile altındaki satırların çalışacağı klasörü belirterek yine RUN ile bağımlılıkları yüklüyoruz. Son olarak da uygulamanın image oluşturulduktan sonra container olarak ayağa kaldırılması durumunda çalıştırılacak komutu belirtiyoruz. Yani sizin uygulamanızın çalışması için gereken komut neyse onu belirtiyoruz. Bu da CMD komutu ile yapılabilir.

Environment Variables (Ortam Değişkenleri)

Bir çok uygulama deploy edildiği yerde bulunan environment değişkenlerine göre uygulamada belirli başlı aksiyonları almaktadır. Elbette sizin uygulamanızın da kendisine has belirli başlı dışarıdan alabileceği environment değişkenlerine ihtiyacı olabilir. Bunu bir kaç şekilde Docker ile yapabiliyoruz.

• Container'ı ayağa kaldırma esnasında
• Dockerfile içerisinde image içinde

Container Zamanında

Bu işlem için -e DEGISKEN=DEGER şeklinde tanımlama yapabiliyoruz. Burada istediğimiz kadar parametre gönderebiliriz.

docker run -r CHANNEL_NAME=kablosuzkedi

çalışan bir container'ın sahip olduğu ENV değişkenlerinin bilgilerine ulaşmak için;

docker inspect containerName

yapıldıktan sonra Config > Env altında bulunabilir.

DOCKER --link

Çalışan 2 container'ı birbirine bağlamak için bu iki container'ı birbirine linkleyebiliriz. Bunun için bağlanılmak istenen container'ın çalıştırılırken name almış olması gerekir.

Bunu iki farklı örnek ile açıklayalım. Bir MySQL ayağa kaldırdığımız bir container'ımız var. Aynı şekilde MySQL'e erişebilecek bir arayüz olan phpMyAdmin olsun. Bu iki container arasında bağlantı kurmamız gerekiyor ki phpMyAdmin MySQL'e bağlanabilsin. Bunun için;

docker run --name mysql-server -p 3306:3306 -e MYSQL_ROOT_PASSWORD=test123456 mysql

docker run --name mysql-server -p 3306:3306 -v /opt/data:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=test123 mysql

docker run --name padmin -p 8000:80 --link mysql-server:db phpmyadmin/phpmyadmin

Diğer bir örneğimiz ise kendi yaptığımız bir proje üzerinden olsun;

Bir TODO App'imiz var. NodeJS ile MongoDB arasında bir bağlantı kurmamız gerekiyor. Burada NodeJS ile MongoDB'ye bağlantı kurduğumuz için MongoDB için ayağa kaldırdığımız container'ın name almış olması gerekiyor.

docker run --name mongo-container mongo

daha sonra ayağa kalkmış mongo-container isimli container'a NodeJS içerisinden bağlanmak için link yapıyoruz.

Not: NodeJS için kullanacağımız ImageName todo-app olsun.

docker run -p 3001:3001 --link baglanilacakContainerName:kodIcerisindeKullanilacakAlias todo-app

şeklinde yapilmalidir. Peki burada açıklamamız gereken 2 farkli nokta var.

baglanilacakContainerName : Adından da anlaşılabileceği gibi bağlanmak istediğimiz container'ın adını belirttiğimiz bölüm. Bizim durumumuz için bu mongo-container olmalıdır.

kodIcerisindeKullanilacakAlias : Bu bölüm biraz çetrefilli işte :) Mongoose ile mongoDB'ye bağlanmak için yazdığımız komut aşağıdaki gibidir;

 await Mongoose.connect("mongodb://127.0.0.1:27017/todos", {
    useNewUrlParser: true,
    useUnifiedTopology: true,
  });

Fakat container'lar çalıştığında 127.0.0.1 üzerinden çalışmıyor. Docker Host içerisinde çalışıyorlar. Bu container'ları birbirlerine bağlamak için burada --link argümanını kullandık. Bundan dolayı da bu bağlantı cümlesi değiştirilmelidir.

Peki nasıl?

yukarıda mongodb için --link baglanilacakContainerName:kodIcerisindeKullanilacakAlias tanımını yapmıştık. Buradaki kodIcerisindeKullanilacakAlias bizim tamı tamına mongoDB'ye kod üzerinden bağlantıyı yaptığımız yerdeki değişikliği belirtiyor.

 await Mongoose.connect("mongodb://kodIcerisindeKullanilacakAlias:27017/todos", {
    useNewUrlParser: true,
    useUnifiedTopology: true,
  });

CMD ile ENTRYPOINT arasındaki farklar

CMD ile ENTRYPOINT temelde aynı komutlar yani Container ayağa kalktığı anda çalıştırılacak komutları belirlerler. Fakat ikisi arasındaki temel fark şudur. Ubuntuyu şu şeklide çalıştırdığınızı farzedelim.

docker run ubuntu

ubuntu image'inin içerisinde bulunan CMD komutundan dolayı burada container ayağa kalkar ve direk kapanır. Çünkü çalışabilecek bir prosesi bulunmamaktadır. Fakat;

docker run ubuntu sleep 2

gibi bir komut verdiğinizde bu arkadaş 2 saniye bekler. Peki neden? Eğer DockerHub üzerinden ubuntunun image'ine giderseniz orada CMD ["/bin/bash"] yazdığını göreceksiniz.docker run imageName ifadesinden sonra yazdığımız bir argüman bizim Image içerisinde kullandığımız CMD komutunu overwrite eder. Yani docker run imageName [CMD]olarak düşünebilirsiniz bunu.

Burada CMD komutun içeriğini komple değiştirir yani. Fakat siz parametreyi bizim durumumuzda sleep 2 yani 2 değerini çalışma anında göndermek istiyorsanız işte işler burada değişiyor.

Bunun için ENTRYPOINT kullanabilirsiniz. ENTRYPOINT'in yapmış olduğu işlem; container ayağa kalktığında kendi içerisinde tanımlanmış olan executable bir uygulamaya sizin gönderdiğiniz parametreyi eklemek. Yani;

Image içerisinde şöyle bir yapımız olsun;

FROM ubuntu
ENTRYPOINT ["sleep"]

bu image'den bir instance alarak container ayağa kaldırmak istediğinizde;

docker run imageName 10

ifadesi gibi bir ifade ile çalıştırırsınız. Bu durumda ENTRYPOINT 10 argümanını alır ve sleep in sonuna ekler yani sleep 10 olur.

Temel olarak farkı budur. CMD komple değiştirilir, ENTRYPOINT ekleme yapar.

CMD ve ENTRYPOINT Yazım Şekilleri

CMD ["executable", "param1", "param2", "param3"]

şeklinde JSON formunda bunu yazabildiğiniz gibi shell formunda da yazabilirsiniz.

CMD executable param1 param2 param3 param4

Aynı yapı ENTRYPOINT için de geçerlidir.

ENTRYPOINT ["executable"]

şeklinde JSON formunda bunu yazabildiğiniz gibi shell formunda da yazabilirsiniz.

ENTRYPOINT executable

DOCKER COMPOSE

Ya sizin birden fazla servisiniz ve bunlarda kullandığınız birden farkli veritabanı, izleme araçları, cache servisi varsa? Bunlar sizin uygulamanız içerisinde aktif olarak kullanılıyorsa her defasında uygulamayı çalıştırmadan önce sürekli sürekli bu link işlemini mi yapmalıyız? Buna cevabımız HAYIR Diğer bir durum ise bu uygulamanızda kullanılan servislerin uygulamanızdan önce çalıştırılmış olmasıdır ki Uygulamanız başarılı bir şekilde bağlanabilsin.

Bunun yerine servislerimizi detaylı bir şekilde tanımlayabildiğimiz mesela;

• Kullanacağı image ya da Dockerfile
• Port numaraları
• Volume Mapping
• Bağlı olduğu servisler

ve çok daha fazlasını yapabildiğimiz bir yapıdır docker compose.

Docker compose bizim image'lerimizi üretmemize ve bu image'lerin container'lara dönüşmesine yardımcı olan bunları tamı tamına bizim istediğimiz sıra ile yapan yardımcı bir araçtır.

Peki bunu nasıl yapıyoruz. Bunun için en önemli nokta; nasıl kendimize ait bir image oluştururuken Dockerfile isimli bir özel dosyadan yararlanıyorsak. Burada da yine docker için bir anlam ifade eden docker-compose.yml isimli YML dosyasından yararlanacağız. Örnek bir YML file üzerinden incelememize devam edelim.

version: "3.4"
services:
  webapp:
    build: .
    ports:
      - 3001:3001
    depends_on:
      - mongodb
  mongodb:
    image: mongo:latest
    ports:
      - 27018:27018
    volumes:
      - data:/data/db
volumes:
  data:

peki bunlar nedir? Hemen açıklayalım.

• services Bizim componentlerimizi servislerimizi belirtir. Mesela webapp, mongodb, redis vs vs.. --link ile yapmış olduğumuz bağlantıdaki gibi named container isimleri olarak düşünebilirsiniz.
  • build Eğer custom bir image'e sahipseniz yani kendi kaynak kodunuzla bir image üretiyorsanız bunun için hazırlamış olduğunuz Dockerfile dosyasını kaynak olarak gösterebilirsiniz. Burada docker-compose.yml ile Dockerfile aynı yerde olduğu için "." kullandık.
  • ports Bir container'ı ayağa kaldırırken kullandığımız -p flag' inden farklı bir şey değildir.
  • volumes eğer bu container içerisindeki bilgiler bir volume üzerine tutulacaksa bunu volumes altında tanımlıyoruz.
  • depends_on ise bizim için oldukça heyecan verici diğer bir özellik. Birbirleriyle bağlantıyı aslında tam olarak burada yapıyoruz diyebilirim. depends_on içerisinde tanımladığımız isimler aslında bu yml file içerisindeki diğer servis isimleri. Docker bunu gördüğünde depends_on içindeki servisler tamamen ayağa kalkmadan önce kesinlikle ilgili servisi çalıştırmaz. Yani bizim örneğimizden yola çıkacak olursak. mongodb servisi ayağa kalkmadan önce webapp çalıştırılmaz.
  • image Eğer dockerHub üzerinden bir image çekiyorsanız onu burada belirtmelisiniz. Aslında Container'ın BASE IMAGE olarak kullanacağı image'i belirtir. Yani Dockerfile üzerindeki FROM komutuna denk gelir.
• volumes Servisler içerisinde belirtmiş olduğumuz volumes tanımlamalarını burada da yazmamız gerekiyor.

Peki bu dosyayı ürettikten sonra nasıl uygulamayı çalıştıracağız?

Bu oldukça kolay. docker-compose.yml dosyasının bulunduğu dizine giderek;

docker-compose up

dememiz yeterlidir. Bu bizim için içerisinde bulunan image tanımlarını bir bundle olarak yapar ve container'ı ayağa kaldıracaktır.

Docker Networks

Docker varsayılan olarak gelen 3 farklı network türü vardır.

• Bridge
• None
• Host

Hepsinin birbirinden farklı özellikleri vardır.

Bridge Network

Docker host içerisinde birbirlerinden bağımsız IP'lerde çalışan farklı farklı container'ları belirtir. Bu container'lar kendi aralarında iletişim kurabilirler.

docker run --network=bridge mongo

None Network

Docker host içerisinde herhangi bir şekilde bağlantı kurulamayan izole edilmiş container'lar için kullanılan network türüdür.

docker run --network=none mongo

Host Network

Docker host üzerinde yapabileceğimiz işlemler için kullanılan network türüdür.

docker run --network=host mongo

Peki biz 2 container sadece bir network üzerinde diğer 2 container'da farklı bir network üzerinde çalışmasını isteseydik(yani birbirlerinden izole etmek isteseydik) nasıl bir network türü oluşturacaktık?

Kullanıcı Tanımlı Networks

docker network create --driver bridge --subnet 182.18.0.1/24 --gateway 182.18.0.1 wp-mysql-network

docker network ls

komutunu kullanarak, kullanılan tüm network'lerin listesini görebilirsiniz.

Bir network ile ilgili detayları öğrenmek istiyorsanız

docker network inspect bridge

komutunu kullanabilirsiniz.

Herhangi bir container'in kullanmış olduğu networke ait detayları görmek istersek

docker inspect containerName

komutu ile bunu rahatlıkla yapabiliriz.

Container > Container arası iletişim

Eğer bir container'da bulunan uygulamanız diğer bir container içerisinde çalışan bir MySQL, MongoDB vs gibi herhangi bir uygulamaya erişmek isterse örneğin mysql bağlantısı için;

mysql.connect(172.18.0.3)

şeklinde IP adresi üzerinden bağlanabiliriz fakat bu doğru bir yol değildir. Çünkü Docker host yeniden başlatıldığında Docker host bu IP adresinin hala mysql isimli image'e ait olup olamayacağının garantisini veremez.

Bunun yerine yapılacak en iyi çözüm containerName ile bağlanmaktır.

mysql.connect(mysql-db)

şeklinde bağlantı yaptığımızda container, diğer container içerisinde bulunan mysql instance'ına erişebilecektir.

### ÖRNEK

docker network create --driver bridge --subnet 182.18.0.1/24 --gateway 182.18.0.1 wp-mysql-network

docker run --name mysql-db -e MYSQL_ROOT_PASSWORD=db_pass123 --network=wp-mysql-network mysql:5.6

docker run --name webapp -e DB_Host=mysql-db --network=wp-mysql-network kodekloud/simple-webapp-mysql

ÖRNEK 2 node-mongo-todo-app

docker network create todo-app-network

docker run --name mongodb --net todo-app-network -d mongo

docker run --name todo-app -p 3001:3001 --net todo-app-network node-mongo-todo-app

Aynı Network içerisinde bulunan bu iki uygulamayi birbirine bağlamak için "IP" adresi üzerinden değil container name üzerinden ilerliyoruz. Buna göre MongoDB ye bağlanmak için.

mongodb:27017/todos

dememiz yeterlidir.

Bir image'i Docker Hub'a göndermek

Elimizde bir image var diyelim. Bunu public olarak dockerHub'a göndermek istiyoruz bunu nasıl yapabiliriz?

Bunun için ilk olarak DockerHub üzerinde bir hesabınızın olması gerekiyor. Bu hesap üzerinde kendinize ait public/private olarak saklayabileceğiniz image'lerinizi tutabilir ve bunlara erişebilir ve kendin Docker Host'unuz üzerine çekebilirsiniz.

Eğer dockerHub üzerinde bir account'unuz varsa o zaman terminal üzerinden docker ile sisteme giriş yapmanız gerekiyor.

docker login

ile giriş yaptıktan sonra artık kendi ürettiğimiz image'leri dockerHub'a gönderebiliriz demektir. Bu işlemi yapmak için yapacağımız tek komut image push. Tam kullanımı ise;

docker image push imageName:tagName

Bir image'e ait tüm tag'leri dockerHub üzerine göndermek istiyorsanız.

docker image push --all-tags imageName

argümanını kullanabilirisiniz. Fakat burada dikkat etmemiz gereken çok önemli bir durum söz konusu.

Eğer Docker tarafından onaylanan bir DockerHub Pusher değilseniz (Mongo, Node, Ubuntu vs) Docker'a kendi imageName'inizle bir image upload edemezsiniz. Bu image'in önüne kullanıcı adınızı koyarak bu image'i göndermeniz lazım yani;

kendi oluşturmuş olduğunuz image'in ismi counter-app diyelim. Bunu DockerHub üzerine göndermek istiyorsanız;

docker image push --all-tags gkandemir/counter-app

şeklinde image'i gönderebilirsiniz. Fakat bu durumda gkandemir/counter-app şeklinde bir image'iniz Docker Engine üzerinde olmayabilir. Bundan dolayı kullandığınız image'i yeni bir tag ekleyerek push yapılabilecek hale getirebilirsiniz.

docker image tag counter-app gkandemir/counter-app

dedikten sonra artık DockerHub'a gönderebiliriz.

docker image push --all-tags gkandemir/counter-app

Ubuntu'ya Docker Yüklemek | Production | Reverse Proxy

Bu işlem için ilk olarak DigitalOcean üzerinden Ubuntu 20.04(LTS) bir sunucu aldım ve onunla yoluma devam ettim. Sunucuya ssh ile giriş yaptıktan sonra aşağıdaki gibi adımları teker teker uyguladım fakat bunlar için 2 farklı kaynak önerebilirim size;

Ubuntu'ya Docker Yüklemek Install Docker Engine on Ubuntu

Reverse Proxy Açıklaması Reverse Proxy NGINX

Yine ben buraya kendi adımlarımızı da yazıyorum çünkü biz 2 farklı domain'i tek bir host üzerine yönlendirdik. Yukarıdaki Reverse Proxy açıklaması tam olarak yaptıklarımızı karşılamıyor yine de okumanızda fayda vardır :)

İlk olarak paket listesini güncelleyip ihtiyacımız olan bazı paketleri yüklüyoruz.

sudo apt-get update
apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

Docker ve Docker Compose kurulumlarını yapıp versiyonlarını kontrol ediyoruz

apt install docker.io
docker --version

apt install docker-compose
docker-compose --version

Docker servisinin çalışıp çalışmadığına dikkat edelim. Eğer burada active(Running) gibi bir ifade yoksa servisi çalıştırmalıyız.

systemctl status docker

Çalıştırmak için;

systemctl start docker

Şimdi Docker yüklendi 2 farklı uygulamayı iki farklı domain tarafından görüntülenebilecek şekilde ayarlayacağız hostumuzu fakat öncesinde bu iki uygulamayı Docker üzerinen sunmamız gerekiyor. Yani Container'ları ayağa kaldırmamız lazım. Container için gerekli olanlar nedir? Image. O halde image'leri oluşturmaya başlayalım.

Bunun için /temp altında web-apps isimli bir klasör oluşturduk ve onun içerisinde wordpress ve asana-clone isimli 2 farklı klasör oluşturduk.

mkdir web-app/wordpress
mkdir web-app/asana-clone

WordPress kurulumu için wordpress klasörü içerisinde docker-compose.yml dosyasını oluşturup içerisine aşağıdaki kodları yazabilirsiniz.

version: "3.4"
services:
  wordpress:
    image: wordpress
    ports:
      - 8080:80
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: bloguser
      WORDPRESS_DB_PASSWORD: test123
      WORDPRESS_DB_NAME: blogdb
    volumes:
      - wordpress:/var/www/html
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: blogdb
      MYSQL_USER: bloguser
      MYSQL_PASSWORD: test123
      MYSQL_RANDOM_ROOT_PASSWORD: "1"
    volumes:
      - db:/var/lib/mysql
volumes:
  wordpress:
  db:

daha sonrasında yapacağımız tek işlem;

docker-compose up

ÖNEMLİ NOT: bunu yaparken /tmp/web-apps/wordpress dizininde olduğunuzdan emin olun.

Asana Clone App kurulumu için ise Local üzerinden dosyayı aktardık. Onun içerisinde zaten bir app/ ve bir de Dockerfile olduğu için onu direk sunucuya scp yardımı ile gönderdik.

Örnek Dockerfile içeriği;

FROM node:14-slim
WORKDIR /vue-app
COPY app/ .
RUN npm install
RUN npm install -g live-server
RUN npm run build
EXPOSE 8080
CMD ["live-server", "dist"]

Bu Dockerfile üzerinden image üretmek için de;

docker build . -t asana-clone-app

dememiz yeterlidir. Bu image'i çalıştırmak için ise;

docker run -p 8090:8080 -d asana-clone-app

dememiz yeterli olacaktır.

ÖNEMLİ NOT: bunun içinde /temp/web-apps/asana-clone/ dizininde olduğunuzdan emin olun.

Artık Sunucu üzerinde 8090 portundan Asana uygulamasını, 8080 portu üzerinden ise wordpress uygulamasını ayağa kaldırdık.

Elimizde 2 farklı domain var;

• videomeet.app
• talkinghead.app

bu iki domaini ilk başta DigitalOcean üzerinden almış olduğumuz Sunucunun IP Adresine CloudFlare üzerinden yönlendirdik. Yani kullanıcı bu iki domainden hangisine girerse girsin aynı makineye yönlendirilecek.

Şimdi yapmamız gereken ise buradaki domainin ismine göre (talkinghead ya da videomeet) ilgili container'a yönlendirmek olacak. İşte bu duruma reverse proxy deniliyor. Bunu yapmak için sunucuda yoksa nginx yüklemeliyiz. Ardından da sites-available dizinine girip orada reverse-proxy.conf dosyası üreteceğiz. Yazacağımız Reverse Proxy bilgisini bu konfigürasyon dosyasında saklayacağız.

apt install nginx
unlink /etc/nginx/sites-enabled/default
cd /etc/nginx/sites-available
vi reverse-proxy.conf

Konfigürasyon ise;

server {
        listen 80;
        listen [::]:80;
        server_name videomeet.app;
        server_name_in_redirect off;

        access_log /var/log/nginx/reverse-access.log;
        error_log /var/log/nginx/reverse-error.log;

        location / {
            proxy_set_header Client-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            proxy_pass http://127.0.0.1:8080;
  }
}

server {
        listen 80;
        listen [::]:80;
        server_name talkinghead.app;
        server_name_in_redirect off;

        access_log /var/log/nginx/reverse-access.log;
        error_log /var/log/nginx/reverse-error.log;

        location / {
            proxy_set_header Client-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            proxy_pass http://127.0.0.1:8090;
  }
}

daha sonrasında şu adımları yapmalıyız;

ln -s /etc/nginx/sites-available/reverse-proxy.conf /etc/nginx/sites-enabled/reverse-proxy.conf
nginx -t
systemctl restart nginx
systemctl status nginx

burayı özet geçecek olursak sites-available içerisindeki reverse-proxy.conf dosyasını sites-enabled içerisine aktarıyoruz ve nginx'i test ediyoruz. Burada eğer success görüyorsanız her şey yolunda demektir :)

Bundan sonraki tek adım ise nginx servisini yeniden başlatmak demektir :)

Böylece 2 farklı domain tek sunucu üzerinen docker host'un farklı uçlarına bakıyor hale geldiler.