Dit is een transcriptie van de toespraak и .
Dit is het verhaal van een project dat gebruik maakte van een zelfgeschreven configuratiemanagementsysteem en waarom de overstap naar Ansible 18 maanden duurde.
Dag nr. -ХХХ: vóór het begin
Aanvankelijk bestond de infrastructuur uit veel afzonderlijke hosts waarop Hyper-V draaide. Het maken van een virtuele machine vereiste veel stappen: de schijven op de juiste plek zetten, DNS registreren, DHCP reserveren, de VM-configuratie in de git-repository plaatsen. Dit proces was gedeeltelijk gemechaniseerd, maar VM's werden bijvoorbeeld handmatig tussen hosts gedistribueerd. Maar ontwikkelaars kunnen bijvoorbeeld de VM-configuratie in git corrigeren en deze toepassen door de VM opnieuw op te starten.
Aangepaste configuratiebeheeroplossing
Ik vermoed dat het oorspronkelijke idee was bedacht als IaC: veel staatloze VM's die hun status naar nul resetten wanneer ze opnieuw worden opgestart. Wat was VM-configuratiebeheer? Schematisch ziet het er simpel uit:
- Er werd een statische MAC vastgelegd voor de VM.
- Op de VM waren een ISO met CoreOS en een opstartschijf aangesloten.
- CoreOS start het aanpassingsscript door het te downloaden van de WEB-server op basis van zijn IP.
- Het script downloadt de VM-configuratie via SCP op basis van het IP-adres.
- Het voetdoek van systeemeenheidbestanden en het voetdoek van bash-scripts worden gelanceerd.
Deze oplossing had veel voor de hand liggende problemen:
- CoreOS ISO is verouderd.
- Veel complexe geautomatiseerde acties en magie bij het migreren/creëren van VM's.
- Moeilijkheden met updaten en wanneer een bepaalde softwareversie nodig is. Nog meer plezier met kernelmodules.
- VM's werden niet zo verkregen zonder gegevens, d.w.z. VM's verschenen met een schijf waarop extra gebruikersgegevens waren gemonteerd.
- Iemand was voortdurend bezig met het verknoeien van de afhankelijkheden van de systeemeenheden en CoreOS liep vast bij het opnieuw opstarten. Het was moeilijk om dit op te vangen met de beschikbare tools in CoreOS.
- Beheer van geheimen.
- Er was geen CM. Er waren bash- en YML-configuraties voor CoreOS.
Om de VM-configuratie toe te passen, moet u deze opnieuw opstarten, maar mogelijk wordt deze niet opnieuw opgestart. Het lijkt een voor de hand liggend probleem, maar er zijn geen persistente schijven - er is geen plek om logbestanden op te slaan. Nou, oké, laten we proberen de kernellaadoptie toe te voegen, zodat de logs worden verzonden. Maar nee, hoe ingewikkeld is het allemaal.
Dag #0: Herken het probleem
Het was de gebruikelijke ontwikkelingsinfrastructuur: jenkins, testomgevingen, monitoring, register. CoreOS is ontworpen voor het hosten van k8s-clusters, d.w.z. het probleem was hoe CoreOS werd gebruikt. De eerste stap was het kiezen van een stapel. Wij hebben besloten:
- CentOS als basisverdeling, omdat Dit is de distributie die het dichtst bij productieomgevingen ligt.
- Ansible voor configuratiebeheer, omdat er is uitgebreid onderzoek naar gedaan.
- Jenkins als raamwerk voor het automatiseren van bestaande processen, omdat het wordt al actief gebruikt voor ontwikkelingsprocessen
- Hyper-V als virtualisatieplatform. Er zijn een aantal redenen die buiten het bestek van het verhaal vallen, maar kort gezegd: we kunnen de clouds niet gebruiken, we moeten onze eigen hardware gebruiken.
Dag nr. 30: Vaststelling van bestaande overeenkomsten - Overeenkomsten als code
Toen de stapel leeg was, begonnen de voorbereidingen voor de zet. Vastleggen van bestaande afspraken in de vorm van code (Afspraken als Code!). Overgang handenarbeid -> mechanisatie -> automatisering.
1. Configureer VM's
Ansible doet dit uitstekend. Met een minimum aan lichaamsbewegingen kunt u de controle over VM-configuraties overnemen:
- Maak een git-repository.
- We plaatsen de lijst met VM's in de inventaris, configuraties in playbooks en rollen.
- We zijn een speciale Jenkins-slave aan het opzetten van waaruit je Ansible kunt draaien.
- We maken een taak aan en configureren Jenkins.
Het eerste proces is klaar. De afspraken staan vast.
2. Maak een nieuwe virtuele machine
Alles was hier niet erg handig. Het is niet erg handig om vanuit Linux VM's op Hyper-V te maken. Een van de pogingen om dit proces te mechaniseren was:
- Ansbile maakt via WinRM verbinding met de Windows-host.
- Ansible voert een powershell-script uit.
- Powershell-script maakt een nieuwe VM.
- Met behulp van Hyper-V/ScVMM wordt bij het maken van een VM in het gastbesturingssysteem de hostnaam geconfigureerd.
- Bij het bijwerken van de DHCP-lease verzendt de VM zijn hostnaam.
- Standaard ddns- en DHCP-integratie aan de kant van de domeincontroller configureert het DNS-record.
- U kunt een VM aan uw inventaris toevoegen en deze configureren met Ansible.
3. Maak een VM-sjabloon
Ze hebben hier niets uitgevonden - ze hebben een inpakker meegenomen.
- Voeg de packer, kickstart config toe aan de git repository.
- Een speciale Jenkins-slave opzetten met hyper-v en Packer.
- We maken een taak aan en configureren Jenkins.
Hoe deze koppeling werkt:
- Packer maakt een lege VM en haalt de ISO op.
- De VM start op, Packer voert het commando in de bootloader in om ons kickstart-bestand vanaf een diskette of http te gebruiken.
- Anaconda wordt gestart met onze configuratie en de initiële OS-configuratie is voltooid.
- Packer wacht tot de VM beschikbaar komt.
- Packer binnen de VM draait anible in de lokale modus.
- Ansible gebruikt precies dezelfde rollen als in stap #1.
- Packer exporteert de VM-sjabloon.
Dag #75: Herformuleer de overeenkomst zonder deze te verbreken = Test anible + Testkitchen
Het vastleggen van conventies in code is misschien niet voldoende. Als je in het reilen en zeilen van het proces iets wilt veranderen, kun je immers iets kapot maken. Daarom verschijnt in het geval van infrastructuur het testen van juist deze infrastructuur. Om de kennis binnen het team te synchroniseren, zijn we Ansible-rollen gaan testen. Ik ga er niet dieper op in, want... er is een artikel dat de gebeurtenissen op dat moment beschrijft (spoiler dit was niet de definitieve versie en later werd alles ingewikkelder ).
Dag #130: Misschien is CentOS+ansible niet nodig? misschien openshift?
We moeten begrijpen dat het proces van het introduceren van infrastructuur niet het enige was en dat er nevenprojecten waren. Zo kwam er een verzoek om onze applicatie in openshift te lanceren en dat leverde ruim een week onderzoek op wat het bewegingsproces vertraagde. Het resultaat bleek dat openshift niet aan alle behoeften voldoet; je hebt echte hardware nodig, of op zijn minst de mogelijkheid om met de kernel te spelen.
Dag #170: Openshift is niet geschikt, laten we een gokje wagen met Windows Azure Pack?
Hyper-V is niet erg vriendelijk, SCVMM maakt het niet veel beter. Maar er bestaat zoiets als Windows Azure Pack, een add-on voor SCVMM en die Azure nabootst. Maar in werkelijkheid ziet het product er verlaten uit: de documentatie heeft verbroken links en is zeer schaars. Maar als onderdeel van het onderzoek naar opties om de levensduur van onze cloud te vereenvoudigen, hebben ze er ook naar gekeken.
Dag #250: Windows Azure Pack niet erg goed. Wij blijven op SCVMM
Windows Azure Pack zag er veelbelovend uit, maar er werd besloten om WAP met zijn complexiteiten niet in het systeem te brengen omwille van onnodige functies en bleef bij SCVMM.
Dag #360: De olifant stukje bij beetje opeten
Slechts een jaar later was het platform om naartoe te verhuizen klaar en begon het verhuisproces. Hiervoor is een SMART-taak opgesteld. We hebben alle VM's uitgeprobeerd en begonnen de configuratie één voor één uit te zoeken, deze te beschrijven in Ansible en deze af te dekken met tests.
Dag #450: Wat voor soort systeem heb je gekregen?
Het proces zelf is niet interessant. Het is routine, er kan worden opgemerkt dat de meeste configuraties relatief eenvoudig of isomorf waren en dat volgens het Pareto-principe 80% van de VM-configuraties 20% van de tijd nodig hadden. Volgens hetzelfde principe werd 80% van de tijd besteed aan het voorbereiden van de verhuizing en slechts 20% aan de verhuizing zelf.
Dag #540: Finale
Wat gebeurde er in 18 maanden?
- De afspraken werden een code.
- Handenarbeid -> mechanisatie -> Automatisering.
Kruisstukken
Bron: www.habr.com