Et huet sech d'Neit Joer ugekënnegt. Kanner am ganze Land hate scho Bréiwer un de Kleeschen geschéckt oder Kaddoen fir sech selwer gemaach, an hiren Haaptexekutor, ee vun de groussen Händler, huet sech op d'Apotheose vum Verkaf virbereet. Am Dezember klëmmt d'Laascht op säin Rechenzentrum e puer Mol. Dofir huet d'Firma beschloss, den Rechenzentrum ze moderniséieren an e puer Dosen nei Serveren a Betrib ze setzen amplaz vun Ausrüstung, déi d'Enn vu sengem Liewensdauer erreecht huet. Dëst schléisst d'Geschicht géint d'Kulisse vu dréiende Schnéiflacken op, an den Thriller fänkt un.

D'Ausrüstung ass e puer Méint virum Héichpunkt vum Verkaf op de Site ukomm. Den Operatiounsservice weess natierlech wéi a wat fir op de Serveren ze konfiguréieren fir se an d'Produktiounsëmfeld ze bréngen. Awer mir hu missen dat automatiséieren an de mënschleche Faktor eliminéieren. Zousätzlech goufen d'Server virun der Migratioun vun enger Rei vu SAP Systemer ersat, déi fir d'Firma kritesch waren.

D'Commissioning vun neie Serveren war strikt un eng Frist gebonnen. A plënneren huet gemengt souwuel d'Versendung vun enger Milliard Kaddoen an d'Migratioun vu Systemer a Gefor ze bréngen. Och e Team aus Papp Frost a Kleeschen konnt den Datum net änneren - Dir kënnt de SAP System fir Lagermanagement nëmmen eemol am Joer iwwerdroen. Vum 31. Dezember bis den 1. Januar stinn déi rieseg Lagerhaiser vum Händler, insgesamt der Gréisst vun 20 Fussballsterrainen, hir Aarbecht fir 15 Stonnen op. An dëst ass déi eenzeg Zäit fir de System ze plënneren. Mir hu kee Raum fir Feeler beim Aféierung vun Serveren.

Loosst mech kloer sinn: meng Geschicht reflektéiert d'Tools an d'Konfiguratiounsmanagementprozess déi eis Team benotzt.

De Konfiguratiounsmanagementkomplex besteet aus e puer Niveauen. De Schlësselkomponent ass de CMS System. An der industrieller Operatioun wäert d'Feele vun engem vun den Niveauen zwangsleefeg zu onsympathesche Wonner féieren.

OS Installatioun Gestioun

Den éischten Niveau ass e System fir d'Installatioun vu Betribssystemer op kierperlechen a virtuelle Serveren ze managen. Et erstellt Basis OS Konfiguratiounen, eliminéiert de mënschleche Faktor.

Mat dësem System krute mir Standard Server Instanzen mat OS gëeegent fir weider Automatisatioun. Wärend dem "Pouring" kruten se e Minimum Set vu lokalen Benotzer an ëffentleche SSH Schlësselen, souwéi eng konsequent OS Konfiguratioun. Mir konnten garantéiert sinn d'Serveren duerch d'CMS ze verwalten a ware sécher datt et keng Iwwerraschungen "ënnert ënnen" um OS Niveau waren.

Déi "maximal" Aufgab fir den Installatiounsmanagementsystem ass d'Server automatesch vum BIOS / Firmware-Niveau op den OS ze konfiguréieren. Vill hei hänkt vun der Ausrüstung an Opstellungsaufgaben of. Fir heterogen Ausrüstung kënnt Dir berücksichtegen REDFISH API. Wann all d'Hardware vun engem Verkeefer ass, ass et dacks méi praktesch fäerdege Management Tools ze benotzen (zum Beispill HP ILO Amplifier, DELL OpenManage, etc.).

Fir den OS op kierperlech Serveren z'installéieren, hu mir de bekannte Cobbler benotzt, deen eng Rei vun Installatiounsprofiler definéiert, déi mam Operatiounsservice ausgemaach ass. Wann Dir en neie Server an d'Infrastruktur bäigefüügt huet, huet den Ingenieur d'MAC Adress vum Server un den erfuerderleche Profil am Cobbler gebonnen. Wann Dir fir d'éischte Kéier iwwer dem Netz booten, krut de Server eng temporär Adress an e frësche OS. Duerno gouf et op d'Zil VLAN / IP Adresséierung transferéiert a weider do geschafft. Jo, VLAN änneren brauch Zäit a verlaangt Koordinatioun, mee et gëtt zousätzlech Schutz géint zoufälleg Installatioun vum Server an engem Produktioun Ëmwelt.

