Mga serbisyo ng ulila: ang downside ng (micro) na arkitektura ng serbisyo

Ang Direktor ng Operasyon ng Banki.ru portal na si Andrey Nikolsky ay nagsalita sa kumperensya noong nakaraang taon DevOpsDays Moscow tungkol sa mga serbisyo ng ulila: kung paano makilala ang isang ulila sa imprastraktura, bakit masama ang mga serbisyo ng ulila, kung ano ang gagawin sa kanila, at kung ano ang gagawin kung walang makakatulong.

Sa ibaba ng cut ay isang text na bersyon ng ulat.

Hello mga kasamahan! Ang pangalan ko ay Andrey, pinamumunuan ko ang mga operasyon sa Banki.ru.

Mayroon kaming malalaking serbisyo, ito ay mga serbisyong monolitik, may mga serbisyo sa mas klasikal na kahulugan, at may napakaliit. Sa aking terminolohiyang manggagawa-magsasaka, sinasabi ko na kung ang isang serbisyo ay simple at maliit, kung gayon ito ay micro, at kung ito ay hindi masyadong simple at maliit, kung gayon ito ay isang serbisyo lamang.

Mga kalamangan ng mga serbisyo

Mabilis kong tatalakayin ang mga pakinabang ng mga serbisyo.

Ang una ay scaling. Mabilis kang makakagawa ng isang bagay sa serbisyo at simulan ang produksyon. Nakatanggap ka ng trapiko, na-clone mo ang serbisyo. Mayroon kang higit na trapiko, na-clone mo ito at nabubuhay kasama nito. Ito ay isang magandang bonus, at, sa prinsipyo, noong nagsimula kami, ito ay itinuturing na pinakamahalagang bagay para sa amin, kung bakit namin ginagawa ang lahat ng ito.

Pangalawa, isolated development, kapag mayroon kang ilang development team, maraming iba't ibang developer sa bawat team, at bawat team ay bumuo ng sarili nitong serbisyo.

Sa mga koponan mayroong isang pananarinari. Iba-iba ang mga developer. At mayroong, halimbawa, mga taong snowflake. Una kong nakita ito kay Maxim Dorofeev. Minsan ang mga taong snowflake ay nasa ilang mga koponan at hindi sa iba. Ginagawa nitong medyo hindi pantay ang iba't ibang serbisyong ginagamit sa buong kumpanya.

Tingnan ang larawan: ito ay isang mahusay na developer, siya ay may malaking kamay, marami siyang magagawa. Ang pangunahing problema ay kung saan nanggaling ang mga kamay na ito.

Ginagawang posible ng mga serbisyo na gumamit ng iba't ibang mga programming language na mas angkop para sa iba't ibang mga gawain. Ang ilang serbisyo ay nasa Go, ang ilan ay nasa Erlang, ang ilan ay nasa Ruby, ang isang bagay ay nasa PHP, ang isang bagay ay nasa Python. Sa pangkalahatan, maaari mong palawakin nang napakalawak. May mga nuances din dito.

Pangunahing tungkol sa mga devop ang arkitektura na nakatuon sa serbisyo. Ibig sabihin, kung wala kang automation, walang proseso ng pag-deploy, kung manu-mano mo itong i-configure, maaaring magbago ang iyong mga configuration mula sa isang instance ng serbisyo, at kailangan mong pumunta doon para gumawa ng isang bagay, pagkatapos ay nasa impiyerno ka.

Halimbawa, mayroon kang 20 serbisyo at kailangan mong i-deploy sa pamamagitan ng kamay, mayroon kang 20 console, at sabay-sabay mong pinindot ang “enter” na parang ninja. Hindi ito masyadong maganda.

Kung mayroon kang isang serbisyo pagkatapos ng pagsubok (kung may pagsubok, siyempre), at kailangan mo pa ring tapusin ito ng isang file upang gumana ito sa produksyon, mayroon din akong masamang balita para sa iyo.

Kung umaasa ka sa mga partikular na serbisyo ng Amazon at nagtatrabaho sa Russia, dalawang buwan na ang nakalipas ay mayroon ka ring "Nasusunog ang lahat sa paligid, ayos lang ako, lahat ay cool."

