В процессе работы появилась идея автоматизировать доставку powershell скриптов, а также синхронизировать работу в команде среди системных администраторов со скриптами выполняемыми на разных серверах. Статья рассчитана на простых win администраторов незнакомых глубоко с git, gitlab, ci/cd и прочими devops заморочками, поэтому если интересно прошу под кат.

Начнем с проблем которые возникали при работе

• отсутствие версионности;
• несогласованность между коллегами при доработке скриптов;
• потеря полезных скриптов при уходе коллег;
• ручная доставка скриптов в места их выполнения;
• банальный бардак.

Все эти проблемы на самом деле мелочны в единичных случаях, но когда все это уже находится в масштабах команды и кучи скриптов, то хотелось бы навести в этом порядок.

Для упрощения жизни я использовал замечательный продукт Gitlab, уже развернутый у нас и используемый кодерами. Я не буду рассматривать процесс установки gitlab и gitlab-runner, просто уточню что у нас уже есть настроенный gitlab с доменной авторизацией и отдельный runner на windows с powershell executor, который и будет выполнять наши задачи развертывания. Для написания скриптов я использую отличный Visual Studio Code.

Организуем работу в gitlab

И так приступим, для начала нам необходимо сделать группу в gitlab, в которую войдут все наши системные администраторы.


Далее добавим наших коллег в Members с правами Developer и можно приступать к созданию проекта. Проект обязательно создаем в нашей группе, что бы к нему автоматически получили доступ наши коллеги.


После создания проекта, на первой же страничке будут все подсказки на тему «что делать дальше». В нашем случае нужно запушить существующие файлы со своей рабочей станции в gitlab. Для примера все это лежит в каталоге «E:\scripts\powershellmegaproject». Воспользуемся соответствующей подсказкой и выполним на своем компьютере:

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

Бинго! Все наши файлики из каталога «E:\scripts\powershellmegaproject» теперь в нашем проекте.

Что дальше? Откроем VSCode и попробуем внести изменения в наш powershell скрипт, находящийся в этом каталоге. Сохранив файл, мы увидим в разделе «Source Control» уведомление, где можно посмотреть изменения и сделать коммит. Далее делаем пуш на сервер:


Проверим на сайте проекта в gitlab, там будет актуальное содержимое файлов, а в истории коммитов можно отследить изменения.

Настройка CI/CD

Пора настроить доставку скриптов на сервер. Для работы CI/CD для вашего проекта должен быть доступен runner. Назначить его можно в админке gitlab — runners, либо использовать shared runner`ы.

А теперь к проекту. Что бы CI/CD заработало необходимо создать в каталоге с нашим проектом файл .gitlab-ci.yml с описанием действий (подсказку и help об этом можно так же увидеть при переходе в меню gitlab — CI/CD — Pipelines). Для доставки файлов можно выбрать различные способы, от просто копирования файлов, до rsync или git pull на нужный сервер. Так как мы рассматриваем самый простой сценарий, то будет просто копирование powershell`ом. Для этого необходимо сделать папку на целевом сервере со скриптом общедоступной в сети и предоставить доступ на изменение пользователю под которым запущена наша служба gitlab-runner.

Заполним .gitlab-ci.yml простым содержимым:

deploy_stage:
  variables:
    DEST_DIR: \\srv-megaserver\scripts\powershellmegaproject
  script:
    - remove-item -path $DEST_DIR\* -recurse
    - gci -Recurse | Copy-Item -Destination $DEST_DIR

Тут мы запишем в переменную путь до нашего каталога (в других проектах можно просто копировать этот файл и менять целевой каталог) и простой powershell командой сначала удалим все содержимое каталога, а потом скопируем все из нашего проекта в эту папку.

Коммитим, пушим изменения и проверяем. В нашей папке на сервере должны обновится все файлы. Посмотреть статус и выполнение Pipeline можно в том же разделе нашего gitlab — ci/cd — pipelines, пример успешного выполнения:

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

Допустим на этом сервере уже настроено задание на выполнение этого скрипта из проекта в планировщике, как итог мы всегда получаем выполнение актуальных файлов проектов.

Что с коллегами?

Все просто, создаем папку для проектов, переходим в неё в ps/cmd и клонируем проект к себе.

cd e:\projects
git clone http://gitlab.domain.net/sysadminsdev/powershellmegaproject.git

Всё, дальше просто работаем в VSCode открыв папку, делая коммиты и пуши.

Чего мы добились в итоге

• все скрипты у нас хранятся в репозитарии;
• вся группа администрирования может работать со скриптами;
• все изменения видны в истории;
• любой новоиспеченный администратор сразу видит все наработки и ему не нужно бегать по серверам и узнавать «где-что выполняется»;
• все продуктивные изменения автоматически доставляются на «продуктивное место работы».

Мы устранили все наши проблемы, а также значительно упростили нашу жизнь в команде.

Бонусом

Добавьте файл README.md в каталог с проектом для описания что в этих скриптах вообще происходит.
Добавьте файл Changelog для описания изменений.

ps: что можно еще? Можно крутить runner в docker, можно конфигурить scheduler в ansible, можно еще много чего и по сложней, но целью статьи было упростить понимание данного инструментария для новичков.