Buuin ang iyong unang DevOps chain sa limang hakbang para sa mga nagsisimula.
Ang DevOps ay naging isang panlunas sa lahat para sa masyadong mabagal, hindi nakakonekta at kung hindi man ay may problemang proseso ng pag-unlad. Ngunit kailangan mo ng kaunting kaalaman sa DevOps. Sasaklawin nito ang mga konsepto tulad ng DevOps chain at kung paano gumawa ng isa sa limang hakbang. Ito ay hindi isang kumpletong gabay, ngunit isang "isda" lamang na maaaring palawakin. Magsimula tayo sa kasaysayan.
Ang aking pagpapakilala sa DevOps
Dati akong nagtatrabaho sa cloud sa Citi Group at bumuo ng IaaS web application para pamahalaan ang cloud infrastructure ng Citi, ngunit palagi akong interesado sa kung paano i-optimize ang development chain at pagbutihin ang kultura sa mga developer. Inirerekomenda sa akin ni Greg Lavender, ang aming CTO para sa Cloud Architecture at Infrastructure, ang aklat na ito. . Ipinapaliwanag nito nang maganda ang mga prinsipyo ng DevOps at parang nobela.
Ipinapakita ng talahanayan sa likod kung gaano kadalas naglalabas ang mga kumpanya ng mga bagong bersyon:
Paano pinamamahalaan ng Amazon, Google at Netflix na ilunsad nang labis? At ito ay simple: naisip nila kung paano lumikha ng halos perpektong chain ng DevOps.
Ibang-iba ang mga bagay para sa amin sa Citi hanggang sa lumipat kami sa DevOps. Pagkatapos ang aking koponan ay may iba't ibang mga kapaligiran, ngunit ginawa namin ang paghahatid sa server ng pag-unlad nang manu-mano. Ang lahat ng mga developer ay nagkaroon ng access sa isang development server lamang batay sa IBM WebSphere Application Server Community Edition. Sa sabay-sabay na pagtatangkang maghatid, "bumagsak" ang server, at sa bawat oras na kailangan naming "masakit" na makipag-ayos sa aming sarili. Nagkaroon din kami ng hindi sapat na saklaw ng code na may mga pagsubok, nakakaubos ng oras na proseso ng manu-manong paghahatid, at walang paraan upang subaybayan ang paghahatid ng code sa tulong ng ilang gawain o kinakailangan ng kliyente.
Malinaw na may apurahang kailangang gawin, at nakahanap ako ng kaparehas na kasamahan. Nagpasya kaming lumikha ng unang DevOps chain nang magkasama - nag-set up siya ng isang virtual machine at isang server ng application ng Tomcat, at inalagaan ko si Jenkins, pagsasama sa Atlassian Jira at BitBucket, pati na rin ang saklaw ng code sa mga pagsubok. Naging matagumpay ang proyekto: ganap naming na-automate ang development chain, nakamit ang halos 100% uptime sa development server, nagawang subaybayan at pahusayin ang coverage ng code gamit ang mga pagsubok, at maaaring maiugnay ang isang sangay ng Git sa isang paghahatid at isyu ng Jira. At halos lahat ng mga tool na ginamit namin sa pagbuo ng DevOps chain ay open source.
Sa katunayan, pinasimple ang chain, dahil hindi man lang kami naglapat ng mga advanced na configuration gamit ang Jenkins o Ansible. Pero nagtagumpay kami. Marahil ito ay bunga ng prinsipyo (aka ang 80/20 na panuntunan).
Isang Maikling Paglalarawan ng DevOps at CI/CD Chain
Ang DevOps ay may iba't ibang kahulugan. Ang DevOps, tulad ng Agile, ay may kasamang iba't ibang disiplina. Ngunit karamihan ay sasang-ayon sa sumusunod na kahulugan: Ang DevOps ay isang paraan, o siklo ng buhay, ng software development, ang pangunahing prinsipyo nito ay ang lumikha ng kultura kung saan ang mga developer at iba pang empleyado ay "sa parehong wavelength", ang manu-manong paggawa ay awtomatiko, ginagawa ng lahat ang kanilang makakaya, tumataas ang dalas ng paghahatid, tumataas ang produktibidad ng trabaho, tumataas ang kakayahang umangkop.
Habang ang mga tool lamang ay hindi sapat upang lumikha ng isang DevOps na kapaligiran, ang mga ito ay kailangang-kailangan. Ang pinakamahalaga sa mga ito ay ang tuluy-tuloy na pagsasama at tuloy-tuloy na paghahatid (CI/CD). Mayroong iba't ibang yugto sa chain para sa bawat environment (hal. DEV (development), INT (integration), TST (testing), QA (quality assurance), UAT (user acceptance testing), STG (preparation), PROD (use)) , ang mga manu-manong gawain ay awtomatiko, ang mga developer ay maaaring gumawa ng kalidad na code, ihatid ito, at madaling muling buuin.
Inilalarawan ng talang ito kung paano gumawa ng DevOps chain sa limang hakbang, gaya ng ipinapakita sa larawan sa ibaba, gamit ang mga open source na tool.
Bumaba tayo sa negosyo.
Hakbang 1: Platform ng CI/CD
Una sa lahat, kailangan mo ng CI/CD tool. Ang Jenkins ay isang MIT-licensed, open-source CI/CD tool na nakasulat sa Java na nagpasikat sa kilusang DevOps at naging de facto na pamantayan para sa CICD.
Ano ang Jenkins? Isipin na mayroon kang mahiwagang control panel para sa iba't ibang serbisyo at tool. Sa sarili nitong, ang isang CI/CD tool tulad ng Jenkins ay walang silbi, ngunit sa iba't ibang mga tool at serbisyo, ito ay nagiging pinakamakapangyarihan.
Bilang karagdagan sa Jenkins, maraming iba pang mga open source na tool, pumili ng anuman.
Narito kung ano ang hitsura ng isang proseso ng DevOps sa isang tool na CI/CD
Mayroon kang tool sa CI / CD sa localhost, ngunit wala pang magagawa. Lumipat tayo sa susunod na hakbang.
Hakbang 2: Pag-bersyon
Ang pinakamahusay na (at arguably pinakamadaling) paraan upang subukan ang magic ng isang CI/CD tool ay upang isama ito sa isang source control management (SCM) tool. Bakit kailangan mo ng kontrol sa bersyon? Sabihin nating gumagawa ka ng aplikasyon. Isusulat mo ito sa Java, Python, C++, Go, Ruby, JavaScript, o anumang iba pang wika na isang bagon at isang maliit na cart. Ang isinulat mo ay tinatawag na source code. Sa una, lalo na kung nagtatrabaho ka nang mag-isa, maaari mong i-save ang lahat sa isang lokal na direktoryo. Ngunit habang lumalaki ang proyekto at mas maraming tao ang sumali, kailangan mo ng paraan para magbahagi ng mga pagbabago sa code ngunit maiwasan ang mga salungatan kapag pinagsasama ang mga pagbabago. At kailangan mo ring ibalik sa anumang paraan ang mga nakaraang bersyon nang hindi gumagamit ng mga backup at gumagamit ng paraan ng copy-paste para sa mga file ng code.
At dito walang SCM kahit saan. Ang SCM ay nag-iimbak ng code sa mga repositoryo, namamahala sa mga bersyon nito, at nag-coordinate nito sa mga developer.
Maraming mga tool sa SCM, ngunit ang Git ay nararapat na maging de facto na pamantayan. Ipinapayo ko sa iyo na gamitin ito, ngunit may iba pang mga pagpipilian.
Narito ang hitsura ng pipeline ng DevOps pagkatapos idagdag ang SCM.
Maaaring i-automate ng tool ng CI/CD ang pag-upload at pag-download ng source code at pakikipagtulungan ng team. Hindi masama? Ngunit ngayon kung paano gumawa ng isang gumaganang application mula dito, na minamahal ng bilyun-bilyong mga gumagamit?
Hakbang 3: Bumuo ng Automation Tool
Lahat ay nangyayari ayon sa nararapat. Maaari kang mag-upload ng code at gumawa ng mga pagbabago sa source control, at mag-imbita ng mga kaibigan na makipagtulungan sa iyo. Ngunit wala ka pang app. Upang ito ay maging isang web application, dapat itong i-compile at i-package para sa pamamahagi o patakbuhin bilang isang executable. (Ang isang interpreted programming language tulad ng JavaScript o PHP ay hindi kailangang i-compile.)
Gumamit ng tool ng build automation. Alinmang tool ang pipiliin mo, ibubuo nito ang code sa tamang format at i-o-automate nito ang paglilinis, pagsasama-sama, pagsubok, at paghahatid. Ang mga tool sa pagbuo ay nag-iiba ayon sa wika, ngunit karaniwang ginagamit ang mga sumusunod na opsyon sa open source.
Perpekto! Ngayon, ipasok natin ang mga file ng pagsasaayos ng build automation tool sa source control upang mabuo sila ng CI/CD tool.
Masarap sa pakiramdam. Ngunit saan ilalabas ang lahat ng ito ngayon?
Hakbang 4: Server ng Web Application
Kaya, mayroon kang naka-package na file na maaaring isagawa o ilunsad. Upang maging talagang kapaki-pakinabang ang isang application, dapat itong magkaroon ng ilang uri ng serbisyo o interface, ngunit kailangan mong ilagay ang lahat ng ito sa isang lugar.
Ang isang web application ay maaaring i-host sa isang web application server. Ang application server ay nagbibigay ng isang kapaligiran kung saan maaari kang magsagawa ng naka-package na lohika, mag-render ng mga interface, at maglantad ng mga serbisyo sa web sa isang socket. Kailangan mo ng HTTP server at ilang iba pang environment (isang virtual machine, halimbawa) para mai-install ang application server. Sa ngayon, magkunwaring inaasikaso mo ang lahat ng ito habang nagpapatuloy ka (bagama't magsasalita ako tungkol sa mga lalagyan sa ibaba).
Mayroong ilang mga bukas na web application server.
Mayroon na kaming halos gumaganang DevOps chain. Mahusay na trabaho!
Sa prinsipyo, maaari kang huminto dito, pagkatapos ay maaari mong hawakan ito sa iyong sarili, ngunit ito ay nagkakahalaga ng pakikipag-usap tungkol sa kalidad ng code.
Hakbang 5: Pagsakop sa pagsubok
Ang pagsubok ay nangangailangan ng maraming oras at pagsisikap, ngunit mas mahusay na makahanap kaagad ng mga bug at pagbutihin ang code upang masiyahan ang mga end user. Para sa layuning ito, maraming mga bukas na tool na hindi lamang susubukan ang code, ngunit nagpapayo din kung paano ito pagbutihin. Karamihan sa mga tool ng CI/CD ay maaaring magsaksak sa mga tool na ito at i-automate ang proseso.
Ang pagsubok ay nahahati sa dalawang bahagi: pagsubok ng mga balangkas para sa pagsulat at pagsasagawa ng mga pagsubok, at mga tool na may mga pahiwatig upang mapabuti ang kalidad ng code.
Mga Framework ng Pagsubok
Mga tool na may mga tip sa kalidad
Karamihan sa mga tool at framework na ito ay isinulat para sa Java, Python, at JavaScript dahil ang C++ at C# ay pagmamay-ari (bagaman ang GCC ay open source).
Inilapat namin ang mga tool sa saklaw ng pagsubok, at ngayon ang pipeline ng DevOps ay dapat magmukhang larawan sa simula ng tutorial.
Mga karagdagang hakbang
Mga lalagyan
Tulad ng sinabi ko dati, ang isang application server ay maaaring i-host sa isang virtual machine o isang server, ngunit ang mga lalagyan ay mas sikat.
? Sa madaling salita, sa isang virtual machine, ang operating system ay madalas na kumukuha ng mas maraming espasyo kaysa sa application, at ang isang lalagyan ay karaniwang sapat na may ilang mga aklatan at configuration. Sa ilang mga kaso, ang mga virtual machine ay kailangang-kailangan, ngunit ang lalagyan ay maaaring tumanggap ng application kasama ang server nang walang dagdag na gastos.
Para sa mga lalagyan, karaniwang kinukuha ang Docker at Kubernetes, bagama't may iba pang mga opsyon.
Magbasa ng mga artikulo tungkol sa Docker at Kubernetes sa :
Mga tool sa automation ng middleware
Ang aming DevOps chain ay nakatuon sa collaborative na pagbuo at paghahatid ng isang application, ngunit may iba pang mga kawili-wiling bagay na maaari mong gawin sa mga tool ng DevOps. Halimbawa, gumamit ng Infrastructure as Code (IaC) na mga tool, na kilala rin bilang middleware automation tools. Nakakatulong ang mga tool na ito na i-automate ang pag-install, pamamahala, at iba pang mga gawain para sa middleware. Halimbawa, ang isang automation tool ay maaaring kumuha ng mga application (web application server, database, monitoring tool) gamit ang mga tamang configuration at itulak ang mga ito sa application server.
Narito ang ilang mga opsyon para sa open middleware automation tools:
Mga detalye sa mga artikulo :
Ano ngayon?
Ito ay dulo lamang ng malaking bato ng yelo. Marami pang magagawa ang DevOps chain. Magsimula sa isang tool na CI/CD at tingnan kung ano pa ang maaari mong i-automate para mapadali ang iyong trabaho. Huwag kalimutan ang tungkol sa para sa epektibong pagtutulungan.
Narito ang ilan pang magagandang artikulo sa DevOps para sa mga nagsisimula:
Maaari mo ring isama ang DevOps sa mga open agile na tool:
Pinagmulan: www.habr.com