2026 GitLab Runner на macOS в Mac Cloud: токены регистрации, исполнители и безопасный параллелизм

Команды разработчиков платформ, знакомые с программами Linux, часто увязают в тупике, когда конвейерам iOS требуется оборудование Apple. После установки SSH-соединения с арендованным облачным узлом Mac предсказуемы следующие ошибки: неправильная двоичная архитектура, теги, которые никогда не соответствуют .gitlab-ci.yml, или три одновременных задания xcodebuild, разрушающие состояние диска и связки ключей. Эта статья предназначена для инженеров, которые хотят, чтобы macOS чувствовал себя так же удобно, как VPS: мы выясняем четыре повторяющиеся уязвимости, сравниваем Shell со специальными исполнителями, проводим пятиэтапную регистрацию и дымовое тестирование, предоставляем конкретные цифры мощности, которые вы можете включить в обзоры, и заканчиваем структурированными данными из часто задаваемых вопросов, которые соответствуют практике GitLab 2026.

Иллюстрация инженеров, настраивающих GitLab Runner и параллельную обработку CI на хосте облачной сборки Mac в 2026 году.

В этом руководстве

1. Резюме: чем пользователи macOS отличаются от привычек Linux

В Linux Docker executor уже привычен: эфемерные контейнеры, лимиты cgroup и монтирование томов дают предсказуемую изоляцию. macOS не является прямой заменой. Цепочки Apple рассчитывают на залогиненный контекст для подписи, DerivedData быстро разрастается рядом с кэшем CocoaPods или SwiftPM, параллельные xcodebuild конкурируют за одни и те же деревья файлов без продуманных пулов и путей. Ставить concurrent равным числу performance-ядер — частая ошибка: сбои линковщика и OOM компилятора проявляются как нестабильные пайплайны. Для Apple Silicon скачайте бинарник darwin-arm64 GitLab Runner; смешение amd64 toolchain под Rosetta с нативным Swift даёт трудноуловимые расхождения линковки. Руководство исходит из одной или нескольких Mac в облаке с SSH, ведущих себя в GitLab как маркированная ёмкость, а не как случайные ноутбуки, уходящие в сон.

2. Уязвимости: токены, теги, связка ключей, конфликт дисков.

Обзоры архитектуры обычно выявляют одни и те же четыре конфликта, когда команды, ориентированные на Linux, сталкиваются с macOS:

  1. Токены регистрации: токены уровня инстанса и проекта помещают Runner в разные области. После ротации без обновления ~/.gitlab-runner/config.toml Runner выглядит онлайн, но не забирает job.
  2. Дрейф тегов: YAML ожидает tags: [macos, ios], а Runner зарегистрировал только macos-arm64 — пайплайны висят в pending. Ручные правки тегов без документации повторяют проблему после каждой переустановки.
  3. Брелки и автоматическое подписание : Задания исполнителя оболочки могут выполняться вне потока разблокировки цепочки ключей интерактивного входа в систему. Без выделенного пользователя CI или явного разделения цепочки ключей идентификаторы подписи кода исчезают на полпути конвейера.
  4. Конфликты дисков и кэша : DerivedData, кэши модулей и артефакты совместно используют один том. Параллельные задания с агрессивным сокращением могут удалять промежуточные задания, на которые все еще ссылается родственное задание, что приводит к недетерминированным ошибкам.

3. Матрица решений: Shell против индивидуального исполнителя

Большинство команд начинают с shell, потому что это повторяет команды, которые инженеры уже запускают по SSH. Кастомные executor или внешняя виртуализация усиливают изоляцию и объём обслуживания. Ниже таблица для проектной документации.

измерениеИсполнитель оболочкииндивидуальное или внешнее утепление
Время для вашей первой «зеленой» работыЧасыдни и недели
Прочность изоляцииНизкоуровневая общая пользовательская средаВыше, ближе к чистым помещениям
Эргономика знакаПроще всего, если сеанс входа соответствует пользователю CI.Требуется явная секретная инъекция.
Стратегия параллелизмаСтрогие ограничения одновременности и пулы теговМожет сопоставлять пулы с каталогами или хостами
Гигиена жесткого дискаСоглашения о путях и запланированная очисткаКрючки могут привязывать или удалять рабочие области.
Лучше всего подходитМаленькие и средние команды, меньше репозиториев, ориентированность на xcodebuildМногопользовательские автопарки с высокими требованиями к соблюдению требований
Практические советы : Пока вы не выполните надежную изоляцию, вы предпочитаете пулы, разделенные тегами, с консервативным параллелизмом и фиксированными корнями DerivedData, а не поиску идеальных герметичных сборок, которые блокируют всю программу.