Ginagamit namin ang Ansible para i-automate ang deployment, Puppet para sa convergence, Bamboo para i-automate ang deployment, at Confluence para kahit papaano ay ilarawan ang lahat ng ito.

Hindi ko ito tatalakayin nang detalyado, dahil ang ulat ay higit pa tungkol sa mga kasanayan sa pakikipag-ugnayan, at hindi tungkol sa teknikal na pagpapatupad.

Halimbawa, nagkaroon kami ng mga problema kung saan gumagana ang Puppet sa server sa Ruby 2, ngunit ang ilang application ay isinulat para sa Ruby 1.8, at hindi sila gumagana nang magkasama. May mali doon. At kapag kailangan mong magpatakbo ng maraming bersyon ng Ruby sa isang makina, kadalasan ay nagsisimula kang magkaroon ng mga problema.

Halimbawa, binibigyan namin ang bawat developer ng isang platform kung saan mayroong humigit-kumulang lahat ng mayroon kami, lahat ng mga serbisyo na maaaring mabuo, upang mayroon siyang isang nakahiwalay na kapaligiran, maaari niyang sirain ito at itayo ito ayon sa gusto niya.

Nangyayari na kailangan mo ng ilang espesyal na pinagsama-samang pakete na may suporta para sa isang bagay doon. Ito ay medyo matigas. Nakinig ako sa isang ulat kung saan ang imahe ng Docker ay tumitimbang ng 45 GB. Sa Linux, siyempre, mas simple ito, mas maliit ang lahat doon, ngunit gayon pa man, hindi magkakaroon ng sapat na espasyo.

Well, may mga magkasalungat na dependencies, kapag ang isang piraso ng proyekto ay nakasalalay sa isang library ng isang bersyon, ang isa pang piraso ng proyekto ay nakasalalay sa isa pang bersyon, at ang mga library ay hindi naka-install nang magkasama.

Mayroon kaming mga site at serbisyo sa PHP 5.6, nahihiya kami sa kanila, ngunit ano ang magagawa namin? Ito ang aming isang site. May mga site at serbisyo sa PHP 7, mas marami, hindi namin ikinahihiya. At ang bawat developer ay may kanya-kanyang base kung saan masayang nakikita niya.

Kung sumulat ka sa isang kumpanya sa isang wika, ang tatlong virtual machine sa bawat developer ay parang normal. Kung mayroon kang iba't ibang mga wika sa programming, ang sitwasyon ay lumalala.

Mayroon kang mga site at serbisyo dito, dito, pagkatapos ay isa pang site para sa Go, isang site para kay Ruby, at ilang iba pang Redis sa gilid. Bilang isang resulta, ang lahat ng ito ay nagiging isang malaking field para sa suporta, at sa lahat ng oras ang ilan sa mga ito ay maaaring masira.

Samakatuwid, pinalitan namin ang mga benepisyo ng programming language sa paggamit ng iba't ibang mga frameworks, dahil ang PHP frameworks ay medyo naiiba, mayroon silang iba't ibang mga kakayahan, iba't ibang mga komunidad, at iba't ibang suporta. At maaari kang magsulat ng isang serbisyo upang mayroon ka nang handa para dito.

Ang bawat serbisyo ay may sariling koponan

Ang aming pangunahing bentahe, na nag-kristal sa loob ng ilang taon, ay ang bawat serbisyo ay may sariling koponan. Ito ay maginhawa para sa isang malaking proyekto, maaari kang makatipid ng oras sa dokumentasyon, alam ng mga tagapamahala ang kanilang proyekto.

Madali kang makakapagsumite ng mga gawain mula sa suporta. Halimbawa, nasira ang serbisyo ng insurance. At kaagad ang pangkat na nakikitungo sa insurance ay pumunta upang ayusin ito.

Mabilis na nagagawa ang mga bagong feature, dahil kapag mayroon kang isang atomic na serbisyo, maaari mong mabilis na masira ang isang bagay dito.

At kapag sinira mo ang iyong serbisyo, at hindi maiiwasang mangyari ito, hindi mo naapektuhan ang mga serbisyo ng ibang tao, at ang mga developer mula sa iba pang mga koponan ay hindi lalapit sa iyo nang may mga bit at sasabihin: "Ay-ay, huwag mong gawin iyon."

