Sustavi za upravljanje konfiguracijama

[Annatar]

Pa trebala bi, ali ti za provisioning definitivno ne trebaju Puppet ili Salt (ili CFengine, ili Chef): provisioning se dela OS paketima. Configuration management isto.

Ako nemaš neki software za change management, onda ti je dobar za prvo vrijeme i neki revision control system, poput Mercuriala ili git-a.

Svi takvi "alati" poput Puppeta su zlo. To je rak IT industrije. I metastaziran je. Diskusija z primjerima je definitivno potrebna.

[grogo bolger]

Dakle iskopirao sam Annatarov post o CM i provisioningu.

Nemam pojma oko ovoga, ali silom prilika moram naučit.

Moram koristiti puppet i čini mi se ok.

@Annatar zakay je to rak rana?

Ajmo DevOpsirati

[logit]

Bas i mene veseli ista tema obzirom da me za koji mjesec ceka izrada diplomskog rada
pa da vidimo sto deda ima u skrinjici znanja jos

[grogo bolger]

Dakle imam nekoliko frontend čvorova, svi imaju kombinaciju nginx+varnish.

Na svaki instaliram puppet agenta i sa mastera po imenu servera u puppet manifestima nakucam (naravno spojim ih na mastera, certovi ovo ono):
-da se instalira nginx
-da se instalira varnish
-sa mastera prekobacim poseban tuniran config file.

Što tu ne valja?

[Florest Glimp]

http://www.katello.org/
ili clientless:
http://www.ansible.com/

Što god ima version control, update i rollback a bavi se konfiguracijom bez ad-hoc mijenjanja na klijentu, meni je ekvivalent paketu koji se distribuira na klijenta.

[Annatar]

grogo bolger kaže:

Dakle imam nekoliko frontend čvorova, svi imaju kombinaciju nginx+varnish.

Na svaki instaliram puppet agenta

A zakaj ti treba agent?

-da se instalira nginx
-da se instalira varnish

A zakaj nemreš to instalirati putem instalacijskog programa, kao na primjer Kickstart, AutoYaST, ili JumpStart, ili ak si na SmartOS-u, jednostavno putem SSH ili mSSH?

-sa mastera prekobacim poseban tuniran config file.

Zakaj nisi mogel tu konfiguracijsku datoteku spakirati v OS paket, i njega najnormalnije instalirati putem SSH ili mSSH?

[Annatar]

Florest Glimp kaže:

Što god ima version control, update i rollback a bavi se konfiguracijom bez ad-hoc mijenjanja na klijentu, meni je ekvivalent paketu koji se distribuira na klijenta.

Super. Sad pretpostavi da ti NISI onaj koji je to sklepal (3rd level system engineering), neg da si v 2nd level production support, gdi su sistem administratori. Došlo je do kvara. Sistem administratori nemaju pristup tvojem sustavu za konfiguraciju iz sigurnosnih razloga. Ili još bolje, nije došlo do kvara, neg je sistem inžinjer sklepal krivu konfiguraciju, i onda je pomoću jednog takvog sustava distribuiral. Konfiguracija je tempirana bomba, koja, na prvi pogled, dela kak spada, OSIM ako nije instalirana sat vremena prije neg mrežni administratori ažuriraju konfiguraciju. Nakon toga dolazi do prekida komunikacija, ali samo ukoliko je tvoja promjena instalirana sat vremena prije.

Sad si v ulozi 2nd level podrške, odnosno zamisli si da si jedan od sistem administratora. Dva sata ujutro su. Imaš priority 1 incident.
Probaj pitati operativni sustav, kaj mu je napravljeno, kad, gdi, i od koga. Da vidim.

Kdo je obavl formalni pregled i provjeru te tvoje konfiguracijske promjene?

Probaj pitati operativni sustav koje datoteke su afektirane. 25000 servera je afektirano.

[grogo bolger]

@Annatare a zar mi nije lakše i fleksibilnije držat sve te konfiguracije u gitu?

Pa samo fetcham sa repozitorija i evo ga na. Ako nešto promjenim commitam natrag i usput imam i praćenje promjena nad konfiguracijom, recimo nginx-a.

Pravljenje paketa mi je overkill.

[Annatar]

grogo bolger kaže:

@Annatare a zar mi nije lakše i fleksibilnije držat sve te konfiguracije u gitu?

Pa gdi pise da konfiguracijske pakete nemres ili ne smijes drzati v git-u, ili koji god sustav za kontrolu revizije ti pase

