GIT

Versionskontrolle und Teamwork

Pygit installieren

apt install libgit2-dev
salt-pip install pygit2==1.6.1 --no-deps

Seit Version 3006 verwendet Salt nicht mehr die Pytoninstallation des Betriebssystems. Im Ordner /opt/saltstack/salt/lib/ verwaltet Salt seine eigene Pythonversion. Deshalb müssen Sie die für den Salt-Master benötigte Python-Erweiterung mit dem Kommando salt-pip installieren.

Schlüssel erzeugen

mkdir /etc/salt/git.keys.d 
ssh-keygen -N "" -t ecdsa -C "master@salt" \
-f /etc/salt/git.keys.d/master
chmod 0600 /etc/salt/git.keys.d/master

Verwenden Sie edsa-Keys und nicht ed25519.

Master mit Git verbinden

/etc/salt/master.d/git.conf

fileserver_backend:
  - gitfs

gitfs_remotes:
  - git@(bitbucket.org|github.com):<USERNAME>/<REPO>.git:
    - privkey: /etc/salt/git.keys.d/master
    - pubkey: /etc/salt/git.keys.d/master.pub 
    - root: states     # use subfolder
    - base: <BRANCH>   # set the branch

Hinterlegen Sie den Public Key im Git-Server, wenn möglich, als Read-only -Zugang.

Bei Bitbucket werden Read-only Zugänge über Access-Keys pro Repository verwaltet.

In GitHub hinterlegen Sie den öffentlichen Schlüssel als sogenannten Deploy Key. Dazu klicken Sie innerhalb des Repositorys auf Settings, und dann auf der linken Seite auf Deploy Keys. Oben rechts finden Sie dann den Knopf Add Deploy Key. Fügen Sie per Copy & Paste den Inhalt von /etc/salt/git.keys.d/master.pub ein.

Bitbucket Read-Only-Zugang

Deploy Keys bei GitHub

Mit dem Kommando salt-run fileserver.file_list kontrollieren Sie, ob die States aus dem Git-Repository verfügbar sind.

Warten bitte! Änderungen stehen erst einige Sekunden nach einem Commit auf dem Salt-Master zur Verfügung. Ungeduldige können mit salt-run fileserver.update ein Update erzwingen.

Sollten die in Git gespeicherten States im Salt-Master nicht verfügbar sein, prüfen Sie, ob die SSH-Keys korrekt funktionieren.

cd /tmp
GIT_SSH_COMMAND='ssh -i /etc/salt/git.keys.d/master -o IdentitiesOnly=yes' \
git clone <YOUR-GIT-URL>

Pillars per Git

Ergänzen Sie die ggf. schon existierende Konfiguration der sogenannten ext_pillar.

/etc/salt/master.d/ext_pillar.conf

ext_pillar:
  - git:
    - git@(bitbucket.org|github.com):<USERNAME>/<REPO>.git:
      - privkey: /etc/salt/git.keys.d/master
      - pubkey: /etc/salt/git.keys.d/master.pub 
      - root: pillar

ext_pillar sind immer eine Ergänzung zu den Standard-Pillars. Wenn Pillars per Git verwaltet werden, sind Pillar im lokalen Dateisystem des Master ebenfalls aktiv. Wenn Sie Pillars ausschließlich per Git verwalten möchten, löschen Sie den Ordner /srv/pillar.

Pillars, welche in einem Git-Repository liegen, brauchen ebenfalls eine top.sls über die alle Pillar-Dateien inkludiert und Minions zugewiesen werden.

Pillars vom Type file_tree können (noch) nicht in Git speichert werden.

Workflow

Nutzen Sie z.B. Forks oder Branches, damit jeder Mitarbeiter sein eigenes Repository mit States und Pillars zur Verfügung hat, um neue Konfigurationen zu erarbeiten und zu testen.

Jeder Mitarbeiter sollte über seinen eigenen lokalen Salt-Master verfügen, der an seinem persönlichen Fork "hängt". Nachdem neue States oder Pillars auf einem Fork getestet wurden, stellt der Mitarbeiter einen Pull-Request, damit die Änderungen in das produktive Master-Repository übernommen werden.