Как я могу заставить git принимать самоподписанный сертификат?

Первоначальная настройка vps

Вот вы купили инстанс например на

, первое, что необходимо предпринять, это защитить ваш сервер от агрессивного внешнего мира. Я не буду ничего доказывать и утверждать, просто покажу лог /var/log/messages своего виртуального сервера:

Во-первых установим файервол ufw:

apt-get update && apt-get install ufw

Включим политику по-умолчанию: блокируем все входящие соединения, разрешаем все исходящие соединения:

ufw default deny incoming
ufw default allow outgoing

Важно: не забудем разрешить соединение по ssh:

ufw allow OpenSSH

Общий синтаксис такой: Разрешить соединение по порту: ufw allow 12345, где 12345 — номер порта или же название сервиса. Запретить: ufw deny 12345

Включаем файервол:

ufw enable

Создание сервисов на основе контейнеров docker

Для создания управляемых сервисов используем инструмент

docker-compose

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

docker-compose.yml

$ nano docker-compose.yml

И запишем такой текст, заменив доменное имя:

Backup и восстановление gitlab

Очень подробно процесс бэкапа и восстановления gitlab рассмотрен в документации.  Я лишь сделаю краткую выжимку из информации оттуда.

У gitlab есть встроенный механизм создания резервной копии. Подготовить бэкап можно командой:

# gitlab-rake gitlab:backup:create

По-умолчанию бэкап будет создан в директории /var/opt/gitlab/backups, откуда вы его можете переместить в другое место.

Существуют разные стратегии бэкапа. По-умолчанию, данные сразу упаковываются с помощью tar. Этот процесс не моментальный и занимает какое-то время. Если в этот момент с данными активно работать, то файлы будут изменены, а tar будет выдавать предупреждения. Чтобы этого избежать, можно указывать STRATEGY=copy, например вот так:

# gitlab-rake gitlab:backup:create STRATEGY=copy

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

Директорию, куда бэкапить, можно указать в конфиге примерно вот так:

 gitlab_rails['backup_upload_connection'] = {
   :provider => 'Local',
   :local_root => '/mnt/backups'
 }

 # The directory inside the mounted folder to copy backups to
 # Use '.' to store them in the root directory
 gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'

В данном случае /mnt/backups не обязательно локальная папка. Это может быть и сетевая папка nfs или smb, примонтированная к серверу. Можете использовать локальную директорию, а потом с помощью rsync куда-то передавать данные.

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

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

 ## Limit backup lifetime to 7 days - 604800 seconds
 gitlab_rails['backup_keep_time'] = 604800

Для регулярного выполнения backup данных gitlab можно создать задачу в cron. Вот пример, для регулярного резервного копирования в 2 часа ночи:

0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

Обязательно нужно учесть, что таким образом созданные бэкапы не включают в себя сам файл конфигурации gitlab и ключей ssh, которые хранятся в /etc/gitlab. Эту директорию нужно бэкапить отдельно.

Для восстановления gitlab из бэкапа, вам необходимо установить чистую gitlab той же версии, что есть в архивной копии. Убедиться в том, что она работает. Затем восстановить вручную файл /etc/gitlab/gitlab-secrets.json. Далее копируете файл с бэкапом в директорию /var/opt/gitlab/backups и назначаете пользователя git владельцем файла. Дальше выполняете команды:

# gitlab-ctl stop unicorn
# gitlab-ctl stop sidekiq
# gitlab-ctl status
# gitlab-rake gitlab:backup:restore BACKUP=1493107454_2021_04_25_10.6.4-ce

После этого восстановите конфиг /etc/gitlab/gitlab.rb. Перезапустите gitlab и выполните проверку.

# gitlab-ctl restart
# gitlab-rake gitlab:check SANITIZE=true

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

Centos unable to load client key

Если вы пытаетесь это сделать на CentOS, и ваш .pemфайл дает вам

unable to load client key: "-8178 (SEC_ERROR_BAD_KEY)"

Тогда вам понадобится ответ StackOverflow о том, как curlиспользовать NSS вместо Open SSL.

И вы хотите, чтобы восстановить curlиз источника :

Ci/cd изнутри

Процесс непрерывной интеграции/внедрения описан в файле .gitlab-ci.yml в корне репозитория, он состоит из 4 стадий: загрузка зависимостей, phpunit-тестирование, сборка, развёртывание.

Git конфигурация подписанного сертификата

НИКОГДА не отключайте все проверки SSL!

Это создает плохую культуру безопасности. Не будь таким человеком.

Ключи конфигурации, которые вы ищете:

Это для настройки сертификатов хоста, которым вы доверяете

Они предназначены для настройки ВАШЕГО сертификата для ответа на вызовы SSL.

Выборочно применить вышеуказанные настройки к конкретным хостам.

Gitlab vs bitbucket

