werf - alat kami pikeun CI / CD di Kubernetes (Tinjauan sareng laporan video)

27 Mei di aula utama konferensi DevOpsConf 2019, dilaksanakeun salaku bagian tina festival RIT++ 2019, salaku bagian tina bagian "Pangiriman Terus-terusan", laporan dibéré "werf - alat kami pikeun CI/CD di Kubernetes". Ieu ceramah ngeunaan maranéhanana masalah sareng tantangan anu disanghareupan ku sadayana nalika nyebarkeun ka Kubernetes, kitu ogé ngeunaan nuansa nu bisa jadi teu langsung noticeable. Nganalisis solusi anu mungkin, kami nunjukkeun kumaha ieu dilaksanakeun dina alat Open Source werf.

Kusabab presentasi teh, utiliti urang (baheulana kawanoh salaku dapp) geus ngahontal hiji milestone bersejarah ngeunaan 1000 béntang dina GitHub - Kami ngarepkeun komunitas pangguna anu ngembang bakal ngagampangkeun kahirupan pikeun seueur insinyur DevOps.

Ku kituna, hayu urang ngawanohkeun video laporan (~ 47 menit, langkung informatif tibatan artikel) sareng ekstrak utama tina éta dina bentuk téks. indit!

Nganteurkeun kode ka Kubernetes

Obrolan moal deui ngeunaan werf, tapi ngeunaan CI / CD di Kubernetes, nunjukkeun yén parangkat lunak kami dibungkus dina wadah Docker. (Kuring ngobrol ngeunaan ieu dina 2016 laporan), sarta K8s bakal dipaké pikeun ngajalankeun eta dina produksi (langkung seueur ngeunaan ieu dina sataun 2017).

Kumaha pangiriman sapertos di Kubernetes?

• Aya Repository Git sareng kode sareng petunjuk pikeun ngawangun éta. Aplikasi ieu diwangun kana gambar Docker sareng diterbitkeun dina Docker Registry.
• Repository anu sami ogé ngandung petunjuk ngeunaan cara nyebarkeun sareng ngajalankeun aplikasi. Dina tahap panyebaran, paréntah ieu dikirim ka Kubernetes, anu nampi gambar anu dipikahoyong tina pendaptaran sareng ngaluncurkeunana.
• Salaku tambahan, biasana aya tés. Sababaraha ieu tiasa dilakukeun nalika nyebarkeun gambar. Anjeun oge bisa (nurutan parentah sarua) nyebarkeun salinan aplikasi nu (dina spasi ngaran K8s misah atawa klaster misah) tur ngajalankeun tés aya.
• Tungtungna, anjeun peryogi sistem CI anu nampi acara ti Git (atanapi klik tombol) sareng nyauran sadaya tahapan anu ditunjuk: ngawangun, nyebarkeun, nyebarkeun, nguji.

Aya sababaraha catetan penting di dieu:

1. Kusabab urang boga infrastruktur immutable (infrastruktur anu teu bisa dirobah), gambar aplikasi anu dianggo dina sagala tahapan (pementasan, produksi, jsb.), kudu aya hiji. Kuring ngobrol ngeunaan ieu dina leuwih jéntré tur kalawan conto. di dieu.
2. Kusabab urang nuturkeun infrastruktur salaku pendekatan kode (IaC), kodeu aplikasi, parentah pikeun assembling jeung launching eta kudu persis dina hiji gudang. Kanggo inpo nu langkung lengkep ihwal ieu, tingali laporan sarua.
3. ranté pangiriman (pangiriman) biasana urang tingali sapertos kieu: aplikasina dirakit, diuji, dileupaskeun (tahap pelepasan) sareng éta - pangiriman parantos dilaksanakeun. Tapi kanyataanana, pangguna nampi naon anu anjeun gulung, teu lajeng mun anjeun dikirimkeun ka produksi, sarta nalika anjeunna bisa indit ka dinya jeung produksi ieu digawé. Ku kituna kuring yakin ranté pangiriman ends ngan dina tahap operasional (lumpat), atawa leuwih tepatna, malah dina momen nalika kode ieu dikaluarkeun tina produksi (ngaganti ku nu anyar).

Hayu urang balik deui ka skéma pangiriman luhur di Kubernetes: ieu nimukeun teu ukur ku urang, tapi sacara harfiah sadayana anu nungkulan masalah ieu. Kanyataanna, pola ieu ayeuna disebut GitOps (Anjeun tiasa maca langkung seueur ngeunaan istilah sareng ideu di tukangeunana di dieu). Hayu urang nempo tahapan skéma.

