Bu yazıda Apache Zookeper’ a (tecrübe ve dilimiz döndüğünce) değinecek, sonrasında Zookeeper kurulumu ve Zookeeper cluster kurulumu yapıp Zookeeper’ ın konfigürasyon ve yönetimiyle alakalı temel bazı noktalara değinerek yazıyı sonlandıracağız.

Zookeeper Nedir?

Zookeeper, dağıtık yapıda olan servislerin koordine edilmesi için geliştirilmiş -kendisi de dağıtık yapıda çalışan- bir uygulamadır. Yaygın olarak kullanılan ve Zookeeper’ ın sitesinde uygulama örnekleri bulunan bazı servisler için aşağıdaki listeye göz atabiliriz. Tabi ki Zookeeper’ ın kullanım alanları bunlarla sınırlamak doğru olmaz.

• İki aşamalı commit, Two-phase commit protocol (2PC); Tek bir veritabanı üzerinde yapılan transaction işleminin birden çok kaynak üzerinde yapılmasına olanak sağlayan bir özellik/standart.
• Locks / Shared Locks; Bir nesneyi kullanıma tamamen kapatmak olarak tanımlayabileceğimiz lock özelliğine, veritabanlarının satır seviyesinde kilitleme (row level lock) örnek olarak verilebilir. Shared lock içinse; sadece okuma veya sadece yazma kilidi gibi örnekler verilebilir.
• Queues; Aslında kilit ve izleme (lock ve watch) implementasyonları içeren birçok yazılımda olduğu gibi Zookeeper üzerinde de mesaj kuyruğu oluşturmak mümkün.
• Barriers / Double Barriers; Kilit özelliğinin aksine bariyer (barrier) kullanımında, adından da anlaşılacağı üzere, hiç bir işlemin yapılmamasını için engel konulmasıdır. Yani kilit özelliğinde aynı anda bir işlem ya da istemci (client) çalışabiliyorken, bariyer kullanıldığında tüm işlem veya istemciler bekletiliyor.
• Lider seçimi, Leader Election; Günümüz uygulamalarında halen tercih edilmekle birlikte artık yetersiz kalan master-slave yapısının yerine master-free yapı kurulmasını sağlayan, otomatik lider (master) seçimine imkan veren bir özelliktir. Bu sayede hem sisteminizin tek bir noktaya bağımlılığı (SPOF, single point of failure) ortadan kalkıyor hem de, lider (master) değişimi gibi bir zaman kaybı (down time) ve operasyona ihtiyaç duyulmamış oluyor.
• Konfigürasyon yönetimi; Özellikle Apache Solr’ ın da kullandığı bir yöntem olan bu pratik, dağıtık yapıda çalışan servislerinizin konfigürasyonlarını tek bir noktadan ve çok hızlı şekilde yönetmenizi sağlıyor.

Zookeeper Kurulumu

Zookeeper ve Solr’ ı çoğunlukla JDK ile çalıştırmayı tercih ettiğimizden JDK ve Zookeeper dosyalarını (bu yazıda kurulumla alakalı yönlendirmelerde yardımcı olacağından zookeepers adlı bir dizine) indirelim. Sunucu üzerinde gui yoksa ve Oracle JDK dağıtımını kullanacaksanız Download JDK on Linux linki faydalı olabilir. Ayrıca Zookeeper’ a özel bir JVM/JDK kullanacağınıza dair parametre göndermezseniz otomatik olarak sistemde kurulu olan JVM’i algılayacaktır. Bu konuya Apache Solr ve Tomcat Kurulumu yazısında değindiğimizden çok fazla üzerinde durmuyoruz.

Aşağıda Mac OS için kısaca indirme aşamaları bulunuyor. Çok üzerinde durmuyoruz çünkü isterseniz siteden tarayıcı aracılığıyla ya da dilediğiniz şekilde indirip edinebilirsiniz.

# zookepers klasoru olustur
mkdir zookeepers

# zookeepers klasorune gir (calisilan calisma dizinini degistir)
cd zookeepers

# JDK'yi indir
wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u51-b16/jre-8u51-macosx-x64.tar.gz

# Zookeeper'i indir
wget http://www.eu.apache.org/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz
# jdk'yi arsivden cikar
tar xvzf jre-8u51-macosx-x64.tar.gz

# zookeeper' i arsivden cikar
tar xvzf zookeeper-3.4.6.tar.gz

Bu işlemler sonrasında klasörümüz şu şekilde olmalı

-rw-r--r--   56217343  jre-8u51-macosx-x64.tar.gz
drwxr-xr-x        102  jre1.8.0_51.jre
drwxr-xr-x        748  zookeeper-3.4.6
-rw-r--r--   17699306  zookeeper-3.4.6.tar.gz

Tek bilgisayarda 3 farklı Zookeeper kopyasını aynı anda çalıştırmak istediğimizden Zookeper klasöründen 3 kopya oluşturacağız. Bunu sadece test amaçlı kullanmayı öneriyoruz. Gerçek (production) ortamda 3 ayrı sunucu üzerine kurmaya alternatif olarak tek bir sunucuya böyle bir kurulumu önermiyoruz. Zookeeper için tek bir sunucu kaynağımız varsa şu amaçlarla aynı sunucuya kurmak yerinde olabilir; Sektörün acı gerçekleri gereği Zookeeper üzerinde gerçek ortamda konfigürasyon denemeleri, Zookeeper jre’inde parametere denemeleri, Zookeper servisinin bir şekilde durma ihtimali vb.

# zookeeper birinci kopyamiz
cp -r zookeeper-3.4.6 zookeeper1

# zookeeper ikinci kopyamiz
cp -r zookeeper-3.4.6 zookeeper2

# zookeeper ucuncu kopyamiz
cp -r zookeeper-3.4.6 zookeeper3

Son haliyle Zookeepers klasörümüz:

-rw-r--r--   56217343 jre-8u51-macosx-x64.tar.gz
drwxr-xr-x        102 jre1.8.0_51.jre
drwxr-xr-x        748 zookeeper-3.4.6
-rw-r--r--   17699306 zookeeper-3.4.6.tar.gz
drwxr-xr-x        748 zookeeper1
drwxr-xr-x        748 zookeeper2
drwxr-xr-x        748 zookeeper3

Bu elle (manuel) indirme kurma yönteminin en büyük dezavantajı sistem yeniden başlatıldığında hiçbir servisin otomatik olarak başlamayacağıdır.

Zookeeper Konfigürasyonu

Zookeeper’i indirdikten sonra artık konfigürasyon kısmına geçebiliriz. Tek bir kopya çalıştırmadan direkt kümeleme (clustering) olarak konfigüre edip çalıştıracağız.

Öncelikle (yine tek sunucu üzerinde üç kopya çalıştırmamız nedeniyle) data dizinini ayrı bir klasöre yönlendireceğiz ki üç Zookeeper da varsayılan kurulumla gelen /tmp/zookeper dizini kullanmasın. Bunun için Zookeeper klasörleri altında data klasörü oluşturuyoruz.

mkdir zookeeper1/data
mkdir zookeeper2/data
mkdir zookeeper3/data

Sonraki adımda ise sunuculara idlerini veriyoruz.Tüm sunuculara (Zookeeper’ı ayrı ayrı sunucular üzerine kurmuş olsak bile) 1 nolu id vermemeye dikkat edin.

echo "1" > zookeeper1/data/myid
echo "2" > zookeeper2/data/myid
echo "3" > zookeeper3/data/myid

Bu adımda ise Zookeper ile gelen varsayılan konfigürasyon dosyasını (Zookeeper tarafından okunabilmesi için zoo.cfg adıyla) kopyalıyoruz.

cp zookeeper1/conf/zoo_sample.cfg zookeeper1/conf/zoo.cfg 
cp zookeeper2/conf/zoo_sample.cfg zookeeper2/conf/zoo.cfg 
cp zookeeper3/conf/zoo_sample.cfg zookeeper3/conf/zoo.cfg

zookeeper1 için zoo.conf dosyasınya yapılması/eklenmesi gereken ek konfigürasyonlar:

clientPort=2171
dataDir=/Users/mustafakirimli/Desktop/zookeepers/zookeeper1/data/
server.1=localhost:3070:4070
server.2=localhost:3071:4071
server.3=localhost:3072:4072

server2 için zoo.conf dosyasınya yapılması/eklenmesi gereken ek konfigürasyonlar:

clientPort=2172
dataDir=/Users/mustafakirimli/Desktop/zookeepers/zookeeper2/data/
server.1=localhost:3070:4070
server.2=localhost:3071:4071
server.3=localhost:3072:4072

server3 için zoo.conf dosyasınya yapılması/eklenmesi gereken ek konfigürasyonlar:

clientPort=2173
dataDir=/Users/mustafakirimli/Desktop/zookeepers/zookeeper3/data/
server.1=localhost:3070:4070
server.2=localhost:3071:4071
server.3=localhost:3072:4072

Eğer ayrı ayrı sunuculara kurulum yapacaksak yukarıdaki gibi ayrı portlar kullanmak yerine tüm sunuculara aynı direktifleri verebiliriz. Yani tüm sunucularda Zookeper erişim portu 2171, Zookeeper slave (takipçi) portu 3070 ve Zookeeper seçim (election) portu 4070 olabilir. Buradaki slave yapısı klasik master-slave’ den biraz farklı çalışmakta. Bir lider (leader) bulunmakta ve herhangi bir Zookeeper sunucusuna gelen istekler senkron olarak diğer sunuculara iletilmektedir.

Sonraki yazı konularından biri olan Solr Cloud Kurulumu’ nda da göreceğimiz gibi, Zookeeper’ ın kendi lideri dışında özellikle Solr sharding kullanırken bağımsız seçimler (election) yapıp bir sunucu içinde farklı liderler de ayarlandığını göreceğiz. Bu konuyu açma nedenimiz Zookeeper’ ın kümeleme (clustering) için kullandığı lider seçimi implementasyonu uygulamalarımız tarafından da implemente edilebilir ve Zookeeper’ ın liderinden bağımsız hareket edebilir.

