Git, v2, eiku v3 ja huomiot.

Tämän viikon raportissa käymme vähän läpi versionhallintaa, miksi se on tärkeää ja pikaisesti myös miten sitä voidaan käyttää hyödyksi palvelinten hallinnassa.

Lyhyesti: Versionhallinta on yksi ohjelmistokehityksen ja järjestelmänhallinnan kulmakivistä. Sen sijaan, että tiedostoja kopioitaisiin käsin nimillä kuten config_vanha, config_vielä_vanhempi ja config_toimiva_v2, versionhallintajärjestelmä pitää kirjaa kaikista tehdyistä muutoksista: kuka teki muutoksia ja milloin teki. Tämä toimii kuten aikakone joka mahdollistaa paluun mihin tahansa aiempaan pisteeseen - esimerkiksi, eikä vähintään - jos jotain menee rikki.

Git on nimenomaan yksi tärkeimmistä tällaisista. Se on hajautettu versionhallintatyökalu, joka ei tallenna vain tiedostojen eroja, vaan kokonaisia tilannekuvia (snapshots) projektista jokaiseen tallennuspisteeseen (commit).

Infran koodaamisen näkökulmasta Git on korvaamaton. Aiemmissa raporteissa olemme kirjoittaneet Salt-tiloja, kuten init.sls- ja top.sls-tiedostoja jotka määrittelleet haluttuja tiloja. Kun nämä määritystiedostot tallennetaan Gitiin: saamme täydellisen historian kaikista infraan tehdyistä muutoksista. Jos uusi muutos aiheuttaa ongelmia - voimme välittömästi palata edelliseen toimivaan versioon. Tämä tuo järjestelmänhallintaan erityisesti kurinalaisuutta jota tarvitaan kaikessa (oikeasti aivan kaikessa) tekemisessä (oma mielipide) Samalla tämä tukee Saltin perusajatusta idempotenssista: tilan varmistamisesta.

Olen pitkään tehnyt omassa verkossani git-toimintaa soft-serven kautta, mutta nyt vasta tämän raportin kirjoituksessa tajusin: GIT on vain yksinkertainen binääri joka ei paljoa eroa SSHn toimintaperiaatteesta.

Eli tällä viikolla teen gitillä mahdollisimman yksinkertaisen repon: kahden koneen välille. Tällä itsekin opin yksinkertaisen ja erittäin tärkeän työkalun hallintaa. Github/softserve sikseen (nämä helppo ottaa mukaan jos niille tarvetta).

Kaksi konetta - yksi synkkaus.

Eli teen kaliin (valas) repon ja työnnän versiot sinne macbookiltani. Tutkin gitin referenssejä ja luon kalissa luomaani projektikansioon (salt-projekti.git) --bare komennolla pohjan. Bare-varasto sisältää vain Gitin versionhallintadatan eli ei lainkaan työkopioita tiedostoista. Se on tarkoitettu vain paikaksi, johon muutoksia voidaan puskea ja josta niitä voidaan hakea.

Tässä myös HUOM! En yhtään muista pitikö git asentaa mäkille brewillä. Itselläni ollut aikaisemmin jo käytössä - eli jos ei löydy pohjalta niin brew on kaveri

git init --bare

Mäkillä kloonaan tiedostot sshn yli itselleni. Huomaa, että tässä minulla on jo toteutettu avaimet koneiden välillä julkisen avaimen periaatteella. Eli mäkilläni ’valas’ on määritelty käyttämään avainta ja yhdistämään tiettyyn koneeseen.

git clone henry@valas:~/salt-projekti.git

Nyt voin työstää mitä tahansa kansion sisällä. Teen yksinkertaisen readme tiedoston sisälle.

Asetan myös käyttäjänimen ja sähköpostin koneiden välille GIT repoon. Nyt EN käytä --global merkkiä, koska teen vain tähän projektiin testinä. Globaalina käyttäisin näitä kaikissa mäkkini git repoissa.

git config user.name ”henry-kalin-masterkäyttäjä”
git config user.email ”henry@hopsu”

Protip: ilman globaalia nämä tallentuvat kansion .git/config tiedostoon

Porkkanaesimerkki ja syödään porkkana!

Tehdään siis ensimmäinen lähetys koneiden välillä. Jos kyseessä olisi yhteistyöprojekti, pitäisi ensimmäisenä vetää projekti palvelimelta ennen lähetystä. Täten muiden muutokset tulevat sinun muutoksiin mukaan. Nyt voidaan vain

git add .
# Tässä käydään kansio ja sen alihakemistot muutoksista ja merkitään rekisteriin.

git commit -m "Tässä ensimmäinen lähetys"
# Luodaan uusi tallennuspiste -m viestillä. 

git push
# Tehdään vertaukset vanhoihin, annetaan tälle lähetykselle sormenjälki, annetaan metatiedot ja tallennetaan viesti. 

Vertaan myös valaasta mitä vastaanotettu.

Tämä ei näytä miltään (koska loimme --bare varaston). Teen myös uuden git haun valaan sisällä /tmp kansioon.

cd /tmp
git clone /home/henry/salt-projekti.git testiklooni
# testiklooni kansio väliaikaiskansioon

Ja siellähän nuo! Eli repo on pystyssä.

*#”€”#%”% (kirosanoja)

Eli teen mäkillä huonot muutokset repoon. Haluan palauttaa ensin ilman committia muutokset takaisin.

git reset --hard

Palauttaa takaisin viimeisimpään. HUOM! Oikeasti poistaa muutokset!

Commitin jälkeen

git log --oneline
# Näyttää siistinä committien hashit

git reset --hard HASHnro
# Tuo sen lähetyksen versiot sisään. HUOM poistaa muut muutokset!

TAI

git revert HASHnro
# Tämä palauttaa koko repon edelliseen turvalliseen.

Logeista nähdään myös muutokset.

Saltin kanssa

Eli nyt voimme luoda projektille vaikka edellisviikkojen btop projektin (asennetaan btop). Luon salt-tilan ’btop/init.sls’

srv/salt/btop/init.sls
btop-paketti:
  pkg.installed:
    - name: btop

Lähetän palvelimelle ja testaan toimivuuden.

Tällä saamme synkattua gitistä salt-toiminnan!

Kommentit

Tein itsekin liian pitkään töitä soft-servellä tjms, kun en ymmärtänyt, että GIT on vain yksinkertainen työkalu. Jo pelkästään github antaa sellaisen vaikutelman.

Todellisuudessa git on TODELLA hyvä ihan vain yksinkertaisesti kahden koneen synkronointiin. Tästä helppo jatkaa ja laajentaa repoa joko omassa infrassa laajemmin (esim soft-serve) tai ulkopuolisiin repoihin maailmalle.

Lähteet

Soft-serve https://github.com/charmbracelet/soft-serve

GIT docs https://git-scm.com/docs

Avaimista https://fi.wikipedia.org/wiki/Julkisen_avaimen_salaus

Brew git https://formulae.brew.sh/formula/git

Kuvat optimoitu https://optimage.app

Käytetty aika tähän raporttiin: 2h (mutta taustalla kymmeniä ja kymmeniä tunteja gitin parissa muuten)