CICD

Практика по CI/CD

Тема 1. Основы работы с системой контроля версий git

Тема:

Основы работы с системой контроля версий git. 

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 1.* и вывод по достигнутым результатам.

Каждому шагу в отчёте необходимо дать осмысленное название.

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

Шаг 1.1

Создайте проект с исходным кодом программного обеспечения на компьютере разработки

mkdir ~/my_program

Перейдите в проект

cd ~/my_program

Создайте файл main.c:

touch main.c

поместите в созданный файл следующее содержимое:

#include <stdio.h>

int main() {
    printf("Hello from program!\n");
    return 0;
}

Создайте файл Makefile:

touch Makefile

поместите в созданный файл следующее содержимое:

CC = gcc

TARGET = main
SRC = main.c

CFLAGS = -Wall -Wextra

all: $(TARGET)
$(TARGET): $(SRC)
	$(CC) $(CFLAGS) $(SRC) -o $(TARGET)

run: $(TARGET)
	chmod +x $(TARGET)
	./$(TARGET)

clean:
	rm -f $(TARGET)

Создайте файл .gitignore:

touch .gitignore

поместите в созданный файл следующее содержимое:

main

Шаг 1.2

Перейдите в проект

cd ~/my_program

Соберите программы

make

Сделайте файл получившейся программы исполняемым и запустите

make run

Просмотрите файлы проекта

ls -l

Опишите проделанную работу в отчёте.

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

Шаг 1.3

Перейдите в проект:

cd ~/my_program

Инициализируйте контроль версий кода проекта посредством git:

git init

Переименуйте главную ветку из master в main согласно современным договорённостям разработчиков:

git branch -m main

Посмотрите содержимое файла .git/config

cat .git/config

Добавьте к содержимому этого файла следующие параметры:

[user]
	name = <ваше имя>
	email = <ваш емэйл>

Например:

[user]
	name = petrov_ii
	email = petrov@mail.com

Замените утилиту постраничного просмотра git на cat (это предотвратит необходимость выхода из постраничного навигатора):

git config core.pager cat

Посмотрите повторно содержимое файла .git/config

cat .git/config

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

Подсказка: Для установки параметров name и email в разделе user вместо ручного редактирования файла можно было бы выполнить команды:

git config core.name=petrov_ii
git config core.email=petrov@mail.com

Кстати, если понадобится их поменять, то можно попробовать этот вариант тоже.

Шаг 1.4

Добавьте содержимое каталога к будущему коммиту

git add .

Сделайте коммит:

git commit -m "My first commit"

Просмотрите журнал коммитов:

git log

Внесите изменения в файл main.c (например, измените выводимое текстовое сообщение). Затем просмотрите изменённые файлы в проекте:

git status

Просмотрите также разницу между состоянием файлов проекта в последнем коммите и текущим состоянием:

git diff

Верните состояние файла main.c к состоянию, в котором он был на предыдущем коммите:

git checkout -f main.c

Проверьте содержимое файла

cat main.c

Повторно просмоте статус проекта:

git status

Внесите ещё раз изменения в файл main.c (например, измените выводимое текстовое сообщение). Затем просмотрите изменённые файлы в проекте:

git status

Просмотрите повторно разницу между состоянием файлов проекта в последнем коммите и текущим состоянием:

git diff

На этот раз сохраните изменения в файле путём создания нового коммита. Для этого добавьте изменённый файл к отслеживанию системой контроля версий:

git add main.c

(здесь важно понимать, что, не смотря на то, что когда-то вы уже делали это (git add .), после изменения содержимого файла для добавления изменений в коммит его (файл) нужно повторно добавить к отслеживанию. Т.е. мы добавляем не сам файл, а факт изменения этого файла)

Теперь повторно выполните команду:

git status

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

После сделайте новый коммит:

git commit -m "My second commit"

Просмотрите журнал коммитов:

git log

Также не лишним будет повторно посмотреть и статус

Шаг 1.5

Перейдите в проект

cd ~/my_program

Просмотрите доступные ветки проекта

git branch

Скорее всего в ответ придёт что-то вроде:

* main

Это означает что у вас в проекте одна ветка (branch) и она называется

main

