{"meta":{"title":"Использование пользовательских изображений","intro":"Создавайте, управляйте и используйте индивидуальные изображения для Более крупные средства выполнения, размещенные на GitHub вашей организации или предприятия.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/how-tos","title":"Инструкции"},{"href":"/ru/actions/how-tos/manage-runners","title":"Управление средствами выполнения"},{"href":"/ru/actions/how-tos/manage-runners/larger-runners","title":"Более крупные бегуны"},{"href":"/ru/actions/how-tos/manage-runners/larger-runners/use-custom-images","title":"Использование пользовательских изображений"}],"documentType":"article"},"body":"# Использование пользовательских изображений\n\nСоздавайте, управляйте и используйте индивидуальные изображения для Более крупные средства выполнения, размещенные на GitHub вашей организации или предприятия.\n\n## Пользовательские образы\n\nВы можете создать собственное изображение, чтобы определить точную среду, которую используете Более крупные средства выполнения, размещенные на GitHub . Пользовательские образы позволяют предварительно установить средства, зависимости и конфигурации, чтобы ускорить рабочие процессы и повысить согласованность между заданиями.\n\nКогда средство выполнения тестов использует пользовательский образ, оно действует как «предварительно подогретая» среда, позволяя рабочим процессам выполняться быстрее, загружая пакеты и двоичные файлы один раз во время создания образа, а не каждый раз при выполнении рабочего процесса. Дополнительные сведения о пользовательских образах см. в разделе [Изображения средства выполнения](/ru/actions/concepts/runners/github-hosted-runners#runner-images).\n\nПроцесс использования пользовательского изображения включает в себя три основных этапа:\n\n1. [Настройка раннера для генерации изображений](#setting-up-an-image-generation-runner): создайте крупное средство выполнения для создания и хранения вашего пользовательского изображения.\n2. [Создание пользовательского изображения](#generating-a-custom-image): Создайте пользовательское изображение, запустив рабочий процесс с помощью средства запуска создания образов.\n3. [Установка пользовательских образов](#installing-custom-images): Создайте средство выполнения, использующее ваш пользовательский образ.\n\n## Предпосылки\n\nПрежде чем создавать пользовательские образы, убедитесь, что выполнены следующие требования.\n\n* **Политика**: пользовательские образы должны быть включены для вашей организации или предприятия. Владельцы предприятия могут управлять доступом к пользовательским образам и настраивать политики хранения в параметрах политики действий. Дополнительные сведения см. в разделе [Применение политик для GitHub Actions в вашем предприятии](/ru/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#custom-images).\n* Разрешения: чтобы создавать пользовательские **образы** и управлять ими, вы должны быть владельцем организации или предприятия, или иметь роль, или `CI/CD Admin` иметь роль со следующими детализированными разрешениями.\n\n * Просмотр пользовательских образов размещенного в организации средства выполнения тестов\n * Управление пользовательскими образами размещенного в организации средства выполнения тестов\n * Управление группами runner и runner организации\n\n Дополнительные сведения см. в разделе [Разрешения на кастомные организационные роли](/ru/organizations/managing-peoples-access-to-your-organization-with-roles/permissions-of-custom-organization-roles).\n\n## Настройка средства запуска генерации изображений\n\nЧтобы создать пользовательский образ, необходимо сначала настроить средство запуска создания образов. При создании средства выполнения тестов платформа, выбранная для средства выполнения, должна совпадать с платформой образа, который требуется создать. Платформой раннера может быть Linux x64, Linux ARM64 или Windows x64.\n\n1. крупное средство выполненияСоздайте:\n * Сведения об организациях см. [в разделе Добавление более крупного средства выполнения тестов в организацию](/ru/actions/how-tos/manage-runners/larger-runners/manage-larger-runners#adding-a-larger-runner-to-an-organization).\n * Сведения о предприятиях см. [в разделе Добавление более крупного средства выполнения тестов в предприятие](/ru/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners/manage-larger-runners#adding-a-larger-runner-to-an-enterprise).\n2. При настройке средства выполнения тестов выберите следующие конфигурации для средства выполнения тестов создания образов:\n * **Платформа**: выберите поддерживаемую платформу, которая соответствует платформе образа, который вы планируете создать (Linux x64, Linux ARM64 или Windows x64).\n * **Изображение**: выберите образ для сборки, затем установите флажок **Разрешить этому средству выполнения создавать пользовательские изображения**.\n * Можно начать с образа, принадлежащего GitHub-, или выбрать базовый образ, чтобы начать с чистой ОС.\n * Вы можете начать с уже существующего пользовательского изображения в качестве основы, что позволит создавать слоистые рабочие процессы изображений.\n * Для платформ ARM64 вы также можете выбрать образ, поддерживаемый ARM, с предустановленными инструментами.\n * **Группа бегунов**: выберите группу, в которую будет входить ваш бегун. После создания пользовательского образа только средства выполнения тестов в этой группе могут создавать новые версии этого образа.\n\n## Создание пользовательского изображения\n\nПосле создания средства запуска генерации изображений запустите рабочий процесс, включающий `snapshot` ключевое слово для создания пользовательского изображения.\n\nЧтобы настроить рабочий процесс для создания изображений, выполните следующие действия.\n\n* Задайте в качестве `runs-on` значения имя созданного средства выполнения генерации изображений.\n* `snapshot` Добавьте ключевое слово в задание, используя либо строковый синтаксис, либо синтаксис сопоставления, показанный ниже.\n * Каждая работа, содержащая ключевое слово, `snapshot` создает отдельное изображение. Чтобы создать только одно изображение или версию изображения, включите все шаги рабочего процесса в одно задание.\n * При каждом успешном выполнении задания, содержащего ключевое слово, `snapshot` создается новая версия этого изображения.\n\n> \\[!NOTE]\n> GitHub Рекомендует настраивать генерацию изображений как запланированный рабочий процесс каждую неделю. Такой подход гарантирует, что зависимости остаются up-to-date и содержат последние обновления безопасности. Дополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).\n\nМожет потребоваться некоторое время, чтобы изображение было полностью сгенерировано и готово к использованию после завершения рабочего процесса. Время подготовки зависит от размера и конфигурации средства выполнения тестов и может занять несколько часов для более крупных средств выполнения.\n\nИзображение создается только после успешного завершения задания. Это предотвращает создание новых версий образов в случае сбоя рабочего процесса или его незавершенного состояния.\n\nПосле создания изображения оно становится доступным для использования в рабочих процессах. Дополнительные сведения об управлении пользовательскими изображениями см. [в разделе Управление пользовательскими изображениями](#managing-custom-images).\n\n### Строковый синтаксис\n\nВы можете использовать строковый синтаксис with, `snapshot` чтобы определить имя изображения. Этот метод создает новое изображение или добавляет новую версию к существующему образу с тем же именем. С помощью этого синтаксиса нельзя указать номер версии.\n\n```yaml\njobs: \n build:\n runs-on: my-image-generation-runner\n snapshot: my-custom-image\n steps:\n # Add any steps to download and setup any dependencies here\n```\n\n### Синтаксис сопоставления\n\nВы можете использовать синтаксис сопоставления с `snapshot` для определения как одного, `image-name` так и необязательного `version`. Когда вы указываете основную версию, дополнительная версия автоматически увеличивается, если эта основная версия уже существует. Версии патчей не поддерживаются.\n\n```yaml\njobs: \n build:\n runs-on: my-image-generation-runner\n snapshot: \n image-name: my-custom-image\n version: 2.*\n steps:\n # Add any steps to download and setup any dependencies here\n```\n\n### Условные выражения\n\nКлючевое `snapshot` слово поддерживает условное выполнение с использованием `if` ключевого слова вокруг сопоставления снимка. Вы можете использовать условия для управления моментом создания снимка изображения. Например, следующее задание пропускает создание образа для сборок тегов.\n\n```yaml\njobs: \n build:\n runs-on: my-image-generation-runner\n snapshot: \n if: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n image-name: my-custom-image\n version: 2.*\n steps:\n # Add any steps to download and setup any dependencies here\n```\n\nДополнительные сведения о ключевом слове `if` см. в разделе [Использование условий для управления выполнением задания](/ru/actions/how-tos/write-workflows/choose-when-workflows-run/control-jobs-with-conditions).\n\n## Управление версиями\n\nПри создании кастомных изображений GitHub автоматически назначается номера версий, чтобы помочь вам управлять обновлениями и отслеживать историю изображений.\n\n### Поведение по умолчанию\n\nЕсли изображение с указанным названием отсутствует в вашей организации или предприятии, GitHub создайте его с первоначальным номером версии 1.0.0.\nЕсли изображение с таким же именем уже существует, GitHub создайте новую версию, увеличивая малый номер версии (например, 1.1.0, 1.2.0 и т.д.).\n\nЕсли вы не укажете версию в файле YAML, при создании изображений будет использоваться это поведение по умолчанию.\n\n### Указание версии в рабочем процессе\n\nЕсли вы включите версию в YAML-отображение, GitHub сначала проверьте основной номер версии.\n\n* Если указанная основная версия уже существует, то в новом образе используется следующая дополнительная версия (например, 1.0 становится 1.1).\n* Если основной версии нет, создаётся GitHub новая версия мажора (например, 2.0).\n\nВерсии патчей не поддерживаются.\n\n### Последний тег\n\nСамый последний запуск рабочего процесса для изображения всегда помечается как последний.\nЕсли вы указываете старую основную версию в YAML (например, версию: 1.\\*, когда существует версия 2.0), GitHub генерируется новая минорная версия под старой основной версией и отмечает её как последнюю.\n\n> \\[!NOTE]\n> Более крупное средство выполнения, размещенное в GitHub Creation не поддерживает wildcards при выборе версии изображения.\n\n## Срок действия изображений, построенных на основе кастомных изображений\n\nКогда пользовательский образ создаётся из другого образа, производный образ наследует срок действия своего базового образа. Максимальный возраст версии рассчитывается с момента создания базового пользовательского образа, а не с момента создания производного изображения.\n\nНапример, если пользовательское изображение A создано во 2-й день, а пользовательское изображение B — из A на 4-й день с политикой максимального возраста версии в 7 дней, то и A, и B истекают на 9-й день.\n\n## Выставление счетов и хранение кастомных изображений\n\nЗадания, использующие кастомные изображения, оплачиваются по той же ставке за минуту, что и те крупное средство выполнения , что используют это изображение. Хранение пользовательских изображений оплачивается отдельно через GitHub Actions хранилище.\n\nЕсли вы часто перестраиваете изображения и сохраняете старые версии, использование хранилища может быстро расти, потому что каждая успешная задача рабочего процесса, включающая `snapshot` это ключевое слово, создаёт новую версию изображения. Дополнительные сведения см. в разделе \\[AUTOTITLE и [Биллинг GitHub Actions](/ru/billing/concepts/product-billing/github-actions#custom-image-storage)]\\(/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#custom-images-retention-policies).\n\n## Управление пользовательскими образами\n\nВы можете просматривать подробную информацию о каждом изображении, удалять неиспользуемые изображения или определенные версии, а также отслеживать версии изображений с течением времени.\n\n1. На GitHubперейдите на главную страницу организации.\n2. Под именем организации щелкните ** Settings**. Если вкладка \"Параметры\" не отображается, выберите **раскрывающееся меню ** и нажмите кнопку **\"Параметры**\".\n\n \n3. На левой боковой панели нажмите ** Действия**, затем нажмите **Пользовательские изображения**.\n4. На странице \"Пользовательские изображения\" вы можете просмотреть все пользовательские образы, созданные в вашей организации или предприятии.\n5. Чтобы просмотреть сведения о конкретном изображении, нажмите на его название.\n\n## Установка пользовательских образов\n\nКогда ваш кастомный образ будет готов, вы можете установить его на новый Более крупное средство выполнения, размещенное в GitHub.\n\n1. Следуйте шагам для создания крупное средство выполнения:\n * Сведения об организациях см. [в разделе Добавление более крупного средства выполнения тестов в организацию](/ru/actions/how-tos/manage-runners/larger-runners/manage-larger-runners#adding-a-larger-runner-to-an-organization).\n * Сведения о предприятиях см. [в разделе Добавление более крупного средства выполнения тестов в предприятие](/ru/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners/manage-larger-runners#adding-a-larger-runner-to-an-enterprise).\n\n2. При настройке бегуна:\n * **Платформа**: выберите ту же платформу, которую вы использовали для создания образа (Linux x64, Linux ARM64 или Windows x64).\n * **Изображение**: выберите вкладку **«Пользовательский** », затем выберите свое пользовательское изображение из списка.\n * Если вы не видите свое изображение, убедитесь, что вы выбрали правильную платформу и что вы создаете средство выполнения на том же уровне (организации или предприятии), где было создано изображение.\n * **Версия образа**: выберите **Последняя** , чтобы автоматически использовать самую последнюю версию, или выберите конкретный номер версии, чтобы закрепить средство выполнения этой версии.\n * Если вы выберете **Последнее**, средство выполнения автоматически обновится, когда станет доступна новая версия образа. Если вы закрепили средство выполнения тестов определенную версию, вам потребуется отредактировать его вручную, чтобы обновить его позже.\n * **Размер**: выберите размер бегуна с объемом памяти, равным или превышающим размер вашего изображения. Например, если образ был создан на 8-ядерном средстве выполнения, выберите 8-ядерный или более крупный для запуска этого образа.\n * **Группа средств выполнения**: назначьте средство выполнения тестов группе средств выполнения, которая является общей для репозиториев, которым необходимо использовать этот образ.\n\n3. В вашей GitHub Actions работе с рабочим процессом установите `runs-on` ключ к имени вашего бегуна.\n\n ```yaml\n jobs: \n build:\n runs-on: my-custom-runner\n steps:\n # Add any steps for your workflow here\n ```\n\n4. Запустите рабочий процесс, чтобы убедиться в его успешном завершении. В журналах заданий имя и версия образа будут отображаться в разделе \"Настройка задания\".\n\n## Лучшие практики безопасности для пользовательских изображений\n\nЧтобы предотвратить несанкционированные изменения ваших изображений, следуйте этим лучшим практикам.\n\n* **Используйте специализированные группы бегунов для создания изображений.** Бегуны, которые генерируют производственные изображения, должны оставаться в отдельной группе. Не делите группы раннеров между производственными, разработочными или тестовыми репозиториями, так как любой, кто имеет доступ к репозиторию разработки или тестового репозитория, может внедрить вредоносный код в производственный образ.\n* **Не разрешайте публичным репозиториям доступ к запускам генерации изображений.** Ограничьте количество репозиториев, которые могут использовать runrunner для генерации изображений, только теми, которым это необходимо, и регулярно проверяйте доступ.\n* **Применяйте наименьшие привилегии к репозиториям.** Избегайте предоставления общеорганизационного `write` доступа для репозиториев, имеющих доступ к раннерам генерации изображений. Поскольку изображения можно генерировать из любой ветки, любой, обладающий доступом к записи, мог создать ветку с произвольным кодом и запустить генерацию изображений."}