Automatizimi në Linux: nga cron dhe Bash te Ansible dhe systemd

Informatec Digital » Burime » Automatizimi në Linux: nga cron dhe Bash te Ansible dhe systemd

Nëse përdorni Linux çdo ditë, herët a vonë do ta kuptoni se përsëritja e vazhdueshme e të njëjtave detyra është një humbje kohe marramendëse . Kopjet rezervë manuale, pastrimi i skedarëve të përkohshëm, përditësimi i paketave, kontrollet e statusit të sistemit… të gjitha këto mund t'i delegohen sistemit, kështu që ndodhin automatikisht ndërsa bëni gjëra më interesante (ose flini rehat).

Ekosistemi Linux është projektuar për dekada të tëra për këtë qëllim: për të automatizuar detyrat në mënyrë të besueshme, fleksibile dhe të sigurt . Nga komandat klasike si cron dhe at, përmes anacron, te kohëmatësit systemd dhe Ansible më i përparuar, keni një gamë të gjerë mjetesh për të mbuluar gjithçka, nga skripti më i thjeshtë deri te orkestrimi i qindra serverave. Në këtë udhëzues, ne do t'i bashkojmë të gjitha këto pjesë dhe do t'i bëjmë ato praktike me shpjegime të hollësishme dhe shembuj të qartë.

Çfarë do të thotë automatizimi në Linux dhe pse duhet t'ju interesojë?

Kur flasim për automatizimin në Linux, i referohemi planifikimit të ekzekutimit të komandave, skripteve ose shërbimeve pa ndërhyrjen e njeriut , qoftë në mënyrë të njëhershme apo të përsëritur. Kjo vlen për gjithçka, nga laptopi juaj personal deri te një grumbull serverësh prodhimi.

Automatizimi ka disa përparësi të qarta: zvogëlon gabimet njerëzore duke eliminuar detyrat përsëritëse, kursen kohë, siguron që detyrat kritike të ekzekutohen gjithmonë me të njëjtën saktësi dhe lejon administrim të standardizuar të sistemit. Linux është veçanërisht i mirë në këtë sepse është projektuar që nga themeli për të punuar me skripte dhe mjete konsole që janë shumë të kombinueshme.

Është e vërtetë që disa kanë frikë se automatizimi i tepërt do të krijojë varësi teknologjike ose se njohuritë manuale do të humbasin, por kur përdoret mirë, liron kohë për detyra me vlerë më të lartë : projektimin e arkitekturës, analizën e sigurisë, përmirësimin e procesit ose vetë zhvillimin.

Në përdorimin e përditshëm, automatizimi në Linux zakonisht mbështetet në disa shtylla: skriptet Bash, cron/anacron, at, kohëmatësit systemd dhe mjetet e menaxhimit të konfigurimit si Ansible . Secili prej tyre adreson një nevojë të ndryshme, të cilën do ta shqyrtojmë në detaje.

Cron: klasiku thelbësor i automatizimit periodik

Nëse ka një mjet që çdo administrator Linux duhet ta dijë përmendësh, ai është cron. Cron është një daemon që funksionon në sfond dhe nis komanda ose skripte në kohë specifike : çdo minutë, çdo orë, çdo ditë, çdo javë, çdo muaj ose në kombinime më komplekse.

Emri i tij vjen nga "chronos", fjala greke për kohën , dhe ka qenë i pranishëm në Unix që nga fundi i viteve 70. Shumica e shpërndarjeve moderne (Debian, Ubuntu, Fedora, etj.) përdorin ndonjë variant të Vixie Cron, i cili është shumë mirë i testuar dhe i qëndrueshëm. Për mjediset e prodhimit, është një komponent themelor, pothuajse aq thelbësor sa vetë bërthama.

Përdorimi i cron ju lejon të automatizoni gjëra të tilla si kopjet rezervë çdo natë, rotacionin e regjistrave, detyrat e monitorimit, skriptet e mirëmbajtjes dhe gjenerimin e raporteve . Filozofia është e thjeshtë: ju përcaktoni se çfarë të ekzekutoni dhe kur, dhe cron kujdeset për pjesën tjetër, pa ndonjë ndërfaqe grafike ose procedura të ndërlikuara.

Për më tepër, cron është i disponueshëm në pothuajse çdo sistem të ngjashëm me Unix, kështu që ajo që mësoni me cron është e dobishme për shumë mjedise të ndryshme , nga një VPS i lirë te një server korporativ.

Arkitektura cron e Linux: daemon, crontabs dhe drejtori speciale

Për ta përdorur cron në mënyrë efektive, është e dobishme të kuptohet struktura e tij e brendshme. Në përgjithësi, sistemi sillet rreth demonit crond, skedarëve crontab dhe disa drejtorive të veçanta të menaxhuara nga sistemi.

