Haz
12
    
Posted (serkan) in cloud, hosting, internet, server on Haziran-12-2009

GoGrid bir sanal sunucu sağlama servisi. ServePath tarafından kurulmuş. Bir aydan biraz daha uzun bir süre deneme fırsatım oldu. ServePath’in sağladığı standart dedicated sunucularla birbirine gayet güzel geçişip ortak iş çıkarabiliyor. GoGrid’in piyasadaki en temel rakibi Amazon Web Services (AWS). AWS üstünde çok fazla tecrübem olmadığından karşılaştırma yapamayacağım ama GoGrid’de neyi beğendim neyi beğenmedim değinmek istiyorum.

Web sitesinde görebileceğiniz gibi açılışta ödeme yapmadan deneyebilmeniz için 50$ kadar tüketim yapmanıza fırsat tanıyan ücretsiz bir kuponları var. Ancak yine de alışverişten önce müşteri temsilcisine web sayfalarındaki sohbet arabirimi üstünden ulaşıp bir şeyler sorarsanız size 100$ değerinde bir kupon teklif edecektir. Afiyetle tüketebilirsiniz. :) Ben öyle yaptım.

Kullanışlı olduğunu düşündüğüm bir kontrol paneli var. Sitedeki görüntüleri izleyerek fkir sahibi olabilirsiniz yanlız her ne kadar GoGrid yetkilileri kabul etmiyor hatta daha doğrusu anlam veremiyor olsalar da Türkiye’de konrol panelleri yavaş açılıyor. Bana farklı bir tarayıcı kullanmamı ya da modemimi kontrol etmemi söylediler ama bütün tarayıcılarda yavaş ve başka bir bilgisayarda (hatta başka hatlarda) denediğimde bile yavaşlık fark edilir düzeyde. Tabi panelde günlerinizi geçirmiyorsunuz. Sanal sunucunuzu başlatıp çıkıyorsunuz bu öyle dert edilecek birşey değil.

Yönetim paneli üstünden bir sanal sunucu başlatmak 5-15 dakika içinde mümkün oluyor. Bir kaç satır bilgi girip işinize yarayan işletim sistemini seçip biraz bekleyince sunucu tamamiyle hazır oluyor. CentOS, RHEL, Windows 2003 ve Windows 2008 kullanmak mümkün. Veritabanını ayrı bir sanal bilgisayarda tutmak isterseniz o durumda da aynı işletim sistemleri üstüne eklenen MySQL, PostgreSQL ve MS-SQL çözümleri var.

Yük degeleyici servisini tamamen bedavaya veriyor. AWS’de bunun için ayrı bir sanal makine ücreti ödemek gerek bu büyük bir avantaj. Hızlı bir şekilde bir yük dengeleyici onlarca web sunucusu ve bir veritabanı sunucudan oluşan bir küme kurmak çok kolay.

Yanlız bu konuda beni hayal kırıklığına uğrattıkları bir yer var. Tüm bilgisayarlara bağlanıp Linux konsolu ile rahatlıkla ulaşılabilen ilk 10GB’ı bedava olan Cloud Storage isimli bir depolama alanları var. Ben bu alanı web uygulamamın statik dosyalarını sunabilecek bir alan olarak sandım ilk önce. Ama ne yazık ki Apache tarafından erişilemez durumda ve bu alanda bulunan herhangi bir şeyin webe sunulması mümkün değil. Bu alan sadece yedekleme işlemi için. Ayrıca bir kere başlatıldımı kaldırılamıyor. Elbette kaldırılamıyor olması size bir şey kaybettirmiyor ama kontrol panelde kullanmadığım bir şeyi görmek benim sinirimi bozuyor.