Ngawangun panggung

Sigana mah anjeun tiasa ngobrol ngeunaan ngawangun gambar Docker di 2019, nalika sadayana terang kumaha nyerat Dockerfiles sareng ngajalankeun. docker build?.. Ieu sababaraha nuansa anu kuring hoyong perhatikeun:

1. beurat gambar urusan, jadi make multi-tahapninggalkeun dina gambar ngan aplikasi nu bener diperlukeun pikeun operasi.
2. Jumlah lapisan kudu diminimalkeun ku ngagabungkeun ranté tina RUN-paréntah nurutkeun harti.
3. Nanging, ieu nambihan masalah debugging, Kusabab nalika assembly nu ngadat, anjeun kudu neangan paréntah katuhu tina ranté nu ngabalukarkeun masalah.
4. Laju Majelis penting sabab urang hayang gancang gulung kaluar parobahan jeung ningali hasilna. Salaku conto, anjeun henteu hoyong ngawangun deui katergantungan dina perpustakaan basa unggal waktos anjeun ngawangun aplikasi.
5. Sering tina hiji gudang Git anjeun peryogi loba gambar, anu tiasa direngsekeun ku sakumpulan Dockerfiles (atanapi namina tahapan dina hiji file) sareng skrip Bash kalayan rakitan berurutan.

Ieu ngan ukur puncak gunung es anu disanghareupan ku sadayana. Tapi aya masalah anu sanés, khususna:

1. Sering dina tahap assembly urang peryogi hal gunung (Contona, cache hasil paréntah sapertos apt dina diréktori pihak katilu).
2. Urang hayang Ansible tinimbang nulis dina cangkang.
3. Urang hayang ngawangun tanpa Docker (naha urang kudu mesin virtual tambahan nu urang kudu ngonpigurasikeun sagalana pikeun ieu, lamun urang geus boga klaster Kubernetes nu urang bisa ngajalankeun peti?).
4. Majelis paralel, nu bisa dipikaharti ku cara béda: Paréntah béda ti Dockerfile (lamun multi-tahap dipaké), sababaraha commits of Repository sarua, sababaraha Dockerfiles.
5. Majelis disebarkeun: Urang rék ngumpulkeun hal dina pods anu "ephemeral" sabab cache maranéhna disappears, nu hartina perlu disimpen wae misah.
6. Ahirna, kuring ngaranna puncak kahayang otomatis: Éta idéal pikeun buka Repository nu, ngetik sababaraha paréntah tur meunangkeun gambar siap-dijieun, dirakit kalawan pamahaman kumaha jeung naon nu kudu bener. Nanging, kuring pribadi henteu yakin yén sadaya nuansa tiasa diramalkeun ku cara ieu.

Sareng ieu mangrupikeun proyék:

• moby / buildkit - pembina ti Docker Inc (parantos terpadu kana versi Docker ayeuna), anu nyobian ngabéréskeun sadaya masalah ieu;
• kaniko - pembina ti Google anu ngamungkinkeun anjeun ngawangun tanpa Docker;
• Buildpacks.io - usaha CNCF urang nyieun magic otomatis tur, hususna, hiji solusi metot kalawan rebase pikeun lapisan;
• sareng sakumpulan utilitas sanés, sapertos ngawangun, genuinetools / img...

... sareng tingali sabaraha béntang aranjeunna dina GitHub. Maksudna, di hiji sisi, docker build aya tur bisa ngalakukeun hiji hal, tapi kanyataanana masalahna teu lengkep direngsekeun - buktina ieu ngembangkeun paralel kolektor alternatif, nu masing-masing solves sababaraha bagian tina masalah.

Majelis di werf

Janten urang kedah werf (baheula kawéntar kawas dapp) - Utilitas open source ti perusahaan Flant, anu parantos kami damel mangtaun-taun. Éta sadayana dimimitian 5 sababaraha taun ka pengker sareng skrip Bash anu ngaoptimalkeun rakitan Dockerfiles, sareng salami 3 taun ka pengker pangwangunan pinuh parantos dilaksanakeun dina kerangka hiji proyék sareng gudang Git sorangan. (mimiti dina Ruby, teras ditulis deui to Go, sareng dina waktos anu sami namina). Naon masalah assembly nu direngsekeun di werf?