Demoni cron fillon me sistemin (zakonisht nëpërmjet systemd ose init-it përkatës) dhe qëndron zgjuar, duke kontrolluar çdo minutë për detyra që do të aktivizojnë . Kur zbulon një rresht që përputhet me minutën aktuale, ai nis komandën përkatëse në një proces të ri shell.

Çdo përdorues i sistemit mund të ketë skedarin e vet të planifikimit, të njohur si crontab. Crontab-et e përdoruesit zakonisht ruhen në shtigje si /var/spool/cron/ ose /var/spool/cron/crontabs/ , varësisht nga shpërndarja. Është e rëndësishme të mos i modifikoni ato manualisht, por përmes komandës `crontab` , e cila validon sintaksën dhe njofton demonin cron për çdo ndryshim.

Përveç crontab-eve të përdoruesit, ekzistojnë mekanizma cron që mbulojnë të gjithë sistemin : skedari /etc/crontab, direktoria /etc/cron.d/ dhe direktoritë periodike /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly dhe /etc/cron.monthly. Këto direktori të fundit përmbajnë skripte që sistemi i ekzekuton periodikisht duke përdorur mjete si anacron ose shërbimet run-parts.

Ideja e përgjithshme është që demoni cron ushqehet me këto skedarë dhe drejtori , duke kontrolluar çdo minutë për të parë nëse duhet të ekzekutohet ndonjë gjë. Kjo arkitekturë modulare e bën të lehtë për paketat e sistemit të instalojnë detyrat e tyre pa ndikuar në konfigurimin global.

Sintaksa e crontab: pesë fushat dhe operatorët e tyre

Një nga gjërat që do të mbani mend më shumë kur të filloni të përdorni cron është sintaksa e rreshtave të tij. Çdo hyrje në një crontab përdoruesi përbëhet nga pesë fusha kohore plus komanda për të ekzekutuar . Edhe pse nuk do ta riprodhojmë tabelën fjalë për fjalë, fushat standarde janë minuta, ora, dita e muajit, muaji dhe dita e javës.

Çdo fushë pranon vlera numerike, diapazone, lista të ndara me presje, hapa me një vijë të pjerrët përpara dhe madje edhe yllin tipik për të treguar "të gjitha vlerat e mundshme". Falë këtyre operatorëve, ju mund të shprehni modele komplekse pa pasur nevojë të shkruani njëzet rreshta të ndryshëm.

Përveç kësaj, shumë implementime cron pranojnë shkurtesa të veçanta si @daily, @hourly, @weekly, @monthly, @reboot dhe të ngjashme. Këto pseudonime thjeshtojnë detyrat e zakonshme, kështu që nuk keni nevojë as të mbani mend rendin e fushave.

Kur punoni me skedarin /etc/crontab ose /etc/cron.d/, shtohet një fushë e gjashtë për të specifikuar përdoruesin nën të cilin do të ekzekutohet detyra . Kjo është thelbësore për detyrat e sistemit që duhet të ekzekutohen si llogari root ose llogari të tjera shërbimi.

Mësimi përmendësh i kësaj sintakse dhe praktikimi me disa shembuj nga bota reale është ajo që bën ndryshimin midis përdorimit të ngathët të cron dhe automatizimit të pastër, të lexueshëm dhe të lehtë për t’u mirëmbajtur me kalimin e kohës.

Menaxhim profesional i crontab: redaktimi, renditja dhe versionimi

Komanda crontab është ndërfaqja zyrtare për të punuar me detyrat e planifikuara të një përdoruesi. Me të, ju mund të krijoni, modifikoni, listoni dhe madje të fshini crontab-in tuaj, dhe më e rëndësishmja, ju shmangni modifikimin direkt të skedarëve të brendshëm të sistemit , gjë që zvogëlon gabimet dhe problemet me lejet.

Një praktikë shumë e rekomanduar në mjedise serioze është mbajtja e përmbajtjes së crontab në skedarë teksti të versionuar duke përdorur Git . Në këtë mënyrë, ju mund të rishikoni se kush çfarë ndryshoi dhe kur, të krahasoni versionet më të vjetra dhe të rivendosni shpejt një konfigurim të mëparshëm nëse diçka prishet pas një modifikimi.

Është gjithashtu e mundur të instaloni një crontab nga një skedar i jashtëm, gjë që funksionon shumë mirë me procedurat e automatizuara të vendosjes ose infrastrukturën si kod . Në këtë mënyrë, në vend që të modifikoni manualisht çdo server, ju dërgoni të njëjtin skedar te të gjithë ata dhe aplikoni ndryshimet në mënyrë uniforme.

