Однажды подслушано:
— А… А что мы сейчас делаем?
— Деплой приложения.
— А что такое деплой?
— Деплой… Ну это деплой, что тут не понятного?
И действительно, для тех, кто в “теме”, все очевидно - берем приложение на 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)
OlegSpectr
00.00.0000 00:00+1Я понимаю, что тут учебный пример, туториал, но вот прям не хватает описания, а для чего это делается? Вот раннер - это что такое? А для чего? А стадии в CI/CD - это что? В общем, после прочтения статьи останется много вопросов у начинающих.
valvalva Автор
00.00.0000 00:00Да, спасибо за комментарий, мне в свое время очень не хватало такой статьи, я постарался в минимальное количество команд уместить работающий пример, который можно воспроизвести прямо у себя на компьютере и далее его развивать. Материалов хорошо описывающих теорию я находил много, но, лично мне, понятнее, когда можно сделать и увидеть в работе
valvalva Автор
00.00.0000 00:00Вот здесь, похожий пример рассматривается со всеми описаниями: https://youtu.be/FeD6VBY2Xss
kibez
00.00.0000 00:00+1Спасибо за хороший "стартовый" материал! Автор ясно написал - “игрушечный” деплой, от которого можно оттолкнуться в сторону настоящих “DevOps”!
Как мне кажется, лучше в следующей статье опишите "следующий шаг" ... улучшение описаной схемы / ранеры / ....
Ahuromazdie
00.00.0000 00:00Иии? "все очевидно - берем приложение на Python, заворачиваем в Docker, кладем в GitLab, выкатываем через CI/CD в Кubernetes. "
web3_Venture
00.00.0000 00:00А есть какая система CI CD которая может из коробки 1) брать из локальной папки с git изменения , компилировать , собирать образ и выкладывать на локальную машину с docker ?
slonopotamus
А теперь у нас машинок стало не 1, а N. И вся эта конструкция развалилась, потому что gitlab-runner ну вот вообще не предназначен для того что вы пытаетесь с его помощью делать. Его задача - взять какой-нибудь подходящий под требования пайплайна раннер, выполнить там пайплайн (и, по-хорошему, зачистить следы своего пребывания, освободив машину под следующие пайплайны). А вам нужно совсем другое. Вам нужно чтобы состояние машины было приведено в соответствие заказанным.
В общем не учите людей плохому.
valvalva Автор
Это учебный пример, "подводящее упражнение" :)
valvalva Автор
Кстати, действительно, отличный аргумент добавить Ansible. Всегда нравились статьи не "Давайте изучим Docker" а "Давайте увидим, как Docker упростит нам решение задач"