Сервис BitBucket не очень популярен у нас. Многие его вообще не знают, но насколько я слышал, он популярен на западе. Он позиционирует себя как сервис для небольших команд разработчиков. В качестве плюсов у него есть только парочка по сравнению с github:

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

Из недостатков по сравнению с gitlab только один:

• Бесплатная self-hosted версия позволяет работать не более, чем пяти пользователям.

В целом, у BitBucket вроде как интерфейс пошустрее, приятнее работать. Сам я никогда им не пользовался и даже аккаунта там нет.

Все три продукта зрелые, проверенные, известные. Принципиально gitlab отличается только возможностью установки на свои сервера. В остальном функционал схожий и чаще всего достаточный для большинства разработчиков. Более подробно нужно смотреть на нюансы, если они у вас есть, и на возможность интеграции с нужными вам продуктами. Непосредственно как системы контроля версий они все хороши и достаточны.

Gitlab vs github

Основной конкурент gitlab это сайт и сервис github. Он появился гораздо раньше, поэтому вполне логично, что обладает гораздо большей популярностью. На сегодняшний день это сайт номер один для размещения open source проектов. Они, по-моему, все на нем размещаются. Вот его основные преимущества:

• Огромное комьюнити. Очень часто git напрямую ассоциируется с github.
• Богатая интеграция сторонних сервисов. По сути, все поддерживают работу с github.
• Все в одном месте. Имея аккаунт на github ты получаешь доступ практически ко всем опенсорс проектам. Можешь без проблем их форкать, контрибьютить и т.д.
• Аккаунт на гитхабе иногда просят показать при устройстве на работу. Актуально для программистов.

Минусов по сути только два, но существенные:

• На бесплатном аккаунте нет возможности создавать приватные репозитории. Они все будут с публичным доступом.
• Нет возможности установить локальную версию.

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

То есть в целом github более старый, зрелый, популярный сервис, который все знают и используют. Gitlab же появился только в 2021 году.

Global .gitconfigдля самоподписанных центров сертификации

Ради меня и моих коллег здесь показано, как нам удалось заставить самозаверяющие сертификаты работать без отключения sslVerify. Отредактируйте,.gitconfig чтобы использовать git config –global -eдобавить эти:

Активация режима swarm

Для начала рекомендуем изучить материалы на тему режима Swarm, например, на официальном сайте

. Swarm — это кластер сервисов Docker, расположенных на различных физических или виртуальных машинах и ведущих себя как единое целое.

Распределение запросов между имеющимися сервисами Docker осуществляется по схеме

ingress load balancing

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

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

Мы активируем режим Docker Swarm на сервере

Manager

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

Node1

В терминале с открытой сессией на сервере Manager выполним команду:

$ docker swarm init
Swarm initialized: current node (r1mbxr2dyuf48zpm5ss0kvwv7) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-5ihkl37kbs13po7htnj9dzzg3gex4i6iuvjho7910crd0hv895-36jw5epwcw3xwpzmqf1mqgod2 {ваш IP-адрес}:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

Как видно из сообщения, текущий сервис Docker стал менеджером и готов к добавлению подчиненных хостов через выполнение указанной команды. Скопируем эту команду и подключимся к серверу

Node1

по SSH, для добавления его добавления в Swarm:

$ docker swarm join --token SWMTKN-1-1lhmuomvb060rnom4jqj8gxc565f4wgwadjs9ucvqx6huwvbfc-6vt1ljdhldxtetjv2hnct7sh4  {ваш IP-адрес}:2377

Результатом успешного выполнения команды должно стать сообщение:

This node joined a swarm as a worker.

Следующем шагом станет настройка рабочего сервера, который будет выполнять все работы от GitLab CI.

Генерация сертификатов

Чтобы управлять демоном докера удаленно требуется шифрованное TLS соединение. Для этого необходимо иметь сертификат и ключ, которые надо сгенерировать и перенести на удаленную вашу машину. Следуйте шагам, заданным в инструкции на официальном сайте docker:

Добавление пользователя к проекту

Посмотрим, как добавить пользователя в проект в gitlab. Для этого открываем проект. В левом меню выбираем раздел Settings -> Members. Здесь вы можете проверить доступ других пользователей к проекту. При необходимости, добавить нового. Сделаем это.

Все, пользователю добавлен доступ на просмотр к вашему проекту с ограничением доступа по времени.

Загрузка зависимостей

На данном этапе производится попытка установить все зависимости приложения через composer.

Результатом работы данного этапа будет наполнение папки /composer/home/cache. Эта папка сохраняется в volume у gitlab-ci-multi-runner и кэш composer будет доступен при выполнении всех последующих задач (как в текущей pipeline, так и в последующих).

Запуск приложения локально

Я подготовил скелет приложения и выложил его на GitHub. Всё написанное ниже относится к приложениям, созданным на основе этого шаблона и к инфраструктуре, необходимой для запуска такого приложения.