Në praktikë, administratorët me përvojë zakonisht dokumentojnë çdo rresht me një koment paraprak, grupojnë detyrat përkatëse dhe mbajnë një konventë të qartë emërtimi dhe shtigje për skriptet e përdorura në cron. Kjo disiplinë e bën jetën shumë më të lehtë muaj më vonë.

Shembuj të zakonshëm të detyrave të automatizuara me cron

Për të kuptuar potencialin e cron, thjesht shqyrtoni rastet tipike të përdorimit. Një nga më të shpeshtat është mirëmbajtja rutinë e sistemit : rrotullimi dhe kompresimi i regjistrave, pastrimi i skedarëve të përkohshëm, rigjenerimi i indekseve të kërkimit ose fshirja e kopjeve rezervë të vjetra.

Një bllok tjetër shumë i zakonshëm është monitorimi i detyrave . Është relativisht e zakonshme të ekzekutohen skripte që kontrollojnë përdorimin e diskut, ngarkesën e sistemit, gjendjen e shërbimeve të caktuara ose konsumin e memories, dhe nëse zbulojnë një prag të rrezikshëm, ato gjenerojnë një regjistër, dërgojnë një email ose shkaktojnë një alarm për një sistem të jashtëm.

Në fushën e zhvillimit dhe bazave të të dhënave, cron ka gjithashtu shumë potencial. Për shembull, detyrat e planifikuara përdoren për të bërë kopje rezervë të bazave të të dhënave, për të ekzekutuar skripte që rigjenerojnë metrika ose për të eksportuar raporte në skedarë CSV , ose edhe për të orkestruar kanale të vogla të përpunimit të të dhënave.

E gjithë kjo mbështetet pothuajse gjithmonë nga skriptet Bash ose gjuhë të tjera që bëjnë punën aktuale, ndërsa cron kujdeset për "kur". Kjo ndarje përgjegjësish e mban crontab-in të pastër dhe logjikën e biznesit të kapsuluar në skedarë të veçantë.

Variablat e mjedisit në cron: burimi klasik i gabimeve

Një nga gabimet më të zakonshme që bëjnë njerëzit kur fillojnë me cron është supozimi se detyrat ekzekutohen në të njëjtin mjedis si kur punojnë në terminalin interaktiv . Asgjë nuk mund të jetë më larg së vërtetës: cron ekzekuton komandat në një kontekst shumë të kufizuar, me një PATH të kufizuar dhe pa personalizimet e shell-it tuaj.

Kjo do të thotë që shumë skripte që funksionojnë në mënyrë perfekte kur ekzekutohen manualisht dështojnë nën cron sepse nuk mund t'i gjejnë skedarët binare, nuk mund të gjejnë shtigje relative ose varen nga variablat e mjedisit që nuk ekzistojnë . Zgjidhja është e thjeshtë: përcaktoni në mënyrë të qartë PATH dhe çdo variabël tjetër të nevojshëm brenda vetë crontab-it ose në skript.

Është gjithashtu e zakonshme të kontrollohet sjellja e email-it duke përdorur variablin `MAILTO` , në mënyrë që rezultati standard i detyrave ose të dërgohet në kutinë postare të përdoruesit ose të hidhet poshtë. Në mjediset ku sistemi i email-it nuk është i konfiguruar, këshillohet që rezultati të ridrejtohet te skedarët në `/dev/null` për të parandaluar akumulimin e heshtur.

Si përmbledhje, kur hartoni punë cron, duhet të mendoni se ato funksionojnë në një lloj "mjedisi minimalist" dhe se gjithçka që i nevojitet skriptit tuaj duhet të deklarohet në mënyrë të qartë.

/etc/crontab, /etc/cron.dy janë drejtori periodike

Përveç crontab-eve individuale, Linux ofron një crontab sistemi që zakonisht ndodhet në /etc/crontab . Ky skedar ndryshon nga crontab-et e përdoruesit në atë që përfshin një fushë shtesë për të specifikuar llogarinë nën të cilën do të ekzekutohet komanda, gjë që është thelbësore për detyrat globale.

Ky skedar zakonisht përcakton, ndër të tjera, ekzekutimin e skripteve në /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly dhe /etc/cron.monthly . Në shumë sisteme, këto ekzekutime u delegohen mjeteve si anacron, të cilat sigurojnë që detyrat të ekzekutohen edhe nëse kompjuteri nuk është i ndezur në kohën e saktë.

Drejtoria /etc/cron.d/ përmban skedarë shtesë crontab, të cilët zakonisht instalohen nga paketat e sistemit ose mjetet e jashtme. Çdo skedar ndjek të njëjtin format si /etc/crontab, duke përfshirë fushën e përdoruesit. Kjo është mënyra e rekomanduar për të shtuar detyra të sistemit pa modifikuar crontab-in kryesor , duke përmirësuar mirëmbajtjen dhe duke parandaluar konfliktet gjatë përditësimeve.

