Однажды подслушано:

— А… А что мы сейчас делаем?

— Деплой приложения.

— А что такое деплой?

— Деплой… Ну это деплой, что тут не понятного?

И действительно, для тех, кто в “теме”, все очевидно - берем приложение на Python, заворачиваем в Docker, кладем в GitLab, выкатываем через CI/CD в Кubernetes. Но тем, кто только учится, с таким обилием незнакомых технологий, приходится нелегко. Можно сравнить с катанием на сноуборде - пока “голова” и “тело” не освоят сразу несколько неочевидных навыков - вдоволь “наваляешься”:) Поэтому, и в сноуборде, и в любом другом виде спорта есть “подводящие” упражнения и я хочу предложить сегодня одно из таких.

В этой статье я буду отталкиваться от бытующего мнения, что в “девопсы” чаще всего идут системные администраторы, поэтому, вместо программы на Python возьмём какой-нибудь популярный сервис, например proxy Squid, поместим его конфигурацию в GitLab и настроим CI/CD тестирование и применение изменений конфигурации на сервере. Чтобы руководство было максимально воспроизводимым, опишу все необходимые шаги для развертывания стенда в домашних условиях с использованием виртуальной машины (VM) в VirtualBox.

Шаг 1. Развертывание VM

Скачайте и установите VirtualBox:

https://www.virtualbox.org/wiki/Downloads

Создайте VM, подключив к ней образ дистрибутива, например:

https://www.debian.org/download

Или, можно воспользоваться готовым образом, например моим:

https://val.bmstu.ru/unix/img/My%20Documents/debian_11.1_64_01.ova

В настройках системы назначьте не менее 4096 МБ основной памяти (4GB RAM), подключите сетевой адаптер “мостом” к сетевой карте Вашего компьютера (хост системы), и запустите VM.

Проведите инсталляцию системы, в большинстве экранов можно оставить значения по умолчанию (GUI не обязателен) установите сервис SSH. Можно оставить вариант автоматического (через сервис DHCP) назначения ip параметров. После финальной перезагрузки, подключитесь к консоли системы и узнайте назначенный ей ip адрес командой:

ip a

Если используете мой образ, то нужно подключиться к консоли VM после запуска (учетная запись student/password), поднять привилегии, настроить получение ip параметров по dhcp, активировать интерфейс и выяснить назначенный системе ip, выполнив команды:

student@debian:~$ sudo -i

debian:~# nano /etc/network/interfaces
auto lo
  iface lo inet loopback

auto eth0
  iface eth0 inet dhcp
debian:~# ifup eth0

debian:~# echo 127.0.1.1 $(hostname) >> /etc/hosts

Последняя инструкция нужна для исключения предупреждений о невозможности получить ip по hostname сервисов sudo и proxy Squid (выполнить ее можно на 2-м шаге, скопировав после подключения к VM по SSH).

Шаг 2. Разворачиваем сервис Squid

Для удобства копирования команд из статьи, подключитесь к VM используя SSH клиент. Если у Вас Windows на домашнем компьютере, можно использовать PuTTY:

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

Установите Squid, отредактируйте файлы конфигурации (для нашего примера будет удобно использовать вариант, при котором proxy будет “пускать” только на определенные сайты, что позволит легко протестировать работу сервиса), убедитесь в отсутствии синтаксических ошибок и перезапустите сервис, выполнив команды:

student@debian:~$ sudo -i

debian:~# apt update

debian:~# apt install squid -y

debian:~# nano /etc/squid/permit_domains.txt
.debian.org
.linux.org.ru
debian:~# nano /etc/squid/conf.d/my.conf
acl permit_domains dstdomain "/etc/squid/permit_domains.txt"
http_access allow permit_domains
debian:~# squid -k check

debian:~# squid -k reconfigure

Для тестирования сервиса настройте браузер на хост системе, например, Firefox

https://www.mozilla.org/ru/firefox/new/

указав ip адрес Вашей VM (здесь и далее, замените 192.168.1.102 на тот, который у Вас)

В результате должны “открываться” только сайты, перечисленные в файле permit_domains.txt

Шаг 3. Устанавливаем GitLab

Установите GitLab, используя официальное руководство:

https://about.gitlab.com/install/#debian

или набор команд ниже, не забыв исправить ip адрес в EXTERNAL_URL на Ваш:

debian:~# apt install -y curl ca-certificates perl

debian:~# curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash

debian:~# EXTERNAL_URL="http://192.168.1.102" apt-get install gitlab-ce

