GitLab CI: Часть 2, специальные образы

May 11, 2017 16:23 · 416 words · 2 minute read gitlab gitlab ci

В первой статье цикла о настройке GitLab Continuous Integration (GitLab CI) мы упоминали о неких специфических docker-образах, которые будут использоваться в нашем конкретном примере при сборке проекта.

Давайте разберемся, зачем они нам нужны, что это за образы и изучим инструкции в их Dockerfil’ах!

В официальной документации по настройке GitLab CI есть такая строка:

GitLab CI allows you to use Docker Engine to build and test docker-based projects

Так как действительно удобно упаковывать приложение для тестирования или деплоя в docker-контейнер, мы просто обязаны использовать эту возможность! Собственно, именно поэтому при регистрации раннера в предыдущей статье мы указали тип docker (--executor docker) и запускаем раннер в привилегированном режиме (--docker-privileged).

Далее нам необходимо в конфигурационном файле .gitlab-ci.yml (рассматривать который мы будем в следующей статье) указать docker-образ, в котором будут происходить все шаги нашего CI и подключить еще один служебный образ (service).

Со служебным образом должно быть все просто: в официальной документации рекомендуют использовать образ docker:dind, где dind расшифровывается как docker-in-docker. Все бы хорошо, но конкретно в нашем случае используются самоподписанные SSL-сертификаты (о том как их сгенерировать читайте здесь), поэтому нам нужно «встроить» в образ docker:dind свой корневой самоподписанный сертификат.

Для корректной работы с локальным Docker Registry при использовании самоподписанных SSL-сертификатов необходимо добавить корневой сертификат в каталог /etc/docker/certs.d/registry.gitlab.lc:5000 на всех хостах (в т. ч. docker-контейнерах), которые будут взаимодействовать с Registry. Если каталога /etc/docker/ нет, тогда можно добавить корневой сертификат в каталог /usr/local/share/ca-certificates/ (для Ubuntu) и выполнить команду:

update-ca-certificates -f

Наш корневой SSL-сертификат называется ca.crt и находится в каталоге с Dockerfile, в котором описаны инструкции для сборки служебного образа (на замену образу docker:dind). Содержимое Dockerfile следующее:

FROM docker:dind
 
RUN mkdir -p /etc/docker/certs.d/registry.gitlab.lc\:5000
COPY .ca.crt /etc/docker/certs.d/registry.gitlab.lc\:5000/ca.crt
COPY .ca.crt /usr/local/share/ca-certificates/ca.crt
RUN update-ca-certificates -f
 
VOLUME /var/lib/docker
EXPOSE 2375
 
ENTRYPOINT ["dockerd-entrypoint.sh"]
CMD []

Для сборки образа, находясь в каталоге с Dockerfile, запускаем команду:

docker build -t registry.gitlab.lc:5000/develop/ed:my-docker-dind .

Второй необходимый нам образ должен включать в себя docker-compose (очень удобно управлять всеми контейнерами, описав их конфигурацию в одном файле) и ssh-клиент (пригодится в будущем для деплоя образа). Инструкции в Dockerfile выглядят так:

FROM docker:1.13
 
RUN apk add --no-cache py-pip bash openssh-client
RUN pip install docker-compose
RUN if [ ! -d /root/.ssh ]; then mkdir -p /root/.ssh; fi \
 && echo -e "Host *\n StrictHostKeyChecking no\n UserKnownHostsFile=/dev/null\n" >/root/.ssh/config

Собираем образ командой:

docker build -t registry.gitlab.lc:5000/develop/ed:tmaier-dc-ssh .

Пушим только что собранные образы в локальный Docker Registry:

docker push registry.git.labs.lc:5000/develop/ed

В дальнейшем в конфигурационном файле .gitlab-ci.yml для использования данных образов необходимо добавить следующие строки:

image: registry.gitlab.lc:5000/develop/ed:tmaier-dc-ssh
services:
  - registry.gitlab.lc:5000/develop/ed:my-docker-dind
...

но подробнее об этом мы поговорим в следующей статье.

tweet Share