Команда Developer Experience (DX) в GitHub сотрудничала с рядом других команд, работая над переносом нашей системы непрерывной интеграции (CI) на Действия GitHub для поддержки потребностей нашей инженерной команды в разработке и масштабировании. Наша цель как команды — дать возможность нашим инженерам уверенно и быстро поставлять программное обеспечение. С этой целью мы работали над предоставление асфальтированных дорожек, набор автоматизированных инструментов и приложений для оптимизации нашей разработки, платформ среды выполнения и развертываний. Недавно мы работали над улучшением нашего опыта CI, используя недавно выпущенную функцию GitHub. Действия более крупных бегуновчтобы запустить наш CI.
Читайте дальше, чтобы узнать, как мы выполняем 15 000 заданий CI в течение часа на 150 000 вычислительных ядрах!
Краткая история CI на GitHub
На протяжении всей своей истории GitHub инвестировал в множество различных систем CI. В каждой системе наша цель заключалась в том, чтобы улучшить опыт разработки как для инженеров GitHub, пишущих и развертывающих код, так и для инженеров, обслуживающих системы.
Однако в предыдущих системах CI мы сталкивались с проблемами масштабирования системы для удовлетворения потребностей нашей команды инженеров в обеспечении как стабильных, так и временных сред сборки. Ни одна из этих проблем не позволила нам обеспечить оптимальный опыт разработки.
Затем GitHub выпустил GitHub Actions большие бегуны. Это дало нам возможность не только перейти к полнофункциональной системе CI, но также разработать, испытать и использовать системы, которые мы создаем для наших клиентов, а также получить обратную связь, которая поможет создать продукт. Для команды GitHub DX этот переход стал прекрасной возможностью отказаться от поддержки наших прошлых систем CI, обеспечив при этом превосходный опыт разработки.
Что такое более крупные бегуны?
Более крупные бегуны — это бегуны GitHub Actions, размещенные на GitHub. Это управляемые виртуальные машины (ВМ) с большим объемом оперативной памяти, ЦП и дискового пространства, чем у стандартных средств запуска, размещенных на GitHub. Для бегунов предлагаются машины различных размеров, а также некоторые дополнительные функции по сравнению со стандартными бегунами, размещенными на GitHub.
Более крупные версии доступны для клиентов GitHub Team и GitHub Enterprise Cloud. Проверить эти документы чтобы узнать больше о более крупных бегунах.
Почему мы выбрали более крупные бегуны?
Автомасштабирование и управляемое
Исходя из предыдущих итераций CI-систем GitHub, нам нужна была возможность создавать CI-машины по требованию, чтобы обеспечить быстрые циклы обратной связи, необходимые инженерам GitHub, и масштабироваться в зависимости от скорости изменений сайта.
При использовании более крупных бегунов мы сохраняем возможность автоматического масштабирования нашей системы CI, поскольку GitHub автоматически создает несколько экземпляров бегуна, которые масштабируются вверх и вниз в соответствии с требованиями работы наших инженеров. Дополнительным преимуществом является то, что команде GitHub DX больше не нужно беспокоиться о масштабировании бегунов, поскольку все эти сложности решает сам GitHub!
Мы хотели поделиться некоторыми приблизительными цифрами о текущем пиковом использовании более крупных бегунов:
- Использует 4500 одновременных 32-ядерных процессоров.
- Выполняет 125 000 минут сборки в час
- Ставит в очередь и выполняет около 15 000 заданий в час.
- Выделяет около 150 000 вычислительных ядер
(Бета) Поддержка пользовательских образов виртуальных машин
GitHub Actions предоставляет участникам множество уже встроенных инструментов, которых достаточно и удобно для различных проектов в компании. Однако для некоторых сложных производственных сервисов GitHub готовые раннеры не удовлетворяли всем нашим требованиям.
Чтобы поддерживать эффективную и быструю систему CI, команде DX требовалась возможность предоставить машинам все инструменты, необходимые для создания этих производственных сервисов. Мы не хотели тратить дополнительное время на установку инструментов или компиляцию проектов во время работы CI.
В настоящее время мы встраиваем функции в более крупные раннеры, чтобы их можно было запускать из пользовательского образа виртуальной машины, называемого пользовательскими образами. Хотя эта функция все еще находится в стадии бета-тестирования, использование пользовательских изображений является огромным преимуществом для жизненного цикла CI GitHub по нескольким причинам.
Во-первых, пользовательские образы позволяют GitHub объединять все необходимое программное обеспечение и инструменты, необходимые для создания и тестирования сложных сервисов производственных подшипников. Все, что уникально для GitHub или одного из наших проектов, можно предварительно установить в образ еще до запуска рабочего процесса GitHub Actions.
Во-вторых, пользовательские изображения позволяют GitHub значительно ускорить рабочие процессы GitHub Actions, выступая в качестве кэша начальной загрузки для некоторых проектов. Во время создания собственного образа мы включаем в него предварительно созданную версию исходного кода проекта. Впоследствии, когда проект запускает рабочий процесс GitHub Actions, он может использовать кэшированную версию своего исходного кода и любые другие артефакты сборки, чтобы ускорить процесс сборки.
Кэшированный исходный код проекта в пользовательском образе виртуальной машины может быстро устареть из-за высоких темпов разработки в GitHub. Это, в свою очередь, приводит к увеличению продолжительности рабочего процесса. Команда DX работала с командой инженеров GitHub Actions над созданием API на GitHub, позволяющего регулярно обновлять собственный образ несколько раз в день, чтобы поддерживать актуальность исходного кода проекта.
На практике это значительно сократило время начальной загрузки наших проектов. Без пользовательских изображений наши рабочие процессы от начала до конца заняли бы около 50 минут по сравнению с 12 минутами, которые они занимают сегодня. Это меняет правила игры для наших инженеров.
Мы работаем над тем, чтобы предложить эту функциональность в большом масштабе. Если вас интересуют специальные образы для ваших рабочих процессов CI/CD, обратитесь к своему менеджеру по работе с клиентами, чтобы узнать больше!
Важные функции GitHub Actions
На GitHub есть тысячи проектов — от сервисов, выполняющих рабочие нагрузки, до небольших инструментов, которым необходимо запускать CI для выполнения повседневных операций. Чтобы воплотить это в жизнь, GitHub использует несколько важных функций GitHub Actions, которые позволяют нам эффективно и безопасно использовать платформу в масштабе всей компании.
Многоразовые рабочие процессы
Одна из главных целей команды DX — проложить путь для всех репозиториев для запуска CI без ненужного повторения между репозиториями. До GitHub Actions мы создавали отдельные конфигурации заданий, которые можно было использовать в нескольких проектах. В GitHub Actions это было не так просто, поскольку любой репозиторий может определять свои собственные рабочие процессы. Многоразовые рабочие процессы вам на помощь!
многоразовые рабочие процессы Функция GitHub Actions позволяет централизованно управлять рабочим процессом в репозитории, который может использоваться многими другими репозиториями в организации. Это имело решающее значение при переходе от нашей предыдущей системы CI к GitHub Actions. Мы смогли создать несколько готовых рабочих процессов в одном репозитории, и многие репозитории могли затем использовать эти рабочие процессы. Это упрощает процесс добавления CI в существующий или новый проект.
В нашем центральном репозитории, где размещены наши многократно используемые рабочие процессы, мы можем определить рабочие процессы следующим образом:
on:
workflow_call:
inputs:
cibuild-script:
description: 'Which cibuild script to run.'
type: string
required: false
default: "script/cibuild"
secrets:
service-api-key:
required: true
jobs:
reusable_workflow_job:
runs-on: gh-larger-runner-medium
name: Simple Workflow Job
timeout-minutes: 20
steps:
- name: Checkout Project
uses: actions/checkout@v3
- name: Run cibuild script
run: |
bash ${{ inputs.cibuild-script }}
shell: bash
А при использовании репозиториев они могут просто использовать многократно используемый рабочий процесс, написав всего несколько строк кода!
name: my-new-project
on:
workflow_dispatch:
push:
jobs:
call-reusable-workflow:
uses: github/internal-actions/.github/workflows/default.yml@main
with:
cibuild-script: "script/cibuild-my-tests"
secrets:
service-api-key: ${{ secrets.SERVICE_API_KEY }}
Еще одним большим преимуществом функции многократного использования рабочих процессов является то, что runner может быть определен в повторно используемом рабочем процессе, а это означает, что мы можем гарантировать, что все пользователи рабочего процесса будут работать в нашем назначенном более крупном пуле исполнителей. Теперь проектам не нужно беспокоиться о том, какой раннер им нужно использовать!
(Бета) Повторное использование результатов предыдущего рабочего процесса
Чтобы оптимизировать опыт разработчиков, команда DX работала с нашей командой инженеров над созданием функции для GitHub Actions, которая позволяет рабочим процессам повторно использовать результаты предыдущего запуска рабочего процесса, где результаты будут одинаковыми.
В некоторых случаях содержимое файлов репозитория совершенно одинаково при выполнении рабочих процессов, выполняемых с разными фиксациями. То есть идентификаторы дерева Git для текущего коммита такие же, как и для предыдущего коммита (отличий между файлами нет). В этих случаях мы можем обойти проверки CI, повторно используя результаты предыдущего рабочего процесса, и позволить инженерам не ждать повторного запуска CI.
Эта функция избавляет инженеров GitHub от выполнения от 300 до 500 рабочих процессов в день!
Другие проблемы, с которыми пришлось столкнуться
Доступ к частному сервису
Во время выполнения некоторых внутренних рабочих процессов GitHub Actions им необходима возможность доступа к некоторым частным службам GitHub в виртуальном частном облаке GitHub (VPC) по сети. Это могут быть такие ресурсы, как хранилище артефактов, службы метаданных приложений и другие службы, которые позволяют вызывать наш тестовый пакет.
Когда мы перешли к более крупным компаниям, требование доступа к частным услугам стало главной проблемой. В предыдущих версиях нашей CI-инфраструктуры эти частные сервисы были доступны через другие облачные и сетевые конфигурации. Однако более крупные серверы изолированы от других производственных сред, а это значит, что они не могут получить доступ к нашим частным сервисам.
Как и всем компаниям, нам необходимо сосредоточиться как на безопасности нашей платформы, так и на опыте разработчиков. Чтобы удовлетворить эти два требования, GitHub разработал решение для удаленного доступа, которое позволяет клиентам, проживающим за пределами наших VPC (более крупных компаний), получать безопасный доступ к избранным частным сервисам.
Это решение для удаленного доступа работает по принципу создания токен OIDC в действиях GitHub передача токена OIDC шлюзу удаленного доступа, который авторизует запрос путем проверки токена OIDC, а затем пересылает запрос частной службе, находящейся в частной сети.
Благодаря этому решению мы можем безопасно предоставить удаленный доступ крупным участникам, использующим GitHubActions, к нашим частным ресурсам в нашем VPC.
GitHub выложил в открытый исходный код базовую структуру этого шлюза удаленного доступа. github/actions-oidc-шлюз-пример репозиторий, так что обязательно проверьте его!
Заключение
GitHub Actions обеспечивает надежную и бесперебойную работу инженеров GitHub, работающих на GitHub.com. Нам удалось добиться этого, используя возможности GitHub Actions, такие как многократно используемые рабочие процессы и повторно используемые результаты рабочих процессов, а также используя масштабируемость и управляемость более крупных модулей GitHub Actions. Мы также приложили эти усилия для улучшения продукта GitHub Actions. Проще говоря, GitHub работает на GitHub.
2023-10-05 12:19:49
1696510384
#Как #GitHub #использует #GitHub #Actions #более #крупные #средства #запуска #Actions #для #создания #тестирования #GitHub.com