Gaya ng dati, may mga nuances. Mayroon kaming matatag na mga koponan, ang mga tagapamahala ay ipinako sa koponan. Mayroong malinaw na mga dokumento, maingat na sinusubaybayan ng mga tagapamahala ang lahat. Ang bawat koponan na may manager ay may ilang mga serbisyo, at mayroong isang tiyak na punto ng kakayahan.

Kung ang mga koponan ay lumulutang (ginagamit din namin minsan ito), mayroong isang mahusay na pamamaraan na tinatawag na "star map".

Mayroon kang listahan ng mga serbisyo at tao. Ang asterisk ay nangangahulugan na ang tao ay isang eksperto sa serbisyong ito, ang isang libro ay nangangahulugan na ang tao ay nag-aaral ng serbisyong ito. Ang gawain ng tao ay palitan ang buklet para sa isang asterisk. At kung walang nakasulat sa harap ng serbisyo, magsisimula ang mga problema, na pag-uusapan ko pa.

Paano lumilitaw ang mga serbisyo ng ulila?

Ang unang problema, ang unang paraan upang makakuha ng serbisyo ng ulila sa iyong imprastraktura ay ang pagtanggal ng mga tao. Mayroon bang sinumang nagkaroon ng negosyo na nakakatugon sa mga takdang oras bago masuri ang mga gawain? Minsan nangyayari na ang mga deadline ay mahigpit at walang sapat na oras para sa dokumentasyon. "Kailangan naming ibigay ang serbisyo sa produksyon, pagkatapos ay idagdag namin ito."

Kung ang koponan ay maliit, nangyayari na mayroong isang developer na nagsusulat ng lahat, ang natitira ay nasa mga pakpak. "Isinulat ko ang pangunahing arkitektura, idagdag natin ang mga interface." Pagkatapos sa ilang mga punto ang manager, halimbawa, umalis. At sa panahong ito, kapag umalis ang tagapamahala at hindi pa naitalaga ang isang bago, ang mga developer mismo ang magpapasya kung saan pupunta ang serbisyo at kung ano ang nangyayari doon. At tulad ng alam natin (bumalik tayo ng ilang slide), sa ilang mga koponan ay may mga taong snowflake, minsan ay isang snowflake na nangunguna sa koponan. Pagkatapos ay huminto siya, at kumuha kami ng serbisyong ulila.

Kasabay nito, ang mga gawain mula sa suporta at mula sa negosyo ay hindi nawawala; sila ay napupunta sa backlog. Kung mayroong anumang mga pagkakamali sa arkitektura sa panahon ng pagbuo ng serbisyo, napupunta rin sila sa backlog. Ang serbisyo ay unti-unting lumalala.

Paano makilala ang isang ulila?

Inilalarawan ng listahang ito ang sitwasyon nang maayos. Sino ang may natutunan tungkol sa kanilang imprastraktura?

Tungkol sa mga dokumentadong work-around: mayroong isang serbisyo at, sa pangkalahatan, ito ay gumagana, mayroon itong dalawang-pahinang manual kung paano ito gagawin, ngunit walang nakakaalam kung paano ito gumagana sa loob.

O, halimbawa, mayroong ilang uri ng link shortener. Halimbawa, kasalukuyan kaming mayroong tatlong link shortener na ginagamit para sa iba't ibang layunin sa iba't ibang serbisyo. Ito ay mga kahihinatnan lamang.

Ngayon ako ang magiging kapitan ng obvious. Ano ang dapat gawin? Una, kailangan nating ilipat ang serbisyo sa ibang manager, ibang team. Kung hindi pa humihinto ang iyong team lead, sa kabilang team na ito, kapag naunawaan mo na ang serbisyo ay parang ulila, kailangan mong isama ang isang taong nakakaintindi ng kahit isang bagay tungkol dito.

Ang pangunahing bagay: dapat mayroon kang mga pamamaraan sa paglipat na nakasulat sa dugo. Sa aming kaso, karaniwan kong sinusubaybayan ito, dahil kailangan ko ang lahat upang gumana. Kailangan ito ng mga manager na maihatid nang mabilis, at kung ano ang mangyayari dito sa ibang pagkakataon ay hindi na napakahalaga sa kanila.