Pravljenje paketa mi je overkill.

[ANTRpowerdns-conf] 0> cat etc/opt/antr/powerdns/pdns.conf
daemon=yes
master=yes
slave=yes
setuid=${ANTR_LOGIN}
setgid=${ANTR_GROUP}
write-pid=no
logging-facility=${ANTR_LOGGING_FACILITY}
recursor=${ANTR_RECURSOR_IP}:${ANTR_RECURSOR_PORT}

Na kaj te ovaj gore konfiguracijski predlozak, s shell varijablama v njemu, podsjeca? A to je konfiguracija koja se koristi v produkciji, uchekirana v sustav za kontrolu revizije...

A pazi sad,

[ANTRpowerdns-conf] 0> pkgmk -od /net/installserver/export/install/ANTR/SunOS/any
## Building pkgmap from package prototype file.
## Processing pkginfo file.
WARNING: parameter <PSTAMP> set to "installserver.subdomain.domain.tld20151220122903"
## Attempting to volumize 5 entries in pkgmap.
part  1 -- 20 blocks, 19 entries
## Packaging one part.
/net/installserver/export/install/ANTR/SunOS/any/ANTRpowerdns-conf/pkgmap
/net/installserver/export/install/ANTR/SunOS/any/ANTRpowerdns-conf/pkginfo
/net/installserver/export/install/ANTR/SunOS/any/ANTRpowerdns-conf/root/etc/$ANTR_BASE/powerdns/pdns.conf
/net/installserver/export/install/ANTR/SunOS/any/ANTRpowerdns-conf/install/depend
/net/installserver/export/install/ANTR/SunOS/any/ANTRpowerdns-conf/install/i.conf
/net/installserver/export/install/ANTR/SunOS/any/ANTRpowerdns-conf/install/r.conf
## Validating control scripts.
## Packaging complete.

kaj je tu tocno "overkill" Ista funkcionalnost kao i Puppet, bez ikakvog ekstra softwarea, bez da moras proucavati Puppet i proucavati njegov Ruby dijalekt!

I kaj je najboljse,

ssh dnsmaster 'yes | sudo pkgrm ANTRpowerdns-conf; yes | sudo pkgadd -d /net/installserver/ANTR/SunOS/any ANTRpowerdns-conf'

Ciljani server,

ssh dnsmaster 'cat /etc/opt/antr/powerdns/pdns.conf'
daemon=yes
master=yes
slave=yes
setuid=powerdns
setgid=powerdns
write-pid=no
logging-facility=0
recursor=127.0.0.1:5300

Gdi je tu overkill, pogotovo kad uzmes v obzir da to treba funkcionirati za neograniceni broj sustava?

Jel' mi trebal ekstra software?
Osim sshd(1M), jel mi treba client-server arhitektura?
Jesam trebal navciti specijalni dijalekt Ruby-a?
Jesam napravl nekaj mimo operativnog sustava?

[grogo bolger]

A ono, overkill je da ne znam pravit RPM pakete

[Annatar]

cat << _EOF_ > ~/.rpmmacros 
%HOME           %{expand:%%(echo $HOME)}
%GROGO_BASE       opt/grogo
%_topdir        %{HOME}/devel/rpms
%_prefix        /%{GROGO_BASE}
%_sysconfdir    /etc/%{GROGO_BASE}
%_localstatedir /var/%{GROGO_BASE}
%_defaultdocdir /%{GROGO_BASE}/share/doc
%_mandir        /%{GROGO_BASE}/share/man
%_infodir       /%{GROGO_BASE}/share/info
%__printf       /usr/bin/printf
%__python       /%{GROGO_BASE}/bin/python
^D

% sudo yum install rpm-build
% for Directory in BUILD BUILDROOT SPECS SOURCES RPMS RPMS/noarch RPMS/x86_64 RPMS/i386; do  mkdir -p ${Directory}; done

...Zemi bilo koji redhatov ili SuSE-ov .srpm, iscupaj van sadrzaj (zbrisi vse v SOURCES/ direktoriju), preradi .spec datoteku kak ti pase, imas konfiguracijski paket.

Vse varijable definiras v .spec datoteci kao makroe,

%define GROGO_LOGIN nginx
...
...
...

modifikacije idu v %pre, %post, %preun, ili %postun, ovisno v tome v kojem kontekstu se moraju dogoditi, i to je to. Kad si gotov,