Masalah anu diwarnaan biru parantos dilaksanakeun, ngawangun paralel dilakukeun dina host anu sami, sareng masalah anu disorot dina warna konéng direncanakeun bakal réngsé dina ahir usum panas.

Tahap publikasi dina pendaptaran (nyebarkeun)

Urang nelepon docker push... - naon bisa jadi hésé ngeunaan unggah hiji gambar ka pendaptaran? Teras timbul patarosan: "Tag naon anu kuring kedah pasang dina gambar?" Éta timbul pikeun alesan yén urang gaduh Gitflow (atanapi strategi Git anu sanés) sareng Kubernetes, sareng industri nyobian mastikeun yén naon anu lumangsung di Kubernetes nuturkeun naon anu lumangsung di Git. Barina ogé, Git mangrupikeun hiji-hijina sumber bebeneran urang.

Naon anu sesah ngeunaan ieu? Pastikeun reproducibility: ti commit di Git, anu sifatna immutable (teu bisa dirobah), ka gambar Docker, anu kedah dijaga sami.

Éta ogé penting pikeun urang nangtukeun asal, sabab urang hoyong ngartos ti mana commit aplikasi ngajalankeun di Kubernetes ieu diwangun (mangka urang tiasa ngalakukeun diffs sarta hal sarupa).

Strategi méré tag

Nu kahiji basajan poé git. Simkuring boga pendaptaran kalawan gambar tagged salaku 1.0. Kubernetes gaduh panggung sareng produksi, dimana gambar ieu diunggah. Dina Git urang nyieun commits na di sawatara titik urang tag 2.0. Urang ngumpulkeun éta nurutkeun parentah ti Repository sarta nempatkeun eta dina pendaptaran kalawan tag 2.0. Urang gulung ka panggung sareng, upami sadayana saé, teras ka produksi.

Masalah sareng pendekatan ieu urang mimiti nempatkeun tag, sarta ngan lajeng diuji sarta digulung kaluar. Naha? Anu mimiti, éta ngan saukur teu logis: kami ngaluarkeun versi parangkat lunak anu kami henteu acan diuji (urang henteu tiasa ngalakukeun anu sanés, sabab pikeun mariksa, urang kedah nempatkeun tag). Kadua, jalur ieu henteu cocog sareng Gitflow.

Pilihan kadua nyaéta git commit + tag. Cabang master gaduh tag 1.0; pikeun eta dina pendaptaran - hiji gambar deployed ka produksi. Salaku tambahan, klaster Kubernetes gaduh kontur sawangan sareng pementasan. Salajengna urang turutan Gitflow: dina cabang utama pikeun pangwangunan (develop) urang nyieun fitur anyar, hasilna commit kalawan identifier nu #c1. Kami ngumpulkeun éta sareng nyebarkeun éta dina pendaptaran nganggo identifier ieu (#c1). Kalawan identifier sarua urang gulung kaluar pikeun nilik. Urang lakonan hal nu sarua jeung commits #c2 и #c3.