Чтобы запустить приложение локально, нужно выполнить следущие команды:

Запуск проекта на локальной машине

Мы готовы запустить проект на локальной машине. Подобный метод запуска удобно использовать в целях разработки и тестирования в дальнейшем. Для начала установим Docker (мы приведем пример для Ubuntu 16.04, для Windows существует отдельный инсталлятор).

Защита сервиса докера на управляющем сервере самоподписанными сертификатом

Примечание. Использование TLS и управление центром сертификации — тема, требующая значительной подготовки. Желательно ознакомиться с технологиями OpenSSL, x509 и TLS перед использованием их в реальных проектах.

На финальном этапе развертывания приложения в рабочей Swarm-среде необходимо защищенное соединение между GitLab Runner и сервисом Docker, запущенном на сервере Manager, что видно на схеме ниже:

Процесс развертывания приложения в рабочей среде.

Для этого необходимо использовать единый сертификационный центр для клиента (GitLab Runner) и сервиса Docker (Manager). После создания сертификата и ключа для клиента, их можно использовать для удаленного подключения к сервису Docker и выполнения различных операций.

Как загрузить или залить проект

Переходим к самому интересному. Посмотрим, как загрузить или выложить наш существующий проект на gitlab. Я для примера решил взять сайт на wordpress и выложить его исходники на gitlab. В дальнейшем изменение сайта будет фиксироваться через систему контроля версий git и заливаться на gitlab.

Удивительно, но в наше время далеко не все разработчики ведут свои проекты в git. Я постоянно вижу, как сайты на wordpress или bitrix правят прям на живую, а потом не могут понять, чего понаделали и почему не работает. Спасает только регулярный инкрементный бэкап, если вовремя спохватиться и начать искать багнутые изменения за какую-то дату. Надеюсь мое руководство будет полезно для разработчиков, которые захотят жить по-новому и начнут работать с git 🙂

Все, что пойдет дальше, не имеет прямого отношения к gitlab. С ним мы фактически закончили. Дальше мы будем работать с локальным репозиторием git и заливать его на gitlab. Использоваться будут исключительно git команды. По самому git в интернете очень много информации, в том числе хороших книг.

Как пользоваться gitlab

Перейдем к практике. Мы установили и настроили gitlab. Теперь посмотрим, как с ним работать. Это очень функциональный инструмент и в двух словах тут все не расскажешь. Я рассмотрю самые азы использования гитлаб для начинающих, чтобы можно было просто познакомиться и понять, как и где его можно использовать.

Настраиваем gitlab container registry

В этой статье мы рассмотрим, как настроить реестр образов GitLab Container Registry, находящийся за обратным прокси сервером NGINX. Предполагается, что у вас уже установлен GitLab с помощью пакета Omnibus. Согласно документации, Container Registry можно настроить на том же домене, на котором работает сам GitLab, но в случае работы GitLab за прокси сервером, необходимо завести отдельный домен для реестра образов, чтобы избежать конфликта доменных имен при настройке виртуальных хостов в GitLab Nginx.

Реестр образов будет доступен по адресу: registry.example.com. Добавляем А запись для домена реестра в DNS. Приводим конфиг виртуального хоста на сервере обратного прокси к следующему виду:

server {
    listen       80;
    server_name  registry.example.com;

    #return 301 https://$host$request_uri;

    root /usr/share/nginx/html;

    location / {
        deny all;
    }

    location ^~ /.well-known {
        default_type 'text/plain';
        allow all;
    }

    error_log   /var/log/nginx/registry_example_com_error.log error;
    access_log  /var/log/nginx/registry_example_com_access.log;
}

Получаем валидный сертификат от Let’s Encrypt с помощью плагина webroot:

certbot certonly -a webroot -w /usr/share/nginx/html -d registry.example.com

Дополняем конфигурацию домена реестра. Указываем путь к сертификату и приватному ключу, который мы получили ранее. Также проксируем запросы на порт “registry_nginx” и не забываем включить постоянный редирект на https:

server {
    listen       443 ssl;
    server_name  registry.example.com;

    ssl_certificate /etc/letsencrypt/live/registry.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/registry.example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;

    client_max_body_size 2000M;
    chunked_transfer_encoding on;

    root /usr/share/nginx/html;

    location / {
        proxy_pass http://192.168.0.10:8090;
        proxy_read_timeout      300;
        proxy_connect_timeout   300;
        proxy_redirect          off;
        proxy_set_header        X-Forwarded-Proto https;
        proxy_set_header        Host              $http_host;
        proxy_set_header        X-Real-IP         $remote_addr;
        proxy_set_header        X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Ssl   on;
    }

    location ^~ /.well-known {
        default_type 'text/plain';
        allow all;
    }

    error_log   /var/log/nginx/registry_example_com_ssl_error.log error;
    access_log  /var/log/nginx/registry_example_com_ssl_access.log;
}

