Dans le processus, l'idée est venue d'automatiser la livraison de scripts PowerShell, ainsi que de synchroniser le travail d'équipe entre les administrateurs système avec les scripts s'exécutant sur différents serveurs. L'article est conçu pour les administrateurs de Win simples qui ne connaissent pas git, gitlab, ci / cd et d'autres problèmes de devops, donc si vous êtes intéressé, demandez cat.
Commençons par les problèmes qui se sont posés lors du travail
- manque de versioning;
- incohérence entre collègues lors de la finalisation des scripts;
- perte de scripts utiles lorsque des collègues partent;
- livraison manuelle des scripts sur les lieux de leur exécution;
- désordre banal.
Tous ces problèmes sont en fait petits dans des cas isolés, mais quand tout cela est déjà à l'échelle de l'équipe et des tas de scripts, je voudrais mettre les choses en ordre.
Pour simplifier ma vie, j'ai utilisé le merveilleux produit Gitlab, déjà déployé avec nous et utilisé par les encodeurs. Je ne considérerai pas
le processus d'installation de gitlab et
gitlab-runner , je vais juste préciser que nous avons déjà un
gitlab configuré
avec une autorisation de domaine et un runner windows séparé avec l'
exécutant powershell , qui effectuera nos tâches de déploiement. Pour les scripts, j'utilise l'excellent
code Visual Studio .
Nous organisons le travail dans gitlab
Alors voilà, pour commencer, nous devons créer un groupe dans gitlab, qui comprendra tous nos administrateurs système.
Ensuite, nous ajoutons nos collègues aux membres disposant de droits de développeur et vous pouvez commencer à créer un projet. Nous créons le projet dans notre groupe, afin que nos collègues y aient automatiquement accès.
Après avoir créé le projet, sur la première page, il y aura tous les conseils sur le sujet "que faire ensuite". Dans notre cas, nous devons démarrer les fichiers existants à partir de notre poste de travail dans gitlab. Par exemple, tout cela se trouve dans le répertoire "E: \ scripts \ powershellmegaproject". Utilisez l'invite appropriée et exécutez sur votre ordinateur:
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! Tous nos fichiers du répertoire "E: \ scripts \ powershellmegaproject" sont maintenant dans notre projet.
Et ensuite? Ouvrez VSCode et essayez d'apporter des modifications à notre script PowerShell situé dans ce répertoire. Après avoir enregistré le fichier, nous verrons une notification dans la section Contrôle de source, où vous pourrez voir les modifications et effectuer un commit. Ensuite, nous poussons vers le serveur:
Vérifions sur le site Web du projet dans gitlab, le contenu réel des fichiers sera là, et dans l'historique des commits, vous pouvez suivre les changements.
Configuration CI / CD
Il est temps de configurer la livraison des scripts au serveur. Pour que CI / CD fonctionne, un coureur doit être disponible pour votre projet. Vous pouvez l'attribuer dans l'admin gitlab - runners, ou utiliser des coureurs partagés.
Et maintenant au projet. Pour que CI / CD fonctionne, vous devez créer un fichier .gitlab-ci.yml avec une description des actions dans le répertoire de notre projet (un conseil et une aide à ce sujet peuvent également être vus en allant dans le menu gitlab - CI / CD - Pipelines). Vous pouvez choisir différentes méthodes de livraison de fichiers, de la simple copie de fichiers à rsync ou git pull vers le serveur souhaité. Puisque nous envisageons le scénario le plus simple, il ne fera que copier PowerShell. Pour ce faire, vous devez rendre le dossier sur le serveur cible avec le script accessible au public sur le réseau et fournir un accès de modification à l'utilisateur sous lequel notre service gitlab-runner s'exécute.
Remplissez .gitlab-ci.yml avec un contenu simple:
deploy_stage: variables: DEST_DIR: \\srv-megaserver\scripts\powershellmegaproject script: - remove-item -path $DEST_DIR\* -recurse - gci -Recurse | Copy-Item -Destination $DEST_DIR
Ici, nous écrivons le chemin de notre répertoire dans une variable (dans d'autres projets, vous pouvez simplement copier ce fichier et changer le répertoire de destination) et avec une simple commande powershell, nous supprimons d'abord tout le contenu du répertoire, puis copions tout de notre projet dans ce dossier.
Validez, appuyez sur les modifications et vérifiez. Dans notre dossier sur le serveur, tous les fichiers doivent être mis à jour. Vous pouvez voir l'état et l'exécution de Pipeline dans la même section de nos pipelines gitlab - ci / cd -, un exemple de réussite de l'exécution:
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
Supposons que sur ce serveur une tâche a déjà été configurée pour exécuter ce script à partir d'un projet dans le planificateur, par conséquent, nous obtenons toujours l'exécution des fichiers de projet réels.Quoi de neuf avec des collègues?
C'est simple, créez un dossier pour les projets, allez-y en ps / cmd et clonez le projet à nous-mêmes.
cd e:\projects git clone http://gitlab.domain.net/sysadminsdev/powershellmegaproject.git
Tout, puis juste travailler dans VSCode en ouvrant le dossier, en faisant des commits et en poussant.
Qu'avons-nous réalisé en conséquence?
- tous les scripts sont stockés dans le référentiel;
- l'ensemble du groupe d'administration peut travailler avec des scripts;
- tous les changements sont visibles dans l'histoire;
- tout administrateur nouvellement créé voit immédiatement tous les développements et il n'a pas besoin de courir autour des serveurs et de découvrir "où-ce qui est fait";
- tous les changements productifs sont automatiquement livrés au "lieu de travail productif".
Nous avons éliminé tous nos problèmes et simplifié considérablement notre vie d'équipe.
Bonus
Ajoutez le fichier README.md au répertoire du projet pour décrire ce qui se passe dans ces scripts.
Ajoutez un fichier Changelog pour décrire les modifications.
ps: que pouvez-vous faire d'autre? Vous pouvez tordre runner dans docker, vous pouvez configurer le planificateur dans ansible , vous pouvez toujours faire beaucoup de choses plus compliquées, mais le but de l'article était de simplifier la compréhension de cette boîte à outils pour les débutants.