Buildkite macOS Agent: Hosted или Self-hosted? Выбор предприятия 2026

В Buildkite SaaS управляет планированием и координацией, но само задание выполняется агентом. Hosted Agent — это управляемая среда, предоставляемая Buildkite; Self-hosted Agent работает на узле, который контролирует предприятие. В третьем слое находится реальный Mac, на котором установлены macOS, Xcode, сертификаты, кэш и дополнительные инструменты.

Это разделение важно для бюджета и безопасности. Нельзя считать, что покупка доступа к Buildkite автоматически решает вопрос Mac-ресурсов: контрольная плоскость, агент и вычислительный узел имеют разные обязанности. Общая архитектура описана в официальной документации Buildkite Agent.

Для первичной маршрутизации используется не название проекта, а требуемая степень контроля:

• PR-проверка и обычные unit-тесты — Hosted Agent, если код не требует корпоративного VPN и специальных инструментов.
• Тесты симулятора — Hosted Agent при совместимости образа и достаточной квоте; Self-hosted Mac, если нужны фиксированные симуляторы, нестандартные плагины или долгоживущий кэш.
• Архивирование приложения — обычно Self-hosted, когда сборка зависит от закреплённой версии Xcode, приватных пакетов или локальной политики доступа.
• Производственная подпись — изолированный Self-hosted Mac с отдельной очередью и отдельными секретами.
• Задания с доступом к внутренним API — Self-hosted узел в согласованном сетевом контуре либо отдельная схема с контролируемым прокси.

Официальная модель очередей Buildkite предполагает, что агенты получают задания через очереди с соответствующими тегами и правилами маршрутизации. Поэтому Hosted и Self-hosted ресурсы следует оформлять как разные очереди, а не смешивать в одной группе в надежде, что метки случайно выберут безопасный узел. Подробные правила приведены в документации по очередям Buildkite.

Для iOS-команды вопрос «можно ли выбрать macOS» недостаточен. Нужно проверить, можно ли воспроизводимо закрепить всю цепочку: версию macOS, Xcode, SDK, Ruby или Swift Package Manager, системные расширения, CLI-инструменты, сертификаты, плагины и кэш.

Hosted Agent удобен, когда проект помещается в поддерживаемый набор образов. Предварительно подготовленная среда ускоряет запуск PR-проверок и избавляет команду от части обслуживания. Однако доступный образ, установленная версия Xcode и требования к системе могут изменяться. Такие сведения необходимо сверять с актуальным описанием macOS Hosted Agents, а совместимость Xcode — с системными требованиями Apple для Xcode 26.

Self-hosted Mac даёт более глубокий контроль:

• можно зафиксировать рабочую комбинацию macOS и Xcode;
• можно установить внутренние сертификаты, плагины и бинарные зависимости;
• можно управлять локальным кэшем DerivedData и зависимостей;
• можно согласовать образ узла с аудитом и внутренним процессом изменения.

Но этот контроль не равен вечной заморозке. Xcode требует совместимой macOS, сертификаты истекают, зависимости уязвимы, а устаревший SDK постепенно перестаёт проходить проверку публикации. Поэтому фиксированная среда должна иметь владельца, журнал изменений и тестовый клон.

Что проверяется до выбора Hosted Agent

Команда должна получить не маркетинговое обещание, а подтверждение по каждому ограничению:

• нужная версия Xcode присутствует в поддерживаемом образе;
• необходимые CLI-инструменты устанавливаются без ручного доступа;
• плагины и hooks проекта разрешены;
• кэш не нарушает изоляцию между заданиями;
• размер артефактов и длительность задания укладываются в действующие ограничения;
• исходящий сетевой доступ достаточен для пакетных репозиториев и сервисов подписи.

Если хотя бы один пункт критичен для релиза и не подтверждён на реальном проекте, его следует направить в Self-hosted очередь.

Безопасность определяется не тем, находится ли агент «в облаке» или «в офисе», а тем, какие секреты и маршруты доступны конкретному заданию. PR из доверенной ветки и производственная подпись не должны автоматически получать одинаковый набор полномочий.

Для Hosted Agent нужно проверить:

• как выдаются краткоживущие учётные данные;
• очищается ли рабочая среда после завершения задания;
• какие сетевые выходы разрешены;
• где временно оказываются исходники, логи и артефакты;
• можно ли запретить публикацию секретов в логах.

Для Self-hosted Agent ответственность расширяется. Нужно защищать токен агента, ограничивать плагины, принудительно выполнять чистое получение исходников и контролировать исходящие соединения. Рекомендации по токенам и их безопасному применению собраны в документации Buildkite для Self-hosted Agent.