Подключитесь к GitLab в браузере с хост машины, по указанному при инсталляции EXTERNAL_URL, учетной записью root и паролем, который нужно скопировать из файла:

debian:~# cat /etc/gitlab/initial_root_password

В разделе “Admin→Users→New User” создайте нового пользователя (предлагаю, тоже student) задав атрибуты

Name: student
Username: student
Email: student@localhost

Для упрощения примера, не будем настраивать электронную почту в VM, поэтому, сразу после создания (“Create User”) учетной записи, перейдите в ее редактирования (“Edit”), придумайте, запомните и дважды укажите пароль (потребуют хороший пароль:) после чего, сохраните изменения (“Save сhanges”)

Подключитесь новой учётной записью (на предложение указать новый пароль можно ввести предыдущий)

Шаг 4. Размещаем конфигурацию proxy сервера в GitLab

Создаем новый проект “Create a project”→“Create blank project”

Указываем Project name: squid project и убираем “галочку” “Initialize repository with a README”, поскольку будем загружать репозиторий, который создадим на следующем шаге.

Выполняем инструкции из подсказки в разделе “Push an existing folder”, задав в начале git параметр user.email

debian:~# git config --global user.email student@localhost

debian:~# cd /etc/squid/

debian:/etc/squid# git init --initial-branch=main

debian:/etc/squid# git remote add origin http://192.168.1.102/student/squid-project.git

debian:/etc/squid# git add .

debian:/etc/squid# git commit -m "Initial commit"

debian:/etc/squid# git push -u origin main

“Щелкнув” по названию проекта убедитесь, что все файлы из каталога /etc/squid появились в GitLab. Для изменения файлов конфигурации теперь можно не подключаться через SSH к VM с сервисом Squid, а отредактировать их прямо здесь через “Web IDE”. Остается вопрос, как эти изменения попадут в VM с сервисом Squid?

Шаг 5. GitLab Runner

Установите GitLab Runner, используя официальное руководство:

https://docs.gitlab.com/runner/install/linux-manually.html

или набор команд ниже:

debian:~# curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"

debian:~# dpkg -i gitlab-runner_amd64.deb

Если первая команда работает слишком долго, можно скачать старую версию с моего сайта, для нашего примера она подойдет:

debian:~# wget http://val.bmstu.ru/unix/Git/gitlab-runner_amd64.deb

Разрешим пользователю gitlab-runner выполнять команды с повышенными привилегиями, необходимые для тестирования, копирования и применения новой конфигурации proxy:

