Automatizavimas „Linux“ sistemoje: nuo „cron“ ir „Bash“ iki „Ansible“ ir „systemd“

„Informatec Digital“ » Ištekliai » Automatizavimas „Linux“ sistemoje: nuo „cron“ ir „Bash“ iki „Ansible“ ir „systemd“

Jei kasdien naudojate „Linux“, anksčiau ar vėliau suprasite, kad nuolatinis tų pačių užduočių kartojimas yra didžiulis laiko švaistymas . Rankinis atsarginių kopijų kūrimas, laikinų failų valymas, paketų atnaujinimas, sistemos būsenos tikrinimas... visa tai galima deleguoti sistemai, kad tai vyktų automatiškai, kol jūs užsiimate įdomesniais dalykais (arba ramiai miegate).

„Linux“ ekosistema dešimtmečius buvo kuriama būtent šiam tikslui: patikimai, lanksčiai ir saugiai automatizuoti užduotis . Nuo klasikinių komandų, tokių kaip „cron“ ir „at“, per „anacron“ iki „systemd“ laikmačių ir pažangesnės „Ansible“ – turite platų įrankių spektrą, apimantį viską – nuo ​​paprasčiausio scenarijaus iki šimtų serverių orkestravimo. Šiame vadove mes sujungsime visus šiuos elementus ir padarysime juos praktiškus, pateikdami išsamius paaiškinimus ir aiškius pavyzdžius.

Ką reiškia automatizavimas „Linux“ sistemoje ir kodėl tai turėtų rūpėti?

Kalbėdami apie automatizavimą „Linux“ sistemoje, turime omenyje komandų, scenarijų ar paslaugų vykdymo planavimą be žmogaus įsikišimo , nesvarbu, ar tai būtų vienkartinis, ar pasikartojantis procesas. Tai taikoma viskam – nuo ​​asmeninio nešiojamojo kompiuterio iki gamybinių serverių klasterio.

Automatizavimas turi keletą aiškių privalumų: jis sumažina žmogiškųjų klaidų skaičių, pašalindamas pasikartojančias užduotis, taupo laiką, užtikrina, kad svarbiausios užduotys visada būtų atliekamos tokiu pačiu tikslumu , ir leidžia standartizuoti sistemos administravimą. „Linux“ ypač gerai tai daro, nes ji buvo sukurta nuo nulio taip, kad veiktų su lengvai derinamais scenarijais ir konsolės įrankiais.

Tiesa, kai kurie baiminasi, kad per didelis automatizavimas sukurs technologinę priklausomybę arba kad bus prarastos rankinio darbo žinios, tačiau tinkamai panaudotas jis atlaisvina laiko didesnės vertės užduotims : architektūros projektavimui, saugumo analizei, procesų tobulinimui ar pačiam kūrimui.

Kasdieniniame naudojime automatizavimas „Linux“ sistemoje paprastai remiasi keliais ramsčiais: „Bash“ scenarijais, „cron“ / „Anacron“, „at“, „systemd“ laikmačiais ir konfigūracijos valdymo įrankiais, tokiais kaip „Ansible“ . Kiekvienas iš jų skirtas skirtingam poreikiui, kurį mes išsamiau išnagrinėsime.

Cron: esminė periodinės automatizacijos klasika

Jei yra vienas įrankis, kurį kiekvienas „Linux“ administratorius turėtų žinoti mintinai, tai yra „cron“. „Cron“ yra demonas, veikiantis fone ir paleidžiantis komandas arba scenarijus tam tikru laiku : kas minutę, kas valandą, kasdien, kas savaitę, kas mėnesį arba sudėtingesniais deriniais.

Jo pavadinimas kilęs iš graikiško žodžio „chronos“, reiškiančio laiką , ir jis Unix sistemoje naudojamas nuo XX a. 70-ojo dešimtmečio pabaigos. Dauguma šiuolaikinių distribucijų („Debian“, „Ubuntu“, „Fedora“ ir kt.) naudoja kokią nors „Vixie Cron“ variantą, kuris yra labai gerai išbandytas ir stabilus. Gamybos aplinkoje tai yra esminis komponentas, beveik toks pat būtinas kaip ir pats branduolys.

Naudodami „cron“ galite automatizuoti tokius dalykus kaip naktinis atsarginių kopijų kūrimas, žurnalų rotavimas, stebėjimo užduotys, priežiūros scenarijai ir ataskaitų generavimas . Filosofija paprasta: jūs apibrėžiate, ką ir kada paleisti, o „cron“ pasirūpina visa kita be jokios grafinės sąsajos ar sudėtingų procedūrų.

Be to, „cron“ galima naudoti praktiškai bet kurioje „Unix“ tipo sistemoje, todėl tai, ko išmokstama naudojant „cron“, pravers daugelyje skirtingų aplinkų – nuo ​​pigių VPS iki įmonės serverių.

