Çalıştığım centos sunucularda çekirdek versiyonu yükseltme ve indirme işlemi yapmak zorunda kaldım. Bununla ilgili buraya da not alayım istedim.
Öncelikle işlemi gerçekleştirmeden önce
$ uname -a
komutu ile çekirdek versiyonumuzu kontrol edelim.
Eğer çekirdek versiyonunu yükseltme işlemi yapacaksak.
$ sudo rpm -i çekirdekpaketi.rpm
$ sudo reboot
Bu iki komutu kullanarak işletim sistemimizi artık yeni çekirdekle kaldırabiliriz.
Eğer çekirdek versiyonumuzu indirme işlemi yapacaksak. Öncelikle sistemim ayağa kalktığı çekirdeği sistemden kaldırmamız gerekiyor. Ve bunun için paket isminden emin olmalıyız.
$ sudo rpm -qa | grep kernel
$ sudo rpm -e paket-adi.rpm
$ sudo rpm -i paket-adi.rpm
$ sudo reboot
Bu komutlardan sonra işletim sistemimizi artık eski versiyonda bir çekirdekle ayağa kaldırmış oluyoruz.
17 Mayıs 2018 Perşembe
7 Mayıs 2018 Pazartesi
Ssh kimlik doğrulamasının Tacacs+ ile entegrasyonu
Terminal erişim denetleyici erişim kontrol sistemi (TACACS), merkezi bir sunucu üzerinden ağa bağlı erişim kontrolü için uzaktan kimlik doğrulamayı ve yetkilendirme gibi hizmetleri sağlar. Tacacs bağlantı noktası olarak (tcp veya udp) 49.portu kullanır. Tacacs, bir istemcinin bir kullanıcı adı ve parola kabul etmesine ve bir tacacs kimlik doğrulaması sunucusuna, bazen de tacacs daemon veya tacacsd denen bir sorgu göndermesine izin verir. Kimlik doğrulama isteğinin kabul edilip edilmeyeceğini veya reddedilip reddedileceğini belirler.
Tacacs+ ve Radıus, daha yakın zamanda oluşturulmuştur. Tacacs+ tamamen yeni bir protokoldür ve öncülleri, Tacacs ve Xtacacs ile uyumlu değildir. Tacacs+, TCP'yi kullanır. Tacacs+ kimlik doğrulama, yetkilendirme ve muhasebe (AAA) mimarisini kullandığı için, protokolün bu ayrı bileşenleri ayrı sunucularda ayrıştırılabilir ve işlenebilir.
Ben debian üzerinde ssh kimlik doğrulamasını tacacs+ ile sağlamak istiyordum. Bunu için linux'da pam modulunu kullandım. PAM , servislere göre farklı kimlik denetleme yöntemleri belirleyebilmeyi sağlayan bir sistemdir. Bununla birlikte tacacs+ kullanmabilmek için iki paket yüklememiz gerekiyor.
$ sudo apt-get install libpam-tacplus
$ sudo apt-get install tacacs+
Ssh'ın pam modulunu kullanmasını istediğimiz için /etc/ssh/sshd_config dosyasında aşağıdaki değişiklikleri yapıyoruz:
UsePAM no
ChallengeResponseAuthentication no
"/etc/pam.d/" dizinini altına ve tacacs oluşturuyoruz. Ben şuan sadece kimlik doğrulaması için tacacs+ kullanmak istediğim için onunla ilgili yapılandırmaları yaptım.
/etc/pamd/sshd
auth include tacacs
@include common-password
/etc/pam.d/tacacs
auth [success=2 default=ignore] pam_succeed_if.so uid < 501
auth [success=done default=ignore] /lib/security/pam_tacplus.so debug server=serverip secret=secretkey login=plain timeout=2
auth required pam_unix.so user=admin #ben admin kullanıcısının aynı zamanda yereldeki parolasıyla giriş yapabilmesini istediğim için bu ayarı özel olarak ekledim.
Bu ayarları yaptıktan sonra sshd servisini yeniden başlatıyoruz.
$sudo services sshd restart
*****Bilmeniz gereken önemli bir nokta, ssh ile kimlik doğrulamasını tacacs'a yaptırırken, kullanıcılarınızın yerelde de tanımlı olması gerekiyor. Tacacs sadece kullanıcı adı ve parola gönderdiği için ssh ile bağlantı sağlandığında ssh bu kullanıcının kabuğunu, ev dizinini, kullanıcı id, grup id gibi beklediği cevapları alamaz. Bu yüzden de kullanıcın yerelde de tanımlı olması gerekir. Bunu aşmanın bazı yöntemleri varmış. Nss tabanlı yöntemler bunlara bakabilirsiniz.
Tacacs+ ve Radıus, daha yakın zamanda oluşturulmuştur. Tacacs+ tamamen yeni bir protokoldür ve öncülleri, Tacacs ve Xtacacs ile uyumlu değildir. Tacacs+, TCP'yi kullanır. Tacacs+ kimlik doğrulama, yetkilendirme ve muhasebe (AAA) mimarisini kullandığı için, protokolün bu ayrı bileşenleri ayrı sunucularda ayrıştırılabilir ve işlenebilir.
Ben debian üzerinde ssh kimlik doğrulamasını tacacs+ ile sağlamak istiyordum. Bunu için linux'da pam modulunu kullandım. PAM , servislere göre farklı kimlik denetleme yöntemleri belirleyebilmeyi sağlayan bir sistemdir. Bununla birlikte tacacs+ kullanmabilmek için iki paket yüklememiz gerekiyor.
$ sudo apt-get install libpam-tacplus
$ sudo apt-get install tacacs+
Ssh'ın pam modulunu kullanmasını istediğimiz için /etc/ssh/sshd_config dosyasında aşağıdaki değişiklikleri yapıyoruz:
UsePAM no
ChallengeResponseAuthentication no
"/etc/pam.d/" dizinini altına ve tacacs oluşturuyoruz. Ben şuan sadece kimlik doğrulaması için tacacs+ kullanmak istediğim için onunla ilgili yapılandırmaları yaptım.
/etc/pamd/sshd
auth include tacacs
@include common-password
/etc/pam.d/tacacs
auth [success=2 default=ignore] pam_succeed_if.so uid < 501
auth [success=done default=ignore] /lib/security/pam_tacplus.so debug server=serverip secret=secretkey login=plain timeout=2
auth required pam_unix.so user=admin #ben admin kullanıcısının aynı zamanda yereldeki parolasıyla giriş yapabilmesini istediğim için bu ayarı özel olarak ekledim.
Bu ayarları yaptıktan sonra sshd servisini yeniden başlatıyoruz.
$sudo services sshd restart
*****Bilmeniz gereken önemli bir nokta, ssh ile kimlik doğrulamasını tacacs'a yaptırırken, kullanıcılarınızın yerelde de tanımlı olması gerekiyor. Tacacs sadece kullanıcı adı ve parola gönderdiği için ssh ile bağlantı sağlandığında ssh bu kullanıcının kabuğunu, ev dizinini, kullanıcı id, grup id gibi beklediği cevapları alamaz. Bu yüzden de kullanıcın yerelde de tanımlı olması gerekir. Bunu aşmanın bazı yöntemleri varmış. Nss tabanlı yöntemler bunlara bakabilirsiniz.
27 Nisan 2018 Cuma
Sftp Sunucusu Kurulumu-CENTOS
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. Bunun için ayrıca sftp kurulumu yapmanıza gerek olmaz.
Şimdi aşağıdaki kod ile sistemimizde gerekli dosyaların olup olmadığını kontrol edelim.
$ rpm -qa|grep ssh
libssh2-1.4.3-10.el7_2.1.x86_64
openssh-7.4p1-13.el7_4.x86_64
openssh-server-7.4p1-13.el7_4.x86_64
openssh-clients-7.4p1-13.el7_4.x86_64
Daha sonra sftp dosyalarını yükleyip indirmek için kullanıcağımız dizini oluşturalım. Bu dizini istediğiniz dizin altına oluşturabilirsiniz. Ben home dizini altına oluşturmayı tercih ettim.
$ mkdir /home/sftp
$ cd /home
$ chmod 701 sftp
sftp dizininin iznini 701 yapıyoruz.
Bir sftp kullanıcıları için grup oluşturuyoruz.
$ groupadd sftpusers
Daha sonra kullanıcıyı oluşturuyoruz:
$ useradd -g sftpusers -d /upload -s /sbin/nologin mysftpuser
* -d komutu ile daha sonra /upload klasörünün /home/sftp/upload altında olacağı anlamına gelir.
$ passwd mysftpuser
Upload dizinini oluşturup sahiplik ayarlarını yapıyoruz:
$ mkdir -p /home/sftp/upload
$ chown -R root:sftpusers /home/sftp
$ chown -R mysftpuser:sftpusers /home/sftp/upload
Daha sonra /etc/ssh/sshd_config yapılandırma dosyasına aşağıdaki satırları ekliyoruz:
Match Group sftpusers
ChrootDirectory /home/sftp/%u
ForceCommand internal-sftp
*sftpusers grubundaki kullanıcıların sadece sftp bağlantısı sağlayabilmesini ve sadece home/sftp altına erişimi olmasına izin verdik.
Son olarakta sshd servisini yeniden başlatıyoruz.
$ service sshd restart
Şimdi aşağıdaki kod ile sistemimizde gerekli dosyaların olup olmadığını kontrol edelim.
$ rpm -qa|grep ssh
libssh2-1.4.3-10.el7_2.1.x86_64
openssh-7.4p1-13.el7_4.x86_64
openssh-server-7.4p1-13.el7_4.x86_64
openssh-clients-7.4p1-13.el7_4.x86_64
Daha sonra sftp dosyalarını yükleyip indirmek için kullanıcağımız dizini oluşturalım. Bu dizini istediğiniz dizin altına oluşturabilirsiniz. Ben home dizini altına oluşturmayı tercih ettim.
$ mkdir /home/sftp
$ cd /home
$ chmod 701 sftp
sftp dizininin iznini 701 yapıyoruz.
Bir sftp kullanıcıları için grup oluşturuyoruz.
$ groupadd sftpusers
Daha sonra kullanıcıyı oluşturuyoruz:
$ useradd -g sftpusers -d /upload -s /sbin/nologin mysftpuser
* -d komutu ile daha sonra /upload klasörünün /home/sftp/upload altında olacağı anlamına gelir.
$ passwd mysftpuser
Upload dizinini oluşturup sahiplik ayarlarını yapıyoruz:
$ mkdir -p /home/sftp/upload
$ chown -R root:sftpusers /home/sftp
$ chown -R mysftpuser:sftpusers /home/sftp/upload
Daha sonra /etc/ssh/sshd_config yapılandırma dosyasına aşağıdaki satırları ekliyoruz:
Match Group sftpusers
ChrootDirectory /home/sftp/%u
ForceCommand internal-sftp
*sftpusers grubundaki kullanıcıların sadece sftp bağlantısı sağlayabilmesini ve sadece home/sftp altına erişimi olmasına izin verdik.
Son olarakta sshd servisini yeniden başlatıyoruz.
$ service sshd restart
24 Mart 2018 Cumartesi
VRRP
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.
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.
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"]
Elastalert Kural Yapılandırma Dosyası
Elasticsearch, Logstash ve Kibana giderek artan log ve verileri yönetmek için kullanılıyor. Kibana görselleştirme için iyi fakat biz verilerdeki değişikliklerde, tutarsızlıklarda uyarıcı bir araca ihtiyac duyuyoruz.
Elasticsearch’deki verilerin belli desenlerle eşleştiğinde uyarılmasını istiyorsak, Elastalert bu işi yapmak için kullanılan bir araçtır.
İki türlü birleşeni birleştirerek çalıştırılır; kural tipleri ve alertler. Elasticsearch belirlenen kural tipine göre periyodik olarak sorgulanır. Eşleşme olduğunda uyarı gönderilir.
Elastalert de çok sayıda kural türü bulunur:
- Belli bir zamanda olayların eşleşmesi ( frequency )
- Eşleşme hacminin artması veya azalması ( spike )
- Belli zaman da eşleşmeler daha az olduğunda ( flatline )
- Belli bir alan liste ile eşleştiğinde( whitelist ya da blacklist )
- Verilmiş herhangi bir filtre ile eşleştiğinde ( any )
- Bir alan bir süre içinde iki farklı değerlere sahip olduğunda ( change )
Alert türler şimdilik bunlara destek vermektedir:
- Command
- Email
- JIRA
- OpsGenie
- SNS
- HipChat
- Slack
- Telegram
- Debug ( Konsola eşleşen loglarla ilgili bilgileri dönderir. )
Kural Yapılandırması
Varsayılan olarak çalışma prensibi her dosya sonu .yaml ile bitmeli, rule dizininin içinde olmalıdır.
Gerekli Alanlar
es_host: Kuralın sorgulanacağı makine adı(Elasticserch makine adı).
es_port: es_host a ulaşmak için kullanılan port.
index: Arama yapılacak dizin adıdır. Özel karakterleri burada kullanabiliriz. Örneğin index: my-index-* , my-index-2014-10-5 ile eşleşir. Format string içeriği %Y yıl, %m ay, %d gün içerir. Bunu kullanmak için use_strftime_index true olmalıdır.
name: Kural adı, eşsiz olmalıdır.
type: Kullanmak için seçtiğimiz kural adını yazıyoruz.
alert: Kullanmak istediğimiz alert tiplerini yazıyoruz.
Şeçenek Olan Alanlar
es_username , es_password Elasticsearch makinesi ile otomatik bağlantı sağlamak için kullanılır.
es_send_get_body_as : Elasticsearch sorgusu için kullanılan metod. Varsayılan olarak GET’dir.
use_strftime_index: Eğer True ise ElastAlert index için tarih zaman kullanılır.
aggregation: Çoklu eşleşmelerde bir alert göndermek için kullanılır. Eşleşmeyi bulduğunda aggregation periyodunu tamamlamayı bekler. Cron sözdizimini kullanır, hakkında. ( hours, minute, days )
buffer_time: config.yaml da genel ayarlanmış tanımlamaların üzerine yazmak için kullanılır. (Formatı zamandır.)
max_query_size: Tek sorguda Elasticsearch de indirilebilecek maksimum dosya sayısı. (int) Varsayılan olarak genel max_query_size’dır(10.000) )
use_kibana4_dashboard: Kibana4 dashboard’a bağlamak için kullanılır. Örneğin “ https://kibana.example.com/#/dashboard/My-Dashboard” gibi.
timeframe: Belli kural türlerinde minimum süre geçmesi gerektirir onu belirler.
filter: Sorguları filtrelemek için kullanılan alan.
Örnek rule.yaml
es_host: elk-elasticsearch
es_port: 9200
name: log_error
type: frequency
index: logstash-*
# link to a kibana dashboard with correct time settings
use_kibana4_dashboard:"http://elk-elasticsearch:5601/app/kibana#/dashboard/monitoring dashboard"
num_events: 1
max_query_size: 10000
run_every:
minutes: 1
buffer_time:
minutes: 15
timeframe:
minutes: 1
filter:
- query:
query_string:
query: "level:ERROR"
alert:
- "debug"
- "email"
email:
- "error@example.net"
22 Temmuz 2016 Cuma
Jhipster-console ile Elastalert Yapılandırması
Elastalert genel bir yapılandırma dosyasına sahiptir(config.yaml). Elastalert yapılandırma dosyaları YAML dosyasıdır.
*Kurallar içinde yapılandırma dosyası oluşturacağımızdan hepsini bir dizinde toplamak kolaylık olabilir.
Örnek config.yaml
# The unit can be anything from weeks to seconds
run_every:
minutes: 1
# ElastAlert will buffer results from the most recent
# period of time, in case some log sources are not in real time
buffer_time:
minutes: 5
# The elasticsearch hostname for metadata writeback
# Note that every rule can have it's own elasticsearch host
es_host: elk-elasticsearch
# The elasticsearch port
es_port: 9200
# Optional URL prefix for elasticsearch
#es_url_prefix: elasticsearch
# Connect with SSL to elasticsearch
use_ssl: False
# Option basic-auth username and password for elasticsearch
#es_username: someusername
#es_password: somepassword
# The index on es_host which is used for metadata storage
# This can be a unmapped index, but it is recommended that you run
# elastalert-create-index to set a mapping
writeback_index: elastalert_status
# If an alert fails for some reason, ElastAlert will retry
# sending the alert until this time period has elapsed
alert_time_limit:
days: 1
Örnek Yapılandırma dosyasında var olan seçenek dışında kullanacağınız yapılandırma alanları da vardır:
rules_folder: ElastAlertden gelen kural yapılandırma dosyalarının yolu yazılır.
run_every: Elastalertin Elasticserch sorgu sıklığıdır. Verilen kural çalıştığında zamanı tutar ve şimdiki zamandan itibaren periyodik olarak sorgular. Bu alanın biçimi "minute"
es_host: Elastalert'in aramalarıyla ilgili metadataları kaydeden Elasticserch'un makine adıdır.
es_port: es_host makinesine erişmek için kullanılan porttur.
use_ssl: es_host bağlanırken SSL kullanmak isteyip istemediğimizi değerine 'True', 'False' vererek ayarlayabiliriz.
es_hostname: es_host a bağlanırken otomatik bağlanmak için kullanıcı adı
es_password: es_host a bağlanırken otomatik bağlanmak için parola
es_url_prefix: Elasticserch endpoint için url alan kodu.
es_send_get_body_as: Elasticsearh sorgulaması için metot. GET, POST ve source olabilir. Varsayılan Get dir.
es_counn_timeout: Bağlanma ve es_host'u okumak için zaman aşımı ayrlar. Varsayılan olarak 10 dur.
scan_subdirectories: Ayar yapılmadığında veya elastalert kural dizinini yeniden indirmeyeceginde. True veya False Varsayılan olarak True.
writeback_index: Elasticsearch de kaydedilen verileri indekslemek için kullanılır. 3 farklı tipi vardır.
1)elastalert_status
2)elastalert
3)elastalert_error
scroll_keepalive :Maksimum sürede akan bağlantılar anlık yakalanmalı. Fakat sonuçların bitirilmesini sağlamak için dikkatli değer vermeliyiz. Yüksek değer verdiğimiz zaman elasticserch kaynaklarını kötüye kullanır.(Format time units)
old_query_limit: Elastalert için sorgular arasındaki maksimum sürede en son çalıştırılan sorguyu başlatır. Varsayılan olarak one week
disable_rules_on_error: Eğer True ise, Elastalert yakalanmayan exception kurallarını yok sayar. Varsayılan olarak True.
notify_email: email bildirimi göndermek için. Varsayılan olarak True dur.
notify_email: Bildirim göndermek istediği email ya da email listesi. Varsayılan olark email göndermez.
options:from_addr: Adres email bildirimlerinde başlık kullanır. Varsayılan değer 'Elastalert' dir.
stmp_host: Email bildirimi göndermek için kullanılan stmp ana makie adı.
email_replay_to: Varsayılan olarak alıcı adresidir.
Konteynırdan elastalerti çalıştırmak için elastalert.py dosyasını çalıştırmanız gerekir. Çalıştırırken sizden config dosyasını isteyecektir. config.yaml dosyasının yolunu --config parametresiyle belirtmek gerekir.
# python /opt/elastalert/elastalert/elastalert.py --config opt/elastalert/config.yaml
Kaydol:
Kayıtlar (Atom)