Fluksi tipik i punës është që demoni cron i kontrollon periodikisht këto skedarë dhe, në kombinim me anacron ose run-parts, aktivizon skriptet e përfshira në drejtoritë përkatëse në kohën e duhur . Ju, si administrator, thjesht duhet të siguroheni që skriptet tuaja janë përgatitur siç duhet dhe vendosur në vendndodhjen e duhur.

Anacron: kur pajisjet nuk janë gjithmonë të ndezura

Një kufizim i njohur i cron është se nëse kompjuteri fiket kur një detyrë është planifikuar të ekzekutohet, ajo detyrë humbet. Anacron u krijua pikërisht për të mbushur këtë boshllëk , veçanërisht në makinat që nuk janë të ndezura 24/7, siç janë laptopët ose kompjuterët desktopë të zyrës.

Anacron nuk mbështetet aq shumë në datën dhe orën e saktë, por më tepër në numrin e ditëve që kanë kaluar që nga ekzekutimi i fundit i një detyre. Kur sistemi fillon, ai kontrollon se cilat detyra ditore, javore ose mujore janë anashkaluar dhe i riplanifikon ato që të ekzekutohen me një vonesë të vogël dhe të konfigurueshme.

Kjo fushë vonese në minuta është e rëndësishme sepse parandalon që të gjitha punët në pritje të nisen menjëherë gjatë nisjes , gjë që mund ta mbingarkojë sistemin. Në vend të kësaj, ato janë të shpërndara, duke i lejuar kompjuterit të niset më gradualisht.

Në shumë sisteme moderne, nëse anacron është i pranishëm, ai është përgjegjës për skriptet në /etc/cron.daily, /etc/cron.weekly dhe /etc/cron.monthly, ndërsa cron trajton detyra më të hollësishme dhe më të shpeshta. Ky kombinim i bën automatizimet të fuqishme edhe në makinat që fiken shpesh.

Komanda at: ekzekutim një herë në të ardhmen

Ndërsa cron dhe anacron përqendrohen në detyra të përsëritura, komanda at mbulon një rast shumë të thjeshtë dhe të dobishëm: planifikimin e një komande për t'u ekzekutuar vetëm një herë në një kohë të caktuar në të ardhmen. Është si të lësh një shënim në sistem për të bërë diçka "nesër në orën 9:30" ose "pas 2 orësh".

Sintaksa e `at` është mjaft miqësore për përdoruesit dhe lejon shprehje të kohës natyrore. Pasi të përcaktoni punën, sistemi e ruan atë në një radhë dhe e ekzekuton atë në kohën e planifikuar . Pas kësaj, puna zhduket, ndryshe nga `cron`, i cili e mban detyrën derisa ta modifikoni ose ta fshini.

Ky mjet është veçanërisht i përshtatshëm për detyra të njëhershme që nuk doni t'i harroni, por që nuk kanë kuptim si detyra të përsëritura : rinisje të planifikuara, ekzekutime mirëmbajtjeje pas një dritareje pune ose teste që duhet të nisin në një kohë të caktuar.

Në kombinim me skripte të mira, `at` bëhet një wildcard elegant që shumë përdorues e harrojnë se ekziston, por që mund t'i thjeshtojë shumë detyrat e përditshme kur krijimi i një hyrjeje të re cron nuk ia vlen.

Kohëmatësit systemd: alternativa moderne ndaj cron

Në shpërndarjet moderne që përdorin systemd (Ubuntu, Debian, Fedora, CentOS dhe shumë të tjera), ekziston një mënyrë tjetër për të planifikuar detyrat: kohëmatësit systemd . Në vend që të mbështeteni në crontab, këtu përcaktoni njësitë e shërbimit (.service) dhe njësitë e kohëmatësit (.timer) që systemd i menaxhon njësoj si shërbimet e tjera.

Kohëmatësit Systemd dallohen sepse integrohen pa probleme me pjesën tjetër të ekosistemit systemd : mund të shikoni gjendjen, regjistrat dhe varësitë duke përdorur të njëjtat mjete të njohura (journalctl, systemctl, etj.). Kjo është ideale për punë komplekse që duhet të fillojnë pas shërbimeve të tjera, të zbatojnë politika rinisjeje ose të mirëmbajnë regjistra të detajuar.

Një kohëmatës tipik përbëhet nga një skedar shërbimi që përcakton se çfarë ekzekutohet (një skript, një skedar binar, një veprim specifik) dhe një skedar kohëmatësi që specifikon se kur dhe sa shpesh ekzekutohet. Systemd ofron shprehje dhe opsione fleksibile të kalendarit, të tilla si persistenca , e cila bën që puna të ekzekutohet pas një mbylljeje nëse nuk është ekzekutuar.