Mir hunn virtuell Serveren erstallt baséiert op Templates virbereet mat HashiСorp Packer. De Grond war déi selwecht: fir méiglech mënschlech Feeler beim Installatioun vum OS ze verhënneren. Awer, am Géigesaz zu de physikalesche Serveren, eliminéiert Packer de Besoin fir PXE, Netzwierkbooten, a VLAN Ännerungen. Dëst huet et méi einfach a méi einfach gemaach virtuell Serveren ze kreéieren.

Reis. 1. Gestioun vun der Installatioun vun Betribssystemer.

Geheimnisser Gestioun

All Konfiguratiounsmanagementsystem enthält Daten déi vun normale Benotzer verstoppt solle sinn, awer néideg fir Systemer virzebereeden. Dëst sinn Passwierder vu lokalen Benotzer a Servicekonten, Zertifikatschlësselen, verschidde API Tokens, etc.. Si ginn normalerweis "Geheimnisser" genannt.

Wann Dir net vun Ufank un feststellt, wou a wéi Dir dës Geheimnisse späichert, da sinn, ofhängeg vun der Schwieregkeet vun den Informatiounssécherheetsfuerderunge, déi folgend Späichermethoden méiglecherweis:

• direkt am Konfiguratiounskontrollcode oder an Dateien am Repository;
• an spezialiséiert Configuratioun Gestioun Handwierksgeschir (Zum Beispill, Ansible Vault);
• an CI / CD Systemer (Jenkins / TeamCity / GitLab / etc.) oder an Konfiguratioun Gestioun Systemer (Ansible Tower / Ansible AWX);
• Geheimnisser kënnen och "manuell" transferéiert ginn. Zum Beispill gi se an enger spezifizéierter Plaz geluecht, an da gi se vun Konfiguratiounsmanagementsystemer benotzt;
• verschidde Kombinatioune vun der uewen.

All Method huet seng eegen Nodeeler. Den Haaptgrond ass de Mangel u Politik fir Zougang zu Geheimnisser: et ass onméiglech oder schwéier ze bestëmmen, wien verschidde Geheimnisse benotze kann. En aneren Nodeel ass de Mangel un Zougang Audit an e ganze Liewenszyklus. Wéi séier ze ersetzen, zum Beispill en ëffentleche Schlëssel, deen am Code an an enger Rei vu verbonne Systemer geschriwwe gëtt?

Mir hunn déi zentraliséiert Geheimlagerung HashiCorp Vault benotzt. Dëst erlaabt eis:

• halen Geheimnisser sécher. Si sinn verschlësselte, an och wann een Zougang zu der Vault-Datebank kritt (zum Beispill, andeems se se aus engem Backup restauréiert), kënnen se net d'Geheimnisser liesen, déi do gespäichert sinn;
• organiséieren Politik fir Zougang zu Geheimnisser. Nëmmen d'Geheimnisser "zougewisen" hinnen sinn fir Benotzer an Uwendungen sinn;
• Audit Zougang zu Geheimnisser. All Aktiounen mat Geheimnisser ginn am Vault Audit Log opgeholl;
• organiséieren e vollwäertege "Liewenszyklus" vun der Aarbecht mat Geheimnisser. Si kënne erstallt ginn, zréckgezunn, en Verfallsdatum festleeën, asw.
• einfach mat anere Systemer z'integréieren déi Zougang zu Geheimnisser brauchen;
• a benotzt och end-to-end Verschlësselung, eemoleg Passwierder fir d'OS an d'Datebank, Certificaten vun autoriséierten Zentren, etc.

Loosst eis elo op den zentrale Authentifikatiouns- an Autorisatiounssystem weidergoen. Et war méiglech ouni et ze maachen, awer d'Verwaltung vu Benotzer a ville verbonne Systemer ass ze net-trivial. Mir hunn d'Authentifikatioun an d'Autorisatioun duerch den LDAP-Service konfiguréiert. Soss muss Vault kontinuéierlech d'Authentifikatiouns-Tokens fir d'Benotzer ausginn a verfollegen. A läschen an derbäi Benotzer géif zu enger Quest ginn "huet ech dëse Benotzerkont iwwerall erstallt / geläscht?"

Mir addéieren en aneren Niveau un eise System: Geheimnismanagement an zentral Authentifikatioun / Autorisatioun:

Reis. 2. Geheimnisser Gestioun.

Configuratioun Gestioun

Mir koumen zum Kär - de CMS System. An eisem Fall ass dëst eng Kombinatioun vun Ansible a Red Hat Ansible AWX.

Amplaz Ansible, Chef, Puppet, SaltStack kënne benotzt ginn. Mir hunn Ansible gewielt op Basis vu verschiddene Critèren.