Teknik servisteki eleman Cloud Storage biriminin Apache tarafından erişilebilir olması için mühendislerinin çalıştıklarını söyledi. Bu servis hayata geçmeden o alan web uygulamasının sunacağı statik dosyalar için kullanılamayacağından kullanıcılar için saklanan dosyalar için ayrı bir çözüm bulmak gerekecek. Çünkü birden fazla web sunucusunun merkezi bir veritabanı etrafında çalıştığı bir ortamda tüm kullanıcı verilerini web server üzerinde bulunan depolama alanında saklamak saçmalık olur. Oysa AWS kullanıyorsanız S3 servisi bu soruna çözüm oluyor. Elbette ücretli olarak çözüm oluyor ama zaten GoGrid de Cloud Storage alanını her zaman ücretsiz sunmak zorunda değil. Sağladığı alanı kullanamayınca ücretsiz olmasının bir mantığı yok. Tabi yedekleme işi için birebir olması ayrı bir konu.

GoGrid sunucuları kapatılabiliyorlar ama kapatmış olmanız o sunucu için para ödemiyor olmanız anlamına gelmiyor. Sunucuyu silene kadar ayrılmış bellek miktarına göre saatlik ödemenize devam ediyorsunuz. Çok hızlı bir şekilde diskteki her şeyi yedeklemek ardından kapatmak ve gerektiği zaman açıp kullanmaya devam etmek de pek mümkün olmadığından eğer sürekli açık tutmaya yetecek paranız yoksa GoGrid size göre değil.

Sunucular hangi bellek miktarı ile başlatılırsalar o miktarda kalıyorlar. Herhangi bir şekilde arttırılmasını talep etmeniz mümkün değil. Teknik servise bu durumu nasıl çözmem gerektiğini sorunca verdiği cevap hiç yoktan iyiydi. Diskte ne var ne yok yedeği alınır ve zaten bedava olan depolama alanına atılır. Sunucu silinir ve yeniden oluşturulur. Ardından yedeklenmiş kalıp tekrar sunucuya aktarılır. Bu arada kısa bir süre onarım için servis dışı kalınır.

Çalışan bir sunucuda bellek arttırımı yapabilmek için de çalışıyorlarmış. En azından müşterilerini dinliyor olmaları çok güzel. Yani bu hemen bugün olmasa bile ilerde bir gün yolum düşerse çekinmeden alışveriş yapabileceğim bir yer haline getiriyor GoGrid’i.

Sunuculardan e-posta yollamaya izin verme konusunda çok hassaslar. Size ne için e-posta yollamak istediğinizden elinizde bir e-posta adresi arşivi bulunup bulunmadığına kadar bir kaç soru soruyorlar. Verdiğiniz cevaplara göre e-posta yollama izni vermeme haklarını saklı tutuyorlar. Zaten kullanıcıya sağladıkları IP adreslerinden herhangi biri spam kara listelerine girerse direk 100$ gibi bir beden tahsil edeceklerini söylüyorlar. Spam hususunda çok hassaslar.

Hassasiyetlerini ve teknik destek kalitelerini sevdim. Zaten bir sunucu yapılandırma yardımına ihtiyacınız olursa bunu ayrıca ücretli olarak veriyorlar. Sunucuları bize göre uzakta bulunduğundan olsa gerek ben biraz yavaş olduğunu düşünüyorum ama bu konuda benim tespitlerime çok bel bağlamamanızı tavsiye ederim. Ciddi bir ölçüm yapma fırsatım olmadı. Tabi video sitesi falan kurup Türkiye’de hizmet vermek saçmalık olur. Buna eminim. :)


 
Haz
15
    
Posted (serkan) in alışveriş, hosting, internet on Haziran-15-2008

Uzunca süre kullandığım ama iki yıldır uğramadığım ElmaHost kapandığını açıklayınca, burada bahsetmeye değer diye düşündüm.