Просмотрите журнал коммитов:

git log

В ответ придёт что-то вроде:

commit 477a3a1f243a7e62806c8239b3f193f839007c02 (HEAD -> main)
Author: petrov_ii <petrov@mail.com>
Date:   Mon Jan 19 11:36:04 2026 +0300

    Second

commit d0b5b111f559379b90f98cf417a372bd55d02774
Author: petrov_ii <petrov@mail.com>
Date:   Mon Jan 19 11:31:20 2026 +0300

    First

Ранее мы могли вернуть изменённый файл main.c к состоянию последнего коммита командой

git checkout -f main.c

Эта команда возвращает содержимое файла main.c на состояние, сохранённое коммитом. При этом то состояние, которое у файла было до выполнения этой команды, будет полностью потеряно.

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

Для этого необходимо выполнить команду:

git checkout <id коммита>

Например

git checkout d0b5b111f559379b90f98cf417a372bd55d02774

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

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

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

git checkout <имя ветки>

Например, в случае с веткой main:

git checkout main

Шаг 1.6

На шаге 1.1 был создан файл:

.gitignore

в котором описаны файлы и каталоги, которые система контроля версий git должна игнорировать.

По этой причине создаваемый при сборке исполняемый файл:

main

Не отображается при выполнении команды:

git status

и не был добавлен при выполнении команды:

git add .

(точка здесь означает все файлы, которые могут быть добавлены к контролю версий. Однако, файла main не было добавлен!).

В git-проекте принято хранить исходный код без продуктов сборки (чем является исполняемый файл main). По этой причине он был добавлен в файл:

.gitignore

, чтобы git игнорировал его.

Шаг 1.7

Измените несколько раз содержимое файла:

main.c

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

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

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

Шаг 1.8

Ответьте на вопросы.

Разместите вопросы и ответы на них в отчёте.

Список вопросов:

1. Какая команда позволяет инициализировать процесс контроля версий в каталоге проекта посредством системы контроля версий git?
2. Какой командой добавить файл test.txt к отслеживанию системой контроля версий git?
3. Какой командой можно сделать коммит, указав сообщение коммита?
3. Укажите путь до имени конфигурационного файла git-проекта относительно каталога git-проекта?
4. Какой командой можно переключить состояние проекта на конкретный коммит?
5. Какой командой можно переключить состояние проекта на самый новый по времени создания коммит?

Тема 2. Основы работы с CI/CD платформой gitlab

Тема:

Основы работы с CI/CD платформой gitlab.

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 2.* и вывод по достигнутым результатам.

Каждому шагу в отчёте необходимо дать осмысленное название.

Шаг 2.1

В теме 1 были рассмотрены основы работы с системой контроля версий git.

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

Однако при совместной работе над кодом только локального контроля версий недостаточно.

Обычно, для синхронизации проекта между разработчиками (или между рабочими местами одного разработчика) в дополнение к системе контроля версий git используются платформы для хранения и обеспечения дополнительных условий для совместной работы над кодом, такие как: GitHub, GitLab, GitFlic и другие...

К общим функциям таких платформ можно отнести:

1. Хранение кода и механизмы предоставления доступа к коду между разработчиками;
2. Подсистема для хранения и обсуждения ошибок и неисправностей (issues) в коде, тесно интегрированная с существующим механизмом коммитов системы контроля версий;
3. Подсистемы обеспечения непрерывной интеграции (CI - Continuous Integration);
4. Подсистемы обеспечения непрерывной доставки (CD - Continuous Delivery);
5. Подсистемы публикации релизов программного обеспечения.

Возможности современных CI/CD платформ, таких как GitHub или GitLab позволяют автоматизировать многие рутинные операции, такие как: тестирование кода, сборка, развёртывание (deployment), выпуск новых версий ПО и др.

Платформа GitLab позволяет использовать свою версию с открытым исходным кодом для самостоятельного развёртывания (self-hosted) энтузиастами или небольшими организациями в пределах локальной сети предприятия или в пределах облачного хостинга организации.

С этой точки зрения для использования в образовательных целях эта платформа также представляет большой интерес.

Дальнейшие основы CI/CD в рамках этого практического пособия будут даны на примере CI/CD платформы GitLab, расположенной по адресу https://gitlab.nntc.nnov.ru