• Als éischt ass et Villsäitegkeet. Eng Rei vu fäerdege Moduler fir Kontroll et ass beandrockend. A wann Dir net genuch dovun hutt, kënnt Dir op GitHub a Galaxy sichen.
• Zweetens ass et net néideg Agenten op verwalteten Ausrüstung z'installéieren an z'ënnerstëtzen, ze beweisen datt se net mat der Belaaschtung stéieren, a bestätegen d'Feele vu "Lieszeechen".
• Drëttens, Ansible huet eng niddereg Barrière fir d'Entrée. E kompetenten Ingenieur wäert en Aarbechtsbuch wuertwiertlech um éischten Dag vun der Aarbecht mam Produkt schreiwen.

Awer Ansible eleng an engem Produktiounsëmfeld war net genuch fir eis. Soss géife vill Problemer entstoen mat der Aschränkung vun den Zougang an d'Aktualitéit vun den Handlungen vun den Administrateuren. Wéi den Zougang ze limitéieren? No allem war et néideg fir all Departement ze verwalten (liesen: d'Ansible Playbook lafen) "seng eegen" Set vu Serveren. Wéi erlaabt nëmmen bestëmmte Mataarbechter spezifesch Ansible Playbooks ze lafen? Oder wéi ze verfollegen wien de Playbook lancéiert huet ouni vill lokalt Wëssen op Serveren an Ausrüstung opzestellen déi Ansible lafen?

Den Deel vum Léiw vun esou Themen gëtt vum Red Hat geléist Ansible Tower, oder säin Open-Source Upstream Projet Ansible AWX. Dofir hu mir et léiwer fir de Client.

An nach een Touch zum Portrait vun eisem CMS System. Ansible Playbook soll a Code Repository Management Systemer gespäichert ginn. Mir hunn et GitLab CE.

Also, d'Konfiguratiounen selwer ginn duerch eng Kombinatioun vun Ansible / Ansible AWX / GitLab geréiert (kuckt Fig. 3). Natierlech ass AWX / GitLab mat engem eenzegen Authentifikatiounssystem integréiert, an Ansible Playbook ass mat HashiCorp Vault integréiert. Konfiguratioune ginn nëmmen duerch Ansible AWX an d'Produktiounsëmfeld an, an där all "Spillregelen" spezifizéiert sinn: wien kann konfiguréieren wat, wou de Configuratiounsmanagementcode fir den CMS ze kréien, asw.

Reis. 3. Configuratioun Gestioun.

Test Gestioun

Eis Konfiguratioun gëtt a Codeform presentéiert. Dofir si mir gezwongen déi selwecht Regele wéi Software Entwéckler ze spillen. Mir mussen d'Prozesser vun der Entwécklung organiséieren, kontinuéierlech Testen, Liwwerung an Uwendung vum Konfiguratiounscode op Produktiounsserveren.

Wann dëst net direkt gemaach gëtt, da géifen d'Rollen, déi fir d'Konfiguratioun geschriwwe sinn, entweder ophalen ze ënnerstëtzen a geännert ginn, oder géifen ophalen an der Produktioun ze lancéieren. D'Kur fir dëse Schmerz ass bekannt, an et huet sech an dësem Projet bewisen:

• all Roll ass vun Eenheet Tester Daach;
• Tester ginn automatesch lafen wann et eng Ännerung am Code gëtt deen d'Konfiguratiounen geréiert;
• Ännerungen am Konfiguratiounsmanagement Code ginn an d'Produktiounsëmfeld verëffentlecht nëmmen nodeems se all Tester a Code iwwerpréift.

Code Entwécklung a Konfiguratiounsmanagement si méi roueg a méi prévisibel ginn. Fir kontinuéierlech Testen ze organiséieren, hu mir de GitLab CI / CD Toolkit benotzt, an hunn geholl Ansible Molekül.

Wann et eng Ännerung am Konfiguratiounsmanagementcode gëtt, rifft GitLab CI / CD Molekül:

• et kontrolléiert de Code Syntax,
• hieft den Docker Container,
• gëlt de geännerten Code op de geschafene Container,
• iwwerpréift d'Roll fir Idempotenz a fiert Tester fir dëse Code (d'Granularitéit hei ass um ansible Rollniveau, kuckt Fig. 4).

Mir hunn Konfiguratiounen an d'Produktiounsëmfeld geliwwert mat Ansible AWX. Operatiounsingenieuren hunn Konfiguratiounsännerungen duerch virdefinéiert Template applizéiert. AWX huet onofhängeg déi lescht Versioun vum Code vun der GitLab Master Branche "gefrot" all Kéier wann et benotzt gouf. Op dës Manéier hu mir d'Benotzung vun ontestenen oder alen Code am Produktiounsëmfeld ausgeschloss. Natierlech ass de Code an d'Meeschtesch Branche erakomm nëmmen no Testen, Iwwerpréiwung an Genehmegung.

Reis. 4. Automatesch Testen vun Rollen an GitLab CI / CD.