„Linux cron“ architektūra: demonas, crontabai ir specialūs katalogai

Norint efektyviai naudoti „cron“, naudinga suprasti jo vidinę struktūrą. Apskritai sistema sukasi apie „crond“ demoną, „crontab“ failus ir kelis specialius sistemos valdomus katalogus.

„Cron“ demonas paleidžiamas nuo sistemos (paprastai per „systemd“ arba atitinkamą init) ir išlieka budrus, kas minutę tikrindamas, ar nėra užduočių, kurias reikia suaktyvinti . Kai aptinka eilutę, atitinkančią dabartinę minutę, paleidžiama susijusi komanda naujame apvalkalo procese.

Kiekvienas sistemos vartotojas gali turėti savo planavimo failą, vadinamą „crontab“. Vartotojo „crontab“ failai paprastai saugomi tokiuose keliuose kaip /var/spool/cron/ arba /var/spool/cron/crontabs/ , priklausomai nuo distribucijos. Svarbu jų neredaguoti rankiniu būdu, o naudojant komandą „crontab“ , kuri patikrina sintaksę ir praneša „cron“ demonui apie bet kokius pakeitimus.

Be naudotojų „crontab“ failų, yra ir visai sistemai skirti „cron“ mechanizmai : failas /etc/crontab, katalogas /etc/cron.d/ ir periodiniai katalogai /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly ir /etc/cron.monthly. Pastaruosiuose kataloguose yra scenarijai, kuriuos sistema periodiškai paleidžia naudodama tokius įrankius kaip „anacron“ arba „run-parts“.

Bendra idėja yra ta, kad „cron“ demonas naudoja šiuos failus ir katalogus , kas minutę tikrindamas, ar reikia ką nors vykdyti. Ši modulinė architektūra leidžia sistemos paketams lengvai įdiegti savo užduotis nepaveikiant globalios konfigūracijos.

„crontab“ sintaksė: penki laukai ir jų operatoriai

Vienas iš dalykų, kuriuos labiausiai prisiminsite pradėdami naudoti „cron“, yra jo eilučių sintaksė. Kiekvieną įrašą vartotojo „crontab“ faile sudaro penki laiko laukai ir vykdoma komanda . Nors lentelės neatkartosime pažodžiui, standartiniai laukai yra minutė, valanda, mėnesio diena, mėnuo ir savaitės diena.

Kiekviename lauke galima įvesti skaitines reikšmes, diapazonus, kableliais atskirtus sąrašus, veiksmus su pasviruoju brūkšniu ir netgi įprastą žvaigždutę, žyminčią „visas galimas reikšmes“. Šių operatorių dėka galite išreikšti sudėtingus modelius nerašydami dvidešimties skirtingų eilučių.

Be to, daugelis „cron“ diegimų priima specialius sparčiuosius klavišus, tokius kaip „@daily“, „@hourly“, „@weekly“, „@monthly“, „@reboot“ ir panašius. Šie slapyvardžiai supaprastina įprastas užduotis, todėl jums net nereikia atsiminti laukų tvarkos.

Dirbant su failu /etc/crontab arba /etc/cron.d/, pridedamas šeštas laukas, skirtas nurodyti vartotoją, kurio vardu bus vykdoma užduotis . Tai labai svarbu sistemos užduotims, kurios turi būti vykdomos kaip root arba kitos paslaugos paskyros.

Šios sintaksės įsiminimas ir praktikavimasis su keliais realaus pasaulio pavyzdžiais yra tai, kas lemia skirtumą tarp gremėzdiško „cron“ naudojimo ir aiškios, skaitomos ir lengvai prižiūrimos automatizacijos laikui bėgant.

Profesionalus „crontab“ valdymas: redagavimas, sąrašų sudarymas ir versijų kūrimas

„crontab“ komanda yra oficiali sąsaja, skirta dirbti su vartotojo suplanuotomis užduotimis. Su ja galite kurti, redaguoti, pateikti sąrašą ir net ištrinti savo „crontab“ failą, o svarbiausia – išvengti tiesioginio vidinių sistemos failų modifikavimo , o tai sumažina klaidų ir leidimų problemų skaičių.

Rimtose aplinkose labai rekomenduojama „crontab“ turinį laikyti versuotuose tekstiniuose failuose naudojant „Git“ . Tokiu būdu galite peržiūrėti, kas ką ir kada pakeitė, palyginti senesnes versijas ir greitai atkurti ankstesnę konfigūraciją, jei po pakeitimo kas nors sugenda.

Taip pat galima įdiegti „crontab“ iš išorinio failo, kuris labai gerai veikia su automatizuoto diegimo procedūromis arba infrastruktūra kaip kodu . Tokiu būdu, užuot rankiniu būdu redagavus kiekvieną serverį, siunčiate tą patį failą visiems jiems ir vienodai pritaikote pakeitimus.