Шаг 2.2

Войдите в свой аккаунт на https://gitlab.nntc.nnov.ru и создайте новый git-репозиторий.

Имя репозитория должно содержать фамилию и инициалы обучающегося.

Например, для обучающегося с ФИО Петров Иван Иванович, проходящего учебную практику, название репозитория может быть таким:

up_petrov_ii_01

В результате будет создан пустой проект.

Этот проект уже имеет правильным образом инициализированную структуру и может быть склонирован на компьютер разработчика. Команда для клонирования проекта в общем виде выглядит так:

git clone https://gitlab.nntc.nnov.ru/<имя пользователя>/<название проекта>.git

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

Как правило эта инструкция автоматически генерируется платформой gitlab и находится в файле:

README.md

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

Хорошим тоном для любого разработчика является переработка файла:

README.md

в соответствии с задачами и целями проекта.

Другими словами: файл

README.md

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

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

Сделать это можно как минимум двумя способами.

Способ 1 (простой)

Склонируйте репозиторий по полной ссылке. Например так:

git clone https://gitlab.nntc.nnov.ru/petrov_ii/up_petrov_ii_01.git

Далее скопируйте из проекта, созданного в процессе изучения темы 1, все файлы, кроме скрытого каталога

.git

(точка в имени означает что каталог скрыт и для его просмотра может понадобиться навык просмотра скрытых файлов и каталогов в зависимости от операционной системы).

Почему нельзя копировать каталог

.git

?

Потому что в склонированном проекте есть уже свой каталог

.git

со своим файлом

config

, который уже корректно настроен с точки зрения интеграции локального репозитория (склонированного командой выше) с удалённым репозиторием gitlab.

Сравните содержимое конфигурационных файлов обоих проектов и вывод отразите в отчёте.

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

Выполните это используя навык, полученный при выполнении задания 1.

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

git push

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

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

У команды

git push

есть "обратная" команда:

git pull

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

Другими словами: отправить изменения в удалённый репозиторий:

git push

, принять изменения из удалянного репозитория в локальный:

git pull

Преимущества и недостатки

Недостатком такого способа является потеря история коммитов, сделанных ранее (поскольку по сути это новый git-репозиторий, с добавленными в него новыми изменениями).

Преимуществом такого способа является простота: не нужно вспоминать дополнительные команды по добавлению ссылки на удалённый репозиторий.

Такой способ удобно использовать, когда код программы до создания репозитория на gitlab не имел версионного контроля ранее (т.е. в каталоге с кодом не был инициализирован git репозиторий. Или был, но историю коммитов "не жалко").

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

Способ 2 (правильный)

Для того чтобы связать существующий локальный git-репозиторий с удалённым репозиторием на платформе gitlab необходимо в локальном репозитории выполнить команду:

git remote add origin https://gitlab.nntc.nnov.ru/<имя пользователя>/<название проекта>.git

Например:

git remote add origin https://gitlab.nntc.nnov.ru/petrov_ii/up_petrov_ii_01.git

затем установить ветку проекта по умолчанию:

git branch -M main

после чего выполнить начальную синхронизацию локального репозитория с удалённым:

git push -uf origin main

В результате в конфигурационный файл локального git-проекта будут внесены соответствующие дополнения и этот проект также будет настроен для синхронизации изменения посредством

git pull

или

git push

аналогично тому, как описано в предыдущем варианте.

При этом вся история коммитов также будет сохранена и синхронизирована.

Преимущества и недостатки

Основным преимуществом такого способа является его лаконичность, логичность и понятность, что позволяет считать этот способ наиболее правильным.

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

Шаг 2.3

Команды

git pull

и

git push

требуют аутентификации. В качестве базового способа аутентификации используется логин и пароль от платформы gitlab.

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

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

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

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

В результате будет открыта страница со списком токенов доступа (у нового проекта может не быть токенов, если вы их ранее не создавали).

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

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

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

Для организации аутентификации проекта необходимо создать токен и задать ему необходимое время жизни. Это можно сделать нажав на кнопку:

Добавить новый токен

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

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