ElmaHost, ilk internet girişimimin (şimdiki adıyla yedinumara.net‘in) hayata gözlerini açtığı, genel anlamda iyi diye hatırladığım sıradan bir internet servis sağlayıcısı. Sunucusu Amerika’da bulunan bildiğim kadarıyla tek kişi tarafından yönetilen ve HostBul‘dan bulduğum bir şirket. Çok iyi hatırlıyorum HostBul’un ana sayfasına verdiği reklama tıklayarak ulaşmıştım ve çok düşünmemiştim. Ucuzdu. Elektronik posta yoluyla kısa sürede cevap alıyordum. Hatta bir bakıma bu özelliğinden etkilenmiştim. Ama o zamanlar hiç bir şey bilmiyordum. Kolay tavlanacak bir müşteri olduğum ortadaydı. Yarım Elma (50MB web alanı ve sanırım 3GB trafik hakkı) ile başladığım tüketime en son beş kat daha büyük bir paketle devam ederken son verdim. Neden?

Çünkü yeni seçenek daha ucuzdu. Dev gibi (halen %1′ini kullanamadığım) bir alan teklif ediyordu. Alanıma istediğim kadar projeyi birbirinden bağımısız ekleyebileceğimi söylüyordu. Hele hele öyle bir ilk açılış ücreti vardı ki ucuz demek yeterli değil. ElmaHost’a ödediğim fiyatın yarısını bile ödemeden dev gibi bir sunucum varmış gibi hissetmem mümkündü.

Sonuçta yedinumara.net veritabanındaki Türkçe karakter sorunlarını ortadan kaldırmak zorunda kalıp, bunun için bir hafta kadar uğraş verip yeni sunucuya taşındım. O sıralarda bloğumun ilk denemeleri ve onlarca başka proje için yeterince geniş alanım oluştu. Kısacası her şeyi daha ucuza veren birinin beni tavlaması zor olmadı. Veritabanımın bakımını yapmak için çektiğim zahmeti kredi kartımın ekstresini gördüğüm an unutuverdim bile.

Yarın bir başkası daha ucuza aynı servisi verirse ne yaparım? Bilmiyorum. Taşınma kolaylığına bağlı olarak değişir tabi ama sanırım şimdiki servis sağlayıcımın en büyük avantajı; taşımayı külfet sayacağım kadar çok web sitesini kendi üstünden sunmama sebep olmuş olması. O kadar çok alan veriyor ki kullanmadığınızda israf olduğunu düşünmeye başlıyorsunuz. Sağladığı ferahlık hissi yanında çekip gitmeniz zorlaştıkça zorlaştırıyor. Engelleyici bir özelliğin müşteri tarafından sevildiği nerede görülmüş?

Peki ElmaHost şimdiki servis sağlayıcımdan pahalı olmasına rağmen sağladığı 300-500MB’lık alanda ufak tefek siteleri açmak için sınırsız fırsat verseydi ne olurdu?

  • Öncelikle çok fazla deneme yapmayı seven benim gibi biri ile duygusal bir bağ oluştururdu. Bu bağ da kapandığı gün hüzünlenip bloğuna taşımak kadar önemsiz olmazdı. Benim daha uzun süre müşteri kalmamı sağlardı.
  • Alan dar kaldığı sürece hesabımı kimseyle paylaşmazdım ama ben yeni servis sağlayıcıma geçerken bunu yapabileceğimden zaten haberdar değildim ki. Bu eski servis sağlayıcımın bir eksiği sayılmazdı. Hatta o dönem, ne gerek var gigabytlelarca alana diye Gmail ile dalga geçtiğim bir dönemdi. Bu çeşit bir aç gözlülük yapmazdım.
  • ElmaHost’da hiç birşey değişmiyordu. Hem de hiç bir şey… Belki sadece düzgün çalışsın yeter diye düşünebilirsiniz ama bir bloğu olsaydı RSS’ye ekleyip beni arada varlığından haberdar etmesine müsaade ederdim. O zaman zihnimde daha çok yer tutardı.

