Опыт использования VSCode Remote-Containers

Не так давно, в VSCode-insiders (для разработчиков или любителей получать и тестить все новое) билде появилось расширение Remote Development, которое включает в себя удобную разработку в докере, по SSH, WSL. И относительно недавно это расширение стало доступно в VSCode без приставки insiders.

Remote — SSH — Работайте с исходным кодом в любом месте, открывая папки на удаленной машине / ВМ с использованием SSH. Поддерживает подключение к x86_64 Linux SSH серверам сейчас, и все больше платформ находятся на подходе.
Remote — Containers — Работайте с изолированной цепочкой инструментов или приложением на основе контейнера, открывая любую папку внутри (или вмонтированную) в контейнер.
Remote — WSL — Получите опыт разработки на базе Linux, не выходя из Windows, открыв любую папку в подсистеме Windows для Linux.

Но речь в этой статье пойдет о Remote — Containers. Я опробовал это расширение на практике (пока оно было доступно в VSCode-insiders) и очень остался доволен.

Преимущества разработки с использованием Remote — Containers

• Вы и ваша команда перестают мучаться и адаптировать различные скрипты поднятия проекта, для разных операционных систем.
• У вас и вашей команды теперь отныне одна и единственная среда разработки в докере.
• Все необходимые переменные окружения, вы можете уже сразу указать в Dockerfile или docker-compose.yml
• А еще в довесок поднять дополнительные контейнеры сервисов, которые необходимы для разработки (будь то redis, mysql или nginx, или еще какой сервис, все зависит от вашей фантазии)
• “Все это очень похоже на простое поднятие окружения из dev контейнеров или dev docker-compose.yml” — но это не совсем так и какие же отличия есть, пойдет сказ ниже.

Чем отличается Remote-Containers от обычного docker-compose up

0. Вы не можете проигнорить девелоперовский контейнер, вы просто не сможете разрабатывать. Это останавливающая сила, для тех, кто привык “разворачивать систему локально” игнорируя дев докеры.

• У вас есть один главный контейнер, в котором вы разрабатываете и при этом нет команд для запуска какого либо сервиса внутри, лишь команда, что поддерживает контейнер открытым (к примеру, sleep infinity). это ваше рабочее окружение и внутрь контейнера, добавлена папка, с вашим проектом, так что все изменения, внесенные локально или в докере — синхронизируются (собственно используются VOLUME настройки в докере, но уже автоматически).
• Для того, чтобы протестировать ваш сервис, вам самим нужно будет запустить его (или несколько сервисов, в разных терминалах в VSCode), как вы это делаете локально, но намного проще! Этот подход позволяет экспериментировать и не переживать по поводу изменения команды запуска, прописанную в конфигурации.
• Терминал VSCode, после запуска в режиме “Reopen in Container”,

будет смотреть внутрь контейнера, доступа к локальному терминалу в VSCode (в вашей ОС), у вас не будет. Так что, сколько бы вы ни запустили терминалов, внутри VSCode, все они будут запускаться удаленно — т.е. в контейнере. Таким образом, вы ничего не натворите плохого локально, ваша система не будет замусорена.

4. При этом, у вас есть возможность автоматически запустить сервисы Redis, Mysql или PostgreSQL и это сделает VSCode в содружестве с Docker Desktop или просто Docker демоном вашей ОС.

5. Git как VCS прокидывается автоматически в контейнер и коммитить, пушить или обновляться, из репозитория, не составит труда.

6. Создается рабочая папка с проектом и именно эта папка будет рутовой в терминале VSCode.

7. Гибкая настройка команд, выполняемых после старта контейнера.

8. Все это возможно благодаря автоматическому деплою vscode-server внутрь контейнера.

9. Настройка расширений, которые нужно поставить в докер.

Как начать разработку с использованием Remote-Containers?

1. Для начала нужно создать папку с проектом

2. Установить расширение Remote Development от Microsoft

3. Нажать на (Ctrl) Command + Shift + P для вызова меню команд VSCode

4. Набрать текст Remote-Containers: для того, чтобы отфильтровать все доступные команды.

4. Выбрать пункт Remote-Containers: Create Container Configuration File

5. Появится следующий список c уже готовыми конфигурациями:

6. Если вы разрабатываете на python, то набрав слово python, вы увидите список готовых конфигураций:

Как видите, тут есть возможность создания как расширенной настройки с двумя сервисами Python 3 & PostgreSQL, так и простой конфигурации с Python 2 или Python 3 на борту. Точно также и с node.js и любой другой платформой или языком программирования.

7. Если в списке, не нашлось подходящего для вас, не беда, можно самому подкорректировать базовую конфигурацию для себя

8. Далее в зависимости от того, какую конфигурацию вы выбрали, у вас будет одна из ниже перечисленных картин в дереве исходного кода в VSCode.

Или же

Как видно из изображений выше, если появляются два сервиса, то создается docker-compose.yml. Если всего один сервис, то будет создан Dockerfile.

9. Далее VSCode предложит запустить ваш проект в контейнере, следующим всплывающим окном

Нажав на “Reopen in Container” вы запустите процесс создания окружения в докере.