Здесь важно понимать, что на эту страницу вернуться больше возможности не предоставится и созданный таким образом токен посмотреть не получится. Поэтому нужно или скопировать токен на этом этапе, например, в текстовый файл, либо придётся удалять этот токен и создавать новый (и его уже не забывать скопировать заранее).

Обычно токен выглядит примерно так:

glpat-kZdA2AMiqk3_WuoENw_K

Далее этот токен можно применить либо к уже склонированному проекту, либо выполнить клонирование проекта, сразу внедрив токен в url репозитория.

В уже склонированном проекте необходимо открыть файл:

.git/config

найти в нём примерно такую конструкцию:

 [remote "origin"]
	url = https://gitlab.nntc.nnov.ru/petrov_ii/up_petrov_ii_01.git
	fetch = +refs/heads/*:refs/remotes/origin/*

и заменить её на следующую:

 [remote "origin"]
	url = https://-:glpat-kZdA2AMiqk3_WuoENw_K@gitlab.nntc.nnov.ru/petrov_ii/up_petrov_ii_01.git
	fetch = +refs/heads/*:refs/remotes/origin/*

затем сохранить файл.

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

https://gitlab.nntc.nnov.ru/petrov_ii/up_petrov_ii_01.git

получить url с токеном:

https://-:glpat-kZdA2AMiqk3_WuoENw_K@gitlab.nntc.nnov.ru/petrov_ii/up_petrov_ii_01.git

затем склорировать проект по полученному url:

git clone https://-:glpat-kZdA2AMiqk3_WuoENw_K@gitlab.nntc.nnov.ru/petrov_ii/up_petrov_ii_01.git

В результате проект будет склонирован по изменённому url и этот изменённый url сразу окажется в конфигурационном файле внутри склонированного репозитория.

Принцип подстановки токена в url аналогичен принципам базовой аутентификации в протоколах типа ftp://, http:// и других. В общем виде это выглядит так:

<протокол>://<логин>:<пароль>@<хост>/<строка_пути>

В нашем случае роль логина играет дефис, а токен является временным паролем:

https://-:glpat-kZdA2AMiqk3_WuoENw_K@gitlab.nntc.nnov.ru/petrov_ii/up_petrov_ii_01.git

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

В целях безопасности рекомендуется устанавливать не слишком большое время жизни токена.

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

Шаг 2.4

Проделайте действия, описанные в обоих способах. Отразите работу в отчёте.

Разместите вопросы и ответы на них в отчёте.

Список вопросов:

1. Что происходит при выполнении команды git push?
2. Что происходит при выполнении команды git pull?
3. Происходит ли синхронизация состояния локального репозитория с удалённым сразу после коммита?
4. Необходимы ли логин и пароль для обеспечения контроля версий в локальном каталоге проекта?
5. Необходимо ли выполнять команду git commit для обеспечения контроля версий в локальном каталоге проекта?
6. Необходимо ли выполнять команду git push для обеспечения контроля версий в локальном каталоге проекта?

Тема 3. Установка gitlab-runner на GNU/Linux хост

Тема:

Организация доступа на GNU/Linux хост посредством протокола ssh. Установка gitlab-runner на GNU/Linux хост.

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 3.* и вывод по достигнутым результатам.

Каждому шагу в отчёте необходимо дать осмысленное название.

Шаг 3.1

Посредством утилиты:

ssh-keygen

создайте ключевую пару (открытую и закрытую части криптографического ключа).

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

id_ed25519
id_ed25519.pub

или:

id_rsa
id_rsa.pub

(в зависимости от типа шифрования, настроенного операционной системе, на которой создаётся ключевая пара).

Файл с суффиксом:

.pub

содержит открытую часть ключа. Второй файл, соответственно, содержит закрытую часть ключа.

Закрытую часть сохраните у себя и ни кому не передавайте (это ваш будущий ключ от удалённого GNU/Linux хоста).

Содержимое открытой части ключа добавьте к содержимому файла:

authorized_keys

, который обычно находится в каталоге:

.ssh

внутри домашнего каталога пользователя, под которым вы планируете подключаться на GNU/Linux хост по протоколу ssh.

Да, верно: открытую часть ключа следует доставить на удалённый GNU/Linux хост и положить в выше упомянутый файл в выше упомянутом каталоге того пользователя удалённого GNU/Linux хоста, под которым планируется подключение.

Шаг 3.2

Для процедуры доставки открытой части ключа можно воспользоваться утилитой:

ssh-copy-id

(если это позволяют настройки безопасности удалённого GNU/Linux хоста) либо в ручном режиме переместить содержимое открытого ключа в необходимый файл на удалённом хосте, предварительно подключившись на удалённый GNU/Linux хост по протоколу ssh по логину и паролю.

При корректной настройке удалённого GNU/Linux хоста к нему можно будет подключаться, используя закрытую часть ключа, командой, общий вид которой следующий:

ssh -i </путь/до/закрытой_части_ключа> <пользователь>@<хост_или_ip_адрес> -p <порт>

Если порт ssh сервера, к которому производится подключение, стандартный (22), то ключ -p с номером порта в команде можно опустить.

Пример команды:

ssh -i ~/.ssh/id_ed25519 user@10.207.123.123 -p 22

При выполнении такой команды подразумевается, что содержимое файла:

id_ed25519.pub

находится в файле:

/home/user/.ssh/authorized_keys

на GNU/Linux хосте с ip-адресом:

10.207.123.123

а ssh сервер работает на этом же хосте на стандартном порту

22

(как уже говорилось выше, ключ -p 22 в команде можно опустить, если порт сервера стандартный -- 22-й).

Шаг 3.3

Предыдущие два шага демонстрируют процесс настройки БЕЗОПАСНОГО доступа на уалённый сервер.

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

Следовательно, категорически не рекомендуется оставлять доступ по паролю на удалённый сервер!

Когда доступ на удалённый сервер (GNU/Linux хост) получен, на нём необходимо установить и настроить средство выполнения для gitlab.

Это программное обеспечение называется:

gitlab-runner

В некоторых GNU/Linux дистрибутивов gitlab-runner может входить в состав репозитория программного обеспечения.

Далее будет рассмотрена процедура установки средства выполнения "gitlab-runner" универсальным способом.

Шаг 3.4

1. Подключитесь к серверу по протоколу ssh;

2. Перейдите в режим суперпользователя;

3. Загрузите бинарную версию средства выполнения "gitlab-runner" для сервера архитектуры x86_64 (она же amd64) командой:

curl -L --output /usr/local/bin/gitlab-runner https://wiki.nntc.nnov.ru/download/gitlab-runner-linux-amd64

4. Сделайте загруженный файл исполняемым:

chmod +x /usr/local/bin/gitlab-runner

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

useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

6. Установите и запустите средство выполнения как сервис

gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
gitlab-runner start

Готовые бинарные сборки средства выполнения "gitlab-runner" существуют также под архитектуры 386, arm и arm64.

Для снижения нагрузки на интернет-канал лабораторий колледжа в команде (п.3) установки используется локальная ссылка.

Более подробную информацию по установке средства выполнения можно получить здесь

На этом этапе на GNU/Linux хост установлено средство выполнения "gitlab-runner", посредством которого можно будет выполнять непрерывную интеграцию (CI) и непрерывную поставку/доставку контента (CD).

Для этого необходимо связать gitlab-репозиторий со средством выполнения. Об этом подробно расскзано в теме 1.

Шаг 3.5

Сделайте полный вывод о проделанной работе по теме 0.

Шаг 3.6

Ответьте на вопросы и разместите вопросы и ответы на них в отчёте.

Список вопросов:

1. Для чего нужна утилита ssh-keygen?
2. Для чего нужна утилита ssh-copy-id?
3. Для чего нужен файл ~/.ssh/authorized_keys?
4. Сколько файлов создаётся при создании ключа ssh?
5. Для чего служит средство выполнения "gitlab-runner" на сервере, на котором оно установлено и запущено?

Тема 4. Настройка gitlab-runner на работу с репозиторием gitlab

Тема:

Настройка gitlab-runner на работу с репозиторием gitlab.

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 4.* и вывод по достигнутым результатам.
Название gitlab-проекта обязательно должно включать фамилию обучающегося.

Отчёт должен содержать ссылку на существующий git-репозиторий, описанный в отчёте.

Каждому шагу в отчёте необходимо дать осмысленное название.

Шаг 4.1

Войдите в свой аккаунт на https://gitlab.nntc.nnov.ru и создайте новый git-репозиторий.

Имя репозитория должно содержать фамилию и инициалы обучающегося.

Например, для обучающегося с ФИО Петров Иван Иванович, проходящего учебную практику, название репозитория может быть таким:

up_petrov_ii_02

Шаг 4.2

Перейдите на страницу созданного репозитория.

Найдите раздел "Средства выполнения" в меню "Настройки - CI/CD"

Создайте средство выполнения, заполнив форму следующим образом:

Теги:

test

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

Создать средство выполнения

На следующей странице ознакомьтесь с пошаговой инструкцией по запуску средства выполнения gitlab-runner (пройдите по предлагаемым ссылкам инструкции чтобы ознакомиться наиболее полно!), скопируйте команды, которые в последующем понадобятся для запуска средства выполнения на GNU/Linux хосте, затем нажмите на кнопку:

Просмотр средств выполнения

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

#20 (LDBWhOpr)

Шаг 4.3

Рядом с созданным на предыдущем шаге средством выполнения будет показан треугольный значок с восклицательным знаком. Это означает, что gitlab не подключился к средству выполнения на GNU/Linux хосте. Теперь необходимо это настроить.

Используйте скопированные ранее команды чтобы зарегистрировать средство выполнения на GNU/Linux хосте. Для этого:

1. Войдите на GNU/Linux хост по протоколу ssh;

2. Выполните команду для регистрации средства выполнения;

3. Перейдите на страницу "Средства выполнения" проекта;

4. Убедитесь что треугольный значок с восклицательным знаком пропал и на его месте появился зелёный кружок, символизирующий успешное подключение gitlab к средству выполнения (к gitlab-runner-у).

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

Шаг 4.4

Склонируйте ваш репозиторий себе на компьютер и создайте внутри файл

.gitlab-ci.yml

со следующим содержимым

stages:
  - test

hello_job:
  stage: test
  tags:
    - test
  script:
    - echo "Hello from GitLab CI"
    - uname -a
    - echo "Hello from GitLab CI" > /tmp/test
    - uname -a >> /tmp/test

Сделайте коммит (git commit) и синхронизируйте изменения с репозиторием (git push).

Затем перейдите в средство выполнения ("Сборка" - "Средства выполнения") в меню вашего репозитория в gitlab и посмотрите статус задания.

Опишите результат в отчёт.

Затем войдите по протоколу ssh на GNU/Linux хост, на котором работает средство выполнения и просмотрите содержимое файла:

/tmp/test

Опишите результат исследования файла на GNU/Linux хосте.

Шаг 4.5

Сделайте вывод о проделанной работе по теме 1.

Опишите связь между работой средства выполнения и содержимым файла:

.gitlab-ci.yml

Шаг 4.6

Ответьте на вопросы.

Разместите вопросы и ответы на них в отчёте.

Список вопросов:

1. Сколько команд будет выполнено средством выполнения?
2. Какие именно это команды?
3. Какие команды формируют содержимое файла test в каталоге /tmp GNU/Linux хоста?
4. Как связано название стадии (stage) и названия тегов, указываемых при конфигурировании средства выполнения?
5. На что влияют названия тегов, указываемых при конфигурирования средства выполнения?

Тема 5. Стадии CI (stages) и взаимодействие между ними посредством артефактов

Тема:

Стадии CI и взаимодействие между ними посредством артефактов.

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 5.* и вывод по достигнутым результатам.

Каждому шагу в отчёте необходимо дать осмысленное название.

Тема 6. Создание релизов программного обеспечения.

Тема:

Создание релизов программного обеспечения.

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 6.* и вывод по достигнутым результатам.

Каждому шагу в отчёте необходимо дать осмысленное название.

Тема 7. Контрольное задание

Тема:

Контрольное задание

Отчёт:

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

1. Не менее пяти стадий (stages) в файле .gitlab-ci.yaml;
2. Не менее двух стадий должны обмениваться артефактами (один или более артефакт);
3. Финальная стадия должна публиковать релиз программного обеспечения.