Обзор
Добро пожаловать в очередную часть моей серии «Советы профи по GitHub Codespaces». В прошлой части мы говорили об интеграции GitHub с Azure DevOps и о том, как вы можете использовать некоторые замечательные возможности GitHub, такие как Codespaces, вместе с Azure DevOps.
В сегодняшней статье я расскажу вам о том, как можно использовать кодовое пространство GitHub не только в качестве «среды разработки» для работы с кодом, но и задействовать вычислительную мощь кодового пространства, запустив в кодовом пространстве одновременно Self Hosted GitHub runner.
Мы будем использовать пользовательский образ docker, который будет автоматически предоставлять агент саморазмещающегося runner и регистрировать его одновременно с предоставлением Codespace в качестве части среды разработки.
Мы также рассмотрим жизненный цикл Codespace/Runner. По умолчанию все активные кодовые пространства, которые простаивают, переходят в спящий режим через 30 минут для экономии вычислительных затрат, поэтому мы рассмотрим, как можно настроить и продлить (при необходимости) этот тайм-аут.
На самом деле мы будем использовать очень похожий подход для конфигурации образа докера, основанный на одной из моих предыдущих записей в блоге, «Создание контейнера Self Hosted GitHub runner Linux на базе Docker». Ознакомьтесь с этой статьей, если вам нужна дополнительная информация о том, как работают саморазмещающиеся контейнеры GitHub runner.
Начало работы
Все примеры и образцы кода также доступны в моем демо-репозитории GitHub Codespaces.
Поскольку контейнеры Codespaces/Dev основаны на образах docker, мы создадим собственный образ linux docker, который будет запускать и загружать runner agent при запуске кодового пространства.
Мы создадим следующее дерево структуры папок в корне нашего репозитория GitHub:
В вашем репозитории GitHub создайте подпапку '.devcontainer', в моем случае я назвал папку конфигурации кодового пространства 'codespaceRunner'.
Затем создайте следующий Dockerfile:
# You can pick any Debian/Ubuntu-based image. 😊
FROM mcr.microsoft.com/vscode/devcontainers/base:0-bullseye
# [Optional] Install zsh
ARG INSTALL_ZSH="true"
# [Optional] Upgrade OS packages to their latest versions
ARG UPGRADE_PACKAGES="false"
# Install needed packages and setup non-root user. Use a separate RUN statement to add your own dependencies.
ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=$USER_UID
COPY library-scripts/*.sh /tmp/library-scripts/
RUN bash /tmp/library-scripts/common-debian.sh "${INSTALL_ZSH}" "${USERNAME}" "${USER_UID}" "${USER_GID}" "${UPGRADE_PACKAGES}" "true" "true"
# cd into the user directory, download and unzip the github actions runner
RUN cd /home/vscode && mkdir actions-runner && cd actions-runner
#input GitHub runner version argument
ARG RUNNER_VERSION="2.292.0"
RUN cd /home/vscode/actions-runner
&& curl -O -L https://github.com/actions/runner/releases/download/v${RUNNER_VERSION}/actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz
&& tar xzf /home/vscode/actions-runner/actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz
&& /home/vscode/actions-runner/bin/installdependencies.sh
# copy over the start.sh script
COPY library-scripts/start.sh /home/vscode/actions-runner/start.sh
# Apply ownership of home folder
RUN chown -R vscode ~vscode
# make the script executable
RUN chmod +x /home/vscode/actions-runner/start.sh
# Clean up
RUN rm -rf /var/lib/apt/lists/* /tmp/library-scripts
Затем создайте файл 'devcontainer.json'. (См. мою предыдущую статью в блоге о том, как этот файл может быть изменен с помощью дополнительных функций и расширений):
{
"name": "CodespaceRunner",
"dockerFile": "Dockerfile",
// Configure tool-specific properties.
"customizations": {
// Configure properties specific to VS Code.
"vscode": {
// Add the IDs of extensions you want installed when the container is created.
"extensions": [
"ms-vscode.azurecli",
"ms-vscode.powershell",
"hashicorp.terraform",
"esbenp.prettier-vscode",
"tfsec.tfsec"
]
}
},
// Use 'forwardPorts' to make a list of ports inside the container available locally.
// "forwardPorts": [],
// Use 'postStartCommand' to run commands each time the container is successfully started..
"postStartCommand": "/home/vscode/actions-runner/start.sh",
// Comment out to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
"remoteUser": "vscode",
// Amend GitHub runner version with 'RUNNER_VERSION'. https://github.com/actions/runner/releases.
"build": {
"args": {
"UPGRADE_PACKAGES": "true",
"RUNNER_VERSION": "2.295.0"
}
},
"features": {
"terraform": "latest",
"azure-cli": "latest",
"git-lfs": "latest",
"github-cli": "latest",
"powershell": "latest"
}
}
ПРИМЕЧАНИЕ: Вы можете изменить версию бегущей строки на GitHub, изменив атрибут build args RUNNER_VERSION.
// Amend GitHub runner version with 'RUNNER_VERSION'. https://github.com/actions/runner/releases.
"build": {
"args": {
"UPGRADE_PACKAGES": "true",
"RUNNER_VERSION": "2.295.0"
}
Далее мы создадим папку с несколькими скриптами, которые будут использоваться нашим докер-образом.
Создадим папку 'library-scripts' и поместим в нее следующие два скрипта: ‘start.sh’ и ‘common-debian.sh’.
Давайте рассмотрим каждый из скриптов подробнее.
-
common-debian.sh: Этот скрипт установит дополнительные инструменты на базе debian в контейнер dev.
-
start.sh:
#start.sh
#!/bin/bash
GH_OWNER=$GH_OWNER
GH_REPOSITORY=$GH_REPOSITORY
GH_TOKEN=$GH_TOKEN
HOSTNAME=$(hostname)
RUNNER_SUFFIX="runner"
RUNNER_NAME="${HOSTNAME}-${RUNNER_SUFFIX}"
USER_NAME_LABEL=$(git config --get user.name)
REPO_NAME_LABEL="$GH_REPOSITORY"
REG_TOKEN=$(curl -sX POST -H "Accept: application/vnd.github.v3+json" -H "Authorization: token ${GH_TOKEN}" https://api.github.com/repos/${GH_OWNER}/${GH_REPOSITORY}/actions/runners/registration-token | jq .token --raw-output)
/home/vscode/actions-runner/config.sh --unattended --url https://github.com/${GH_OWNER}/${GH_REPOSITORY} --token ${REG_TOKEN} --name ${RUNNER_NAME} --labels ${USER_NAME_LABEL},${REPO_NAME_LABEL}
/home/vscode/actions-runner/run.sh
Второй скрипт запустит контейнер Codespace/Dev и загрузит GitHub runner при запуске Codespace. Обратите внимание, что нам нужно указать скрипту некоторые параметры:
GH_OWNER=$GH_OWNER
GH_REPOSITORY=$GH_REPOSITORY
GH_TOKEN=$GH_TOKEN
Эти параметры (переменные окружения) используются для настройки и регистрации саморазмещаемого бегуна github в нужном репозитории.
Нам нужно указать имя учетной записи/организации GitHub через переменную окружения 'GH_OWNER', имя репозитория через GH_REPOSITORY и PAT-токен через GH_TOKEN.
Вы можете хранить конфиденциальную информацию, такую как токены, к которой вы хотите получить доступ в своих кодовых пространствах через переменные окружения. Давайте настроим эти параметры как зашифрованные секреты для кодовых пространств.
-
Перейдите на страницу репозитория
'Settings'и выберите'Secrets -> Codespaces', нажмите на'New repository secret'.
-
Создайте каждый секрет кодового пространства со значениями для вашей среды.
ПРИМЕЧАНИЕ: Когда саморазмещаемый бегунок будет запущен и зарегистрирован, он также будет помечен ‘именем пользователя’ и ‘именем хранилища’ из следующих строк. (При необходимости эти метки могут быть изменены):
USER_NAME_LABEL=$(git config --get user.name)
REPO_NAME_LABEL="$GH_REPOSITORY"
Примечание о персональном маркере доступа (PAT)
О том, как создать персональный токен доступа, см. в разделе Создание персонального токена доступа на GitHub PAT. Токены PAT отображаются только один раз и являются конфиденциальными, поэтому обеспечьте их сохранность.
Для регистрации саморазмещаемого бегуна токену PAT требуются следующие минимальные диапазоны прав: "repo", "read:org":
Совет: Я рекомендую использовать только токены PAT с коротким сроком действия и генерировать новые токены каждый раз, когда требуется регистрация новых бегунов-агентов.
Развертывание бегуна Codespace на GitHub
Как видно на скриншоте ниже, в моем репозитории нет настроенных бегунов.
-
Перейдите в свой репозиторий, нажмите на выпадающий список
'<> Code'и выберите вкладку'Codespaces', выберите опцию'Advanced'для настройки и создания кодового пространства. -
Выберите соответствующий
'Branch','Region','Machine type'и для'Dev container configuration'выберите созданную нами конфигурацию'codespaceRunner'и нажмите на'Createcodespace'.
Создание и запуск контейнера займет несколько минут, но вы можете просматривать журналы, пока кодовое пространство создается в режиме реального времени.
Чтобы ускорить создание кодового пространства, администраторы хранилища могут включить предварительную сборку кодового пространства для хранилища. Дополнительную информацию см. в разделе «О предварительных сборках GitHub Codespaces».
Когда кодовое пространство создано, вы можете узнать имя хоста базового вычислителя, набрав в терминале: 'hostname'.
Перейдите на страницу настроек вашего репозитория, обратите внимание, что теперь там зарегистрирован и помечен вашим именем пользователя и именем репозитория саморазмещающийся бегун GitHub. Имя бегуна совпадает с именем хоста Codepsace.
Управление жизненным циклом Codespace/Runner
При остановке вашего кодового пространства бегун не будет удален, а только перейдет в состояние 'Offline', и когда вы снова запустите кодовое пространство, бегун будет снова доступен.
Кроме того, как уже упоминалось, по умолчанию все активные кодовые пространства, не остановленные вручную, будут простаивать и переходить в спящий режим через 30 минут для экономии вычислительных затрат. Давайте посмотрим, как можно изменить жизненный цикл кодовых пространств.
-
В правом верхнем углу любой страницы нажмите на фотографию своего профиля, затем нажмите Настройки и в разделе «Код, планирование и автоматизация» на боковой панели выберите Кодовые пространства.
-
В разделе «Время простоя по умолчанию» введите нужное вам время и нажмите Сохранить. Время должно составлять от 5 минут до 240 минут (4 часа).
Заключение
Как видите, довольно просто запускать саморазмещающиеся экшен-бегуны внутри вашего пространства кодов и использовать вычислительные мощности самого контейнера dev.
Поступая таким образом, мы можем решить несколько проблем одним решением.
- Стоимость — Не тратить впустую затраты и вычислительные мощности, добавляя вычисления отдельно для саморазмещаемых бегунов вместе с Codespaces.
- Администрирование — работа обоих сервисов на одном вычислительном комплексе и совместное использование одной и той же конфигурации и инструментария экономит время на администрирование и обслуживание.
- Доступность — саморазмещаемые бегуны доступны как часть работающего кодового пространства.
ВАЖНО: Обратите внимание, что использование меток бегунов очень важно при инициировании/запуске действий против бегунов или групп бегунов, размещенных в кодовом пространстве. Поэтому каждый бегун помечается именем пользователя и именем репозитория.
Пример
Самостоятельно размещаемый бегун автоматически получает определенные метки при добавлении в GitHub Actions. Они используются для указания его операционной системы и аппаратной платформы:
Вы можете использовать YAML вашего рабочего процесса для отправки заданий на комбинацию этих меток. В этом примере самостоятельный хостинг, соответствующий всем трем меткам, будет иметь право на выполнение задания:
runs-on: [self-hosted, linux, ARM64]
Ярлыки по умолчанию фиксированы, их нельзя изменить или удалить. Рассмотрите возможность использования пользовательских меток, если вам нужно больше контроля над маршрутизацией заданий.
Как видно из этого примера рабочего процесса в моем репозитории, я маршрутизирую задания GitHub Action, в частности, на свой собственный хостинг на Codespace, используя метки имени пользователя и имени репозитория с 'runs-on':
name: Runner on Codespace test
on:
workflow_dispatch:
jobs:
testRunner:
runs-on: [self-hosted, Pwd9000, GitHub-Codespaces-Lab]
steps:
- uses: actions/checkout@v3.0.2
- name: Display Terraform Version
run: terraform --version
- name: Display Azure-CLI Version
run: az --version
Надеюсь, вам понравился этот пост и вы узнали что-то новое. Вы также можете найти примеры кода, использованные в этой статье, на моей опубликованной странице GitHub. ❤️
Автор
Like, share, follow me on: 🐙 GitHub | 🐧 Twitter | 👾 LinkedIn
Marcel.L
