Введение
Содержание, представленное в этой статье, включает в себя:
- Понимание CI/CD и его необходимости
- установка и регистрация gitlab-runner
- инструкции по настройке gitlab-ci
- Вход без пароля через SSH
- файл развертывания rsync
- Выпуск в нескольких средах и откат
- Частые проблемы и решения
Для прочтения этой статьи вам необходимо:
- Иметь определенную базу знаний ssh, копиюРуководство по работе с SSH
- Концептуальная основа gitlab ci/cd
- Займите около 10 минут
2. Научно-популярная CI/CD
2.1 КИ и КД
Непрерывная интеграция относится к процессу, в котором разработчики отправляют код в ветки функций (часто), немедленно выполняют сборки и модульные тесты и интегрируют код в магистраль после прохождения стандартов тестирования. Акцент делается на отправке, сборке и модульном тестировании кода ответвления, а результатом этого процесса является отчет модульного тестирования.
Непрерывная доставка основана на непрерывной интеграции, развертывании созданного кода в «производственной среде» и после завершения тестирования QA.Развертывание вручнуюпроцесса в среду сборки. Акцент делается на развертывании кода, этот процесс создает отчеты о тестировании.
Непрерывное развертывание — это следующий шаг в непрерывном взаимодействии, в котором особое внимание уделяется процессу развертывания производственного кода.автоматизацияи может обрабатывать такие операции, как онлайн-уведомления.
2.2 Необходимость CI/CD
В двух словах я думаю, что это должно быть так: пусть машина делает механические вещи. Команда разработки без CI/CD, думаю, может быть так: невозможно управлять кодом и сотрудничать со многими людьми (git-репозиторий тоже часть CI), ряд шеллов нужно обрабатывать вручную, выпуск кода требует входа на сервер и т. д.; Наоборот, с CI/CD эти вещи оставляются на усмотрение машины, высвобождая фрагментированное время для более значимых вещей (таких как рыбалка и отдых) .
2.3 Как должен выглядеть идеальный процесс разработки CI/CD?
Я думаю, что идеальный процесс разработки CI/CD должен состоять из трех этапов:build,deployа такжеnotify. Фаза сборки фокусируется на построении кода и модульном тестировании, фаза развертывания — на развертывании кода в среде test/grey/prod, а фаза уведомления — на онлайн-уведомлениях, как показано ниже.
Следующий контент завершается на двух этапах сборки и развертывания:развертывание от 0 до 1. Системная среда автора: Ubuntu 18.04.1 LTS
3. Установка и регистрация Gitlab-Runner
3.1 Установка бегунка
sudo apt-get install gitlab-runner
Официальная документация сайтаinstall gitlab-runner
3.2 Зарегистрировать бегуна
sudo gitlab-runner register
После операции в стиле QA вы можете ввести информацию в соответствии с подсказкой, вы можете обратиться кРабота официального сайта, требует внимания:
①. Хост и токен gitlab находятся в вашем проекте gitlab. Путь к странице: Настройки >> CI/CD >> Runners
②.Исполнитель раннера выбирает докер, ввод изображения (изображения)node:8.11.2-stretch
После успешной регистрации мы можем увидеть наш зарегистрированный бегун в разделе: Настройки >> CI/CD >> Runners.
В-четвертых, конфигурация Gitlab-Runner
Создайте новый проект в корневом каталоге проекта.gitlab.ymlфайл, добавьте следующее:
unit_test,compileа такжеdeploy_testЭто пользовательское имя задания и несколько других инструкций по настройке:
-
cache: cache задает файл кеша, в котором кэшируется пакет зависимостей node_module для повышения эффективности построения задания, он определен глобально и действует для всех заданий; -
stage: Настройте два этапа сборки и развертывания -
artifacts: загрузить файл. Определите папку dist, созданную при компиляции, и кэшируйте ее на сервере gitlab, предоставьте загрузку (загрузку с веб-страницы gitlab) или поделитесь ею между заданиями на одном этапе; -
only: Определите условия срабатывания задания, вы можете указать имя ветки,tags(срабатывает при пометке) и т. д. (эти условия являются отношением ИЛИ, и срабатывает одно из этих условий); -
when: Определите время запуска задания, значение может быть:on_success,always,manualЖдать; -
dependencies: Определите задание, от которого зависит текущее задание; -
environment: Определите среду, к которой принадлежит текущее задание, что очень полезно для операций отката, которые будут подробно описаны позже; - deploy_test этой работы
before_scriptЕсть длинный раздел контента, роль здесь заключается в настройке входа без пароля по ssh, который будет подробно описан позже.
Пять, ssh вход без пароля
5.1 Зачем нужен вход без пароля?
- Файл dist, созданный сборкой, должен быть передан на целевой сервер (тестер/генератор) либо на основе сетевого протокола http, либо на основе протокола ssh (или другого протокола передачи файлов?)
- На базе http нужно написать интерфейс приема файлов.Здесь напрямую используется передача файлов на базе ssh.rsync, Просто и безопасно!
- Ряд скриптов, определенных в runner, выполняются в док-контейнере, и в них нельзя вмешиваться вручную, поэтому сервер входа в систему должен быть защищен от пароля.
Во-первых, настройте процесс входа в систему без пароля на локальной машине (машине, на которой находится зарегистрированный бегун):
5.2. Сгенерируйте пару открытого и закрытого ключей
Используйте rsa как асимметричное шифрование:
ssh-keygen -t rsa -C "$(whoami)@$(hostname)-$(date -I)"
иллюстрировать: Просто введите до конца, не забудьте ввести сразу при вводе парольной фразы, этоno passphrase. Если вам нужно добавить пароль, извините, не поможет!
5.3. Определение содержимого конфигурации ssh
Напишите следующее в файле ~/.ssh/config (файл не существует и создайте его напрямую):
Host any_name
Port your_port
HostName server_ip
User user
IdentityFile ~/.ssh/id_rsa
иллюстрировать: файл конфигурации, который определяет ssh, предназначен для быстрого доступа, точно так же, как вы настраиваете хост, без имени хоста вы можете получить доступ только по ip. После настройки вы можете пройтиssh any_nameВойдите на сервер. Разумеется, не случайно вас попросят ввести логин-пароль сервера.
5.4 Вход без пароля
Суть входа без пароля заключается в хранении локального открытого ключа в файле author_keys целевого сервера (файл-сервер не существует и может быть создан напрямую).
ssh-copy-id -i ~/.ssh/id_rsa.pub username@ip
Особенно: Если ваш порт не является портом 22 по умолчанию, добавьте номер порта-p PORT
5.5. Аутентификация входа
ssh any_name
Неудивительно, что вы должны иметь возможность войти непосредственно на сервер. Итак, вернемся к настройке gitlab~
6. Определите информацию о конфигурации ssh на gitlab
Мы вводим местоположение страницы gitlab: Настройки >> CI / CD >> Определено в разделе «Переменные среды»..gitlab.ymlНесколько переменных появляются на:
-
SSH_PRIVATE_KEY: Скопируйте закрытый ключ этой машины (машины, на которой находится бегун): ~/.ssh/id_rsa -
TEST_CONFIG: Только что скопируйте информацию, определенную конфигурацией ssh: ~/.ssh/config -
TEST_KNOWN_HOST: эта переменная определена, чтобы позволить ssh аутентифицировать сервер (в противном случае он будет считаться ненадежной средой для ssh).Значение переменной генерируется с помощью следующей команды:
ssh-keyscan -p PORT IP
7. Используйте rsync для передачи файлов
rsync -rve ssh dist/ user@hostname:project_path/dist
иллюстрировать:hostnameВыssh configОпределенныйHostстоимость.руководство по работе с rsync
Восемь, определите окружающую среду
Преимущество настройки среды заключается в том, что вы можете управлять каждой средой выпуска, особенно онлайн-выпуском, и вы можете откатиться во времени, если есть ошибка. На веб-странице gitlab: Операции >> среды вы можете просмотреть среды в текущем проекте и нажать кнопку предварительного просмотра справа, чтобы просмотреть эффект выпуска соответствующей среды.
environment：test_env, вы можете просмотреть все записи о выпуске в текущей среде, а кнопка справа может выполнить операцию отката.Девять, наступи на ноты ямы
На протяжении всего процесса создания многие из них связаны с входом на сервер по ssh.Выберите несколько часто встречающихся проблем, которые нужно объяснить:
9.1. Host key verification failed
Когда мы впервые используем ssh для входа на сервер, ssh спроситАутентифицировать личность удаленного сервера, подключение не разрешено до тех пор, пока не будет выполнена аутентификация. Есть два способа решить эту проблему:
-
Настройка без аутентификации:
Добавьте абзац в конфигурацию конфигурации ssh
StrictHostKeyChecking no,в этом случае.gitlab.ymlВы можете удалить околоknown_hostsустановлен; - Аутентификация по отпечатку открытого ключа удаленного сервера:
ssh-keyscan -p PORT IP
Сохраните вывод скрипта в~/.ssh/known_hostsфайл (упомянутый в разделе, определяющем информацию о конфигурации ssh на @gitlab), так что ssh получит отпечаток открытого ключа целевого сервера из файла для подтверждения личности перед входом в систему.
9.2. Permission denied, please try again
Эта проблема возникает из-за того, что не настроен «вход без пароля через ssh».
9.3. rsync: Failed to exec a: No such file or directory
Эта проблема не возникает при нормальных обстоятельствах, но это настоящая яма. Я загружаю каталог dist, сгенерированный сборкой, на сервер через rsync в задании развертывания и выдаю ошибку, что каталог не существует.
После выполнения задания компиляции я перечисляю файлы/папки в корневом каталоге (вывод gitlab-runner):
release-[timestamp]Мягкая ссылка каталога (я использую Ubuntu, и в конфигурации веб-пакета задана хитрость: каждая сборка создает одинrelease-[timestamp]каталог, устанавливая мягкую ссылку. Мягкая ссылка не является каталогом, ее содержимое является адресом целевой папки).
в моем.gitlab.ymlВ конфигурации,artifactsкэшируетсяdist, не помещая фактическую папкуrelease-[timestamp]Кэш, то при входе на следующую работу естественно выдаст, что директория не существует. Решение:
cp dist public
существуетcompileВ этом задании скопируйте каталог dist после создания, а затем скопируйтеpublicСправочник переданartifactsкеш.