Тестовый сервер для команды разработчиков

Тестовый сервер для команды разработчиков

Вводная

1. Один тестовый сервер
2. Gitlab и redmine на другом сервере
3. Желание разобраться в проблеме

Все сервера находятся в нашей локальной сети, тестовый сервер недоступен извне.

1. Возможность тестировать несколько проектов/веток одновременно
2. Разработчик может зайти на сервер, до настроить его и при этом не сломать ничего у других
3. Все должно быть максимально удобно и делаться по 1 кнопке желательно из gitlab (CI/CD).

Варианты решений

1. Один сервер, много хостов

Самый простой вариант. Используем тот же тестовый сервер, только разработчику нужно создавать хост под каждую ветку/проект и вносить его в конфигурацию nginx/apache2.

1. Быстро и всем понятно
2. Можно автоматизировать

Минусы:

1. Не выполняется п.2 из требований — разработчик может запустить обновление бд и при некотором стечении обстоятельств положить все (Привет Андрей!)
2. Довольно сложная автоматизация с кучей конфигурационных файлов

2. Каждому разработчику по серверу!

Выделяем каждому по серверу и разработчик сам отвечает за свое хозяйство.

1. Разработчик может полностью настроить сервер под свой проект

Минусы:

1. п.2 требований так и не выполняется
2. Дорого и ресурсы могут просто простаивать пока идет разработка, а не тестирование
3. Автоматизация еще сложней чем в п.1 из-за разных серверов

3. Контейнеризация — docker, kubernetes

Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами.

1. Используется один сервер
2. Выполняются все пункты требований

Минусы:

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

Внедрение docker

При использовании gitlab очень часто попадались на глаза настройки AutoDevOps, kubernetes. Плюс бородатые дядьки на различных meetup рассказывают как у них круто все работает с kubernetes. Поэтому было принято решение попробовать развернуть кластер на своих мощностях, был выпрошен сервер (а тестовый трогать нельзя, там люди тестируют) и понеслась!

Так как опыта у меня с kubernetes 0, делось все по мануалу с попыткой понять как все эти кластера работают. Спустя некоторое время мне удалось поднять кластер, но потом пошли проблемы с сертификатами, ключами, да и вообще с трудностью развертывания. Мне же нужно было решение проще, чтобы научить своих коллег с этим работать (например, тот же отпуск не хочется проводить сидящим в скайпе и помогающим с настройкой). Поэтому kubernetes был оставлен в покое. Оставался сам docker и нужно было найти решение для маршрутизации контейнеров. Так как их можно было поднять на разных портах, то можно было бы использовать тот же nginx для внутреннего перенаправления. Называется это обратный прокси сервер.

Обратный прокси-сервер — тип прокси-сервера, который ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. При этом для клиента это выглядит так, будто запрашиваемые ресурсы находятся непосредственно на прокси-сервере.

Обратный прокси-сервер

Чтобы не изобретать велосипед, я начал искать готовые решения. И оно нашлось — это traefik.

Træfik — это современный обратный прокси HTTP и балансировщик нагрузки, который упрощает развертывание микросервисов. Træfik интегрируется с существующими инфраструктурными компонентами ( Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS, . ) и настраивается автоматически и динамически. Для работы с docker достаточно указать его сокет и все, дальше Træfik сам находит все контейнеры и маршрутизацию до них (подробнее в «Упаковываем приложения в docker»).

Запускаю его через docker-compose.yml

Здесь мы сообщаем прокси, что нужно слушать порты 80,443 и 8080 (веб морда прокси), монтируем сокет докера, файл конфигурации и папку с сертификатами. Для удобства именования тестовых сайтов, мы решили сделать локальную доменную зону *.test. При обращении к любому сайту на ней, пользователь попадает на наш тестовый сервер. Поэтому сертификаты в папке traefik самоподписаные, но он так поддерживает Let’s Encrypt.

Перед стартом нужно создать в докере сеть proxy (можете назвать по своему).

Это будет сеть для связи traefik с контейнерами php сайтов. Поэтому указываем ее в параметре networks сервиса и в networks всего файла указав в параметре external: true.

Тут все довольно просто — указываем точки входа http и https трафика, не забудьте поставить insecureSkipVerify = true если сертификаты локальные. В секции entryPoints.https.tls можно не указывать сертификаты, тогда traefik подставит свой сертификат.

Можно запустить сервис

Если перейти по адресу site.test, то выдаст ошибку 404, так как этот домен не привязан ни к какому контейнеру.

Упаковываем приложения в docker

Теперь нужно настроить контейнер с приложением, а именно:

1. указать в сетях сеть proxy
2. добавить labels с конфигурацией traefik

Ниже приведена конфигурация одного из приложений

В сервисе app, в секции сети нужно указать proxy и default, это значит что он будет доступен в двух сетях, как видно из конфигурации я не пробрасываю порты наружу, все идет внутри сети.

Далее конфигурируем labels

В общей секции networks нужно указать external: true

Константу TEST_DOMAIN нужно заменить на домен, например, site.test

Теперь если зайти на домены site.test, crm.site.test, bonus.site.test можно увидеть рабочий сайт. А на домене pma.site.test будет phpmyadmin для удобной работы с бд.

Настройка GitLab

Создаем обработчик заданий, для этого запускаем

Указываем url gitlab, токен и через что будет выполняться задание (executors). Так как у меня тестовый и gitlab находятся на разных серверах, то выбираю ssh executor. Нужно будет указать адрес сервера и логин/пароль для подключения по ssh.

Runner можно сделать прикрепленным к одному или нескольким проектам. Так как у меня логика работы везде одинаковая, поэтому был создан shared runner (общий для всех проектов).
И последний штрих это создать файл конфигурации CI

В данной конфигурации описаны 2 этапа — build и clear. Этап build имеет 2 варианта выполнения — build_develop и build_prod

Gitlab строит понятную диаграмму выполнения процесса. В моем примере все процессы стартуют вручную (параметр when: manual). Сделано это для того, чтобы разработчик после разворачивания тестового сайта, мог делать pull своих правок в контейнер без пересборки всего контейнера. Еще одна причина это наименование доменов — site$CI_PIPELINE_ID.test, где CI_PIPELINE_ID — номер процесса запустившего сборку. То есть отдали на проверку сайт с доменом site123.test и чтобы внести горячие правки, сразу заливаются изменения в контейнер самим разработчиком.

Небольшая особенность работы ssh executor. При подключении к серверу создается папка вида

Поэтому была добавлена строчка

В ней мы поднимаемся на папку выше и копируем проект в папку с номером процесса. Так можно разворачивать несколько веток одного проекта. Но в настройках обработчика нужно поставить галку Lock to current projects, так обработчик не будет пытаться развернуть несколько веток одновременно.

Этап clear останавливает контейнеры и удаляет папку, могут понадобиться права root, поэтому используем команду echo password | sudo -S rm, где password ваш пароль.

Уборка мусора

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

выполняется раз в день.

Заключение

Данное решение помогло нам существенно оптимизировать тестирование и выпуск новых фич. Готов ответить на вопросы, конструктивная критика принимается.

Бонус

Для того чтобы не собирать каждый раз образы из Dockerfile, можно хранить их локальном реестре докера.

В данном варианте не используется аутентификация, это не безопасный способ (. ), но для хранения не критичных образов нам подходит.

Можно настроить gitlab для просмотра

После этого в gitlab появляется список образов

Загрузка необходимых файлов на веб-сервер

Лучшие цены на SSL-сертификаты (от 550 руб.)

• Все доверенные центры сертификации
• Большой выбор сертификатов
• Пошаговые инструкции по выпуску и установке

Прежде всего, необходимо загрузить представленные в панели 1cloud файлы .ca и .crt на веб-сервер. Если ваш сервер не имеет графического окружения рабочего стола, вы можете загрузить эти файлы на другой компьютер, а затем перенести их одним из приведенных ниже способов.

Примечание: подразумевается, что необходимая для работы пара закрытый/открытый ключ была сгенерирована на том же веб-сервере, на который вы будете переносить приобретенный сертификат. Если вы создавали ключи на другой машине, вам необходимо также перенести файл закрытого ключа .key на ваш веб-сервер по аналогии с описанной ниже процедурой копирования файлов сертификатов.

Перенос сертификатов с компьютера Linux/Mac OS:

Самый простой способ загрузки сертификатов на сервер — опция SCP, встроенная в возможность терминала вашего компьютера:

1. Загрузите файлы .CA и .CRT из панели управления 1cloud на локальный компьютер.
2. Откройте терминал и перейдите в папку, в которую вы сохранили сертификаты (напр., Downloads):
   cd

/Downloads
Скопируйте сертификаты вашего сайта и Центра Сертификации на веб-сервер:
scp crt.crt ca.crt user@1.22.33.444:/etc/ssl
Где:
scp — команда копирования файлов
mydomain.ru_crt.crt — имя загруженного из панели файла сертификата вашего веб-сайта
mydomain.ru_ca.crt — имя загруженного из панели файла сертификата Центра Авторизации
user — имя вашего пользователя для подключения к серверу через ssh (часто используется root)
1.22.33.444 — IP-адрес вашего веб-сервера
/etc/ssl — директория на удаленном сервере, в которую в хотите сохранить загружаемые файлы.