% rpmbuild -ba --clean GRGOnginex-conf.spec

...i rpmbuild ti konstruira RPMS/noarch/GRGOnginex-conf.verzija-revizija.noarch.rpm, kao i SRPM/GRGOnginex-conf-verzija-revizija.noarch.srpm.

SRPM/GRGOnginex-conf-verzija-revizija.noarch.srpm pohranis v git repozitorij i peres dalje z modeliranjem change management procesa.

A osim toga, kad pocnes fakat konfiguracijski management, brzo bu ti postalo jasno da ti stog softwarea koji lifra proizvodjac OS-a vise nije dovoljan, dakle ovo gore znanje bu ti trebalo za paketiranje vlastitog softwarea.

Svaka sekunda investirana v ucenje paketiranja se vraca nazaj z stostrukim kamatama.

[Florest Glimp]

Annatar kaže:

Kdo je obavl formalni pregled i provjeru te tvoje konfiguracijske promjene?

Isti onaj koji obavlja formalni pregled rpm paketa koji sam sklepao i pustio na 25000 servera.

[Annatar]

Florest Glimp kaže:

Isti onaj koji obavlja formalni pregled rpm paketa koji sam sklepao i pustio na 25000 servera.

E jebiga onda!

Nemreš riješiti izostanak change management procesa configuration management tehnologijom.

Općenito se izostanak procesa nemre riješiti tehnologijom, a pogotovo ne v ovom slučaju.

[bata konj harmonikas]

po meni ti softwarei imaju smisla samo ako radis u firmi koja ima i linux (x derivata) i windows, i solaris, i aix i bog te nece svasta nesto. onda imas centralni repozitorij imagea i skripti i policya i svega. i svako drlja svoje, ovisno o pripadnosti odredjenoj user grupi vidis samo "svoje" servere.
nedostatak kao i kod svakog je da nakon x godina rada se nabere kamare skripti, policya, patcheva itd. i prvo sustav postane uzasno spor a drugo ako nisi u startu enforceao nekakav smisleni patching i update sistem poslije imas samo krs i onaj overload glupog posla, krpljenja, koji nije produktivan. vece firme ti sve idu na te nekakve programe za centralizaciju, tipa hpsm, a puppet i chef su vise manje igrackice, za male environments. ima tu mnogo shema za optimizaciju i svsta nesto ali fora je da se citav sistem administracije postavi kako treba od pocetka jer kasnije bude krkljanac, pogotovo a ko firma ima SLA takav da moras imat deployane patcheve i updatee najkasnije u mjesec dana nakon sto su izasli a tool se sjebe, rikne baza, mreza, whatever, po policyu moze svako drkat po svom kako oce, patch je bugiran pa ti napravi rollback ako znas uopce sta je patchirano, rollback na sta ? sta uopce radi ? nece ti hpsm to rec, dakle to je samo tool a ti kao sistem admin moras unaprijed mislit na sve moguce zajebe. cesto ispadne da na kraju mrdas pakete rucno, upgrade, downgrade, jer je idiotski tool zajebo ili ne radi. ali opet kad radi kako treba onda usparas vremena.

[Annatar]

dakle to je samo tool a ti kao sistem admin moras unaprijed mislit na sve moguce zajebe.

To NIJE posel sistem administratora; to je posel sistem inzinjera.

Sistem administrator konzumira ono kaj smisli sistem inzinjer, a posel sistem inzinjera je da to slozi tak da mali broj ljudi moze pritiskanjem "gumba" poganjati masivnu infrastrukturu.

Idemo prvo definirati kontekst, odnosno organizaciju:

1. nivo podrske: help desk;
2. nivo podrske: sistem administratori (operacija);
3. nivo podrske: odjel za sistem inzinjering (komponente).

Za tak nekaj treba prvenstveno osmisliti procese. Tehnologija igra sekundarnu ulogu, jer je to bez organizacijske strukture te procesa ho-ruk, partizanski nacin rada i prije ili kasnije (obicno prije) to devolvira u hackeraj i kaos. Cak i z svom mogucom tehnologijom.

OK, sad sam vam dal organizacijsku strukturu. Kaj je z komponentama? Kakav je to model? Jel' znate?

[bata konj harmonikas]

Annatar kaže:

OK, sad sam vam dal organizacijsku strukturu. Kaj je z komponentama? Kakav je to model? Jel' znate?