Praktiškai patyrę administratoriai paprastai dokumentuoja kiekvieną eilutę su prieš tai esančiu komentaru, grupuoja susijusias užduotis ir palaiko aiškią „cron“ naudojamų scenarijų pavadinimų tvarką bei kelius . Ši disciplina po kelių mėnesių labai palengvina gyvenimą.

Įprasti automatizuotų užduočių su cron pavyzdžiai

Norėdami suprasti „cron“ potencialą, tiesiog peržiūrėkite tipinius naudojimo atvejus. Vienas iš dažniausių yra įprastinė sistemos priežiūra : žurnalų rotavimas ir glaudinimas, laikinų failų valymas, paieškos indeksų atkūrimas arba senų atsarginių kopijų ištrynimas.

Kitas labai dažnas blokas yra užduočių stebėjimas . Gana dažnai paleidžiami scenarijai, kurie tikrina disko naudojimą, sistemos apkrovą, tam tikrų paslaugų būklę arba atminties sunaudojimą, ir jei aptinka pavojingą ribą, sukuria žurnalą, siunčia el. laišką arba suaktyvina įspėjimą išorinei sistemai.

Kalbant apie kūrimą ir duomenų bazes, „cron“ taip pat turi daug potencialo. Pavyzdžiui, suplanuotos užduotys naudojamos duomenų bazių atsarginėms kopijoms kurti, scenarijams, kurie regeneruoja metriką arba eksportuoja ataskaitas į CSV failus , vykdyti, arba net mažiems duomenų apdorojimo srautams valdyti.

Visa tai beveik visada palaiko „Bash“ scenarijai arba kitos kalbos, kurios atlieka tikrąjį darbą, o „cron“ rūpinasi „kada“. Toks atsakomybių atskyrimas užtikrina tvarkingą „crontab“ ir verslo logiką, įterptą į atskirus failus.

Aplinkos kintamieji „cron“ programoje: klasikinis klaidų šaltinis

Viena iš dažniausių klaidų, kurias žmonės daro pradėdami dirbti su „cron“, yra manyti, kad užduotys vykdomos toje pačioje aplinkoje kaip ir dirbant interaktyviame terminale . Niekas negalėtų būti toliau nuo tiesos: „cron“ vykdo komandas labai ribotame kontekste, su ribotu PATH ir be jūsų terminalo pritaikymų.

Tai reiškia, kad daugelis scenarijų, kurie puikiai veikia paleidžiami rankiniu būdu, neveikia naudojant „cron“, nes negali rasti dvejetainių failų, negali nustatyti santykinių kelių arba priklauso nuo aplinkos kintamųjų, kurių nėra . Sprendimas paprastas: aiškiai apibrėžkite PATH ir visus kitus būtinus kintamuosius pačioje „crontab“ byloje arba scenarijuje.

Taip pat įprasta el. pašto elgseną valdyti naudojant kintamąjį `MAILTO` , kad standartinė užduočių išvestis būtų siunčiama į vartotojo pašto dėžutę arba išmetama. Aplinkose, kuriose el. pašto sistema nėra sukonfigūruota, patartina nukreipti išvestį į failus, esančius `/dev/null`, kad būtų išvengta tylaus kaupimosi.

Apibendrinant, kuriant „cron“ užduotis, reikia galvoti apie tai, kad jos veiktų tam tikroje „minimalistinėje aplinkoje“ ir kad viskas, ko reikia jūsų scenarijui, turi būti aiškiai deklaruota.

/etc/crontab, /etc/cron.dy yra periodiniai katalogai

Be individualių „crontab“ failų, „Linux“ siūlo ir sisteminį „crontab“, paprastai esantį faile /etc/crontab . Šis failas skiriasi nuo vartotojo „crontab“ failų tuo, kad jame yra papildomas laukas, skirtas nurodyti paskyrą, kurioje bus vykdoma komanda, o tai būtina atliekant globalias užduotis.

Šis failas paprastai apibrėžia, be kita ko, scenarijų, esančių /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly ir /etc/cron.monthly failuose, vykdymą . Daugelyje sistemų šis vykdymas deleguojamas tokioms priemonėms kaip „anacron“, kurios užtikrina, kad užduotys būtų vykdomos net jei kompiuteris nėra įjungtas konkrečiu laiku.

Kataloge /etc/cron.d/ yra papildomų „crontab“ failų, kuriuos paprastai įdiegia sistemos paketai arba išoriniai įrankiai. Kiekvienas failas yra tokio paties formato kaip ir /etc/crontab, įskaitant vartotojo lauką. Tai rekomenduojamas būdas pridėti sistemos užduotis nekeičiant pagrindinio „crontab“ , taip pagerinant priežiūrą ir išvengiant konfliktų atnaujinimų metu.