Перенос сертификатов с компьютера Windows:

1. Установите программу WinSCP. Скачать ее можно здесь.
2. Запустите WinSCP. В открывшемся окне введите данные, которые вы используете для подключени я к вашему серверу по SSH.
   В левой части окна программы отображаются файлы на локальном компьютере, в правой — на подключенном удаленном сервере. Выберите или создайте директорию, в которую вы хотите сохранить сертификаты, в правой части окна. Перетащите файлы .CA и .CRT в эту директорию из левой части окна.

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

Если закрытый ключ .key был сгенерирован непосредственно на сервере, то для его копирования в другую директорию вы можете использовать команду:
cp /home/root/private.key / etc /ssl/private.key
Где:
cp — команда копирования
/home/root/ — путь до файла ключа
private.key — имя файла ключа
/etc/ssl/private.key — путь, по которому необходимо скопировать файл ключа

Удалить файл ключа из старого расположения вы можете с помощью команды:
rm /home/root/private.key
(синтаксис команды аналогичен предыдущему примеру)

Установка NetCat на Windows

В этом руководстве будет рассмотрен процесс установки и использования утилиты netcat на виртуальных серверах под управлением операционной системы семейства Windows.

Виртуальный сервер на базе Windows

• Лицензия включена в стоимость
• Тестирование 3-5 дней
• Безлимитный трафик

Что это такое

Netcat — сетевая утилита, которую часто называют “Швейцарским армейским ножом”, используется для чтения или записи по TCP и UDP соединениям, используя простой интерфейс.

Установка

Загрузите архив с утилитой.
Перейдите в каталог с загрузками и распакуйте содержимое архива в любое удобное место.
В нашем примере мы будем использовать каталог “C:Program filesnetcat”.
При перемещении Вам необходимо ввести пароль “nc”.

Содержимое каталога после перемещения файлов.

Далее откройте командную строку Windows или PowerShell. С помощью команды cd перейдите в каталог с файлами: cd ‘C:Program filesnetcat’

Запустите утилиту netcat: .nc.exe

В поле открывшейся командной строки можно начинать работу с утилитой. Для вывода доступных опций воспользуйтесь ключом -h: nc -h

Примеры использования

На первой машине с IP-адресом X.X.X.X выполните команду nc с указанием порта, например 80.
Для Linux: nc -l -p 80

Для Windows после запуска утилиты netcat: -l -p 80

На другой машине, которая подключается, выполните команду, указав IP-адрес первой машины и порт.
Для Linux: nc X.X.X.X 80

1. Получаем код страницы и дополнительную информацию с помощью GET-запроса. PS C:Program Filesnetcat> .nc.exe
2. Сканирование портов. PS C:Program Filesnetcat> .nc.exe PS C:Program Filesnetcat> .nc.exe
3. Чат-сервер
   Для Windows: X.X.X.X 80

В пустой строке начинайте писать сообщение, после нажатия Enter оно будет отправлено.

Тестовый сервер для команды разработчиков

Вводная

1. Один тестовый сервер
2. Gitlab и redmine на другом сервере
3. Желание разобраться в проблеме

Все сервера находятся в нашей локальной сети, тестовый сервер недоступен извне.

1. Возможность тестировать несколько проектов/веток одновременно
2. Разработчик может зайти на сервер, до настроить его и при этом не сломать ничего у других
3. Все должно быть максимально удобно и делаться по 1 кнопке желательно из gitlab (CI/CD).

Варианты решений

1. Один сервер, много хостов

Самый простой вариант. Используем тот же тестовый сервер, только разработчику нужно создавать хост под каждую ветку/проект и вносить его в конфигурацию nginx/apache2.

1. Быстро и всем понятно
2. Можно автоматизировать

Минусы:

1. Не выполняется п.2 из требований — разработчик может запустить обновление бд и при некотором стечении обстоятельств положить все (Привет Андрей!)
2. Довольно сложная автоматизация с кучей конфигурационных файлов

2. Каждому разработчику по серверу!

Выделяем каждому по серверу и разработчик сам отвечает за свое хозяйство.

1. Разработчик может полностью настроить сервер под свой проект

Минусы:

1. п.2 требований так и не выполняется
2. Дорого и ресурсы могут просто простаивать пока идет разработка, а не тестирование
3. Автоматизация еще сложней чем в п.1 из-за разных серверов