ElmaHost başarısız bir girişim olduğundan mı yoksa başka kişisel sebeplerden mi kapandı bilmiyorum? Ama kayda değer bir başarıya sahip olsaydı kapatılmazdı herhalde değil mi?


 
Nis
14
    
Posted (serkan) in Google App Engine, django, hosting, internet, python on Nisan-14-2008

Google bu sefer gerçekten bahsedilmeyi hak ediyor. Ne OpenSocial‘ı duyunca ne de Android‘e sıra gelince buraya taşıma gereği duymadım ama App Engine biraz farklı.

Aslında (benim için) biraz farklı dememin tek sebebi halihazırda yapmakta olduğum bir çalışmaya denk gelmesinden yoksa Google babamın oğlu olduğundan falan değil.

Django ile çalışıp kullandığı paylaşımlı sunucunun kaynak tüketim politikasını zorlayan uygulamalar yüzünden ağırdan almak zorunda kalan biri olarak Google bana “buyur burada misafir edelim” deyince teklife göz atmamak olmaz.

Servisi daha bugün fark ettiğimden ve sadece belgeleri okuyup kendi bilgisayarımda denemeler yapma fırsatı bulduğumdan üstüne konuşmak için biraz daha zamana ihtiyacım var ama şimdilik iyi ki akıl etmişler demeden geçemiyorum.

Aslında herkesin rahatlıkla aklına gelebilecek Google’ı bir hosting sağlayıcıymış gibi gösterecek bir hizmet ama durum bununla sınırlı değil. Google kendi kurallarını koyduğu bir framework geliştirmiş. Django’dan bayağı esinlenmiş. Bunun yanında Django ve benzeri diğer Python kütüphanelerini de işin içine dahil edilebilir hale getirmiş. Hatta ilk versiyonun sadece Python ile yayınlanmasına bakmayın herkesin Python programcısı olmadığını biliyorlar. Benim ikinci dil tahminim Ruby.

İşin güzel tarafı Google tarafından sağlanan ölçeklenebilir veri merkezinin uygulama geliştiricilerinin hizmetine açılması. Yani elimizdeki uygulama çok fazla sistem kaynağı tüketiyor diye düşünmeyeceğiz. Düşünsek bile bunu Google’dan ücreti karşılığında satın alabileceğiz. Hobi projemiz büyüdü diye sunucu satın almak onu bakımını yapmak zorunda kalmayacağız.

Henüz deneyemediğim ama videolardan izleyerek öğrendiğim admin panelleri ise beni mest etti diyebilirim. Şuan üstünde çalıştığım web uygulamalarında karşılaştığım en büyük sorun birileri onları kullanırken nasıl yenileyebileceğimdir. Çalışan ve bir de üstünde kritik veriler tutan bir web uygulaması geliştiriyorsanız ve bir de siz tam bir şeyler değiştirmeye kalkacakken birilerinin onu kullanıyor olma ihtimali varsa nasıl güncelleme yaparsınız? Elbette yolu var ama ben pek zevk almıyorum bu işi yaparken. Hatta bu durum bende öyle önüne geçilmez bir korku oluşturdu ki çalışmalarımı iyice kararlı hale getirmeden yayına çıkaramıyorum. Bu aşırı mükemmeliyetçilik de çoğu zaman hiç bir şey çıkarmamak demek oluyor. İşte Google App Engine‘de buna çok basit bir çözüm var. Eğer yanlış anladığım bir kısım yoksa, App Engine’de yeni uygulamanızı yükleyin test edin ve eğer sorunsuz olduğunu görürseniz son kullanıcının yeni sürümü kullanmasını sağlayın. Bu arda ziyaretçiniz halen eski sürümle sanki hiç bir şey olmamış gibi hayatına devam edebilir. Daha ne isterim… (Bir an önce denemeyi tabi ki! Daha denemeden üstüne bu kadar konuşabildiğime göre herhalde en çok istediğim şey buymuş!)