Įprastas darbo procesas yra toks, kad „cron“ demonas periodiškai tikrina šiuos failus ir kartu su „anacron“ arba „run-parts“ tinkamu laiku paleidžia atitinkamuose kataloguose esančius scenarijus . Jums, kaip administratoriui, tereikia užtikrinti, kad jūsų scenarijai būtų tinkamai paruošti ir patalpinti tinkamoje vietoje.

„Anakron“: kai įranga ne visada įjungta

Žinomas „cron“ apribojimas yra tas, kad jei kompiuteris išjungiamas, kai suplanuota vykdyti užduotis, ta užduotis prarandama. „Anacron“ buvo sukurtas būtent tam, kad užpildytų šią spragą , ypač kompiuteriuose, kurie neveikia visą parą, pavyzdžiui, nešiojamuosiuose ar stacionariuose kompiuteriuose.

„Anacron“ ne tiek remiasi tikslia data ir laiku, kiek dienų skaičiumi, praėjusiu nuo paskutinio užduoties vykdymo. Kai sistema paleidžiama, ji patikrina, kurios dienos, savaitės ar mėnesio užduotys buvo praleistos, ir jas suplanuoja taip, kad jos būtų vykdomos su nedideliu, konfigūruojamu vėlavimu.

Šis uždelsimo laukas minutėmis yra svarbus, nes jis neleidžia visoms laukiančioms užduotims paleisti vienu metu paleidžiant kompiuterį , nes tai galėtų perkrauti sistemą. Vietoj to, jos yra išskirstytos, todėl kompiuteris gali paleistis lėčiau.

Daugelyje šiuolaikinių sistemų, jei yra „anacron“, jis yra atsakingas už scenarijus, esančius /etc/cron.daily, /etc/cron.weekly ir /etc/cron.monthly failuose, o „cron“ tvarko smulkesnes, dažnesnes užduotis. Šis derinys užtikrina automatizavimo patikimumą net ir dažnai išjungiamuose kompiuteriuose.

Komanda „at“: vienkartinis vykdymas ateityje

Nors „cron“ ir „anacron“ daugiausia dėmesio skiria pasikartojančioms užduotims, komanda „at“ apima labai paprastą ir naudingą atvejį: komandos paleidimo tik vieną kartą konkrečiu ateities laiku planavimą. Tai tarsi palikti sistemoje pastabą ką nors padaryti „rytoj 9:30“ arba „po 2 valandų“.

Funkcijos „at“ sintaksė yra gana patogi naudoti ir leidžia naudoti natūralaus laiko išraiškas. Apibrėžus užduotį, sistema ją išsaugo eilėje ir vykdo suplanuotu laiku . Po to užduotis dingsta, kitaip nei „cron“, kuris išsaugo užduotį, kol ją pakeičiate arba ištrinate.

Šis įrankis ypač patogus vienkartinėms užduotims, kurių nenorite pamiršti, bet kurios nėra prasmingos kaip pasikartojančios užduotys : suplanuotiems paleidimams iš naujo, priežiūros darbams po darbo lango arba testams, kuriuos reikia paleisti konkrečiu laiku.

Kartu su gerais scenarijais, `at` tampa elegantišku pakaitos simboliu, apie kurio egzistavimą daugelis vartotojų pamiršta, tačiau kuris gali labai supaprastinti kasdienes užduotis, kai kurti naują cron įrašą neverta.

„systemd“ laikmačiai: moderni „cron“ alternatyva

Šiuolaikiniuose distribuciniuose paketuose, kurie naudoja „systemd“ („Ubuntu“, „Debian“, „Fedora“, „CentOS“ ir daugelyje kitų), yra kitas būdas planuoti užduotis: „systemd“ laikmačiai . Užuot pasikliavę „crontab“ rinkmenomis, čia apibrėžiate paslaugų vienetus (.service) ir laikmačio vienetus (.timer), kuriuos „systemd“ valdo kaip ir kitas paslaugas.

„Systemd“ laikmačiai išsiskiria tuo, kad sklandžiai integruojasi su likusia „systemd“ ekosistema : būseną, žurnalus ir priklausomybes galite peržiūrėti naudodami tuos pačius pažįstamus įrankius („journalctl“, „systemctl“ ir kt.). Tai idealiai tinka sudėtingoms užduotims, kurios turi būti paleidžiamos po kitų paslaugų, vykdyti paleidimo iš naujo politiką arba tvarkyti išsamius žurnalus.

Įprastą laikmatį sudaro aptarnavimo failas, apibrėžiantis, kas vykdoma (scenarijus, dvejetainis failas, konkretus veiksmas), ir laikmačio failas, nurodantis, kada ir kaip dažnai jis paleidžiamas. „Systemd“ siūlo lanksčias kalendoriaus išraiškas ir parinktis, tokias kaip „persistent“ , kurios priverčia užduotį vykdyti ir po išjungimo, jei jis buvo praleistas.

