Tämä on puheen transkriptio и .
Tämä on tarina projektista, jossa käytettiin itse kirjoitettua kokoonpanonhallintajärjestelmää ja miksi muutto Ansibleen kesti 18 kuukautta.
Päivä nro -ХХХ: Ennen alkua
Aluksi infrastruktuuri koostui useista erillisistä isännistä, jotka käyttivät Hyper-V:tä. Virtuaalikoneen luominen vaati monia vaiheita: levyjen sijoittaminen oikeaan paikkaan, DNS:n rekisteröinti, DHCP:n varaaminen, VM-määritysten laittaminen git-varastoon. Tämä prosessi oli osittain mekanisoitu, mutta esimerkiksi VM:t jaettiin isäntien kesken käsin. Mutta esimerkiksi kehittäjät voivat korjata VM-kokoonpanon gitissä ja ottaa sen käyttöön käynnistämällä VM:n uudelleen.
Mukautettu kokoonpanonhallintaratkaisu
Epäilen, että alkuperäinen idea suunniteltiin IaC:ksi: monet tilattomat virtuaalikoneet, jotka nollaavat tilansa uudelleenkäynnistettäessä. Mikä oli VM-määritysten hallinta? Kaavamaisesti se näyttää yksinkertaiselta:
- VM:lle naulattiin staattinen MAC.
- VM:ään liitettiin ISO CoreOS:llä ja käynnistyslevyke.
- CoreOS käynnistää mukautuskomentosarjan lataamalla sen WEB-palvelimelta sen IP-osoitteen perusteella.
- Skripti lataa VM-kokoonpanon SCP:n kautta IP-osoitteen perusteella.
- Systemd-yksikkötiedostojen jalkaliina ja bash-skriptien jalkaliina käynnistetään.
Tällä ratkaisulla oli monia ilmeisiä ongelmia:
- CoreOS ISO on vanhentunut.
- Paljon monimutkaisia automatisoituja toimintoja ja taikuutta siirrettäessä/luodattaessa virtuaalikoneita.
- Vaikeuksia päivittämisen kanssa ja milloin tarvitaan tietty ohjelmistoversio. Vielä hauskempaa ydinmoduulien kanssa.
- VM:itä ei niin saatu ilman dataa, ts. Virtuaalikoneisiin ilmestyi levy, johon oli asennettu lisää käyttäjätietoja.
- Joku sotki jatkuvasti järjestelmäyksiköiden riippuvuuksia ja CoreOS jumiutui uudelleenkäynnistyksen yhteydessä. Tätä oli vaikea saada kiinni CoreOS:n käytettävissä olevilla työkaluilla.
- Salaisuuksien hallinta.
- CM:ää ei ollut. CoreOS:lle oli bash- ja YML-konfiguraatioita.
VM-määrityksen käyttöönotto edellyttää, että se käynnistetään uudelleen, mutta se ei välttämättä käynnisty uudelleen. Vaikuttaa ilmeiseltä ongelmalta, mutta pysyviä levyjä ei ole - lokeja ei ole minnekään tallentaa. No, ok, yritetään lisätä ytimen latausvaihtoehto, jotta lokit lähetetään. Mutta ei, kuinka monimutkaista kaikki on.
Päivä 0: Tunnista ongelma
Se oli tavallinen kehitysinfrastruktuuri: jenkinit, testiympäristöt, valvonta, rekisteri. CoreOS on suunniteltu k8s-klustereiden isännöintiin, ts. Ongelmana oli CoreOS:n käyttö. Ensimmäinen askel oli pinon valinta. Päätimme:
- CentOS perusjakaumana, koska Tämä on tuotantoympäristöjä lähinnä oleva jakelu.
- Ansible kokoonpanon hallintaan, koska siitä tehtiin laaja tutkimus.
- Jenkins puitteet olemassa olevien prosessien automatisoinnille, koska sitä on jo käytetty aktiivisesti kehitysprosesseissa
- Hyper-V virtualisointialustana. On useita syitä, jotka ylittävät tarinan, mutta lyhyesti sanottuna - emme voi käyttää pilviä, meidän on käytettävä omaa laitteistoamme.
Päivä nro 30: Nykyisten sopimusten korjaaminen - Sopimukset koodina
Kun pino oli selvä, aloitettiin valmistelut siirtoon. olemassa olevien sopimusten korjaaminen koodin muodossa (Sopimukset koodina!). Siirtyminen ruumiillinen työ -> koneellistaminen -> automaatio.
1. Määritä virtuaalikoneet
Ansible tekee hyvää työtä tässä. Vähimmäisillä kehon liikkeillä voit hallita VM-kokoonpanoja:
- Luo git-arkisto.
- Laitamme luettelon virtuaalikoneista inventaarioon, kokoonpanot leikkikirjoihin ja rooleihin.
- Olemme perustamassa erityisen jenkins-orjan, josta voit käyttää Ansiblea.
- Luomme työpaikan ja määritämme Jenkinsin.
Ensimmäinen prosessi on valmis. Sopimukset ovat kiinteät.
2. Luo uusi VM
Kaikki täällä ei ollut kovin kätevää. Ei ole kovin kätevää luoda virtuaalikoneita Hyper-V:lle Linuxista. Yksi yrityksistä koneistaa tämä prosessi oli:
- Ansbile muodostaa yhteyden WinRM:n kautta Windows-isäntään.
- Ansible suorittaa powershell-skriptin.
- Powershell-skripti luo uuden virtuaalikoneen.
- Hyper-V/ScVMM:ää käytettäessä isäntänimi määritetään luotaessa virtuaalikonetta vieraskäyttöjärjestelmässä.
- Kun päivität DHCP-vuokrasopimusta, VM lähettää isäntänimensä.
- Normaali ddns- ja dhcp-integraatio Domain Controller -puolella määrittää DNS-tietueen.
- Voit lisätä VM:n varastoosi ja määrittää sen Ansiblen avulla.
3. Luo VM-malli
He eivät keksineet täällä mitään - he ottivat pakkaajan.
- Lisää pakkaaja, kickstart config git-arkistoon.
- Erityisen jenkins-orjan asettaminen hyper-v:n ja Packerin kanssa.
- Luomme työpaikan ja määritämme Jenkinsin.
Kuinka tämä linkki toimii:
- Packer luo tyhjän VM:n ja poimii ISO:n.
- Virtuaalinen kone käynnistyy, Packer antaa komennon käynnistyslataimeen käyttääkseen kickstart-tiedostoamme levykkeeltä tai http.
- Anaconda käynnistetään konfiguraatiollamme ja käyttöjärjestelmän alkuasetukset on tehty.
- Packer odottaa, että VM tulee saataville.
- Virtuaalikoneen sisällä oleva Packer toimii paikallisessa tilassa.
- Ansible käyttää täsmälleen samoja rooleja, joita se toimii vaiheessa #1.
- Packer vie VM-mallin.
Päivä #75: Refaktoroi sopimus rikkomatta = Testattavissa + Testkitchen
Konventojen kaappaaminen koodiin ei välttämättä riitä. Loppujen lopuksi, jos prosessin läpikotaisin haluat muuttaa jotain, voit rikkoa jotain. Siksi infrastruktuurin tapauksessa ilmenee juuri tämän infrastruktuurin testaus. Synkronoidaksemme tiedon tiimin sisällä aloimme testata Ansible-rooleja. En mene syvemmälle, koska... siellä on artikkeli, joka kuvaa sen ajan tapahtumia (spoileri tämä ei ollut lopullinen versio ja myöhemmin kaikki muuttui monimutkaisemmaksi ).
Päivä #130: Ehkä CentOS+ansible ei ole tarpeen? ehkä openshift?
Meidän on ymmärrettävä, että infrastruktuurin käyttöönottoprosessi ei ollut ainoa, vaan sivuprojekteja oli. Esimerkiksi tuli pyyntö käynnistää sovelluksemme openshiftissä ja tämä johti yli viikon kestäneeseen tutkimukseen mikä hidasti siirtoprosessia. Tuloksena kävi ilmi, että openshift ei kata kaikkia tarpeita, vaan tarvitaan todellista laitteistoa tai ainakin kykyä pelata ytimellä.
Päivä #170: Openshift ei sovellu, otetaanko mahdollisuus Windows Azure Packin kanssa?
Hyper-V ei ole kovin ystävällinen, SCVMM ei tee siitä paljon parempaa. Mutta on olemassa sellainen asia kuin Windows Azure Pack, joka on SCVMM:n lisäosa ja jäljittelee Azurea. Mutta todellisuudessa tuote näyttää hylätyltä: dokumentaatiossa on rikkinäisiä linkkejä ja se on erittäin niukkaa. Mutta osana tutkimusta vaihtoehtoista pilvemme käyttöiän yksinkertaistamiseksi he tarkastelivat myös sitä.
Päivä #250: Windows Azure Pack ei ole kovin hyvä. Pysymme SCVMM:ssä
Windows Azure Pack vaikutti lupaavalta, mutta WAP:ia monimutkaistuksineen päätettiin olla tuomatta järjestelmään tarpeettomien ominaisuuksien vuoksi ja pysyttiin SCVMM:ssä.
Päivä #360: Elefantin syöminen pala palalta
Vasta vuoden kuluttua muuttoalusta oli valmis ja muuttoprosessi alkoi. Tätä tarkoitusta varten asetettiin SMART-tehtävä. Tarkistimme kaikki VM:t ja aloimme selvittää kokoonpanoa yksitellen, kuvata sitä Ansiblessa ja peittää sen testeillä.
Päivä #450: Millaisen järjestelmän sait?
Itse prosessi ei ole mielenkiintoinen. Se on rutiinia, voidaan todeta, että useimmat konfiguraatiot olivat suhteellisen yksinkertaisia tai isomorfisia ja Pareto-periaatteen mukaan 80% VM-konfiguraatioista vaati 20% ajasta. Samalla periaatteella 80 % ajasta käytettiin muuton valmisteluun ja vain 20 % itse muuttoon.
Päivä #540: Finaali
Mitä tapahtui 18 kuukaudessa?
- Sopimuksista tuli koodi.
- Ruumiillinen työ -> Mekanisointi -> automaatio.
Linkit
Lähde: will.com