Kur zgjidhni midis kohëmatësve cron dhe systemd, një rregull i mirë është të pyesni veten nëse keni nevojë për regjistrim të integruar, varësi shërbimi ose qëndrueshmëri të përparuar . Nëse përgjigjja është po, një kohëmatës është zakonisht më i mirë. Për detyra të thjeshta dhe universale, cron mbetet një opsion veteran dhe plotësisht i vlefshëm.

Në fund të fundit, nuk ka konflikt midis dy qasjeve: mund të përdorni cron për detyra të thjeshta dhe kohëmatës për detyra të sofistikuara , pa asnjë problem që të bashkëjetojnë në të njëjtin sistem.

Siguria dhe kontrolli i aksesit në cron

Meqenëse cron mund të ekzekutojë praktikisht çdo komandë me lejet e duhura të përdoruesit, siguria është një çështje thelbësore. Linux përfshin mekanizma sigurie të bazuar në skedarët /etc/cron.allow dhe /etc/cron.deny , të cilët përcaktojnë se cilët përdorues mund të përdorin cron.

Në varësi të konfigurimit, sistemi mund të lejojë punët cron vetëm për ata që janë në një listë të bardhë ose t'ua mohojë ato në mënyrë të qartë atyre që janë në një listë të zezë. Menaxhimi i duhur i këtyre skedarëve është thelbësor në mjediset me shumë përdorues ose serverat e ekspozuar , ku është e padëshirueshme që çdo llogari të jetë në gjendje të mbingarkojë burimet me detyra të projektuara keq.

Për më tepër, këshillohet të kufizoni se cilët skripte ekzekutohen si root dhe të rishikoni me kujdes kodin e çdo detyre të planifikuar me privilegje të larta. Një mbikëqyrje e thjeshtë në një skript cron me privilegje administratori mund të hapë një dobësi shumë serioze sigurie.

Në kontekste më të avancuara, mjete si SELinux ose AppArmor mund të shtojnë shtresa shtesë kontrolli mbi atë që mund të bëjnë proceset e nisura nga cron, duke forcuar më tej sigurinë e sistemit.

Debugimi i punëve cron: metodologjia dhe gabimet tipike

Kur një detyrë e planifikuar nuk po bën atë që prisni, strategjia më e mirë nuk është të eksperimentoni pa qëllim, por të ndiqni një metodologji të thjeshtë diagnostikuese . Hapi i parë është të verifikoni që demoni cron është me të vërtetë aktiv dhe i aktivizuar, duke përdorur mjetet e shërbimit të shpërndarjes.

Më pas, duhet të rishikoni regjistrat e sistemit dhe çdo regjistër specifik për cron-in. Shpesh, do të gjeni gabime sintaksore në crontab, probleme me lejet ose dështime në ekzekutimin e skriptit që nuk ishin menjëherë të dukshme.

Hapi tjetër logjik është të ekzekutoni manualisht skriptin ose komandën që cron përpiqet të nisë, por duke simuluar mjedisin cron sa më mirë të jetë e mundur : i njëjti përdorues, të njëjtat shtigje, pa u varur nga pseudonimet ose funksionet e shell-it tuaj interaktiv.

Ndër gabimet më të zakonshme janë: harresa e ridrejtimit të rezultatit standard dhe të gabimit, përdorimi i shtigjeve relative që nuk kanë kuptim kur cron ekzekuton skriptin, supozimi se PATH përfshin drejtori që nuk janë realisht aty, ose mosmarrja në konsideratë e faktit që shumë instanca të së njëjtës detyrë mund të mbivendosen në kohë.

Korrigjimi i këtyre problemeve përfshin përcaktimin e gjithçkaje në mënyrë të qartë, përdorimin e shtigjeve absolute, shtimin e regjistrave të debugimit dhe mbrojtjen e detyrave nga ekzekutimet e njëkohshme, nëse është e mundur.

Praktikat e mira profesionale me cron

Me kalimin e viteve, komuniteti i administratorëve të sistemit ka nxjerrë një sërë rekomandimesh që bëjnë diferencën midis "konfigurimit të katër punëve cron rastësisht" dhe menaxhimit profesional të automatizimit.

Një rregull i artë është që gjithmonë të ridrejtoni rezultatin e secilës detyrë në një skedar regjistri, oa /dev/null . Nëse nuk e bëni këtë, cron do të përpiqet t'ia dërgojë me email atë rezultat përdoruesit, gjë që mund të mbushë kutitë postare të root-it ose thjesht të humbasë nëse sistemi i email-it nuk është i konfiguruar, duke e bërë jashtëzakonisht të vështirë zgjidhjen e problemeve.