Ang susunod na paraan para maging ulila ay "Gagawin namin ito nang outsourced, magiging mas mabilis ito, at pagkatapos ay ibibigay namin ito sa team." Ito ay malinaw na ang lahat ay may ilang mga plano sa koponan, isang turn. Kadalasan ang isang customer ng negosyo ay nag-iisip na ang outsourcer ay gagawin ang parehong bagay tulad ng teknikal na departamento na mayroon ang kumpanya. Bagama't iba ang kanilang mga motivator. May mga kakaibang teknolohikal na solusyon at kakaibang algorithmic na solusyon sa outsourcing.

Halimbawa, mayroon kaming serbisyo na mayroong Sphinx sa iba't ibang hindi inaasahang lugar. Sasabihin ko sa iyo mamaya kung ano ang dapat kong gawin.

Ang mga outsourcer ay may mga self-written frameworks. Ito ay hubad lamang na PHP na may copy-paste mula sa isang nakaraang proyekto, kung saan mahahanap mo ang lahat ng uri ng mga bagay. Ang mga deployment script ay isang malaking disbentaha kapag kailangan mong gumamit ng ilang kumplikadong Bash script upang baguhin ang ilang linya sa ilang file, at ang mga deployment script na ito ay tinatawag ng ilang ikatlong script. Bilang resulta, binago mo ang sistema ng pag-deploy, pumili ng iba, lumukso, ngunit hindi gumagana ang iyong serbisyo. Dahil doon ito ay kinakailangan upang maglagay ng 8 higit pang mga link sa pagitan ng iba't ibang mga folder. O nangyayari na isang libong talaan ang gumagana, ngunit isang daang libo ang hindi na gumagana.

Itutuloy ko ang pagiging kapitan. Ang pagtanggap ng isang outsourced na serbisyo ay isang mandatoryong pamamaraan. May nakarating na ba ng outsourced na serbisyo at hindi tinatanggap kahit saan? Ito ay hindi kasing tanyag, siyempre, bilang isang serbisyo ng ulila, ngunit gayon pa man.

Kailangang suriin ang serbisyo, kailangang suriin ang serbisyo, kailangang baguhin ang mga password. Nagkaroon kami ng kaso noong binigyan nila kami ng serbisyo, may admin panel “if login == 'admin' && password == 'admin'...”, nakasulat mismo sa code. Umupo kami at nag-iisip, at isinulat ito ng mga tao sa 2018?

Ang pagsubok sa kapasidad ng imbakan ay kailangan ding bagay. Kailangan mong tingnan kung ano ang mangyayari sa isang daang libong mga rekord, kahit na bago mo ilagay ang serbisyong ito sa produksyon sa isang lugar.

Walang dapat ikahiya sa pagpapadala ng serbisyo para sa pagpapabuti. Kapag sinabi mong: "Hindi namin tatanggapin ang serbisyong ito, mayroon kaming 20 mga gawain, gawin ang mga ito, pagkatapos ay tatanggapin namin," ito ay normal. Ang iyong konsensya ay hindi dapat masaktan sa katotohanan na ikaw ay nagse-set up ng isang manager o na ang negosyo ay nag-aaksaya ng pera. Ang negosyo ay gagastos ng higit pa.

Nagkaroon kami ng kaso noong nagpasya kaming mag-outsource ng isang pilot project.

Naihatid ito sa oras, at ito lang ang pamantayan ng kalidad. Kaya naman gumawa kami ng isa pang pilot project, na hindi na talaga piloto. Ang mga serbisyong ito ay tinanggap, at sa pamamagitan ng administratibong paraan ay sinabi nila, narito ang iyong code, narito ang koponan, narito ang iyong tagapamahala. Ang mga serbisyo ay talagang nagsimula nang kumita. Kasabay nito, sa katunayan, sila ay mga ulila pa rin, walang nakakaintindi kung paano sila nagtatrabaho, at ginagawa ng mga tagapamahala ang kanilang makakaya upang itakwil ang kanilang mga gawain.