Nalika urang sadar yén aya cukup fitur, urang ngawitan nyaimbangkeun sagalana. Jieun cabang di Git release_1.1 (dina dasarna #c3 ti develop). Teu perlu ngumpulkeun release ieu, sabab ... ieu dipigawé dina hambalan saméméhna. Ku alatan éta, urang ngan saukur bisa gulung kaluar kana pementasan. Urang ngalereskeun bug di #c4 sareng sami ngagulung ka pementasan. Dina waktos anu sami, pangwangunan dijalankeun develop, dimana parobahan nu périodik dicokot tina release_1.1. Dina sababaraha waktos, kami nampi komitmen anu disusun sareng diunggah kana pementasan, anu kami senang (#c25).

Teras urang ngahijikeun (kalayan gancang-gancang) cabang pelepasan (release_1.1) dina master. Kami nempatkeun tag sareng versi énggal dina komitmen ieu (1.1). Tapi gambar ieu parantos dikumpulkeun dina pendaptaran, janten supados henteu ngumpulkeun deui, urang ngan saukur nambihan tag kadua kana gambar anu tos aya (ayeuna gaduh tag dina pendaptaran. #c25 и 1.1). Sanggeus éta, urang gulung kaluar ka produksi.

Aya kalemahan yén ngan ukur hiji gambar anu diunggah kana pementasan (#c25), sarta dina produksi éta jenis béda (1.1), tapi urang terang yén "fisik" ieu mangrupikeun gambar anu sami tina pendaptaran.

Karugian nyata nyaéta teu aya dukungan pikeun ngahijikeun komitmen, anjeun kedah gancang-gancang.

Urang tiasa langkung jauh sareng ngalakukeun trik ... Hayu urang tingali conto Dockerfile saderhana:

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/public

Hayu urang ngawangun file tina éta dumasar kana prinsip ieu:

• SHA256 tina idéntifikasi gambar anu dianggo (ruby:2.3 и nginx:alpine), anu mangrupa checksum tina eusina;
• sadaya tim (RUN, CMD teras salajengna.);
• SHA256 tina file anu ditambahkeun.

... sareng nyandak checksum (deui SHA256) tina file sapertos kitu. Ieu tanda tangan sagalana nu ngahartikeun eusi gambar Docker.

Hayu urang balik ka diagram na tinimbang commits kami bakal ngagunakeun tanda tangan sapertos, i.e. tag gambar kalawan tanda tangan.

Ayeuna, nalika perlu, contona, pikeun ngahijikeun parobahan tina sékrési ka master, urang tiasa ngalakukeun komitmen gabungan anu nyata: éta bakal gaduh identifier anu béda, tapi tanda tangan anu sami. Kalayan identifier anu sami kami bakal ngagulung gambar ka produksi.

Karugianna nyaéta ayeuna moal mungkin pikeun nangtukeun jenis komitmen anu didorong pikeun produksi - checksum ngan ukur tiasa dianggo dina hiji arah. Masalah ieu direngsekeun ku lapisan tambahan sareng metadata - kuring bakal nyarioskeun ka anjeun engké.

Tagging dina werf

Dina werf urang indit malah salajengna jeung Nyiapkeun pikeun ngalakukeun ngawangun disebarkeun ku cache nu teu disimpen dina hiji mesin ... Ku kituna, urang ngawangun dua jenis gambar Docker, urang nelepon aranjeunna. panggung и gambaran.

Repositori werf Git nyimpen petunjuk khusus pikeun ngawangun anu ngajelaskeun tahapan-tahapan ngawangun (sateuacanPasang, masang, sateuacanSetup, disetél). Kami ngumpulkeun gambar tahap kahiji kalayan tanda tangan anu didefinisikeun salaku checksum tina léngkah munggaran. Teras we tambahkeun kodeu sumber, pikeun gambar panggung anyar urang ngitung checksum na ... Operasi ieu diulang pikeun sakabéh tahapan, salaku hasilna urang meunang susunan gambar panggung. Teras we ngadamel gambar ahir, anu ogé ngandung metadata ngeunaan asal-usulna. Sarta kami tag gambar ieu ku cara béda (detail engké).

Anggap saatos ieu komitmen anyar muncul dimana ngan ukur kode aplikasi anu parantos dirobih. Naon anu bakal kajadian? Pikeun parobahan kode, patch bakal dijieun jeung gambar panggung anyar bakal disiapkeun. Signature na bakal ditangtukeun salaku checksum tina gambar panggung heubeul jeung patch anyar. Gambar ahir anyar bakal kabentuk tina gambar ieu. Paripolah anu sami bakal lumangsung kalayan parobihan dina tahapan anu sanés.

Janten, gambar panggung mangrupikeun cache anu tiasa disimpen sacara disebarkeun, sareng gambar anu parantos didamel tina éta diunggah ka Docker Registry.

Ngabersihan pendaptaran

Kami henteu ngobrol ngeunaan ngahapus lapisan anu tetep ngagantung saatos tag dihapus - ieu mangrupikeun fitur standar tina Docker Registry sorangan. Kami nyarioskeun kaayaan nalika seueur tag Docker ngumpulkeun sareng kami ngartos yén kami henteu peryogi deui sababaraha di antarana, tapi butuh rohangan (sareng / atanapi urang mayar).

Naon strategi beberesih?

1. Anjeun ngan bisa ngalakukeun nanaon teu beberesih. Kadangkala kacida gampang mayar saeutik pikeun spasi tambahan ti unravel kutang badag tina tag. Tapi ieu ngan dianggo nepi ka titik nu tangtu.
2. Reset pinuh. Upami anjeun ngahapus sadaya gambar sareng ngawangun deui ngan ukur anu ayeuna dina sistem CI, masalah tiasa timbul. Upami wadahna di-restart deui dina produksi, gambar énggal bakal dimuat pikeun éta - gambar anu henteu acan diuji ku saha waé. Ieu maéhan ideu infrastruktur anu teu tiasa dirobih.
3. Bulao-héjo. Hiji pendaptaran mimiti ngabahekeun - urang unggah gambar ka nu sejen. Masalah anu sami sareng metodeu sateuacana: dina waktos naon anjeun tiasa mupus pendaptaran anu mimiti ngabahekeun?
4. Dumasar waktos. Pupus sadaya gambar anu langkung lami ti 1 bulan? Tapi pasti bakal aya layanan anu teu acan diropéa salila sabulan ...
5. sacara manual nangtukeun naon nu geus bisa dihapus.

Aya dua pilihan anu leres-leres: ulah ngabersihan atanapi kombinasi biru-héjo + sacara manual. Dina kasus anu terakhir, urang ngobrol ngeunaan ieu: nalika anjeun ngartos yén éta waktuna pikeun ngabersihan pendaptaran, anjeun nyiptakeun anu énggal sareng nambihan sadaya gambar énggal ka dinya salami, contona, sabulan. Sarta sanggeus sabulan, tingali nu pods di Kubernetes masih ngagunakeun pendaptaran heubeul, sarta mindahkeun ogé ka pendaptaran anyar.

Naon geus kami datang ka werf? Urang ngumpulkeun:

1. Kepala Git: sadayana tag, sadaya cabang - asumsina yén urang peryogi sadayana anu ditandaan dina Git dina gambar (sareng upami henteu, maka urang kedah ngahapus dina Git sorangan);
2. kabéh pods nu ayeuna ngompa kaluar ka Kubernetes;
3. ReplicaSets heubeul (naon ieu nembe dirilis), sarta kami ogé rencanana scan Helm release tur pilih gambar panganyarna aya.

... jeung nyieun whitelist tina set ieu - daptar gambar nu urang moal ngahapus. Urang ngabersihan kaluar sagalana sejenna, nu satutasna urang manggihan gambar panggung yatim jeung ngahapus ogé.

Tahap nyebarkeun

Déklaratif dipercaya

Titik kahiji anu abdi hoyong narik perhatian dina deployment nyaeta rollout tina konfigurasi sumberdaya diropéa, nyatakeun declaratively. Dokumén YAML asli anu ngajelaskeun sumber daya Kubernetes sok béda pisan sareng hasil anu leres-leres dijalankeun dina kluster. Kusabab Kubernetes nambihan kana konfigurasi:

1. idéntifikasi;
2. informasi jasa;
3. loba nilai standar;
4. bagian kalawan status ayeuna;
5. parobahan dijieun salaku bagian tina webhook pangakuan;
6. hasil karya rupa Controllers (jeung scheduler nu).

Ku alatan éta, nalika konfigurasi sumberdaya anyar muncul (anyar), urang henteu tiasa ngan ukur nyandak sareng nimpa konfigurasi ayeuna, "hirup" sareng éta (hirup). Jang ngalampahkeun ieu urang kudu ngabandingkeun anyar kalawan konfigurasi dilarapkeun panungtungan (panungtungan-dilarapkeun) jeung gulung kana hirup nampi patch.

Pendekatan ieu disebut 2-arah ngahiji. Hal ieu dipaké, contona, dina Helm.

Aya ogé 3-arah ngahiji, anu béda dina éta:

• ngabandingkeun panungtungan-dilarapkeun и anyar, urang tingali naon anu dihapus;
• ngabandingkeun anyar и hirup, urang nempo naon geus ditambahkeun atawa dirobah;
• patch dijumlahkeun dilarapkeun ka hirup.

Kami nyebarkeun 1000+ aplikasi sareng Helm, janten kami leres-leres hirup sareng ngahiji 2 arah. Tapi, éta ngagaduhan sababaraha masalah anu kami parantos direngsekeun ku patch kami, anu ngabantosan Helm tiasa dianggo normal.

Status rollout nyata

Saatos sistem CI kami ngahasilkeun konfigurasi anyar pikeun Kubernetes dumasar kana acara salajengna, éta ngirimkeunana pikeun dianggo (ngalamar) ka klaster - ngagunakeun Helm atawa kubectl apply. Salajengna, ngagabung N-jalan geus dijelaskeun lumangsung, nu API Kubernetes ngabales approvingly kana sistem CI, sarta yén pikeun pamaké na.

Sanajan kitu, aya masalah badag: sanggeus kabeh aplikasi suksés henteu hartosna rollout suksés. Upami Kubernetes ngartos parobahan naon anu kedah diterapkeun sareng nerapkeunana, kami masih henteu terang kumaha hasilna. Contona, ngamutahirkeun sarta balikan deui pods di frontend nu bisa jadi suksés, tapi teu di backend, sarta kami bakal meunang versi béda tina gambar aplikasi jalan.

Pikeun ngalakukeun sadayana leres, skéma ieu peryogi tautan tambahan - tracker khusus anu bakal nampi inpormasi status tina API Kubernetes sareng ngirimkeunana pikeun analisa salajengna ngeunaan kaayaan nyata. Kami nyiptakeun perpustakaan Open Source di Go - cubedog (tingali pengumumanna di dieu), nu solves masalah ieu sarta diwangun kana werf.

Paripolah tracker ieu dina tingkat werf dikonpigurasi nganggo annotations anu disimpen dina Deployments atanapi StatefulSets. Anotasi utama - fail-mode - ngartos harti handap:

• IgnoreAndContinueDeployProcess - urang malire masalah rolling kaluar komponén ieu terus deployment;
• FailWholeDeployProcessImmediately - kasalahan dina komponén ieu ngeureunkeun prosés deployment;
• HopeUntilEndOfDeployProcess - urang miharep yén komponén ieu bakal dianggo ku tungtung deployment nu.

Contona, kombinasi ieu sumberdaya jeung nilai annotation fail-mode:

Nalika urang nyebarkeun pikeun kahiji kalina, pangkalan data (MongoDB) panginten henteu acan siap - Deployments bakal gagal. Tapi anjeun bisa ngadagoan momen pikeun ngamimitian, sarta deployment masih bakal lumangsung.

Aya dua deui anotasi pikeun kubedog di werf:

• failures-allowed-per-replica - Jumlah ragrag diwenangkeun pikeun tiap replika;
• show-logs-until - ngatur momen nepi ka mana werf nembongkeun (dina stdout) log ti sakabéh pods digulung kaluar. standar nyaéta PodIsReady (Pikeun malire pesen anu urang henteu hoyong pisan nalika lalu lintas mimiti datang ka pod), tapi nilaina ogé sah: ControllerIsReady и EndOfDeploy.

Naon deui anu urang pikahoyong tina panyebaran?

Salian dua titik anu parantos dijelaskeun, kami hoyong:

• tingali log - sareng ngan ukur anu diperyogikeun, sareng henteu sadayana sakaligus;
• lagu kamajuan, sabab lamun pakasaban hangs "jempé" pikeun sababaraha menit, hal anu penting pikeun ngarti naon anu lumangsung di dinya;
• ngabogaan rollback otomatis bisi aya anu salah (ku kituna penting pikeun terang status nyata panyebaran). Rollout kudu atom: boh eta ngaliwatan nepi ka ahir, atawa sagalana balik deui ka kaayaan saméméhna.

hasil

Pikeun kami salaku perusahaan, pikeun ngalaksanakeun sagala nuansa anu dijelaskeun dina tahapan pangiriman anu béda (ngawangun, nyebarkeun, nyebarkeun), sistem CI sareng utilitas cekap. werf.

Daripada kasimpulan:

Kalayan bantosan werf, kami parantos kamajuan anu saé dina ngarengsekeun sajumlah ageung masalah pikeun insinyur DevOps sareng bakal bungah upami komunitas anu langkung lega sahenteuna nyobian utiliti ieu dina aksi. Bakal leuwih gampang pikeun ngahontal hasil alus babarengan.

Video sareng slide

Video tina pagelaran (~ 47 menit):

Presentasi laporan:

PS

Laporan séjén ngeunaan Kubernetes dina blog kami:

• «Autoscaling sarta manajemén sumberdaya di Kubernetes» (Dmitry Stolyarov; 27 April 2019 dina "Strike");
• «Ngalegaan sareng ngalengkepan Kubernetes» (Andrey Polovov; 8 April 2019 dina Saint HighLoad++);
• «Basis data sareng Kubernetes» (Dmitry Stolyarov; 8 Nopémber 2018 dina HighLoad++);
• «Ngawaskeun sarta Kubernetes» (Dmitry Stolyarov; 28 Méi 2018 di RootConf);
• «Praktek Pangalusna CI/CD sareng Kubernetes sareng GitLab» (Dmitry Stolyarov; 7 Nopémber 2017 dina HighLoad++);
• «Pangalaman urang sareng Kubernetes dina proyék-proyék leutik» (Dmitry Stolyarov; 6 Juni 2017 di RootConf).

sumber: www.habr.com