Et gëtt och e Problem mat der Operatioun vu Produktiounssystemer. Am richtege Liewen ass et ganz schwéier Konfiguratiounsännerungen duerch CMS Code eleng ze maachen. Noutsituatioune entstinn wann en Ingenieur d'Konfiguratioun "hei an elo" muss änneren, ouni op Code Redaktioun, Testen, Genehmegung, etc.

Als Resultat, duerch manuell Ännerungen, erschéngen Differenzen an der Konfiguratioun op der selwechter Zort Ausrüstung (zum Beispill, sysctl Astellunge sinn anescht op HA Cluster Wirbelen konfiguréiert). Oder déi aktuell Konfiguratioun op der Ausrüstung ënnerscheet sech vun der am CMS Code spezifizéiert.

Dofir, zousätzlech zu kontinuéierlecher Tester, iwwerpréift mir Produktiounsëmfeld fir Konfiguratiounsdiskrepanzen. Mir hunn déi einfachst Optioun gewielt: de CMS Konfiguratiounscode am "Dréchent Run" Modus lafen, dat heescht ouni Ännerungen z'applizéieren, awer mat Notifikatioun vun all Ënnerscheeder tëscht der geplangter an der aktueller Konfiguratioun. Mir hunn dëst ëmgesat andeems se periodesch all Ansible Playbooks mat der "-check" Optioun op Produktiounsserver lafen. Wéi ëmmer ass d'Ansible AWX verantwortlech fir d'Playbook ze lancéieren an um neiste Stand ze halen (kuckt Fig. 5):

Reis. 5. Schecken fir Konfiguratioun Differenzen an Ansible AWX.

No Kontrollen schéckt AWX en Diskrepanzbericht un d'Administrateuren. Si studéieren déi problematesch Konfiguratioun an fixen se dann duerch ugepasste Spillbicher. Dëst ass wéi mir d'Konfiguratioun am Produktiounsëmfeld behalen an de CMS ass ëmmer aktuell a synchroniséiert. Dëst eliminéiert désagréabel "Wonner" wann CMS Code op "Produktioun" Serveren benotzt gëtt.

Mir hunn elo eng wichteg Testschicht besteet aus Ansible AWX / GitLab / Molekül (Figur 6).

Reis. 6. Test Gestioun.

Schwéier? Ech streiden net. Awer esou e Komplex vu Konfiguratiounsmanagement ass eng ëmfaassend Äntwert op vill Froen am Zesummenhang mat der Automatiséierung vun der Serverkonfiguratioun ginn. Elo hunn d'Standardservere vun engem Händler ëmmer eng strikt definéiert Konfiguratioun. CMS, am Géigesaz zu engem Ingenieur, wäert net vergiessen déi néideg Astellungen ze addéieren, Benotzer erstellen an Dutzende oder Honnerte vun erfuerderlechen Astellungen auszeféieren.

Et gëtt kee "geheime Wëssen" an den Astellunge vu Serveren an Ëmfeld haut. All néideg Funktiounen sinn am Spillbuch reflektéiert. Keng Kreativitéit a vague Instruktioune méi: "Installéiert et wéi normal Oracle, awer Dir musst e puer sysctl Astellunge spezifizéieren an d'Benotzer mat der erfuerderter UID addéieren. Frot d'Kärelen an der Operatioun, si wëssen".

D'Kapazitéit fir Konfiguratiounsdiskrepanzen z'entdecken an se proaktiv ze korrigéieren bitt Fridden vum Geescht. Ouni e Konfiguratiounsmanagementsystem gesäit dëst normalerweis anescht aus. Problemer accumuléieren bis enges Daags se "schéissen" an d'Produktioun. Duerno gëtt eng Debriefing duerchgefouert, Konfiguratiounen iwwerpréift a korrigéiert. An den Zyklus widderhëlt sech erëm

An natierlech beschleunegt mir de Start vun Serveren an Operatioun vun e puer Deeg op Stonnen.

Gutt, op Silvester selwer, wéi d'Kanner mat Freed Kaddoe ofgeschaaft hunn an Erwuessener Wënsch gemaach hunn wéi d'Kimmer geschloen hunn, hunn eis Ingenieuren de SAP System op nei Serveren migréiert. Och de Kleeschen wäert soen datt déi bescht Wonner déi sinn déi gutt virbereet sinn.

PS Eist Team begéint dacks d'Tatsaach datt d'Clienten d'Konfiguratiounsmanagementproblemer sou einfach wéi méiglech wëllen léisen. Ideal, wéi duerch Zauber - mat engem Tool. Awer am Liewen ass alles méi komplizéiert (jo, Sëlwer Kugelen goufen net erëm geliwwert): Dir musst e ganze Prozess erstellen andeems Dir Tools benotzt, déi fir d'Clients Team bequem sinn.

Auteur: Sergey Artemov, Departement Architekt DevOps Léisungen "Jet Infosystems"

Source: will.com