Сведения о контейнерах разработки
Контейнеры разработки или контейнеры разработки — это контейнеры Docker, которые специально настроены для предоставления полнофункционационной среды разработки. Каждый раз, когда вы работаете в среде codespace, вы используете контейнер разработки на виртуальной машине.
Можно настроить контейнер разработки для репозитория, чтобы codespace, созданные для этого репозитория, дали вам специализированную среду разработки со всеми инструментами и средами выполнения, которые необходимо использовать для конкретного проекта. Если вы не определили конфигурацию в репозитории, GitHub Codespaces использует конфигурацию по умолчанию, которая содержит множество общих средств, которые может потребоваться команде для разработки проекта. См. статью "Использование конфигурации контейнера разработки по умолчанию".
Файлы конфигурации для контейнера разработки содержатся в каталоге .devcontainer в репозитории. Для добавления файлов конфигурации можно использовать Visual Studio Code. Можно выбрать одну из стандартных конфигураций для различных типов проектов. Их можно использовать без дополнительной настройки, либо можно изменить конфигурации для более точной настройки среды, которую они создают. См. статью "Использование предварительно определенной конфигурации контейнера разработки".
Кроме того, можно добавлять собственные пользовательские файлы конфигурации. См. статью "Создание настраиваемой конфигурации контейнера разработки".
Можно определить одну конфигурацию контейнера разработки для репозитория, разные конфигурации для разных ветвей или несколько конфигураций. При наличии нескольких конфигураций пользователи могут выбрать предпочтительную конфигурацию при создании среды codespace. Это особенно полезно для больших репозиториев, содержащих исходный код на разных языках программирования или для различных проектов. Можно создать набор конфигураций, которые позволяют разным командам работать в codespace, настроенном соответствующим образом для выполняемой ими работы.
При создании пространства кода из шаблона можно начать с одного или нескольких файлов конфигурации контейнера разработки в рабочей области. Чтобы настроить среду дальше, можно добавить или удалить параметры из этих файлов и перестроить контейнер, чтобы применить изменения к пространству кода, в который вы работаете. Если вы публикуете пространство кода в репозитории на GitHub, все пространства кода, созданные из этого репозитория, будут совместно использовать определенную конфигурацию. См. статью "Применение изменений конфигурации к пространству кода и Создание пространства кода на основе шаблона".
devcontainer.json
Основным файлом в конфигурации контейнера разработки является файл devcontainer.json. Этот файл можно использовать для определения сред codespace, созданных для репозитория. Содержимое этого файла определяет контейнер разработки, который может включать платформы, средства, расширения и перенаправление портов. Файл devcontainer.json обычно содержит ссылку на файл Dockerfile, который обычно находится рядом с файлом devcontainer.json.
При создании пространства кода из репозитория без devcontainer.json файла или при запуске из пустого шаблона GitHubиспользуется конфигурация контейнера разработки по умолчанию. См. статью "Использование конфигурации контейнера разработки по умолчанию".
Файл devcontainer.json обычно находится в каталоге .devcontainer репозитория. Кроме того, его можно расположить непосредственно в корне репозитория, в этом случае имя файла должно начинаться с точки: .devcontainer.json.
Если вы хотите выбрать конфигурации контейнеров разработки в репозитории, все альтернативные варианты .devcontainer/devcontainer.json файла (или .devcontainer.json) должны находиться в собственном подкаталоге по пути .devcontainer/SUBDIRECTORY/devcontainer.json. Например, вы можете иметь на выбор две конфигурации:
.devcontainer/database-dev/devcontainer.json.devcontainer/gui-dev/devcontainer.json
При наличии нескольких файлов devcontainer.json в репозитории каждый codespace создается только из одной из конфигураций. Параметры нельзя импортировать или наследовать между файлами devcontainer.json. Если файл devcontainer.json в настраиваемом подкаталоге содержит зависимые файлы, такие как Dockerfile или сценарии, выполняемые командами в файле devcontainer.json, рекомендуется располагать эти файлы в этом же подкаталоге.
Сведения о том, как выбрать предпочтительную конфигурацию контейнера разработки при создании пространства кода, см. в разделе Создание пространства кода для репозитория.
Сведения о параметрах и свойствах, которые можно задать в devcontainer.json файле, см . на веб-сайте "Спецификация контейнеров разработки".
Использование файла devcontainer.json
Рекомендуется рассматривать файл devcontainer.json как предоставление "настройки", а не "персонализации". Следует включать только те вещи, которые всем пользователям, работающим с вашей базой кода, необходимы в качестве стандартных элементов среды разработки, а не как личные предпочтения. Такие вещи, как анализатор кода, полезно стандартизировать и требовать, чтобы они были установлены у всех, поэтому они хорошо подходят для включения в файл devcontainer.json. Такие элементы, как декораторы пользовательского интерфейса или темы, — это личный выбор каждого, и их не следует помещать в файл devcontainer.json.
Вы можете персонализировать пространства кода с помощью dotfiles и синхронизации параметров. См . раздел AUTOTITLE.
Dockerfile
Dockerfile можно добавить как часть конфигурации контейнера разработки.
Dockerfile — это текстовый файл с инструкциями, необходимыми для создания образа контейнера Docker. Этот образ используется для создания контейнера разработки каждый раз, когда кто-то создает codespace с помощью файла devcontainer.json, который ссылается на этот файл Dockerfile. Инструкции в Dockerfile обычно начинаются со ссылки на родительский образ, на котором будет основан новый образ. За этим следуют команды, которые выполняются в процессе создания образа, например для установки пакетов программного обеспечения.
Файл Dockerfile для контейнера разработки обычно находится в папке .devcontainer вместе с файлом devcontainer.json, который на него ссылается.
Примечание.
В качестве альтернативы использованию Dockerfile можно использовать image свойство в devcontainer.json файле, чтобы ссылаться непосредственно на существующий образ, который вы хотите использовать. Указанное здесь изображение должно быть разрешено любой политикой образа организации, которая была задана. См . раздел AUTOTITLE. Если ни файл Dockerfile ни образ не найдены, используется образ контейнера по умолчанию. См. статью "Использование конфигурации контейнера разработки по умолчанию".
Простой пример файла Dockerfile
В следующем примере используются четыре инструкции:
`ARG` определяет переменную времени сборки.
`FROM` указывает родительский образ, на котором будет основан создаваемый образ Docker. Если политика базового образа настроена, разрешая использовать только определенные изображения, указанный образ должен соответствовать одной из ссылок на изображения в политике. Если это не так, пространства кода для этого репозитория будут созданы в режиме восстановления. См [. раздел AUTOTITLE](/codespaces/managing-codespaces-for-your-organization/restricting-the-base-image-for-codespaces).
`COPY` копирует файл из репозитория и добавляет его в файловую систему пространства кода.
`RUN` обновляет списки пакетов и запускает сценарий. Вы также можете использовать инструкцию `RUN` для установки программного обеспечения, как показано в комментариях. Чтобы выполнить несколько команд, используйте оператор `&&` для объединения команд в одну инструкцию `RUN`.
ARG VARIANT="16"
FROM mcr.microsoft.com/devcontainers/javascript-node:1-${VARIANT}
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
&& apt-get -y install --no-install-recommends bundler
# [Optional] Uncomment if you want to install an additional version
# of node using nvm
# ARG EXTRA_NODE_VERSION=18
# RUN su node -c "source /usr/local/share/nvm/nvm.sh \
# && nvm install ${EXTRA_NODE_VERSION}"
COPY ./script-in-your-repo.sh /tmp/scripts/script-in-codespace.sh
RUN apt-get update && bash /tmp/scripts/script-in-codespace.sh
ARG VARIANT="16"
FROM mcr.microsoft.com/devcontainers/javascript-node:1-${VARIANT}
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
&& apt-get -y install --no-install-recommends bundler
# [Optional] Uncomment if you want to install an additional version
# of node using nvm
# ARG EXTRA_NODE_VERSION=18
# RUN su node -c "source /usr/local/share/nvm/nvm.sh \
# && nvm install ${EXTRA_NODE_VERSION}"
COPY ./script-in-your-repo.sh /tmp/scripts/script-in-codespace.sh
RUN apt-get update && bash /tmp/scripts/script-in-codespace.sh
Примечание.
В приведенном выше примере скрипт, скопированный в пространство кода (script-in-your-repo.sh) должен существовать в репозитории.
Дополнительные сведения об инструкциях Dockerfile см . в справочнике по Dockerfile в документации по Docker.
Использование файла Dockerfile
Чтобы использовать файла Dockerfile в рамках конфигурации контейнера разработки, необходимо сделать ссылку на него в файле devcontainer.json с помощью свойства dockerfile.
{
// ...
"build": { "dockerfile": "Dockerfile" },
// ...
}
{
// ...
"build": { "dockerfile": "Dockerfile" },
// ...
}
Различные варианты доступны, если вы хотите использовать существующую оркестрацию контейнеров в контейнере разработки. См. раздел "Параметры оркестрации" спецификации на веб-сайте "Контейнеры разработки".
Использование конфигурации контейнера разработки по умолчанию
Если вы не добавляете конфигурацию контейнера разработки в репозиторий или если конфигурация не указывает базовый образ для использования, то GitHub создает контейнер из образа Linux по умолчанию. Этот образ Linux включает ряд версий выполнения для популярных языков, таких как Python, Node, PHP, Java, Go, C++, Ruby и .NET Core/C#. Используются последние или LTS-выпуски этих языков. Существуют также средства для поддержки обработки и анализа данных и машинного обучения, таких как JupyterLab и Conda. Образ контейнера разработчика по умолчанию также включает другие инструменты и утилиты для разработчиков, такие как Git, GitHub CLI, yarn, openssh и vim. Чтобы просмотреть список всех языков, сред выполнения и средств, которые включены, используйте команду devcontainer-info content-url в терминале codespace и перейдите по URL-адресу, который выведет команда.
Сведения о том, что входит в образ Linux по умолчанию, см. в репозитории devcontainers/images .
Конфигурация по умолчанию является хорошим вариантом, если вы работаете над небольшим проектом, использующим языки и средства, которые предоставляет GitHub Codespaces.
Примечание.
GitHub не взимает плату за хранение контейнеров, созданных на основе образа контейнера разработки по умолчанию. Дополнительные сведения о выставлении счетов для хранилища пространства кода см. в разделе Биллинг GitHub Codespaces. Сведения о том, как проверить, создано ли пространство кода из образа контейнера разработки по умолчанию, см. в разделе Получение наиболее эффективной работы с включенным использованием.
Использование предопределенной конфигурации контейнера разработки
Если вы используете Codespaces в Visual Studio Codeили в веб-браузере, можно создать конфигурацию контейнера разработки для репозитория, выбрав из списка предопределенных конфигураций. Эти конфигурации предоставляют распространенные настройки для определенных типов проектов и помогут быстро приступить к работе с конфигурацией, которая уже имеет соответствующие параметры контейнера, Visual Studio Code и расширения Visual Studio Code, которые должны быть установлены.
Использование предопределенной конфигурации — это отличная идея, если требуется дополнительная расширяемость. Вы также можете начать с предопределенной конфигурации и изменять ее по мере необходимости в процессе развития проекта. Дополнительные сведения об определениях предопределенных контейнеров разработки см. в репозитории devcontainers/images .
Можно добавить предопределенную конфигурацию контейнера разработки либо во время работы в codespace, либо при локальной работе с репозиторием. Для этого в VS Code во время локальной работы, а не подключено к пространству кода, необходимо установить и включить расширение "Контейнеры разработки". Дополнительные сведения об этом расширении см. в разделе VS Code Marketplace. В следующей процедуре описывается процесс при использовании пространства кода. Действия в VS Code, если вы не подключены к пространству кода, очень похожи.
-
Перейдите к Visual Studio Code Command Palette (shift+), а затем начните вводить "добавить разработку". Щелкните "Кодовые пространства": добавление файлов конфигурации контейнера разработки.