Bir yandan da Sun Microsystems’ın network.com servisine rakip olduğunu düşünmüyor değilim. Basit moleküler deneyleri sıradan bir Genetikçi bile burada yazacağı web uygulamaları ile halledebilir. Sonuçta ihtiyaç duyulan işlemci gücünü Google ücreti mukabilinde sağlayacak ve Türk müşterilere tenezzül bile etmeyen Sun’da kedi ulaşamadığı ciğere mundar der misali “biz zaten yüksek güç tüketecek müşterilere bakıyoruz” diyecek. (Sun’ın hazır uygulama sağladığını ama Google App Engine’de uygulamanın sıfırdan geliştirilmesi gerektiğini de unutmamalı tabi.)

Belgeleri inceleyince özellikle Google hesaplarının web uygulamalarına entegre edilmesinin çok kolaylaştığını fark ettim. Hatta acaba ben de burada sunacağım bir uygulamada herkese yeni bir kullanıcı adı ve şifre vermek yerine zaten sahip oldukları Google hesaplarını kullanmalarına izin mi versem diye düşündüm? (Muhtemelen en az bir kere denerim de.) Ama bunun yanılmıyorsam taa 2001 yılında Microsoft tarafından Passport projesi ile hayal edildiği ve başarısız bir girişime çoktan dönüştüğünü unutmamalı. O zamanlar MS Passport ne kadar kullanışlı ve kolay geliştirilebilir bir üründü bilmiyorum ama bu sefer ki Google servisi (hele bir de bu kadar çok Google hayranı olduğu düşünülürse) kolaylıkla popüler olacak gibi duruyor.

Google App Engine’i denemeyi hemen hemen tüm Django kullanıcılarına tavsiye ederim. Django’nun çalışma prensibine benzer bir yapısı var zaten. Fazla kafa yormadan 5-6 saate neyin ne olduğunu kapmak mümkün ama tabi üstünde ciddi şekilde uygulama geliştirmeden çok şey söylemek zor. Hem bu bir PREVIEW RELEASE ve helen ilk sürümünde…


 
Şub
10
    
Posted (serkan) in django, hosting, internet, python on Şubat-10-2008

Daha önce yaparım dediğim bir şeyi ilk defa bu kadar erken başarıyorum. İşte WebFaction’da Django’yu en verimli şekilde kurma klavuzu.

WebFaction, Django için en uygun servis sağlayıcılardan biri. Panelden otomatik olarak uygulamanızı oluşturup hemen kullanmaya başlayabiliyorsunuz. Ancak bu durumda proje ismi myproject oluyor ki bu çok gıcık bir durum. Hele hele elinizde daha önceden yazılmış ve doğal olarak ismi myproject olmayan bir kod varsa bir şekilde var sayılan proje ismini değiştirmek zorundasınız. Elinizdeki kodu değiştirmek çok zaman alıcı olacaktır.

Benim adımlarımı teker teker takip etmeden önce panelin nasıl kullanıldığına ilişkin WebFaction Screencast‘ını izlemek çok iyi bir fikir.

Aslında anlatacağımın bir benzerini WebFaction forumunda İngilizce olarak bulmak mümkün. Ben de burada Türkçe anlatmayı seçtim. Onun tıpkısının aynısı değil ama ben de oradan öğrendim.

Önce projemizi oluşturalım.

Domain / websites > Applications sayfasında arborea isminde bir uygulama oluşturalım. İsim olarak başka bir şey seçerseniz her adımda arborea sözcüğü yerine seçtiğiniz ismi kullanmayı unutmayın. App type olarak ben Django (0.96) with Python (2.5) seçtim.

Domain / websites > Domains kısmına girip kendimize yeni bir alan adı veya alt alan adı ekliyoruz. Benim yaptığım, eklenmiş alan adlarımdan birine alt alan adı ön eki eklemekten ibaret oldu.