Renkantis tarp „cron“ ir „systemd“ laikmačių, gera taisyklė yra savęs paklausti, ar jums reikia integruoto registravimo, paslaugų priklausomybių, ar išplėstinio duomenų saugojimo . Jei atsakymas yra „taip“, laikmatis paprastai yra geresnis pasirinkimas. Paprastoms, universalioms užduotims „cron“ išlieka patyrusiu ir visiškai tinkamu pasirinkimu.

Galiausiai, tarp šių dviejų metodų nėra jokio konflikto: galite naudoti „cron“ paprastoms užduotims, o laikmačius – sudėtingesnėms , be jokių problemų egzistuodami toje pačioje sistemoje.

Saugumas ir prieigos kontrolė „cron“ programoje

Kadangi „cron“ gali vykdyti praktiškai bet kokią komandą su atitinkamais vartotojo leidimais, saugumas yra labai svarbus klausimas. „Linux“ sistemoje yra saugumo mechanizmai, pagrįsti /etc/cron.allow ir /etc/cron.deny failais , kurie nustato, kurie vartotojai gali naudoti „cron“.

Priklausomai nuo konfigūracijos, sistema gali leisti „cron“ užduotis tik tiems, kurie yra baltajame sąraše, arba aiškiai jas uždrausti tiems, kurie yra juodajame sąraše. Tinkamas šių failų valdymas yra gyvybiškai svarbus daugelio vartotojų aplinkose arba pažeidžiamuose serveriuose , kur nepageidautina, kad kuri nors paskyra galėtų perkrauti išteklius prastai suplanuotomis užduotimis.

Be to, patartina apriboti, kurie scenarijai paleidžiami kaip root, ir atidžiai peržiūrėti bet kurios suplanuotos užduoties kodą su didelėmis teisėmis. Paprasta klaida „cron“ scenarijuje su administratoriaus teisėmis gali sukelti labai rimtą saugumo pažeidžiamumą.

Sudėtingesniuose kontekstuose tokios priemonės kaip „SELinux“ ar „AppArmor“ gali pridėti papildomų kontrolės lygių, susijusių su „cron“ paleistais procesais, taip dar labiau sustiprindamos sistemos saugumo poziciją.

Cron užduočių derinimas: metodologija ir tipinės klaidos

Kai suplanuota užduotis neatlieka to, ko tikėjotės, geriausia strategija yra ne be tikslo žaisti, o vadovautis paprasta diagnostikos metodika . Pirmas žingsnis – patikrinti, ar „cron“ demonas iš tiesų yra aktyvus ir įjungtas, naudojant platinamosios programos aptarnavimo įrankius.

Toliau turėtumėte peržiūrėti sistemos žurnalus ir visus su „cron“ susijusius žurnalus. Dažnai „crontab“ rasite sintaksės klaidų, leidimų problemų arba scenarijų vykdymo klaidų, kurios nebuvo iš karto pastebimos.

Kitas logiškas žingsnis – rankiniu būdu paleisti scenarijų arba komandą, kurią bando paleisti „cron“, tačiau kuo geriau imituojant „cron“ aplinką : tas pats vartotojas, tie patys keliai, nepriklauso nuo interaktyviojo apvalkalo slapyvardžių ar funkcijų.

Dažniausios klaidos yra šios: pamirštama nukreipti standartinę ir klaidų išvestį, naudojami santykiniai keliai, kurie neturi prasmės, kai „cron“ vykdo scenarijų, daroma prielaida, kad PATH apima katalogus, kurių iš tikrųjų nėra, arba neatsižvelgiama į tai, kad keli tos pačios užduoties egzemplioriai gali sutapti laike.

Šių problemų sprendimas apima aiškų visko apibrėžimą, absoliučių kelių naudojimą, derinimo žurnalų pridėjimą ir, jei įmanoma, užduočių apsaugą nuo vienu metu vykdomų užduočių.

Gera profesinė praktika su cron

Bėgant metams, sistemų administratorių bendruomenė parengė keletą rekomendacijų, kurios sprendžia, ar „atsitiktinai nustatyti keturias „cron“ užduotis“, ar profesionaliai valdyti automatizavimą.

Auksinė taisyklė – kiekvienos užduoties išvestį visada nukreipti į žurnalo failą, pvz., „/dev/null“ . Jei to nepadarysite, „cron“ bandys išsiųsti tą išvestį vartotojui el. paštu, o tai gali užpildyti root pašto dėžutes arba tiesiog pasimesti, jei el. pašto sistema nėra sukonfigūruota, todėl trikčių šalinimas gali būti labai sudėtingas.

