Перестроение контейнера в пространстве кода

О перестроении контейнера разработки

При работе в пространстве кода среда разработки — это контейнер Docker, который выполняется на виртуальной машине. Если вы вносите изменения в конфигурацию контейнера разработки из пространства кода и хотите применить эти изменения к текущему пространству кода, необходимо перестроить контейнер.

По умолчанию при перестроении контейнера разработки GitHub Codespaces ускорит процесс сборки, повторно используя кэшированные образы из предыдущих сборок контейнера. Обычно это самый быстрый способ реализации изменений в конфигурации контейнера разработки по следующим причинам.

GitHub Codespaces может повторно использовать образы в кэше, а не отталкивать их от реестров контейнеров.
Части конфигурации контейнера разработки, определяющие, как создается контейнер, например функции контейнера разработки и инструкции Dockerfile, уже были реализованы на уровнях образов в кэше, поэтому вам не придется ждать, пока эти процессы будут выполняться снова. (Однако команды в конфигурации, выполняемой после сборки контейнера, например onCreateCommand, будут выполняться снова.)

Иногда может потребоваться выполнить полное перестроение контейнера. При полном перестроении GitHub Codespaces очищает все контейнеры Docker, образы и тома из кэша, а затем перестраивает контейнер с новыми извлекаемых образами. Все настройки, определенные в конфигурации, будут выполняться снова, создавая новые слои образов. Вы можете выполнить полную перестроение после многих итерации перестроения контейнера с кэшированные образы в таких ситуациях, как показано ниже.

Необходимо убедиться, что настройка, определенная в конфигурации, не зависит от кэшированных образов, и будет выполняться по мере необходимости при создании нового пространства кода на основе конфигурации. Например, зависимость может быть удалена из базового образа после последнего извлечения в пространство кода.
Вы хотите освободить место на диске, используемое кэшем, например, если вы не используете место на диске или хотите свести к минимуму расходы на хранение. Кэш образов может использовать значительное количество дискового пространства, если вы несколько раз изменили базовый образ, если вы внесли большое количество итеративных изменений в конфигурацию или выполняете несколько контейнеров с Помощью Docker Compose.

Перестроение контейнера

Контейнер можно перестроить в пространстве кода в веб-клиенте или классическом приложении VS Code или использовать GitHub CLI.

Перестроение контейнера разработки в веб-клиенте или классическом приложении VS Code

Доступ к VS Code Command Palette с помощью shift Command+P (Mac) или CTRL+SHIFT++P (Windows/Linux).
Начните вводить "Перестроить" и выберите "Пространства кода: перестроить контейнер".
Выберите "Перестроить " или "Полная перестроение " в открывшемся диалоговом окне подтверждения.
Если изменения в конфигурации контейнера разработки приводят к ошибке контейнера, codespace запустится в режиме восстановления и появится сообщение об ошибке.
- Диагностируйте проблему путем просмотра журналов создания. Для этого нажмите кнопку Просмотр журнала создания.
- Чтобы устранить ошибки, выявленные в журналах, обновите файл devcontainer.json.
- Чтобы применить изменения, перестройте контейнер.

Использование GitHub CLI для перестроения контейнера разработки

Если вы изменили конфигурацию контейнера разработки за пределами VS Code (например, GitHub или в интегрированной среде разработки JetBrains), можно использовать GitHub CLI для перестроения контейнера разработки для существующего пространства кода.

В терминале введите следующую команду.
```
gh codespace rebuild
```
Перечислены пространства кода.
Используйте клавиши со стрелками на клавиатуре, чтобы выделить требуемое пространство кода, а затем нажмите клавишу ВВОД.

Чтобы выполнить полную перестроение с помощью GitHub CLI, можно использовать gh codespace rebuild --full команду.

Сохранение данных при перестроении

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

/workspaces За пределами каталога пространство кода содержит структуру каталогов Linux, которая зависит от образа контейнера разработки, используемого для сборки пространства кода. Вы можете добавлять файлы или вносить изменения в файлы за пределами /workspaces каталога. Например, можно установить новые программы или настроить конфигурацию оболочки в файле, ~/.bashrcнапример. В качестве пользователя, не являющегося корневым, вы не можете автоматически записывать доступ к определенным каталогам, но большинство образов разрешают корневой доступ к этим каталогам с sudo помощью команды.

За пределами /workspaces``/tmp каталога каталоги в пространстве кода привязаны к жизненному циклу контейнера. Это означает, что все внесенные изменения сохраняются при остановке и запуске пространства кода, но не сохраняются при перестроении контейнера.

Если вы хотите сохранить файлы вне /workspaces каталога через перестроение, можно создать в нужном расположении в контейнере символьную ссылку (symlink) к постоянному каталогу. Например, в каталоге /workspaces/.devcontainer можно создать каталог config, который будет сохранен при перестроении. Затем вы можете связать символьной ссылкой каталог config и его содержимое как postCreateCommand в файле devcontainer.json.

{
    "image": "mcr.microsoft.com/devcontainers/base:alpine",
    "postCreateCommand": "chmod +x .devcontainer/postCreate.sh && .devcontainer/postCreate.sh"
}

В приведенном ниже примере файла postCreate.sh содержимое каталога config связано символической ссылкой с домашним каталогом.

#!/bin/bash
ln -sf $PWD/.devcontainer/config $HOME/config && set +x

Дополнительные материалы

Основные сведения о контейнерах разработки