Domain / websites > Websites sayfasında ise alan adımızı ve uygulamamızı birbirine bağlayacağız. Alan adları arasından gereken(ler)i seçip hemen alttaki App açılır menüsünden arborea uygulamasını seçili hale getiriyoruz. Eğer seçtiğimiz alan ad(lar)ının herhangi bir alt dizinine bağlamak istemiyorsak URL path kısmına sadece / koyuyoruz. Eğer bir alt dizine koyacaksak /altdizinismi gibi yazmak gerekecek.

Tercih ettiğiniz FTP istemcinizi açın ve /home/kullanıcıadınız/webapps/arborea dizinine bilgisayarınızda daha önce geliştirdiğiniz arborea ismindeki projenizi gönderin. Sonuç olarak sunucuda üç farklı dizin (apache2, myproject, arborea) bulunmalı. Eğer halihazırda üretilmiş bir projeniz yoksa şimdi üretin ve yollayın. myproject isimli dizini değiştirmeyin. Yoksa içindeki dosyalarda da değişiklik yapmanız gerekir. Tercih sizin.

Daha sonra GNU/Linux konsolu ile veya Windows’ta Putty gibi bir uygulama ile ssh üstünden sunucuya bağlanmanız gerekiyor.

ssh kullaniciadiniz@web24.webfaction.com (Burada web24 yerine sizin sunucunuzun ön eki gelmeli.)

cd webapps/arborea
ls

…komutları ile apache2, myproject ve arborea diye üç dizinle karşılaşacaksınız. Yani FTP ile yükleme yaptığımız yere ulaştık.

Şimdi istediğimiz bir metin editörü ile httpd.conf üzerinde değişiklik yapmamız gerek. Ben emacs‘i tercih ediyorum siz nano vs. de kullanabilirsiniz.

emacs apache2/conf/httpd.conf

…komutu ile açıp

SetEnv DJANGO_SETTINGS_MODULE myproject.settings

satırını

SetEnv DJANGO_SETTINGS_MODULE arborea.settings

şeklinde düzeltmemiz gerekiyor.

Emacs kullandığımıza göre Ctrl+X Ctrl+S tuşlarına sırayla basarak kaydediyoruz ve ardından Ctrl+X Ctrl+C ile çıkıyoruz. (Çıkış sırasında kaydetmek isteyip istemediğimi sormasını hiç sevmem. :p )

Sunucumuzu yeniden başlatmamız gerek. Bulunduğumuz dizini değiştirmeden

./apache2/bin/restart

…komutunu kullanmamız yeterli.

Teorik olarak yapılması gereken başka işlem kalmadı ancak bu durum hiç bir statik dosya sunmayacaksanız geçerli. İçerisinde en azından bir tane resim dosyası bulunmayan web uygulaması olmayacağını düşünürsek işimizin bittiğini söyleyemeyiz.

WebFaction artık herhangi bir uygulama sayısı sınırı koymadığından Domain / websites > Applications sayfasında üreteceğiniz bir symbolic link uygulaması ile istediğiniz bir dizini webe açın. Bu dizinde de .gif, .css gibi tüm statik dosyalarınzı saklayın. İster bir alt alan adınıza ister bir alt dizininize Domain / websites > Websites sayfası aracılılığı ile bağlayın. Django projenizin settings.py dosyasında da MEDIA_ROOT ve MEDIA_URL değişikliklerini yaptıktan sonra statik dosyaları sunamamanız için herhangi bir sebep kalmayacak.

Unutmayın admin paneliniz de benzer şekilde dosyalar sunmaya ihtiyaç duyar. contrib/admin/media dizininizi buraya taşıyıp settings.py’deki ADMIN_MEDIA_PREFIX ayarı ile oynamayı unutmayın. Tabi isterseniz admin sayfasının statik öğelerini hiç taşımadan ona özel bir sembolik link uygulaması dahi oluşturabilirsiniz. Seçim tamamıyla size kalmış.