3. Контейнеризация — docker, kubernetes

Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами.

1. Используется один сервер
2. Выполняются все пункты требований

Минусы:

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

Внедрение docker

При использовании gitlab очень часто попадались на глаза настройки AutoDevOps, kubernetes. Плюс бородатые дядьки на различных meetup рассказывают как у них круто все работает с kubernetes. Поэтому было принято решение попробовать развернуть кластер на своих мощностях, был выпрошен сервер (а тестовый трогать нельзя, там люди тестируют) и понеслась!

Так как опыта у меня с kubernetes 0, делось все по мануалу с попыткой понять как все эти кластера работают. Спустя некоторое время мне удалось поднять кластер, но потом пошли проблемы с сертификатами, ключами, да и вообще с трудностью развертывания. Мне же нужно было решение проще, чтобы научить своих коллег с этим работать (например, тот же отпуск не хочется проводить сидящим в скайпе и помогающим с настройкой). Поэтому kubernetes был оставлен в покое. Оставался сам docker и нужно было найти решение для маршрутизации контейнеров. Так как их можно было поднять на разных портах, то можно было бы использовать тот же nginx для внутреннего перенаправления. Называется это обратный прокси сервер.

Обратный прокси-сервер — тип прокси-сервера, который ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. При этом для клиента это выглядит так, будто запрашиваемые ресурсы находятся непосредственно на прокси-сервере.

Обратный прокси-сервер

Чтобы не изобретать велосипед, я начал искать готовые решения. И оно нашлось — это traefik.

Træfik — это современный обратный прокси HTTP и балансировщик нагрузки, который упрощает развертывание микросервисов. Træfik интегрируется с существующими инфраструктурными компонентами ( Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS, . ) и настраивается автоматически и динамически. Для работы с docker достаточно указать его сокет и все, дальше Træfik сам находит все контейнеры и маршрутизацию до них (подробнее в «Упаковываем приложения в docker»).

Запускаю его через docker-compose.yml

Здесь мы сообщаем прокси, что нужно слушать порты 80,443 и 8080 (веб морда прокси), монтируем сокет докера, файл конфигурации и папку с сертификатами. Для удобства именования тестовых сайтов, мы решили сделать локальную доменную зону *.test. При обращении к любому сайту на ней, пользователь попадает на наш тестовый сервер. Поэтому сертификаты в папке traefik самоподписаные, но он так поддерживает Let’s Encrypt.

Перед стартом нужно создать в докере сеть proxy (можете назвать по своему).

Это будет сеть для связи traefik с контейнерами php сайтов. Поэтому указываем ее в параметре networks сервиса и в networks всего файла указав в параметре external: true.

Тут все довольно просто — указываем точки входа http и https трафика, не забудьте поставить insecureSkipVerify = true если сертификаты локальные. В секции entryPoints.https.tls можно не указывать сертификаты, тогда traefik подставит свой сертификат.

Можно запустить сервис

Если перейти по адресу site.test, то выдаст ошибку 404, так как этот домен не привязан ни к какому контейнеру.

Упаковываем приложения в docker

Теперь нужно настроить контейнер с приложением, а именно:

1. указать в сетях сеть proxy
2. добавить labels с конфигурацией traefik

Ниже приведена конфигурация одного из приложений

В сервисе app, в секции сети нужно указать proxy и default, это значит что он будет доступен в двух сетях, как видно из конфигурации я не пробрасываю порты наружу, все идет внутри сети.

Далее конфигурируем labels

В общей секции networks нужно указать external: true

Константу TEST_DOMAIN нужно заменить на домен, например, site.test

Теперь если зайти на домены site.test, crm.site.test, bonus.site.test можно увидеть рабочий сайт. А на домене pma.site.test будет phpmyadmin для удобной работы с бд.

Настройка GitLab

Создаем обработчик заданий, для этого запускаем

Указываем url gitlab, токен и через что будет выполняться задание (executors). Так как у меня тестовый и gitlab находятся на разных серверах, то выбираю ssh executor. Нужно будет указать адрес сервера и логин/пароль для подключения по ssh.

Runner можно сделать прикрепленным к одному или нескольким проектам. Так как у меня логика работы везде одинаковая, поэтому был создан shared runner (общий для всех проектов).
И последний штрих это создать файл конфигурации CI

В данной конфигурации описаны 2 этапа — build и clear. Этап build имеет 2 варианта выполнения — build_develop и build_prod