Проверяем и перечитываем конфиг nginx:

nginx -t
nginx -s reload

Теперь вносим изменения в конфигурацию сервера GitLab. По умолчанию подсистема “GitLab Container Registry” отключена. Она активируется, полностью автоматически настраиваясь оркестратором “Omnibus”, при обнаружении в конфигурационном файле параметра “registry_external_url”.

# cat /etc/gitlab/gitlab.rb
registry_external_url 'https://registry.example.com'
gitlab_rails['registry_enabled'] = true
registry['enable'] = true
registry_nginx['enable'] = true
registry_nginx['proxy_set_headers'] = {
  "Host" => "$http_host",
  "X-Real-IP" => "$remote_addr",
  "X-Forwarded-For" => "$proxy_add_x_forwarded_for",
  "X-Forwarded-Proto" => "https",
  "X-Forwarded-Ssl" => "on"
}
registry_nginx['listen_port'] = 8090
registry_nginx['listen_https'] = false

Запускаем перенастройку GitLab:

gitlab-ctl reconfigure

Проверяем на клиенте аутентификацию и заливку образа:

docker login registry.example.com
docker build -t registry.example.com/test/test-1 .
docker push registry.example.com/test/test-1

Источники:

https://medium.com/@s.petrushin/настройка-gitlab-container-registry-c9ae3fb8a35

https://my-sertif.ru/gitlab-container-registry-za-nginx-reverse-proxy/

Настройка continuous deleivery на gitlab

Для того чтобы воркер гиталаба смог выполнять команды на удаленном хосте докера необхоимо определиться, как и где хранить сертификаты и ключ для шифрованного соединения с dockerd. Я решил данную проблему просто прописав в переменные в настройках gitlbab:

Просто выводите содержимое сертификатов и ключа через cat:

cat ca.pem

. Копируете и вставляете в значение переменных.

Пропишем сценарий для деплоя через гитлаб. Использовать будет docker-in-docker (dind) образ.

Содержимое скрипта деплоя с комментариями:

#!/usr/bin/env sh
# Падаем сразу, если возникли какие-то ошибки
set -e
# Выводим, то , что делаем
set -v

# 
DOCKER_COMPOSE_FILE=docker-compose.yml
# Куда деплоим
DEPLOY_HOST=185.241.52.28
# Путь для сертификатов клиента, то есть в нашем случае - gitlab-воркера
DOCKER_CERT_PATH=/root/.docker

# проверим, что в контейнере все имеется
docker info
docker-compose version

# создаем путь (сейчас работаем в клиенте - воркере gitlab'а)
mkdir $DOCKER_CERT_PATH
# изымаем содержимое переменных, при этом удаляем лишние символы добавленные при сохранении переменных.
echo "$CA_PEM" | tr -d 'r' > $DOCKER_CERT_PATH/ca.pem
echo "$CERT_PEM" | tr -d 'r' > $DOCKER_CERT_PATH/cert.pem
echo "$KEY_PEM" | tr -d 'r' > $DOCKER_CERT_PATH/key.pem
# на всякий случай даем только читать
chmod 400 $DOCKER_CERT_PATH/ca.pem
chmod 400 $DOCKER_CERT_PATH/cert.pem
chmod 400 $DOCKER_CERT_PATH/key.pem

# далее начинаем уже работать с удаленным docker-демоном. Собственно, сам деплой
export DOCKER_TLS_VERIFY=1
export DOCKER_HOST=tcp://$DEPLOY_HOST:2376

# проверим, что коннектится все успешно
docker-compose 
  -f $DOCKER_COMPOSE_FILE 
  ps

# логинимся в docker-регистри, тут можете указать свой "местный" регистри
docker login -u $DOCKER_USER -p $DOCKER_PASSWORD

docker-compose 
  -f $DOCKER_COMPOSE_FILE 
  pull app
# поднимаем приложение
docker-compose 
  -f $DOCKER_COMPOSE_FILE 
  up -d app

Основная проблема была в том, чтобы «вытащить» из переменных gitlab CI/CD содержимое сертификатов в нормальном виде. Я не мог понять, почему не работало соединение с удаленным хостом. На хосте посмотрел журнал sudo journalctl -u docker, там ошибка при рукопожатии.

Настройка dockerd

В сценарии запуска демона docker убираем опцию -H df://, эта опция отвечает, на каком хосте можно управлять демоном докера.

# At /lib/systemd/system/docker.service
[Service]
Type=notify
ExecStart=/usr/bin/dockerd

Далее следует создать файл настроек, если его еще нет и прописать опции:

Разрешим подключения по порту 2376:

sudo ufw allow 2376

Перезапустим dockerd с новыми настройками:

sudo systemctl daemon-reload && sudo systemctl restart docker