May isa pang mahusay na konsepto - pag-unlad ng gerilya. Kapag ang ilang departamento, kadalasan ang departamento ng marketing, ay gustong subukan ang isang hypothesis at inutusan ang buong serbisyo na i-outsource. Ang trapiko ay nagsimulang bumuhos dito, isinara nila ang mga dokumento, pumirma ng mga dokumento kasama ang kontratista, pumasok sa operasyon at nagsasabing: "Mga pare, mayroon kaming serbisyo dito, mayroon na itong trapiko, nagdadala ito sa amin ng pera, tanggapin natin ito." Kami ay tulad ng, "Oppa, paano iyon."

At isa pang paraan para makakuha ng orphan service: kapag biglang na-load ang ilang team, sinabi ng management: "Ilipat natin ang serbisyo ng team na ito sa ibang team, mas maliit ang load nito." At pagkatapos ay ililipat namin ito sa isang ikatlong koponan at papalitan ang manager. At sa huli, ulila na naman kami.

Ano ang problema ng mga ulila?

Sino ang hindi nakakaalam, ito ang barkong pandigma na Wasa na pinalaki sa Sweden, na sikat sa katotohanang lumubog ito 5 minuto pagkatapos ilunsad. At ang Hari ng Sweden, sa pamamagitan ng paraan, ay hindi nagsagawa ng sinuman para dito. Ito ay itinayo ng dalawang henerasyon ng mga inhinyero na hindi alam kung paano gumawa ng mga naturang barko. Likas na epekto.

Ang barko ay maaaring lumubog, sa pamamagitan ng paraan, sa isang mas masamang paraan, halimbawa, kapag ang hari ay nakasakay na dito sa isang lugar sa isang bagyo. At kaya, nalunod siya kaagad, ayon kay Agile, mabuti na mabigo nang maaga.

Kung nabigo tayo nang maaga, kadalasan ay walang mga problema. Halimbawa, sa panahon ng pagtanggap ipinadala ito para sa rebisyon. Ngunit kung nabigo na tayo sa produksyon, kapag ang pera ay namuhunan, pagkatapos ay maaaring magkaroon ng mga problema. Mga kahihinatnan, tulad ng tawag sa mga ito sa negosyo.

Bakit mapanganib ang mga serbisyo sa ulila:

• Maaaring biglang masira ang serbisyo.
• Ang serbisyo ay tumatagal ng mahabang oras upang ayusin o hindi naayos.
• Mga problema sa kaligtasan.
• Mga problema sa mga pagpapabuti at pag-update.
• Kung masira ang isang mahalagang serbisyo, masisira ang reputasyon ng kumpanya.

Ano ang gagawin sa mga serbisyo ng ulila?

Uulitin ko ulit ang gagawin. Una, dapat mayroong dokumentasyon. Itinuro sa akin ng 7 taon sa Banki.ru na ang mga tagasubok ay hindi dapat kunin ang salita ng mga developer, at ang mga operasyon ay hindi dapat kunin ang salita ng lahat. Kailangan nating suriin.

Pangalawa, kinakailangang magsulat ng mga diagram ng pakikipag-ugnayan, dahil nangyayari na ang mga serbisyo na hindi masyadong natanggap ay naglalaman ng mga dependency na walang sinabi tungkol sa. Halimbawa, na-install ng mga developer ang serbisyo sa kanilang susi sa ilang Yandex.Maps o Dadata. Naubusan ka ng libreng limitasyon, nasira ang lahat, at hindi mo alam kung ano ang nangyari. Ang lahat ng naturang rake ay dapat na inilarawan: ang serbisyo ay gumagamit ng Dadata, SMS, iba pa.

Pangatlo, nagtatrabaho sa teknikal na utang. Kapag gumawa ka ng ilang uri ng saklay o tumanggap ng serbisyo at sinabing may kailangang gawin, kailangan mong tiyakin na tapos na ito. Dahil pagkatapos ay maaaring lumabas na ang maliit na butas ay hindi gaanong maliit, at mahuhulog ka dito.