Kita svarbi praktika – logiką supakuoti į atskirus scenarijus, o ne rašyti ilgas komandas tiesiai į „crontab“ . Tai palengvina scenarijaus versijų kūrimą, rankinį testavimą, dokumentavimą ir pakartotinį naudojimą.

Siekiant išvengti dubliavimosi problemų, tokios priemonės kaip „flock“ leidžia įdiegti paprastus blokavimo mechanizmus: jei vienas užduoties egzempliorius vis dar vykdomas, kitas arba laukia, arba nutraukia savo veiklą nevykdydamas. Tai labai svarbu atliekant sudėtingas atsarginių kopijų kūrimo ar duomenų apdorojimo užduotis.

Galiausiai, pravartu kiekvieną „crontab“ eilutę pakomentuoti aiškiu aprašymu ir valdyti failo versijas naudojant „Git“ ar panašias sistemas . Laikui bėgant (arba pasikeitus administratoriui), šie komentarai ir pakeitimų istorija bus neįkainojami.

„Bash“ scenarijai: variklis, kuris vykdo automatizavimą

Visa tai, kas išdėstyta aukščiau, neveikia, jei neturime ką nors naudingo paleisti, ir čia praverčia „Bash“ scenarijai. Scenarijus yra tiesiog tekstinis failas su komandomis, kurias apvalkalas vykdo vieną po kitos , tarsi jas rašytumėte patys, tačiau nepavargdamas.

Istoriškai apvalkalo scenarijai buvo Unix automatizavimo pagrindas nuo XX a. 70-ojo dešimtmečio. Atsiradus „Bash“ kaip numatytajam apvalkalui daugelyje distribucijų, buvo sujungta paprasta, bet galinga scenarijų kalba , puikiai tinkanti sistemos komponentams susieti, failams apdoroti ir išorinėms programoms koordinuoti.

Praktiškai tipiškas „Bash“ scenarijus prasideda eilute #!/bin/bash , nurodančia apvalkalą, kuris turėtų jį interpretuoti, apibrėžia kintamuosius, vykdo komandas, naudoja sąlygines sąlygas ir ciklus bei prideda informacinius pranešimus su „echo“, kad žinotume, kas vyksta.

Yra labai paprastų scenarijų, kurie perkelia tik kelis failus, ir daug sudėtingesnių, kurie atlieka visas atsargines kopijas, generuoja ataskaitas ir derinami su „cron“ arba „at“, kad būtų automatiškai vykdomi reguliariais intervalais.

Svarbiausia, kad bet kokia užduotis, kuri terminale per dažnai kartojama, puikiai tinka tapti scenarijumi, taip vidutinės trukmės laikotarpiu sutaupydami laiko ir išvengdami kvailų klaidų.

Praktinis pavyzdys: kasdienis atsarginių kopijų kūrimas naudojant „Bash“ ir „cron“

Labai dažnas scenarijus – norint sukurti kasdienę konkretaus svarbaus aplanko atsarginę kopiją . Naudojant „Bash“, tai galima padaryti vos keliomis kodo eilutėmis, sukuriant katalogą su dabartine data ir įtraukiant į jį atitinkamus duomenis.

Bendroji logika paprastai yra maždaug tokia: sugeneruokite eilutę su šiandienos data, sukurkite paskirties kelią, kuriame ji būtų, sukurkite tą katalogą, jei jo nėra, rekursyviai nukopijuokite svarbius duomenis ir galiausiai parodykite pranešimą, rodantį, kad atsarginė kopija sėkmingai sukurta.

Jei tai derinsite su atsarginių kopijų šifravimu, „tar/gz“ naudojimu „Linux“ sistemoje arba saugiu perdavimu į kitą serverį per VPN arba SSH tunelius, galėsite be didelių komplikacijų sukurti tinkamą atsarginių kopijų kūrimo strategiją , pasikliaudami vien klasikiniais „Linux“ įrankiais.

Šį scenarijų galite išsaugoti tokiame kataloge kaip /usr/local/sbin arba savo scenarijų aplanke ir suteikti jam vykdymo teises. Tada naudokite „cron“, kad suplanuotumėte automatinį vykdymą tuo metu, kai serveris yra mažai apkrautas , pavyzdžiui, kiekvieną naktį vidurnaktį.

Jei tai derinsite su atsarginių kopijų šifravimu arba saugiu perdavimu į kitą serverį per VPN arba SSH tunelius, galėsite be didelių komplikacijų sukurti tinkamą atsarginių kopijų kūrimo strategiją , pasikliaudami vien klasikiniais „Linux“ įrankiais.

Pagrindinis automatizavimas naudojant „Bash“ scenarijus: pirmieji žingsniai