Проверим:

sudo systemctl status docker

Если все «зеленое», то считаем, что на сервере мы успешно настроили docker.

Настройка git для сертифкатов startssl | александр горбач

Настройка gitlab runner

Финальным этапом настройки среды непрерывной интеграции и развертывания с Docker является подключение рабочего сервиса GitLab CI, на котором будут выполняться все работы по сборке и тестированию приложения.

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

Runner

Подключимся по SSH к серверу Runner. Сперва необходимо установить GitLab Runner и соединить этот сервер с GitLab.Добавим репозиторий разработчиков GitLab:

Настройка секретных переменных в gitlab ci

Мы не будем хранить данные клиентских ключей на машине Runner из соображений безопасности. Для таких задач в GitLab CI реализована функция секретных переменных среды.

Создадим новый проект в GitLab:

После создания проекта перейдем в настройки CI / CD:

Откроем область секретных переменных (Secret variables) и будем работать с ней:

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

Вернёмся к терминалу с сессией на сервере

Manager

и выполним команду:

$ cat ca.pem
(Сокращенный вывод)
-----BEGIN CERTIFICATE-----
MIIFgTCCA2mgAwIBAgIJAMzFvrYTSMoxMA0GCSqGSIb3DQEBCwUAMFcxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
...
bI9XGs39F r8Si5y6oHqkZHMpRX631i2KRA6k4jBPrZrS0MH3OwsCobuat5T1ONH
Kx7TFZSuFO25XIut1WucVn5yPWLTKRniMV7dVws9i9x9Sp2Iamk w2x1GPO6bHtr
BWqdORkUEWMs DTgX2J989AFh7gnYwHZ2Bo7HKlC6IbOlol7b2E/5p7hWrpe7sf 
oQDn1bhgoauhq2AL4BysJfA3uHoA
-----END CERTIFICATE-----

Скопируем это значение и добавим новую секретную переменную в GitLab:

Теперь по этому примеру добавим оставшиеся значения cert.pem и key.pem.

Настройка сервиса docker на управляющем сервере manager

По-умолчанию доступ к сервису Docker имеет только пользователь-владелец процесса. Для выполнения операций по развертыванию приложения с удаленного хоста, нам необходимо разрешить подключение извне, при этом использовать TLS-протокол. Мы уже получили необходимые сертификаты и ключи, осталось настроить Docker для работы с ними.

Мы создадим отдельный конфигурационный файл явно прописывающий хосты, по которым будет доступен Docker, поэтому для начала нам нужно удалить стандартный параметр -H, прописывающий хост. Для этого создадим новую директорию docker.service.d, в которой переопределим параметры запуска сервиса:

$ mkdir -p /etc/systemd/system/docker.service.d

Создадим файл настройки:

$ nano /etc/systemd/system/docker.service.d/exec-start.conf

Добавим следующую секцию, для параметра

ExecStart

требуется сначала очистить предыдущие значения и затем указать новые:

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd

Создадим новый конфигурационный файл:

$ nano  /etc/docker/daemon.json

И запишем следующий текст, определяющим использование протокола TLS для доступа к сервису Docker, а также расположение серверного ключа и сертификата:

{
  "hosts": ["tcp://0.0.0.0:2376","fd://"],
  "tlsverify": true,
  "tlscacert": "/root/certificates/ca.pem",
  "tlscert": "/root/certificates/server-cert.pem",
  "tlskey": "/root/certificates/server-key.pem"
}

Для вступления изменений в силу, перезапустим сервис Docker:

$ systemctl daemon-reload
$ service docker restart

Теперь мы можем подключиться по TLS к нашему сервису Docker по адресу

[IP адрес сервера]:2376

Непрерывная интеграция и доставка

Пришло время самого интересного — запуска и обзора непрерывной интеграции. Для этого просто перейдем в директорию нашего проекта на локальной машине и произведем первый коммит и публикацию в удаленный репозиторий:

$ git add --all
$ git commit -m “init”
$ git push origin master

Если на предыдущих шагах не было совершенно ошибки, произойдет “пуш” в наш репозиторий GitLab, пройдут все тесты и сборка образов Docker, а затем развертывание в Docker Swarm.

Для отслеживания процессов перейдем в GitLab в раздел Pipelines и откроем последний:

Если ваш результат отличается от приведенного, перейдите в раздел Jobs и посмотрите логи по неудавшейся операции, часто это бывают опечатки или неверные адреса серверов.

Перейдем в раздел Environments:

Здесь происходит управление развернутыми средами для различных целей. Сейчас мы используем только среду master, но это не мешает вам настроить их под свои процессы. Если было произведено уже несколько коммитов в одну среду, можно использовать функцию откатывания на предыдущую версию — для этого раскройте среду master, нажатием на название среды:

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

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