Zookeeper’ı Ayrı JVM/JRE ile Çalıştırma (opsyionel)

Daha önce de değindiğimiz bir konu olan java uygulamalarını sistem varsayılanı haricinde bir jre ile çalıştırmak istiyorsak bunu Zookeeper’ a basit bir konfigürasyon ile belirtebiliriz. Yine buradaki java.env dosyası normal kurulumda bulunmaz, biz elle eklediğimizde Zookeeper JVM konfigürasyonu olarak bu dosyayı okur.

echo "JAVA_HOME=/Users/mustafakirimli/Desktop/zookeepers/jre1.8.0_51.jre/Contents/Home/" > zookeeper1/conf/java.env
echo "JAVA_HOME=/Users/mustafakirimli/Desktop/zookeepers/jre1.8.0_51.jre/Contents/Home/" > zookeeper2/conf/java.env
echo "JAVA_HOME=/Users/mustafakirimli/Desktop/zookeepers/jre1.8.0_51.jre/Contents/Home/" > zookeeper3/conf/java.env

Zookeeper Log Konfigürasyonu (opsiyonel)

Daha önce Zookeeper kullandıysanız sunucunun hemen her yerinde zookeeper.out log dosyası görebilirsiniz. Bunun nedeni ZOOKEEPER_HOME/bin/zkEnv.sh dosyasının eğer aksi belirtilmediyse logları şu an çalışılan klasöre (cwd, current working directory) yönlendirmesidir. Örneğin Zookeeper servisini başlatırken /var klasöründe iseniz zookeeper.out dosyaları burada (/var/zookeeper.out olarak) oluşur. Bir sonraki başlatma işleminizde / dizininde iseniz burada (/zookeeper.out olarak) oluşur vs. derken karmaşık hale gelebilir.

Kendi içinde halletmesi yerine bir kaç satır konfigürasyon yaparak yönlendirmeyi istediğimiz klasöre yapabiliyor oluruz.

# opsiyonel olarak zookeeper.out loglarini istediginiz klasore yonlendirebilirsiniz
# oncelikle log klasorlerini olusturalim
sudo mkdir /var/log/zookeeper1
sudo mkdir /var/log/zookeeper2
sudo mkdir /var/log/zookeeper3

# Zookeeper servisini hangi kullanici ile başlayacaksak o kullaniciya klasor sahipligini verelim
sudo chown mustafakirimli:staff /var/log/zookeeper*

# Ve Zookeeper' a loglari yonlendirecegi yeri soylemesi icin zookeeper-env.sh dosyasina konfigurasyon girelim
# not: bu dosya standart kurulumda bulunmaz, biz elle eklersek Zookeeper kontrol edecek, yoksa pass gececektir
echo "ZOO_LOG_DIR=/var/log/zookeeper1" > zookeeper1/conf/zookeeper-env.sh
echo "ZOO_LOG_DIR=/var/log/zookeeper2" > zookeeper2/conf/zookeeper-env.sh
echo "ZOO_LOG_DIR=/var/log/zookeeper3" > zookeeper3/conf/zookeeper-env.sh

Zookeepe’ı Çalıştırma

Kurulum ve konfigürasyon aşamaları bittiğine göre artık Zookeeper servislerimizi çalıştırabiliriz. Herhangi bir sırayla aşağıdaki komutları çalıştırdığımızda Zookeeper servisleri başlamış olacaktır.

./zookeeper1/bin/zkServer.sh start
./zookeeper2/bin/zkServer.sh start
./zookeeper3/bin/zkServer.sh start

Durdurmak için de yine aynı komuta stop parametresini göndermek yeterli olacaktır.

./zookeeper1/bin/zkServer.sh stop
./zookeeper2/bin/zkServer.sh stop
./zookeeper3/bin/zkServer.sh stop

Zookeeper’ı İzleme (Monitoring)

Zookeeper servisinin çalışıp çalışmadığını ve şu an hangi modda olduğunu öğrenmek için sunucu üzerinden zkServer.sh dosyasını veya sunucu dışından netcat (nc) komutunu kullanabilirsinizi.

./zookeeper1/bin/zkServer.sh status

JMX enabled by default
Using config: /Users/mustafakirimli/Desktop/zookeepers/zookeeper1/bin/../conf/zoo.cfg
Mode: follower

echo stats | nc localhost 2171