-
Нажмите кнопку "Создать новую конфигурацию".
-
Нажмите кнопку "Показать все определения".

-
Щелкните определение, которое вы хотите использовать.

-
Следуйте инструкциям по настройке определения.
-
Нажмите кнопку ОК.
-
Если вы работаете в пространстве кода, примените изменения, нажав кнопку "Перестроить" в всплывающем окне в правом нижнем углу окна. Дополнительные сведения о перестроении контейнера см. в разделе "Применение изменений конфигурации к пространству кода".

Добавление дополнительных функций в файл devcontainer.json
Функции — это автономные единицы кода установки и конфигурации контейнера разработки, предназначенные для работы в широком диапазоне базовых образов контейнеров. Функции можно использовать для быстрого добавления средств, сред выполнения или библиотек в образ пространства кода. Дополнительные сведения см. в спецификации [ доступных функций и ](https://containers.dev/implementors/features/)функций на веб-сайте "Контейнеры разработки".
Вы можете добавить функции в devcontainer.json файл из VS Code или из репозитория на GitHub. См . раздел AUTOTITLE.
Создание настраиваемой конфигурации контейнера разработки
Если ни одна из предопределенных конфигураций не соответствует вашим потребностям, можно создать пользовательскую конфигурацию, написав собственный файл devcontainer.json.
-
Если вы добавляете один файл
devcontainer.json, который будет использоваться всеми, кто создает codespace из репозитория, создайте файл в каталоге.devcontainerв корне репозитория. -
Если вы хотите предложить пользователям выбор конфигурации, можно создать несколько пользовательских файлов
devcontainer.json, каждый из которых должен находится в отдельном подкаталоге каталога.devcontainer.Примечание.
- Вы не можете найти
devcontainer.jsonфайлы в каталогах более одного уровня ниже.devcontainer. Например, файл в каталоге.devcontainer/teamA/devcontainer.jsonбудет работать, а в.devcontainer/teamA/testing/devcontainer.json— нет. - Когда пользователи создают пространства кода из кнопки "Использовать этот шаблон" в репозитории шаблонов , они не будут выбирать между конфигурациями. Пространство кода будет создано на основе конфигурации по умолчанию, определенной в
.devcontainer/devcontainer.json, или в.devcontainer.jsonкорне репозитория. См . раздел AUTOTITLE.
Если несколько
devcontainer.jsonфайлов находятся в репозитории, они перечислены в раскрывающемся списке конфигурации контейнера разработки на странице параметров создания пространства кода. См . раздел AUTOTITLE.
- Вы не можете найти
`devcontainer.json` Добавление файла
Если у вас еще нет devcontainer.json файла в репозитории, можно быстро добавить его из GitHub.
-
Перейдите в репозиторий и щелкните раскрывающийся список Code .
-
На вкладке Codespaces щелкните многоточие (...), а затем выберите "Настроить контейнер разработки".

Новый .devcontainer/devcontainer.json файл откроется в редакторе. Файл будет содержать некоторые начальные свойства, включая features объект, в который можно добавить новые инструменты, библиотеки или среды выполнения. См . раздел AUTOTITLE.
Если репозиторий уже содержит один или несколько devcontainer.json файлов, щелкните "Настройка контейнера разработки" откроет существующий devcontainer.json файл с наивысшим приоритетом в соответствии со спецификацией на веб-сайте "Контейнеры разработки".
Выбор конфигурации по умолчанию во время создания пространства кода
Если файл .devcontainer/devcontainer.json или .devcontainer.json существует, он будет выбором по умолчанию в списке доступных файлов конфигурации при создании пространства кода. Если ни один из файлов не существует, будет выбрана конфигурация контейнера разработки по умолчанию.
На следующем снимке экрана репозиторий не содержит .devcontainer/devcontainer.json или .devcontainer.json файлы, поэтому выбрана конфигурация контейнера разработки по умолчанию. Однако в подкаталогах .devcontainer каталога определены два альтернативных файла конфигурации, поэтому они перечислены в качестве параметров.

Изменение файла devcontainer.json
Можно добавлять и изменять поддерживаемые ключи конфигурации в файле devcontainer.json, чтобы указать аспекты среды codespace, например, какие расширения VS Code будут установлены. Сведения о параметрах и свойствах, которые можно задать в devcontainer.json файле, см . на веб-сайте "Спецификация контейнеров разработки".
Файл devcontainer.json записывается с помощью формата JSONC (JSON с комментариями). Это позволяет включать комментарии в файл конфигурации. См. статью "Редактирование JSON" с помощью VS Code в документации по VS Code.
Примечание.
Если вы используете linter для проверки devcontainer.json файла, убедитесь, что для него задано значение JSONC, а не JSON или примечания будут отображаться как ошибки.
Параметры интерфейса для VS Code
Параметры интерфейса можно настроить для VS Code, с тремя областями: user, Remote [Codespaces], and Workspace. Эти области можно просмотреть в редакторе параметров VS Code.
Для отображения редактора настроек используйте клавишную комбинацию Command+, (Mac) / Ctrl+, (Linux/Windows).

Если параметр определен в нескольких областях, в первую очередь приоритет имеют параметры рабочей области, затем параметры удаленного репозитория [Codespaces], а затем пользователя.
Параметры интерфейса по умолчанию можно определить для VS Code в двух местах.
- Параметры интерфейса, определенные в файле в
.vscode/settings.jsonрепозитории, применяются в качестве параметров области рабочей области в пространстве кода. - Параметры интерфейса, определенные в
settingsключе вdevcontainer.jsonфайле, применяются как удаленные параметры [Codespaces]-scoped в пространстве кода.
Применение изменений конфигурации к среде codespace
Изменения в конфигурации будут применены при следующем создании пространства кода. Однако изменения можно применить к существующему пространству кода, перестроив контейнер. Это можно сделать в пространстве кода в VS Code веб-клиента или классического приложения или использовать GitHub CLI.
Примечание.
При перестроении контейнера в пространстве кода изменения, внесенные за пределами /workspaces каталога, очищаются. Изменения, внесенные в /workspaces каталог, включая клон репозитория или шаблона, из которого вы создали пространство кода, сохраняются при перестроении. Дополнительные сведения см. в разделе Подробные сведения о GitHub Codespaces.
Перестроение контейнера разработки в веб-клиенте или классическом приложении VS Code
-
Перейдите к VS Code Command Palette (shift+Command+P CTRL SHIFT++P / ), а затем начните вводить "перестроить". Щелкните Codespaces: Перестроить контейнер.

Совет
Иногда может потребоваться выполнить полную перестроение, чтобы очистить кэш и перестроить контейнер с помощью свежих образов. Дополнительные сведения см. в разделе Перестроение контейнера в пространстве кода.
-
Если изменения в конфигурации контейнера разработки приводят к ошибке контейнера, codespace запустится в режиме восстановления и появится сообщение об ошибке.

- Диагностируйте проблему путем просмотра журналов создания. Для этого нажмите кнопку Просмотр журнала создания.
- Чтобы устранить ошибки, выявленные в журналах, обновите файл
devcontainer.json. - Чтобы применить изменения, перестройте контейнер.
Использование GitHub CLI для перестроения контейнера разработки
Если вы изменили конфигурацию контейнера разработки за пределами VS Code (например, на GitHub), можно использовать GitHub CLI для перестроения контейнера разработки для существующего пространства кода.
-
В терминале введите следующую команду.
gh codespace rebuildПеречислены пространства кода.
-
Используйте клавиши со стрелками на клавиатуре, чтобы выделить требуемое пространство кода, а затем нажмите клавишу ВВОД.