Посмотрим на наше приложение. В браузере перейдите по адресу сервера Manager:

Если несколько раз перезагрузить страницу, то заметим, что значение hostname меняется в пределах 4 вариантов, что соответствует количеству реплик, которое мы указали для сервиса web.
Docker Swarm взял на себя контроль по размещению контейнеров между нодами в своей сети. При этом половина контейнеров сервиса web была автоматически размещена в подчиненном ноде. Для просмотра подробной информации можно выполнить следующую команду на сервере Manager, заменив название рабочей среды (если вы его меняли в команде docker stack deploy) на своё:

$ docker stack ps env_name

Мы рассмотрели один из способов применения GitLab CI для настройки непрерывной интеграции и доставки своих Docker-проектов. Следует отметить, что при использовании подобного решения для рабочих проектов следует уделить значительное внимание безопасности — использовать сертификаты доверенных центров, настроить сеть нодов в Docker Swarm для реагирования на перезагрузки серверов и контролировать количество хранимых и используемых образов Docker.

Обновление gitlab

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

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

Обновление gitlab:

# Debian/Ubuntu
sudo apt-get update
sudo apt-get install gitlab-ce

# Centos/RHEL
sudo yum install gitlab-ce

На деле, я подозреваю, на крупных и нагруженных серверах могут быть проблемы. Как минимум, нужно отключить сервер от пользователей и спокойно провести протестированное заранее обновление. В тестовой среде вы скорее всего все проверите без нагрузки. Поэтому на всякий случай, с продуктового сервера тоже снимите нагрузку. Нужно запланировать время простоя на процедуру обновления.

Обновление сервиса docker на машине manager

Подключимся по SSH к серверу

Manager

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

Один лайнер

РЕДАКТИРОВАТЬ: см. Ответ VonC , который указывает на предостережение об абсолютных и относительных путях для конкретных версий git от 2.14.x / 2.15 до этого одного лайнера

Онлайн курс “sre практики и инструменты”

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с

онлайн-курсом “SRE практики и инструменты”

в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и Linux. Обучение длится 3 месяц, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

На курсе вы узнаете как:

• Внедрить SRE практики в своей организации
• Управлять надежностью, доступностью и эффективностью сервисов
• Управлять изменениями
• Осуществлять мониторинг
• Реагировать на инциденты и производительность
• Работать со следующим технологическим стеком: Linux, AWS, GCP, Kubernetes, Ansible, Terraform, Prometheus, Go, Python.

Проверьте себя на вступительном тесте и смотрите подробнее программу по

Ошибка 502 в gitlab

Частенько пользователи gitlab сталкиваются с ошибкой 502 (Whoops, GitLab is taking too much time to respond.). Вам ее показывает nginx. В общем случае это означает, что веб сервер не смог получить ответ от бэкенда. В случае с gitlab бэкендом выступает unix сокет – /var/opt/gitlab/gitlab-workhorse/socket.

Для справки. Конфигурация nginx для gitlab, как и многие другие, располагается по адресу /var/opt/gitlab, конкретно nginx вот тут – /var/opt/gitlab/nginx/conf.

Почему не отвечает бэкаенд и вылезает 502 ошибка наверняка сказать нельзя. Вот самые простые и очевидные причины:

1. У вас мало оперативной памяти на сервере. Если ее только 2 Гб, то ошибку 502 вы можете видеть время от времени, даже если работаете с gitlab один. Для работы nginx, redis, postgresql и прочих элементов гитлаба надо много памяти. Так что если у вас ее 2 гигабайта, просто увеличьте до 4-х и проверьте результат. Как вариант, можете увеличить или включить swap, если у вас его совсем не было.
2. У вас упала служба gitlab-workhorse, которая открывает сокет, который слушает nginx. Почему она упала – отдельный вопрос. Или почему она работает, а сокета нет. Попробуйте просто перезагрузить сервер. Если повторяться ошибка не будет, можете считать, что решили проблему. Одной из причин падений сервиса может быть занятый порт какой-то службы, которая относится к gitlab. Это может случиться, если на сервере, помимо гитлаба работают другие службы. Возможно ошибки в конфиге или проблемы после обновления.
3. По какой-то причине могли измениться права доступа к сокету /var/opt/gitlab/gitlab-workhorse/socket, и nginx не может получить к нему доступ. Исправьте это. Посмотрите от какого пользователя работает nginx и убедитесь в том, что у него хватает прав для доступа к сокету.

Возможно, есть еще какие-то причины появления ошибки 502 в gitlab. Я рассмотрел самые основные, которые покрывают большинство случаев.

Питон, пип и конда

Связанный : Как добавить пользовательский корневой сертификат CA в CA Store, используемый pip в Windows?

Подготовка и настройка инфраструктуры