Clients:
 /0:0:0:0:0:0:0:1:61147[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 0/0/0
Received: 3
Sent: 2
Connections: 1
Outstanding: 0
Zxid: 0x300000001
Mode: follower
Node count: 5

Bunların dışında netcat (nc) ile gönderebileceğiniz 4 harf komutlarını Zookeper’ın sitesinde yer alan The Four Letter Words bölümünden inceleyebilirsiniz.

Zookeeper Konsolunu Kullanmak

Zookeeper’ın konsol arabirimine erişmek için (cli) aşağıdaki komutu kullanabilirsiniz. Konsola giriş yaptıktan sonra burada Zookeeper üzerinde depolanan verileri kolaylıkla görebilirsiniz. Zookeeper verileri kolay anlaşılabilmesi için hiyerarşik yapıda (dosya/klasör standartında) depoluyor. Örneğin konsola iken “ls /” komutu ile Zookeper’in root dizininde yer alan dosya ve klasörleri listeleyebilirsiniz. Create ile klasor (node) oluşturabilir, set ile klasore veri yazabilirsiniz.

Kafa karıştırmaması gereken nokta her klasor (node) hem veri hem de alt klasor (node) barındırabiliyor. get komutu ile klasor (node) verisini okurken, ls komutu ile alt klasorleri (node) listeleyebilirsiniz.

./zookeeper1/bin/zkCli.sh -server localhost:2171

[zk: localhost:2171(CONNECTED) 14] ls /
[zookeeper]

[zk: localhost:2171(CONNECTED) 15] create /servers Sunucular
Created /servers

[zk: localhost:2171(CONNECTED) 16] create /servers/asia Asya     
Created /servers/asia

[zk: localhost:2171(CONNECTED) 17] create /servers/europe Avrupa
Created /servers/europe

[zk: localhost:2171(CONNECTED) 18] ls /
[servers, zookeeper]

[zk: localhost:2171(CONNECTED) 19] ls /servers
[europe, asia]

[zk: localhost:2171(CONNECTED) 20] ls /servers/europe
[]

[zk: localhost:2171(CONNECTED) 21] ls /servers/asia  
[]

[zk: localhost:2171(CONNECTED) 22] get /servers
Sunucular
cZxid = 0x30000001f
ctime = Sat Aug 08 14:38:07 EEST 2015
mZxid = 0x30000001f
mtime = Sat Aug 08 14:38:07 EEST 2015
pZxid = 0x300000021
cversion = 2
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 9
numChildren = 2

[zk: localhost:2171(CONNECTED) 23] get /servers/asia
Asya
cZxid = 0x300000020
ctime = Sat Aug 08 14:38:18 EEST 2015
mZxid = 0x300000020
mtime = Sat Aug 08 14:38:18 EEST 2015
pZxid = 0x300000020
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0

Zookeeper’ ın N/2+1 Limiti

Zookeeper’ ı birden çok sunucu üzerine küme (cluster) olarak kurup çalışmak için bazı kısıtlamalar veya dikkat etmeniz gereken noktalar mevcut. Kümelemeyi salt çoğunluk yöntemi (quorum based) ile yönetmesinden dolayı, n/2+1 sunucu yeter sayısına ulaşmadığında seçim yapamamakta ve yanıt (hizmet) verememektedir. Bu sebepledir ki Zookeeper hizmeti kurulu makina sayısının yarısı çalışır durumda olmalıdır. Örneğin 5 sunucu üzerinde Zookeeper kurulu ise bu sunuculardan birinci ve ikinci sunucu durduğunda Zookeeper hizmeti çalışmaya devam eder, ancak üçüncü sunucu da durduğunda yani çalışan sunucu sayısı iki olursa Zookeeper hizmeti duracaktır.

Bu örnekle formülü aslında AŞAĞI_YUVARLA(n/2)+1 olarak yazmamızın daha doğru olacağını belirtmek gerekir. Türkçe olunca anlama güçlüğü çeken meslektaşlarımız için İngilizce halini de şöylece yazıyor olalım; ROUND(n/2)+1

Kaynak

• http://zookeeper.apache.org/
• https://en.wikipedia.org/wiki/Two-phase_commit_protocol
• https://en.wikipedia.org/wiki/Leader_election
• https://en.wikipedia.org/wiki/Single_point_of_failure
• http://stackoverflow.com/questions/10268583/how-to-automate-download-and-installation-of-java-jdk-on-linux

Apache Solr replikasyon kullanımına dair bu son yazımızda, daha önce incelemeye çalıştığımız başlıkları hem görselleştirerek işleyecek hem de kurulum anlatmak yerine replikasyonu kendi içinde tarştımaya açacağız.

Master Slave Replikasyon (1-n)

Bu kurulumda tüm sunucular master Solr sunucusuna bağlanıyor. Buradaki en büyük sıkıntı slave sunucu sayınız arttıkça master sunucuya gelen trafiğin darboğaz oluşturma ihtimalininde artmasıdır. İllaki bu kurulumu tercih edeceksek slave sunucuları aralık/sıklık (interval) ile değil oluşturduğunuz görev/kuyruklamalarla dakika aralığında senkronize etmeniz olacaktır. Örneğin, verilerin her 10 dakikada bir güncellenmesini istiyorsak ve 10 sunucumuz varsa her bir sunucuyu 1-2-3-..-9-10 dakikalarında güncelleme işlemine tabi tutmamız gerekir. Daha açık bir örnekle, birinci sunucunun saat 8 ‘deki senkronizasyon ayarları şu şekilde olmalı; 08:01, 08:11, 08:21, 08:31, 08:41, 08:51 …  Tabi ki unutulmaması gereken nokta, verilerin tüm sunucularda aynı anda güncellenme zorunluluğu bulunması farklı zamanlarla yapacağınız senkronizasyonlarda sorun çıkaracaktır.

Sunucular master sunucudan data çektiği gibi aynı şekilde solrconfig_slave.xml dosyasını çekiyor ve solrconfig.xml olarak kullanıyor. Replikasyona dahil edilmiş diğer dosyaları da olduğu gibi aktarıyor. Master sunucuda bulunan solrconfig.xml ‘i kullanmama nedenimiz o dosya içerisinde master sunucu konfigürasyonu bulunuyor olmasıdır. Gelen solrconfig_slave.xml dosyası içerisinde master’ın hangi sunucu olduğu da yer aldığından, slave sunucu senkronizasyon bilgilerine sahip olmuş oluyor.

Tek Repeater İle Replikasyon (1-1-n)

Bu konfigürasyon bir master sunucu, bir repeater sunucu ve istenilen sayıda slave sunucu (1-1-n) oluşacak şekilde çalışıyor. Bir önceki kuruluma göre (1-n) avantajı master network trafiğini master sunucu üzerinden alıp bu görevi repeater’a aktarmaktır. Böylece master sunucuyu uygulamadan gelen update vd. işlemleri işlerken darboğaz oluşması gibi sorunlardan uzak tutulmuş oluruz.

Bu kurulumun dosya replikasyonunda ise master sunucudan repeater’a giden iki solrconfig dosyası bulunuyor. Biri solrconfig_repeater.xml dosyası, repeater sunucu bu dosyayı solrconfig.xml olarak kullanıyor. İkinci dosya ise solrconfig_slave.xml, repeater bu dosyayı alıp aynen saklıyor ve slave sunuculara gönderiyor. Slave sunucular solrconfig_slave.xml dosyasını solrconfig.xml olarak kullanıyor.

Çoklu Repeater İle Replikasyon (1-n-n)

Bu kurulum ise bir master sunucu, istenilen sayıda repeater sunucu ve istenilen sayıda slave sunucudan (1-n-n) oluşuyor. Kurulumun çoklu repeater temelinde yapılmış olması ölçeklendirme konusunda kolaylık sağlayacaktır. Burada lokasyon bazlı, CDN ‘e benzer yapıda, repeater kullanımını anlatmaya çalıştık. Tabi ki farklı şemalar çıkarmak mümkün, amacımız sadece çalışma mantığını anlatmaya çalışmak. Bu kurulum (1-n-n) örneğinde de repeater veya slave sayımız artarsa yukarıda bahsettiğimiz gibi farklı zamanlarda senkronizasyon yapabiliriz. Master-slave, replikasyon vd. yöntemleri bir kenara bırakıp ölçeklendirme ile alakalı konuşacak olursak; 10′ lu sunucu sayılarıyla arama motorlarının mimarisini açıklamaya kalkmayacağız ama güncel verilerin arama sonuçlarında farklılık göstermesi, yük dengeleyicinin yönlendirmesine göre sorgunuzun farklı sunucularda işlenmesi nedeniyle, sonuçların değişkenlik göstermesi buna benzer nedenlerdendir.

Bu kurulumun (1-n-n) konfigürasyon dosyaları replikasyonu ise hemen hemen bir öncekine benzemekte. Ayrıldığı tek nokta tüm konfigürasyonu master sunucu üzerinden yönetirken herhangi bir slave sunucunun hangi repeater sunucuya bağlanacağını belirleme zorunluğumuzdur. Bunun için her repeater sunucu üzerinde solrcore.properties_slave dosyası oluşturup repeater seviyesinden sonra bu dosyayı da replikasyona dahil etmemiz gerekir. Slave sunucuya yapılan replikasyon sonrasında bu dosya solrcore.propertiesolarak, solrconfig.xml dosyasında bu şekilde tanımlamıştık, kaydedilecek ve slave sunucu üzerinde bulunan solrconfig.xml dosyası ${solr.core.master_url} değişkenini bu dosyadan okuyup hangi repeater sunucuya bağlanacağını anlamış olur.

Sonuç

Bir önceki yazıda anlattığımız replikasyon ve repeater kullanımına bu yazıda şemalarla yer verip biraz daha netleşmesini amaçladık. Tek başına yük devretme (fail-over), daha gelişmiş merkezi konfigürasyon yönetimi, çoklu master yapısı vd. özellikleri içeren cloud ile yarışamıyor olsa da kısmen cloud’un da replikasyon kullanıyor olması dolayısıyla incelemiş olduk.

Kaynak

Yazıdaki şemaları http://www.digikey.com/schemeit aracını kullanarak oluşturduk. Teşekkürü borç biliriz.

Kullanılan şemaların düzenlemeye açık haline aşağıdaki adreslerden ulaşabilirsiniz. İyi niyetli kullanıcıları tenzih ederek amacı dışında kullanılmamasını rica ediyoruz

http://www.digikey.com/schemeit/#q8h (1-n)
http://www.digikey.com/schemeit/#q8g (1-1-n)
http://www.digikey.com/schemeit/#q8b (1-n-n)

Bilenleri tenzih ederek replikasyon nedir diye değinecek olursak; Datanın bir kaynaktan diğerine aynen, değiştirmeden ve parçalara ayırmadan, kopyalanması diyebiliriz. Buna, benzer çalışma mantığı olan disk aynalama (disk mirroring) standardı RAID 1′ i  örnek olarak gösterebiliriz. Tabi ki bazı RAID denetçileri parçalı okuma yapabiliyor ama konumuzun bu olmaması ve “RAID 1′e benzer” dememiz nedeniyle daha fazla üzerinde durmuyoruz. Tekrarlayıcıları ise network darboğazı (network bottleneck) oluşmaması için ana (master) sunucuya yardım eden sunucular olarak düşünebiliriz. Solr ‘a bulut (cloud) özelliği eklendikten sonra tek başına pek tercih edilmiyor olsa da fikir vermesi açısından ve pratik yapmak için replikasyonu -en azından- denemek yararlı olabilir. Yazının devamında ana sunucuyu master, takipçi sunucuyu slave, tekrarlayıcıyı da repeater olarak adlandıracağız.

Apache Solr Replikasyonu Nasıl Çalışır?

Solr’ ı replikasyon ile kulanırken bir master sunucu ve buna bağlı n tane slave sunucu kurarak çalıştırabiliriz. Slave sunucu sayısının çok olması ve/veya slave sunucuların master sunucuya yaptığı istekler network üzerinde darboğaz oluşturmaması için bazı slave sunucuları repeater olarak kullanabiliriz. Tüm bu iletişimi HTTP üzerinden ve Solr RequestHandler ‘larıyla  (RequestHandler konusunu daha sonra işleyeceğiz) yapar.

Solr, replikasyon yaparken master sunucudan öncelikle değişiklik listesini alır, daha sonra bu dosyaları geçici (tmp) dizinine indirmeye başlar ve tüm değişiklikler indirilene kadar indexlerde herhangi bir değişiklik yapmayıp sistemin çalışmaya devam etmesini sağlar. Replikasyon işleminin yarıda kesilmesi durumunda slave sunucu üzerinde tek kaybımız güncel verinin henüz uygulanmamış olması olur, bunun dışında gelen isteklere cevap vermeye ve çalışmasına normal olarak devam eder. Replikasyon işlemi kaldığı yerden devam edip indirilme tamamlandığında indexlere değişiklikleri uygular (yandaki resimde örnek replikasyon monitör görüntüsü mevcut).

Replikasyon kullanımı bize aynı anda tüm konfigürasyonları tek merkezden yönetme imkanı da sağlamış olur. Master sunucu üzerinde yaptığımız değişiklikler tüm slave sunucular tarafından çekilerek uygulanır. Böylece tüm slave sunucularda tek tek konfigürasyon ayarlamaya çalışmak zorunda kalmayız. Burada isteğimiz dosyaları replikasyona ekleyebilme esnekliği bırakılması güzel bir özellik olarak göze çarpıyor. Ayrıca replikasyon sonrasında (aşağıda bahsedeceğiz) dosyayı salve sunucularda yeniden adlandırabilme (rename) imkanımız da mevcut.

Burada dikkat edilmesi gereken nokta Solr’ ı master/slave replikasyon yöntemi ile kullanırken okuma dışındaki değişiklik yaratan sorguların (update, delete vd.) tamamının master sunucuya gelmesi gerektiğidir. Slave sunuculara güncelleme sorgusu gelmesi durumunda hiçbir problem çıkmamakla birlikte o değişiklik/ekleme’ nin sadece o sunucuda görüneceği ve replikasyon işlemi yapıldığı anda master sunucudaki kayıtlar dışındaki değişikliklerin kaybolacağını bilmemiz gerekir. Ayrıca slave sunucuya güncelleme yaratan komutlar geldiğinde bir sonraki replikasyon işlemini master’dan tüm datayı yeniden çekeceği için uzatmış olursunuz.

Eğer replikasyon ile birlikte konfigürasyon yönetimini de (önerilen budur) aktif ettiyseniz slave sunucuların konfigürasyonunda replikasyona dahil edilmiş bir dosyada değişiklik yaptığınızda replikasyon işlemi sonrasında yaptığınız değişiklikler kaybolup master sunucudaki konfigürasyonlar geçerli olacaktır.

Replikasyon Ayarlarımız

Replikasyon konfigürasyonuna geçmeden neler yapmak istediğimizi çalışırken minimum kağıda veya tahtaya çizdiğimiz gibi tablo halinde listeleyelim. Üç ayrı kurulum yapıp biri master diğer ikisi slave sunucu olacak şekilde aşağıdaki değerleri kullanacağız. Tabloya başlıkları, dizgide takıntılı olmam nedeniyle göze hoş gelmediği gerekçesiyle eklemedim. Başlıklar “Sunucu Adı, Apache Portu, Apache Shutdown Portu, Master, Dizin Yolu” oluşuyor. Replikasyona özel ayarlara geçmeden yandaki tabloya göre yaptığımız kurulumların yapılıp (Apache Solr ve Tomcat Kurulumu yazısında olduğu gibi) ayrı ayrı çalıştığına emin olalım. Bunun için http://localhost:8081/solr http://localhost:8082/solr http://localhost:8083/solr adreslerinden Solr paneline erişebiliyor olmamız gerekiyor.

Eğer farklı sunucularda kurulum yapacaksanız tabi ki portlar aynı olabilir (hatta aynı olması önerilir). Her bir kurulum setine aynı portları verip diğer kurulumlardan ayırabiliriz. Mesela x sitesi için üç ayrı sunucuda 8081, y sitesi için de üç ayrı sunucuda 8082 portlarına kurulum yapmak gibi. Aynı şekilde dizinler de tüm sunucularda aynı yolda bulunması iyi olacaktır.

Apache Solr Replikasyon Master Sunucu Ayarları

Master (8081) sunucumuzda solr_home/collection1/conf/solrconfig.xml dosyasında <requestHandler name="/replication" class="solr.ReplicationHandler" > ile başlayan direktif içinde aşağıdaki değişiklikleri yapalım. Şimdilik sadece master ayarlarının yorumlarını kaldırıp aktifleştirdik.

  <requestHandler name="/replication" >
    <!--
       To enable simple master/slave replication, uncomment one of the 
       sections below, depending on whether this solr instance should be
       the "master" or a "slave".  If this instance is a "slave" you will
       also need to fill in the masterUrl to point to a real machine.
    -->
    <lst name="master">
        <str name="replicateAfter">commit</str>
        <str name="replicateAfter">startup</str>
        <str name="confFiles">schema.xml,stopwords.txt</str>
    </lst>
    <!-- 
       <lst name="slave">
         <str name="masterUrl">http://your-master-hostname:8983/solr</str>
         <str name="pollInterval">00:00:60</str>
       </lst>
    -->
  </requestHandler>

Burada replicateAfter direktifi hangi durum/olay sonrası verilerin replikasyona dahil edileceğini belirliyor. Alabileceği parametreler startup, commit ve optimize. En efektif olanı commit gibi duruyor. Optimize yüksek boyutlu indexlerde çok zaman aldığından replikasyon maliyeti artabilir. Tabi ki çok fazla dosya transfer olmaması gibi artı yanı da var. Bu sebeple duruma göre direktifi ayarlamak gerekiyor. Konfigürasyona verdiğiniz direktifteki ilgili olay gerçekleştiğinde master sunucu üzerinde replicable index versiyonu güncellenir ve böylece slave sunucular kendi index versiyonlarından güncel bir veri olduğunu farkedip replikasyon işlemi (bir sonraki başlıkta bulunan direktifler doğrultusunda) yaparlar.

Apache Solr Replikasyon Slave Sunucu Ayarları

Slave sunucularımızda (8082 ve 8083) solr_home/collection1/conf/solrconfig.xml dosyasında <requestHandler name="/replication" class="solr.ReplicationHandler" > ile başlayan direktif içinde aşağıdaki değişiklikleri yapalım. Şimdilik sadece slave ayarlarının yorumlarını kaldırıp aktifleştirdik ve master sunucumuzun adresini verdik.

   <requestHandler name="/replication" >
    <!--
       To enable simple master/slave replication, uncomment one of the
       sections below, depending on whether this solr instance should be
       the "master" or a "slave".  If this instance is a "slave" you will
       also need to fill in the masterUrl to point to a real machine.
    -->
    <!--
       <lst name="master">
         <str name="replicateAfter">commit</str>
         <str name="replicateAfter">startup</str>
         <str name="confFiles">schema.xml,stopwords.txt</str>
       </lst>
    -->
    <lst name="slave">
       <str name="masterUrl">http://localhost:8081/solr/collection1/replication</str>
       <str name="pollInterval">00:00:60</str>
    </lst>
  </requestHandler>

Tüm direktifleri tek tek işlemeyeceğiz ama pollInterval ‘in otomatik replikasyon işleminin ne sıklıkla yapılacağını (HH:mm:ss) bildirdiğini ve bu direktifi vermezseniz replikasyonu sadece ilgili komutu (urli) elle tetikleyerek gerçekleştirebileceğimizi bilmekte yarar var. Son olarak pollInterval direktifi -interval kelimesinden de anlaşılacağı üzere- zaman değil aralık/sıklık komutu alır. Yani 01:00:00 komutu saat 1′de değil her saat başı çalış anlamına gelmektedir.
Slave sunucularda bu değişikliği yapıp Solr’ı tekrar başlattığımızda ve http://localhost:8082/solr/#/collection1/replication http://localhost:8083/solr/#/collection1/replication adreslerine girdiğimizde yandaki resimde olduğu gibi replikasyon hakkında bilgi ve bazı komutları görebiliyor olacağız. Burada yer alan bilgiler solrconfig.xml içindeki direktiflerin yanı sıra master sunucudaki direktifleri de yansıtıyor. Master sunucuda replikasyonun aktif olup olmadığı (Settings Master: replication enable), master sunucuda hangi konfigürasyon dosyalarının replikasyona dahil olduğu (Settings Master: confFiles), master sunucu değişiklikleri hangi durumda replikasyona hazır hale getireceği (Settings Master: replicateAfter)

Bunun yanı sıra master ve slave sunucudaki index replikasyon durumlarını da versiyon numaralarıyla verir. Master sunucuda indexin hangi versiyonda olduğu (Index Master Searching). Master sunucuda replikasyona dahil edilen (replikasyon yapılabilir veriler) index versiyon numarası (Index Master Replicable). Slave sunucudaki index versiyonu, bu bilgi master’dan son değişiklikler alınırken kullanılıyor (Index Slave Searching)

Bu bölümle alakalı son olarak “replicate now” butonunun adından da anlaşılacağı üzere “replikasyonu şu an gerçekleştir” komutunu verdiğini (http://localhost:8082/solr/collection1/replication?command=fetchindex&wt=json urlini çağırarak) söyleyelim.

solrconfig.xml Dosyasını Replikasyona Ekleme

Slave sunucularda konfigürasyonları teker teker değiştirmek istemiyorsak (mesela pollInterval değerlerini değiştirmek istiyor olabiliriz) master sunucu üzerinde slave sunucularda kullanılmak üzere solrconfig_slave.xml adında dosya oluşturup (slave sunucu için yaptığımız konfigürasyonları içeren dosyanın aynısı olabilir) aşağıdaki direktifleri master sunucu (8081) üzerinde solr_home/collection1/conf/solrconfig.xml dosyasına yukarıda master konfigürasyonu kısmında anlattığımız gibi vermemiz yeterli olacaktır.

<str name="confFiles">schema.xml,stopwords.txt,solrconfig_slave.xml:solrconfig.xml</str>

Slave sunucu replikasyon monitör görüntüsü

Bu direktif slave makinelerce solrconfig_slave.xml dosyasını master sunucudan indir ve solrconfig.xml olarak kaydet olarak yorumlanır. Böylelikle slave sunucuların solrconfig.xml dosyasını master sunucudan güncellemiş oluruz. Yandaki resim master sunucudan solrconfig.xml dosyasını alan bir slave sunucunun replikasyon monitörü görüntüsüdür.

Dosyaların replikasyona dahil edilmesinde şöyle ilginç bir durum olduğunu bilmenizi isterim; dosyaların sunuculara gitmesi için replikasyonu tetikleyen bir işlem oluşması, commit veya optimize gibi, gerekiyor. Diğer bir ifadeyle; konfigürasyon dosyasında yapılan değişiklikler replikasyonu tetiklemiyor.

Apache Solr Replikasyon Repeator Sunucu Ayarları

Yukarıdaki 3 sunucu kurulumuna 10 sunucu daha ekleyip; 1 master, 2 repeater ve her bir repeater’a bağlı 5′şer sunucu (1,2,5) oluşturacaksak şu adımları izlememiz gerekir. Kurulum örneğini 13 sunucu üzerinden verme nedenim (1,1,n) kurulum konfigürasyonu ile (1,n,n) konfigürasyonunun çok farklı olması. Mesela 1,1,n kurulumunda repeater sunucusunda da herhangi bir dosya değiştirme zorunluluğunuzun olmaması gibi.

Bu kısım hakkında kusura bakmamanızı rica ediyorum, zira ayrı bir yazı başlığı gibi gelmesi ve kısa yoldan anlatamıyor olmam nedeniyle sadece kurulum adımlarını ve gereki konfigürasyonları yazıp bitirmek istiyorum.

Master sunucu üzerinde yapılacaklar;

solrconfig.xml:

...
<lst name="master">
  <str name="replicateAfter">startup,commit</str>
  <str name="confFiles">schema.xml,stopwords.txt,solrconfig_repeater.xml:solrconfig.xml,solrconfig_slave.xml</str>
</lst>
...

Yukarıdaki ayarlar, repeater sunucusu master’dan replikasyon yaparken solrconfig_repeater.xml dosyasını kendine solrconfig.xml olarak kopyalacak ve içerisinde de master url’i olmasından dolayı master’a otomatik olarak bağlanacak (bir önceki başlıkta işlediğimiz gibi). Repeater sunucusu solrconfig_slave.xml dosyasını olduğu gibi alıp bir işlem yapmayacak.

solrconfig_repeater.xml:

...
<lst name="master">
  <str name="replicateAfter">commit</str>
  <str name="confFiles">schema.xml,stopwords.txt,elevate.xml,solrconfig_slave.xml:solrconfig.xml,solrcore.properties_slave:solrcore.properties</str>
  <str name="commitReserveDuration">00:00:10</str>
</lst>
<lst name="slave">
  <str name="masterUrl">http://localhost:8081/solr/collection1/replication</str>
  <str name="pollInterval">00:10:00</str>
</lst>
...

Yukarıdaki ayarlar repeater sunucusunda solrconfig.xml dosyası olarak görünecek ve herhangi bir slave sunucu repeater’a replikasyon için bağlandığında solrconfig_slave.xml dosyasını kendine solrconfig.xml dosyası olarak kaydedecek. Ayrıca solrcore.properties_slave dosyasını da solrcore.properties olarak kaydedecek.

solrconfig_slave.xml:

...
<lst name="slave">
  <str name="masterUrl">${solr.core.master_url}</str>
  <str name="pollInterval">00:10:00</str>
</lst>
...

Repeater sunucudan alınan ve solrconfig.xml olarak kaydedilen solrconfig_slave.xml dosyası master_url olarak solr.core.master_url değişkeninden gelen değeri okuyacak.

Repeater sunucular üzerinde yapılacaklar;

solr_home/collection1/conf/solrcore.properties dosyası içine her repeater sunucusunun replikasyon url’ini yazalım. Mesela 8082 sunucumuz repeater ise aşağıdaki örnek uygun olacak;

master_url=http://localhost:8082/solr/collection1/replication

Slave sunucular üzerinde yapılacaklar;

Eklediğimiz herhangi bir slave sunucuyu ilk kurulumda istediğimiz bir repeater’a bağlamamız yeterli olacaktır. Diğer tüm konfigürasyonları repeater sunucudan devralacaktır. Repeater’a slave’i bağlama işlemini yazının başlarında anlattığımız yöntemle kolaylıkla yapabilirsiniz.

Repeater başlığı içinde yer alan tüm adımlar için bir defaya mahsus bir üst sunucuya slave olarak bağlanmanız gerekiyor, sonrasında tüm konfigürasyonlar ve veriler bir üst sunucudan gelmeye başlayacaktır. Tek istisna repeater sunucusu üzerinde master_url’i verdiğimiz solrcore.properties dosyasını oluşturmamız gerekmesi.

Sonuç

Konfigürasyonları replikasyona dahil ederken tabi ki tüm dosyaları replikasyona eklememiz çok daha mantıklı olacaktır. Yazıda çok fazla karmaşık olmaması açısından önemli 1-2 dosya üzerinden anlatma yolunu seçtim.

Solr replikasyonuyla deneysel kullanım dışında ilgilenmediğim için yanılıyor olabilme ihtimaliyle  beraber, master sunucusunu kapatırsanız ya da bir şekilde cevap veremez duruma gelirse slave sunucularda hiçbir problem çıkmıyor. Yandaki ekra görüntüsünde görüleceği üzere sadece invalid_master hatası alırsınız.

Sonuç olarak kendi tecrübelerime dayanarak replikasyon yönetmine yorum yapmam gerekirse en büyük eksikliğinin tek sunucuya güncelleme sorgusu gönderme zorunluluğunuzun olması diyebilirim. Bir sonraki yazıda inceleyeceğimiz bulut yönteminde herhangi bir sunucuya güncelleme isteği gönderebiliyorsunuz.

Kaynaklar

Replication
Disk Mirroring
RAID 1
Solr Index Replication
Solr Replication

Bu yazıda klasikleşen haliyle öncelikle kurulumundan başlayacağız. Ama bu defa apt, brew, port gibi paket yöneticileriyle* değil binary dağıtımlarıyla** gerekli tüm yazılımları bir klasörde çalışabilecek şekilde kuracağız.

Solr İçin Gerekli Yazılımlar

Solr, Java ile geliştirilen bir yazılım olduğundan çalışırken -en az- Java Sanal Makine (Java Virtual Machine, JRE)’sine ihtiyaç duyar. En az dedik çünkü debugging yapacaksak ve bazı karakter seti sorunlarından kurtulmamız için Java Geliştirme Kiti (Java Development Kit, JDK) kurmamız gerekir. Bunun dışında Solr’ ı çalıştırabilmek için dahili olarak gelen Jetty Web Sunucunu*** kullanabiliriz. Biz Tomcat ile kullanımını inceleyip kurulumu biraz detaylandıracağız. Ayrıca hemen her bilgisayarda kurulu olan JRE ‘yi kullanmak yerine sadece kurduğumuz Solr’ ın kullanacağı JRE konfigüre edeceğiz. Bir nevi (tam olmasa da) virtual environment (sanal ortam?) yapmaya çalışacağız. Böylece Solr’ ı istediğimiz herhangi bir Java sürümü ile ve tüm dosyaları tek klasörde toplayarak çalıştırabilecek hale geleceğiz. Bu aynı zamanda Solr üzerinde denemeler yapmak için de iyi bir yöntem. Ayrıca, replika**** ve cloud özellikleri için farklı kurulumlar yapıp kendi bilgisayarımızda bunları rahatlıkla denemiş oluruz. Bu ayrıca -çok nadir görülse de- sistem JRE güncellemelerinden olumsuz etkilenmemizin önüne geçer.

Toparlayacak olursak; Apache Tomcat,  Apache Solr, JRE (Java Runtime Environment) yazılımlarına ihtiyacımız olacak. Root dizinde (isterseniz masaüstü ya da tmp dizini de olabilir) solr4 adında bir klasör oluşturup ilgili yazılımları bu klasöre indireceğiz. Şu an yayında olan stabil sürümleri sırasyıla indirip sıkıştırılmış dosyaları açalım/çıkaralım ; Apache Solr 4.7.0,  Apache Tomcat 8.0.3, JRE ya da JDK (JDK kurulumu bu yazı kapsamında değil)

Yukarıdaki adımları uygulayıp arşiv/zip dosyalarını sildiğimizde /solr4/ klasörü şu klasörleri barındıracak;

• apache-tomcat-8.0.3/
• jre1.7.0_51/
• solr-4.7.0/

Tomcat ve JRE/JDK Kurulumu

Bizim örneğimizdeki versiyon ile belirtecek olursak, apache-tomcat-8.0.3/conf/server.xml dosyasını açıp <Connector port=”8080″ protocol=”HTTP/1.1″ yazan bölümü tomcat için hangi portu kullanmak istiyorsak port özelliğini buna göre değiştirelim. Varsayılan dışında bir kurulum yapmaya çalıştığımız için portu 8082 olarak set ediyoruz. Değişiklik sonrası ilgili satır <Connector port=”8082″ protocol=”HTTP/1.1″ görünümünde olacak.

Bir başka Tomcat ayarı ise yine aynı dosyada (apache-tomcat-8.0.3/conf/server.xml) Tomcat kapatma portunu (shutdown port) değiştirmek olacak. Bunu değiştirmezsek aynı anda çalışan birden fazla Tomcat kullanırken bir Tomcat’ i kapatmanız diğer Tomcat’lerin de durmasına neden olacaktır. İlgili ayar apache-tomcat-8.0.3/conf/server.xml dosyasındaki <Server port=”8005″ shutdown=”SHUTDOWN”> kısmında bulunan port özelliği değiştirmek olacaktır. Biz 8006 olarak set ettik. Değişiklik sonrasında şu şekilde görünecek; <Server port=”8006″ shutdown=”SHUTDOWN”>

Tomcat’ i kendi indirdiğimiz JRE versiyonuyla çalıştırabilmek için apache-tomcat-8.0.3/bin/setenv.sh dosyasını oluşturup içine “JRE_HOME=/solr4/jre1.7.0_51” yazmamız yeterli. Bu dosyayı oluşturmazsak Tomcat sistemin varsayılan JRE veya JDK path değişkenlerini okuyacaktır. Konsoldan yapmak için  echo “JRE_HOME=/tmp/solr4/jre1.7.0_51″ > /solr4/apache-tomcat-8.0.3/bin/setenv.sh

Mac kullanıcıları JRE ayarı için JRE_HOME=/solr4/jre1.7.0_51/Contents/Home şeklinde ayarlamaları gerekmekte.

JDK ile çalıştırmak isterseniz JAVA_HOME değişkenini ayarlamanız gerekiyor. Catalina, JRE_HOME ayarlanmamışsa JAVA_HOME değişkenini okuduğunu söylüyor (apache-tomcat-8.0.3/bin/catalina.sh dosyasındaki direktifleri okumanız faydalı olabilir).

Bu ayarı yaptıktan sonra tomcat sunucusu kendi halinde çalışabiliyor olacak. Tomcat sunucusunu Catalina servlet konteyner (servlet container) ayar klasörü oluşması için  başlatıp durduracağız. Bunu yapmak için apache-tomcat-8.0.3/bin/ klasörü altında bulunan .sh uzantılı dosyalara çalıştırma izni vermemiz (chmod +x ./apache-tomcat-8.0.3/bin/*.sh) gerekiyor. Daha sonra Tomcat’i çalıştırmak için ./apache-tomcat-8.0.3/bin/startup.sh durdurmak içinse ./apache-tomcat-8.0.3/bin/shutdown.sh komutlarını kullanıyoruz. Tomcat düzgün çalışıyorsa yukarıdaki kurulum ayarlarıyla erişmek için http://localhost:8082 adresine girdiğimizde yandaki resmi görebiliyor olmalıyız.

Solr Kurulumu

Solr kurulumuna Solr ile gelen kütüphaneleri Apache lib klasörüne kopyalayarak başlayabiliriz. solr-4.7.0/example/lib/ext/ içindeki tüm dosyaları apache-tomcat-8.0.3/lib/ klasörü içine kopyalayalım.

Solr data ve konfigürasyon dosyalarını tutacak bir klasör oluşturuyoruz. Klasör adı solr_home olsun. Bu klasörü oluşturduktan sonra /solr4/ klasörü şu şekilde görünecek.

• apache-tomcat-8.0.3/
• jre1.7.0_51/
• solr-4.7.0/
• solr_home/

Sonrasında Solr ile gelen örnek uygulamayı (solr-4.7.0/example/solr/ dizini içindeki her şeyi) solr_home dizinine kopyalayalım. Bu örnek uygulama Solr ‘a ait bir çok özelliğin konfigürasyonu bulundurduğu için yeni başlayanlar için çok faydalı olacaktır.

Bu konfigürasyonla Solr’ ın kütüphaneleri bulabilmesi için solr_home/collection1/conf/solrconfig.xml dosyası içinde <lib dir=”../../../ yazan kısmı <lib dir=”../../solr-4.7.0/ olarak değiştirelim.

Şimdi de Solr uygulamasını Tomcat’ e tanımlamaya (böylece Tomcat çalışırken deploy olmasını sağlamaya) çalışalım. Bunun için apache-tomcat-8.0.3/conf/Catalina/localhost/ solr.xml klasörü içinde solr.xml dosyası oluşturup içinde aşağıdaki konfigürasyonu yazalım;

<?xml version="1.0" encoding="UTF-8" ?>
<Context 
    docBase="/solr4/solr-4.7.0/example/webapps/solr.war"
    allowlinking="true"
    crosscontext="true"
    debug="0"
    antiResourceLocking="false"
    privileged="true">
  <Environment name="solr/home" override="true" type="java.lang.String" value="/solr4/solr_home" />
</Context>

Son olarak Solr uygulama ayarını da yapalım. Bunun için solr_home dizini içinde solr.xml dosyası oluşturalım ve içine aşağıdaki konfigürasyonu yazalım. Burada hostPort özelliğine Solr ‘ın kullanacağı portu yazıyoruz.

<?xml version="1.0" encoding="UTF-8" ?>
<solr persistent="true">
  <cores adminPath="/admin/cores" host="${host:}" hostPort="8082" hostContext="${hostContext:}">
    <core config="solrconfig.xml" name="collection1" instanceDir="collection1" schema="schema.xml" dataDir="data"/>
  </cores>
</solr>

Yukarıdaki işlemleri tamamladıktan sonra http://localhost:8082/solr adresine girdiğimizde yandaki resimde bulunan Solr yönetim arayüzü önümüze geliyor olması gerekiyor. Solr yönetim paneli anasayfasında Solr versiyonunu (solr-spec), Lucene versiyonunu (lucene-spec), JVM başlığı altında Java versiyonunu (Runtime), yine JVM başlığı altında Catalina pathlerini görebilirsiniz (Args). Bu bilgiler yukarıdaki kurulumu düzgün gerçekleştirip gerçekleştiremediğimizin doğrulaması olacak. Yandaki resimde /tmp klasörü altına kurulmuş bir Solr ‘ın yönetim paneli anasayfası görünmekte. Diğer direktifleri görmek/doğrulamak için http://localhost:8082/solr/#/~java-propertis adresini kullanabilirsiniz.

Solr Kurulum Scripti

Bu işlemleri konsoldan yapmak isterseniz gerekli komutlar aşağıdaki gibidir (kullanmadan önce sisteminizin yedeğini almanız önerilir). Ayrıca bir sonraki yazıda replika kurarken, daha sonra cloud kurulumunda shardening***** ile birlikte replika kurarken (4 ayrı server kurulumunu simüle edeceğiz) bu kod bize biraz yardımcı olacak.

############ kurulum icin basit ayarlar, istedigimiz sekilde degistirebiliriz ###########
export SOLR_DIR='solr4'      # tum uygulama, konfigurasyon ve datalarin olacagi klasor
export SOLR_PORT='8082'      # solr'i kullanmak istedigimiz port
export TOMCAT_MPORT='8006'   # tomcat yonetim portu
export SOLR_VER='4.7.0'      # kullanmak istedigimiz solr versionu
export TOMCAT_VER='8.0.3'    # kullanmak istedigimiz tomcat versionu 
export SOLR_HOME='solr_home' # solr'a ait data ve konfigurasyonlarin bulunacagi klasor 
if [ -d "/Applications/" ]
then
  export JRE_URL='http://download.oracle.com/otn-pub/java/jdk/7u51-b13/jre-7u51-macosx-x64.tar.gz'  # MacOS x64
else
  export JRE_URL='http://download.oracle.com/otn-pub/java/jdk/7u51-b13/jre-7u51-linux-x64.tar.gz' # linux x64
fi
############ kurulum icin basit ayarlar, istedigimiz sekilde degistirebiliriz ###########

mkdir $SOLR_DIR # solr klasorunu olustur
cd $SOLR_DIR    # solr klasorune gir

# solr klasorunu diger islemler icin degiskene set et
export MYHOME=`pwd` #echo $MYHOME 

# ilgili solr, tomcat ve jre versiyonunu indir
wget "http://www.eu.apache.org/dist/lucene/solr/$SOLR_VER/solr-$SOLR_VER.zip"
wget "http://www.eu.apache.org/dist/tomcat/tomcat-`echo $TOMCAT_VER |cut -d'.' -f1`/v$TOMCAT_VER/bin/apache-tomcat-$TOMCAT_VER.zip"
wget -O jre.tar.gz --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com" $JRE_URL jre.tar.gz

# indirilen zipli solr ve tomcat dosyalarini ac ve zipli dosyalari sil
unzip "apache-tomcat-$TOMCAT_VER.zip" && unzip "solr-$SOLR_VER.zip"
rm "apache-tomcat-$TOMCAT_VER.zip" && rm "solr-$SOLR_VER.zip"

# jre' yi arsivden cikart ve arsiv dosyasini sil
tar -xzvf jre.tar.gz && rm jre.tar.gz

# cikarlina jre klasorunu jre olarak yeniden adlandir
for file in jre*.jre; do mv "$file" "jre"; done

# sistem varsayilan JRE 'si yerine indirdigimiz jre'yi kullan
if [ -d "/Applications/" ]
then
  echo "JRE_HOME=$MYHOME/jre/Contents/Home" >  apache-tomcat-$TOMCAT_VER/bin/setenv.sh # MacOS x64
else
  echo "JRE_HOME=$MYHOME/jre" >  apache-tomcat-$TOMCAT_VER/bin/setenv.sh # linux x64
fi

# tomcat portunu istenilen portla degistir
sed -i.bak 's%%%g' apache-tomcat-$TOMCAT_VER/conf/server.xml

# tomcat/bin klasoru icindeki .sh uzantili dosyalara calistirma izni ver
chmod +x ./apache-tomcat-$TOMCAT_VER/bin/*.sh

./apache-tomcat-$TOMCAT_VER/bin/startup.sh # tomcat'i baslat
sleep 8 # tomcat'in hazir olmasi icin bir sure bekle (8 saniye)
./apache-tomcat-$TOMCAT_VER/bin/shutdown.sh # tomcat'i durdur

# solr ile gelen kutuphaneleri tomcat/lib klasorune kopyala
cp solr-$SOLR_VER/example/lib/ext/* apache-tomcat-$TOMCAT_VER/lib/

mkdir $SOLR_HOME # solr home klasorunu olustur

# solr ile gelen ornek solr uygulamasini solr home dizinine kopyala
cp -r solr-$SOLR_VER/example/solr/* $SOLR_HOME/

# solr'in basvuracagi kutuphane yolunu guncelle
sed -i.bak 's%

' > apache-tomcat-$TOMCAT_VER/conf/Catalina/localhost/solr.xml

# solr'i tek core ile calisacak sekilde konfigure et
echo '

' > $SOLR_HOME/solr.xml

 # tomcat'i baslat
./apache-tomcat-$TOMCAT_VER/bin/startup.sh

Sonuç:

Kurulum işlemi biraz kafa karıştırıyor gibi görünüyor olabilir, ayrıca paket yöneticilerini kullanarak tek komut ile yüklemeyi çok kolay gerçekleştirebilirsiz de. Bunu seçmeme nedenlerime gelince;

• Bilgisayardan anladığımı zannetsem de Ubuntu üzerinde bir çok JRE/JDK kurulu olmasına rağmen varsayılan JRE 1.6 ‘ya ayarlı olduğundan sürekli hata almam. .bash_profile vd. dosyaları, sembolik linkleri tek tek karıştırıp doğrusu set etmem gerekiyor muhtemelen ya da bilgisayarcı çağırmam gerekiyor
• Son uygulama sürümleri için işletim sisteminizi yükseltme zorunluluğu veya paket yöneticinizin sürümünü kullanmak zorunda kalmam,
• Tek bilgisayarda aynı anda birden çok kopya/örnek (instance) çalıştırmayı veya farklı Solr/Tomcat kombinasyonlarını test etmeyi istemem,
• Windows kullananlar için biraz daha platform bağımsız bir anlatım olmasını istemem (en azından hangi dosyalara path ve direktifler eklendiği anlaşılabiliyor)

Eğer kurulum yaptığım klasörü taşıdığımda da Solr çalışmaya devam etsin derseniz https://gist.github.com/mustafakirimli/9430373 adresindeki relative path ile konfigüre edilmiş kurulum scriptini kullanabilirsiniz.

Kaynak:

https://wiki.apache.org/solr/SolrInstall
https://gist.github.com/mustafakirimli/9416138
https://gist.github.com/mustafakirimli/9430373 (relative path ile)
http://en.wikipedia.org/wiki/Apache_Tomcat#Catalina

———————————————————————–
* Paket Yöneticileri
** Yazılım Dağıtımı
*** Jetty Web Sunucusu
**** Replika
***** Shard

Zamanım oldukça Solr hakkında öğrendiğim/uyguladığım birçok bilgi/yöntemi buradan paylaşmaya çalışacağım. Basit kurulumundan başlayıp (bu yazı hazır, önümüzdeki hafta yayında olacak), replica kurulum, cloud kurulum gibi adımlarla devam edip, daha sonra detaylı konfigürasyon yazıları (solr.xml, solrconfig.xml, schema.xml, zoo.cfg vd.) yayınlayıp örnek senaryolar üzerinden Solr optimizasyon konularını içeren yazıları da paylaşıp yazı dizisini tamamlamayı düşünüyorum.

Neden Arama Sunucusu* (otomatik tamamlama – auto complete)

Bu yazı tabi ki arama sunucusu kullanmayı düşünenler için ama yine de -tam cevabı olamasa da- kendi tecrübelerime dayanarak ifade etmeye çalışayım. Genellikle kullanıcı arama sorgularını veritabanı üzerinde LIKE kullanarak işleriz, text alanlarda da MATCH() AGAINST ile fulltext search yaparız. Hatta bazen SOUNDEX de kullandığımız olmuştur ve bunu basit bir eşleme işi için kullandığımı da söylemeden geçemeyeceğim.

Özellikle gelişmiş e-ticaret sistem ve/veya sitelerini teknik açıdan incelerseniz (Magento iyi bir örnek) sadece arama yapmak değil kullanıcı anlamaya ve yardımcı olmaya yönelik birçok optimizasyon yapıldığını rahatlıkla görebilirsiniz. Mesela arama kelimeleri için eşanlamlı sözcük listesi kullanılır. Kullanıcı sorgusu öncelikle bu kelimelerin olduğu tabloda taranır ve değiştirilerek yukarıdaki arama yöntemi ile devam edilir. Mesela kullanıcı Karnıbahar araması yaptığında biz bunu Karnabahar olarak değiştirip (düzeltme) aramayı bu şekilde sürdürürüz. Kullanıcı TV araması yaptığında Televizyon olarak yine bu tablo yardımıyla değiştiririz (eşanlamlı sözcük).

Bunun yanı sıra yine Magento üzerinde bir örneğini görebileceğiniz bazı performans ve optimizasyonlar görebiliriz. Buna en iyi örnek Magento catalogsearch_fulltext tablosudur. Bu tabloda ürün özelliklerinden aranmasını istediğiniz özellik değerleri yatay halde tek satırda tutulur. Çünkü özellikle biraz gelişmiş sistemler bile yönetim panelinde esneklik sağlamak için verilerin önemli bir kısmı düşey olarak tutulur. Hâl böyle olunca bunları tek bir tabloya alıp otomatik tamamlama (auto complete) sorgularını hızlandırmamız gerekir. Bu tablonun bir nedeni de (en azından MySQL ‘de) InnoDB arama motoru kullanan tabloda fulltext search index kullanamıyor olmanızdır.

Ayrıca arama kelimelerini dil işleyen bir sınıf/sistem üzerinden geçirip çekim ve yapım eklerini atarak aramaya devam etmek istiyor da olabiliriz.

Neden Arama Sunucusu (filtreleme/faceted search-navigation**)

İnternet üzerinde portallarda ve e-ticaret sitelerinde sıklıkla karşılaştığımız bir özellik olan filtreleme artık vazgeçilmez hale geldi. Ve IT olarak bu isteğe çözüm üretmek gibi bir yükümlülüğümüz var. Bu cümleden sonra iç içe yazılmış AND / OR sorguları gözümüzün önünde hemen canlandı sanki. Hele bir de çoklu seçim özelliği ile ürün sayıları eklenince kafalarımız biraz daha karışmaya başlıyor.

Kullanıcı A markalı ürünleri görmek istediğinde ekranda sadece A markalı ürünleri gösteriyorken bir başka marka da seçebilmesi için (seçimi/filtreyi genişletme, çoklu seçim) diğer markaları da göstermemiz gerekir. Bunun üzerine bir başka özelllik ile de (renk, fiyat vd) filtre yapmak istediğinde -bir çok projede- ürün listesindeki ürünleri ayrı, filtreleri ayrı sorgularla çekmek zorunda kalırız.

Bir başka en iyi örnek ise; kullanıcı Android Telefon araması yapıp ucuzdan pahalıya doğru sıraladığında önce direkt eşleşenleri kendi içlerinde sıralamak sonrasında tek tek eşleşenleri kendi içlerinde sıralamak gerekir. Bu arama da Telefon kelimesiyle eşleşen ama ucuz olan bir telefonun Android Telefon ile direkt eşleşen telefonlardan önce çıkmaması gerekir. ORDER BY FUNC(x) DESC, ORDER BY FUNC(x) DESC .. sorgusundan bahsediyoruz aslında. Bu, arama sunucularının sıralamadaki en basit özelliğidir, bunun için bile MySQL sunucumuzu filesort ‘a zorlamış oluyoruz (yanılmıyorsam).

Hangi Arama Sunucusu

Piyasada yaygın olarak kullanılan Apache Solr ve ElasticSearch var. İkisi de lucene tabanlı olup bazı özellik farkları bulunmakta. Biz Apache Solr ile devam edeceğiz. Özellik karşılaştırması için güzel bir site de mevcut. Solr vs ElasticSearch adresinden ulaşabilirsiniz.

Adresini şu an hatırlamadığım bir başka sitede okuma işlemlerinde Solr, yazma işlemlerinde ise ElasticSearch ‘ün hızlı olduğunu okumuştum. Karar vermeden önce kendi testlerinizi yapmanızı öneririm.

Kaynak ve Ekstra Bilgi

Search Engine Indexing
Faceted Search
Inverted Index
N-gram
Apache Lucene
Apache Solr
Elasticsearch
—————————————————————–
* Arama moturu olarak da adlandırılmasıyla birlikte hem Google, Yahoo, Bing gibi sitelerle karıştırılmaması hem de arama algoritması, indexleme yazılımı gibi isimleri olması nedeniyle “Arama Sunucusu” olarak anıyoruz
** Türkçe karşılığını bulamadığım için kusura bakmayın, ayrıca Magento bunu layered navigation adıyla anıyor

Bu yazıda, aslında birçok blog ve etkinlikte gerek yakinen tanıdığım/çalıştığım arkadaşlarımın gerekse sektörde bulunan tecrübeli meslektaşlarımın değindiği mesaj kuyruklama (messaging queue) konusuna bir de biz göz atacağız.

Mesaj (İş) Kuyruklamaya Neden İhtiyaç Duyarız

Birçok projede kullanıcıyla direkt bağlantısı olsun ya da olmasın çalıştırılması/yürütülmesi zaman alan bazı işlemler gerçekleştiriyoruz. Buna, sık telaffuz edilen kullanıcı kayıt (register) olduğunda email gönderilmesi örneğini verebileceğimiz gibi, kullanıcının istediği raporu hazırlama, yüklenen bir imajı farklı ebatlarda boyutlandırma, alınan sipariş/satış/rezervasyon gibi bilgilerin kullandığımız diğer yazılımlara aktarımı vb. örnekler de vermemiz mümkün.

Ayrıca sadece çalışması/yürütülmesi zaman alan işlemler değil; belirli aralıklarla çalışması gereken betikler ve üzerinde bir takım iş mantığı yürütüldükten sonra işleme alınması gereken  işlemler de gerekli olabilir.

Mesaj Kuyruklamayı Geleneksel Yöntemlerle Nasıl Çözeriz

Yukarıda saydığımız bu ve bu gibi işlemleri kullanıcıyı bekletmeden çalıştırmak için bir dizi önlemler/geliştirmeler almamız elbette mümkün. Bunlardan İlk akla geleni ve bizim de tecrübe ettiğimiz asenkron işlemi simüle etme yöntemidir. Bu yöntemde zamanlanmış görevler (linux için cron) kullanılarak yapılacak işler ilgili tablolardan zaman aralığı vd. bilgilere göre taranıp işlenir (son 5 dakika içindeki yeni kayıtları işlemek gibi). Bir diğer simüle yöntemi ise, bir önceki paragrafta yer alan işlemler (kayıt, sipariş/satış/rezervasyon vd) tamamlandığında bir kaynağa (dosya, sql, no-sql, memory) işlenmesi gereken iş olduğu bildirilip işleme devam edilir ve yine zamanlanmış görevler yardımıyla bunlar işlenir.

Bu yöntem ilk başlarda tabi ki kolay ve uygun görülebilir ama projenizin ikinci yılında 25 adet zamanlanmış göreviniz olduğunda gerek yönetim gerekse işletim maliyetleri açısından işiniz zora girmeye başlayabilir. Tek dezavantaj tabiki bu değildir aşağıdaki soru(n)ları da cevapsız bırakmayacak bir yazılım geliştirmeniz kaçınılmaz olacaktır;

• Yürütülme esnasında hata oluşursa tekrar denenmesi gerekir (tekrar deneme, retry)
• Bazı işler belirli önceliğe göre çalışması gerekebilir (önceliklendirme, priority)
• Bir işin önceliği düşük olsa bile uzun süre kuyrukta kalmaması gerekir (yaşlandırma, aging)
• İşlerin kısa sürede işleme alınması gerekir (sık aralıklarla çalışan cron)
• İki ayrı zamanlanmış görev (cron) aynı iş üzerinde çakışmaması gerekir
• X kaynağı aktarım yaparken bizden HTTP yetkilendirmesi istiyor
• Kuyrukları tek makinede işlemek yeterli olmuyor iki makine işlesin (ölçeklendirme, scaling)

İlk madde için; Hata durumunda diğer işlerin yürütülmesi sorun değilken diğer bir işte kesinlikle sonrakilerinde işlenmemesi gerekiyor olabilir.

Bunlardan özellikle son iki madde gerçekten çok önemli bir sorun teşkil ediyor. Zamanlanmış görevi uzun aralıklarla çalıştırırsanız (1-2 saat gibi) bu süre zarfında 3 tane iş olsa dahi işlenmeyecek, ama sık çalıştırırsanız ve yoğun iş kuyruğu oluşursa iki ayrı zamanlanmış görev aynı işi yapmaya başlayacak. Bunun önüne geçmek için zamanlanmış görev dosyasının sadece bir defa çalışması için “file lock” kullanacaksınız ama zamanlanmış görev dosyası hata fırlatırsa ve kilidi kaldıramazsa başka bir zamanlanmış görev çalışamayacak. Hatta bir defasında veritabanında tuttuğumuz iş (kuyruk) tablosuna is_locked alanı açtığımızı ve zamanlanmış görev çalışırken ilgili satırı işlemeden önce kilitlediğini itiraf etmem de iyi olacaktır.

Son madde için de -kendi kuyruklama yazılımımızı geliştirmeye çalıştığımız için- elbette bizim bir çözüm bulmamız gerekiyor; tek sayıları bir makine çift sayıları ayrı bir makine işlesin (maksimum iki makine tabi ki), random bir iş seçsin, random bir makineye atılsın, saniye bazında aralıklarla çoklu makine çalışsın vs. gibi.

Yukarıda yazılanların hepsinin tecrübe ile sabit olduğunu ve paragraf sayısını artırmanın da bir o kadar mümkün olduğunu bilmenizi isterim.

Ve elbette bunları yapmak bir şekilde mümkün görünüyor da olabilir, ama projemizin asıl amacı iş kuyruklamak ve bunları yönetmek değilse bırakalım bunu ilgili bileşen yapsın. Buna şöyle bakabiliriz; piyasada halihazırda onlarca veritabanı sunucusu var ve çoğunlukla açık kaynak ve biz kendi veritabanı sunucumuzu yazmak yerine -çoğunlukla- bunlardan birini kullanıyoruız.

Mesaj Kuyruklamayı Yeni Nesil* Yöntemlerle Nasıl Çözeriz

Yazının girişinde de bahsettiğim gibi kuyruklamanın nasıl kullanılacağına dair çokça döküman olması, yazının asıl amacı “nasıl kullanırız” yerine “neden kullanmalıyız” sorusuna cevap aramak olması ve  saatlerce zaman harcanmasına rağmen kod örneklerinin eksikliği, yetersiz bulmam vd. nedenlerle taslak olarak kalan 26 adet yazı sebebiyle bu kısmı çok uzun tutmayacağım.

Kısaca değinecek olursak; ihtiyacımız olan özelliklerin hemen hepsini karşılayan çözümler/yazılımlar mevcut. Bunlardan birini seçerek başlamak ve proje geliştirme sürecinde iş kuyruklamayı da göz önünde bulundurmak iyi olacaktır. Sonrasında ilgili yerlerde mesaj kuyruklama yazılımına işi -varsa nevi ile birlikte bildirmek- ve listener (consumer) aracılığıyla kuyruğa gelen işleri işlemek olacaktır.

Yazıyı, “neden kullanmalıyız” sorusuna cevap arama kapsamında tutup burada noktalamak istiyorum. Kesin olmamakla birlikte mesaj kuyruklama bileşen/yazılımlarının bize sayfadığı faydaları bir başka yazıda tartışabiliriz diye düşünüyorum.

Herkese keyifli çalışmalar,

* Yeni nesil diye adlandırıyor olmakla birlikte mesaj kuyruklamanın aslında hiç de yeni olmayan bir bileşen olduğunu bilmenizi isterim.

Django kurmadan önce virtualenvironment ile “sanal geliştirme ortamı” kurmalıyız. İstediğiniz herhangi bir dizine kurabilirsiniz. Benim seçtiğim dizin :

~/project/

Bu dizine

virtualenv hastatakip

komutu ile yeni virtual environment ortamı oluşturuyoruz. Bu komut sonrasında dizine aşağıdaki dosyalar oluşmalı.

bin/
include/
lib/
local/

Kurmuş olduğumuz “virtual environment”ı aktif etmek için.

source ~/project/hastatakip/bin/activate

komutu çalıştırılmalı.  Virtual environment aktif edildikten sonra Django kurulumu yapabiliriz.  Djangoyu kurmak için

pip install django

komutunu yazıyoruz.  Böylece virtual environment altına django kurulumu yapmış olduk.

cd ~/project/hastatakip/
django-admin.py startproject hastatakip

komutu ile yeni django kurulumu yapılır.

cd hastatakip

komutu ile yeni oluşturulan django dizine geçtikten sonra

python manage.py runserver

komutu ile yeni projenizi çalıştırıyor olmanız gerekiyor. Hatasız çalıştığını varsayıyorum. O halde

http://127.0.0.1:8000/ adresinde django projenizi görüntülüyor olmalısınız.

Django ile kurulmuş projenizde her defasında virtual environment’ı ve djangoyu çalıştırmak için uzun kodlar yazmanız zor olabilir. Bunun için şöyle küçük kısayollar işinizi kolaylaştıracaktır.

Aşağıdaki 3 satırı  ~/.bashrc dosyasına ekleyelim.

alias hasta='cd ~/project/hastatakip/hastatakip; source ~/project/hastatakip/bin/activate'
alias hastarun='cd ~/project/hastatakip/hastatakip; source ~/project/hastatakip/bin/activate; python manage.py runserver;'
alias hastashell='cd ~/project/hastatakip/hastatakip; source ~/project/hastatakip/bin/activate; python manage.py shell;'

source ~/bashrc

komutunu çalıştırdıktan sonra

hasta

komutu hastatakip projesi dizinine gidecek ve virtualenvironment’ı aktif edecek.

hastarun

komutu hastatakip projesi dizinine gidecek ve virtualenvironment’ı aktif edecek ve djangoyu çalıştıracak.

hastashell

komutu hastatakip projesi dizinine gidecek ve virtualenvironment’ı aktif edecek ve djangoyu shell’i çalıştıracak.

Artık hastarun diyerek projemizi

pip freeze

komutu yaklaşık ise şu sonucu veriyor olmalı.

Django==1.6.1
argparse==1.2.1
wsgiref==0.1.2

Django ile bir arkadaşım için yazdığım hasta takip uygulaması Ubuntu 13.10 üzerinde geliştirdim. Ubuntu versiyonunuzu görmemin yollarını şu sayfadan öğrenebilirsiniz. Kod geliştirme için hiç IOS  kullanmadım ama Windows ile Linux kıyaslamasında Linux bir çok yönü ile açık ara önde bence. Linux tabanlı işletim sistemleri arasında ise Ubuntu tercih etmemin sebebi ise uygulama kütüphanesinin uyumluluğu ve stabiletesi diyebiliriz ve ayrıca alışkanlık Diğer Linux Dağıtımları için şu sayfaya göz atabilirsiniz.

Kod Editörü olarak Sublime Text 2.0.2 kullandım. Sublime çok severek kullandığım bir uygulama değil. Hatta sublime için gerçek anlamda bir editör demek zor. Fakat kullanımındaki basitliği, hızı ve python için geliştirilmiş trial kullanılanabilen uygulamanın çok fazla olmaması Sublime’ı ön plana çıkarıyor.

Versiyon kontrol sistemi için ise git kullandım. Linux işletim sistemi geliştiricisi  Linus Torvalds tarafından 2005 yılında tasarlanan git versiyon kontrol sistemi, biz yazılımcıların hayatında gerçekten bir devrim oldu. git ‘in 1.8.3.2 versiyonu kurulu ubuntu üzerinde. Git reposu olarak ise ücretsiz özel repo vermesi sebebi ile bitbutket kullandım.

Python kütüphanelerinin stabilitesini kontol etmek için virtualenvironment ve pip kullandım.  Virtualenvironment kurduktan ve aktif ettikten sonra pip ile kurduğumuz her paket o sanal ortama özgü olur. Virtual environment hakkında Cihan Okyay’ın şu yazısını okuyabilirsiniz. Python pip hakkında ise şöyle bir yazım var. Python 2.7.5 versiyonu kurulu bilgisayarımda.

Python ve django kurulumlarını bu yazı dizisinin içeriğine almadım. Başka makalelerden bulunabilir.  O nedenle bu yazıyı burda noktalıyorum. Nokta.

Yazmaya başladım bile hatta. Yazdıkça da, burada paylaşacağım.

Yazının uzun olacağını düşünerek, isimlendirerek bölümlere ayırdım  :

Bölüm 1 : Django İle Hasta Takip Yazılımı Yapmak – Platform

Bölüm 2 : Django İle Hasta Takip Yazılımı Yapmak – Django Kurulum

Aslında çok karmaşık bir konu değil ama bu konuda türkçe kaynak olmadığını görünce yazmak istedim.

En kısa tanımı ile pip bir paket yönetim yazılımıdır. python ile yazılmış paketlerin yönetimini pip ile yapabilirsiniz.

Diğer paket yönetim programları ( apt-get / aptitude … ) dururken neden pip kullanayım ki sorusu geliyor tabi insanın aklına. pip ‘in en önemli avantajı requirements dosyası ile birden çok paketin istenilen versiyonları ile kurulmasıdır.

Örneğin

sudo pip install -r requirements.txt

komutu ile requirements.txt dosyası ile verilen tüm paketler tek komut ile kurulabilir ve böylece paketler arası sürüm farklarından oluşabilecek olası problemlerin önüne geçilmiş olunur.

Örnek requirements.txt dosyamızın içeriği şu şekilde olabilir :

Django==1.3
Fabric==1.2.0
Jinja2==2.5.5
PyYAML==3.09
Pygments==1.4
SQLAlchemy==0.7.1
South==0.7.3

Böylece istediğimiz versiyonları içeren bir geliştirme ortamı oluşturabiliriz.

Eğer pip ile tek bir paket kurmak istersek

sudo pip install celery==3.1.7

veya celery paketinin son versiyonu için

sudo pip install celery

Ayrıca pip virtual-environment ile kullanıldığında tadından yenmez ama o başka bir yazının konusudur.

Kısaca pip budur. Aslında uzunca da budur.

Not: Fotoğrafın konu ile hiç alakası yok ama kedi ve bebek fotoğrafı her zaman ilgi çeker diye düşündüm. “Yazı bana birşey ifade etmiyor ama fotoğraf güzelmiş” diyecekler olur belkide. Zaten python pip’in logosu falanda yok