Blogumuza teknik direktörümüzün son konuşmalarından yola çıkan yayınlarla başlayacağız. (Dmitry Stolyarov). Hepsi 2016 yılında çeşitli profesyonel etkinliklerde gerçekleşti ve DevOps ve Docker konusuna adandı. Badoo ofisindeki Docker Moskova toplantısından bir video, daha önce yayınlamıştık Çevrimiçi. Yeni raporlara raporların özünü aktaran makaleler eşlik edecek. Bu yüzden…
31 Mayıs konferansında “Rus İnternet Teknolojileri” (RIT++ 2016) festivali kapsamında düzenlenen “Sürekli Dağıtım ve Dağıtım” bölümü “Docker ile Sürekli Teslimatın En İyi Uygulamaları” raporuyla açıldı. Docker ve diğer Açık Kaynak ürünlerini kullanarak Sürekli Teslimat (CD) süreci oluşturmaya yönelik en iyi uygulamaları özetledi ve sistematik hale getirdi. Üretimde pratik deneyime güvenmemizi sağlayan bu çözümlerle çalışıyoruz.
Bir saat geçirme fırsatınız varsa Tamamını izlemenizi öneririz. Aksi takdirde, metin biçimindeki ana özet aşağıdadır.
Docker ile Sürekli Teslimat
Altında Sürekli Teslim Git deposundaki uygulama kodunun önce üretime geçmesi ve ardından arşive düşmesi sonucu oluşan olaylar zincirini anlıyoruz. Şuna benziyor: Git → Oluştur → Test Et → Yayınla → Çalıştır.
Raporun büyük bir kısmı oluşturma aşamasına (uygulama derlemesi) ayrılmıştır ve yayınlanma ve işletilme konularına kısaca değinilmektedir. Sorunlardan ve bunları çözmenize olanak sağlayan kalıplardan bahsedeceğiz ve bu kalıpların spesifik uygulamaları farklı olabilir.
Docker'a neden burada ihtiyaç duyuluyor? Bu Açık Kaynak aracı bağlamında Sürekli Teslimat uygulamalarından bahsetmeye karar vermemiz boşuna değil. Raporun tamamı bu kullanıma ayrılmış olsa da, uygulama kodunun kullanıma sunulmasının ana modeli dikkate alındığında birçok neden ortaya çıkıyor.
Ana kullanıma sunma modeli
Bu nedenle, uygulamanın yeni sürümlerini çıkardığımızda kesinlikle karşı karşıya kalıyoruz kesinti sorunu, üretim sunucusunun değiştirilmesi sırasında oluşturulur. Uygulamanın eski sürümünden yeni sürümüne giden trafik anında geçiş yapamaz: öncelikle yeni sürümün yalnızca başarıyla indirildiğinden değil, aynı zamanda "ısındığından" (yani istekleri karşılamaya tamamen hazır olduğundan) emin olmalıyız.
Böylece bir süre uygulamanın her iki versiyonu da (eski ve yeni) aynı anda çalışacaktır. Bu otomatik olarak şuna yol açar: paylaşılan kaynak çakışması: ağ, dosya sistemi, IPC, vb. Docker ile bu sorun, uygulamanın farklı sürümlerinin ayrı kaplarda çalıştırılmasıyla kolayca çözülür ve bu sayede aynı ana bilgisayar (sunucu/sanal makine) içinde kaynak izolasyonu garanti edilir. Tabii ki, bazı hilelerle hiç yalıtım olmadan da idare edebilirsiniz, ancak hazır ve kullanışlı bir araç varsa, o zaman tam tersi bir sebep vardır - onu ihmal etmemek.
Konteynerizasyon, konuşlandırıldığında başka birçok avantaj sağlar. Herhangi bir uygulama şunlara bağlıdır: belirli sürüm (veya sürüm aralığı) tercüman, modüllerin/uzantıların vb. kullanılabilirliği ve bunların sürümleri. Ve bu yalnızca doğrudan yürütülebilir ortam için değil, aynı zamanda tüm ortam için de geçerlidir. sistem yazılımı ve sürümü (kullanılan Linux dağıtımına kadar). Konteynerlerin sadece uygulama kodunu değil aynı zamanda gerekli sürümlerin önceden yüklenmiş sistem ve uygulama yazılımlarını da içermesi nedeniyle bağımlılıklarla ilgili sorunları unutabilirsiniz.
Özetleyelim ana kullanıma sunma modeli aşağıdaki faktörleri dikkate alan yeni sürümler:
- İlk başta uygulamanın eski sürümü ilk konteynerde çalışır.
- Yeni versiyon daha sonra açılır ve ikinci bir kapta "ısıtılır". Bu yeni sürümün yalnızca güncellenmiş uygulama kodunu değil, aynı zamanda bağımlılıklarından herhangi birini ve ayrıca sistem bileşenlerini (örneğin, OpenSSL'nin yeni bir sürümü veya tüm dağıtım) taşıyabilmesi dikkat çekicidir.
- Yeni sürüm istekleri karşılamaya tamamen hazır olduğunda trafik ilk konteynerden ikinciye geçer.
- Artık eski sürüm durdurulabilir.
Uygulamanın farklı sürümlerini ayrı kapsayıcılarda dağıtma yaklaşımı başka bir kolaylık sağlar: hızlı geri alma eski sürüme (sonuçta trafiği istenen konteynere aktarmak yeterlidir).
Son ilk tavsiye Kaptan'ın bile kusur bulamayacağı bir şeye benziyor: "[Docker ile Sürekli Teslimatı organize ederken] Docker'ı kullanın [ve ne verdiğini anlayın]" Unutmayın, bu her sorunu çözecek sihirli bir değnek değil, harika bir temel sağlayan bir araçtır.
Yeniden üretilebilirlik
“Tekrarlanabilirlik” ile uygulamaları çalıştırırken karşılaşılan genelleştirilmiş bir dizi sorunu kastediyoruz. Bu gibi durumlardan bahsediyoruz:
- Kalite departmanı tarafından hazırlama amacıyla kontrol edilen komut dosyalarının üretimde doğru bir şekilde çoğaltılması gerekir.
- Uygulamalar, farklı depo aynalarından paket alabilen sunucularda yayınlanır (zamanla güncellenirler ve onlarla birlikte yüklü uygulamaların sürümleri de güncellenir).
- “Yerel olarak benim için her şey çalışıyor!” (...ve geliştiricilerin üretime girmesine izin verilmiyor.)
- Eski (arşivlenmiş) sürümdeki bir şeyi kontrol etmeniz gerekiyor.
- ...
Genel özü, kullanılan ortamlara tam uyumun (ve aynı zamanda insan faktörünün bulunmamasının) gerekli olduğu gerçeğine dayanmaktadır. Tekrarlanabilirliği nasıl garanti edebiliriz? Docker görüntüleri oluşturma Git'teki kodu temel alarak bunları herhangi bir görev için kullanın: test sitelerinde, üretimde, programcıların yerel makinelerinde... Aynı zamanda gerçekleştirilen eylemleri en aza indirmek de önemlidir. sonra görüntünün montajı: ne kadar basitse, hata olasılığı o kadar az olur.
Altyapı koddur
Altyapı gereksinimleri (sunucu yazılımının kullanılabilirliği, sürümü vb.) resmileştirilmez ve "programlanmazsa" herhangi bir uygulama güncellemesinin kullanıma sunulması feci sonuçlara yol açabilir. Örneğin, hazırlama aşamasında zaten PHP 7.0'a geçtiniz ve kodu buna göre yeniden yazdınız - o zaman bunun eski bir PHP (5.5) ile üretimde ortaya çıkması kesinlikle birini şaşırtacaktır. Tercüman sürümündeki büyük değişikliği unutmayabilirsiniz, ancak "şeytan ayrıntıda gizlidir": sürpriz, herhangi bir bağımlılığın küçük bir güncellemesinde olabilir.
Bu sorunu çözmeye yönelik bir yaklaşım olarak bilinir. IaC (Kod Olarak Altyapı, “kod olarak altyapı”) ve uygulama koduyla birlikte altyapı gereksinimlerinin saklanmasını içerir. Geliştiriciler ve DevOps uzmanları bunu kullanarak aynı Git uygulama deposuyla ancak onun farklı bölümlerinde çalışabilir. Bu koddan Git'te, altyapının tüm özellikleri dikkate alınarak uygulamanın dağıtıldığı bir Docker görüntüsü oluşturulur. Basitçe söylemek gerekirse, görüntülerin birleştirilmesine yönelik komut dosyaları (kurallar) kaynak koduyla aynı depoda olmalı ve bir araya getirilmelidir.
Çok katmanlı bir uygulama mimarisi söz konusu olduğunda (örneğin, Docker kapsayıcısında zaten çalışan bir uygulamanın önünde duran nginx vardır), her katman için Docker görüntülerinin Git'teki koddan oluşturulması gerekir. Daha sonra ilk görüntü, yorumlayıcıya ve diğer "kapalı" bağımlılıklara sahip bir uygulamayı içerecek ve ikinci görüntü, yukarı akış nginx'ini içerecektir.
Docker görüntüleri, Git ile iletişim
Git'ten toplanan tüm Docker görsellerini iki kategoriye ayırıyoruz: geçici ve sürüm. Geçici görüntüler Git'teki şubenin adıyla etiketlenenler, bir sonraki işlemde üzerine yazılabilir ve yalnızca önizleme için kullanıma sunulur (üretim için değil). Bu onların serbest bırakılanlardan temel farkıdır: İçlerinde hangi spesifik taahhüdün olduğunu asla bilemezsiniz.
Geçici görüntüleri toplamak mantıklıdır: ana dal (ana dalın güncel sürümünü sürekli olarak görmek için onu otomatik olarak ayrı bir siteye aktarabilirsiniz), sürümleri olan dallar, belirli yeniliklerin dalları.
Geçici görüntülerin önizlemesi üretime çevrilme ihtiyacına geldikten sonra geliştiriciler belirli bir etiket koyar. Etikete göre otomatik olarak toplanır resmi yayınla (etiketi Git'teki etikete karşılık gelir) ve hazırlamaya aktarılır. Kalite departmanı tarafından başarılı bir şekilde doğrulanırsa üretime geçer.
Dapp
Açıklanan her şey (kullanıma sunma, görüntü birleştirme, sonraki bakım), Bash komut dosyaları ve diğer "doğaçlama" araçlar kullanılarak bağımsız olarak uygulanabilir. Ancak bunu yaparsanız, bir noktada uygulama büyük karmaşıklığa ve zayıf kontrol edilebilirliğe yol açacaktır. Bunu anlayarak, CI/CD oluşturmaya yönelik kendi özel İş Akışı yardımcı programımızı oluşturmaya geldik - Dapp.
Kaynak kodu Ruby'de yazılmıştır, açık kaynaktır ve şu adreste yayınlanmıştır: . Ne yazık ki dokümantasyon şu anda aracın en zayıf noktasıdır ancak üzerinde çalışıyoruz. Ve dapp hakkında defalarca yazıp konuşacağız çünkü... Yeteneklerini tüm ilgili toplulukla paylaşmak için içtenlikle sabırsızlanıyoruz, ancak bu arada sorunlarınızı ve çekme isteklerinizi gönderin ve/veya projenin gelişimini GitHub'dan takip edin.
13 Ağustos 2019'da güncellendi: şu anda bir proje Dapp olarak yeniden adlandırıldı , kodu Go'da tamamen yeniden yazıldı ve belgeleri önemli ölçüde iyileştirildi.
Kubernetes
Profesyonel ortamda halihazırda önemli bir kabul görmüş olan bir diğer hazır Açık Kaynak aracı ise Kubernetesbir Docker yönetim kümesi. Docker üzerine inşa edilen projelerin işletilmesinde kullanılması konusu raporun kapsamı dışında olduğundan sunum bazı ilginç özelliklere genel bir bakışla sınırlıdır.
Kullanıma sunma için Kubernetes şunları sunar:
- hazırlık araştırması - uygulamanın yeni bir sürümünün hazır olup olmadığını kontrol etmek (trafiği ona aktarmak için);
- sürekli güncelleme - bir kapsayıcı kümesindeki sıralı görüntü güncellemesi (kapatma, güncelleme, başlatma hazırlığı, trafik değiştirme);
- eşzamanlı güncelleme - bir kümedeki görüntünün farklı bir yaklaşımla güncellenmesi: önce kapların yarısında, sonra geri kalanında;
- canary sürümleri - anormallikleri izlemek için sınırlı (az) sayıda kapsayıcıda yeni bir görüntü başlatır.
Sürekli Teslimat yalnızca yeni bir sürümün piyasaya sürülmesi olmadığından Kubernetes'in daha sonraki altyapı bakımı için çeşitli yetenekleri vardır: tüm kapsayıcılar için yerleşik izleme ve günlük kaydı, otomatik ölçeklendirme vb. Tüm bunlar zaten çalışıyor ve yalnızca uygun sürümü bekliyor. süreçlerinizde uygulanması.
Nihai öneriler
- Docker'ı kullanın.
- Tüm ihtiyaçlarınıza yönelik uygulamaların Docker görüntülerini oluşturun.
- “Altyapı koddur” ilkesini izleyin.
- Git'i Docker'a bağlayın.
- Kullanıma sunma sırasını düzenleyin.
- Hazır bir platform kullanın (Kubernetes veya başka bir).
Videolar ve slaytlar
Performanstan video (yaklaşık bir saat) (raporun kendisi 5. dakikadan itibaren başlar - bu andan itibaren oynatmak için bağlantıyı takip edin).
Raporun sunumu:
PS
Blogumuzdaki konuyla ilgili diğer raporlar:
- «» (Dmitry Stolyarov; 27 Mayıs 2019, DevOpsConf'ta);
- «» (Dmitry Stolyarov; 8 Kasım 2018, HighLoad++'da);
- «» (Dmitry Stolyarov; 7 Kasım 2017, HighLoad++'da);
- «» (Dmitry Stolyarov; 6 Haziran 2017, RootConf'ta).
Kaynak: habr.com