Açık kaynaktan bulutta Hizmet olarak Veritabanına nasıl geldik?
90'ların sonlarından beri açık kaynak üzerinde çalışıyorum. Yirmi yıl önce veritabanları gibi açık kaynakları kullanmak o kadar kolay değildi. Kaynak kodunu indirmek, yamalamak, derlemek ve ancak ondan sonra kullanmak gerekiyordu.
Açık kaynak daha sonra bir dizi basitleştirmeden geçti:
Derlenmesi gereken Tar.gz ve INSTALL kaynakları;
.deb ve .rpm gibi bağımlılıklara sahip paketler; burada yalnızca bir dizi paketi yüklemeniz gerekir;
kurulumun otomatik olduğu APT ve YUM gibi paket depoları;
Docker ve Snap gibi dışarıya bağımlı olmadan kurulum yaparak paket almanızı sağlayan çözümler.
Sonuç olarak, açık kaynaklı yazılımların kullanımı kolaylaşıyor ve bu tür uygulamaların geliştirilmesine giriş engelleri de azalıyor.
Aynı zamanda, herkesin montaj uzmanı olduğu 20 yıl öncesindeki durumun aksine, artık çoğu geliştirici, kullandıkları araçları kaynaktan oluşturamıyor.
Aslında bu fena değil çünkü:
Daha karmaşık ama daha kullanıcı dostu yazılımlar kullanabiliriz. Örneğin, bir tarayıcının kullanımı uygundur, ancak birçok açık kaynak bileşeni içerir ve sıfırdan oluşturulması sakıncalıdır.
Daha fazla kişi açık kaynak ve diğer yazılımların geliştiricisi olabilir, işletmeler tarafından daha fazla yazılım kullanılır ve buna olan ihtiyaç daha fazladır.
Dezavantajı ise basitleştirmedeki bir sonraki adımın bulut çözümlerinin kullanımıyla ilişkili olmasıdır ve bu da belirli bir satıcı bağımlılığına, yani tek bir tedarikçiye bağlanmaya yol açar. Biz basit çözümler kullanıyoruz ve sağlayıcılar da açık kaynak bileşenleri kullanıyor ancak aslında bunlar büyük bulutlardan birine çivilenmiş durumda. Yani, açık kaynağı (ve onunla uyumlu yazılımı) dağıtmanın en kolay ve en hızlı yolu, özel bir API kullanarak bulutlardadır.
Buluttaki veritabanları söz konusu olduğunda iki yaklaşım vardır:
Veritabanı altyapısını normal bir veri merkezinde olduğu gibi oluşturun. Yani, standart yapı taşlarını alın: bilgi işlem, depolama vb., bunlara Linux ve bir veritabanı yükleyin ve bunları yapılandırın.
Sağlayıcının bulut içinde hazır bir veritabanı sunduğu Veritabanını Hizmet olarak kullanın.
DBaaS şu anda hızla büyüyen bir pazar çünkü geliştiricilerin doğrudan veritabanlarıyla çalışmasına olanak tanıyor ve rutin işleri en aza indiriyor. Sağlayıcı, Yüksek Kullanılabilirlik ve kolay ölçeklendirme, veritabanı düzeltme eki uygulama, yedeklemeler ve performans ayarlaması sağlamayı taahhüt eder.
Açık kaynağa dayalı iki tür Hizmet olarak Veritabanı ve Kubernetes biçiminde bir alternatif
Açık veritabanları için iki tür Hizmet olarak Veritabanı vardır:
Kolay dağıtım ve yönetim için yönetim arka ucunda paketlenmiş standart bir açık kaynak ürünü.
Açık kaynakla uyumlu, çeşitli eklentilere sahip gelişmiş bir ticari çözüm.
Her iki seçenek de bulutlar arasında geçiş olasılığını azaltır ve veri ve uygulamaların taşınabilirliğini azaltır. Örneğin, farklı bulut türlerinin temelde aynı standart MySQL'i desteklemesine rağmen aralarında önemli farklılıklar vardır: çalışma, performans, yedekleme vb. açısından. Bir buluttan diğerine geçiş, özellikle karmaşık uygulamalar için zorlayıcı olabilir.
Ve burada şu soru ortaya çıkıyor: Hizmet olarak Veritabanının rahatlığını basit bir açık kaynak çözümü olarak elde etmek mümkün mü?
Kötü haber şu ki ne yazık ki piyasada henüz böyle bir çözüm yok. İyi haber şu ki, bu tür çözümleri uygulamanıza olanak tanıyan Kubernetes var.
Kubernetes, bir uygulamayı tek bir ana bilgisayar yerine bir kümedeki birden fazla sunucuya dağıtmanıza ve yönetmenize olanak tanıyan, bulut veya veri merkezine yönelik bir işletim sistemidir.
Artık Kubernetes bu tür yazılımlar kategorisinde liderdir. Bu tür sorunlara birçok farklı çözüm vardı ama standart haline geldi. Geçmişte alternatif çözümlere odaklanan birçok şirket artık ürünlerini Kubernetes'i destekleyecek şekilde uyarlamaya odaklanıyor.
Ayrıca Kubernetes, birçok satıcının özel, genel ve hibrit bulutlarında desteklenen evrensel bir çözümdür; örneğin: AWS, Google Cloud, Microsoft Azure, Mail.ru Bulut Çözümleri.
Kubernetes veritabanlarıyla nasıl çalışır?
Kubernetes, başlangıçta mikro hizmetler veya web uygulamaları gibi verileri işleyen ancak hiçbir şey depolamayan durum bilgisi olmayan uygulamalar için tasarlanmıştır. Veritabanları spektrumun diğer ucundadır, yani durum bilgisi olan uygulamalardır. Ve Kubernetes başlangıçta bu tür uygulamalar için tasarlanmamıştı.
Ancak son zamanlarda Kubernetes'te veritabanlarının ve diğer durum bilgisi olan uygulamaların kullanımına izin veren özellikler ortaya çıktı:
StatefulSet kavramı, bölmelerin çalışmasını durdurma ve Kademeli Kapatma (uygulamanın öngörülebilir kapanması) uygulanmasıyla ilgili olayları işlemek için kullanılan bir dizi ilkelden oluşur.
Kalıcı Birimler, bölmeler ve Kubernetes yönetim nesneleri ile ilişkili veri depolarıdır.
Operatör Çerçevesi - yani, birçok düğüme dağıtılmış veritabanlarını ve diğer durum bilgisi olan uygulamaları yönetmek için bileşenler oluşturma yeteneği.
Şimdiden genel bulutlarda, arka ucu Kubernetes olan Hizmet olarak büyük Veritabanları var, örneğin: CockroachCloud, InfluxDB, PlanetScale. Yani Kubernetes üzerinde bir veritabanı sadece teorik olarak mümkün olan bir şey değil, aynı zamanda pratikte de işe yarayan bir şeydir.
Percona'nın Kubernetes için iki açık kaynak çözümü var:
MongoDB için Percona Sunucusunun Kubernetes Operatörü.
Kubernetes Operator for XtraDB CLUSTER, MySQL ile uyumlu, yüksek kullanılabilirlik ve tutarlılık sağlayan bir hizmettir. Örneğin bir geliştirme veritabanı için yüksek kullanılabilirliğe ihtiyaç duyulmuyorsa tek bir düğüm de kullanabilirsiniz.
Kubernetes kullanıcıları iki gruba ayrılabilir. Bazı kişiler Kubernetes Operatörlerini doğrudan kullanır; bunlar çoğunlukla teknolojinin nasıl çalıştığını iyi anlayan ileri düzey kullanıcılardır. Diğerleri bunu arka uçta çalıştırıyor - bu tür kullanıcılar Hizmet Olarak Veritabanı gibi bir şeyle ilgileniyorlar, Kubernetes'in nüanslarına dalmak istemiyorlar. İkinci kullanıcı grubu için başka bir açık kaynak çözümümüz var: Percona DBaaS CLI Aracı. Bu, teknolojiyi derinlemesine anlamadan Kubernetes tabanlı açık kaynaklı bir DBaaS almak isteyenler için deneysel bir çözümdür.
Percona'nın DBaaS'ı Google Kubernetes Engine'de nasıl çalıştırılır
Bana göre Google Kubernetes Engine, Kubernetes teknolojisinin en işlevsel uygulamalarından biridir. Dünyanın birçok bölgesinde mevcuttur ve platformu manuel olarak yönetmek yerine komut dosyaları oluşturmanıza olanak tanıyan basit ve kullanışlı bir Komut Satırı Aracına (SDK) sahiptir.
DBaaS'ımızın çalışması için aşağıdaki bileşenlere ihtiyacımız var:
Kubectl.
Google Bulut SDK'sı.
Percona DBaaS CLI.
Kubectl'i yükle
İşletim sisteminize uygun paketi kuruyoruz, Ubuntu örneğine bakacağız. Daha fazla detay burada.
Yazılım paketini de aynı şekilde kuruyoruz. Daha fazla detay burada.
# Add the Cloud SDK distribution URI as a package source
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg]
http://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
# Import the Google Cloud Platform public key
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
# Update the package list and install the Cloud SDK
sudo apt-get update && sudo apt-get install google-cloud-sdk
Percona DBaaS CLI'yi yükleme
Percona depolarından yükleyin. Percona DBaaS CLI Aracı hala deneysel bir ürün olduğundan deneysel depoda bulunur ve zaten Percona depolarınız kurulu olsa bile bunun ayrı olarak etkinleştirilmesi gerekir.
Öncelikle Google hesabınıza giriş yapmanız gerekiyor. Ayrıca Google Cloud, bir kullanıcının birçok bağımsız projeye sahip olmasına olanak tanır, dolayısıyla bu projenin kodunu kullanarak çalışan bir proje belirtmeniz gerekir:
gcloud auth login
gcloud config set project hidden-brace-236921
Daha sonra bir küme oluşturuyoruz. Demo için yalnızca üç düğümden oluşan bir Kubernetes kümesi oluşturdum; bu, yüksek kullanılabilirlik için gereken minimum değerdir:
Daha sonra bir namespace oluşturup onu aktif hale getiriyoruz. Ad alanı, kabaca konuşursak, aynı zamanda bir proje veya ortam gibidir ancak zaten bir Kubernetes kümesinin içindedir. Google Cloud projelerinden bağımsızdır:
Bu birkaç adımı tamamladıktan sonra şu basit komutla üç düğümlü bir küme başlatabiliriz:
# percona-dbaas mysql create-db example
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: example
Resource Endpoint: example-proxysql.my-namespace.pxc.svc.local
Port: 3306
User: root
Pass: Nt9YZquajW7nfVXTTrP
Status: ready
Bir kümeye nasıl bağlanılır
Varsayılan olarak yalnızca Kubernetes'te mevcuttur. Yani “Oluştur” komutunu çalıştırdığınız bu sunucudan erişilemiyor. Örneğin bir istemciyle yapılan testler için kullanılabilir hale getirmek için, bağlantı noktasını Bağlantı Noktası Eşleme yoluyla iletmeniz gerekir:
mysql -h 127.0.0.1 -P 3306 -uroot -pNt9YZquajW7nfVXTTrP
Gelişmiş küme yönetimi komutları
Genel IP'deki veritabanı
Küme kullanılabilirliği için daha kalıcı bir çözüm istiyorsanız harici bir IP adresi alabilirsiniz. Bu durumda veritabanına her yerden erişilebilecektir. Bu daha az güvenlidir ancak çoğu zaman daha kullanışlıdır. Harici IP için aşağıdaki komutu kullanıyoruz:
# percona-dbaas mysql create-db exposed
--options="proxysql.serviceType=LoadBalancer"
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: exposed
Resource Endpoint: 104.154.133.197
Port: 3306
User: root
Pass: k0QVxTr8EVfgyCLYse
Status: ready
To access database please run the following command:
mysql -h 104.154.133.197 -P 3306 -uroot -pk0QVxTr8EVfgyCLYse
Şifreyi açıkça ayarlayın
Sistemin rastgele bir şifre oluşturması yerine şifreyi açıkça belirleyebilirsiniz:
Bu, MySQL'i olabildiğince hızlı ve kolay bir şekilde çalışır hale getirmek, test etmek ve ardından kapatmak veya geliştirme için kullanmak amacıyla görevleri test etmeye yönelik bir çözümdür.
Percona DBaaS CLI aracı, Kubernetes'te DBaaS benzeri bir çözüm elde etmenize yardımcı olur. Aynı zamanda işlevselliği ve kullanılabilirliği üzerinde de çalışmaya devam ediyoruz.