{"id":87084,"date":"2020-07-03T13:42:34","date_gmt":"2020-07-03T11:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-ansible-bez-kotoryh-vashi-plejbuki-komok-slipshihsya-makaron"},"modified":"2020-07-03T13:42:34","modified_gmt":"2020-07-03T11:42:34","slug":"osnovy-ansible-bez-kotoryh-vashi-plejbuki-komok-slipshihsya-makaron","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/osnovy-ansible-bez-kotoryh-vashi-plejbuki-komok-slipshihsya-makaron","title":{"rendered":"Bazat e Ansible, pa t\u00eb cilat playbook-et tuaja jan\u00eb nj\u00eb grumbull makaronash t\u00eb ngjitura","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Shkruaj shum\u00eb rishikime p\u00ebr kodin e t\u00eb tjer\u00ebve n\u00eb Ansible dhe shkruaj shum\u00eb vet\u00eb. Gjat\u00eb analiz\u00ebs s\u00eb gabimeve (t\u00eb huaja dhe t\u00eb mia), si dhe disa intervistash, kuptova gabimin kryesor q\u00eb b\u00ebjn\u00eb p\u00ebrdoruesit e Ansible \u2014 ata p\u00ebrplasen n\u00eb komplikuar, pa e zot\u00ebruar thelbin.<\/p>\n

<\/p>\n

P\u00ebr t\u00eb korrigjuar k\u00ebt\u00eb padrejt\u00ebsi universale, vendosa t\u00eb shkruaj nj\u00eb hyrje n\u00eb Ansible p\u00ebr ata q\u00eb tashm\u00eb e njohin. Paralajm\u00ebroj, kjo nuk \u00ebsht\u00eb nj\u00eb p\u00ebrmbledhje e manualeve, por nj\u00eb artikull i gjat\u00eb me shum\u00eb shkronja dhe pa figura.<\/p>\n

<\/p>\n

Niveli i pritur i lexuesit \u2014 ka shkruar disa mij\u00ebra rreshta YAML, ka di\u00e7ka n\u00eb prodhim, por \"gjith\u00e7ka \u00ebsht\u00eb disi e \u00e7rregullt\".<\/p>\n

<\/a><\/noindex><\/p>\n

Emrat<\/h1>\n

<\/p>\n

Gabimi kryesor i p\u00ebrdoruesit t\u00eb Ansible \u00ebsht\u00eb se nuk di se si quhen gj\u00ebrat. Po n\u00ebse nuk e di emrat, nuk mund t\u00eb kuptosh at\u00eb q\u00eb \u00ebsht\u00eb shkruar n\u00eb dokumentacion. Nj\u00eb shembull i drejtp\u00ebrdrejt\u00eb: gjat\u00eb intervist\u00ebs, nj\u00eb person q\u00eb duket se kishte shkruar shum\u00eb n\u00eb Ansible, nuk mundi t\u00eb p\u00ebrgjigjej n\u00eb pyetjen \"cilat jan\u00eb elementet e playbook?\". Dhe kur e sugjerova q\u00eb \"pritsh\u00ebm ishte p\u00ebrgjigjja q\u00eb playbook p\u00ebrb\u00ebhet nga play\", pasoi nj\u00eb koment shkat\u00ebrrues \"ne nuk e p\u00ebrdorim k\u00ebt\u00eb\". Njer\u00ebzit shkruajn\u00eb n\u00eb Ansible p\u00ebr para dhe nuk e p\u00ebrdorin play. N\u00eb t\u00eb v\u00ebrtet\u00eb, e p\u00ebrdorin, por nuk din\u00eb se \u00e7far\u00eb \u00ebsht\u00eb.<\/em><\/p>\n

<\/p>\n

Pra, le t\u00eb fillojm\u00eb me t\u00eb thjesht\u00ebn: si quhet. Ndoshta e dini k\u00ebt\u00eb, ndoshta jo, sepse nuk keni v\u00ebn\u00eb re kur keni lexuar dokumentacionin.<\/p>\n

<\/p>\n

ansible-playbook ekzekuton playbook. Playbook \u00ebsht\u00eb nj\u00eb skedar me p\u00ebr extension yml\/yaml, brenda t\u00eb cilit di\u00e7ka e till\u00eb:<\/p>\n

<\/p>\n

---\n- hosts: group1\n  roles:\n    - role1\n\n- hosts: group2,group3\n  tasks:\n    - debug:<\/code><\/pre>\n
<\/p>\n
Kemi kuptuar tashm\u00eb q\u00eb i gjith\u00eb ky skedar \u00ebsht\u00eb nj\u00eb playbook. Mund t\u00eb tregojm\u00eb ku jan\u00eb rolet (roles), ku jan\u00eb detyrat (tasks). Por ku \u00ebsht\u00eb play? Dhe \u00e7far\u00eb e ndan play nga role ose playbook?<\/p>\n
<\/p>\n
N\u00eb dokumentacion, t\u00eb gjitha k\u00ebto ekzistojn\u00eb. Dhe ato i anashkalojn\u00eb. Fillestar\u00ebt \u2014 sepse ka shum\u00eb dhe nuk mund ta mbajn\u00eb mend menj\u00ebher\u00eb. T\u00eb kualifikuarit \u2014 sepse \"gj\u00ebrat triviale\". N\u00ebse je i kualifikuar \u2014 rip\u00ebrshkruaj k\u00ebto faqe t\u00eb pakt\u00ebn nj\u00eb her\u00eb n\u00eb gjasht\u00eb muaj, dhe kodi yt do t\u00eb b\u00ebhet shum\u00eb m\u00eb i mir\u00eb.<\/p>\n
<\/p>\n
K\u00ebshtu q\u00eb mba mend: Playbook \u00ebsht\u00eb nj\u00eb list\u00eb, e cila p\u00ebrb\u00ebhet nga play dhe import_playbook<\/code>.
\nKjo \u00ebsht\u00eb nj\u00eb play:<\/p>\n
<\/p>\n
- hosts: group1\n  roles:\n    - role1<\/code><\/pre>\n
<\/p>\n
dhe kjo \u00ebsht\u00eb gjithashtu nj\u00eb play tjet\u00ebr:<\/p>\n
<\/p>\n
- hosts: group2,group3\n  tasks:\n    - debug:<\/code><\/pre>\n
<\/p>\n
\u00c7far\u00eb \u00ebsht\u00eb play? Pse ekziston ajo?<\/p>\n
<\/p>\n
Play \u00ebsht\u00eb elementi ky\u00e7 p\u00ebr playbook, sepse play dhe vet\u00ebm play lidh list\u00ebn e roleve dhe\/ose detyrave me list\u00ebn e hosteve ku ato duhet t\u00eb kryhen. N\u00eb thell\u00ebsit\u00eb e dokumentacionit mund t\u00eb gjeni p\u00ebrmendje p\u00ebr delegate_to<\/code>, pluginet lokale t\u00eb lookup, cil\u00ebsimet specifike p\u00ebr network-cli, jump-hosts, etj. Ato lejojn\u00eb nj\u00eb ndryshim t\u00eb vog\u00ebl t\u00eb vendndodhjes s\u00eb ekzekutimit t\u00eb detyrave. Por, harrojeni k\u00ebt\u00eb. \u00c7do nga k\u00ebto mund\u00ebsi t\u00eb sofistikuara ka aplikime shum\u00eb t\u00eb ve\u00e7anta, dhe ato me siguri nuk jan\u00eb universale. Ne po flasim p\u00ebr gj\u00ebrat baz\u00eb q\u00eb duhet t\u00eb din\u00eb dhe p\u00ebrdorin t\u00eb gjith\u00eb.<\/p>\n
<\/p>\n
N\u00ebse d\u00ebshiron t\u00eb \"b\u00ebsh\" di\u00e7ka \"ndokund\" \u2014 shkruan play. Jo rol. Jo rol me module dhe delegata. Merr dhe shkruaj play. N\u00eb t\u00eb cil\u00ebn, n\u00eb fush\u00ebn hosts, enumeron se ku do t\u00eb ekzekutohet, dhe n\u00eb roles\/tasks \u2014 se \u00e7far\u00eb do t\u00eb ekzekutohet.<\/p>\n
<\/p>\n
E thjesht\u00eb, apo? Si mund t\u00eb jet\u00eb ndryshe?<\/p>\n
<\/p>\n
Nj\u00eb nga momentet karakteristike, kur njer\u00ebzit ndjejn\u00eb d\u00ebshir\u00ebn p\u00ebr ta b\u00ebr\u00eb k\u00ebt\u00eb jo p\u00ebrmes play, \u00ebsht\u00eb \"roli q\u00eb gjith\u00e7ka e konfiguron\". D\u00ebshironi t\u00eb keni nj\u00eb rol q\u00eb konfiguron dhe serverit<\/a> t\u00eb dy llojet e server\u00ebve.<\/p>\n
<\/p>\n
Nj\u00eb shembull arketipal \u00ebsht\u00eb monitorimi. Do t\u00eb ishte e d\u00ebshirueshme t\u00eb kishte nj\u00eb rol monitorimi q\u00eb do t\u00eb konfiguroj\u00eb monitorimin. Roli i monitorimit i jepet hosteve t\u00eb monitorimit (n\u00eb p\u00ebrputhje me play). Por, del se p\u00ebr monitorimin na nevojiten pakot n\u00eb hostet q\u00eb ne monitorojm\u00eb. Pse t\u00eb mos p\u00ebrdorim delegat? Dhe gjithashtu, duhet t\u00eb konfigurojm\u00eb iptables. Delegat? Dhe gjithashtu, duhet t\u00eb shkruajm\u00eb\/p\u00ebrmir\u00ebsojm\u00eb konfigurimin p\u00ebr DBMS, n\u00eb m\u00ebnyr\u00eb q\u00eb monitorimi t\u00eb lejohet. Delegat! Dhe n\u00ebse kreativiteti fillon, mund t\u00eb b\u00ebjm\u00eb delegimin. include_role<\/code> n\u00eb nj\u00eb cik\u00ebl t\u00eb brendsh\u00ebm p\u00ebrmes nj\u00eb filtri t\u00eb zgjuar p\u00ebr list\u00ebn e grupeve, dhe brenda include_role<\/code> mund t\u00eb b\u00ebjm\u00eb gjithashtu delegate_to<\/code> p\u00ebrs\u00ebri. Dhe filloi...<\/p>\n
<\/p>\n
Nj\u00eb d\u00ebshir\u00eb e mir\u00eb \u00ebsht\u00eb t\u00eb keni nj\u00eb rol t\u00eb vet\u00ebm monitoring, q\u00eb \"b\u00ebjn\u00eb gjith\u00e7ka\" \u2014 q\u00eb na \u00e7on n\u00eb nj\u00eb ferr t\u00eb err\u00ebt nga i cili shpesh ka nj\u00eb dalje: t\u00eb tudohet gjith\u00e7ka nga e para.<\/p>\n
<\/p>\n
Ku ndodhi gabimi k\u00ebtu? N\u00eb at\u00eb moment kur e kuptuat se p\u00ebr t\u00eb p\u00ebrfunduar detyr\u00ebn \"x\" n\u00eb hostin X, ju duhet t\u00eb shkoni n\u00eb hostin Y dhe t\u00eb b\u00ebni atje \"y\", ju duhet t\u00eb kishit b\u00ebr\u00eb nj\u00eb ushtrim t\u00eb thjesht\u00eb: t\u00eb shkoni dhe t\u00eb shkruani nj\u00eb play q\u00eb n\u00eb hostin Y b\u00ebn y. Mos t\u00eb shtoni di\u00e7ka n\u00eb \"x\", por t\u00eb shkruani nga fillimi. Edhe n\u00ebse p\u00ebrdorni variabla t\u00eb hardkoduar.<\/p>\n
<\/p>\n
Duket se, n\u00eb paragraf\u00ebt m\u00eb sip\u00ebr \u00ebsht\u00eb th\u00ebn\u00eb e gjitha sakt\u00eb. Por ky nuk \u00ebsht\u00eb rasti juaj! Sepse d\u00ebshironi t\u00eb shkruani kod t\u00eb rip\u00ebrdorsh\u00ebm, i cili \u00ebsht\u00eb DRY dhe ngjan si nj\u00eb bibliotek\u00eb, dhe duhet t\u00eb k\u00ebrkoni nj\u00eb metod\u00eb se si ta b\u00ebni k\u00ebt\u00eb.<\/p>\n
<\/p>\n
K\u00ebtu \u00ebsht\u00eb fshehur nj\u00eb tjet\u00ebr gabim i r\u00ebnd\u00eb. Nj\u00eb gabim, i cili ka kthyer shum\u00eb projekte nga t\u00eb shkruara p\u00ebrmbajt\u00ebse (mund t\u00eb ishte m\u00eb mir\u00eb, por gjith\u00e7ka funksionon dhe \u00ebsht\u00eb e leht\u00eb p\u00ebr t'u shkruar m\u00eb tep\u00ebr) n\u00eb nj\u00eb tmerr t\u00eb plot\u00eb, ku edhe autori nuk mund ta kuptoj\u00eb. Funksionon, por mbrapsht, ndihmoft\u00eb Zot q\u00eb di\u00e7ka t\u00eb ndryshoni.<\/p>\n
<\/p>\n
Ky gabim ting\u00ebllon k\u00ebshtu: roli \u00ebsht\u00eb nj\u00eb funksion biblioteke. Kjo analogji ka shkat\u00ebrruar aq shum\u00eb nisma t\u00eb mira, saq\u00eb \u00ebsht\u00eb thjesht e trishtueshme ta shoh\u00ebsh. Roli nuk \u00ebsht\u00eb nj\u00eb funksion biblioteke. Ai nuk mund t\u00eb b\u00ebj\u00eb llogaritje dhe nuk mund t\u00eb marr\u00eb vendime n\u00eb nivelin e play. M\u00eb kujto, \u00e7far\u00eb vendimesh merr play?<\/p>\n
<\/p>\n
Faleminderit, keni t\u00eb drejt\u00eb. Play merr nj\u00eb vendim (m\u00eb sakt\u00eb, p\u00ebrmban informacion) mbi se cilat detyra dhe role duhet t\u00eb kryhen n\u00eb cilat host-e.<\/p>\n
<\/p>\n
N\u00ebse ngarkoni k\u00ebt\u00eb zgjidhje si nj\u00eb rol, dhe madje me llogaritje, e d\u00ebnon veten tuaj (dhe ata q\u00eb do t\u00eb p\u00ebrpiqen t\u00eb kuptojn\u00eb kodin tuaj) n\u00eb nj\u00eb ekzistenc\u00eb t\u00eb mjerueshme. Roli nuk vendos se ku do t\u00eb ekzekutohet. Kjo zgjidhje vendoset nga play. Roli b\u00ebn at\u00eb q\u00eb i thoni, aty ku i thoni.<\/p>\n
<\/p>\n
Pse programimi n\u00eb Ansible \u00ebsht\u00eb i rreziksh\u00ebm dhe pse COBOL \u00ebsht\u00eb m\u00eb i mir\u00eb se Ansible do t\u00eb diskutojm\u00eb n\u00eb kapitullin p\u00ebr variablat dhe jinja. Deri at\u00ebher\u00eb, le t\u00eb themi nj\u00eb gj\u00eb \u2014 \u00e7do llogaritje q\u00eb b\u00ebni l\u00eb nj\u00eb gjurm\u00eb t\u00eb pandryshueshme nga ndryshimi i variablave global\u00eb, dhe ju nuk mund t\u00eb b\u00ebni asgj\u00eb n\u00eb lidhje me k\u00ebt\u00eb. Sa her\u00eb q\u00eb dy \"gjurm\u00eb\" p\u00ebrplasen \u2014 gjith\u00e7ka \u00ebsht\u00eb humbur.<\/p>\n
<\/p>\n
V\u00ebrejtje p\u00ebr ata q\u00eb jan\u00eb kritik\u00eb: roli, pa dyshim, mund t\u00eb ndikohet n\u00eb kontrollin e rrjedh\u00ebs. Ka delegate_to<\/code> dhe ka aplikime t\u00eb arsyeshme. Ka meta: end host\/play<\/code>. Por! Kujtoni, ne po m\u00ebsojm\u00eb bazat? E keni harruar delegate_to<\/code>. Po flasim p\u00ebr kodin m\u00eb t\u00eb thjesht\u00eb dhe m\u00eb t\u00eb bukur n\u00eb Ansible. I cili \u00ebsht\u00eb e leht\u00eb p\u00ebr t'u lexuar, leht\u00eb p\u00ebr t'u shkruar, leht\u00eb p\u00ebr t'u debuguar, leht\u00eb p\u00ebr t'u testuar dhe leht\u00eb p\u00ebr t\u00eb shtuar. Pra, edhe nj\u00eb her\u00eb:<\/p>\n
<\/p>\n
play dhe vet\u00ebm play vendos se n\u00eb cilat hosts do t\u00eb ekzekutohet \u00e7far\u00eb.<\/strong><\/p>\n
<\/p>\n
N\u00eb k\u00ebt\u00eb seksion ne kemi shqyrtuar p\u00ebrballjen midis play dhe role. Tani do t\u00eb flasim p\u00ebr marr\u00ebdh\u00ebniet midis tasks dhe role.<\/p>\n
<\/p>\n
Tasks dhe Roli<\/h1>\n
<\/p>\n
Le t\u00eb shqyrtojm\u00eb play:<\/p>\n
<\/p>\n
- hosts: somegroup\n  pre_tasks:\n    - some_tasks1:\n  roles:\n     - role1\n     - role2\n  post_tasks:\n     - some_task2:\n     - some_task3:<\/code><\/pre>\n
<\/p>\n
Supozoni se tuaj duhet t\u00eb b\u00ebni foo. Dhe duket k\u00ebshtu foo: name=foobar state=present<\/code>. Ku duhet ta shkruajm\u00eb? n\u00eb pre? post? T\u00eb krijojm\u00eb rol?<\/p>\n
<\/p>\n
\u2026 Dhe ku shkuan tasket?<\/p>\n
<\/p>\n
Ne fillojm\u00eb p\u00ebrs\u00ebri nga bazat \u2014 p\u00ebrdorimi i play. N\u00ebse jeni t\u00eb mjer\u00eb n\u00eb k\u00ebt\u00eb \u00e7\u00ebshtje, nuk mund ta p\u00ebrdorni play si baz\u00eb p\u00ebr gjith\u00e7ka tjet\u00ebr, dhe rezultati juaj b\u00ebhet \"i paq\u00ebndruesh\u00ebm\".<\/p>\n
<\/p>\n
Struktura e play: direktiva hosts, konfigurimet e vet\u00eb play dhe seksionet pre_tasks, tasks, roles, post_tasks. Parametrat e tjer\u00eb p\u00ebr play nuk jan\u00eb t\u00eb r\u00ebnd\u00ebsish\u00ebm p\u00ebr ne tani.<\/p>\n
<\/p>\n
Renditja e seksioneve t\u00eb tyre me tasket dhe rolet: pre_tasks<\/code>, roles<\/code>, detyrat<\/code>, post_tasks<\/code>. P\u00ebr sa i p\u00ebrket rendit semantik t\u00eb ekzekutimit nd\u00ebrmjet detyrat<\/code> dhe roles<\/code> nuk \u00ebsht\u00eb e qart\u00eb, praktikat m\u00eb t\u00eb mira thon\u00eb se ne shtojm\u00eb seksionin detyrat<\/code>, vet\u00ebm n\u00ebse nuk ka roles<\/code>. N\u00ebse ka roles<\/code>, at\u00ebher\u00eb t\u00eb gjitha tasket p\u00ebrkat\u00ebse vendosen n\u00eb seksionet pre_tasks<\/code>\/post_tasks<\/code>.<\/p>\n
<\/p>\n
Rrinte vet\u00ebm ajo q\u00eb \u00ebsht\u00eb semantike e qart\u00eb: s\u00eb pari pre_tasks<\/code>, pastaj roles<\/code>, pastaj post_tasks<\/code>.<\/p>\n
<\/p>\n
Por ne ende nuk kemi p\u00ebrgjigjur pyetjes: ku duhet t\u00eb shkruhet thirrja e modulit foo<\/code> ? A duhet t\u00eb shkruajm\u00eb nj\u00eb rol t\u00eb t\u00ebr\u00eb p\u00ebr \u00e7do modul? Apo \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb kemi nj\u00eb rol t\u00eb madh p\u00ebr gjith\u00e7ka? Dhe n\u00ebse jo rol, ku duhet t\u00eb shkruajm\u00eb \u2014 n\u00eb pre apo n\u00eb post?<\/p>\n
<\/p>\n
N\u00ebse nuk ka p\u00ebrgjigje t\u00eb arsyeshme p\u00ebr k\u00ebto pyetje, at\u00ebher\u00eb \u00ebsht\u00eb nj\u00eb shenj\u00eb e munges\u00ebs s\u00eb intuit\u00ebs, pra ato \"bazat e paq\u00ebndrueshme\". Le t\u00eb analizojm\u00eb. S\u00eb pari, nj\u00eb pyetje kontrolli: N\u00ebse play ka pre_tasks<\/code> dhe post_tasks<\/code> (dhe nuk ka as tasks, as roles), a mund t\u00eb prishet di\u00e7ka n\u00ebse e transferoj t\u00eb par\u00ebn task nga post_tasks<\/code> n\u00eb fund pre_tasks<\/code>?<\/p>\n
<\/p>\n
Natyrisht, formulimi i pyetjes sugjeron se do t\u00eb prishet. Por \u00e7far\u00eb sakt\u00ebsisht?<\/p>\n
<\/p>\n
\u2026 Handlera. Leximi i bazave zbulon nj\u00eb fakt t\u00eb r\u00ebnd\u00ebsish\u00ebm: t\u00eb gjith\u00eb handlerat flush'ohen automatikisht pas \u00e7do seksioni. Pra, \u00e7do detyr\u00eb nga pre_tasks<\/code>, pastaj t\u00eb gjith\u00eb handlerat q\u00eb ishin notify. M\u00eb pas p\u00ebrfundohen t\u00eb gjitha rolet dhe t\u00eb gjith\u00eb handlerat q\u00eb ishin notify n\u00eb rolet. Pastaj post_tasks<\/code> dhe handlerat e tyre.<\/p>\n
<\/p>\n
Pra, n\u00ebse e transferoni nj\u00eb task nga post_tasks<\/code> n\u00eb pre_tasks<\/code>, potencialisht, do ta kryeni at\u00eb para se t\u00eb realizoni handler'in. p\u00ebr shembull, n\u00ebse n\u00eb pre_tasks<\/code> instalohet dhe konfiguriohet server web<\/a>, nd\u00ebrsa n\u00eb post_tasks<\/code> di\u00e7ka d\u00ebrgohet n\u00eb t\u00eb, at\u00ebher\u00eb transferimi i k\u00ebsaj task n\u00eb seksionin pre_tasks<\/code> do t\u00eb \u00e7oj\u00eb n\u00eb faktin q\u00eb n\u00eb momentin e \"d\u00ebrgimit\" serveri ende nuk do t\u00eb jet\u00eb aktivizuar dhe gjith\u00e7ka do t\u00eb d\u00ebshtoj\u00eb.<\/p>\n
<\/p>\n
Tani le t\u00eb mendojm\u00eb s\u00ebrish, p\u00ebrse na duhen pre_tasks<\/code> dhe post_tasks<\/code>? \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u0432\u044b\u043f\u043e\u043b\u043d\u0438\u0442\u044c \u0432\u0441\u0451 \u043d\u0443\u0436\u043d\u043e\u0435 (\u0432\u043a\u043b\u044e\u0447\u0430\u044f \u0445\u044d\u043d\u0434\u043b\u0435\u0440\u044b) \u0434\u043e \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u0440\u043e\u043b\u0438. \u0410 post_tasks<\/code> do t\u00eb na lejoj\u00eb t\u00eb punojm\u00eb me rezultatet e ekzekutimit t\u00eb rol\u00ebve (p\u00ebrfshir\u00eb handlerat).<\/p>\n
<\/p>\n
Nj\u00eb njoh\u00ebs i ngjash\u00ebm i Ansible do t\u00eb na thot\u00eb se ka meta: flush_handlers<\/code>, por \u00e7far\u00eb na duhen flush_handlers, n\u00ebse mund t\u00eb mb\u00ebshtetemi n\u00eb rendin e ekzekutimit t\u00eb seksioneve n\u00eb play? P\u00ebr m\u00eb tep\u00ebr, p\u00ebrdorimi i meta: flush_handlers mund t\u00eb na sjell\u00eb surpriza me duplikim t\u00eb handlers, duke na shkaktuar paralajm\u00ebrime t\u00eb \u00e7uditshme n\u00eb rastin e p\u00ebrdorimit. when<\/code> u bllok<\/code> etj. Sa m\u00eb mir\u00eb ta njihni ansibilin, aq m\u00eb shum\u00eb nuanca do t\u00eb jeni n\u00eb gjendje t\u00eb em\u00ebroni p\u00ebr nj\u00eb zgjidhje \"t\u00eb zgjuar\". Nj\u00eb zgjidhje e thjesht\u00eb \u2014 p\u00ebrdorimi i ndarjes natyrale mes pre\/roles\/post \u2014 nuk sjell nuanca.<\/p>\n
<\/p>\n
Dhe, po kthehemi te 'foo' yn\u00eb. Ku ta vendosim at\u00eb? N\u00eb pre, post, apo n\u00eb roles? Sigurisht, kjo varet nga n\u00ebse na nevojiten rezultatet e pun\u00ebs s\u00eb h\u00ebndlerit p\u00ebr foo. N\u00ebse nuk ka, at\u00ebher\u00eb foo nuk ka nevoj\u00eb t\u00eb vendoset as n\u00eb pre, as n\u00eb post \u2014 k\u00ebto seksione kan\u00eb nj\u00eb kuptim t\u00eb ve\u00e7ant\u00eb \u2014 ekzekutimin e detyrave para dhe pas mas\u00ebs kryesore t\u00eb kodit.<\/p>\n
<\/p>\n
Tani p\u00ebrgjigja n\u00eb pyetjen \"rol apo detyr\u00eb\" i shkurt\u00ebzohet n\u00eb at\u00eb q\u00eb tashm\u00eb ekziston n\u00eb play \u2014 n\u00ebse ka tasks, at\u00ebher\u00eb duhet t\u00eb plot\u00ebsojm\u00eb n\u00eb tasks. N\u00ebse ka roles \u2014 duhet t\u00eb krijojm\u00eb nj\u00eb rol (edhe n\u00ebse \u00ebsht\u00eb vet\u00ebm nj\u00eb task). Po e rikujtoj, tasks dhe roles nuk p\u00ebrdoren nj\u00ebkoh\u00ebsisht.<\/p>\n
<\/p>\n
Kuptimi i t\u00eb dh\u00ebnave themelore t\u00eb Ansible-i ofron p\u00ebrgjigje t\u00eb arsyeshme p\u00ebr pyetje q\u00eb dukeshin si preferenca personale.<\/p>\n
<\/p>\n
Tasks dhe roles (pjesa e dyt\u00eb)<\/h1>\n
<\/p>\n
Tani, le t\u00eb diskutojm\u00eb situat\u00ebn kur po filloni t\u00eb shkruani nj\u00eb playbook. Ju nevojitet t\u00eb b\u00ebni foo, bar dhe baz. A jan\u00eb k\u00ebto tre detyra, nj\u00eb rol apo tre role? P\u00ebr t\u00eb p\u00ebrmbledhur pyetjen: kur duhet t\u00eb filloni t\u00eb shkruani rolet? \u00c7far\u00eb kuptimi ka t\u00eb shkruani rolet, kur mund t\u00eb shkruani detyrat?\u2026 Dhe \u00e7far\u00eb \u00ebsht\u00eb nj\u00eb rol?<\/p>\n
<\/p>\n
Nj\u00eb nga gabimet m\u00eb t\u00eb m\u00ebdha (kam folur tashm\u00eb p\u00ebr k\u00ebt\u00eb) \u00ebsht\u00eb t\u00eb mendoni se roli \u00ebsht\u00eb si nj\u00eb funksion n\u00eb nj\u00eb bibliotek\u00eb t\u00eb programit. Si duket nj\u00eb p\u00ebrshkrim i p\u00ebrgjith\u00ebsuar i funksionit? Ai merr argumente si hyrje, nd\u00ebrvepron me shkak\u00ebt an\u00ebsor\u00eb, krijon efekte an\u00ebsore dhe kthen nj\u00eb vler\u00eb.<\/p>\n
<\/p>\n
Tani, v\u00ebmendje. \u00c7far\u00eb nga kjo mund t\u00eb b\u00ebhet n\u00eb nj\u00eb rol? T\u00eb thirrni efekte an\u00ebsore \u2014 gjithmon\u00eb ju lutem, kjo \u00ebsht\u00eb thelbi i gjith\u00eb Ansible \u2014 t\u00eb b\u00ebni efekte an\u00ebsore. T\u00eb keni shkak\u00eb t\u00eb ansh\u00ebm? Elementar. Por me \"t\u00eb kaloni nj\u00eb vler\u00eb dhe ta kthejni at\u00eb\" \u2014 k\u00ebtu s'do e kemi. S\u00eb pari, nuk mund ta kaloni nj\u00eb vler\u00eb n\u00eb rol. Mund t\u00eb vendosni nj\u00eb variab\u00ebl globale me koh\u00ebzgjatje q\u00eb p\u00ebrkon me play n\u00eb seksionin vars p\u00ebr rolin. Mund t\u00eb vendosni nj\u00eb variab\u00ebl globale me koh\u00ebzgjatje n\u00eb play brenda rolit. Ose edhe me nj\u00eb koh\u00ebzgjatje t\u00eb playbooks.set_fact<\/code>\/register<\/code>). Por nuk e keni t\u00eb mundur t\u00eb keni "variab\u00ebl lokal\u00eb". Nuk mund t\u00eb "pranoni nj\u00eb vler\u00eb" dhe "ta ktheoni at\u00eb".<\/p>\n
<\/p>\n
K\u00ebshtu q\u00eb, e r\u00ebnd\u00ebsishme \u00ebsht\u00eb: nuk mund t\u00eb shkruash di\u00e7ka n\u00eb ansible pa shkaktuar efekte an\u00ebsore. Ndryshimi i variablave global \u00ebsht\u00eb gjithmon\u00eb nj\u00eb efekt an\u00ebsor p\u00ebr funksionin. N\u00eb Rust, p\u00ebr shembull, ndryshimi i nj\u00eb variabli global \u00ebsht\u00eb i pasigurt<\/code>. Por n\u00eb Ansible \u2014 \u00ebsht\u00eb vet\u00ebm nj\u00eb metod\u00eb p\u00ebr t\u00eb ndikuar n\u00eb vlerat p\u00ebr rolin. Vini re fjal\u00ebt q\u00eb p\u00ebrdoren: jo "t\u00eb kaloni vler\u00ebn n\u00eb rol", por "t\u00eb ndryshoni vlerat q\u00eb p\u00ebrdor roli". Nuk ka izolim midis roleve. Nuk ka izolim midis detyrave dhe rolit.<\/p>\n
<\/p>\n
N\u00eb p\u00ebrmbledhje: roli nuk \u00ebsht\u00eb nj\u00eb funksion<\/strong>.<\/p>\n
<\/p>\n
\u00c7far\u00eb ka t\u00eb mir\u00eb n\u00eb rol? S\u00eb pari, roli ka vlera t\u00eb paracaktuara (\/default\/main.yaml<\/code>), s\u00eb dyti roli ka katalog\u00eb shtes\u00eb p\u00ebr ruajtjen e skedareve.<\/p>\n
<\/p>\n
\u00c7far\u00eb \u00ebsht\u00eb e mir\u00eb n\u00eb vlerat e paracaktuara? Ato jan\u00eb, n\u00eb piramid\u00ebn e Maslow, nj\u00eb tabel\u00eb relativisht e \u00e7uditshme e prioriteteve t\u00eb variablave n\u00eb Ansible, vlerat e paracaktuara t\u00eb rolit jan\u00eb m\u00eb t\u00eb pakta n\u00eb prioritet (p\u00ebrve\u00e7 parametrave t\u00eb komand\u00ebs s\u00eb linj\u00ebs s\u00eb ansible). Kjo n\u00ebnkupton se n\u00ebse ju nevojitet t\u00eb ofroni vlera t\u00eb paracaktuara dhe t\u00eb mos shqet\u00ebsoheni se do t\u00eb z\u00ebvend\u00ebsojn\u00eb vlerat nga inventari ose variablat grupore, at\u00ebher\u00eb vlerat e paracaktuara t\u00eb rolit jan\u00eb vendi i vet\u00ebm i duhur p\u00ebr ju. (Po, po, po them nj\u00eb g\u00ebnjesht\u00ebr t\u00eb vog\u00ebl \u2013 ka edhe |d(your_default_here)<\/code>, por gjithsesi, n\u00ebse flasim p\u00ebr vendet stacionare \u2014 vet\u00ebm defoltet e roleve).<\/p>\n
<\/p>\n
\u00c7far\u00eb tjet\u00ebr \u00ebsht\u00eb e mir\u00eb n\u00eb role? Ato kan\u00eb kataloge t\u00eb veta. K\u00ebto jan\u00eb kataloge p\u00ebr variablat, si ata t\u00eb p\u00ebrhersh\u00ebm (dmth. t\u00eb llogaritur p\u00ebr rol), ashtu si edhe p\u00ebr ato dinamike (ka nj\u00eb model t\u00eb till\u00eb ose anti-model \u2014 include_vars<\/code> n\u00eb bashk\u00ebpunim me {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>). K\u00ebto jan\u00eb kataloge p\u00ebr files\/<\/code>, templates\/<\/code>. Po ashtu, ato lejojn\u00eb t\u00eb ken\u00eb modulet dhe plugins e veta (library\/<\/code>). Por, n\u00eb krahasim me detyrat n\u00eb playbook’un (ku gjithashtu mund t\u00eb ket\u00eb gjith\u00e7ka), p\u00ebrfitimi k\u00ebtu \u00ebsht\u00eb vet\u00ebm se skedar\u00ebt nuk jan\u00eb grumbulluar n\u00eb nj\u00eb vend, por n\u00eb disa grumbuj t\u00eb ndar\u00eb.<\/p>\n
<\/p>\n
Nj\u00eb detaj tjet\u00ebr: mund t\u00eb p\u00ebrpiqemi t\u00eb krijojm\u00eb role q\u00eb do t\u00eb jen\u00eb t\u00eb disponueshme p\u00ebr rip\u00ebrdorim (p\u00ebrmes galaxy). Pas shfaqjes s\u00eb koleksioneve, shp\u00ebrndarja e rolleve mund t\u00eb konsiderohet pothuajse e harruar.<\/p>\n
<\/p>\n
Pra, rolet kan\u00eb dy karakteristika t\u00eb r\u00ebnd\u00ebsishme: ato kan\u00eb defoltet (karakteristika unike) dhe ato lejojn\u00eb strukturimin e kodit.<\/p>\n
<\/p>\n
Duke u kthjellim pyetjes fillestare: kur t\u00eb b\u00ebsh detyrat dhe kur rolet? Detyrat n\u00eb playbook p\u00ebrdoren zakonisht ose si \"ngjit\u00ebs\" p\u00ebrpara\/pas rolit, ose si nj\u00eb element ndihm\u00ebs t\u00eb vet\u00eb. Grumbulli i detyrave normale n\u00eb kombinim me rolet \u00ebsht\u00eb nj\u00eb zhg\u00ebnjim i qart\u00eb. Duhet t\u00eb p\u00ebrmbahemi n\u00eb nj\u00eb stil t\u00eb caktuar - ose detyra, ose rolle. Rolet ofrojn\u00eb ndarjen e entiteteve dhe defaultet, detyrat lejojn\u00eb q\u00eb kodi t\u00eb lexohet m\u00eb shpejt. Zakonisht, n\u00eb rol ka kod m\u00eb \"stacionar\" (t\u00eb r\u00ebnd\u00ebsish\u00ebm dhe t\u00eb komplikuar), nd\u00ebrsa n\u00eb stilin e detyrave shkruhen skriptet ndihm\u00ebse.<\/p>\n
<\/p>\n
Ka mund\u00ebsin\u00eb t\u00eb b\u00ebni import_role si detyr\u00eb, por n\u00ebse e shkruani k\u00ebt\u00eb, jini t\u00eb gatsh\u00ebm p\u00ebr nj\u00eb shpjegim p\u00ebr ndjesin\u00eb tuaj estetike, pse d\u00ebshironi ta b\u00ebni k\u00ebt\u00eb.<\/p>\n
<\/p>\n
Nj\u00eb lexues i ngul\u00ebt mund t\u00eb thot\u00eb se rolet mund t\u00eb importojn\u00eb role, rolet mund t\u00eb ken\u00eb var\u00ebsi p\u00ebrmes galaxy.yml, dhe ka gjithashtu nj\u00eb t\u00eb frikshme dhe t\u00eb tmerrshme include_role<\/code> \u2014 kujtoj, ne po rrisim aft\u00ebsi n\u00eb Ansible bazik, dhe jo n\u00eb gimnasitik\u00ebn rrethore.<\/p>\n
<\/p>\n
Handler\u00ebt dhe detyrat<\/h1>\n
<\/p>\n
Le t\u00eb diskutojm\u00eb p\u00ebr nj\u00eb tjet\u00ebr gj\u00eb t\u00eb dukshme: handler-at. P\u00ebrdorimi i duhur i tyre \u00ebsht\u00eb nj\u00eb art i v\u00ebrtet\u00eb. \u00c7far\u00eb e ndan nj\u00eb handler nga nj\u00eb task?<\/p>\n
<\/p>\n
Nd\u00ebrsa po i kujtojm\u00eb bazat, ja nj\u00eb shembull:<\/p>\n
<\/p>\n
- hosts: group1\n  tasks:\n    - foo:\n      notify: handler1\n  handlers:\n     - name: handler1\n       bar:<\/code><\/pre>\n
<\/p>\n
N\u00eb rolet handler\u2019\u00ebt ndodhen n\u00eb rolename\/handlers\/main.yaml. Handler\u2019\u00ebt ndahen nd\u00ebrmjet t\u00eb gjith\u00eb pjes\u00ebmarr\u00ebsve t\u00eb play-it: pre\/post_tasks mund t\u00eb th\u00ebrrasin handler\u2019\u00ebt e rolit, dhe roli mund t\u00eb th\u00ebrras\u00eb handler\u2019\u00ebt nga play-i. Megjithat\u00eb, thirrjet e handler\u2019\u00ebve \"cross-role\" shkaktojn\u00eb shum\u00eb m\u00eb tep\u00ebr konfuzion se sa p\u00ebrs\u00ebritja e nj\u00eb handler\u2019i triviale. (Nj\u00eb element tjet\u00ebr i praktikave m\u00eb t\u00eb mira - p\u00ebrpiquni t\u00eb mos b\u00ebni p\u00ebrs\u00ebritje emrash handler\u2019\u00ebsh).<\/p>\n
<\/p>\n
Dallimi kryesor \u00ebsht\u00eb se nj\u00eb task ekzekutohet (n\u00eb m\u00ebnyr\u00eb idempotente) gjithmon\u00eb (plus\/minus etiketat dhe when<\/code>), dhe nj\u00eb handler \u2014 p\u00ebr ndryshimin e gjendjes (notify aktivizohet vet\u00ebm n\u00ebse ka pasur ndryshime). \u00c7far\u00eb do t\u00eb thot\u00eb kjo? P.sh., q\u00eb n\u00eb nj\u00eb rip\u00ebrs\u00ebritje, n\u00ebse nuk ka pasur ndryshime, nuk do t\u00eb ket\u00eb as handler. Por pse ndonj\u00ebher\u00eb mund t\u00eb nevojitet t\u00eb ekzekutohet handler-i kur nuk ka pasur ndryshime n\u00eb detyr\u00ebn q\u00eb ka krijuar? P.sh., p\u00ebr shkak se di\u00e7ka ka d\u00ebshtuar dhe ka pasur ndryshime, por ekzekutimi nuk ka arritur te handler-i. P.sh., p\u00ebr shkak se rrjeta ka qen\u00eb p\u00ebrkoh\u00ebsisht e papun\u00eb. Konfigurimi \u00ebsht\u00eb ndryshuar, sh\u00ebrbimi nuk \u00ebsht\u00eb rinisur. N\u00eb rip\u00ebrs\u00ebritjen e ardhshme konfigurimi nuk ndryshon m\u00eb, dhe sh\u00ebrbimi mbetet me versionin e vjet\u00ebr t\u00eb konfigurimit.<\/p>\n
<\/p>\n
Situata me konfigurimin nuk \u00ebsht\u00eb e zgjidhshme (n\u00eb t\u00eb v\u00ebrtet\u00eb, mund t\u00eb shpikim nj\u00eb protokoll t\u00eb ve\u00e7ant\u00eb p\u00ebr rinisje me flamuj skedar\u00ebsh dhe k\u00ebshtu me radh\u00eb, por kjo nuk \u00ebsht\u00eb m\u00eb ‘ansible baz\u00eb’ n\u00eb asnj\u00eb form\u00eb). Megjithat\u00eb, ka nj\u00eb histori tjet\u00ebr t\u00eb zakonshme: ne instalojm\u00eb aplikacionin, e regjistrojm\u00eb at\u00eb .sh\u00ebrbim<\/code>-dosja, dhe tani duam ta rifreskojm\u00eb demonin<\/code> dhe statusi=n\u00eb fillim<\/code>. Dhe vendi natyror p\u00ebr k\u00ebt\u00eb duket t\u00eb jet\u00eb handler. Por n\u00ebse e b\u00ebjm\u00eb at\u00eb jo nj\u00eb handler, por nj\u00eb detyr\u00eb n\u00eb fund t\u00eb list\u00ebs s\u00eb detyrave ose nj\u00eb rol, ai do t\u00eb ekzekutohet idempotent \u00e7do her\u00eb. Edhe n\u00ebse playbook-u ka d\u00ebshtuar n\u00eb mes. Kjo nuk zgjidh problemin e restarted (nuk mund t\u00eb b\u00ebni nj\u00eb detyr\u00eb me atributin restarted, sepse humbet idempotenc\u00ebn), por padyshim ka vler\u00eb t\u00eb b\u00ebhet state=started, q\u00eb rrit stabilitetin e p\u00ebrgjithsh\u00ebm t\u00eb playbook-eve, pasi zvog\u00eblon numrin e lidhjeve dhe t\u00eb gjendjeve dinamike.<\/p>\n
<\/p>\n
Nj\u00eb tjet\u00ebr pron\u00eb pozitive e handler\u2019it \u00ebsht\u00eb se ai nuk e mbush daljen me informacion t\u00eb panevojsh\u00ebm. Nuk kishte ndryshime \u2014 nuk ka skipped ose ok t\u00eb panevojshme n\u00eb dalje \u2014 \u00ebsht\u00eb m\u00eb e leht\u00eb p\u00ebr t'u lexuar. Kjo gjithashtu \u00ebsht\u00eb nj\u00eb pron\u00eb negative \u2014 n\u00ebse gjeni nj\u00eb gabim n\u00eb nj\u00eb task q\u00eb ekzekutohet linear q\u00eb n\u00eb provimin e par\u00eb, handler\u2019\u00ebt do t\u00eb ekzekutohen vet\u00ebm kur t\u00eb ket\u00eb ndryshime, dmth. n\u00ebn disa kushte \u2014 shum\u00eb rrall\u00eb. P\u00ebr shembull, hera e par\u00eb n\u00eb jet\u00eb pas pes\u00eb vjet\u00ebsh. Dhe, sigurisht, do t\u00eb ket\u00eb nj\u00eb gabim n\u00eb em\u00ebr dhe gjith\u00e7ka do t\u00eb prish\u00eb. Nj\u00eb her\u00eb tjet\u00ebr nuk do t\u00eb mund t\u2019i ekzekutoni \u2014 nuk ka nd\u00ebrrime.<\/p>\n
<\/p>\n
Nj\u00eb tem\u00eb e ve\u00e7ant\u00eb \u00ebsht\u00eb disponueshm\u00ebria e variablave. P\u00ebr shembull, n\u00ebse keni nj\u00eb notify p\u00ebr nj\u00eb detyr\u00eb me cik\u00ebl, \u00e7far\u00eb do t\u00eb ndodhte me variablat? Mund t\u00eb arrini nj\u00eb p\u00ebrfundim analitik, por nuk \u00ebsht\u00eb gjithmon\u00eb e thjesht\u00eb, sidomos kur variablat vijn\u00eb nga vende t\u00eb ndryshme.<\/p>\n
<\/p>\n
\u2026 Pra, handler\u2019\u00ebt jan\u00eb shum\u00eb m\u00eb pak t\u00eb dobish\u00ebm dhe shum\u00eb m\u00eb problematik\u00eb, sesa duket. N\u00ebse mund t\u00eb shkruani di\u00e7ka bukur (pa komplike) pa handlers, \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb b\u00ebni pa ta. N\u00ebse nuk arrini t\u00eb b\u00ebni bukur \u2014 \u00ebsht\u00eb m\u00eb mir\u00eb me ata.<\/p>\n
<\/p>\n
Nj\u00eb lexues i r\u00ebnd\u00ebsish\u00ebm v\u00eb re drejt q\u00eb ne nuk e kemi diskutuar listen<\/code>, q\u00eb handler-i mund t\u00eb th\u00ebrras\u00eb notify p\u00ebr nj\u00eb handler tjet\u00ebr, q\u00eb handler-i mund t\u00eb p\u00ebrmbaj\u00eb import_tasks (i cili mund t\u00eb b\u00ebj\u00eb include_role me with_items), q\u00eb sistemi i handler\u00ebve n\u00eb Ansible \u00ebsht\u00eb Turing-i plot\u00eb, q\u00eb handler\u00ebt nga include_role kan\u00eb nj\u00eb nd\u00ebrthurje intriguese me handler\u00ebt nga play, etj. \u2014 t\u00eb gjitha k\u00ebto sqarojn\u00eb se nuk jan\u00eb "bazat").<\/p>\n
<\/p>\n
Megjith\u00ebse \u00ebsht\u00eb nj\u00eb WTF i caktuar q\u00eb n\u00eb t\u00eb v\u00ebrtet\u00eb \u00ebsht\u00eb nj\u00eb ve\u00e7ori, dhe p\u00ebr t\u00eb cilin duhet t\u00eb kujtojm\u00eb. N\u00ebse keni nj\u00eb detyr\u00eb q\u00eb ekzekutohet me delegate_to<\/code> dhe ajo ka notify, at\u00ebher\u00eb handler-i p\u00ebrkat\u00ebs ekzekutohet pa delegate_to<\/code>, dmth. n\u00eb hostin ku \u00ebsht\u00eb em\u00ebruar play. (Megjithat\u00eb, handler-i mund t\u00eb ket\u00eb delegate_to<\/code> edhe).<\/p>\n
<\/p>\n
S\u00eb pari, dua t\u00eb them disa fjal\u00eb mbi rolet e rip\u00ebrdorshme. Para se t\u00eb ishin koleksionet, kishte ideja q\u00eb mund t\u00eb krijoheshin role universale, q\u00eb mund ansible-galaxy install<\/code> dhe fillova. Funksionon n\u00eb t\u00eb gjitha OS-t\u00eb, n\u00eb t\u00eb gjitha variantet dhe n\u00eb t\u00eb gjitha situatat. Pra, mendimi im \u00ebsht\u00eb: kjo nuk funksionon. \u00c7do rol me mb\u00ebshtetje 100500 rastesh \u00ebsht\u00eb i destinuar t\u00eb ket\u00eb probleme t\u00eb rast\u00ebsishme. Ato mund t\u00eb zgjidhen me testim t\u00eb masiv, por si me \u00e7do testim, ose keni nj\u00eb produkt t\u00eb kartesian t\u00eb vlerave hyr\u00ebse dhe nj\u00eb funksion total, ose keni \"disa skenar\u00eb t\u00eb mbuluar\". Mendimi im \u00ebsht\u00eb \u2013 \u00ebsht\u00eb m\u00eb mir\u00eb n\u00ebse roli \u00ebsht\u00eb linear (kompleksiteti ciklomatik 1). include_vars<\/code>, mb\u00ebshtetje p\u00ebr 100500 raste \u00ebsht\u00eb e destinuar p\u00ebr abysmal corner case bugs. Ato mund t\u00eb mbyllen me testim masiv, por si me \u00e7do testim, ose keni nj\u00eb produkt t\u00eb kartesian t\u00eb hyrjeve dhe nj\u00eb funksion t\u00eb plot\u00eb, ose keni "scenare t\u00eb ve\u00e7anta t\u00eb mbuluara". Mendimi im \u00ebsht\u00eb \u2014 \u00ebsht\u00eb shum\u00eb m\u00eb mir\u00eb n\u00ebse rola \u00ebsht\u00eb lineare (kompleksiteti ciklomatik 1).<\/p>\n
<\/p>\n
Sa m\u00eb pak if’esh (eksplicit ose deklarativ \u2014 n\u00eb form\u00eb when<\/code> ose form\u00ebn include_vars<\/code> n\u00eb p\u00ebrputhje me grupin e ndryshoreve), aq m\u00eb mir\u00eb \u00ebsht\u00eb roli. Ndonj\u00ebher\u00eb duhet t\u00eb b\u00ebhen ndarje, por, e p\u00ebrs\u00ebris, sa m\u00eb pak t\u00eb jen\u00eb ato, aq m\u00eb mir\u00eb. Pra, duket si nj\u00eb rol i mir\u00eb me galaxy (nuk funksionon!) me nj\u00eb sasi t\u00eb madhe when<\/code> mund t\u00eb jet\u00eb m\u00eb pak e preferueshme se "rola" e saj nga pes\u00eb detyra. Momentin kur nj\u00eb rol me galaxy \u00ebsht\u00eb m\u00eb i mir\u00eb \u2014 kur filloni t\u00eb shkruani di\u00e7ka. Momentin kur b\u00ebhet m\u00eb keq \u2014 kur di\u00e7ka thyhet, dhe keni dyshime se \u00ebsht\u00eb p\u00ebr shkak t\u00eb "rolit me galaxy". E hapni at\u00eb, dhe ka pes\u00eb inkludime, tet\u00eb lista detyrash dhe nj\u00eb grumbull when<\/code>‘ash\u2026 Dhe n\u00eb k\u00ebt\u00eb duhet t\u00eb kuptohet. N\u00eb vend t\u00eb 5 detyrave n\u00eb nj\u00eb list\u00eb lineare, n\u00eb t\u00eb cil\u00ebn as edhe nuk ka \u00e7far\u00eb t\u00eb thyhet.<\/p>\n
<\/p>\n
N\u00eb pjes\u00ebt vijuese<\/h1>\n
<\/p>\n