О перестроении контейнера разработки
При работе в пространстве кода среда разработки — это контейнер 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