Отдельного внимания требуют недоверенные ветки. Если задание может выполнить произвольный скрипт из pull request, узел не должен одновременно хранить производственный сертификат или иметь прямой доступ к внутренним системам. Даже при одинаковом проекте это разные уровни доверия и разные очереди.

Как Buildkite Self-hosted Agent подключается к корпоративной сети

Подключение к внутренней сети выполняется не за счёт одной настройки Buildkite. Архитектору нужно определить, где располагается Mac, через какой прокси агент выходит наружу, какие DNS-имена разрешаются и какие внутренние сервисы доступны только из производственной подсети.

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

1. Создать отдельную очередь для Self-hosted Mac, не смешивая её с Hosted-ресурсами.
2. Назначить узлу минимальный набор тегов, по которым допустимые задания смогут его выбрать.
3. Разместить токен агента в защищённом хранилище, а не в репозитории или открытом скрипте.
4. Настроить исходящий доступ только к Buildkite, репозиториям, пакетным источникам, хранилищам артефактов и необходимым внутренним API.
5. Проверить DNS, прокси, сертификаты TLS и поведение при временной потере VPN.
6. Зафиксировать, какие задания запрещены на этом узле, даже если технически они могут быть запущены.
7. Использовать механизм Job Dispatch Buildkite только после проверки фактической модели доставки заданий и сетевых ограничений.

В результате получается не «Mac с доступом в VPN», а документированный доверенный контур. Если сетевой доступ требуется только для нескольких шагов, безопаснее отделить их от общей PR-проверки, чем выдавать всем заданиям одинаковые права.

Одна быстрая сборка не доказывает высокую пропускную способность. Для IT-руководителя важнее полный цикл: ожидание свободного агента, подготовка среды, выполнение тестов, упаковка артефактов, повтор после сбоя и время восстановления узла.

Hosted Agent обычно полезен при скачках нагрузки: команда не обязана постоянно держать резервную физическую мощность ради редких релизных окон. Но нужно отдельно проверить доступную параллельность, правила очереди, пределы длительности задания и действующую модель оплаты. Эти параметры относятся к изменяемым условиям и сверяются с официальной страницей тарифов Buildkite, а не переносятся из старого расчёта.

Self-hosted Mac подходит для стабильной базовой нагрузки, если подтверждены:

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

При отсутствии этих доказательств «выделенный Mac» может оказаться единственной точкой отказа. Для производственного SLO в расчёт включаются не только минуты сборки, но и время обнаружения, диагностики, восстановления и переключения на замену.

Практичное правило таково: базовый предсказуемый поток направляется в Self-hosted пул, а пик PR-проверок, массовые симуляторные тесты и временные ветки — в Hosted пул. Если же собственный Mac не имеет проверенного удалённого восстановления, его нельзя считать готовым производственным агентом независимо от мощности.

Сравнение тарифной строки с ценой Mac mini не является TCO-анализом. У собственного узла есть расходы, которые часто не попадают в заявку на закупку:

• приобретение или аренда оборудования;
• питание, размещение и сетевой порт;
• управление запасным узлом;
• подготовка образов и установка обновлений;
• проверка Xcode после изменений;
• аудит сертификатов и секретов;
• обслуживание кэша и дискового пространства;
• время инженеров на диагностику;
• потери от недоступности во время релиза.

Для Hosted Agent базовая формула выглядит так:

TCO Hosted = плата Buildkite + стоимость вычислительного времени + хранение и передача артефактов + сетевые и корпоративные интеграции + резерв на превышение квоты.

Для Self-hosted Mac:

TCO Self-hosted = стоимость Mac + размещение + сеть + лицензии и сервисы + инженерное обслуживание + резервная ёмкость + ожидаемый ущерб от простоев.

Если предприятие использует удалённый Mac от NUKCLOUD, аренду следует подставлять в эту формулу по фактическому выбранному периоду, а не по рекламной оценке. Страница тарифов NUKCLOUD должна использоваться как источник текущих условий, а требования к доступу и поддержке — сверяться через раздел помощи NUKCLOUD.

Главная переменная — профиль нагрузки. При постоянном использовании собственный узел может выглядеть выгоднее, но только если учитываются обслуживание и резерв. При нерегулярных PR-пиках Hosted Agent может избежать оплаты простаивающей мощности. При строгой производственной подписи более высокая стоимость Self-hosted иногда оправдана снижением риска утечки и предсказуемостью среды.

Перед пилотом руководителю следует заполнить матрицу фактическими результатами, а не общими оценками. Условия «подходит» должны подтверждаться журналом заданий, политикой безопасности, счётом и тестом восстановления.