4. Пять шагов от регистрации до работы «зеленым дымом»

Следуйте этому порядку на облачном хосте Mac с SSH с поддержкой sudo. Сравните версии GitLab и Runner, используя официальную матрицу совместимости, прежде чем переходить к производству.

  1. Проверка установки и архитектуры: установить бинарник gitlab-runner для darwin-arm64, проверить gitlab-runner --version и uname -m. Зафиксировать запрет случайного amd64 toolchain под Rosetta для Swift-сборок.
  2. Регистрация с осознанными тегами: выполнить gitlab-runner register с корректным токеном инстанса или проекта; введённые теги должны точно совпадать с будущими фрагментами .gitlab-ci.yml. Убедиться, что в config.toml появился новый блок [[runners]].
  3. Executor и параллелизм: задать executor = "shell", стартовать concurrent с одного или двух. Развести пулы PR и release по имени Runner и тегам, чтобы тяжёлые Archive не выжирали сессии связки ключей для lint-job.
  4. Дымовой YAML: добавить job только с sw_vers и xcodebuild -version. Проверить загрузку артефактов и маршрутизацию тегов до подключения полных пайплайнов.
  5. Очистка и наблюдаемость : стандартизировать расположение производных данных и кэша зависимостей. Запланировать очистку диска или этапы завершения конвейера. Предупреждать, когда свободное пространство падает ниже согласованных пороговых значений. Классифицировать ошибки как подписывание, зависимости, нехватку памяти или диска, чтобы ускорить посмертный анализ.

Минимальный пример .gitlab-ci.yml:

stages: [verify] mac-smoke: stage: verify tags: [macos-arm64, ci-pool-dev] script: - sw_vers - xcodebuild -version

Фрагмент config.toml (реальные токены скрыть):

concurrent = 2 check_interval = 0 [[runners]] name = "mac-cloud-pool-dev" url = "https://gitlab.example.com/" token = "REDACTED" executor = "shell" [runners.custom_build_dir] builds_dir = "/Users/gitlab-ci/builds" cache_dir = "/Users/gitlab-ci/cache"

5. Твердые цифры: память, диск и параллелизм

Используйте эти диапазоны при планировании емкости кодовых баз Swift и iOS среднего размера. Всегда проверяйте свои собственные модули. Если руководство требует единого графика в ежеквартальном обзоре, связывайте всплески памяти с глубиной очереди: замена во время фаз подключения покажет большую задержку, даже если среднее время работы кажется приемлемым. Задокументируйте как «среднее», так и «p95», и разделите задержку очереди, начиная с активных минут компиляции, чтобы вы могли видеть, нужно ли вам добавлять бегунов или просто сериализовать большие схемы.

6. Почему парка чисто Linux недостаточно и когда побеждает выделенное облако Mac

Парк бегунов, полностью состоящий из Linux, не может честно работать в нативном режиме. Если вам нужны второстепенные выпуски Xcode, корпоративные правила выхода и стабильные операции SSH, GitLab должен добавить один или несколько выделенных облачных хостов Mac в качестве емкости с тегами премиум-класса. Аренда позволяет исключить закупки из критического пути: вы быстро получаете учетные данные, регистрируете исполнителей и масштабируете горизонтально, клонируя стратегию тегов, вместо того, чтобы размещать рискованный параллельный доступ на одной хрупкой машине. Изоляция в стиле Docker в macOS повышает ценность, но также и рабочий интерфейс. Собственные облачные узлы Mac уменьшают это противоречие для многих профилей CI. Если вам нужен тот же программный ритм, что и при заказе API VPS, ознакомьтесь с руководством по интеграции Mac Cloud API и CI VPSMAC за 90 секунд для сквозного подключения от оформления заказа к зеленым конвейерам.