Первая попытка ci во фронтенде gitlab

внешний интерфейс GitLab Vue.js CircleCI
Первая попытка ci во фронтенде gitlab

В этой статье описано внешнее развертывание 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