Vrrp birden çok yönlendiricinin tek bir yönlendirici gibi davranmasına imkan veren bir yönlendirici yedekliliği protokolüdür. IEEE standartlarına uygundur. Vrrp, bir yönlendiricinin durumu hakkında bilgi verir, bu yönlendirici tarafından işlenen ve değiştirilen rotalar hakkında bilgi vermez.
Vrrp bir Ip alt ağında otomatik varsayılan ağ geçidi seçimleri aracılığıyla yönlendirme yollarının güvenilirliğini ve kullanılabilirliğini arttırır. Bunu ana ve yedek yönlendiriciler grubu oluşturarak yapar. Varsayılan ağ geçidi fiziksel yönlendirici yerine sanal yönlendiriciye atanır.
Vrrp'de seçilen bir yönlendirici sanal IP adresine gelen istekleri işler. Bu yönlendiriciye ana yönlendirici (master) denir. Bir vrrp grubunda birden fazla ana yönlendirici ve yedek yönlendirici bulunabilir. Yerel ağdaki cihazlar varsayılan olarak sanal yönlendirici grubunun Ip adresini kullanır.
Vrrp avantajlarından bir kaçı; yük paylaşımı ( Birden çok yönlendirici üzerinden trafik iletilir. ), aktif yönlendirici düşerse yedek ayağa kalkar ve aktif yönlendirici geri gelirse yedek yönlendirici yeniden yedek yönlendirici olur.
Hsrp yedekleme protokülü de vardır. Bu protokol cisco'ya özel bir protokoldür
Bir sanal yönlendirici grubu oluşturalım.
R1:
interface Ethernet1/0
ip address 10.10.10.1 255.255.255.0
vrrp 1 ip 10.10.10.254
vrrp 1 priority 254
R2:
interface Ethernet1/0
ip address 10.10.10.2 255.255.255.0
vrrp 1 ip 10.10.10.254
vrrp 1 priority 250
Yukarıdaki topolojide 2 yönlendiriciden oluşturulmuş bir sanal yönlendirici grubu bulunmaktadır. İki routerımız için gerekli konfigürasyonları gerçekleştirdik. Bu iki
yönlendirici Ana ve yedek olacaklarını kendi aralarında, priority değeri
belirlediğimiz için bu değerlere bakarak seçecekler. Öncelik numarası (priority number) en yüksek olan R1 ana yönlendirici olarak gözükmektedir. Öncelik numarası varsayılan olarak 100’dür. Bir
yönlendiriciye elle 1-254 arası öncelik numarası verilebilir.
VRRP'nin özelliklerinden biri de bir yönlendiriciye hangi
öncelik numarası verilirse verilsin eğer yönlendiricinin IP adresi sanal
yönlendirici grubunun IP adresi ise o yönlendiricinin öncelik numarası
otomatik olarak 255 olur ve ana yönlendirici olur
VRRP komutları oturduktan ve iki router birbirini gördükten sonra “show vrrp” komutu ile durumlarını teyit edebilirsiniz.
24 Mart 2018 Cumartesi
10 Şubat 2018 Cumartesi
SFTP & TFTP
SFTP
Sftp, ssh kullanarak dosya transferi yapan bir dosya aktarım protokolüdür. Sftp ssh'ın sağladığı güvenlik özelliklerini kullanmış olur. Nerdeyse tüm linux dağıtımlarda stfp istemcisi ön tanımlı olarak gelir.
Sftp bağlantısını kurarken aynı ssh komutu gibi kullanıyoruz:
"$ sftp kullanıcı_adı@sftpserverip"
Eğer varsayılan port dışında bir port kullanılıyorsa, port numarasını -P parametresi ile birlikte vererek bağlantı sağlayabilirsiniz.
? işareti ile sftp için kullanabilceğimiz komutları ve ne işe yaradıklarını görebiliriz.
Sftp sunucusundan istemciye dosya almak için get , göndermek için put komutunu kullanıyoruz.
ls komutu ile sftp sunucusunda olduğumuz dizini listeleyebiliriz.
lls komutu ile de sftp istemcisinde olduğumuz dizini listeleriz.
Yukarıdaki resimde kullanabilceğimiz komutları görebilirsiniz.
TFTP
Tftp protokolü de dosya transferi için kullanılan basit bir protokoldur. 69.port üzerinden genellikle udp kullanılarak uygulanır. Kullanımı sırasında az bellek kullandığı için genelde yönlendirici bilgisayarların önyüklemesinde kullanılır.
Tftp'de kullanıcı kimlik dogrulaması için bir kural yoktur. Tftp dosya transferi yaparken okur ve yazar. Okuma ve yazma işlemi ile transfer başlar. Tftp transfer işlemi tftp sunucunun izin verdiği dizinde gerçekleşir.
Tftp sunucusu kurulumu için şu komutu kullanıyoruz:
$ sudo apt-get install tftpd-hpa
Tftp yapılandırmasını /etc/default/tftpd-hpa dosyasından yapıyoruz. Dosya içeriği şu şekildedir:
tftp_directory seçeneği ile istemcinin hangi dizin altından dosya alıp hangi dizin altına dosya göndereceğini belirliyorsunuz. Fakat burda önemli bir konu dizin izinleridir.
Bu yapılandırmaya göre kullanacağınız dizinin izinini 777 yapmalısınız.
$ sudo chmod -R 777 /srv/tftp
tftp-options ayarına eğer "--secure --create" seçeneğini eklemezseniz istemci /srv/tftp altında bulunmayan bir dosyayı bu dizine gönderme işlemi yapamaz. Sadece varolan dosyaların üstüne yazma işlemi yapabilir.
Tftp istemci kurulumu için:
$ sudo apt-get install tftp
Tftp bağlantısı için isterseniz alttaki ilk komutu kullanabileceğiniz gibi ikinci komut dizisini de kullanabilirsiniz.
$ tftp
$ connect "ip"
Tftp ile listeleme işlemi yapamıyorsunuz. Tftp de okuma ve yazma istegi ile transfer başladığı için aslında connect dediğimizde sunucuya bağlanma gibi bir işlem yapmış olmuyoruz. Hatta sunucunun 69. portundan cevap alıp alamayacağımızı get put işlemlerine kadar bilmiyoruz.
****put işlemini yaparken tftp sunucusuna koyacağınız dosyanında izni 777 olmalıdır. Ayrıca put işlemi yaparken göndermek istediğiniz dosya hangi dizinde ise o dizine gidip tftp bağlantısını o dizinde gerçekleştirmelisiniz.
Sftp de olduğu gibi ? ile hangi komutları kullanabiliceğimizi ve ne işe yaradıklarını görebiliyoruz.
Sftp, ssh kullanarak dosya transferi yapan bir dosya aktarım protokolüdür. Sftp ssh'ın sağladığı güvenlik özelliklerini kullanmış olur. Nerdeyse tüm linux dağıtımlarda stfp istemcisi ön tanımlı olarak gelir.
Sftp bağlantısını kurarken aynı ssh komutu gibi kullanıyoruz:
"$ sftp kullanıcı_adı@sftpserverip"
Eğer varsayılan port dışında bir port kullanılıyorsa, port numarasını -P parametresi ile birlikte vererek bağlantı sağlayabilirsiniz.
? işareti ile sftp için kullanabilceğimiz komutları ve ne işe yaradıklarını görebiliriz.
Sftp sunucusundan istemciye dosya almak için get , göndermek için put komutunu kullanıyoruz.
ls komutu ile sftp sunucusunda olduğumuz dizini listeleyebiliriz.
lls komutu ile de sftp istemcisinde olduğumuz dizini listeleriz.
Yukarıdaki resimde kullanabilceğimiz komutları görebilirsiniz.
TFTP
Tftp protokolü de dosya transferi için kullanılan basit bir protokoldur. 69.port üzerinden genellikle udp kullanılarak uygulanır. Kullanımı sırasında az bellek kullandığı için genelde yönlendirici bilgisayarların önyüklemesinde kullanılır.
Tftp'de kullanıcı kimlik dogrulaması için bir kural yoktur. Tftp dosya transferi yaparken okur ve yazar. Okuma ve yazma işlemi ile transfer başlar. Tftp transfer işlemi tftp sunucunun izin verdiği dizinde gerçekleşir.
Tftp sunucusu kurulumu için şu komutu kullanıyoruz:
$ sudo apt-get install tftpd-hpa
Tftp yapılandırmasını /etc/default/tftpd-hpa dosyasından yapıyoruz. Dosya içeriği şu şekildedir:
TFTP_USERNAME="tftp" TFTP_DIRECTORY="/srv/tftp" TFTP_ADDRESS="0.0.0.0:69" TFTP_OPTIONS="--secure"
tftp_directory seçeneği ile istemcinin hangi dizin altından dosya alıp hangi dizin altına dosya göndereceğini belirliyorsunuz. Fakat burda önemli bir konu dizin izinleridir.
Bu yapılandırmaya göre kullanacağınız dizinin izinini 777 yapmalısınız.
$ sudo chmod -R 777 /srv/tftp
tftp-options ayarına eğer "--secure --create" seçeneğini eklemezseniz istemci /srv/tftp altında bulunmayan bir dosyayı bu dizine gönderme işlemi yapamaz. Sadece varolan dosyaların üstüne yazma işlemi yapabilir.
Tftp istemci kurulumu için:
$ sudo apt-get install tftp
Tftp bağlantısı için isterseniz alttaki ilk komutu kullanabileceğiniz gibi ikinci komut dizisini de kullanabilirsiniz.
- $ tftp *.*.*.*(tftp sunucu ip)
$ tftp
$ connect "ip"
Tftp ile listeleme işlemi yapamıyorsunuz. Tftp de okuma ve yazma istegi ile transfer başladığı için aslında connect dediğimizde sunucuya bağlanma gibi bir işlem yapmış olmuyoruz. Hatta sunucunun 69. portundan cevap alıp alamayacağımızı get put işlemlerine kadar bilmiyoruz.
****put işlemini yaparken tftp sunucusuna koyacağınız dosyanında izni 777 olmalıdır. Ayrıca put işlemi yaparken göndermek istediğiniz dosya hangi dizinde ise o dizine gidip tftp bağlantısını o dizinde gerçekleştirmelisiniz.
Sftp de olduğu gibi ? ile hangi komutları kullanabiliceğimizi ve ne işe yaradıklarını görebiliyoruz.
17 Ekim 2017 Salı
Bilgisayar Mühendisliğini Nasıl Seçtim...
Bu sene hiç blog yazmadığımı farkettim. Tam da sürekli sınav sistemleri hakkında konuşulurken aklıma bu blog yazısını yazmak geldi. Bu yazı bölümü nasıl seçtiğimden çok nasıl sevmeye başladığımın hikayesi olacak aslında.
Türkiye'deki eğitim sistemini hepimiz biliyoruz. Öğrencilerin neye göre meslek seçimi yaptığı da çok aşikar bir şekilde ortada. Ben de onlardan biriyim aslında, bir sene daha hazırlanmak isteyip hocamın "Melike yapma yeterince çalıştın zaten, istediğin puanı yapamama nedeninin stres olduğunu biliyoruz ve ikinci sene hazırlanırsan daha çok stresli olacaksın" diyerek beni engellemesi sonucu tercih yaptım. Size, herkese inat tüm tercihlerimi inşaat mühendisliği yazıp sonra nasıl değiştirdiğimi hiç anlatmayayım :) Zaten Bilgisayar Mühendisliği mi yazacaksın kız kısmı o işi mi yapar öğretmenlik seç muhabbetlerini hiç anlatmıyorum. Çoğu kadın meslek seçimi yaparken böyle şeylere maruz kalıyor. Neyse bu başka bir konu...
Üniversiteye ilk başladığım sene hazırlık okumak istedim. Zorunlu değildi fakat benim hep böyle bir düşüncem vardı. Bir de bölüme isteyerek gelmemişim belki tekrar hazırlanır sınava girerim hayallerim vardı. Buna rağmen okula başladıktan sonra bölümle ilgili araştırma yapmaya başladım. Ne yapıyorlar bu bölüm neymiş nasıl işler yapıyorlarmış. Tabi bu sırada daha hazırlıktayken Necdet hoca hakkında rivayetler duyuyorsunuz "of bir hoca varmış dersini kimse veremiyormuş 10 sene alanlar bile varmış :) "gibi. Bu da sizi biraz fazla korkutuyor açıkçası, zaten üst sınıflarda bunu bilerek yapıyorlar :) Neyse ben korkunun ecele faydası yok diyerek araştırmaya devam ettim. Bölümü araştırdıkça ilgimi çekmeye başladı. GNU/Linux' u hazırlıktayken duymuş ve bilgisayarıma Gnu/linux dağıtımı olan Ubuntu'yu kurmuştum. Linux maceramın son kullanıcı bazlı kullanımı hazırlık seneme dayanır. Daha sonra ikinci yarıyıl zamanıydı yapısal programlama dersine gitmeye karar verdim. Gidip kodlama da neler yapıyorlar görmek istedim. O derse gidene kadar bir satır bile kodlama yapmamış, algoritmanın a'sını bile bilmeyen biriydim.
Derse girdim Mustafa hoca veriyordu sanırım o yıl dersi. Tahtada matrisleri anlatıyordu. Ben de "tamam ya bu bizim matrisler" diyorum. Sonra kodlama kısmına gelindi matrislerle ilgili kodlama kısmından bahsedip yine onla ilgili başka bir kodu yazmamızı istedi. Ben de oturmuşum bilgisayar başına açmışım ide'yi deniycem, sanki daha önce kodlama görmüşüm edasıyla:) Şaka maka yazdım gerçekten derlendi de, ben hala ihtimal vermiyorum tabi doğru olduğuna. Hocayı çağırdık, kontrol etti "evet doğru yapmışsın değişkenin adını d yap tamamdır " dedi. Değişken mi o_0 :)
O gün yaşadığım heyecanı, mutluluğu size anlatamam. O gün düşündüğüm ilk şey "kızlar niye yapamasın, Melike sen bu bölümü okursun çok da güzel yaparsındı". Tabi kendimi biraz fazla gaza getirmiş de olabilirim, "ne var bunda herkes kodlama yapabilir" de diyor olabilirsiniz ama benim o gün hissettiğim umut bu bölümü sevmeme ve bilgisayar mühendisi olmama sebep olmuştur. Şimdi çok mutluyum bu bölümü okumuş olmaktan.
Bu okuduğum dört sene içinde öğrendiğim bir şey var ki; belki bir bölümü sevmeden öyle ya da böyle okuyabilirsiniz fakat o işi yaparken lanetler okursunuz. Hatta Libreoffice'e katkı verirken birinin bir yorumunu duymuştum. Yanlış hatırlamıyorsam "işsizler ondan bunla uğraşıyorlar" tarzında bir cümleydi sanırım. Duyduğumda söylediğim bir şey vardı. Gerçekten haklı olduğu bir nokta var; yaptığınız işi seviyorsanız o sizin için iş olmaktan çıkıyor bir hobi oluyor.
Ben şanslıydım. Çok sevdiğim bir bölümü çok sevdiğim, hakkında rivayetler duyduğum ":)" hocamla birlikte çalışarak bitirdim. Benim kadar şanslı olamayabilirsiniz bu yüzden Türkiye'de neler değişirse değişsin, size kim ne derse desin mesleğinizi seçerken iyi düşünün.
Türkiye'deki eğitim sistemini hepimiz biliyoruz. Öğrencilerin neye göre meslek seçimi yaptığı da çok aşikar bir şekilde ortada. Ben de onlardan biriyim aslında, bir sene daha hazırlanmak isteyip hocamın "Melike yapma yeterince çalıştın zaten, istediğin puanı yapamama nedeninin stres olduğunu biliyoruz ve ikinci sene hazırlanırsan daha çok stresli olacaksın" diyerek beni engellemesi sonucu tercih yaptım. Size, herkese inat tüm tercihlerimi inşaat mühendisliği yazıp sonra nasıl değiştirdiğimi hiç anlatmayayım :) Zaten Bilgisayar Mühendisliği mi yazacaksın kız kısmı o işi mi yapar öğretmenlik seç muhabbetlerini hiç anlatmıyorum. Çoğu kadın meslek seçimi yaparken böyle şeylere maruz kalıyor. Neyse bu başka bir konu...
Üniversiteye ilk başladığım sene hazırlık okumak istedim. Zorunlu değildi fakat benim hep böyle bir düşüncem vardı. Bir de bölüme isteyerek gelmemişim belki tekrar hazırlanır sınava girerim hayallerim vardı. Buna rağmen okula başladıktan sonra bölümle ilgili araştırma yapmaya başladım. Ne yapıyorlar bu bölüm neymiş nasıl işler yapıyorlarmış. Tabi bu sırada daha hazırlıktayken Necdet hoca hakkında rivayetler duyuyorsunuz "of bir hoca varmış dersini kimse veremiyormuş 10 sene alanlar bile varmış :) "gibi. Bu da sizi biraz fazla korkutuyor açıkçası, zaten üst sınıflarda bunu bilerek yapıyorlar :) Neyse ben korkunun ecele faydası yok diyerek araştırmaya devam ettim. Bölümü araştırdıkça ilgimi çekmeye başladı. GNU/Linux' u hazırlıktayken duymuş ve bilgisayarıma Gnu/linux dağıtımı olan Ubuntu'yu kurmuştum. Linux maceramın son kullanıcı bazlı kullanımı hazırlık seneme dayanır. Daha sonra ikinci yarıyıl zamanıydı yapısal programlama dersine gitmeye karar verdim. Gidip kodlama da neler yapıyorlar görmek istedim. O derse gidene kadar bir satır bile kodlama yapmamış, algoritmanın a'sını bile bilmeyen biriydim.
Derse girdim Mustafa hoca veriyordu sanırım o yıl dersi. Tahtada matrisleri anlatıyordu. Ben de "tamam ya bu bizim matrisler" diyorum. Sonra kodlama kısmına gelindi matrislerle ilgili kodlama kısmından bahsedip yine onla ilgili başka bir kodu yazmamızı istedi. Ben de oturmuşum bilgisayar başına açmışım ide'yi deniycem, sanki daha önce kodlama görmüşüm edasıyla:) Şaka maka yazdım gerçekten derlendi de, ben hala ihtimal vermiyorum tabi doğru olduğuna. Hocayı çağırdık, kontrol etti "evet doğru yapmışsın değişkenin adını d yap tamamdır " dedi. Değişken mi o_0 :)
O gün yaşadığım heyecanı, mutluluğu size anlatamam. O gün düşündüğüm ilk şey "kızlar niye yapamasın, Melike sen bu bölümü okursun çok da güzel yaparsındı". Tabi kendimi biraz fazla gaza getirmiş de olabilirim, "ne var bunda herkes kodlama yapabilir" de diyor olabilirsiniz ama benim o gün hissettiğim umut bu bölümü sevmeme ve bilgisayar mühendisi olmama sebep olmuştur. Şimdi çok mutluyum bu bölümü okumuş olmaktan.
Bu okuduğum dört sene içinde öğrendiğim bir şey var ki; belki bir bölümü sevmeden öyle ya da böyle okuyabilirsiniz fakat o işi yaparken lanetler okursunuz. Hatta Libreoffice'e katkı verirken birinin bir yorumunu duymuştum. Yanlış hatırlamıyorsam "işsizler ondan bunla uğraşıyorlar" tarzında bir cümleydi sanırım. Duyduğumda söylediğim bir şey vardı. Gerçekten haklı olduğu bir nokta var; yaptığınız işi seviyorsanız o sizin için iş olmaktan çıkıyor bir hobi oluyor.
Ben şanslıydım. Çok sevdiğim bir bölümü çok sevdiğim, hakkında rivayetler duyduğum ":)" hocamla birlikte çalışarak bitirdim. Benim kadar şanslı olamayabilirsiniz bu yüzden Türkiye'de neler değişirse değişsin, size kim ne derse desin mesleğinizi seçerken iyi düşünün.
2 Kasım 2016 Çarşamba
Libreoffice Çalışmalarım-2
Herkese merhaba,
Üçüncü sınıftayken Libreoffice katkı vermeye başlamış, 13 kişilik bir ekiple birlikte çalışmıştım. Çok güzel işler yaptık ve daha önceki blog yazılarımda bu işlerden bahsetmiştim. Dördüncü sınıfta da Libreoffice katkı vermeye devam ediyorum.
Hakkında blog yazdığım Libreoffice Math aracı ile ilgili çalışmamdan sonra Libreoffice'ın bir çok farklı işleriyle ilgili katkı verdim. Bunlar hakkında özel blog yazıları yazmamıştım. Bu yıl ilk kabul edilen yamamla birlikte şimdi neler yaptığımla ilgili kısaca yazmış olmak istedim.
Bu yılın kabul edilen ilk yamasında arka planda kod iyileştirmesi yaptım. Daha önce uğraşmadığım bir iş olan makro fonksiyonlarla çalıştım. Yeni bir makro fonksiyon tanımlaması ve kullanımıyla ilgili bir iş yaptım. Bir süre daha makrolarla ilgili çalışmaya devam edeceğim.
Söylemeden geçemeyeceğim bir şey var ki; yazın stajda ELK, elastalert ve docker üzerine yaptığım çalışmalardan sonra tekrar "It has been merged to LibreOffice." yazan mailin sevincini yaşamak güzel bir duyguydu :)
Bu senede +Necdet hocamın yön göstermesi ile daha güzel işler yapacağım ve size de güzel haberler vereceğim :)
Üçüncü sınıftayken Libreoffice katkı vermeye başlamış, 13 kişilik bir ekiple birlikte çalışmıştım. Çok güzel işler yaptık ve daha önceki blog yazılarımda bu işlerden bahsetmiştim. Dördüncü sınıfta da Libreoffice katkı vermeye devam ediyorum.
Hakkında blog yazdığım Libreoffice Math aracı ile ilgili çalışmamdan sonra Libreoffice'ın bir çok farklı işleriyle ilgili katkı verdim. Bunlar hakkında özel blog yazıları yazmamıştım. Bu yıl ilk kabul edilen yamamla birlikte şimdi neler yaptığımla ilgili kısaca yazmış olmak istedim.
Bu yılın kabul edilen ilk yamasında arka planda kod iyileştirmesi yaptım. Daha önce uğraşmadığım bir iş olan makro fonksiyonlarla çalıştım. Yeni bir makro fonksiyon tanımlaması ve kullanımıyla ilgili bir iş yaptım. Bir süre daha makrolarla ilgili çalışmaya devam edeceğim.
Söylemeden geçemeyeceğim bir şey var ki; yazın stajda ELK, elastalert ve docker üzerine yaptığım çalışmalardan sonra tekrar "It has been merged to LibreOffice." yazan mailin sevincini yaşamak güzel bir duyguydu :)
Bu senede +Necdet hocamın yön göstermesi ile daha güzel işler yapacağım ve size de güzel haberler vereceğim :)
5 Ağustos 2016 Cuma
On İki Faktör Uygulaması
12 Faktör uygulamasının hizmet olarak yazılım uygulamalarını oluşturmak için metodolojisi vardır:
Bu belgeye katkı veren kişiler doğrudan ilgili geliştiriciler, yüzlerce uygulama geliştirmiş, tanıklık etmiş ve heroku platformun da çalışmalarda geliştirme yapmıştır. Bu döküman, katkıcıların deneyim ve gözlemlerini sentezler. Katkıcıların amacı modern yazılım geliştirmede gördükleri sorunların bilincini arttırmak, sorunları tartışıp ortak ve kavramsal bir çözüm sağlamaktır.
Herhangi bir çalışan uygulama geliştiren mühendisler okumalıdır.
Bir codebase bir çok uygulamanın sürüm kontrolünü incelemektedir. 12 faktör uygulaması her zaman sürüm kontrol sisteminde izlenir, Git , Mermcurial, Subversion gibi. Sürüm takip, kod tabanının bir kopyası, kod deposu olarak bilinir. Bir codebase herhangi tek bir depo(Subverison) ya da kökü paylaşan bir dizi depodur(Git).
Codebase ile uygulama arasında bire bir ilişki her zaman vardır:
Birden fazla codebase varsa bu bir uygulama değil dağıtık sistemdir. Dağıtık sistemin her birleşeni bir uygulama olup on iki faktöre uygun olmalıdır.
Aynı kodu paylaşan birden fazla uygulama on iki faktörü ihlal eder. Çözüm paylaşılan kodları kütüphane ile dahil etmek olabilir.
Uygulamanın sadece bir codebase vardır fakat birden fazla dağıtımı olacaktır. Bir dağıtım uygulamanın çalışan bir örneğidir. Ayrıca her geliştiricinin kendi yerel geliştirme ortamında çalışan bir kopyası vardır, her biri aynı zamanda dağıtım olarak nitelendirilirler.
Sürümler her bir dağıtımda etkin olabilir fakat kod temeli tüm dağıtımlrda aynıdır. Örneğin geliştiricilerin henüz uygulamaya eklenmemiş commitleri olabilir. Bu nedenle hepsi ayrı dağıtım olarak tanımlanır ama kod temeli aynıdır.
2) Dependencies(Bağımlılıklar)
Çoğu programlama dili yardım kütüphaneleri dağıtımı için paketleme sistemi sunuyor. Paketleme sistemi sayesinde yüklenen kütüphaneler sistem geneline yüklenir ya da uygulamayı içeren dizinlerdir. Tüm bağımlılılar açıkça bağımlılık bildirimi yoluyla, apacık ve kesin olarak bildirilirler. Ayrıca çevreleyen sistemden itibaren açık bağımlılıkları için uygulama sırasında bir bağımlılık aracı kullanılır. Tam ve açık şartname uygulama ve geliştirmede eşit uygulanır.
Ne olursa olsun araç zinciri, bağımlılık beyanı ve izolasyon her zaman birlikte kullanılmalıdır. Sadece biri on iki faktörü karşılamak için yeterli değildir.
Açık bağımlılık bildiriminin yararlarından biri de yeni geliştiriciler için kurulumu kolaylaştırmasıdır. Yeni geliştiriciler onların geliştirme makineleri üzerinde, uygulama codebase çıktısını kontrol eder, bağımlılık yöneticisi ön koşulları yükler ve sadece çalışma zamanını zorunlu tutar.
3) Config (Yapılandırma)
Bir uygulama yapılandırması çeşitli dağıtımlar arasındaki farklılıkların muhtemel hepsidir. Bunları içerir:
Uygulamaların bazen koddaki depo yapılandırmaları sabittir. Bu on iki faktöru ihlal eder, bu yapılandırma koddan ayrılmalıdır. Bir turnusol testi için uygulamanın faktor çıktılarının doğru yapılandırılıp yapılandırılmaması, kodun codebasenin herhangi bir zamanda kimlikten ödün vermeden açık kaynak kodlu olup olmadığıdır.
Bu bildirim yapılandırması uygulama içindeki yapılandırmaya dahil edilmez. Yapılandırma dağıtımlar arasında değişmez ve en iyi kod yazılır. Başka bir yaklaşım ise yapılandırma dosyaları kullanılmasıdır örneğin Rails de "config/database.yml" . Bu depo sabitleri kullanarak üzerinde büyük bir değişiklik olduğunda kontrol edilir, ancak yine de zayıflıklar vardır. Yapılandırmayı yönetmek için yapılandırma dosyalarının farklı yerlerde ve farklı biçimlerde olması için bir eğilim vardır. Bundan başka dile veya yapıya özel olma eğilimi vardır.
On iki faktör uygulaması depoları çevre değişkenleri olarak yapılandırılır. Kod değiştirmeden dağıtım arasında geçiş yapmak yapılandırma dosyalarının aksine kolaydır.
Yapılandırma yönetiminin bir diğer yönü gruplandırmadır. Ortamlar olarak gruplandırılır fakat bağımsız olarak her dağıtım için yönetilir. Bu yöntem sorunsuz olarak doğal ömrü boyunca daha fazla dağıtımla genişler.
4) Backing Service(Destek Hizmeti)
Bir destek uygulaması herhangi bir uygulama ağ bölümlerinde, normal işlem üzerinden daha fazla tüketilir. Örneğin, stmp hizmetleri, ön belleğe alma sistemleri, kuyruk sistemleri. Veri tabanı gibi yardım sistemleri bazı sistem yöneticileriyle geleneksel olarak yönetilmeli, uygulama gerçek zamanlı dağıtılmlıdır. Bu yerel yönetim hizmetlerine ek olarak, uygulama aynı zamanda üçüncü şahıslar tarafından sağlanan ve yönetilen servisler olabilir. Örneğin Api, stmp hizmetleri, google maps...
On iki faktör uygulaması için kod yerel ve üçüncü taraf hizmetleri arasında bir ayrım yapmamaktadır. Uygulama da yapılandırma içinde her ikisi de kaynaklara bağlı, url bağlama yolu ya da kimlik saklama ile olmalıdır. On iki faktör uygulamasında bir dağıtım, uygulamanın kodunda herhangi bir değişiklik olmadan üçüncü bir uygulama tarafından yönetilen tek bir yerel MySql veritabanı takası gerektirir. Aynı şekilde bir yerel Stmp sunucusu kod değişikliği olmadan bir üçüncü uygulama Stmp hizmeti ile takas olabilir. Her iki durumda da yapılandırma da sadece kaynak tanıtıcı değiştirilmelidir. Her ayrı destek hizmeti bir kaynaktr. Kaynaklar eklenir ve istediği zaman ayrılabilir.
5) Build,Release,Run(Derle, Sürüm ,Çalıştır)
Bir kod tabanında değişim üç aşamadan oluşur:
12 faktör uygulaması bu aşamalar arasında katı bir ayrım kullanır. Örneğin zamanında kod değişikliği yapmak mümkün değildir çünkü build aşamasındaki değişiklikleri yaymak için bir yol yoktur. Dağıtım araçları, genellikle sürüm yönetim araçları, bir önceki sürüme almak için olanak sağlar.
Örneğin Capistrano dağıtım aracı sürümleri releases dizini altında tutar, şimdiki sürümü current release dizininde tutar. Geri dönüşü de rollback komutu ile hızlıca sağlar.
Her sürüm her zaman eşsiz bir sürüm id'sine sahip olmalıdır. Herhangi bir değişiklikte yeni bir sürüm oluşturmanız gerekir.
Yeni kod dağıtıldığında her uygulamanın geliştiricileri tarafından build başlatılır. Çalışma zamanlı uygulamalar karşılaştırılmalara göre reboot hizmeti durumunu otomatik yapabilir ya da davetsiz bir süreç, süreç yöneticisi tarafından başlatılabilir. Bu nedenle çalışma aşamasında mümkün olduğunca az hareketli parça tutulmalı, geliştirici elle yapmadığında gece olan kırılmalar uygulama çalışırken önlenir. Dağıtıma sürülen hatalar geliştiriciler için daha önemli olduğundan build aşaması karmaşık olabiliyor.
6) Processes(Süreçler)
Uygulama bir veya daha fazla işlem olarak yürütme ortamında yürütülür. En basit durumda kod bir stand-alone script ile yürütme ortamı bir geliştirici yerel dil çalıştırma ile ve süreç komut satırı ile başlatılabilir.
On iki faktör süreçleri durum bilgisi olmayan, paylaşımdan başka bir şey değildir. Süreklilik gerektiren bir veri bir durum bilgisi olan destek hizmeti, tipik bir veritabanında saklanmalıdır.
Sürecin bellek alanı veya bir dosya sistemi özeti tek aktarımlı önbellek olarak kullanılır. Örneğin büyük bir dosya indirirken üzerinde faaliyet gösteren işlemleri ve veritabanındaki işlemin sonuçlarını saklamak. On iki faktör uygulaması bellek veya disk üzerinden önbelleğe aldıklarını bir iş gelecek veya zaten var olduğunu varsayar. Tek bir süreç çalışırken yeniden başlatma genellikle tüm yereli silecektir.
Varlık paketleyici derlenmiş varlıklar için önbellek olarak dosya sistemi kullanır.
7) Port Binding(Port Bağlamı)
Web uygulamaları bazen bir web sunucusu container'ı içinde yürütülür. Örneğin php uygulamaları apache içinde bir modül olarak çalışabilir veya java uygulamaları Tomcat içinde çalışabilir.
On iki faktör uygulaması tamamen kendi kendine yeter. Bir web uygulaması port bağlayıcısı tarafından servis olarak http ile dışa aktarır ve port üzerinden gelen istekleri dinler.
Bir yerel geliştirme ortamında, geliştiriciler dışa aktarılan servislere erişmek için Url gibi örneğin "http://localhost:5000/" ziyaret ederler. Dağıtımda bir yönlendirme katmanı, port-bound web işlemlerine göre, public-facing ana makineden itibaren yönlendirme isteklerini işler.
Bu tipik uygulama kullanılan bağımlılık bildirimleri tarafından web-server kütüphanelerine eklenir. Bu durum kullanıcı alanında uygulama kodunun içindedir. Yürütme ortamı ile sözleşme istekleri hizmet için bir bağlantı noktasıdır.
Http yalnızca servis değil, port bağlayıcıları tarafından dışa aktarılır. Neredeyse her tür yazılım servisleri için porta göre süreç bağlayıcıları üzerinde çalışır ve gelen istekleri bekler.
Port bağlama yaklaşımının anlamı; tüketen uygulamalar için yapılandırmada cevap olarak işlenen destek uygulamaları ile birlikte, Url sağlayıcıları tarafından bir uygulama, diğer uygulamalar için servis bağlayıcısı olmalıdır.
8) Concurrency(Eş zamanlılık)
Bir bilgisayar programı çalıştırıldığında bir veya bir çok süreç ile temsil edilir. Web uygulamaları süreç yürütme biçimlerinde çeşitlidir. Örneğin Php süreçleri apache için çocuk süreçler çalıştırılır, istek değerleri tarafından gerektiğinde başlatma talep eder. Java süreçleri ters yaklaşım kabul etmektedir. Her iki durumda da çalışan süreçler uygulamalar için geliştiricilere göre minimal görünür.
On iki faktör uygulamasında süreçler birinci sınıf vatandaşlardır. On iki faktör uygulaması süreç servislerini çalıştırmak için unix süreç modellerinden güçlü ipuçları alır. Kullanılan bu model de çalışan süreç tipleri için belirtilen her bir tip tarafından çeşitli iş yükü kullanımına göre diğer uygulamaları planlar. Bu tür bireysel süreçler kendi iç dışlama kullanılarak dışa aktarılmaz, thread üzerinde bulunan çalışma zamanlı VM kullanılır ama bireysel VM çok büyüyebilir, bu nedenle çoklu fiziksel makine üzerindeki bir çok süreci kapsamalıdır. On iki faktör uygulamalarının daha eşzamanlı basit ve güvenirlir bir işlem olduğu anlamına gelir. Bu dizi süreç tipleri için ve her tip süreç numarası için tip formatı olarak biliniyor.
On iki faktör uygulaması süreçleri bekletmez ve PID dosyasına yazmaz. Bunun yerine, çıktı akışlarını yönetmek için işletim sisteminin süreç yöneticisine güvenir, çöken süreçlere cevap verir, kullanıcı üyeliği kabul edilmiş kullanıcı tarafından yeniden başlatılır ve kapatılabilir.
9) Disposability(Kullanıma Hazır Olma Durumu)
Hızlı başlatma ve zarif kapama ile sağlamlık seviyesini en üst düzeye çıkarmak. On iki faktör uygulaması süreçleri kullanıma hazır olmalı, amaç bir anlık bildirimle başlatmak ya da bitirmek. Bu hızlı ölçekleme kod için geliştirimi ve yapılandırma değişikliğini kolaylaştırır ve üretim dağıtımı için sağlamlığı kolaylaştırır. Süreçlerin başlatma süresini en aza indirmek için çaba gerekir. İdeal olarak, süreçlerin bir süre için, sürecin yükselmesine kadar, komut başlatması gerekir ve işlemleri karşılamak için hazırlık zaman almaktadır. Süreci bırakmak, yükseltmek ve yardım sağlamak için kısa başlama süresi atiklik sağlayacak. Çünkü süreç yöneticisi izin verdiğinde yeni fiziksel makineler için süreç hareketi kolaylaşacak. Süreç işlem yöneticisinden SIGNTERM sinyali aldığında duracaktır.
Web süreçlerinde zarif kapatma, port servisleri üzerinde dinleme kesilmesiyle elde edilir, herhangi bir geçerli istek, bitirmek için izin verir ve kapatır.
Çalışan süreç için zarif kapatma, çalışma sırasına göre şimdiki işi dönderme ile elde eder.
Süreçler donanımda bir arıza olması durumunda ani kesilmelere karşı güçlü olmalıdır. Bu SIGTERM ile zarif kapatmada çok daha az sık rastlanan bir durum olmasına rağmen olabilir. Sağlam bir kuyruk olan arka uç kullanılmalıdır. Her iki durumda da, on iki faktör uygulaması beklenmedik işlemleri, zarif olmayan kapanışları planlar. Crash-only tasarım mantıksal sonucuna göre bu kavramı ele alır.
10) Dev/prod parity
Tarihle ilgili ürün ve geliştirme arasında önemli boşluklar oluşmuştur. Bu boşluklar üç alanda gerçekleşir:
On iki faktör uygulaması üretim ile dağıtım arasındaki boşluğu tutarak sürekli dağıtım için tasarlanmıştır. Bu üç boşluğa baktığımız da:
Tabloyla özetlemek gerekirse:
Geleneksel uygulama 12 Faktör uygulaması
Dağıtım arasındaki zaman Hafta Saat
Kod yazarları ve kod dağıtıcıları Farklı kisiler Aynı kişiler
Üretim ve geliştirme ortamı Farklı Mümkün olduğunca benzer
Yedekleme hizmeti, veritabanı, kuyruk sistemi ya da önbellek /dev/prod da önemli bir alandır. Bir çok dil yardım hizmetlerine erişimi kolaylaştırmak için kütüphaneler sunar. Bazı geliştiriciler üretimde daha güçlü ve ciddi yardım hizmetlerini kullanmak için yereldeki hafif destek hizmetlerine başvuruyorlar.
12 faktör uygulamaları geliştirme ve dağıtım arasındaki farklı yardım hizmetlerine karşıdır. Destek hizmetleri arasındaki farklılıklar geliştirilirken kod çalıştırma ve test etme bağlantıları kesebilir ya da üretimde fail verebilir. Bu uygulamanın ömrü boyunca düşünüldüğünde maliyeti oldukça artırır.
Hafif yerel destek hizmetleri daha az zorlayıcıdır. Modern yardım hizmetlerinin yüklemesi ve çalıştırması modern paketleme sistemleri sayesinde zor değildir, apt gibi. Bu sistemlerin kurulması ve kullanılmasının maliyeti "dev/prod" bölümü ve sürekli dağıtım yararına oranla düşüktür.
Yeni destek hizmetlerine geçiş yapmak için hala farklı yardım hizmetlerinin uyarlayıcıları kullanılıyor. Fakat tüm dağıtım uygulamalarının kullandıkları tip ve versiyon her bir yardım sistemi için aynı olmalı.
11)Logs (Kayıtlar)
Olay akışlarının işlenmesidir.
Loglar çalışan bir uygulamanın davranışlarında görünürlük sağlar. Sunucu tabanlı ortamlarda genellikle diskteki bir dosyaya yazılır fakat bu sadece bir çıkış yöntemidir. Loglar çalışan süreçlerin ve yardım hizmetlerinin zamanla bağlantılı olay akışlarının toplamıdır. Logların sabit başlangıcı ve sonu yoktur, uygulama çalışırken sürekli akış olur.
12 faktör uygulaması asla çıktı akışını yönelendirme ve depolamayla ilgilenmez. Yazmamalı veya log dosyası yönetmeye kalkışmamalısınız. Bunun yerine, her çalışan süreç olay akışını stduo ile yazıyor. Yerel geliştirme sırasında, uygulama davranışlarını kendi terminalinde gözlemlemek için akışları ön plan da izler. Her işlem akışı ele alınır çevre ortamları tarafından, diğer uygulama akışlarıyla birlikte karşılaştırılır ve arşivlerde görüntülemek üzere nakledilir. Bu hedef arşiv uygulama tarafından görünür veya yapılandırılabilir değildir. Onun yerine uygulama ortamı tarafından tamamen işlenir. Açık kaynak yönlendiricileri bu amaçla kullanılır(Logplex).
Bir uygulama için olay akışı bir dosyaya yönlendirilebilir veya bir terminalde zamanlı kuyruk üzerinden izlenebilmektedir. En önemlisi, akış bir günlük indeksleme ve analiz sistemine gönderilebilir. Bu sistemler uygulamanın zamana bağlı davranışlarını ölçmek için büyük güç ve esneklik sağlar:
12) Admin Proccess( Yönetici süreci )
Bir defaya mahsus admin yönetici görevlerini çalıştırmak.
Süreç oluşumu uygulamanın düzenli iş yapması için kullanılan süreç dizisidir. Ayrı olarak, geliştiriciler yönetimi ve bakımını bir defaya mahsus yapmak isterler:
Bir kerelik yönetici işlemleri, uygulamanın düzenli uzun soluklu süreçleri olarak özdeş bir ortamda çalıştırılmalıdır. Çalışan bir sürüme karşı herhangi bir işlem, sürüme dayalı olarak yapılandırılmalı ve benzer kod tabanı kullanılmalıdır. Yönetici Kod senkronizasyon sorunlarını önlemek için uygulama kodu ile göndermeniz gerekir.
Aynı bağımlılık izolasyon teknikleri tüm süreç türlerinde kullanılmalıdır. Örneğin eğer ruby web servisleri bundle exec thin start komutunu kullanıyorsa, veritabanı göçü içinde bundle exec rake db:migrate kullanmalıdır.
12 faktör bir Repl kabuk çıktısında kutular için güçlü dil desteği sağlar bir defaya mahsus. Yerel dağıtımlarda, geliştiriciler uygulamanın çıkış dizini içinde doğrudan kabuk komutu ile tek seferlik yönetici işlemleri başlatırlar. Bir ürün dağıtımında geliştiriciler ssh veya diğer uzak komut erişim mekanizmalarını böyle bir işlemi başlatmak için kullanırlar.
- Ayar otomasyonu için bildirim formatları kullanır, projeye katılan yeni geliştiriciler için zaman ve maliyeti aza indirmek için.
- Yürütme ortamları arasında maksimum taşınabilirlik sunan temel işletim sistemi ile clean contract vardır.
- Modern bulut platformları üzerindeki dağıtım için uygun, sunucu ve sistem yönetimi ihtiyacını ortadan kaldırır.
- Maksimum çeviklik için sürekli dağıtım sağlayan geliştirme ve üretim arasındaki ayrışmayı en aza indirir,
- Ve önemli değişiklikler dışında, mimari ve geliştirici uygulamaları düzeyinde ölçeklendirilebilir.
Bu belgeye katkı veren kişiler doğrudan ilgili geliştiriciler, yüzlerce uygulama geliştirmiş, tanıklık etmiş ve heroku platformun da çalışmalarda geliştirme yapmıştır. Bu döküman, katkıcıların deneyim ve gözlemlerini sentezler. Katkıcıların amacı modern yazılım geliştirmede gördükleri sorunların bilincini arttırmak, sorunları tartışıp ortak ve kavramsal bir çözüm sağlamaktır.
Herhangi bir çalışan uygulama geliştiren mühendisler okumalıdır.
12 FAKTÖR
1) Codebase(Kod Tabanı)Bir codebase bir çok uygulamanın sürüm kontrolünü incelemektedir. 12 faktör uygulaması her zaman sürüm kontrol sisteminde izlenir, Git , Mermcurial, Subversion gibi. Sürüm takip, kod tabanının bir kopyası, kod deposu olarak bilinir. Bir codebase herhangi tek bir depo(Subverison) ya da kökü paylaşan bir dizi depodur(Git).
Codebase ile uygulama arasında bire bir ilişki her zaman vardır:
Birden fazla codebase varsa bu bir uygulama değil dağıtık sistemdir. Dağıtık sistemin her birleşeni bir uygulama olup on iki faktöre uygun olmalıdır.
Aynı kodu paylaşan birden fazla uygulama on iki faktörü ihlal eder. Çözüm paylaşılan kodları kütüphane ile dahil etmek olabilir.
Uygulamanın sadece bir codebase vardır fakat birden fazla dağıtımı olacaktır. Bir dağıtım uygulamanın çalışan bir örneğidir. Ayrıca her geliştiricinin kendi yerel geliştirme ortamında çalışan bir kopyası vardır, her biri aynı zamanda dağıtım olarak nitelendirilirler.
Sürümler her bir dağıtımda etkin olabilir fakat kod temeli tüm dağıtımlrda aynıdır. Örneğin geliştiricilerin henüz uygulamaya eklenmemiş commitleri olabilir. Bu nedenle hepsi ayrı dağıtım olarak tanımlanır ama kod temeli aynıdır.
2) Dependencies(Bağımlılıklar)
Çoğu programlama dili yardım kütüphaneleri dağıtımı için paketleme sistemi sunuyor. Paketleme sistemi sayesinde yüklenen kütüphaneler sistem geneline yüklenir ya da uygulamayı içeren dizinlerdir. Tüm bağımlılılar açıkça bağımlılık bildirimi yoluyla, apacık ve kesin olarak bildirilirler. Ayrıca çevreleyen sistemden itibaren açık bağımlılıkları için uygulama sırasında bir bağımlılık aracı kullanılır. Tam ve açık şartname uygulama ve geliştirmede eşit uygulanır.
Ne olursa olsun araç zinciri, bağımlılık beyanı ve izolasyon her zaman birlikte kullanılmalıdır. Sadece biri on iki faktörü karşılamak için yeterli değildir.
Açık bağımlılık bildiriminin yararlarından biri de yeni geliştiriciler için kurulumu kolaylaştırmasıdır. Yeni geliştiriciler onların geliştirme makineleri üzerinde, uygulama codebase çıktısını kontrol eder, bağımlılık yöneticisi ön koşulları yükler ve sadece çalışma zamanını zorunlu tutar.
3) Config (Yapılandırma)
Bir uygulama yapılandırması çeşitli dağıtımlar arasındaki farklılıkların muhtemel hepsidir. Bunları içerir:
- Kaynak veritabanı, Memcached ve diğer destek hizmetleri kolları
- Dış hizmetlerin(twitter, amazon gibi) kimlik bilgileri
- Dağıtım için dağıtıma göre standart hostname
Uygulamaların bazen koddaki depo yapılandırmaları sabittir. Bu on iki faktöru ihlal eder, bu yapılandırma koddan ayrılmalıdır. Bir turnusol testi için uygulamanın faktor çıktılarının doğru yapılandırılıp yapılandırılmaması, kodun codebasenin herhangi bir zamanda kimlikten ödün vermeden açık kaynak kodlu olup olmadığıdır.
Bu bildirim yapılandırması uygulama içindeki yapılandırmaya dahil edilmez. Yapılandırma dağıtımlar arasında değişmez ve en iyi kod yazılır. Başka bir yaklaşım ise yapılandırma dosyaları kullanılmasıdır örneğin Rails de "config/database.yml" . Bu depo sabitleri kullanarak üzerinde büyük bir değişiklik olduğunda kontrol edilir, ancak yine de zayıflıklar vardır. Yapılandırmayı yönetmek için yapılandırma dosyalarının farklı yerlerde ve farklı biçimlerde olması için bir eğilim vardır. Bundan başka dile veya yapıya özel olma eğilimi vardır.
On iki faktör uygulaması depoları çevre değişkenleri olarak yapılandırılır. Kod değiştirmeden dağıtım arasında geçiş yapmak yapılandırma dosyalarının aksine kolaydır.
Yapılandırma yönetiminin bir diğer yönü gruplandırmadır. Ortamlar olarak gruplandırılır fakat bağımsız olarak her dağıtım için yönetilir. Bu yöntem sorunsuz olarak doğal ömrü boyunca daha fazla dağıtımla genişler.
4) Backing Service(Destek Hizmeti)
Bir destek uygulaması herhangi bir uygulama ağ bölümlerinde, normal işlem üzerinden daha fazla tüketilir. Örneğin, stmp hizmetleri, ön belleğe alma sistemleri, kuyruk sistemleri. Veri tabanı gibi yardım sistemleri bazı sistem yöneticileriyle geleneksel olarak yönetilmeli, uygulama gerçek zamanlı dağıtılmlıdır. Bu yerel yönetim hizmetlerine ek olarak, uygulama aynı zamanda üçüncü şahıslar tarafından sağlanan ve yönetilen servisler olabilir. Örneğin Api, stmp hizmetleri, google maps...
On iki faktör uygulaması için kod yerel ve üçüncü taraf hizmetleri arasında bir ayrım yapmamaktadır. Uygulama da yapılandırma içinde her ikisi de kaynaklara bağlı, url bağlama yolu ya da kimlik saklama ile olmalıdır. On iki faktör uygulamasında bir dağıtım, uygulamanın kodunda herhangi bir değişiklik olmadan üçüncü bir uygulama tarafından yönetilen tek bir yerel MySql veritabanı takası gerektirir. Aynı şekilde bir yerel Stmp sunucusu kod değişikliği olmadan bir üçüncü uygulama Stmp hizmeti ile takas olabilir. Her iki durumda da yapılandırma da sadece kaynak tanıtıcı değiştirilmelidir. Her ayrı destek hizmeti bir kaynaktr. Kaynaklar eklenir ve istediği zaman ayrılabilir.
5) Build,Release,Run(Derle, Sürüm ,Çalıştır)
Bir kod tabanında değişim üç aşamadan oluşur:
- Build aşaması: yapı olarak bilinen bir yürütülebilir paket içini bir kod deposuna dönüştürür.
- Release aşaması: Build aşamasında oluşturulan yapıyı alır ve dağıtmak için mevcut yapılandırma ile birleştirir. Ortaya çıkan yapı yürütme ortamında çalıştırılmak için hazırdır.
- Çalışma aşaması: Uygulama süreçlerini başlatarak yürütme ortamında uygulamayı çalıştırır.
12 faktör uygulaması bu aşamalar arasında katı bir ayrım kullanır. Örneğin zamanında kod değişikliği yapmak mümkün değildir çünkü build aşamasındaki değişiklikleri yaymak için bir yol yoktur. Dağıtım araçları, genellikle sürüm yönetim araçları, bir önceki sürüme almak için olanak sağlar.
Örneğin Capistrano dağıtım aracı sürümleri releases dizini altında tutar, şimdiki sürümü current release dizininde tutar. Geri dönüşü de rollback komutu ile hızlıca sağlar.
Her sürüm her zaman eşsiz bir sürüm id'sine sahip olmalıdır. Herhangi bir değişiklikte yeni bir sürüm oluşturmanız gerekir.
Yeni kod dağıtıldığında her uygulamanın geliştiricileri tarafından build başlatılır. Çalışma zamanlı uygulamalar karşılaştırılmalara göre reboot hizmeti durumunu otomatik yapabilir ya da davetsiz bir süreç, süreç yöneticisi tarafından başlatılabilir. Bu nedenle çalışma aşamasında mümkün olduğunca az hareketli parça tutulmalı, geliştirici elle yapmadığında gece olan kırılmalar uygulama çalışırken önlenir. Dağıtıma sürülen hatalar geliştiriciler için daha önemli olduğundan build aşaması karmaşık olabiliyor.
6) Processes(Süreçler)
Uygulama bir veya daha fazla işlem olarak yürütme ortamında yürütülür. En basit durumda kod bir stand-alone script ile yürütme ortamı bir geliştirici yerel dil çalıştırma ile ve süreç komut satırı ile başlatılabilir.
On iki faktör süreçleri durum bilgisi olmayan, paylaşımdan başka bir şey değildir. Süreklilik gerektiren bir veri bir durum bilgisi olan destek hizmeti, tipik bir veritabanında saklanmalıdır.
Sürecin bellek alanı veya bir dosya sistemi özeti tek aktarımlı önbellek olarak kullanılır. Örneğin büyük bir dosya indirirken üzerinde faaliyet gösteren işlemleri ve veritabanındaki işlemin sonuçlarını saklamak. On iki faktör uygulaması bellek veya disk üzerinden önbelleğe aldıklarını bir iş gelecek veya zaten var olduğunu varsayar. Tek bir süreç çalışırken yeniden başlatma genellikle tüm yereli silecektir.
Varlık paketleyici derlenmiş varlıklar için önbellek olarak dosya sistemi kullanır.
7) Port Binding(Port Bağlamı)
Web uygulamaları bazen bir web sunucusu container'ı içinde yürütülür. Örneğin php uygulamaları apache içinde bir modül olarak çalışabilir veya java uygulamaları Tomcat içinde çalışabilir.
On iki faktör uygulaması tamamen kendi kendine yeter. Bir web uygulaması port bağlayıcısı tarafından servis olarak http ile dışa aktarır ve port üzerinden gelen istekleri dinler.
Bir yerel geliştirme ortamında, geliştiriciler dışa aktarılan servislere erişmek için Url gibi örneğin "http://localhost:5000/" ziyaret ederler. Dağıtımda bir yönlendirme katmanı, port-bound web işlemlerine göre, public-facing ana makineden itibaren yönlendirme isteklerini işler.
Bu tipik uygulama kullanılan bağımlılık bildirimleri tarafından web-server kütüphanelerine eklenir. Bu durum kullanıcı alanında uygulama kodunun içindedir. Yürütme ortamı ile sözleşme istekleri hizmet için bir bağlantı noktasıdır.
Http yalnızca servis değil, port bağlayıcıları tarafından dışa aktarılır. Neredeyse her tür yazılım servisleri için porta göre süreç bağlayıcıları üzerinde çalışır ve gelen istekleri bekler.
Port bağlama yaklaşımının anlamı; tüketen uygulamalar için yapılandırmada cevap olarak işlenen destek uygulamaları ile birlikte, Url sağlayıcıları tarafından bir uygulama, diğer uygulamalar için servis bağlayıcısı olmalıdır.
8) Concurrency(Eş zamanlılık)
Bir bilgisayar programı çalıştırıldığında bir veya bir çok süreç ile temsil edilir. Web uygulamaları süreç yürütme biçimlerinde çeşitlidir. Örneğin Php süreçleri apache için çocuk süreçler çalıştırılır, istek değerleri tarafından gerektiğinde başlatma talep eder. Java süreçleri ters yaklaşım kabul etmektedir. Her iki durumda da çalışan süreçler uygulamalar için geliştiricilere göre minimal görünür.
On iki faktör uygulamasında süreçler birinci sınıf vatandaşlardır. On iki faktör uygulaması süreç servislerini çalıştırmak için unix süreç modellerinden güçlü ipuçları alır. Kullanılan bu model de çalışan süreç tipleri için belirtilen her bir tip tarafından çeşitli iş yükü kullanımına göre diğer uygulamaları planlar. Bu tür bireysel süreçler kendi iç dışlama kullanılarak dışa aktarılmaz, thread üzerinde bulunan çalışma zamanlı VM kullanılır ama bireysel VM çok büyüyebilir, bu nedenle çoklu fiziksel makine üzerindeki bir çok süreci kapsamalıdır. On iki faktör uygulamalarının daha eşzamanlı basit ve güvenirlir bir işlem olduğu anlamına gelir. Bu dizi süreç tipleri için ve her tip süreç numarası için tip formatı olarak biliniyor.
On iki faktör uygulaması süreçleri bekletmez ve PID dosyasına yazmaz. Bunun yerine, çıktı akışlarını yönetmek için işletim sisteminin süreç yöneticisine güvenir, çöken süreçlere cevap verir, kullanıcı üyeliği kabul edilmiş kullanıcı tarafından yeniden başlatılır ve kapatılabilir.
9) Disposability(Kullanıma Hazır Olma Durumu)
Hızlı başlatma ve zarif kapama ile sağlamlık seviyesini en üst düzeye çıkarmak. On iki faktör uygulaması süreçleri kullanıma hazır olmalı, amaç bir anlık bildirimle başlatmak ya da bitirmek. Bu hızlı ölçekleme kod için geliştirimi ve yapılandırma değişikliğini kolaylaştırır ve üretim dağıtımı için sağlamlığı kolaylaştırır. Süreçlerin başlatma süresini en aza indirmek için çaba gerekir. İdeal olarak, süreçlerin bir süre için, sürecin yükselmesine kadar, komut başlatması gerekir ve işlemleri karşılamak için hazırlık zaman almaktadır. Süreci bırakmak, yükseltmek ve yardım sağlamak için kısa başlama süresi atiklik sağlayacak. Çünkü süreç yöneticisi izin verdiğinde yeni fiziksel makineler için süreç hareketi kolaylaşacak. Süreç işlem yöneticisinden SIGNTERM sinyali aldığında duracaktır.
Web süreçlerinde zarif kapatma, port servisleri üzerinde dinleme kesilmesiyle elde edilir, herhangi bir geçerli istek, bitirmek için izin verir ve kapatır.
Çalışan süreç için zarif kapatma, çalışma sırasına göre şimdiki işi dönderme ile elde eder.
Süreçler donanımda bir arıza olması durumunda ani kesilmelere karşı güçlü olmalıdır. Bu SIGTERM ile zarif kapatmada çok daha az sık rastlanan bir durum olmasına rağmen olabilir. Sağlam bir kuyruk olan arka uç kullanılmalıdır. Her iki durumda da, on iki faktör uygulaması beklenmedik işlemleri, zarif olmayan kapanışları planlar. Crash-only tasarım mantıksal sonucuna göre bu kavramı ele alır.
10) Dev/prod parity
Tarihle ilgili ürün ve geliştirme arasında önemli boşluklar oluşmuştur. Bu boşluklar üç alanda gerçekleşir:
- Time gap: Bir geliştiricini üretime geçmek için kod çalışması günler haftalar aylar sürebilir.
- Personel gap: Geliştiriciler kod yazıyor, ops mühendisleri dağıtır.
- Tools gap: Geliştiriciler ürün dağıtımında Apache,MySQL ve linux kullandığında, nginx, SQlite ve OSx gibi bir yığın kullanıyor olabilirler.
On iki faktör uygulaması üretim ile dağıtım arasındaki boşluğu tutarak sürekli dağıtım için tasarlanmıştır. Bu üç boşluğa baktığımız da:
- Time gap küçültmek: Bir geliştirici kod yazdığı zaman saatler hatta dakikalar sonra bile dağıtmak mümkün.
- Personel gap küçültmek: Kod yazan geliştiriciler dağıtımı yakından izlerler.
- Tools gap küçültmek: Üretim ve dağıtım mümkün olduğunca benzer sürdürürler.
Tabloyla özetlemek gerekirse:
Geleneksel uygulama 12 Faktör uygulaması
Dağıtım arasındaki zaman Hafta Saat
Kod yazarları ve kod dağıtıcıları Farklı kisiler Aynı kişiler
Üretim ve geliştirme ortamı Farklı Mümkün olduğunca benzer
Yedekleme hizmeti, veritabanı, kuyruk sistemi ya da önbellek /dev/prod da önemli bir alandır. Bir çok dil yardım hizmetlerine erişimi kolaylaştırmak için kütüphaneler sunar. Bazı geliştiriciler üretimde daha güçlü ve ciddi yardım hizmetlerini kullanmak için yereldeki hafif destek hizmetlerine başvuruyorlar.
12 faktör uygulamaları geliştirme ve dağıtım arasındaki farklı yardım hizmetlerine karşıdır. Destek hizmetleri arasındaki farklılıklar geliştirilirken kod çalıştırma ve test etme bağlantıları kesebilir ya da üretimde fail verebilir. Bu uygulamanın ömrü boyunca düşünüldüğünde maliyeti oldukça artırır.
Hafif yerel destek hizmetleri daha az zorlayıcıdır. Modern yardım hizmetlerinin yüklemesi ve çalıştırması modern paketleme sistemleri sayesinde zor değildir, apt gibi. Bu sistemlerin kurulması ve kullanılmasının maliyeti "dev/prod" bölümü ve sürekli dağıtım yararına oranla düşüktür.
Yeni destek hizmetlerine geçiş yapmak için hala farklı yardım hizmetlerinin uyarlayıcıları kullanılıyor. Fakat tüm dağıtım uygulamalarının kullandıkları tip ve versiyon her bir yardım sistemi için aynı olmalı.
11)Logs (Kayıtlar)
Olay akışlarının işlenmesidir.
Loglar çalışan bir uygulamanın davranışlarında görünürlük sağlar. Sunucu tabanlı ortamlarda genellikle diskteki bir dosyaya yazılır fakat bu sadece bir çıkış yöntemidir. Loglar çalışan süreçlerin ve yardım hizmetlerinin zamanla bağlantılı olay akışlarının toplamıdır. Logların sabit başlangıcı ve sonu yoktur, uygulama çalışırken sürekli akış olur.
12 faktör uygulaması asla çıktı akışını yönelendirme ve depolamayla ilgilenmez. Yazmamalı veya log dosyası yönetmeye kalkışmamalısınız. Bunun yerine, her çalışan süreç olay akışını stduo ile yazıyor. Yerel geliştirme sırasında, uygulama davranışlarını kendi terminalinde gözlemlemek için akışları ön plan da izler. Her işlem akışı ele alınır çevre ortamları tarafından, diğer uygulama akışlarıyla birlikte karşılaştırılır ve arşivlerde görüntülemek üzere nakledilir. Bu hedef arşiv uygulama tarafından görünür veya yapılandırılabilir değildir. Onun yerine uygulama ortamı tarafından tamamen işlenir. Açık kaynak yönlendiricileri bu amaçla kullanılır(Logplex).
Bir uygulama için olay akışı bir dosyaya yönlendirilebilir veya bir terminalde zamanlı kuyruk üzerinden izlenebilmektedir. En önemlisi, akış bir günlük indeksleme ve analiz sistemine gönderilebilir. Bu sistemler uygulamanın zamana bağlı davranışlarını ölçmek için büyük güç ve esneklik sağlar:
- Geçmişte belirli olayları bulmak.
- Eğilimlerin büyük ölçekli grafikleri.(Örneğin dakika başına istekler)
- Kullanıcı tanımına uygun olarak uyarı verir.( Örneğin hata miktarı belli bir eşiği aştığında uyarı gönderir. )
12) Admin Proccess( Yönetici süreci )
Bir defaya mahsus admin yönetici görevlerini çalıştırmak.
Süreç oluşumu uygulamanın düzenli iş yapması için kullanılan süreç dizisidir. Ayrı olarak, geliştiriciler yönetimi ve bakımını bir defaya mahsus yapmak isterler:
- Veritabanı göçleri çalıştırmak
- Çalıştırılan konsol rasgele kodları çalıştırır veya canlı veritabanına karşı uygulamanın modellerini inceler. Çoğu dil bir Repl'i çalışan yorumlayıcı tarafından sağlar , herhangi bir argüman olmadan veya bazı durumlarda ayrı komutlara sahip olarak.
- Uygulamanın depo içine işlenen tek seferlik komut dosyalarını çalıştırır.
Bir kerelik yönetici işlemleri, uygulamanın düzenli uzun soluklu süreçleri olarak özdeş bir ortamda çalıştırılmalıdır. Çalışan bir sürüme karşı herhangi bir işlem, sürüme dayalı olarak yapılandırılmalı ve benzer kod tabanı kullanılmalıdır. Yönetici Kod senkronizasyon sorunlarını önlemek için uygulama kodu ile göndermeniz gerekir.
Aynı bağımlılık izolasyon teknikleri tüm süreç türlerinde kullanılmalıdır. Örneğin eğer ruby web servisleri bundle exec thin start komutunu kullanıyorsa, veritabanı göçü içinde bundle exec rake db:migrate kullanmalıdır.
12 faktör bir Repl kabuk çıktısında kutular için güçlü dil desteği sağlar bir defaya mahsus. Yerel dağıtımlarda, geliştiriciler uygulamanın çıkış dizini içinde doğrudan kabuk komutu ile tek seferlik yönetici işlemleri başlatırlar. Bir ürün dağıtımında geliştiriciler ssh veya diğer uzak komut erişim mekanizmalarını böyle bir işlemi başlatmak için kullanırlar.
31 Temmuz 2016 Pazar
Kurallar için Filtre Yazımı
query_string: Bölümler için kullanılır veya çoklu alanlarda tam eşleşme sağlar. Lucene sorgu formatını takip eder.
filter:
- query:
query_string:
query: "username: bob"
- query:
query_string:
query: "_type: login_logs"
- query:
query_string:
query: "field: value OR otherfield: othervalue"
- query:
query_string:
query: "this: that AND these: those"
term: Kesin alanlarla eşleşir.
filter:
- term:
message: "foo"
Şeklinde filtreleme yaptığımız zaman, logların mesaj alanlarında foo geçen tüm loglarla eşleşir. Aşağıdaki örneğe baktığımız da 5 tane log message alanında foo olan log gelmiş ve hepsi ile eşleşme sağlanmış.
terms: Birden fazla değerle eşleşmesi için basit bir kombinasyonu vardır:
filter:
- terms:
message: ["foo", "infoowl"]
Log message foo ve infoowl olan loglarla eşleşir.
wildcard: ‘?’( Tek harf değerinde ), ’*’( Kullanış göre içindeki tüm karkterleri temsil eder. ) gibi özel karakter kullanmak için.
filter:
- query:
wildcard:
field: "foo*bar"
not, and, or :
filter:
- or:
- term:
field: "value"
- wildcard:
field: "foo*bar"
- and:
- not:
term:
field: "value"
- not:
term:
_type: "something"
filter:
- query:
query_string:
query: "username: bob"
- query:
query_string:
query: "_type: login_logs"
- query:
query_string:
query: "field: value OR otherfield: othervalue"
- query:
query_string:
query: "this: that AND these: those"
term: Kesin alanlarla eşleşir.
filter:
- term:
message: "foo"
Şeklinde filtreleme yaptığımız zaman, logların mesaj alanlarında foo geçen tüm loglarla eşleşir. Aşağıdaki örneğe baktığımız da 5 tane log message alanında foo olan log gelmiş ve hepsi ile eşleşme sağlanmış.
terms: Birden fazla değerle eşleşmesi için basit bir kombinasyonu vardır:
filter:
- terms:
message: ["foo", "infoowl"]
Log message foo ve infoowl olan loglarla eşleşir.
wildcard: ‘?’( Tek harf değerinde ), ’*’( Kullanış göre içindeki tüm karkterleri temsil eder. ) gibi özel karakter kullanmak için.
filter:
- query:
wildcard:
field: "foo*bar"
not, and, or :
filter:
- or:
- term:
field: "value"
- wildcard:
field: "foo*bar"
- and:
- not:
term:
field: "value"
- not:
term:
_type: "something"
28 Temmuz 2016 Perşembe
ElastAlert Kural Tipleri
*Kural örnek yapılandırma dosyasında ilgili yerlerde değişiklik yapıp, eklenmesi gerekenler eklenmiştir.
Any ( Verilen herhangi bir filtreleme ile eşleştiğinde alert oluşur. )
…
name: log_any
type: any
..
filter:
- query:
query_string:
query: "version:1"
version alanı 1 olan tüm sorgular için alert oluşturur.
Frequency( Belli bir zaman diliminde olayların en az belli bir sayıda eşleşme olduğunda alert oluşur.)
name: log_error
type: frequency
num_events: 1
timeframe:
minutes: 1
filter:
- query:
query_string:
query: "level:ERROR"
Eğer bir dakikada log seviyesi Error olan bir log varsa alert oluşturur.
Flatline ( Belli bir zamanda eşleşen sorgu sayısının verilen eşik değerinden az olmasıyla alert oluşturur. )
name: log_flatline
type: flatline
threshold: 5 // ‘den fazla olunca eşleşmiyor.
timeframe:
minute: 1
filter:
- query:
query_string:
query: "version:1"
version değeri 1 olan sorgular 1 dakikadan 5 den az ise alert oluşturur.
Blaclist ( liste’de var ise alert oluşturur. )
name: log_blacklist
type: blacklist //içerirse eşleşir.
blacklist:
“message” //aranacak kelime
compare_key: message //aranacak yer
Eğer message kelimesi logların message alanında geçiyorsa alert oluşturur.
Whitelist ( Verilen değer listedeki alanla eşleşmiyorsa alert oluşturur. )
name: log_whitelist
type: whitelist
whitelist:
“infoowl” //liste bunu içermiyorsa eşleşir
compare_key: message
ignore_null: True olduğunda compare_key olanı olmadan eşleşme yapmıyor
Eğer infoowl kelimesi logların message alanında geçmiyorsa alert oluşturur.
Cardinality ( Belli bir zamanda belirli alandaki benzersiz değerlerin sayısı verilen eşik değerinden düşükse alert oluşturur. )
name: log_cardinality
type: cardinality
cardinality_field: “host”
min_cardinality: 5
timeframe:
minutes: 1
loglardaki host alanında oluşan benzersiz değerler bir dakikada 5’den düşükse alert oluşturur.
Change ( Bir alan bir süre içerisinde iki farklı değere sahip olduğunda alert oluşturulur. )
name: log_change
type: change
compare_key: message //değişikliğin kontrol edileceği alan
ignore_null: True olduğunda compare_key olanı olmadan eşleşme yapmıyor
query_key: host (kontrol edilmiş olayların hepsinde bu alan olmalı)
timeframe:
minutes: 1
1 dakika da Host alanı olan ve message alanında değişiklik olduğunda alert oluşturuyor.
Örnekler
Örnek 1
Alerti thread_name alanında değişiklik olursa
name: log_error
type: change
index: logstash-*
compare_key: thread_name
ignore_null: True
query_key: host
Çıktıda hem yeni hem eski değerini çıktı olarak vermektedir:
level: ERROR
level_value: 40000
logger_name: com.example.DemoApplication$$EnhancerBySpringCGLIB$$2bec2634
message: New Error
new_value: http-nio-8080-exec-6
old_value: http-nio-8080-exec-5
thread_name: http-nio-8080-exec-6
type: syslog
Örnek 2
Mesaj kısmında Yıldız geçip ay geçmeyen loglar
type: blacklist
blacklist:
- "Yıldız"
compare_key: message
filter:
- not:
term:
message: "ay"
Örnek 3
Mesajda a ve b olup c ve d olmaması. Eğer terms: message: [“a”,”b”] yazarsak sadece a ya da b olduğunda da eşleşme oluyor.
type: frequency
filter:
- term:
message: "a"
- and:
- term:
message: "b"
- and:
- not:
terms:
message: ["c","d"]
Any ( Verilen herhangi bir filtreleme ile eşleştiğinde alert oluşur. )
…
name: log_any
type: any
..
filter:
- query:
query_string:
query: "version:1"
version alanı 1 olan tüm sorgular için alert oluşturur.
Frequency( Belli bir zaman diliminde olayların en az belli bir sayıda eşleşme olduğunda alert oluşur.)
name: log_error
type: frequency
num_events: 1
timeframe:
minutes: 1
filter:
- query:
query_string:
query: "level:ERROR"
Eğer bir dakikada log seviyesi Error olan bir log varsa alert oluşturur.
Flatline ( Belli bir zamanda eşleşen sorgu sayısının verilen eşik değerinden az olmasıyla alert oluşturur. )
name: log_flatline
type: flatline
threshold: 5 // ‘den fazla olunca eşleşmiyor.
timeframe:
minute: 1
filter:
- query:
query_string:
query: "version:1"
version değeri 1 olan sorgular 1 dakikadan 5 den az ise alert oluşturur.
Blaclist ( liste’de var ise alert oluşturur. )
name: log_blacklist
type: blacklist //içerirse eşleşir.
blacklist:
“message” //aranacak kelime
compare_key: message //aranacak yer
Eğer message kelimesi logların message alanında geçiyorsa alert oluşturur.
Whitelist ( Verilen değer listedeki alanla eşleşmiyorsa alert oluşturur. )
name: log_whitelist
type: whitelist
whitelist:
“infoowl” //liste bunu içermiyorsa eşleşir
compare_key: message
ignore_null: True olduğunda compare_key olanı olmadan eşleşme yapmıyor
Eğer infoowl kelimesi logların message alanında geçmiyorsa alert oluşturur.
Cardinality ( Belli bir zamanda belirli alandaki benzersiz değerlerin sayısı verilen eşik değerinden düşükse alert oluşturur. )
name: log_cardinality
type: cardinality
cardinality_field: “host”
min_cardinality: 5
timeframe:
minutes: 1
loglardaki host alanında oluşan benzersiz değerler bir dakikada 5’den düşükse alert oluşturur.
Change ( Bir alan bir süre içerisinde iki farklı değere sahip olduğunda alert oluşturulur. )
name: log_change
type: change
compare_key: message //değişikliğin kontrol edileceği alan
ignore_null: True olduğunda compare_key olanı olmadan eşleşme yapmıyor
query_key: host (kontrol edilmiş olayların hepsinde bu alan olmalı)
timeframe:
minutes: 1
1 dakika da Host alanı olan ve message alanında değişiklik olduğunda alert oluşturuyor.
Örnekler
Örnek 1
Alerti thread_name alanında değişiklik olursa
name: log_error
type: change
index: logstash-*
compare_key: thread_name
ignore_null: True
query_key: host
Çıktıda hem yeni hem eski değerini çıktı olarak vermektedir:
level: ERROR
level_value: 40000
logger_name: com.example.DemoApplication$$EnhancerBySpringCGLIB$$2bec2634
message: New Error
new_value: http-nio-8080-exec-6
old_value: http-nio-8080-exec-5
thread_name: http-nio-8080-exec-6
type: syslog
Örnek 2
Mesaj kısmında Yıldız geçip ay geçmeyen loglar
type: blacklist
blacklist:
- "Yıldız"
compare_key: message
filter:
- not:
term:
message: "ay"
Örnek 3
Mesajda a ve b olup c ve d olmaması. Eğer terms: message: [“a”,”b”] yazarsak sadece a ya da b olduğunda da eşleşme oluyor.
type: frequency
filter:
- term:
message: "a"
- and:
- term:
message: "b"
- and:
- not:
terms:
message: ["c","d"]
Kaydol:
Kayıtlar (Atom)