Gitlab строит понятную диаграмму выполнения процесса. В моем примере все процессы стартуют вручную (параметр when: manual). Сделано это для того, чтобы разработчик после разворачивания тестового сайта, мог делать pull своих правок в контейнер без пересборки всего контейнера. Еще одна причина это наименование доменов — site$CI_PIPELINE_ID.test, где CI_PIPELINE_ID — номер процесса запустившего сборку. То есть отдали на проверку сайт с доменом site123.test и чтобы внести горячие правки, сразу заливаются изменения в контейнер самим разработчиком.

Небольшая особенность работы ssh executor. При подключении к серверу создается папка вида

Поэтому была добавлена строчка

В ней мы поднимаемся на папку выше и копируем проект в папку с номером процесса. Так можно разворачивать несколько веток одного проекта. Но в настройках обработчика нужно поставить галку Lock to current projects, так обработчик не будет пытаться развернуть несколько веток одновременно.

Этап clear останавливает контейнеры и удаляет папку, могут понадобиться права root, поэтому используем команду echo password | sudo -S rm, где password ваш пароль.

Уборка мусора

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

выполняется раз в день.

Заключение

Данное решение помогло нам существенно оптимизировать тестирование и выпуск новых фич. Готов ответить на вопросы, конструктивная критика принимается.

Бонус

Для того чтобы не собирать каждый раз образы из Dockerfile, можно хранить их локальном реестре докера.

В данном варианте не используется аутентификация, это не безопасный способ (. ), но для хранения не критичных образов нам подходит.

Можно настроить gitlab для просмотра

После этого в gitlab появляется список образов

Настройка веб-сервера Apache на использование SSL-сертификата

После копирования файлов сертификата сайта и Центра Сертификации необходимо отредактировать параметры вашего веб-сервера Apache. Для этого подключитесь к вашему серверу по SSH от имени пользователя root и выполните следующие операции:

1. Активируйте использование опции SSL веб-сервером Apache:
   Ubuntu/Debian:
   a2enmod ssl
   CentOS:
   yum install mod_ssl
2. Откройте файл конфигурации сайта, для которого вы хотите установить SSL-сертификат.
   Например, если параметры веб-сайта хранятся в файле /etc/apache2/sites-enabled/000-default.conf:
   nano /etc/apache2/sites-enabled/000-default.conf
   Примечание: На Ubuntu/Debian файлы параметров сайтов Apache как правило находятся в директории /etc/apache2/sites-enabled/ . На CentOS стандартное расположение — /etc/httpd/conf.d/
   Для поиска нужной конфигурации вы можете использовать команду ls /директория/конфигураций (напр. ls /etc/apache2/sites-enabled), которая отображает полный список файлов в указанной директории.
   Затем с помощью команды nano вы можете открыть определенный файл (напр. nano /etc/apache2/sites-enabled/000-default.conf). Проверить, что открытый файл действительно является конфигурацией вашего сайта можно, найдя в нем строку ServerName. Ее значение должно соответствовать домену, для которого вы устанавливаете SSL-сертификат (напр. www.mydomain.ru)
   Примечание для CentOS: если редактор nano не установлен на вашем сервере, вы можете установить его с помощью команды yum install nano
3. Добавьте приведенные ниже параметры в открытый файл конфигурации:
   SSLEngine on
   SSLCertificateFile /etc/ssl/mydomain.ru_crt.crt
   SSLCertificateChainFile /etc/ssl/mydomain.ru_ca.crt
   SSLCertificateKeyFile /etc/ssl/mydomain.ru_key.key
   Где:
   /etc/ssl/mydomain.ru_crt.crt — путь до файла сертификата вашего сайта
   /etc/ssl/mydomain.ru_ca.crt — путь до файла цепочки сертификатов Центра Сертификации (CA)
   /etc/ssl/mydomain.ru_key.key — путь к файлу вашего закрытого ключа

Примечание: если вы хотите, чтобы после установки SSL-сертификата ваш сайт был доступен только по безопасному протоколу https (порт 443), отредактируйте файл его конфигурации по аналогии с приведенным ниже Примером 1. Если же вы хотите, чтобы сайт также оставался по-прежнему доступен по незащищенному протоколу http (порт 80), воспользуйтесь Примером 2.
Вносимые изменения выделены жирным шрифтом.

# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request’s Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.mydomain.ru
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, . trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog $/error.log
CustomLog $/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with «a2disconf».
#Include conf-available/serve-cgi-bin.conf
SSLEngine on
SSLCertificateFile /etc/ssl/mydomain.ru_crt.crt
SSLCertificateChainFile /etc/ssl/mydomain.ru_ca.crt
SSLCertificateKeyFile /etc/ssl/mydomain.ru_key.key

Пример 2 (HTTPS + HTTP):