Jei tik pradedate kurti scenarijus, išmintingiausia būtų viską daryti po vieną žingsnį. Pirmiausia sukurkite tuščią failą, redaguokite jį mėgstamu redaktoriumi, pridėkite kelias kodo eilutes , išsaugokite, suteikite vykdymo teises ir išbandykite.

Pirmieji pratimai paprastai apima paprastų užduočių, tokių kaip failų sąrašo sudarymas, perkėlimas į konkrečius aplankus arba laikinų katalogų valymas, automatizavimą . Tai padeda susipažinti su sintaksė, kintamaisiais, leidimais ir išvesties pranešimais.

Vėliau galite apsvarstyti scenarijus, kurie retkarčiais įrašo datą ir laiką žurnale, naktį kuria suspaustas /etc/ kopijas arba tikrina disko vietą ir siunčia įspėjimą, kai viršijamas tam tikras naudojimo procentas.

Labai gera praktika yra naudoti „echo“ kaip derinimo įrankį , kad scenarijus atspausdintų, kurį žingsnį vykdo, pagrindinių kintamųjų reikšmes ir ar kilo kokių nors problemų. Tai labai supaprastina loginių klaidų paiešką.

Pasipraktikuodami sukursite nedidelę „asmeninę biblioteką“ iš scenarijų, kurie taps jūsų tyliaisiais asistentais, paruoštais veikti savarankiškai dėl „cron“, „at“ arba „systemd“ laikmačių.

Automatizavimas ir saugumas: „Linux“ serverio stiprinimas

Beveik kiekvieną kartą, kai kalbama apie automatizavimą rimtuose serveriuose, pokalbis neišvengiamai pasisuka apie saugumą. „Linux“ serverio stiprinimas apima jo atakų paviršiaus sumažinimą, geriausios praktikos diegimą ir saugumo kontrolės automatizavimą, kad jos nereikėtų rankiniu būdu atkurti duomenų.

Svarbus pirmas žingsnis yra vartotojo paskyros valdymas . Patartina vengti bendrinių ar akivaizdžių vartotojo vardų (pvz., „admin“ arba „oracle“), naudoti mažiau nuspėjamus vardus, nustatyti stiprias slaptažodžių politikas su periodišku galiojimo laiku ir pakoreguoti UID diapazonus, kad jų nebūtų lengva atspėti.

Kita nerimą kelianti sritis yra įdiegti paketai. Kuo daugiau nereikalingos programinės įrangos turite, tuo didesnis tampa jūsų atakų paviršius. Todėl patartina išvardyti įdiegtus paketus, pašalinti nenaudojamus ir stebėti priklausomybes, kad netyčia nesugadintumėte svarbių paslaugų.

Taip pat turėtumėte patikrinti veikiančias paslaugas naudodami tokius įrankius kaip „systemctl“, sustabdyti ir išjungti tas, kurios nieko neprisideda, ir patikrinti klausymosi prievadus naudodami tokius įrankius kaip „netstat“ arba „ss“, kad įsitikintumėte, jog atidaryti tik būtiniausieji.

Jei pridėsime gerą SSH apsaugą (išjungsime tiesioginį root prisijungimą, naudosime rakto autentifikavimą, reguliuosime skirtojo laiko limitus) ir naudosime tokias užkardas kaip „firewalld“ ar „iptables“, gausime kelis apsaugos nuo išorinių atakų sluoksnius be didelių komplikacijų.

SELinux, ugniasienės ir optimizavimas su tuned'ais

Aplinkose, kuriose saugumas yra prioritetas, tokios priemonės kaip „SELinux“ apsaugos nuo pažeidimų panaikinimas veikia kaip papildoma privalomos prieigos kontrolės kliūtis, ribojanti, kurie procesai gali atlikti ką, be tradicinių leidimų.

Svarbu patikrinti „SELinux“ būseną, geriausia konfigūruoti jį griežto vykdymo režimu ir koreguoti politiką pagal sistemos poreikius naudojant specialias programas. Nors iš pradžių tai gali atrodyti bauginančiai, tinkamai sukonfigūravus, ji blokuoja daugelį nepageidaujamų veiksmų.

Tinklo aplinkoje „firewalld“ arba „iptables“ leidžia apibrėžti išsamias įeinančio ir išeinančio srauto taisykles , atidarant tik konkrečias paslaugas, tokias kaip SSH, HTTP ar bet kokia kita, kas iš tiesų būtina. Tai labai sumažina galimų atakų vektorių skaičių.

Kita vertus, yra tokių įrankių kaip „Tuned“, skirtų sistemos našumui optimizuoti naudojant iš anksto nustatytus profilius, pagrįstus darbo krūvio tipu: serveris, darbalaukis, virtualūs svečiai ir kt. Įjungus tinkamą profilį ir leidus „Tuned“ valdyti tam tikrus parametrus, sutaupoma laiko ir pagerinamas bendras našumas.