Для задачи «Buildkite macOS Agent Hosted или Self-hosted» нет универсального ответа. Hosted выбирается при подтверждённой совместимости и переменной нагрузке; Self-hosted — при обязательном контроле; смешанная схема — когда эти требования существуют одновременно.

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

Шаг 1. Разделить задания по доверию

Составляется перечень PR-проверок, симуляторных тестов, архивирования, публикации и обращений к внутренним API. Для каждой группы фиксируются секреты, сетевые адреса, требуемая версия Xcode и допустимая длительность.

Шаг 2. Создать две очереди

Hosted и Self-hosted Agent получают разные имена, теги и правила маршрутизации. Запасной маршрут не должен незаметно отправлять производственную подпись на общий агент.

Шаг 3. Зафиксировать baseline среды

Для реального Mac записываются версии macOS, Xcode, SDK, менеджеров зависимостей, инструментов подписи и системных настроек. Для Hosted фиксируется конкретный доступный образ и дата проверки, поскольку каталог среды может обновляться.

Шаг 4. Проверить чистый запуск

Задание запускается без локального кэша, затем с разрешённым кэшем. Сравниваются не только минуты исполнения, но и воспроизводимость результата, объём скачивания и вероятность загрязнения среды.

Шаг 5. Проверить безопасность

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

Шаг 6. Проверить внутреннюю сеть

На Self-hosted Mac тестируются DNS, прокси, доступ к приватным пакетам, хранилищу артефактов и внутренним API. Каждый разрешённый маршрут записывается; широкое правило «разрешить всю подсеть» не считается результатом проверки.

Шаг 7. Проверить отказ

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

Шаг 8. Сопоставить счета и журналы

В расчёт включаются ожидание, повторные задания, резервная ёмкость, работа инженеров и стоимость аренды или размещения. Для Buildkite тарифная часть берётся из действующего официального расчёта, а для Mac — из подтверждённых закупочных или арендных условий.

Шаг 9. Установить условия допуска

Hosted остаётся основным вариантом, если он проходит проверки Xcode, сети, безопасности и длительности, а его стоимость при фактическом профиле нагрузки приемлема. Self-hosted становится обязательным для производственной подписи, фиксированной среды или закрытой сети. При сочетании обоих наборов условий утверждается двойная маршрутизация.

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

Если Buildkite-проекту нужны стандартные образы, короткие проверки и скачущая нагрузка, Hosted Agent следует оставить первым кандидатом. При этом команда обязана подтвердить доступность нужного Xcode, лимиты выполнения, поведение кэша и фактическую цену по журналам.

Если проект зависит от фиксированного Xcode, частных пакетов, внутренней сети, производственных сертификатов или длительных задач, Self-hosted Mac является более контролируемой основой. Но такой выбор принимается только после проверки токенов, чистого запуска, удалённого восстановления и резервной ёмкости.

Если в одной организации одновременно есть быстрые PR, симуляторные тесты и защищённые релизные задания, наиболее обоснованна двухочередная архитектура:

• Hosted очередь принимает эластичные и менее доверенные проверки;
• Self-hosted очередь обслуживает производственный baseline;
• подписывающие задания получают отдельные секреты и правила;
• метрики ожидания, выполнения, повторов и восстановления собираются раздельно;
• решение о расширении каждого пула принимается по реальным данным, а не по средней скорости одной сборки.

Покупка физического Mac остаётся разумной при длительной стабильной нагрузке, необходимости локального физического интерфейса или строгом владении оборудованием. Она становится менее привлекательной, когда требуется быстро добавить временный ресурс, обеспечить удалённую работу команды или избежать закупки резервных машин. Удалённый Mac в аренде не заменяет проверку безопасности, но может дать предприятию управляемый Self-hosted узел без самостоятельной закупки, доставки и первичной настройки оборудования.

На практике текущая схема часто имеет три недостатка: общий пул смешивает задания с разным уровнем доверия, единственный физический Mac создаёт точку отказа, а резервная мощность оплачивается даже в периоды слабой нагрузки. Если для производственной очереди нужен удалённо доступный Apple Silicon Mac с контролируемым восстановлением, аренда подходящего узла через NUKCLOUD может быть рациональнее расширения собственного парка — при условии, что требования к сети, сроку аренды, доступу и приёмочным тестам заранее зафиксированы. Для начала стоит сверить условия размещения и доступа с политикой конфиденциальности NUKCLOUD, затем провести двойной прогон PR и релизных заданий с раздельным учётом расходов.