ne znam na sta mislis pod model, i ja u principu ne vidim ovu neku podjelu na admine i inzinjere, znaci svako moze sve - ako zna. eventualno visi lvl bi bio neko ko bi odlucio o toolovima i konkretno implementaciji procesa - kroz toolove, znaci sta toolovi mogu, sta trebaju, i onda krenes. npr. u slozenijoj mrezi sa intranetom i DMZ i backup i mgmt mrezom odvojeno, moras rasporedit ldap, ldap copy, dns, bla bla sto cuda kroz firewall ovdje a ovdje ne pa onda na to nakeljit toolove koji ce ti instlirat OS na sisteme kroz satelite, pa movat sistem iz instalacijske u produkcijsku mrezu pa nakeljit rute pa policies pa monitoring, x cuda. i to je neko morao smislit, da. hocu rec da u teoriji bi sve bilo super da se moze bas sve sagledat otpocetka ali cesto se samo krpi postojece, cisto zbog infrastrukture, kako je poslozena historijski, pa onda ni ti sistem inzenjerci nemaju bas ful odrijesene ruke i na kraju sistem admini krpaju kako znaju......a najcesce je 90% toga uvjetovano toolovima, recimo neki saban od menadzera napravi deal s nekom firmom i sad se ti jebi, imas taj i taj tool i iako bi se citava struktura dala bolje i pametnije organizirat, your stuck with what you got i kemijaj brale.

[Annatar]

bata konj harmonikas kaže:

ne znam na sta mislis pod model, i ja u principu ne vidim ovu neku podjelu na admine i inzinjere, znaci svako moze sve - ako zna.

Cak i za to ti treba proces. Bez procesa si zaglavil.

Proces je alfa i omega. Bez procesa te ni jedna tehnologija ne spasi od Viet Cong metoda i hackeraja, cak i da su svi v timu klonovi Bryana Cantrilla.

Cak ni configuration management z OS paketima te ne spasi od hackeraja bez da prvo sednes i razmislis o tome kak bu skvadra bila organizirana te kak bu tekel proces razvoja, poganjanja, te ciklusa osvjezavanja infrastrukture.

Recimo da imas skvadru gdi svako sve zna delat i svi su v tome dobri i svi rade sve. Modeliraj proces po kojemu svi mogu delati sve, a da ipak van dobijes enkapsulirane, potpuno automatizirane komponente koje onda poslije moze poganjati 2. nivo podrske, kad ti organizacija dovoljno sazrije, a da to poganjanje nije "hackiraj, drkaj i mrdaj po sustavima i Puppetu|Chefu|CFEngineu|Salt-u|Ansible-u dok to ne proradi".

[logit]

Dizem malo prasine

Obzirom da imam u serverskoj sali par SPARC mašina na kojima se vrti produkcija moram pitati par pitanja.

Imam dosta virtualiziranih servera i to mahom Solaris 10/11.
Ono sto sam vidio je da svatko se logira na produkciju sa rootom i da moze napraviti promjenu te da nema nikakvih logova o promjenama.

Obzirom da u firmi delam diplomski i imam mašinu koja je doduse virtualizirana ali imam RAMa i procesora dovoljno da sve testiram htio bih
u svoj diplomski staviti upravljanje sustavom na način kako je ovdje opisano:
pomoću sistemskih paketa i da se makne navika da se admin logira u produkciju sa rootom.

Sada mene zanima:

Kada napravim recimo promjenu na sustavu da je potrebno promjeniti adresu NTP poslužitelja na svim serverima. Klaster ne postoji jer uprava neda lovu za njega.

Kako mogu kada kreiram paket isti instalirati na sve sustave, recimo da se radi o Solaris 10 sustavu?

Chef, puppet imaju agenta stalno pita servera da li ima nekih promjena i ako ima iste se automatski primjene. Kako to isto mogu postići sa sistemskim paketima?

Drugo:
Na koji način mogu automatizirat kreiranje i deployanje paketa u repozitorij?
Da li je moguće recimo postaviti nekakav proces kontinuirane integracije koji bi automatski povukao datoteke sa gita ili cega vec, napravio paket, obavio testnu instalaciju i ako je instalacija prosla uspjesno da mi deploya promjenu u produkciju?

[Inspektor Dane]

Za ovo prvo štos napiso za prijave i analize logova treba ti SIEM

Ostalo si dosta nesuvislo nabacao svega, pa mi se neda čitat.

[maliburek]

https://www.youtube.com/watch?v=96PGoXHli3Q

mnogo dobro za pogledat