В боевых условиях для работы системы потребуется три сервера: GitLab — сервер для управления репозиториями Git и Container Registry, Docker для production — сервер для production-сайтов и Docker для разработки — сервер для pre-production и тестовых сайтов разработчиков.

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

У проекта будет один основной репозиторий и по одному репозиторию на каждого разработчика. Основной репозиторий будет источником для production- и staging-сайтов, репозиторий разработчика – для тестового сайта именно этого разработчика. Процессы деплоя для каждого из сайтов будут совпадать.

Отличия будут только в конфигурации приложения и настройках доступа к серверу c Docker. Конфигурация и настройки будут храниться в GitLab, в разделе Settings — CI/CD Pipelines: в основном репозитории – для production- и staging-сайтов, а в репозитории разработчика – для тестового сайта этого разработчика.

Подключение docker registry в gitlab

Перед созданием приложения нам необходимо активировать функцию хранения образов Docker в нашем приложении GitLab для эффективного управления развернутыми версиями приложения и обеспечения возможности отката на предыдущие версии.

Подключимся по SSH к серверу GitLab и откроем конфигурационный файл:

$ nano /etc/gitlab/gitlab.rb

Помогла статья? подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Предварительные требования

Перед началом необходимо удостовериться в выполнении следующих условий:

Официальное

Процесс разработки

На данном этапе у разработчика есть доступ в свой собственный репозиторий. В своём репозитории он имеет роль Developer и может делать практически всё что угодно. В репозитории разработчика ветка master соответствует состоянию его тестового сайта. Protected-ветка stable — состоянию сайта staging.

git fetch --all --prune
git checkout origin/stable
git checkout -b feature-qwerty
git push origin feature-qwerty

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

Также для разработчика в development-окружении доступно расширение xdebug, а управление CSS и Javascript файлами происходит при помощи Webpack Encore.

Развёртывание

На данном этапе docker-образы приложения готовы и загружены в Container Registry. Осталось обновить приложения.

Сборка

Здесь сборка для php-проекта — это создание docker-образов для контейнеров nginx и php, и выкладывание подготовленных образов в GitLab Container Registry.

Здесь, задача build:docker-app-image-master создаёт образы PHP-приложения для staging-сайта (и для тестового сайта разработчика); а задача build:docker-app-image-production — для production-сайта. Для каждой задачи значения переменных из настроек pipeline с суффиксом _MASTER или _PRODUCTION перекрывают дефолтные значения из файла .env.

Также на этом этапе создаётся файл docker-compose.yml, который на следующем этапе будет скопирован на удалённый сервер (см. задачи build:docker-compose-master и build:docker-compose-production). Сформированный файл docker-compose.yml содержит все переменные окружения, необходимые для запуска приложения. В секции services все контейнеры будут создаваться только на основе готовых образов docker.

Системные требования

Официально gitlab поддерживает установку на следующие операционные системы:

1. Debuan, Ubuntu
2. RHEL и производные (CentOS, Oracle Linux, Scientific Linux)
3. openSUSE

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

Системные требования по железу:

1. CPU. Рекомендуется 2 ядра. На одном тоже будет работать, но разработчики предупреждают, что может тормозить при работе каких-нибудь воркеров или задач в фоне. Для старта и знакомства достаточно будет одного ядра.
2. Memory. Установить gitlab на сервер можно только если у него 2 и более гб оперативной памяти. Если меньше, установщик сообщит об ошибке и прекратит работу. Работа с 2 Гб памяти возможна только в тестовом или ознакомительном режиме. Все будет сильно тормозить. Для полноценной работы надо от 4 гб памяти, лучше 8.
3. Storage. Здесь никаких рекомендаций и ограничений нет. Все будет зависеть от сценария использования.
4. Database. Gitlab поддерживает работу с двумя типами БД – PostgreSQL и MySQL. При этом настоятельно рекомендуется использовать PostgreSQL. Она же ставится по-умолчанию.

Создание приложения

Программа будет представлять собой простое веб-приложение, считающее количество посещений и отображающее информацию о контейнере, в котором оно запущено. Для этого нам необходимо создать несколько Dockerfile (файлов конфигурации образа Docker), для каждого используемого сервиса (Nginx, Redis, Flask) и указать, как они должны взаимодействовать между собой.

Откроем страницу проекта, созданного ранее:

Выполним следующую команду для клонирования репозитория и перехода в рабочую директорию, заменив доменное имя:

Создание сервиса nginx

Для сервиса Nginx нам понадобится создать три файла — Dockerfile и два файла настроек. Создадим и запишем общие настройки для всего веб-сервера:

$ nano nginx/nginx.conf

И запишем следующий текст:

Создание сервиса redis

Для сервиса Redis создадим Dockerfile:

$ nano redis/Dockerfile

С простым содержанием:

FROM redis:3.2.11

Мы не вносим дополнительных изменений, но в будущем они вполне возможны, поэтому создадим отдельный сервис.

