Kubernetes, Docker konteynerlerini kümelenmiş bir üretim ortamında çalıştırmak için harika bir araçtır. Ancak Kubernetes'in çözemediği sorunlar da var. Sık üretim dağıtımlarında, süreçteki kesintileri önlemek için tam otomatik bir Mavi/Yeşil dağıtıma ihtiyacımız var; bunun aynı zamanda harici HTTP isteklerini de karşılaması ve SSL aktarımlarını gerçekleştirmesi gerekiyor. Bu, ha-proxy gibi bir yük dengeleyiciyle entegrasyon gerektirir. Diğer bir zorluk ise bulut ortamında çalışırken Kubernetes kümesinin kendisinin yarı otomatik ölçeklendirilmesidir; örneğin geceleri kümenin ölçeğinin kısmen küçültülmesi.
Kubernetes bu özellikleri kutudan çıkarmasa da benzer sorunları çözmek için kullanabileceğiniz bir API sağlar. Açık kaynak temel alınarak oluşturulan Cloud RTI projesinin bir parçası olarak otomatik Mavi/Yeşil dağıtımı ve Kubernetes kümesinin ölçeklendirilmesine yönelik araçlar geliştirildi.
Bir video transkripti olan bu makale, üretimde kesinti olmadan bir git işleminden gelen kodu kabul eden, üretime hazır bir ortam oluşturmak için Kubernetes'i diğer açık kaynak bileşenlerle birlikte nasıl kuracağınızı gösterir.
Yani uygulamalarınıza dış dünyadan erişim sağladıktan sonra otomasyonu tam olarak kurmaya başlayabilir, yani git commit gerçekleştirebileceğiniz aşamaya getirebilir ve bu git commit'in üretime geçmesini sağlayabilirsiniz. Doğal olarak bu adımları uygularken, dağıtımları gerçekleştirirken kesintilerle karşılaşmak istemiyoruz. Yani Kubernetes'teki her türlü otomasyon API ile başlar.
Kubernetes, kutudan çıktığı haliyle verimli bir şekilde kullanılabilecek bir araç değildir. Elbette bunu yapabilirsiniz, kubectl vb. kullanabilirsiniz, ancak yine de API bu platformdaki en ilginç ve kullanışlı şeydir. API'yi bir dizi işlev olarak kullanarak Kubernetes'te yapmak istediğiniz hemen hemen her şeye erişebilirsiniz. kubectl'in kendisi de REST API'yi kullanır.
Bu REST'tir, yani bu API ile çalışmak için herhangi bir dili veya aracı kullanabilirsiniz, ancak özel kütüphaneler hayatınız çok daha kolay hale gelecektir. Ekibim bu tür 2 kitaplık yazdı: biri Java/OSGi için, diğeri Go için. İkincisi pek kullanılmaz ama her halükarda bu yararlı şeyler elinizin altındadır. Bunlar kısmen lisanslı açık kaynaklı bir projedir. Farklı diller için bu tür birçok kütüphane vardır, böylece size en uygun olanı seçebilirsiniz.
Bu nedenle dağıtımınızı otomatikleştirmeye başlamadan önce sürecin herhangi bir kesintiye maruz kalmayacağından emin olmanız gerekir. Örneğin ekibimiz, üretim dağıtımlarını insanların uygulamaları en çok kullandıkları gün ortasında gerçekleştiriyor; bu nedenle bu süreçte gecikmelerin önlenmesi önemlidir. Kesinti süresini önlemek için 2 yöntem kullanılır: mavi/yeşil dağıtım veya sürekli güncelleme. İkinci durumda, uygulamanın 5 kopyası çalışıyorsa bunlar birbiri ardına güncellenir. Bu yöntem harika çalışır ancak dağıtım işlemi sırasında uygulamanın farklı sürümleri aynı anda çalışıyorsa uygun değildir. Bu durumda, arka uç eski sürümü çalıştırırken kullanıcı arayüzünü güncelleyebilirsiniz ve uygulama çalışmayı durduracaktır. Bu nedenle programlama açısından bu tür koşullarda çalışmak oldukça zordur.
Uygulamalarımızın dağıtımını otomatikleştirmek için mavi/yeşil dağıtımı kullanmayı tercih etmemizin nedenlerinden biri de budur. Bu yöntemle uygulamanın aynı anda yalnızca bir sürümünün aktif olduğundan emin olmalısınız.
Mavi/yeşil dağıtım mekanizması şuna benzer. Uygulamalarımıza yönelik trafiği, aynı sürümdeki uygulamanın çalışan kopyalarına ileten ha-proxy aracılığıyla alıyoruz.
Yeni bir dağıtım yapıldığında yeni bileşenlerin verildiği ve yeni sürümün dağıtımını yapan Deployer'ı kullanırız. Bir uygulamanın yeni bir sürümünü dağıtmak, yeni bir kopya kümesinin "yükseltilmesi" ve ardından yeni sürümün bu kopyalarının ayrı, yeni bir bölmede başlatılması anlamına gelir. Ancak ha-proxy onlar hakkında hiçbir şey bilmiyor ve henüz onlara herhangi bir iş yükü yönlendirmez.
Bu nedenle öncelikle replikaların yüke hizmet vermeye hazır olduğundan emin olmak için durum denetiminin yeni sürümlerinin performans kontrolünün yapılması gerekir.
Tüm dağıtım bileşenlerinin bir tür durum denetimini desteklemesi gerekir. Bu, durumu 200 olan bir kod aldığınızda çok basit bir HTTP çağrı kontrolü veya kopyaların veritabanı ve diğer hizmetlerle bağlantısını, dinamik ortam bağlantılarının kararlılığını kontrol ettiğiniz daha ayrıntılı bir kontrol olabilir. ve her şeyin düzgün başlayıp başlamadığı. Bu süreç oldukça karmaşık olabilir.
Sistem güncellenen tüm kopyaların çalıştığını doğruladıktan sonra, Deployer yapılandırmayı güncelleyecek ve doğru confd'yi iletecek ve bu da ha-proxy'yi yeniden yapılandıracaktır.
Ancak bundan sonra trafik, yeni sürümün kopyalarının bulunduğu bölmeye yönlendirilecek ve eski bölme kaybolacaktır.
Bu mekanizma Kubernetes'in bir özelliği değildir. Mavi/yeşil dağıtım kavramı oldukça uzun zamandır ortalıkta dolaşıyor ve her zaman bir yük dengeleyici kullanıyor. Öncelikle tüm trafiği uygulamanın eski sürümüne yönlendiriyorsunuz, güncelleme sonrasında ise tamamen yeni sürüme aktarıyorsunuz. Bu prensip yalnızca Kubernetes'te kullanılmaz.
Şimdi size yeni bir dağıtım bileşenini tanıtacağım - Durum kontrolleri gerçekleştiren, proxy'leri yeniden yapılandıran vb. Deployer. Bu dış dünya için geçerli olmayan ve Kubernetes'in içinde var olan bir kavramdır. Açık kaynak araçlarını kullanarak kendi Deployer konseptinizi nasıl oluşturabileceğinizi size göstereceğim.
Yani Deployer'ın yaptığı ilk şey Kubernetes API'yi kullanarak bir RC çoğaltma denetleyicisi oluşturmaktır. Bu API, daha fazla dağıtım için pod'lar ve hizmetler oluşturur, yani uygulamalarımız için tamamen yeni bir küme oluşturur. RC, replikaların başladığına ikna olur olmaz, bunların işlevselliği üzerinde bir Sağlık kontrolü gerçekleştirecektir. Bunu yapmak için Deployer GET /health komutunu kullanır. Uygun tarama bileşenlerini çalıştırır ve kümenin çalışmasını destekleyen tüm öğeleri kontrol eder.
Tüm bölmeler durumlarını bildirdikten sonra Deployer, yük dengeleyici yapılandırmasının depolanması da dahil olmak üzere Kubernetes tarafından dahili olarak kullanılan yeni bir yapılandırma öğesi olan etcd dağıtılmış depolama oluşturur. Verilerietcd'ye ve yeni veriler için confdmonitorsetcd adı verilen küçük bir araca yazıyoruz.
Başlangıç konfigürasyonunda herhangi bir değişiklik tespit ederse yeni bir ayarlar dosyası oluşturur ve bunu ha-proxy'ye aktarır. Bu durumda ha-proxy, herhangi bir bağlantıyı kaybetmeden yeniden başlatılır ve yükü, uygulamalarımızın yeni sürümünün çalışmasını sağlayan yeni hizmetlere yönlendirir.
Gördüğünüz gibi bileşenlerin bolluğuna rağmen burada karmaşık bir şey yok. Sadece API ve vb.'ye daha fazla dikkat etmeniz gerekiyor. Sizlere kendi kullandığımız açık kaynak konuşlandırıcı Amdatu Kubernetes Deployer'dan bahsetmek istiyorum.
Kubernetes dağıtımlarını düzenlemek için kullanılan bir araçtır ve aşağıdaki özelliklere sahiptir:
- Mavi/Yeşil dağıtım;
- harici bir yük dengeleyici kurma;
- dağıtım tanımlayıcı yönetimi;
- fiili dağıtımın yönetilmesi;
- dağıtım sırasında Durum denetimlerinin işlevselliğinin kontrol edilmesi;
- ortam değişkenlerinin bölmelere uygulanması.
Bu Deployer, Kubernetes API'sinin üzerine kurulmuştur ve tanıtıcıları ve dağıtımları yönetmek için bir REST API'nin yanı sıra dağıtım işlemi sırasında günlük akışı için bir Websocket API sağlar.
Yük dengeleyici yapılandırma verilerini etcd'ye koyar, böylece hazır destekle ha-proxy kullanmanıza gerek kalmaz, kendi yük dengeleyici yapılandırma dosyanızı kolayca kullanabilirsiniz. Amdatu Deployer, Kubernetes'in kendisi gibi Go'da yazılmıştır ve Apache tarafından lisanslanmıştır.
Dağıtıcının bu sürümünü kullanmaya başlamadan önce ihtiyacım olan parametreleri belirten aşağıdaki dağıtım tanımlayıcısını kullandım.
Bu kodun önemli parametrelerinden biri “useHealthCheck” bayrağını etkinleştirmektir. Dağıtım işlemi sırasında bir sağlık kontrolü yapılması gerektiğini belirtmemiz gerekiyor. Dağıtımda, doğrulanması gerekmeyen üçüncü taraf kapsayıcılar kullanıldığında bu ayar devre dışı bırakılabilir. Bu tanımlayıcı aynı zamanda kopya sayısını ve ha-proxy'nin ihtiyaç duyduğu ön uç URL'sini de belirtir. Sonunda, bağlantı noktası yapılandırması, görüntü vb. hakkında bilgi almak için Kubernetes'i çağıran "podspec" bölme belirtimi bayrağı bulunur. Bu oldukça basit bir JSON tanımlayıcısıdır.
Açık kaynaklı Amdatu projesinin parçası olan bir diğer araç ise Deploymentctl'dir. Dağıtımları yapılandırmak için bir kullanıcı arayüzüne sahiptir, dağıtım geçmişini saklar ve üçüncü taraf kullanıcılardan ve geliştiricilerden gelen geri aramalar için web kancaları içerir. Amdatu Deployer'ın kendisi bir REST API olduğundan kullanıcı arayüzünü kullanamayabilirsiniz, ancak bu arayüz herhangi bir API gerektirmeden dağıtımı sizin için çok daha kolay hale getirebilir. Deploymentctl, Angular 2 kullanılarak OSGi/Vertx'te yazılmıştır.
Şimdi beklemenize gerek kalmaması için önceden kaydedilmiş bir kayıt kullanarak yukarıdakileri ekranda göstereceğim. Basit bir Go uygulamasını dağıtacağız. Go'yu daha önce denemediyseniz endişelenmeyin, çok basit bir uygulama olduğundan anlayabilirsiniz.
Burada yalnızca /health'e yanıt veren bir HTTP sunucusu oluşturuyoruz, dolayısıyla bu uygulama yalnızca sağlık kontrolünü test eder, başka hiçbir şeyi test etmez. Kontrol başarılı olursa aşağıda gösterilen JSON yapısı kullanılır. Dağıtıcı tarafından konuşlandırılacak uygulamanın sürümünü, dosyanın üst kısmında gördüğünüz mesajı ve uygulamamızın çalışıp çalışmadığını gösteren boolean veri türünü içerir.
Son satırda biraz hile yaptım çünkü dosyanın en üstüne sabit bir boole değeri yerleştirdim, bu gelecekte "sağlıksız" bir uygulamayı bile dağıtmama yardımcı olacak. Bununla daha sonra ilgileneceğiz.
Öyleyse başlayalım. Öncelikle ~ kubectl get pods komutunu kullanarak çalışan herhangi bir pod'un varlığını kontrol ederiz ve ön uç URL'sinden yanıt gelmemesine bağlı olarak şu anda hiçbir dağıtımın yapılmadığından emin oluruz.
Ekranda daha sonra bahsettiğim dağıtım parametrelerinin ayarlandığı Deploymentctl arayüzünü görüyorsunuz: ad alanı, uygulama adı, dağıtım sürümü, kopya sayısı, ön uç URL'si, kapsayıcı adı, görüntü, kaynak sınırları, durum kontrolü için bağlantı noktası numarası, vb. Kaynak sınırları çok önemlidir çünkü mümkün olan maksimum donanım miktarını kullanmanıza olanak tanır. Burada Dağıtım günlüğünü de görüntüleyebilirsiniz.
Şimdi ~ kubectl get pods komutunu tekrarlarsanız, sistemin 20 saniye boyunca "donduğunu" ve bu sırada ha-proxy'nin yeniden yapılandırıldığını görebilirsiniz. Bundan sonra pod başlar ve kopyamız dağıtım günlüğünde görülebilir.
Videodan 20 saniyelik beklemeyi kestim ve artık uygulamanın ilk sürümünün devreye alındığını ekranda görebilirsiniz. Bütün bunlar yalnızca kullanıcı arayüzü kullanılarak yapıldı.
Şimdi ikinci versiyonu deneyelim. Bunu yapmak için uygulamanın "Merhaba Kubernetes!" mesajını değiştiriyorum. “Merhaba, Deployer!”da sistem bu imajı oluşturur ve Docker kayıt defterine yerleştirir, ardından Deploymentctl penceresinde tekrar “Dağıt” düğmesine tıklamamız yeterlidir. Bu durumda dağıtım günlüğü, uygulamanın ilk sürümü dağıtılırken olduğu gibi otomatik olarak başlatılır.
~ kubectl get pods komutu, uygulamanın şu anda çalışan 2 sürümünün olduğunu gösterir, ancak ön uç, hala sürüm 1'i çalıştırdığımızı gösterir.
Yük dengeleyici, trafiği yeni sürüme yönlendirmeden önce durum denetiminin tamamlanmasını bekler. 20 saniye sonra curl'a geçiyoruz ve artık uygulamanın 2. sürümünün konuşlandırıldığını ve ilkinin silindiğini görüyoruz.
Bu “sağlıklı” bir uygulamanın devreye alınmasıydı. Uygulamanın yeni bir sürümü için Sağlıklı parametresini doğrudan yanlışa değiştirirsem, yani sağlık kontrolünden geçemeyen, sağlıksız bir uygulamayı dağıtmaya çalışırsam ne olacağını görelim. Bu, geliştirme aşamasında uygulamada bazı konfigürasyon hataları yapılmışsa ve bu formda üretime gönderilmişse meydana gelebilir.
Gördüğünüz gibi dağıtım yukarıdaki tüm adımları takip ediyor ve ~kubectl get pods her iki pod'un da çalıştığını gösteriyor. Ancak önceki dağıtımdan farklı olarak günlük, zaman aşımı durumunu gösterir. Yani sağlık kontrolünün başarısız olması nedeniyle uygulamanın yeni sürümü devreye alınamıyor. Sonuç olarak, sistemin uygulamanın eski sürümünü kullanmaya döndüğünü ve yeni sürümün kaldırıldığını görüyorsunuz.
Bunun iyi yanı, uygulamaya çok sayıda eş zamanlı istek gelse bile, dağıtım prosedürünü uygularken kesintinin farkına bile varmayacaklardır. Bu uygulamayı, mümkün olduğu kadar çok istek gönderen Gatling çerçevesini kullanarak test ederseniz, bu isteklerin hiçbiri reddedilmeyecektir. Bu, kullanıcılarımızın sürüm güncellemelerini gerçek zamanlı olarak fark etmeyecekleri anlamına gelir. Başarısız olması durumunda eski sürüm üzerinde çalışmalara devam edilecek, başarılı olması durumunda kullanıcılar yeni sürüme geçiş yapacaktır.
Başarısız olabilecek tek bir şey vardır - durum denetimi başarılı olursa, ancak uygulama kendisine iş yükü uygulanır uygulanmaz başarısız olursa, yani çöküş ancak dağıtım tamamlandıktan sonra gerçekleşir. Bu durumda manuel olarak eski sürüme geri dönmeniz gerekecektir. Biz de Kubernetes'in kendisi için tasarlanmış açık kaynak araçlarla nasıl kullanılacağına baktık. Bu araçları Build/Deploy işlem hatlarınıza eklerseniz dağıtım süreci çok daha kolay olacaktır. Aynı zamanda, dağıtımı başlatmak için kullanıcı arayüzünü kullanabilir veya örneğin master'a taahhütte bulunarak bu süreci tamamen otomatikleştirebilirsiniz.
Derleme Sunucumuz bir Docker görüntüsü oluşturacak, onu Docker Hub'a veya kullandığınız kayıt defterine aktaracaktır. Docker Hub webhook'u desteklediğinden, yukarıda gösterildiği gibi Deployer aracılığıyla uzaktan dağıtımı tetikleyebiliriz. Bu şekilde uygulamanızın potansiyel üretime dağıtımını tamamen otomatikleştirebilirsiniz.
Bir sonraki konuya geçelim: Kubernetes kümesini ölçeklendirme. Kubectl komutunun bir ölçeklendirme komutu olduğunu unutmayın. Daha fazla yardımla mevcut kümemizdeki kopya sayısını kolayca artırabiliriz. Ancak pratikte genellikle podlardan ziyade düğüm sayısını artırmak istiyoruz.
Aynı zamanda Amazon hizmetlerinin maliyetini azaltmak için çalışma saatlerinde artırmanız, geceleri ise çalışan uygulama örneklerinin sayısını azaltmanız gerekebilir. Bu, yalnızca kapsül sayısını ölçeklendirmenin yeterli olacağı anlamına gelmez; çünkü düğümlerden biri boşta olsa bile bunun için Amazon'a ödeme yapmanız gerekecektir. Yani, bölmeleri ölçeklendirmenin yanı sıra, kullanılan makinelerin sayısını da ölçeklendirmeniz gerekecektir.
Bu zorlayıcı olabilir çünkü ister Amazon'u ister başka bir bulut hizmetini kullanıyor olalım, Kubernetes kullanılan makinelerin sayısı hakkında hiçbir şey bilmiyor. Sistemi düğüm düzeyinde ölçeklendirmenize olanak tanıyan bir araçtan yoksundur.
Bu yüzden hem düğümlere hem de bölmelere dikkat etmemiz gerekecek. Kubernetes çalışan düğümlerinin sayısını yapılandırmak için AWS API ve Ölçeklendirme grubu makinelerini kullanarak yeni düğümlerin başlatılmasını kolayca ölçeklendirebiliriz. Kubernetes kümesindeki düğümleri kaydetmek için cloud-init veya benzer bir komut dosyası da kullanabilirsiniz.
Yeni makine Ölçeklendirme grubunda başlar, kendisini bir düğüm olarak başlatır, ana makinenin kayıt defterine kaydolur ve çalışmaya başlar. Bundan sonra, ortaya çıkan düğümlerde kullanılacak kopyaların sayısını artırabilirsiniz. Ölçeği küçültmek daha fazla çaba gerektirir çünkü böyle bir adımın, "gereksiz" makineleri kapattıktan sonra halihazırda çalışan uygulamaların yok olmasına yol açmayacağından emin olmanız gerekir. Böyle bir senaryoyu önlemek için düğümleri “programlanamaz” durumuna ayarlamanız gerekir. Bu, varsayılan zamanlayıcının DaemonSet bölmelerini planlarken bu düğümleri göz ardı edeceği anlamına gelir. Zamanlayıcı bu sunuculardan hiçbir şeyi silmeyecek ancak orada yeni kapsayıcılar da başlatmayacak. Bir sonraki adım, boşaltma düğümünü çıkarmak, yani çalışan bölmeleri ondan başka bir makineye veya bunun için yeterli kapasiteye sahip diğer düğümlere aktarmaktır. Bu düğümlerde artık konteyner olmadığından emin olduktan sonra bunları Kubernetes'ten kaldırabilirsiniz. Bundan sonra Kubernetes'in varlığı sona erecek. Daha sonra gereksiz düğümleri veya makineleri devre dışı bırakmak için AWS API'yi kullanmanız gerekir.
AWS API'ye benzer başka bir açık kaynaklı ölçeklendirme aracı olan Amdatu Scalerd'i kullanabilirsiniz. Bir kümeye düğüm eklemek veya kaldırmak için bir CLI sağlar. İlginç özelliği, zamanlayıcıyı aşağıdaki json dosyasını kullanarak yapılandırma yeteneğidir.
Gösterilen kod gece döneminde küme kapasitesini yarı yarıya azaltır. Hem mevcut replika sayısını hem de Amazon kümesinin istenilen kapasitesini yapılandırır. Bu zamanlayıcıyı kullanmak, geceleri düğüm sayısını otomatik olarak azaltacak ve sabahları artıracak, böylece Amazon gibi bir bulut hizmetindeki düğümleri kullanma maliyetinden tasarruf edeceksiniz. Bu özellik Kubernetes'te yerleşik değildir ancak Scalerd'i kullanmak bu platformu istediğiniz gibi ölçeklendirmenize olanak tanır.
Birçok insanın bana şunu söylediğini belirtmek isterim: "Her şey yolunda ve güzel, peki ya genellikle statik olan veritabanım?" Kubernetes gibi dinamik bir ortamda böyle bir şeyi nasıl çalıştırabilirsiniz? Bence bunu yapmamalısınız, Kubernetes'te veri ambarı çalıştırmaya çalışmamalısınız. Bu teknik olarak mümkün ve internette bu konuyla ilgili eğitimler var ancak bu hayatınızı ciddi anlamda zorlaştıracaktır.
Evet, Kubernetes'te kalıcı mağazalar kavramı var ve Mongo veya MySQL gibi veri depolarını çalıştırmayı deneyebilirsiniz ancak bu oldukça emek yoğun bir iştir. Bunun nedeni veri ambarlarının dinamik bir ortamla etkileşimi tam olarak desteklememesidir. Çoğu veritabanı, kümenin manuel olarak yapılandırılması da dahil olmak üzere önemli yapılandırma gerektirir, otomatik ölçeklendirmeyi ve diğer benzer şeyleri sevmez.
Bu nedenle Kubernetes'te veri ambarı çalıştırmaya çalışarak hayatınızı zorlaştırmamalısınız. Tanıdık hizmetleri kullanarak işlerini geleneksel şekilde düzenleyin ve Kubernetes'e bunları kullanma olanağını sağlayın.
Konuyu bitirirken ekibimin üzerinde çalıştığı Kubernetes tabanlı Cloud RTI platformunu sizlere tanıtmak istiyorum. Merkezi günlük kaydı, uygulama ve küme izleme ve işinize yarayacak diğer birçok yararlı özelliği sağlar. İzlemeyi görüntülemek için Grafana gibi çeşitli açık kaynaklı araçları kullanır.
Kubernetes ile ha-proxy yük dengeleyicinin neden kullanıldığına dair bir soru vardı. Güzel soru çünkü şu anda 2 seviye yük dengeleme var. Kubernetes hizmetleri hâlâ sanal IP adreslerinde bulunuyor. Bunları harici ana makinelerdeki bağlantı noktaları için kullanamazsınız çünkü Amazon bulut ana bilgisayarına aşırı yükleme yaparsa adres değişecektir. Trafiğin Kubernetes ile sorunsuz bir şekilde iletişim kurması için daha statik bir yapı oluşturmak amacıyla ha-proxy'yi hizmetlerin önüne yerleştirmemizin nedeni budur.
Bir başka güzel soru da mavi/yeşil dağıtım yaparken veritabanı şeması değişikliklerini nasıl halledebileceğinizdir? Gerçek şu ki, Kubernetes kullanımından bağımsız olarak veritabanı şemasını değiştirmek zor bir iştir. Eski ve yeni şemanın uyumlu olduğundan emin olmanız gerekir, ardından veritabanını güncelleyebilir ve ardından uygulamaları kendiniz güncelleyebilirsiniz. Veritabanını çalışırken değiştirebilir ve ardından uygulamaları güncelleyebilirsiniz. Tamamen yeni bir veritabanı kümesini yeni bir şemayla başlatan insanları tanıyorum, Mongo gibi şemasız bir veritabanınız varsa bu bir seçenektir, ancak yine de kolay bir iş değildir. Başka sorunuz yoksa ilginiz için teşekkür ederiz!
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com