AWS’ye Geçiş Yapınca Veri Hattım Neden Bozuldu? Bir Mühendis Deneyimi.

Son birkaç aydır, tamamen kendi Windows makinem üzerinde çalışan küçük bir veri hattı oluşturuyordum. RSS içeriği WSL2 içinde çalışıyor, Postgres Docker içinde, Kestra tüm süreci yönetiyor, dbt verileri dönüştürüyor. Her parça çalışıyordu. Çalışan bir bağımlılık grafiğim vardı, testler geçiyordu, makaleleri getiren ve bunları veritabanına kaydeden planlı bir akış vardı.

Her şey çünkü her şey tek bir yerdeydi: benim dizüstü bilgisayarım.

Bu yazıda, bu hattı dizüstü bilgisayarımdan çıkarıp gerçek bir sunucuya taşımaya çalıştığımda neler olduğunu anlatacağım. Burada AWS’yi kullanmak yerine sadece komut satırını kullandım. Beklediğim en zor kısımın AWS’nin kendisi olacağını düşündüm: hesaplar, örnekler, ağ. Ancak sorun bu değildi. Sorun, “her şey aynı makinede çalışıyor” varsayımına dayanarak inşa ettiğim ve farkında olmadığım şeylerin bozulmasıydı. Bu varsayım, benim sandığımdan daha fazla iş yapıyordu ve bunu ortadan kaldırmak, her seferinde beklenmedik şekillerde sorunlara yol açtı.

Sunucuyu Kurmak

Dürüst olmak gerekirse, sunucuyu çalıştırmak en kolay kısım oldu.

Yeni $100’luk ücretsiz deneme sürümüne sahip bir AWS hesabı oluşturdum, kök kullanıcı yerine CLI için bir IAM kullanıcısı ayarladım (bu küçük alışkanlık, beni daha sonraki birçok sorundan kurtardı) ve t3.small boyutunda bir EC2 örneği Ubuntu 22.04 ile başlattım.

Yolda birkaç küçük sürpriz yaşandı. Bunlar büyük sorunlar değildi, ancak her şeyin aynı olmayacağını hatırlatıyordu. Örneğin, ilk çalıştırmada disk alanı yetersiz kaldı ve bu da 8GB’lık varsayılan diskin bile yeterli olmadığını gösterdi.

Sunucunun adresinin değişmemesi için bir Elastic IP atadım ve yalnızca kendi IP adresimin SSH (22), Kestra arayüzü (8080) ve Postgres (5432) portlarına erişebileceği şekilde güvenlik grubunu yapılandırdım. Bu, ev internet bağlantımın sabit bir IP adresi sağlamaması nedeniyle, her oturumda sunucuya bağlanmak için geçerli adresimi yeniden onaylamamı gerektirdi.

Bunların hiçbiri zor değildi. Sadece bu tür bir bilgisayar hakkında bilmem gereken birçok küçük ve özel bilgiyi öğrenmem gerekiyordu.

Veri Hattını Taşıtmak

Proje dosyalarını git yerine rsync ile taşıdım, çünkü .env dosyamda gerçek gizli bilgiler vardı. Docker’ı kurdum ve Kestra’yı başlattım.

Bir sürprizle karşılaştım: Kestra akışları, yerel olarak çalıştığım gibi bir dosyada saklanmıyordu. Akışlar, Kestra’nın kendi veritabanında saklanıyordu. Bu nedenle, sunucuya bağlandığımda akışı manuel olarak UI’dan yapıştırdim.

Akışı çalıştırdım ve hemen başarısız oldu.

Eksik Araçlar

Akış, Python betiğini çalıştırmak için bir Process görevini kullanıyordu. Bu, yerel olarak nasıl yapılandırdıysam aynı şekildeydi.

Hata, eksik bir paketti: python3.12-venv. Araştırmaya başladığımda, farkında olmadığım bir şeyi öğrendim. Process görevi Kestra’nın konteynerinde çalışmıyordu. Kestra’nın konteyneri Python’a sahipti, ancak sanal ortam oluşturmak için gereken parçaya sahip değildi.

Geçici olarak, Kestra konteynerine python3.12-venv’yi yükledim. Bu işe yaradı, ancak yeniden başlatıldığında kaybolacaktı. Kalıcı bir çözüm bulmalıydım.

Burada önemli bir karar vermem gerekti: Görevi Kestra içinde düzeltmek yerine, onu dışarı taşıdım ve Kestra’nın Docker görev yöneticisini kullandım. Fikrim şu şekildeydi: Kestra, Python işini çalıştırmak için ayrı bir konteyner başlatacak, betiği çalıştıracak ve konteyneri kapatacaktı. Bu, istediğim gibi çalışması gereken bir kurulumdu.

Ancak burada daha fazla karmaşıklıkla karşılaşacağımı bilmiyordum.

Yöneticinin Bilmediği Anahtar

Kestra’nın ayrı bir konteyner başlatabilmesi için, Docker demona erişebilmesi gerekiyordu. Bunu, Kestra konteynerine Docker soketini bağlayarak yapabilirsiniz:

Bu önemlidir, çünkü bu sokete sahip olan her şey, sunucuda herhangi bir şeyi çalıştırma yeteneğine sahiptir. Yerel olarak kendi bilgisayarımda bu hiçbir zaman gerçek bir ödünleşim değildi. Açık internette bulunan bir makinede ise önemli bir karardır. Bu öğrenme projesi için kabul edilebilir olduğunu düşündüm, ancak bu tür kararlar bilinçli olarak verilmelidir.

Soketi bağladım ve Kestra’nın Docker görev yöneticisini kullanmasını sağladım. Ancak burada da sorunlarla karşılaştım.

Bağlantı Olmayan Hacim

Sorunlar çözüldükten sonra, akış çalıştı ve yeni bir soruna rastladı: requirements dosyasını açamadı. Proje klasörünü konteynere bağlamıştım.

Bu en uzun deturdur. En sinir bozucu olanı, sessizce başarısız olmasıydı. Önce yanlışlıkla volume-enabled ayarını yanlış yere koydum. Sonra doğru ayarı yaptım ve yine çalışmadı.