Një praktikë tjetër kyçe është paketimi i logjikës në skripte të veçanta në vend që të shkruhen komanda të gjata direkt në crontab . Kjo e bën më të lehtë versionimin e skriptit, testimin e tij manual, dokumentimin e tij dhe ripërdorimin e tij.

Për të shmangur problemet e mbivendosjes, mjete si flock ju lejojnë të zbatoni mekanizma të thjeshtë bllokimi: nëse një instancë e një detyre është ende duke u ekzekutuar, tjetra ose pret ose përfundon pa u ekzekutuar. Kjo është jetike për detyrat e rënda të kopjimit rezervë ose përpunimit të të dhënave.

Së fundmi, është një ide e mirë të komentoni çdo rresht të crontab me një përshkrim të qartë dhe ta mbani skedarin nën kontrollin e versionit me Git ose sisteme të ngjashme . Kur të kalojë koha (ose administratori të ndryshojë), ato komente dhe historiku i ndryshimeve do të jenë të paçmueshme.

Bash Scripting: Motori që drejton automatizimet

Të gjitha sa më sipër nuk janë të mjaftueshme nëse nuk kemi diçka të dobishme për të ekzekutuar, dhe këtu hyjnë në lojë skriptet Bash. Një skript është thjesht një skedar teksti me komanda që shell i ekzekuton njëra pas tjetrës , sikur t'i shkruani vetë, por pa u lodhur.

Historikisht, skriptet shell kanë qenë në zemër të automatizimit në Unix që nga vitet 70. Me mbërritjen e Bash si shell-i parazgjedhur në shumë shpërndarje, u konsolidua një gjuhë skriptimi e thjeshtë por e fuqishme , perfekte për lidhjen e komponentëve të sistemit, përpunimin e skedarëve dhe koordinimin e programeve të jashtme.

Në një nivel praktik, një skript tipik Bash fillon me rreshtin #!/bin/bash për të treguar shell-in që duhet ta interpretojë atë, përcakton variablat, ekzekuton komandat, përdor kushte dhe sythe, dhe shton mesazhe informuese me echo në mënyrë që të dimë se çfarë po ndodh.

Ekzistojnë skripte shumë të thjeshta që lëvizin vetëm disa skedarë dhe të tjera që janë shumë më të hollësishme, që kryejnë kopje rezervë të plotë, gjenerojnë raporte dhe kombinohen me cron ose at për t'u ekzekutuar automatikisht në intervale të rregullta.

Çelësi është se çdo detyrë që përsëritet shumë shpesh në terminal është një kandidat i përsosur për t'u bërë një skript, duke ju kursyer kohë dhe gabime të vogla në planin afatmesëm.

Shembull praktik: backup i përditshëm me Bash dhe cron

Një skenar shumë i zakonshëm është dëshira për të krijuar një kopje rezervë ditore të një dosjeje specifike të rëndësishme . Me Bash, kjo mund të arrihet vetëm me disa rreshta kodi, duke krijuar një drejtori me datën aktuale dhe duke përfshirë të dhënat përkatëse brenda saj.

Logjika e përgjithshme është zakonisht diçka e tillë: gjeneroni një varg me datën e sotme, ndërtoni një shteg destinacioni që e përfshin atë, krijoni atë drejtori nëse nuk ekziston, kopjoni në mënyrë rekursive të dhënat tuaja të rëndësishme dhe së fundmi, shfaqni një mesazh që tregon se kopja rezervë është përfunduar me sukses.

Nëse e kombinoni këtë edhe me enkriptimin e kopjeve rezervë, përdorimin e tar/gz në Linux ose transport të sigurt në një server tjetër nëpërmjet tuneleve VPN ose SSH, mund të krijoni një strategji të mirë kopjesh rezervë pa ndërlikime të mëdha , duke u mbështetur vetëm në mjetet klasike të Linux-it.

Mund ta ruani këtë skript në një drejtori si /usr/local/sbin ose në dosjen tuaj të skripteve dhe t'i jepni leje ekzekutimi. Pastaj, përdorni cron për të planifikuar ekzekutimin e tij automatik në një kohë kur serveri është nën ngarkesë të ulët , për shembull, çdo natë në mesnatë.

Nëse e kombinoni këtë edhe me enkriptimin e kopjeve rezervë ose transportin e sigurt në një server tjetër nëpërmjet tuneleve VPN ose SSH, mund të krijoni një strategji të mirë kopjesh rezervë pa ndërlikime të mëdha , duke u mbështetur vetëm në mjetet klasike të Linux-it.

Automatizimi bazë me skriptet Bash: hapat e parë

Nëse sapo keni filluar të punoni me skriptimin, qasja më e mençur është ta bëni hap pas hapi. Së pari, krijoni një skedar bosh, modifikojeni atë me redaktorin tuaj të preferuar, shtoni disa rreshta kodi , ruajeni atë, jepini leje ekzekutimi dhe testojeni.