Sa mga gawaing arkitektura, nagkaroon kami ng kuwento tungkol sa Sphinx. Isa sa mga serbisyo ang gumamit ng Sphinx para magpasok ng mga listahan. Isang paginated na listahan lamang, ngunit ito ay muling ini-index tuwing gabi. Binuo ito mula sa dalawang index: isang malaking isa ang ini-index tuwing gabi, at mayroon ding isang maliit na index na naka-screw dito. Araw-araw, na may 50% na posibilidad ng pambobomba o hindi, ang index ay nag-crash sa panahon ng pagkalkula, at ang aming balita ay tumigil sa pag-update sa pangunahing pahina. Sa una ay tumagal ng 5 minuto para muling ma-index ang index, pagkatapos ay lumaki ang index, at sa ilang mga punto ay nagsimula itong tumagal ng 40 minuto upang muling i-index. Kapag pinutol namin ito, nakahinga kami ng maluwag, dahil malinaw na lilipas pa ang kaunting oras at muling ma-index ang aming index nang buong oras. Magiging kabiguan ito para sa aming portal, walang balita sa loob ng walong oras - iyon lang, huminto ang negosyo.

Magplano para sa pagtatrabaho sa isang serbisyo ng ulila

Sa katunayan, ito ay napakahirap gawin, dahil ang devops ay tungkol sa komunikasyon. Gusto mong maging maayos ang pakikitungo sa iyong mga kasamahan, at kapag tinamaan mo ng mga regulasyon ang iyong mga kasamahan at tagapamahala, maaaring magkaroon sila ng magkasalungat na damdamin sa mga taong gumagawa nito.

Bilang karagdagan sa lahat ng mga puntong ito, may isa pang mahalagang bagay: ang mga partikular na tao ay dapat na responsable para sa bawat partikular na serbisyo, para sa bawat partikular na seksyon ng pamamaraan ng pag-deploy. Kapag walang tao at kailangan mong akitin ang ibang tao para pag-aralan ang buong bagay na ito, nagiging mahirap.

Kung ang lahat ng ito ay hindi nakatulong, at ang iyong ulila na serbisyo ay ulila pa rin, walang gustong kumuha nito, ang dokumentasyon ay hindi nakasulat, ang pangkat na tinawag sa serbisyong ito ay tumangging gumawa ng anuman, mayroong isang simpleng paraan - upang gawing muli lahat .

Iyon ay, kinukuha mo muli ang mga kinakailangan para sa serbisyo at sumulat ng isang bagong serbisyo, mas mahusay, sa isang mas mahusay na platform, nang walang kakaibang mga teknolohikal na solusyon. At lumipat ka dito sa labanan.

Nagkaroon kami ng sitwasyon nang kumuha kami ng serbisyo sa Yii 1 at napagtanto namin na hindi na namin ito mapapaunlad, dahil naubusan kami ng mga developer na mahusay magsulat sa Yii 1. Lahat ng developer ay magaling sumulat sa Symfony XNUMX. Anong gagawin? Naglaan kami ng oras, naglaan ng koponan, naglaan ng tagapamahala, muling isinulat ang proyekto at maayos na inilipat ang trapiko dito.

Pagkatapos nito, maaaring tanggalin ang lumang serbisyo. Ito ang paborito kong pamamaraan, kapag kailangan mong kunin at linisin ang ilang serbisyo mula sa sistema ng pamamahala ng pagsasaayos at pagkatapos ay dumaan at tingnan na ang lahat ng mga sasakyan sa produksyon ay hindi pinagana, upang ang mga developer ay walang anumang bakas na natitira. Ang imbakan ay nananatili sa Git.

Ito lang ang gusto kong pag-usapan, handa akong pag-usapan, holivar ang paksa, maraming naglangoy dito.

Sinabi ng mga slide na pinag-isa mo ang mga wika. Ang isang halimbawa ay ang pagbabago ng laki ng mga larawan. Kailangan ba talagang mahigpit na limitahan ito sa isang wika? Dahil ang pagbabago ng laki ng imahe sa PHP, mabuti, maaari talagang gawin sa Golang.

