27 Mayıs'ta festival kapsamında düzenlenen DevOpsConf 2019 konferansının ana salonunda “Sürekli Teslimat” bölümü kapsamında “werf - Kubernetes'teki CI/CD aracımız” raporu verildi. Bunlardan bahsediyor Herkesin Kubernetes'e dağıtım yaparken karşılaştığı sorunlar ve zorluklarve hemen fark edilmeyebilecek nüanslar hakkında. Olası çözümleri analiz ederek bunun Açık Kaynaklı bir araçta nasıl uygulandığını gösteriyoruz .
Sunumdan bu yana, yardımcı programımız (eskiden dapp olarak biliniyordu) tarihi bir dönüm noktasına ulaştı. GitHub'da 1000 yıldız — büyüyen kullanıcı topluluğunun birçok DevOps mühendisinin hayatını kolaylaştıracağını umuyoruz.
Yani, sunuyoruz (~47 dakika, makaleden çok daha bilgilendirici) ve metin biçimindeki ana alıntı. Gitmek!
Kubernetes'e kod teslim etme
Konuşma artık werf hakkında değil Kubernetes'teki CI/CD hakkında olacak, bu da yazılımımızın Docker kapsayıcılarında paketlendiğini ima ediyor (Bunun hakkında konuşmuştum )ve üretimde çalıştırmak için K8'ler kullanılacak (bununla ilgili daha fazla bilgi ).
Kubernetes'te teslimat nasıl görünüyor?
- Kodun ve onu oluşturmaya yönelik talimatların bulunduğu bir Git deposu vardır. Uygulama bir Docker görüntüsüne yerleşiktir ve Docker Kayıt Defterinde yayınlanır.
- Aynı depo, uygulamanın nasıl dağıtılacağına ve çalıştırılacağına ilişkin talimatlar da içerir. Dağıtım aşamasında bu talimatlar, istenen görüntüyü kayıt defterinden alan ve başlatan Kubernetes'e gönderilir.
- Ayrıca genellikle testler vardır. Bunlardan bazıları bir görsel yayınlanırken yapılabilir. Ayrıca (aynı talimatları izleyerek) uygulamanın bir kopyasını (ayrı bir K8s ad alanında veya ayrı bir kümede) dağıtabilir ve testleri burada çalıştırabilirsiniz.
- Son olarak, Git'ten olayları (veya düğme tıklamalarını) alan ve belirlenen tüm aşamaları çağıran bir CI sistemine ihtiyacınız var: oluşturma, yayınlama, dağıtma, test etme.
Burada birkaç önemli not var:
- Çünkü değişmez bir altyapımız var (değişmez altyapı), tüm aşamalarda (sahneleme, üretim vb.) kullanılan uygulama görseli, bir tane olmalı. Bunu daha detaylı ve örneklerle anlattım. .
- Çünkü altyapıyı kod yaklaşımıyla takip ediyoruz (IaC), uygulama kodu, montajı ve başlatılmasına ilişkin talimatlar olmalıdır tam olarak tek bir depoda. Bu konuda daha fazla bilgi için bkz. .
- Teslimat zinciri (teslimat) genellikle şöyle görüyoruz: uygulama derlendi, test edildi, yayınlandı (çıkış aşaması) işte bu kadar - teslimat gerçekleşti. Ancak gerçekte kullanıcı sizin sunduğunuz şeyi alır, hayır sonra onu üretime teslim ettiğinizde ve o oraya gidebildiğinde ve bu üretim işe yaradığında. Bu yüzden teslimat zincirinin sona erdiğine inanıyorum sadece işletme aşamasında (koşmak)veya daha doğrusu, kodun üretimden kaldırıldığı anda bile (yenisiyle değiştirildiğinde).
Kubernetes'teki yukarıdaki teslimat şemasına dönelim: bu sadece bizim tarafımızdan değil, aynı zamanda bu sorunla uğraşan herkes tarafından da icat edildi. Aslında bu kalıba artık GitOps adı veriliyor (terim ve arkasındaki fikirler hakkında daha fazla bilgi edinebilirsiniz ). Planın aşamalarına bakalım.
Yapım aşaması
Herkesin Docker dosyalarının nasıl yazılacağını ve çalıştırılacağını bildiği 2019'da Docker görüntüleri oluşturma hakkında konuşabileceğiniz anlaşılıyor. docker build?.. Dikkat etmek istediğim nüanslar şunlar:
- Görüntü ağırlığı önemli, bu yüzden kullanın görüntüde yalnızca işlem için gerçekten gerekli olan uygulamayı bırakmak.
- Katman sayısı zincirleri birleştirerek en aza indirilmelidir.
RUN-anlamına göre komutlar. - Ancak bu durum sorunlara neden oluyor hata ayıklamaçünkü montaj çöktüğünde soruna neden olan zincirden doğru komutu bulmanız gerekir.
- Montaj hızı Önemli çünkü değişiklikleri hızlı bir şekilde uygulamaya koymak ve sonuçları görmek istiyoruz. Örneğin, her uygulama oluşturduğunuzda dil kitaplıklarındaki bağımlılıkları yeniden oluşturmak istemezsiniz.
- Genellikle ihtiyacınız olan bir Git deposundan birçok resimBu, bir dizi Docker dosyasıyla (veya bir dosyadaki adlandırılmış aşamalarla) ve sıralı derlemeleriyle bir Bash betiğiyle çözülebilir.
Bu herkesin karşılaştığı buzdağının sadece görünen kısmıydı. Ancak özellikle başka sorunlar da var:
- Genellikle montaj aşamasında bir şeye ihtiyacımız olur montaj (örneğin, apt gibi bir komutun sonucunu üçüncü taraf bir dizinde önbelleğe alın).
- İstiyoruz yanıtlayıcı ' kabukta yazmak yerine.
- İstiyoruz Docker olmadan derleme (Konteynerleri çalıştırabileceğimiz bir Kubernetes kümemiz varken neden bunun için her şeyi yapılandırmamız gereken ek bir sanal makineye ihtiyacımız var?).
- Paralel montajfarklı şekillerde anlaşılabilen: Docker dosyasından farklı komutlar (çok aşamalı kullanılıyorsa), aynı deponun birkaç işlemi, birkaç Docker dosyası.
- Dağıtılmış montaj: "Geçici" olan şeyleri kapsüller halinde toplamak istiyoruz çünkü önbellekleri kaybolur, bu da ayrı bir yerde saklanması gerektiği anlamına gelir.
- Sonunda arzuların zirvesine isim verdim otomatik büyü: Depoya gitmek, bir komut yazmak ve nasıl ve neyin doğru yapılacağına dair bir anlayışla bir araya getirilmiş hazır bir görüntü elde etmek ideal olacaktır. Ancak kişisel olarak tüm nüansların bu şekilde öngörülebileceğinden emin değilim.
Ve işte projeler:
- — tüm bu sorunları çözmeye çalışan Docker Inc'den (Docker'ın mevcut sürümlerine zaten entegre edilmiş) bir oluşturucu;
- — Docker olmadan derleme yapmanıza olanak tanıyan Google'dan bir oluşturucu;
- — CNCF'nin otomatik sihir yapma girişimi ve özellikle katmanlar için yeniden tabanlama ile ilginç bir çözüm;
- ve bir sürü başka yardımcı program, örneğin , ...
...ve GitHub'da kaç yıldızları olduğuna bakın. Yani bir yandan docker build var ve bir şeyler yapabilir, ancak gerçekte sorun tam olarak çözülmedi - Bunun kanıtı, her biri sorunların bir kısmını çözen alternatif toplayıcıların paralel gelişimidir.
Werf'te montaj
Bu yüzden yapmalıyız (eski dapp gibi) — Uzun yıllardır yapmakta olduğumuz Flant şirketinin açık kaynaklı bir yardımcı programı. Her şey 5 yıl önce Dockerfiles'ın montajını optimize eden Bash betikleriyle başladı ve son 3 yıldır kendi Git deposuyla tek bir proje çerçevesinde tam teşekküllü geliştirme yürütülüyor. (önce Ruby'de, sonra Go'ya ve aynı zamanda yeniden adlandırıldı). Werf'te hangi montaj sorunları çözüldü?
Mavi ile işaretlenen sorunlar halihazırda hayata geçirilmiş, paralel yapı aynı konak içerisinde yapılmış, sarı ile vurgulanan konuların ise yaz sonuna kadar tamamlanması planlanıyor.
Sicilde yayınlanma aşaması (yayımlama)
Biz aradık docker push... - bir resmi kayıt defterine yüklemenin nesi zor olabilir? Ve sonra şu soru ortaya çıkıyor: "Resme hangi etiketi koymalıyım?" Sahip olduğumuz nedenden dolayı ortaya çıkıyor Git akışı (veya diğer Git stratejisi) ve Kubernetes'i kullanıyor ve endüstri, Kubernetes'te olanların Git'te olanları takip etmesini sağlamaya çalışıyor. Sonuçta Git bizim tek gerçek kaynağımızdır.
Bunun neresi zor? Tekrarlanabilirliği sağlayın: doğası gereği değişmez olan Git'teki bir taahhütten (değişmez), aynı tutulması gereken bir Docker görüntüsüne.
Bizim için de önemli kökenini belirlemek, çünkü Kubernetes'te çalışan uygulamanın hangi commit'ten oluşturulduğunu anlamak istiyoruz (daha sonra farklar ve benzeri şeyler yapabiliriz).
Etiketleme Stratejileri
İlki basit git etiketi. Olarak etiketlenmiş bir resme sahip bir kayıt defterimiz var 1.0. Kubernetes'in bu görüntünün yüklendiği sahne ve prodüksiyonu var. Git'te taahhütlerde bulunuyoruz ve bir noktada etiketliyoruz 2.0. Depodaki talimatlara göre topluyoruz ve etiketiyle kayıt defterine yerleştiriyoruz 2.0. Bunu sahneye ve eğer her şey yolundaysa üretime aktarıyoruz.
Bu yaklaşımın sorunu, önce etiketi koymamız ve ancak daha sonra test edip kullanıma sunmamızdır. Neden? Birincisi, bu kesinlikle mantıksız: Yazılımın henüz test etmediğimiz bir sürümünü yayınlıyoruz (başka türlü yapamayız, çünkü kontrol etmek için bir etiket koymamız gerekiyor). İkincisi, bu yol Gitflow ile uyumlu değil.
İkinci seçenek - git taahhüt + etiketi. Ana dalın bir etiketi var 1.0; bunun için kayıt defterinde - üretime dağıtılan bir görüntü. Ayrıca Kubernetes kümesinde önizleme ve hazırlama hatları bulunur. Daha sonra Gitflow'u takip ediyoruz: geliştirme için ana dalda (develop) tanımlayıcıyla bir taahhütle sonuçlanan yeni özellikler yapıyoruz #c1. Bu tanımlayıcıyı kullanarak onu topluyor ve kayıt defterinde yayınlıyoruz (#c1). Aynı tanımlayıcıyla önizlemeye çıkıyoruz. Aynısını taahhütlerle yapıyoruz #c2 и #c3.
Yeterli özelliğin olduğunu anladığımızda her şeyi stabilize etmeye başlıyoruz. Git'te bir şube oluşturun release_1.1 (taban üzerinde #c3 arasında develop). Bu sürümü toplamaya gerek yok, çünkü... bu önceki adımda yapıldı. Bu nedenle, bunu basitçe aşamalandırmaya aktarabiliriz. Hataları düzeltiyoruz #c4 ve benzer şekilde sahnelemeye başlayın. Aynı zamanda geliştirme çalışmaları da sürüyor developDeğişikliklerin periyodik olarak alındığı yer release_1.1. Bir noktada, derlenmiş ve aşamalandırmaya yüklenmiş bir taahhüt alıyoruz ve bundan memnunuz (#c25).
Daha sonra yayın dalını (hızlı ileri sararak) birleştiriyoruz (release_1.1) ustada. Bu commite yeni sürümü içeren bir etiket koyduk (1.1). Ancak bu görüntü zaten kayıt defterinde toplanmıştır, bu nedenle onu tekrar toplamamak için mevcut görüntüye ikinci bir etiket ekliyoruz (artık kayıt defterinde etiketleri var) #c25 и 1.1). Daha sonra üretime aktarıyoruz.
Aşamaya yalnızca bir görüntünün yüklenmesi gibi bir dezavantaj vardır (#c25) ve üretimde durum biraz farklı (1.1), ancak bunların "fiziksel olarak" kayıt defterindeki aynı görüntü olduğunu biliyoruz.
Gerçek dezavantaj, birleştirme taahhütleri için destek olmaması, hızlı ileri sarmanız gerektiğidir.
Daha da ileri giderek bir hile yapabiliriz... Basit bir Docker dosyası örneğine bakalım:
FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb
FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/publicAşağıdaki prensibe göre ondan bir dosya oluşturalım:
- Kullanılan görsellerin tanımlayıcılarından SHA256 (
ruby:2.3иnginx:alpine), içeriklerinin sağlama toplamlarıdır; - tüm takımlar (
RUN,CMDve benzeri.); - Eklenen dosyalardan SHA256.
... ve böyle bir dosyadan sağlama toplamını (yine SHA256) alın. Bu imza Docker görüntüsünün içeriğini tanımlayan her şey.
Diyagrama geri dönelim ve taahhütler yerine bu tür imzaları kullanacağızyani görüntüleri imzalarla etiketleyin.
Artık, örneğin bir sürümden ana sürüme yapılan değişiklikleri birleştirmek gerektiğinde, gerçek bir birleştirme taahhüdü gerçekleştirebiliriz: farklı bir tanımlayıcıya sahip olacak, ancak aynı imzaya sahip olacaktır. Aynı tanımlayıcıyla görüntüyü üretime sunacağız.
Dezavantajı ise üretime ne tür bir taahhüdün aktarıldığını belirlemenin artık mümkün olmamasıdır; sağlama toplamları yalnızca tek yönde çalışır. Bu sorun, meta verilere sahip ek bir katmanla çözüldü - size daha sonra daha fazlasını anlatacağım.
Werf'te etiketleme
Werf'te daha da ileri gittik ve tek bir makinede depolanmayan önbellek ile dağıtılmış bir yapı yapmaya hazırlanıyoruz... Yani iki tür Docker görüntüsü oluşturuyoruz, onlara diyoruz sahne и görüntü.
Werf Git deposu, yapının farklı aşamalarını açıklayan yapıya özel talimatları saklar (yüklemeden önce, kurmak, Kurulumdan önce, kurulum). İlk aşama görüntüsünü, ilk adımların sağlama toplamı olarak tanımlanan bir imzayla topluyoruz. Daha sonra kaynak kodunu ekliyoruz, yeni sahne görüntüsü için sağlama toplamını hesaplıyoruz... Bu işlemler tüm aşamalar için tekrarlanır ve bunun sonucunda bir dizi sahne görüntüsü elde ederiz. Daha sonra kökenine ilişkin meta verileri de içeren son görüntüyü oluşturuyoruz. Ve bu görseli farklı şekillerde etiketliyoruz (detaylar daha sonra).
Bundan sonra, yalnızca uygulama kodunun değiştirildiği yeni bir işlemin göründüğünü varsayalım. Ne olacak? Kod değişiklikleri için yama oluşturulacak ve yeni sahne görseli hazırlanacaktır. İmzası, eski sahne görüntüsünün ve yeni yamanın sağlama toplamı olarak belirlenecektir. Bu görüntüden yeni bir son görüntü oluşacaktır. Diğer aşamalardaki değişikliklerde de benzer davranışlar ortaya çıkacaktır.
Bu nedenle sahne görüntüleri, dağıtılmış olarak saklanabilen bir önbellektir ve bundan önceden oluşturulmuş görüntüler Docker Kayıt Defterine yüklenir.
Kayıt defterini temizleme
Silinen etiketlerden sonra asılı kalan katmanları silmekten bahsetmiyoruz - bu, Docker Registry'nin standart bir özelliğidir. Çok sayıda Docker etiketinin biriktiği ve bunlardan bazılarına artık ihtiyacımız olmadığını anladığımız ancak yer kapladıkları (ve/veya bunun için para ödediğimiz) bir durumdan bahsediyoruz.
Temizleme stratejileri nelerdir?
- Hiçbir şey yapamazsın temizleme. Bazen ekstra alan için biraz ödeme yapmak, büyük bir etiket karmaşasını çözmekten gerçekten daha kolaydır. Ancak bu yalnızca belirli bir noktaya kadar işe yarar.
- Tam sıfırlama. Tüm görüntüleri silerseniz ve yalnızca CI sistemindeki mevcut görüntüleri yeniden oluşturursanız bir sorun ortaya çıkabilir. Konteyner üretimde yeniden başlatılırsa, bunun için henüz kimse tarafından test edilmemiş yeni bir görüntü yüklenecektir. Bu, değişmez altyapı fikrini ortadan kaldırır.
- Mavi-yeşil. Bir kayıt defteri dolmaya başladı - görüntüleri diğerine yüklüyoruz. Önceki yöntemdekiyle aynı sorun: Taşmaya başlayan kayıt defterini hangi noktada temizleyebilirsiniz?
- Zamana göre. 1 aydan eski tüm görseller silinsin mi? Ama bir aydır güncellenmeyen bir hizmet mutlaka olacaktır...
- el ile zaten neyin silinebileceğini belirleyin.
Gerçekten geçerli iki seçenek vardır: elle temizlemeyin veya mavi-yeşil + kombinasyonunu yapmayın. İkinci durumda, aşağıdakilerden bahsediyoruz: Kayıt defterini temizleme zamanının geldiğini anladığınızda, yeni bir tane oluşturursunuz ve örneğin bir ay boyunca tüm yeni görselleri ona eklersiniz. Bir ay sonra Kubernetes'teki hangi bölmelerin hâlâ eski kaydı kullandığını görün ve bunları da yeni kayıt defterine aktarın.
Ne hale geldik Werf? Biz topluyoruz:
- Git başlığı: tüm etiketler, tüm dallar - resimlerde Git'te etiketlenen her şeye ihtiyacımız olduğunu varsayarak (ve değilse, onu Git'in kendisinde silmemiz gerekir);
- şu anda Kubernetes'e aktarılan tüm bölmeler;
- eski ReplicaSets (yakın zamanda piyasaya sürülen) ve ayrıca Helm sürümlerini taramayı ve oradaki en yeni görüntüleri seçmeyi planlıyoruz.
... ve bu setten bir beyaz liste oluşturun - silmeyeceğimiz görsellerin bir listesi. Geriye kalan her şeyi temizliyoruz, ardından yetim sahne görüntülerini bulup onları da siliyoruz.
Dağıtım aşaması
Güvenilir bildirim özelliği
Dağıtımda dikkat çekmek istediğim ilk nokta, bildirimsel olarak bildirilen güncellenmiş kaynak yapılandırmasının kullanıma sunulmasıdır. Kubernetes kaynaklarını açıklayan orijinal YAML belgesi, kümede gerçekte çalışan sonuçtan her zaman çok farklıdır. Çünkü Kubernetes yapılandırmaya şunu ekler:
- tanımlayıcılar;
- servis bilgileri;
- birçok varsayılan değer;
- mevcut durumu içeren bölüm;
- kabul webhook'unun bir parçası olarak yapılan değişiklikler;
- çeşitli kontrolörlerin (ve zamanlayıcının) çalışmasının sonucu.
Bu nedenle, yeni bir kaynak yapılandırması göründüğünde (yeni), mevcut "canlı" konfigürasyonu alıp üzerine yazamayız (yaşamak). Bunu yapmak için karşılaştırmamız gerekecek yeni son uygulanan yapılandırmayla (son uygulanan) ve yuvarlanın yaşamak yama aldı.
Bu yaklaşıma denir 2 yollu birleştirme. Örneğin Helm'de kullanılır.
Ayrıca birde şu var 3 yollu birleştirme, şu açıdan farklılık gösterir:
- karşılaştırma son uygulanan и yeni, nelerin silindiğine bakıyoruz;
- karşılaştırma yeni и yaşamak, nelerin eklendiğine ya da değiştirildiğine bakıyoruz;
- toplanan yama uygulanır yaşamak.
Helm ile 1000'den fazla uygulamayı dağıtıyoruz, yani aslında 2 yönlü birleştirmeyle yaşıyoruz. Ancak yamalarımızla çözdüğümüz ve Helm'in normal çalışmasına yardımcı olan bir takım sorunları var.
Gerçek kullanıma sunma durumu
CI sistemimiz bir sonraki olaya göre Kubernetes için yeni bir konfigürasyon oluşturduktan sonra bunu kullanıma iletir. (uygulamak) bir kümeye - Helm kullanarak veya kubectl apply. Daha sonra, Kubernetes API'sinin CI sistemine ve kullanıcısına onaylayıcı bir şekilde yanıt verdiği, önceden açıklanan N yönlü birleştirme gerçekleşir.
Ancak ortada çok büyük bir sorun var: Sonuçta Başarılı uygulama, başarılı kullanıma sunma anlamına gelmez. Kubernetes hangi değişikliklerin uygulanması gerektiğini anlayıp uygularsa sonucun ne olacağını henüz bilmiyoruz. Örneğin, ön uçtaki pod'ları güncellemek ve yeniden başlatmak başarılı olabilir, ancak arka uçta olmayabilir ve çalışan uygulama görüntülerinin farklı sürümlerini alırız.
Her şeyi doğru bir şekilde yapmak için, bu şema ek bir bağlantı gerektirir - Kubernetes API'sinden durum bilgilerini alacak ve gerçek durumun daha fazla analizi için bunu iletecek özel bir izleyici. Go'da bir Açık Kaynak kitaplığı oluşturduk - (bkz: duyurusu ), bu sorunu çözer ve werf'e yerleşiktir.
Bu izleyicinin werf düzeyindeki davranışı, Dağıtımlar veya StatefulSets'e yerleştirilen ek açıklamalar kullanılarak yapılandırılır. Ana açıklama - fail-mode - aşağıdaki anlamları anlıyor:
-
IgnoreAndContinueDeployProcess— bu bileşenin kullanıma sunulmasıyla ilgili sorunları göz ardı ediyoruz ve dağıtıma devam ediyoruz; -
FailWholeDeployProcessImmediately— bu bileşendeki bir hata dağıtım sürecini durdurur; -
HopeUntilEndOfDeployProcess— Bu bileşenin dağıtımın sonunda çalışacağını umuyoruz.
Örneğin, kaynakların ve ek açıklama değerlerinin bu birleşimi fail-mode:
İlk kez dağıtım yaptığımızda veritabanı (MongoDB) henüz hazır olmayabilir - Dağıtımlar başarısız olur. Ancak başlaması için o anı bekleyebilirsiniz; dağıtım yine de gerçekleşecektir.
Werf'te kubedog için iki ek açıklama daha var:
-
failures-allowed-per-replica- her kopya için izin verilen düşme sayısı; -
show-logs-until- werf'in (stdout'ta) açılan tüm bölmelerden günlükleri göstereceği anı düzenler. Varsayılan:PodIsReady(trafik bölmeye gelmeye başladığında muhtemelen istemediğimiz mesajları yok saymak için), ancak değerler de geçerlidir:ControllerIsReadyиEndOfDeploy.
Dağıtımdan başka ne istiyoruz?
Daha önce açıklanan iki noktaya ek olarak şunları istiyoruz:
- görmek kütükler - ve yalnızca gerekli olanları, arka arkaya her şeyi değil;
- izlemek ilerlemeçünkü iş birkaç dakika boyunca "sessizce" askıda kalırsa, orada neler olduğunu anlamak önemlidir;
- иметь otomatik geri alma bir şeylerin ters gitmesi durumunda (ve bu nedenle dağıtımın gerçek durumunu bilmek kritik öneme sahiptir). Sunum atomik olmalıdır: ya sonuna kadar gider ya da her şey önceki durumuna döner.
sonuçlar
Bir şirket olarak bizim için, açıklanan tüm nüansları teslimatın farklı aşamalarında (derleme, yayınlama, dağıtma) uygulamak için bir CI sistemi ve yardımcı program yeterlidir. .
Sonuç yerine:
Werf'in yardımıyla DevOps mühendislerine yönelik çok sayıda sorunun çözümünde iyi bir ilerleme kaydettik ve daha geniş bir topluluğun bu yardımcı programı en azından eylem halinde denemesinden memnuniyet duyarız. Birlikte iyi bir sonuca ulaşmak daha kolay olacaktır.
Videolar ve slaytlar
Performanstan video (~47 dakika):
Raporun sunumu:
PS
Blogumuzdaki Kubernetes ile ilgili diğer raporlar:
- «» (Dmitry Stolyarov; 27 Nisan 2019, “Grev”);
- «» (Andrey Polovov; 8 Nisan 2019, Saint HighLoad++'da);
- «» (Dmitry Stolyarov; 8 Kasım 2018, HighLoad++'da);
- «» (Dmitry Stolyarov; 28 Mayıs 2018, RootConf'ta);
- «» (Dmitry Stolyarov; 7 Kasım 2017, HighLoad++'da);
- «» (Dmitry Stolyarov; 6 Haziran 2017, RootConf'ta).
Kaynak: habr.com