В этой статье описано внешнее развертывание CI Gitlab. Это не Gitlab, построенный на собственном сервере. используетGitlab.comCI Gitlab, небольшой водопровод из шерсти в Tencent Cloud, не может настроить Gitlab, и он по-прежнему не хочет быть сервером CI.
Гитлаб и Гитхаб
Github — это веб-сайт, предоставляющий пользователю пространство для создания репозиториев git и сохранения некоторых документов с данными или кодов пользователей.
Gitlab — это онлайн-репозиторий кода на основе git.Вы можете использовать Gitlab для создания системы, аналогичной Github, которая обычно используется для создания частных серверов Git во внутренних сетях, таких как предприятия и школы.
Что такое непрерывная интеграция
Статья Руан Ифэн очень хорошо написана.Что такое непрерывная интеграция?
Непрерывная интеграция означает частую интеграцию кода в магистраль (несколько раз в день).
Цель непрерывной интеграции — обеспечить быструю итерацию продуктов при сохранении высокого качества. Его основная мера заключается в том, что код должен пройти автоматизированные тесты, прежде чем быть интегрированным в транк. Пока один тестовый пример не пройден, он не может быть интегрирован.
CI для Gitlab
Начиная с GitLab 8.0, GitLab CI интегрирован в GitLab, нам нужно только добавить в проект файл .gitlab-ci.yml, а затем добавить Runner для выполнения непрерывной интеграции. А с обновлением GitLab GitLab CI становится все более и более мощным.
Сначала поймите несколько основных концепций Gitlab CI
GitLab-CI
Это система непрерывной интеграции, используемая с GitLab, она поставляется вместе с GitLab, то есть на сервере, где вы установили GitLab. Не нужно думать об этом. Он отвечает за разбор скрипта .gitlab-ci.yml.
GitLab-Runner
Это носитель выполнения скрипта, а скриптовая часть .gitlab-ci.yml запускается бегуном. После того, как GitLab-CI просматривает файл .gitlab-ci.yml в проекте, он назначается каждому бегуну для запуска соответствующего скрипта в соответствии с внутренними правилами. Некоторые из этих сценариев используются для тестирования проектов, а некоторые — для развертывания.
.gitlab-ci.yml
Это файл в корневом каталоге проекта git, в котором записан ряд этапов и правил выполнения. GitLab-CI проанализирует его после отправки и вызовет раннер для запуска в соответствии с содержимым внутри.
Проще говоря, вы используете управление версиями Git, чтобы отправить локальный код на удаленный (вот ваш gitlab.com), а затем Gitlab уведомляет ваш сервер, который является Gitlab-runner, для запуска задачи сборки. Затем запустите тестовый пример и, когда он будет пройден, сгенерируйте код для создания соответствующей среды и автоматически разверните его на разных серверах среды.
Установите Gitlab Runner
Если вы хотите использовать Docker Runner, вам необходимо установить Docker. (необязательный)
curl -sSL https://get.docker.com/ | sh
Установка GitLab Runner слишком проста, просто следуйте инструкциям из официальной документации! Ниже приведен метод установки Debian/Ubuntu/CentOS Для других систем обратитесь к официальной документации:
# For Debian/Ubuntu
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
$ sudo apt-get install gitlab-ci-multi-runner
# For CentOS
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
$ sudo yum install gitlab-ci-multi-runner
Затем зарегистрируйте Gitlab Runner Runner должен быть зарегистрирован в Gitlab, прежде чем его можно будет использовать в проекте.Служба gitlab-ci-multi-runner может зарегистрировать несколько Runner.
Зарегистрируйте Runner в системе GNU/Linux:
Выполните следующую команду, чтобы начать процесс регистрации:
sudo gitlab-runner register
Введите URL-адрес экземпляра GitLab:
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
Введите полученный токен для регистрации Раннера:
Please enter the gitlab-ci token for this runner
xxx //这个token在你gitlab.com的项目的 setting >> CI/CD >> Runners settings 下
Введите описание для этого Runner, которое также можно изменить позже через пользовательский интерфейс GitLab:
Please enter the gitlab-ci description for this runner
一个配置很低的服务器
Назначьте бегуну теги, которые также можно изменить позже в пользовательском интерфейсе GitLab:
Please enter the gitlab-ci tags for this runner (comma separated):
tengxun // 这个就相当于每一个runner的唯一id,记住这个tag。
Выберите, будет ли Runner принимать задачи без указанных тегов (по умолчанию: false), которые можно изменить позже в пользовательском интерфейсе GitLab:
Whether to run untagged jobs [true/false]:
[false]: true
Выберите, следует ли заблокировать Runner для текущего проекта, который позже также можно будет изменить в пользовательском интерфейсе GitLab. Эта функция обычно используется для Runner, обозначенного как проект (по умолчанию: true):
Whether to lock Runner to current project [true/false]:
[true]: true
Выберите исполнителя Runner:
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker // 我选择的docker,请记住,选择docker的之前要把docker启动,docker的使用就不是本文所讲的了
Если вы выберете Docker в качестве исполнителя, регистратор позволит вам установить образ по умолчанию для проектов, которые не указывают образ в .gitlab-ci.yml:
Please enter the Docker image (eg. ruby:2.1):
alpine:latest
Затем вы обновляете конфигурацию в соответствии с вашими настройками.
Есть маленькая зеленая точка, это означает, что вы успешно зарегистрировали Runner.настроить.gitlab-ci.yml
После настройки Runner все, что нам нужно сделать, это добавить файл .gitlab-ci.yml в корневой каталог проекта. Когда мы добавили файл .gitlab-ci.yml, задача сборки будет автоматически запускаться каждый раз, когда мы фиксируем код или объединяем MR.
Есть некоторые концепции, которые необходимо объяснить в .gitlab-ci.yml.
Pipeline
Конвейер фактически эквивалентен задаче сборки, которая может содержать несколько процессов, таких как установка зависимостей, выполнение тестов, компиляция, развертывание тестовых серверов и развертывание рабочих серверов. Любой из наших коммитов или запросов на слияние может запустить Pipeline. Как показано ниже:
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
Stages
Этапы представляют этап строительства, который является процессом, упомянутым выше. Мы можем определить несколько этапов в одном конвейере, и каждый этап может выполнять разные задачи. Стадии имеют следующие особенности:
- Все этапы будут проходить по порядку, то есть, когда один этап будет завершен, начнется следующий этап.
- Задача сборки (конвейер) будет успешной только после завершения всех этапов.
- Если какой-либо этап завершается сбоем, последующие этапы не будут выполняться, а задача сборки (конвейер) завершится сбоем.
Таким образом, отношения между этапами и конвейером:
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
Jobs
Задания представляют собой строительные работы и представляют работу, выполняемую на этапе. Мы можем определить несколько заданий на этапах, и эти задания будут иметь следующие характеристики:
- Задания на одном этапе будут выполняться параллельно
- Стадия будет успешной только тогда, когда все задания на одной и той же стадии будут успешно выполнены.
- Если какое-либо задание завершается сбоем, то происходит сбой Stage, то есть задача сборки (Pipeline) завершается с ошибкой.
Итак, диаграмма отношений между Джобсом и Стадией:
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
Вот некоторые основные структуры в скрипте развертывания.Далее поговорим об основном составе .gitlab-ci.yml
Ниже приведен сценарий развертывания простейшего проекта Node.
image: node:alpine // 默认的ci部署的docker镜像
stages: // 首先按顺序定义有几个步骤。步骤下面的所有job是同步执行的
- test
- build
job1:
stage: test // 属于test的stage
script:
- npm run test // 这个job执行的脚本
only:
- master // 只监听master分支的代码提交
tags:
- tengxun // 要使用哪个runner
job2:
stage: build
script:
- npm run build
only:
- master
tags:
- tengxun
Обратите внимание, что имена job1 и job2 здесь выбраны произвольно, это не имеет значения, пока не используются ключевые слова Gitlab-CI.
Перечислите некоторые часто используемые ключевые слова, мастер их можно разработать.
ключевые слова | Это необходимо | описывать |
---|---|---|
image | нет | Образы докеров см.dockerДокументация |
services | нет | Информацию о докер-сервисе см.dockerДокументация |
stages | нет | Определение этапов сборки |
types | нет | псевдоним для этапов (устаревший) |
before_script | нет | Определите команду для запуска перед каждым заданием |
after_script | нет | Определите команду для запуска после каждого задания |
variable | нет | Определить переменные сборки |
cache | нет | Определяет список файлов, которые можно использовать при последующих запусках. |
Это хорошая идея, чтобы обнаружить, что эта статья очень четко объясняет каждое ключевое слово. Яснее, чем я написал.
Перевод официального файла конфигурации Gitlab CI yaml
Перед настройкой вам также необходимо определить некоторые переменные сборки в настройках >> CI/CD >> Секретные переменные в соответствующем проекте вашего gitlab.com, потому что ваш Gitlab-CI будет автоматически регистрироваться на сервере, а затем упаковывать файлы.Автоматическое обновление до.
Runner не может зайти на ваш сервер в традиционной форме ввода паролей учетных записей (потому что это автоматизировано, а вам нужно вводить пароли, так какая же это автоматизация). Вы можете войти только через SSH. Если вы не понимаете, как войти через SSH, пожалуйста, погуглите сами. Закрытый ключ не должен быть записан в файле yml, потому что файл yml виден всем, поэтому Gitlab-CI может настроить имя закрытой переменной в проекте. По крайней мере, после того, как проект будет открыт, не все смогут увидеть закрытый ключ сервера развертывания.
Здесь $SSH_PRIVATE_KEY — это закрытый ключ, сгенерированный вашей машиной для разработки (то есть вашим компьютером для разработки). Обязательно скопируйте
-----BEGIN RSA PRIVATE
-----END RSA PRIVATE KEY-----
эти вещи. (Это яма... потому что она редко позволяет скопировать закрытый ключ) Настроенное ниже ${CI_COMMIT_REF_NAME} является ключевым словом по умолчанию для Gitlab CI. Подробнее см. в документации
Наконец, вставьте конфигурацию моей небольшой водопроводной трубы Tencent Cloud, которая пригодится для личного тестирования.
Это действительно очень простой проект vue. Просто используйте vue-cli для его создания, а затем опубликуйте в каталоге, указанном на сервере.Конфигурация nginx на сервере настроена.
stages:
- test
- build
- deploy
cache:
key: ${CI_COMMIT_REF_NAME}
paths:
- node_modules/
test_dev:
image: node:alpine
stage: test
only:
- dev
tags:
- tengxun
script:
- npm run test
build:
image: node:alpine
stage: build
only:
- master
- dev
tags:
- tengxun
script:
- npm set registry https://registry.npm.taobao.org # 设置淘宝镜像地址
- npm install --progress=false
- npm run build
artifacts:
expire_in: 1 week
paths:
- dist
deploy_dev:
image: alpine
stage: deploy
only:
- dev
tags:
- tengxun
script:
- echo "http://mirrors.aliyun.com/alpine/v3.7/main/" > /etc/apk/repositories
- apk add --no-cache rsync openssh
- mkdir -p ~/.ssh
- echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
- chmod 600 ~/.ssh/id_dsa
- echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
- rsync -rav --delete dist/ "$SERVER_USER_HOST:$SERVER_DEV_PATH"
deploy_master:
image: alpine
stage: deploy
only:
- master
tags:
- tengxun
script:
- echo "http://mirrors.aliyun.com/alpine/v3.7/main/" > /etc/apk/repositories
- apk add --no-cache rsync openssh
- mkdir -p ~/.ssh
- echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
- chmod 600 ~/.ssh/id_dsa
- echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
- rsync -rav --delete dist/ "$SERVER_USER_HOST:$SERVER_MASTER_PATH"
when: manual
На самом деле здесь очень просто использовать rsync для синхронизации кода, сгенерированного сборкой.
rsync — это инструмент с открытым исходным кодом, который обеспечивает быструю добавочную передачу файлов. Статьи по Теме
Проще говоря, он позволяет синхронизировать файлы между исходным и целевым компьютерами.
Прикрепите переведенный документ rsyncнажми на меня
В GitLab-CI кеш и артефакты легко спутать.
Среди них кеш относится к кешу, который часто используется при установке зависимости.Например, если нескольким заданиям необходимо установить одну и ту же зависимость, вы можете использовать зависимость, которая может ускорить процесс установки зависимости; Для артефактов артефакт загружается в GitLab для скачивания или последующих операций. Файлы, указанные в .gitignore, будут автоматически удалены, поэтому для зависимой директории установки можно использовать либо кеш, либо артефакты.
Два основных отличия заключаются в следующем:
- Хоть кеш и определен, но если повторяется эта часть кеша и .gitignore, то его все равно нужно переустанавливать
- При переустановке, т.к. используется кеш, очень вероятно, что он не последний
- Особенно в среде разработки, если вы хотите каждый раз использовать последнее обновление, вам следует удалить кеш и использовать артефакты, которые могут гарантировать определенное обновление.
- Части, определенные в артефактах, будут сгенерированы автоматически и могут быть переданы следующему заданию для распаковки, что позволит избежать повторной установки зависимостей и др. Если вы используете Docker для запуска Gitlab-Runner, кэш создаст некоторые временные контейнеры, которые не легко очистить.
- Артефакты могут установить время автоматического истечения срока действия, а истекшее автоматическое удаление
- Артефакты будут сначала загружены на сервер GitLab, а затем при необходимости загружены снова, поэтому эту часть также можно загрузить и просмотреть в GitLab.
Поскольку мы хотим повторно использовать файлы, упакованные предыдущим заданием в dist, я буду использовать артефакты.
when: manual
Здесь мастер — это вообще стабильная версия кода, поэтому его лучше выполнять вручную.when: manual
Его просто нужно развернуть вручную, и все задания по умолчанию выполняются автоматически.
Лу Синь однажды сказал: «Если у вас есть внутренний ускоренный зеркальный адрес, вы должны использовать домашний зеркальный адрес».
Конфигурация адреса образа здесь включает Docker, APK и NPM. Его надо ставить, он тут давно застрял.
Затем мы отправляем код в master и нажимаем на панель CI/CD вашего проекта.
Затем потребовалось 2 минуты, чтобы небольшая водопроводная труба закончила сборку, и я был убит горем. Щелкните треугольник воспроизведения справа, чтобы выполнить развертывание на моем сервере Tencent Cloud. (разумеется, ветка dev автоматически развертывается и развертывается по умолчанию), и это запускает сборку.Что ж, попытка простого фронтенда CI окончена.
это все.
использованная литература
gitlab-ci автоматическое развертывание gitlab Документация GitLab на китайском языке Перевод официального файла конфигурации Gitlab CI yaml Непрерывная интеграция с GitLab CI