CategoryGenel

Docker Hub ile Automated build nasıl konfigüre edilir?

Docker hub ile github üzerinden Automated build nasıl yapılır ve nasıl kullanılır bu konu hakkında bilgi vereceğim.

Öncelikle fiyatlandırması ile ilgili bilgi vermek istiyorum. Eğer tek projeniz varsa free hesabı yeterli oluyor fakat birden fazla proje için kullanacaksanız aşağıdaki fiyatlandırmayı göz önünde bulundurmalısınız.

Git Repository oluşturulması

Github üzerinde bir repository oluşturmalıyız. Oluşturduktan sonra eğer birden fazla image çıktısı olacak ise örneğin api,client ve nginx için 3 adet image istiyorsak buna göre bir klasörleme yapabiliriz. Oluşturacağımız her image içinde mutlaka bir dockerfile oluşturmalıyız.

Docker Hub Repository oluşturulması

Öncelikle hub.docker.com’a üye oluyoruz. Üye olduktan sonra Repositories -> Create Repository‘i tıklıyoruz. Önümüzde aşağıdaki gibi bir ekran geliyor.

Bu ekranda name ve description ayarlarını girdikten sonra github ya da bitbucket ile hesabımızı bağlayıp oradanda git repomuzu seçiyoruz.

Sonrasında eğer birden fazla image oluşturacaksak, varsayılan ayarlarında kullanmayacaksak click here to customize the build settings butonunu tıkılıyoruz.

Benim projemde api,socket ve nginx vardı. Bunun için aşağıdaki gibi bir ayar kullandım.

Ayrıyetten bu kısım için aşağıdaki gibi özel değişkenleri kullanılmasına izin veriyor.

Docker’da oluşturulan image ile konteynerın kaldırılması

Yukardaki ayarları yaptık ilk commit’imizi çıktık ve image’imiz oluştuğumuzu varsayıyorum. O zaman docker sunucumuza girip konteynırımızı kaldırma vakti.

Öncelikle docker login ile hub.docker.com’daki üyeliğimiz ile login olmalıyız. Login olduktan sonra docker pull username/repo-adi -a komutu ile bu repoya ait tüm versiyonları indirebiliriz.

Sunucumuza image’leri indirdikten sonra docker run usernam/repoadi:api şeklidne api tagi ile olan image’imizi docker üzerinde kaldırabiliriz.

Sonraki yazılarımda docker,docker image,docker file ve docker konteyner hakkında genel bilgi vermeye çalışacağım.

SOLID Yazılım Geliştirme Prensipleri Nedir?

SOLID Prensipleri, yazılım geliştirirken object oriented programlamaya uygun, açık ve geliştirilebilir kod yazmak için dünya çapında uygulanması gereken prensiplerdir. 5 ana prensip vardır.

  • Single Responsibility Principle
  • Open/Closed Principle
  • Liskov ‘s Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

Bu prensipleri tek tek c# dili ile örnekler vererek anlatmaya çalışacağım.

S – Single Responsibility Principle

Her metodun tek sorumluluğu olması anlamına gelir. Yani bir metoda sadece tek bir iş yaptırırız. Örneğin mesaj gönderme fonksiyonu sadece mesaj gönderir. Onun haricinde bir iş yapmaz.

Örneklendirelim. Aşağıda ki örnek Message sınıfı içinde bir mesaj gönderme fonksiyonu var. Bu mesaj gönderme fonksiyonu hem mesaj gönderiyor hemde hata varsa bunun loglamasını yapıyor. Dolayısı ile birden fazla iş yapmaktadır. Bu da tek sorumluluk prensibine aykırı bir durumdur.

Bunu düzeltmek için loglama görevini ayrı bir methoda vermeliyiz. Aşağıdaki örnekte loglama için ayrı bir sınıf oluşturdum. Bu sınıftaki bir fonksiyona da loglama işini yaptırdım.

O – Open/closed principle

Açık/Kapalılık prensibi, metodlar genişlemeye açıktır fakat değişime kapalıdır. Yeni özellikler eklenebilir fakat değiştirilemez.

Hemen bunuda örneklendirelim. Bunu örneklendirmek biraz daha zor olacaktır. Fakat yukarıdaki Single responsibility prensibinde ki verdiğim örnek üzerinden gitmeye çalışacağım. Örneğin gizli mesajlar diye bir şey olsun. Ve mesajın başında [hidden] yazıyorsa bu gizli mesajlar veritabanına eklensin.

Aşağıdaki kod bu işi yapıyor. Fakat Açık/Kapalılık ilkesine aykırı olarak yapıyor.

Bu kod yerine prensiplere uygun kod yazmak için aşağıdaki kodu kullanmalıyız. Bu kod ile fonksiyonun içini değiştirmek yerine ayrı bir HiddenMessage için bir sınıf oluşturduk ve bu sınıf içindeki fonksiyonu override ettik.

L – Liskov substitution principle

Liskov’un yerine geçme prensibi, katılım aldıkları sınıfın tüm özelliklerini kullanmasını ve sonrasında kendi özelliklerini üstüne eklemesini baz alır.

Örneğin kuş isimli bir sınıfımız var. Bu sınıf içinde adında bir metot var. Kartal kuş sınıfından üretiliyor ve bu sınıftaki metodunu kullanıyor. Buraya kadar her şey sorunsuz fakat tavukta bu sınfıtan üretiliyor ama uç metodunu kullanamıyor. Bu yüzden dolayı bu LSP’ye aykırıdır. Tavuğun ayrı bir sınfıtan üretilmesi gerekir.

Yukarda verdiğim Message Örneklerinden gitmek gerekirse PrivateMessage şeklinde bir sınıfımız olsun ve bu sınıf içinde SendPrivateMessage adında bir metod olsun.

Yukarıdaki örnekte PrivateMessage sınıfı kalıtım aldığı sınıfındaki metotları kullanmadığı için bu prensibe aykırıdır. Doğrusu aşağıdaki gibidiir.

I – Interface segregation principle

Bir arayüzde gerekli olmayan metotların eklenmemesi prensibidir. Yine kuş örneğini verecek olursak tavuk sınıfı için metodu gerekli olmayan bir metodudur. Çünkü tavuk hiç bir zaman o metodu kullanmayacaktır.

Aşağıdaki örnekte NewMessage sınıfında gerekli olmayan bir ReadMessage için bir metod bulunmaktadır.

Fakat bunun yerine aşağıdaki gibi 2 farklı arayüz olmalıdır.

D – Dependency inversion principle

Bağımlılığın ters çevrilmesi ilkesi, üst seviyeli sınıflar, metotlar alt seviyeli sınıf ve metotlara bağımlı olmamalıdır. Aynı şekilde alt seviyede yapılan değişiklikler de üst seviyeli etkilenmemelidir.

Burda yanlış örnek olarak az önce single responsibility principle için doğru dediğimiz örneği vereceğim.

Burda Database ve Logger için bağımlılık var. Bunu bu prensibe uygun yapmak için aşağıdaki gibi bir kod yazmalıyız. Database ve Logger içerde bi bağımlılığı olmaması gerekir.