Dabei kam die Idee auf, die Bereitstellung von Powershell-Skripten zu automatisieren und die Teamarbeit zwischen Systemadministratoren mit Skripten zu synchronisieren, die auf verschiedenen Servern ausgeführt werden. Der Artikel richtet sich an einfache Win-Administratoren, die mit Git-, Gitlab-, CD- / CD- und anderen Entwicklerproblemen nicht vertraut sind. Wenn Sie also interessiert sind, fragen Sie bitte unter cat.
Beginnen wir mit den Problemen, die bei der Arbeit aufgetreten sind
- fehlende Versionierung;
- Inkonsistenz zwischen Kollegen beim Finalisieren von Skripten;
- Verlust nützlicher Skripte, wenn Kollegen gehen;
- manuelle Lieferung von Skripten an Orte ihrer Ausführung;
- banales Durcheinander.
All diese Probleme sind in Einzelfällen eigentlich klein, aber wenn all dies bereits auf der Skala des Teams und einer Vielzahl von Skripten liegt, möchte ich die Dinge in Ordnung bringen.
Um mein Leben zu vereinfachen, habe ich das wunderbare Gitlab-Produkt verwendet, das bereits bei uns bereitgestellt und von Encodern verwendet wurde. Ich werde
den Installationsprozess von Gitlab und
Gitlab-Runner nicht berücksichtigen.
Ich möchte nur klarstellen, dass wir bereits ein konfiguriertes
Gitlab mit Domänenautorisierung und einen separaten Windows-Runner mit dem
Powershell-Executor haben , der unsere Bereitstellungsaufgaben ausführt. Für die Skripterstellung verwende ich den hervorragenden
Visual Studio-Code .
Wir organisieren die Arbeit in Gitlab
Also los geht's, für den Anfang müssen wir eine Gruppe in gitlab bilden, die alle unsere Systemadministratoren umfasst.
Fügen Sie als Nächstes unsere Kollegen zu Mitgliedern mit Entwicklerrechten hinzu, und Sie können mit der Erstellung des Projekts beginnen. Wir erstellen das Projekt in unserer Gruppe, damit unsere Kollegen automatisch darauf zugreifen können.
Nach dem Erstellen des Projekts finden Sie auf der ersten Seite alle Tipps zum Thema "Was ist als Nächstes zu tun?". In unserem Fall müssen wir vorhandene Dateien von unserer Workstation in gitlab starten. All dies liegt beispielsweise im Verzeichnis "E: \ scripts \ Powershellmegaproject". Verwenden Sie die entsprechende Eingabeaufforderung und führen Sie sie auf Ihrem Computer aus:
cd E:\scripts\powershellmegaproject git init git remote add origin http://gitlab.domain.net/sysadminsdev/powershellmegaproject.git git add . git commit -m "Initial commit" git push -u origin master
Bingo! Alle unsere Dateien aus dem Verzeichnis "E: \ scripts \ Powershellmegaproject" befinden sich jetzt in unserem Projekt.
Was weiter? Öffnen Sie VSCode und versuchen Sie, Änderungen an unserem Powershell-Skript in diesem Verzeichnis vorzunehmen. Nachdem Sie die Datei gespeichert haben, wird im Abschnitt Quellcodeverwaltung eine Benachrichtigung angezeigt, in der Sie die Änderungen anzeigen und ein Commit durchführen können. Als nächstes pushen wir zum Server:
Lassen Sie uns auf der Projektwebsite in gitlab nachsehen, ob der eigentliche Inhalt der Dateien vorhanden ist und ob Sie in der Historie der Commits die Änderungen verfolgen können.
CI / CD-Setup
Es ist Zeit, die Übermittlung von Skripten an den Server zu konfigurieren. Damit CI / CD funktioniert, muss ein Runner für Ihr Projekt verfügbar sein. Sie können es in den Admin-Gitlab-Läufern zuweisen oder gemeinsam genutzte Läufer verwenden.
Und jetzt zum Projekt. Damit CI / CD funktioniert, müssen Sie eine .gitlab-ci.yml-Datei mit einer Beschreibung der Aktionen im Verzeichnis unseres Projekts erstellen (ein Hinweis und eine Hilfe dazu finden Sie auch im Menü gitlab - CI / CD - Pipelines). Sie können verschiedene Methoden für die Übermittlung von Dateien auswählen, z. B. das Kopieren von Dateien nach rsync oder git pull auf den gewünschten Server. Da wir das einfachste Szenario betrachten, wird nur Powershell kopiert. Machen Sie dazu den Ordner auf dem Zielserver mit dem Skript im Netzwerk öffentlich verfügbar und gewähren Sie dem Benutzer, unter dem unser Gitlab-Runner-Dienst ausgeführt wird, Änderungszugriff.
Füllen Sie .gitlab-ci.yml mit einfachem Inhalt:
deploy_stage: variables: DEST_DIR: \\srv-megaserver\scripts\powershellmegaproject script: - remove-item -path $DEST_DIR\* -recurse - gci -Recurse | Copy-Item -Destination $DEST_DIR
Hier schreiben wir den Pfad zu unserem Verzeichnis in eine Variable (in anderen Projekten können Sie diese Datei einfach kopieren und das Zielverzeichnis ändern) und löschen mit einem einfachen Powershell-Befehl zuerst den gesamten Inhalt des Verzeichnisses und kopieren dann alles aus unserem Projekt in diesen Ordner.
Festschreiben, Änderungen vornehmen und prüfen. In unserem Ordner auf dem Server sollten alle Dateien aktualisiert werden. Sie können den Status und die Ausführung der Pipeline im selben Abschnitt unserer gitlab - ci / cd - Pipelines sehen, ein Beispiel für eine erfolgreiche Ausführung:
Running with gitlab-runner 11.3.1~beta.4.g0aa5179e (0aa5179e) on gl-runner2-windows a24eda81 Using Shell executor... Running on SRV-GL-RUNNER2... Fetching changes... HEAD is now at e6e9a2c update ci file From http://gitlab.domain.net/sysadminsdev/powershellmegaproject e6e9a2c..5f5cfce master -> origin/master Checking out 5f5cfceb as master... Skipping Git submodules setup $ remove-item -path $DEST_DIR\* -recurse $ gci -Recurse | Copy-Item -Destination $DEST_DIR Job succeeded
Angenommen, auf diesem Server wurde bereits eine Aufgabe konfiguriert, um dieses Skript von einem Projekt im Scheduler aus auszuführen. Dadurch erhalten wir immer die Ausführung der tatsächlichen Projektdateien.Was ist mit Kollegen los?
Es ist ganz einfach: Erstellen Sie einen Ordner für Projekte, rufen Sie ihn in ps / cmd auf und klonen Sie das Projekt für uns.
cd e:\projects git clone http://gitlab.domain.net/sysadminsdev/powershellmegaproject.git
Alles, dann arbeiten Sie einfach in VSCode, indem Sie den Ordner öffnen, Festschreibungen vornehmen und Pushs ausführen.
Was haben wir dadurch erreicht?
- Alle Skripte werden im Repository gespeichert.
- Die gesamte Administrationsgruppe kann mit Skripten arbeiten.
- Alle Änderungen sind in der Geschichte sichtbar.
- Jeder neu erstellte Administrator sieht sofort alle Entwicklungen und muss nicht auf den Servern herumlaufen und herausfinden, wo was getan wird.
- Alle produktiven Änderungen werden automatisch an den "produktiven Arbeitsplatz" geliefert.
Wir haben alle unsere Probleme beseitigt und unser Leben als Team erheblich vereinfacht.
Bonus
Fügen Sie die Datei README.md zum Projektverzeichnis hinzu, um zu beschreiben, was in diesen Skripten geschieht.
Fügen Sie eine Changelog-Datei hinzu, um die Änderungen zu beschreiben.
ps: was kannst du noch tun Sie können Runner in Docker drehen, Sie können Scheduler in Ansible konfigurieren , Sie können noch viele Dinge komplizierter machen, aber der Zweck des Artikels war es, das Verständnis dieses Toolkits für Anfänger zu vereinfachen.