Visa tai beprasmiška, jei atliekama tik vieną kartą, o paskui pamirštama. Saugumui ir našumui reikalinga nuolatinė peržiūra, reguliarūs pataisymai ir nuolatinis stebėjimas , ir būtent čia praverčia automatizavimas: daugelį šių įprastų užduočių galima suplanuoti taip, kad jos vyktų automatiškai.

„Ansible“: didelio masto automatizavimas ir konfigūracijos valdymas

Kai serverių skaičius plečiamas nuo vieno ar dviejų iki dešimčių ar šimtų, „cron“ ir vietiniai scenarijai neužtikrina nuoseklumo. „Ansible“ pasirodo kaip automatizavimo ir konfigūracijos valdymo įrankis , kuriam nereikia agentų mazguose ir kuris naudoja SSH bei skaitomus YAML failus.

Naudodami „Ansible“ galite apibrėžti pagrindinių kompiuterių atsargas, generuoti SSH raktų poras autentifikavimui be slaptažodžio ir automatizuoti „Linux“ sistemos administravimą, rašydami veiksmų planus, kuriuose aprašoma pageidaujama serverių būsena : kuriuos paketus reikia įdiegti, kurios paslaugos aktyvios, kurie konfigūracijos failai yra ir pan.

Didžiausias privalumas yra tas, kad tą patį veiksmų planą galite taikyti kelioms sistemoms vienu metu ir gauti nuoseklų bei pakartojamą rezultatą , o tai būtų labai sunku pasiekti, jei kiekvienas administratorius pakeitimus taikytų rankiniu būdu. Be to, „Ansible“ yra idempotentinė: to paties veiksmų plano paleidimas kelis kartus nieko nesugadina; jis tiesiog užtikrina, kad viskas būtų taip, kaip turėtų būti.

Pavyzdžiui, paprastas veiksmų planas gali įdiegti „tmux“ visuose „žiniatinklio“ grupės serveriuose vos keliomis kodo eilutėmis. Remiantis tuo, galima kurti sudėtingesnes automatizacijas: programų diegimą, masinį konfigūracijos keitimą, raktų rotaciją ir pan.

Saugumo kontekste „Ansible“ idealiai tinka griežtesnių politikų taikymui, ugniasienių konfigūravimui, SSH derinimui arba audito scenarijų diegimui visuose mazguose centralizuotai, užkertant kelią klaidoms ir nukrypimams.

Kasdienė automatizacija: pavyzdžiai ir darbo filosofija

Be konkrečių įrankių, laikui bėgant susiformuoja ir mąstysena: kiekvieną kartą, kai kelis kartus rankiniu būdu pakartojate ką nors, verta savęs paklausti, ar to negalima automatizuoti . „Linux“ tam tiesiogine prasme ir sukurta.

Kai kurie žmonės terminalą netgi laiko tyliu asistentu, kuris fone atlieka įvairius darbus: planuoja el. pašto priminimus, generuoja savaitines santraukas, sinchronizuoja katalogus su nuotoliniais serveriais arba valo atsisiuntimų ir laikinus aplankus jums net piršto nepajudinus.

Netgi dažnai nepastebimi įrankiai, tokie kaip „at“, leidžia suplanuoti vienkartinį paleidimą rytoj konkrečiu laiku be vargo, kurį sukelia „cron“ darbas . Kartu su gerai struktūrizuotais scenarijais šios priemonės paverčia jūsų „Linux“ sistemą savotiška skaitmenine „indaplove“, kuri tvarko pasikartojančias užduotis.

Svarbu automatizavimą vertinti vadovaujantis sveiku protu ir mąstant : svarbu ne automatizuoti dėl to, kad tai madinga, o įvertinti, kurios užduotys užima daug laiko, yra linkusios į žmogiškąsias klaidas arba turi poveikį, jei yra pamirštamos, ir pirmiausia nustatyti joms prioritetą.

Laikui bėgant, jūs rašote sau nedidelius pratimus: „cron“ užduotis, kurios įrašo datą ir laiką, kad patikrintų, ar teisingai sukonfigūravote sintaksę, atsarginių kopijų kūrimo scenarijus, stebėjimo scenarijus ir netgi kai kurių šių užduočių konvertavimą į „systemd“ laikmačius su pastovumu ir atsitiktiniais vėlavimais, kad būtų paskirstyta apkrova.

Sudėjus visus šiuos elementus – „Bash“ scenarijus, „cron“, „anacron“, „at“, „systemd“ laikmačius, „Ansible“, geriausią saugumo praktiką, užkardas ir optimizavimo įrankius – sukuriama aplinka, kurioje „Linux“ veikia jums visą parą, tvarko atsargines kopijas, stiprina saugumą ir rūpinasi našumu , o jūs sutelkiate dėmesį į mažiau mechanines ir įdomesnes problemas.