Sa katunayan, ito ay opsyonal, tulad ng lahat ng mga kasanayan. Marahil, sa ilang mga kaso, ito ay hindi kanais-nais. Ngunit kailangan mong maunawaan na kung mayroon kang isang teknikal na departamento sa isang kumpanya ng 50 katao, 45 sa kanila ay mga espesyalista sa PHP, ang isa pang 3 ay mga devop na nakakaalam ng Python, Ansible, Puppet at isang katulad nito, at isa lamang sa kanila ang nagsusulat sa ilang uri ng wika. ilang serbisyo sa pagbabago ng laki ng imahe ng Go, pagkatapos kapag umalis na ito, kasama nito ang kadalubhasaan. At kasabay nito, kakailanganin mong maghanap ng developer na partikular sa merkado na nakakaalam ng wikang ito, lalo na kung bihira ito. Iyon ay, mula sa isang pang-organisasyon na pananaw, ito ay may problema. Mula sa pananaw ng mga devops, hindi mo lang kakailanganing i-clone ang ilang handa na hanay ng mga playbook na ginagamit mo upang mag-deploy ng mga serbisyo, ngunit kakailanganin mong isulat muli ang mga ito.

Kasalukuyan kaming gumagawa ng isang serbisyo sa Node.js, at ito ay magiging isang platform lamang sa malapit para sa bawat developer na may hiwalay na wika. Ngunit nakaupo kami at naisip na ang laro ay nagkakahalaga ng kandila. Ibig sabihin, ito ay isang tanong na dapat mong maupo at pag-isipan.

Paano mo sinusubaybayan ang iyong mga serbisyo? Paano mo kinokolekta at sinusubaybayan ang mga log?

Kinokolekta namin ang mga log sa Elasticsearch at inilalagay ang mga ito sa Kibana, at depende sa kung ito ay produksyon o pagsubok na mga kapaligiran, iba't ibang mga kolektor ang ginagamit doon. Somewhere Lumberjack, somewhere else something else, hindi ko na maalala. At mayroon pa ring ilang mga lugar sa ilang mga serbisyo kung saan nag-i-install kami ng Telegraf at nag-shoot sa ibang lugar nang hiwalay.

Paano mamuhay kasama ang Puppet at Ansible sa parehong kapaligiran?

Sa katunayan, mayroon na tayong dalawang kapaligiran, ang isa ay Puppet, ang isa ay Ansible. Kami ay nagtatrabaho upang i-hybridize ang mga ito. Ang Ansible ay isang magandang framework para sa paunang setup, ang Puppet ay isang masamang framework para sa paunang setup dahil nangangailangan ito ng hands-on na trabaho nang direkta sa platform, at tinitiyak ng Puppet ang convergence ng configuration. Nangangahulugan ito na ang platform ay nagpapanatili ng sarili nito sa isang napapanahon na estado, at upang ang ansibilized na makina ay mapanatiling napapanahon, kailangan mong magpatakbo ng mga playbook dito sa lahat ng oras nang may ilang dalas. Iyon ang pagkakaiba.

Paano mo pinapanatili ang pagiging tugma? Mayroon ka bang mga config sa parehong Ansible at Puppet?

Ito ang aming malaking sakit, pinapanatili namin ang pagiging tugma sa aming mga kamay at iniisip kung paano magpatuloy mula sa lahat ng ito sa isang lugar ngayon. Lumalabas na ang Puppet ay naglalabas ng mga pakete at nagpapanatili ng ilang mga link doon, at ang Ansible, halimbawa, ay naglalabas ng code at inaayos ang pinakabagong mga config ng application doon.

Ang pagtatanghal ay tungkol sa iba't ibang bersyon ng Ruby. Anong solusyon?

Nakatagpo namin ito sa isang lugar, at kailangan naming panatilihin ito sa aming mga ulo sa lahat ng oras. Pinatay lang namin ang bahaging tumatakbo sa Ruby na hindi tugma sa mga application at pinananatiling hiwalay.

Kumperensya ngayong taon DevOpsDays Moscow magaganap sa Disyembre 7 sa Technopolis. Tumatanggap kami ng mga aplikasyon para sa mga ulat hanggang Nobyembre 11. Sumulat sa amin kung gusto mong magsalita.

Bukas na ang pagpaparehistro para sa mga kalahok, sumali sa amin!

Pinagmulan: www.habr.com