Ushtrimet e para zakonisht përfshijnë automatizimin e detyrave të thjeshta, të tilla si renditja e skedarëve, zhvendosja e tyre në dosje specifike ose pastrimi i drejtorive të përkohshme . Kjo ju ndihmon të njiheni me sintaksën, variablat, lejet dhe mesazhet e daljes.

Më vonë, mund të merrni në konsideratë skripte që regjistrojnë datën dhe orën në një regjistër herë pas here, të krijojnë kopje të kompresuara të /etc/ natën, ose të kontrollojnë hapësirën e diskut dhe të dërgojnë një alarm kur tejkalohet një përqindje e caktuar e përdorimit.

Një praktikë shumë e mirë është të përdoret `echo` si një mjet për debugging , në mënyrë që skripti të printojë hapin që po ekzekuton, vlerat e variablave kyçe dhe nëse ka hasur ndonjë problem. Kjo e thjeshton shumë gjetjen e gabimeve logjike.

Me praktikë, do të ndërtoni një "bibliotekë" të vogël personale me skripte që bëhen asistentët tuaj të heshtur, gati për t'u ekzekutuar vetë falë kohëmatësve cron, at ose systemd.

Automatizimi dhe siguria: forcimi i serverit Linux

Pothuajse çdo herë që diskutohet automatizimi në servera seriozë, biseda në mënyrë të pashmangshme kthehet te siguria. Forcimi i një serveri Linux përfshin zvogëlimin e sipërfaqes së sulmit të tij, zbatimin e praktikave më të mira dhe automatizimin e kontrolleve të sigurisë në mënyrë që ato të mos varen nga thirrja manuale.

Një hap i parë kyç është menaxhimi i llogarisë së përdoruesit . Këshillohet të shmangni emrat e përdoruesit të përgjithshëm ose të dukshëm (si "admin" ose "oracle"), të përdorni emra më pak të parashikueshëm, të vendosni politika të forta fjalëkalimesh me skadim periodik dhe të rregulloni diapazonin UID në mënyrë që të mos jenë të lehtë për t'u hamendësuar.

Një tjetër fushë shqetësuese janë paketat e instaluara. Sa më shumë softuer të panevojshëm të keni, aq më e madhe bëhet sipërfaqja juaj e sulmit. Prandaj, është praktikë e mirë të listoni paketat e instaluara, të hiqni ato të papërdorura dhe të monitoroni varësitë për të shmangur prishjen e paqëllimshme të shërbimeve kritike.

Gjithashtu duhet të kontrolloni shërbimet që janë në ekzekutim duke përdorur mjete si systemctl, të ndaloni dhe çaktivizoni ato që nuk kontribuojnë asgjë dhe të kontrolloni portet e dëgjimit me programe si netstat ose ss për t'u siguruar që janë të hapura vetëm ato që janë absolutisht të nevojshme.

Nëse shtojmë forcim të mirë të SSH (çaktivizimin e hyrjes direkte në root, përdorimin e autentifikimit të çelësit, rregullimin e afateve kohore) dhe përdorimin e firewall-eve si firewalld ose iptables, fitojmë disa shtresa mbrojtjeje kundër sulmeve të jashtme pa shumë ndërlikime.

SELinux, firewall-e dhe optimizim me akord

Për mjediset ku siguria është përparësi, mjete si forcimi i SELinux veprojnë si një pengesë shtesë e kontrollit të detyrueshëm të aksesit, duke kufizuar se cilat procese mund të bëjnë çfarë, përtej lejeve tradicionale.

Është e rëndësishme të kontrolloni statusin e SELinux, mundësisht duke e konfiguruar atë në modalitetin e zbatimit të rreptë dhe duke rregulluar politikat sipas nevojave të sistemit duke përdorur programe specifike. Ndërsa në fillim mund të duket frikësuese, kur konfigurohet siç duhet, bllokon shumë veprime të padëshiruara.

Në mjedisin e rrjetit, firewalld ose iptables ju lejojnë të përcaktoni rregulla të detajuara për trafikun hyrës dhe dalës , duke hapur vetëm shërbime specifike si SSH, HTTP ose çfarëdo që është vërtet e nevojshme. Kjo e zvogëlon shumë numrin e vektorëve të mundshëm të sulmit.

Nga ana tjetër, ekzistojnë mjete si tuned, të dizajnuara për të optimizuar performancën e sistemit duke përdorur profile të paracaktuara bazuar në llojin e ngarkesës së punës: server, desktop, mysafirë virtualë, etj. Aktivizimi i profilit të duhur dhe lejimi i tuned të menaxhojë parametra të caktuar kursen kohë dhe përmirëson performancën e përgjithshme.