Создание сервиса с приложением flask

Сервис с приложением Flask начнём с создания основного исполняемого файла:

$ nano web/main.py

Вставим следующий код:

Создание сертификата и ключей

Оставаясь в сервере

Manager

, приступим к созданию сертификационного центра (CA). Перейдем в новую директорию:

$ mkdir certificates
$ cd certificates

Для начала нужно создать приватный и публичный RSA-ключ для CA (потребуется придумать кодовое слово длиной не меньше 4 символов):

$ openssl genrsa -aes256 -out ca-key.pem 4096

Generating RSA private key, 4096 bit long modulus
...............................................................................................................................................................................................................................  
..................................................  
e is 65537 (0x10001)
Enter pass phrase for ca-key.pem:
Verifying - Enter pass phrase for ca-key.pem:

Приступим к созданию локального сертификационного центра. Будут запрошены данные связанные с идентификацией центра. На этапе ввода полного квалифицированного доменного имени (FQDN) требуется ввести доменное имя хоста, по которому доступен сервер

Manager

, но в целях примера (не используйте подобный метод в рабочих машинах!) используем слово

manager

для обозначения сервера:

Создать и удалить проект

Давайте создадим наш первый проект в gitlab. Для этого достаточно на главной странице нажать на Create a Project, либо в любом месте сайта в верхнем меню нажать на .

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

1. Private – доступ только у вас
2. Internal – доступ только у пользователей вашего сайта
3. Public – публичный доступ для всех без аутентификации.

Галочку Initialize repository with a README пока не нажимайте, так как дальше мы инициализируем репозиторий в другом месте и зальем в этот проект.

Проект создали. Теперь покажу, как его удалить в случае необходимости. Там так запрятали этот функционал, что совсем не очевидно, как удалить проект.

Для удаления проекта в gitlab, вам нужно зайти в сам проект. В левом меню выбрать раздел Settings -> General, в самом низу в блоке Advanced нажать на Expand и там уже выбрать Remove Project.

Двигаемся дальше в изучении работы в gitlab.

Сравнение gitlab с github и остальными

Коротко пройдусь по отличиям gitlab от остальных платформ управления git репозиториями, которые в последнее время стали стандартом, вытеснив все остальные системы контроля версий. Сразу предупреждаю, что судить буду по своим поверхностным знаниям указанных систем, так как плотно с ними не работал. Но так как системы известные, некоторой информацией в любом случае обладаю.

Укажите config когда git clone-ing

Если вам нужно применить его для каждого репо, в документации сказано, что вы должны просто запустить его git config –localв своем репо-каталоге. Ну, это бесполезно, если вы еще не клонировали репо локально, не так ли?

Вы можете сделать global -> localhokey-pokey, установив вашу глобальную конфигурацию, как указано выше, а затем скопировать эти настройки в вашу локальную конфигурацию репо, как только она клонируется …

ИЛИ что вы можете сделать, это указать команды config,git clone которые будут применены к целевому репо после его клонирования.

Установка gitlab

Существует несколько способов установки Gitlab:

1. С помощью deb/rpm пактов из репозитория разработчика.
2. Ручная сборка из исходников.
3. Установка в docker контейнере.

Проще всего, к тому же рекомендуется разработчиком, установка готовых пакетов из репозитория. Второй способ подойдет для тех, кто хочет установить Gitlab на систему, для которой нет готовых пакетов. Например, на Freebsd. Процесс этот не сильно сложный, но утомительный, так как gitlab состоит из множества компонентов, которые нужно будет установить и настроить по отдельности, а потом связать между собой.

Третий способ установки через docker контейнер мне вообще не понятен, так как идеология докера – один сервис, один контейнер. А тут будет целая куча сервисов в одном контейнере. В таком случае мне кажется более удобным использовать lxc контейнер, а не docker.

Я буду устанавливать Gitlab первым способом с помощью готовых пакетов из репозитория. Отдельно остановимся на системных требованиях.

Установка на ubuntu

Устанавливаем зависимости, необходимые для работы gitlab:

# apt-get install curl ca-certificates postfix

Подключаем репозиторий gitlab. Для этого используется скрипт, который определяет версию системы и в зависимости от нее подключает нужный репозиторий:

Установка на centos

Устанавливаем зависимости, необходимые для работы gitlab:

# yum install curl policycoreutils-python postfix

Подключаем репозиторий gitlab. Для этого используется скрипт, который определяет версию системы и в зависимости от нее подключает нужный репозиторий:

Установка серверов

Для настройки и запуска приложения в режиме Swarm нам понадобится 2 типа серверов — менеджер и подчиненный. Кроме того, дополнительно один сервер будет выделен под GitLab Runner для выполнения задачи сборки и запуска контейнеров.

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

Создадим три новых сервера из образа Docker:

Полученные IP-адреса мы будем использовать далее.