Или же, если по каким-либо причинам, вы закрыли окно, то не стоит переживать, можно воспользоваться комбинацией клавиш (Ctrl для Windows и Linux) Command + Shift + P и набрав Remote-Containers: Reopen Folder in Container…

Вы запустите аналогичный процесс.

Совет! Вы можете быстрее открыть только нужные пункты меню для Remote-Containers, нажав на зеленую кнопку с “><“, в левом нижнем углу VSCode.

10. Далее вы можете наблюдать за процессом поднятия окружения и как только все будет готово, терминал в VSCode будет присоединен к контейнеру.

Как только процесс скачивания образов и деплоя сервера VSCode в докер, будет закончен, у вас появится следующая картина.

И вы сможете создать терминал, который будет смотреть внутрь контейнера и выполнять в нем такие же действия, что и в локальной системе.

Содержимое папки .devcontainer

Давайте обратим свой взор внутрь этой папки, в которой сосредоточены настройки для Remote-Containers.

devcontainer.json

Этот файл естественно отличается содержимым, если используется несколько сервисов контейнеров или только один рабочий контейнер.

В случае с несколькими сервисами, основное внимание стоит уделить свойствам:

• service —название основного сервиса в docker-compose.yml. Что будет указано, туда и будет подключена VSCode.
• extensions — тоже, что и для одиночного контейнера (описание ниже)
• shutdownAction — очень важный пункт. В данном случае указана команда stopCompose — что эквивалентно команде docker-compose down, когда вы закрываете VSCode или выбираете команду Remote-Containers: Reopen Folder Locally

• postCreateCommand — тоже, что и для одиночного контейнера (описание ниже)

В случае с одним сервисом, внимание стоит уделить свойствам:

• appPort — позволит прокинуть порт из докер контейнера VSCode в вашу ОС (разумеется на этом порту вы получите отклик если вручную запустите сервис в терминале VSCode)
• extensions — очень важный параметр, так как расширения установленные локально, в VSCode не будут автоматом поставлены в докер вместе с серверной частью VSCode. Названия расширений отображаются при клике на расширении в меню расширений VSCode. Именно это название стоит копировать и вставлять в список расширений, необходимых для разработки. Очень удобно! Другому разарботчику, не нужно думать или знать, какие расширения нужно поставить, чтобы комфортно разрабатывать.

• postCreateCommand — эта команда важна для запуска действий после создания контейнера, к примеру установки зависимостей (что часто забывают делать разработчики) перед стартом разработки. Или установки каких либо специфических библиотек.

Вот пример, с указанным портом для проброса в локальную ОС и списком необходимых расширений для VSCode

Dockerfile (в случае единственного контейнера)

Это стандартный докер, только без CMD или ENTRYPOINT команд в конце. Все что нужно сделает VSCode.

В нем производится установка необходимых зависимостей, установка глобальных пакетов (часто это подводный камень для команды разработчиков, часто бывает что ни в README ни в другом источнике, не указываются эти важные пакеты. В package.json их не добавить, увы).

Конечно, можно и так:

"scripts": {
"preinstall": "npm i -g name_of_global_module"
}

но все же это не так очевидно.

Вот тут https://github.com/npm/npm/issues/2949 народу просто очевидно сказали — “добро пожаловать в эру докера”, мол незачем вам впихивать в package.json то, что выходит за его границы ответственности. В принципе с этим я тоже согласен.

docker-compose.yml (в случае конфигурации с несколькими контейнерами)

Тут, как говорится, можно разойтись с душой, на что гораздо ваше воображение.

Вот пример моего композа, подправленного после создания шаблонной конфигурации, в результате разработки.

В папке также может присутствовать файл requirements.txt.temp или package.json.tmp. Но эти файлы нужны для того, чтобы если в проекте в друг по каким то причинам не окажется такового, то контейнер будет все равно запущен. В противном случае, команда COPY бы оборвалась и контейнер бы не поднялся.

Вот эта команда COPY .devcontainer/requirements.txt.temp requirements.txt* /workspace/ работает отлично с requirements.txt.temp, это некий такой хак, если requirements.txt будет отсутствовать, то COPY команда скопирует файл requirements.txt.temp и создание окружения разработчика будет продолжено.

Недостатки

• Нет функционала удобного копирования файлов из локальной системы в VSCode удаленно, приходится либо производить копирование через локальный терминал, либо пользоваться командами, открытия папки локально. Благо повторное открытие в докере выполняется быстро. Так что пока это не особо надоедает и не так часто это приходится делать.
• Нет возможности открыть локальный терминал, что будет смотреть в вашу систему, пока вы находитесь в режиме удаленной разработки. А было бы круто, если бы рядом с “+” кнопкой, в окне терминала, была возможность выбрать, какой вид терминала открыть, локальный или удаленный. C другой стороны я понимаю почему так не сделали, во избежание конфуза и проделывания тех действий, что по невнимательности пользователя, могут произвестись на реальной системе. Но тут можно найти компромис, как-то дать понять пользователю, что вот это локальный терминал и в нем ты будешь производить действия в реальной системе.

Эпилог

На этом все! Спасибо за то, что дочитали до конца статьи. Выбор как всегда за вами. И да прибудет с вами сила )))!

Ранее статья была опубликована тут.