E gjithë kjo është e pakuptimtë nëse bëhet vetëm një herë dhe pastaj harrohet. Siguria dhe performanca kërkojnë rishikim të vazhdueshëm, përditësime të rregullta dhe monitorim të vazhdueshëm , dhe pikërisht këtu hyn në lojë automatizimi: shumë nga këto detyra rutinë mund të planifikohen të ekzekutohen më vete.

Ansible: automatizim në shkallë të gjerë dhe menaxhim konfigurimi

Kur shkallëzoni nga një ose dy servera në dhjetëra ose qindra, skriptet cron dhe lokale nuk arrijnë të ruajnë qëndrueshmërinë. Ansible hyn në skenë si një mjet automatizimi dhe menaxhimi konfigurimi që nuk kërkon agjentë në nyje dhe mbështetet në SSH dhe skedarë YAML të lexueshëm.

Me Ansible ju përcaktoni inventarët e hosteve, gjeneroni çifte çelësash SSH për vërtetim pa fjalëkalim dhe automatizoni administrimin e sistemit Linux duke shkruar manuale që përshkruajnë gjendjen e dëshiruar të serverave : cilat paketa duhet të instalohen, cilat shërbime janë aktive, cilët skedarë konfigurimi janë të pranishëm, etj.

Avantazhi i madh është se mund të aplikoni të njëjtin manual në shumë sisteme njëkohësisht dhe të merrni një rezultat të qëndrueshëm dhe të përsëritshëm , diçka shumë e vështirë për t'u arritur nëse çdo administrator do të aplikonte ndryshimet manualisht. Për më tepër, Ansible është idempotent: ekzekutimi i të njëjtit manual disa herë nuk prish asgjë; thjesht siguron që gjithçka të jetë ashtu siç duhet të jetë.

Për shembull, një manual i thjeshtë mund të trajtojë instalimin e tmux në të gjithë serverët në një grup "web" vetëm me disa rreshta kodi. Prej andej, mund të ndërtohen automatizime më komplekse: vendosje aplikacionesh, ndryshime në konfigurim masiv, rotacion çelësash e kështu me radhë.

Në një kontekst sigurie, Ansible është ideal për zbatimin e politikave të forcimit, konfigurimin e firewall-eve, akordimin e SSH ose vendosjen e skripteve të auditimit në të gjitha nyjet në mënyrë qendrore, duke parandaluar mbikëqyrjet dhe devijimet.

Automatizimi i përditshëm: shembuj dhe filozofia e punës

Përtej mjeteve specifike, ekziston një mentalitet që zhvillohet me kalimin e kohës: sa herë që përsërit diçka manualisht disa herë, ia vlen të pyesësh veten nëse nuk mund të automatizohet . Linux është bërë fjalë për këtë.

Disa njerëz e shohin terminalin madje si një asistent të heshtur që bën gjëra për ju në sfond: cakton njoftime për email-e, gjeneron përmbledhje javore, sinkronizon drejtoritë me servera të largët ose pastron dosjet e shkarkimeve dhe të përkohshme pa pasur nevojë të lëvizni një gisht.

Edhe mjetet shpesh të neglizhuara si `at` ju lejojnë të planifikoni një ekzekutim të vetëm nesër në një kohë të caktuar pa shqetësimin e një pune cron . Të kombinuara me skripte të strukturuara mirë, këto shërbime e shndërrojnë sistemin tuaj Linux në një lloj "lavastoviljeje" dixhitale që merret me detyra të përsëritura.

Gjëja e rëndësishme është t'i qasemi automatizimit me gjykim të shëndoshë dhe me logjikë të shëndoshë : nuk ka të bëjë me automatizimin sepse është në modë, por me vlerësimin se cilat detyra kërkojnë kohë, janë të prirura ndaj gabimeve njerëzore ose kanë ndikim nëse harrohen, dhe me prioritizimin e atyre të parave.

Me kalimin e kohës, përfundoni duke shkruar ushtrime të vogla për veten tuaj: punë cron që regjistrojnë datën dhe orën për të kontrolluar nëse e keni konfiguruar saktë sintaksën, skripte rezervë, skripte monitorimi dhe madje edhe konvertime të disa prej këtyre detyrave në kohëmatës të sistemit me vonesa të vazhdueshme dhe të rastësishme për të shpërndarë ngarkesën.

Duke i bashkuar të gjitha këto pjesë - skriptet Bash, cron, anacron, at, kohëmatësit systemd, Ansible, praktikat më të mira të sigurisë, firewall-et dhe mjetet e optimizimit - ju përfundoni duke ndërtuar një mjedis ku Linux punon për ju 24/7, duke mirëmbajtur kopje rezervë, duke forcuar sigurinë dhe duke u kujdesur për performancën , ndërsa ju përqendroheni në probleme më pak mekanike dhe më interesante.