debian:~# nano /etc/sudoers.d/squid-sudo
gitlab-runner ALL=NOPASSWD: /bin/cp -r ./* /etc/squid/, /usr/sbin/squid -k *

Проверим, все ли работает. Для этого добавьте домен какого-нибудь сайта в файл permit_domains.txt используя “Web IDE” в GitLab и выполните Commit изменений в ветку main. Далее, с правами пользователя gitlab-runner, склонируйте проект, зайдите в его каталог и выполните команды тестирования, копирования и применения новой конфигурации:

debian:~# su - gitlab-runner

gitlab-runner@debian:~$ git clone http://192.168.1.102/student/squid-project.git

gitlab-runner@debian:~$ cd squid-project/

gitlab-runner@debian:~/squid-project$ sudo /usr/sbin/squid -k check -f conf.d/my.conf

gitlab-runner@debian:~/squid-project$ sudo /bin/cp -r ./* /etc/squid/

gitlab-runner@debian:~/squid-project$ sudo /usr/sbin/squid -k reconfigure

Если новый сайт открывается, значит все готово к автоматизации!

Шаг 6. GitLab CI/CD

Зарегистрируйте GitLab Runner в GitLab. Для этого, подключитесь к GitLab учетной записью root (см. Шаг 3) а в командной строке запустите процесс регистрации:

debian:~# gitlab-runner register

укажите http://localhost/ в качестве “GitLab instance URL”

Enter the GitLab instance URL (for example, https://gitlab.com/):
http://localhost/

в GitLab в разделе Admin→CI/CD→Runners нажмите на кнопку “Register an instance runner” скопируйте и вставьте в командную строку “registration token”

Enter the registration token:
xxxxxxxxxxxxxx-xxxxxxx

оставьте значение поля “description” без изменений

Enter a description for the runner:
[debian]:

в качестве списка “tags” укажите единственное значение squid-tag, оно нам скоро пригодится

Enter tags for the runner (comma-separated):
squid-tag

оставьте “optional maintenance” без изменений, на WARNING не будем обращать внимание (хотя скоро статью придется переписывать:), главное - наличие сообщения о успешной регистрации

Enter optional maintenance note for the runner:
WARNING: ...
Registering runner... succeeded                     runner=oDSeAdUz

в качестве “executor” выберите shell (начнем с него:)

Enter an executor: docker-ssh, virtualbox, instance, docker-ssh+machine, kubernetes, custom, docker, parallels, shell, ssh, docker+machine:
shell

Убедитесь что в GitLab, в разделе разделе Admin→CI/CD→Runners наш Runner находится в режиме Online и снова подключитесь к нему учетной записью student

В проекте “squid project” зайдите в раздел CI/CD→Editor и нажмите на кнопку “Configure Pipeline”

Замените текст Pipeline на этот:

stages:
  - test
  - deploy

test1-job:
  stage: test
  script:
    - sudo /usr/sbin/squid -k check -f conf.d/my.conf
  tags:
    - squid-tag

deploy1-job:
  stage: deploy
  script:
    - sudo /bin/cp -r ./* /etc/squid/
    - sudo /usr/sbin/squid -k reconfigure
  tags:
    - squid-tag

и нажмите на кнопку “Commit Changes”.

Добавьте домен еще какого-нибудь сайта в файл permit_domains.txt используя “Web IDE” в GitLab и выполните Commit изменений в ветку main.

Убедитесь, что в разделе CI/CD→Pipelines проекта значение Status установилось в passed, в браузере открывается новый сайт, а добавленный домен присутствует в файле:

debian:~# cat /etc/squid/permit_domains.txt

Если так, поздравляю, Вы только что написали свой первый CI/CD Pipeline!

Итоги

Такой вот “игрушечный” деплой, от которого можно оттолкнуться в сторону настоящих “DevOps” решений. Если что-то нужно уточнить, обращайтесь в комментариях!

На этом все, спасибо, что дочитали до конца, если такой подход к обучению DevOps технологиям вызовет интерес, напишу аналогичные статьи по ansible, docker, k8s и прочим!

Комментарии (12)


  1. slonopotamus
    00.00.0000 00:00
    +4

    А теперь у нас машинок стало не 1, а N. И вся эта конструкция развалилась, потому что gitlab-runner ну вот вообще не предназначен для того что вы пытаетесь с его помощью делать. Его задача - взять какой-нибудь подходящий под требования пайплайна раннер, выполнить там пайплайн (и, по-хорошему, зачистить следы своего пребывания, освободив машину под следующие пайплайны). А вам нужно совсем другое. Вам нужно чтобы состояние машины было приведено в соответствие заказанным.

    В общем не учите людей плохому.


    1. valvalva Автор
      00.00.0000 00:00
      -2

      Это учебный пример, "подводящее упражнение" :)


    1. valvalva Автор
      00.00.0000 00:00

      Кстати, действительно, отличный аргумент добавить Ansible. Всегда нравились статьи не "Давайте изучим Docker" а "Давайте увидим, как Docker упростит нам решение задач"


  1. OlegSpectr
    00.00.0000 00:00
    +1

    Я понимаю, что тут учебный пример, туториал, но вот прям не хватает описания, а для чего это делается? Вот раннер - это что такое? А для чего? А стадии в CI/CD - это что? В общем, после прочтения статьи останется много вопросов у начинающих.


    1. valvalva Автор
      00.00.0000 00:00

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


      1. valvalva Автор
        00.00.0000 00:00

        Вот здесь, похожий пример рассматривается со всеми описаниями: https://youtu.be/FeD6VBY2Xss


  1. kibez
    00.00.0000 00:00
    +1

    Спасибо за хороший "стартовый" материал! Автор ясно написал - “игрушечный” деплой, от которого можно оттолкнуться в сторону настоящих “DevOps”!

    Как мне кажется, лучше в следующей статье опишите "следующий шаг" ... улучшение описаной схемы / ранеры / ....


    1. valvalva Автор
      00.00.0000 00:00

      Да, так и планирую, следующая остановка ansible


    1. Ahuromazdie
      00.00.0000 00:00

      Иии? "все очевидно - берем приложение на Python, заворачиваем в Docker, кладем в GitLab, выкатываем через CI/CD в Кubernetes. "


  1. web3_Venture
    00.00.0000 00:00

    А есть какая система CI CD которая может из коробки 1) брать из локальной папки с git изменения , компилировать , собирать образ и выкладывать на локальную машину с docker ?


    1. gavk
      00.00.0000 00:00

      git post commit hook сможет запустить сборку.


  1. W3n8f34
    00.00.0000 00:00
    +1

    Мне понравилось.спасибр!