Глава 10. Применение WSL для корпоративной разработки

Содержание

При помощи природы взаимодействия WSL вы можете запускать предпочитаемые вами IDE или редактор в Windows, в то время как остаётесь совместимым с исполнением своего проекта внутри реальной среды Linux. По той причине, что WSL2 пользуется настоящим ядром Linux, открываются новые имеющиеся возможности, такие как способность запуска дистрибутива Kubernetes для разработки систем с архитектурой микрослужб. Также имеется заманчивая возможность применения графического процессора (GPU) вашей рабочей станции или ноутбука для ускорения задач машинного обучения.

Создание рабочей станции Microk8s

Весь компьютерный мир гудит относительно идеи разработки микрослужб и шаблонов развёртывания. Эти понятия становятся возможными при помощи программного обеспечения Kubernetes, о котором было бы трудно не слышать. Canonical, та компания, которая стоит за неизменно популярным Ubuntu, упаковала дистрибутив Kubernetes, который они назвали “microk8s”. Отличная новость относительно microk8s состоит в том, что он целиком самостоятельно упакован в контейнер и устанавливается единственной командой.

Предварительные требования для Microk8s

Отличная новость относительно microk8s состоит в том, что он упакован в пакет Snap. Snap это самоупаковывающиеся пакеты, которые содержат все необходимые для их работы приложения и устанавливаются просто и быстро. Данное руководство требует чтобы вы обладали рабочим дистрибутивом в WSL2 с разрешённым в нём systemD, поскольку Snap требует для корректной своей работы systemD. Убедитесь что вы ознакомились с Главой 7, Персонализация WSL на предмет подробностей включения systemd в вашей среде.

Для того чтобы убедиться что ваша среда настроена как нужно, выполните (Рисунок 10-1):


> snap version

Рисунок 10-1

Запуск “snap version” в WSL2 неким работающим systemd

Если ваша система установлена корректно, здесь будет сообщение о версиях ваших Snap и Snapd совместно с запущенным вами дистрибутивом и версией ядра WSL2.

Теперь, когда у нас имеется, по крайней мере отвечающий, Snapd, попробуйте установить и исполнить hello-world:


> sudo snap install hello-world
> hello-world

Это должно успешно установить Snap hello-world из Snap Store и исполняет эту новую команду. Если всё работает, команда hello-world выдаст на печать приветственное сообщение (Рисунок 10-2):

Рисунок 10-2

Успешно установленный и исполнивший “hello-world” пакет Snap

Установка Microk8s

Наши поздравления, теперь у вас есть всё что вам нужно для установки Microk8s. Давайте далее установим его:


> sudo snap install microk8s --classic
> sudo usermod -a -G microk8s $USER
> newgrp microk8s
> sudo chown -f -R $USER ~/.kube
> microk8s status

Включение добавлений Microk8s

Теперь, обладая установленным microk8s вы можете выполнять доступ к панели управления Kubernetes при помощи kubectl, как обычно, а также развёртывать и управлять службами и подами посредством обычных инструментов, которые вы бы могли применять для администрирования в промышленном кластере. Вы также можете быстро включать и отключать различные добавления через команды microk8s enable и microk8s disable (Рисунок 10-3).

Рисунок 10-3

Успешная установка microk8s

Например, большинство развёртываемых в кластере Kubernetes рабочих потоков обычно осуществляют доступ к прочим службам в том же самом кластере через имена DNS. Эти имена внутренние для данного кластера, которые разрешаются в их соответствующие IP адреса через обычный поиск по DNS. Благодаря минималистской природе microk8s, такая предоставляемая CoreDNS служба DNS не включена сразу в поставке, но запросто разрешается (Рисунок 10-4):


> microk8s enable dns

Рисунок 10-4

Включение в microk8s службы CoreDNS

Вы можете удалить функциональность CoreDNS снова когда она больше не требуется при помощи


> microk8s disable dns

Для установки схем (charts) Helm можно включить Helm при помощи (Рисунок 10-5):


> microk8s enable helm3

Рисунок 10-5

Включение Helm 3 для microk8s

Развёртывание кластера при помощи Helm

Обычный способ развёртывания рабочих потоков в кластере Kubernetes состоит в применении Helm. Доступ к нему в microk8s осуществляется при помощи команд microk8s.helm или microk8s.helm3. Первая это Helm 2, а вторая для Helm 3. Какую вы выберете это остаётся за вами и скорее всего зависит от той версии, которую вы применяете в своей промышленной среде. Если у вас нет предпочтений, давайте начнём с Helm 3. Какую бы из них вы не выбрали, вам следует включить его в своей системе microk8s при помощи команды enable:


> microk8s enable helm3

Чтобы иметь возможность обогатить наши службы нам потребуется включить контроллер ingress microk8s (Рисунок 10-6) при помощи:


> microk8s enable ingress

Рисунок 10-6

Включение контроллера ingress microk8s

Теперь мы можем установить блог Ghost (Рисунок 10-7) через:


> microk8s.helm3 repo add groundhog2k https://groundhog2k.github.io/helm-charts/
> microk8s.helm3 repo update
> microk8s.helm3 install ghost groundhog2k/ghost

Рисунок 10-7

Установка блога Ghostпри помощи microk8s и helm3

Теперь вы можете применять microk8s.helm3 для развёртывания как если бы вы применяли Helm в своей промышленной среде. За сведениями о применении воспользуйтесь microk8s.helm3 help и https://helm.sh/ для документации по Helm раз вы решили остановиться на нём.

Применение рабочего стола Docker

Установка рабочего стола Docker в WSL

Если у вас имеется установленным в Windows Docker Desktop из www.docker.com/get-started, мы можем настроить его для включения поддержки под WSL. Отыщите иконку Docker в вашем системном лотке (следующий за часами вашей полоски задач) и дважды кликните по ней (Рисунок 10-8).

Рисунок 10-8

Отображение иконки рабочего стола Docker в системном лотке

В этом новом окне кликните по иконке настроек справа вверху - она выглядит как шестерёнка.

Прежде всего убедитесь что он включён на применение механизма на основании WSL2 (Рисунок 10-9). Это заменит виртуальную машину Docker Desktop на среду с малым весом, использующую инфраструктуру WSL2.

Рисунок 10-9

Включение возможности применения механизма на основе WSL2 для рабочего стола Docker

Теперь мы переместимся к Resources и далее к WSL Integration. Здесь мы можем включать и отключать интеграцию Docker Desktop с дистро WSL применяя тот же самый Механизм (Engine) Docker из Windows и любого из включённых Дистро (Рисунок 10-10).

Рисунок 10-10

Настройка интеграции с WSL рабочего стола Docker

Сборка контейнера Docker

После настройки интеграции WSL с окном настроек Docker Desktop мы моем применять команды Docker внутри своего дистро WSL таким же образом, как мы могли бы делать это в Windows через PowerShell или cmd.exe. Для подтверждения этого мы воспользуемся образцом приложения getting-started Docker для отображения того как вы можете собирать образы контейнеров из WSL при помощи Docker Desktop.

Прежде всего клонируйте https://github.com/docker/getting-started воспользовавшись git:


> git clone https://github.com/docker/getting-started

Перейдём в каталог getting-started и выполните команду Docker build. Эта build, в случае успешного завершения, отобразит идентификатор образа, который мы применили для запуска своего контейнера (Рисунок 10-11):


> cd getting-started
> docker build .

Рисунок 10-11

Успешные сборка и запуск примера контейнером getting-started Docker

Теперь мы можем переместиться к http://127.0.0.1/ в веб браузере Windows для просмотра примера веб страницы (Рисунок 10-12).

Рисунок 10-12

Веб страница getting-started из того контейнера, который мы только что собрали и запустили при помощи интеграции рабочего стола Docker WSL

Подключение к редактору/ IDE

Visual Studio

IDE стандартом де факто для корпоративных клиентов является Visual Studio Microsoft, который можно интегрировать с WSL для сборки и отладки приложений .NET Core и .NET 5.0 для развёртывания в системах Linux.

Установка в версии 16.8 Visual Studio и более ранних

В Visual Studio 16.8 и более ранних версиях, включите эту функциональную возможность при помощи следующей этапности:

Откройте Visual Studio и выберите “Continue without code”.
Отыщите и откройте меню Extensions и выберите “Manage Extensions”.
В блоке поиска наберите слово Dot-Net-Core-Debugging-With-Wsl2
Кликните кнопку Download в элементе с меткой “.NET Core Debugging with WSL 2 – Preview” (Рисунок 10-13).

Рисунок 10-13

Выгрузка и установка .NET Core Debugging при помощи расширения WSL2 Visual Studio
После того как выгрузка завершится, закройте Visual Studio и позвольте закончиться установке (будьте готовы к приглашению на ввод UAC).

Установка в версии 16.9 Visual Studio и старше

В Visual Studio 16.9 и более поздних версиях эта функциональная возможность включается как составная часть, а потому для её включения мы воспользуемся приложением “Visual Studio Installer” - это то же самое приложение, которым вы пользуетесь для первоначальной установки Visual Studio в рабочей станции, обновите его для более новой версии и сможете добавлять и удалять функциональные возможности.

Вы можете включить функциональную возможность “.NET Core Debugging with WSL 2” как часть элемента “.NET Core cross-platform development” в закладке рабочего потока или выберите её из закладки “Individual components” (Рисунок 10-14).

Рисунок 10-14

Выбор .NET Core Debugging при помощи элемента WSL2 в установщике Visual Studio

Отладка вашего прикладного приложения в WSL

Чтобы иметь возможность отладки своих прикладных приложений в WSL2, она должна быть целью в .NET Core или .NET 5.0. Вы можете создать новый проект, который совместим через выбор Linux из выпадающих в окне “New project” платформ (Рисунок 10-15).

Рисунок 10-15

Создание нового проекта, имеющего целями Linux

После того как вы получили совместимый проект, выпадает меню для выбора того какую платформу применять для отладки, которое должно перечислить как вариант “WSL 2” (Рисунок 10-16). Если вы выбираете этот элемент, он настроит вашу среду для запуска приложений .NET Core или .NET 5.0 и затем позволяет вам запускать свой сеанс отладки.

Рисунок 10-16

Выбор “WSL2” в качестве среды для отладки

Visual Studio Code

Многие разработчики переходят на применение в качестве своего предпочтительного редактора Visual Studio Code. Code допускает бесшовную интеграцию с WSL при помощи его расширения “WSL Remote”. При помощи этого расширения Code, сам редактор расщепляется на две части, причём Интерфейс пользователя исполняется в Windows, однако те инструменты, которые используются для разработки и отладки запускаются в WSL. Вы можете даже открыть терминал изнутри Code, который покажет вам оболочку Bash из вашей среды WSL.

Чтобы начать, нам потребуется установить внутри Code расширение “WSL Remote”:

Для запуска Code выберите его из меню Start/Flag (Пуск) в Windows; или откройте диалог запуска (клавиша Windows + R), наберите Code и нажмите Ввод; либо воспользуетесь поиском Windows нажав клавишу Windows со своей клавиатуры, затем наберите Code и, наконец, нажмите Ввод.
Нажмите Ctrl+P и наберите ext install remote-wsl и затем нажмите Ввод. Это откроет экран расширений с расширением Remote WSL.
Кликните по кнопке “Install” в панели с правой стороны лежащей в основе панели расширений Code, озаглавленной “Remote – WSL” (Рисунок 10-17).

Рисунок 10-17

Экран установки WSL Remote extension для Visual Studio Code

Теперь, когда у нас имеется необходимое расширение, мы можем открыть файл или папку из своего дистро WSL:

Нажмите Ctrl+Shift+P.
Наберите remote-wsl.
Выберите параметр “New Window…” для открытия нового окна с установленным по умолчанию дистро WSL или “New Window using distro…” для выбора того дистро, который вы бы хотели применять (Рисунок 10-18).

Рисунок 10-18

Открытие нового окна Code, подключённого к WSL
Выберите “Open Folder” для поиска и открытия папки из своего дистро WSL (Рисунок 10-19).

Рисунок 10-19

Открытие папки из экземпляра now-connected WSL

Теперь вы заметите, что когда вы подключаетесь к экземпляру WSL, автоматически внизу справа в окне Visual Studio Code открывается терминал. Этот терминал является непосредственным представлением BASH, запущенном внутри WSL, а потому всё что было бы возможным в командной строке без Code, допустимо и здесь (Рисунок 10-20).

Рисунок 10-20

Демонстрация того, что терминал внутри Code это реальный терминал WSL

Применяя механизм клиент- сервер, который используется в Code, вы можете даже отлаживать свой исполняемый в WSL код из запущенного в Windows Code. В данном случае мы сталкиваемся с точкой прерывания в веб приложении .NET, которое запущено в WSL, при помощи исполняемого в Windows Code (Рисунок 10-21).

Рисунок 10-21

Отладчик натыкается на точку прерывания в Windows при отладке некого исполняемого в WSL .NET прикладного приложения веб

IDE JetBrains

IDE JetBrains поддерживает открытие проекта изнутри экземпляра WSL2 через показ особого пути \\wsl$ в диалоге File ➤ Open (Рисунок 10-22). При открытии или создании проекта из \\wsl$, IDE JetBrains автоматически переключится на применение Git изнутри своего экземпляра WSL.

Рисунок 10-22

Окно “Open File or Project” IDE JetBrains, отображающее доступные пути WSL

Как и в случае с удалённой отладки в WSL при помощи Visual Studio и Visual Studio Code, в IDE JetBrains растёт поддержка исполнения большего числа этапов сборки и отладки внутри экземпляра WSL. Одна из наилучших практик поддержки выполняется внутри WebStorm при сборке проекта NodeJS. При создании проекта вы можете определять что WebStorm применяет исполняемые файлы node и npm из вашего экземпляра WSL.

При создании нового проекта вы можете определять инструментарий внутри WSL:

Выберите ниспадающее “Node interpreter” и остановитесь на add (Рисунок 10-23).

Рисунок 10-23

Добавление нового “Node interpreter” в WebStorm
Внутри нового диалога введите путь к своему исполняемому файлу node, которым скорее всего будет /usr/bin/node, но может быть и иным в вашей системе (Рисунок 10-24).

Рисунок 10-24

Настройка пути к исполняемому “node” в дистрибутиве Ubuntu WSL
Теперь добавьте любой код и затем запускайте или отлаживайте своё приложение применяя обычные методы JetBrains. В приводимом ниже вы видите, что тривиальный пример на самом деле исполняется внутри WSL, на что указывает слово “linux” в получаемом выводе “Hello linux World!” (Рисунок 10-25).

Рисунок 10-25

Запуск тривиального образца для показа его исполнения в WSL

Применение проброса GPU вычислений

Искусственный интеллект и машинное обучение (AI/ML, Artificial intelligence и machine learning) становятся практически скрепоносным требованием для многих проектов. Одной из наиболее популярных инфраструктур AI/ML является TensorFlow от Google. При использовании TensorFlow применяется большое число интенсивных вычислений, которые не очень хорошо выполняются в ЦПУ и TensorFlow рекомендует применять графический процессор (GPU) для ускорения скорости вычисления на много порядков.

Тем не менее, в WSL2 графический процессор применяется в Windows для исполнения вашего дисплея и он не может отключаться от Windows для выделения в виртуальную машину своего WSL2 через технологию виртуализацию, известную как проброс PCI или проброс GPU. Рабочие потоки AI/ML включаются начиная со сборки Windows Insider номер 20150 доступен в выпуске Windows 21H1 для всех, где для WSL2 выставляется некий API для доступа к графическому процессору вашей рабочей станции без применения проброса при его отключении от вашей системы Windows.

CUDA nVidia

Для включения NVIDIA CUDA вы должны обладать GPU NVIDIA и выгрузить и установить драйверов разработчика с NVIDIA .

Наилучшая практика применения TensorFlow для CUDA NVIDIA состоит в использовании Docker внутри вашего экземпляра WSL. Если у вас имеется установленным в Windows Docker Desktop, проверьте, пожалуйста что интеграция WSL отключена для экземпляра WSL, потому как мы установим в такой системе натуральный Docker. Мы планируем поддержку вычисления GPU для Docker Desktop.

Установите в своём экземпляре WSL Docker. Здесь мы предполагаем либо Debian или Ubuntu:
```
> sudo apt -y install docker.io
> sudo adduser $USER docker
		
```

Включите репозитории APT NVIDIA:


> distribution=$(. /etc/os-release; echo $ID$VERSION_ID)
> curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add
> curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
> curl -s -L https://nvidia.github.io/libnvidia-container/experimental/$distribution/libnvidia-container-experimental.list | sudo tee /etc/apt/sources.list.d/libnvidia-container-experimental.list

Обновите кэши своего APT и установите среду исполнения NVIDIA для поддержки доступа к нашему контейнеру к GPU нашей рабочей станции:
```
> sudo apt update
> sudo apt install -y nvidia-docker2
		
```
Теперь необходимо остановить свой экземпляр WSL. В предположении что вызов выполняется из Ubuntu-20.04, выполните
```
> wsl.exe --terminate Ubuntu-20.04
		
```
Сейчас запустите эталонное тестирование для проверки того что CUDA работает надлежащим образом. Оно должно выдать сообщение о названии вашего устройства GPU; в данном случае это “GeForce GTX 960” (Рисунок 10-26).
```
> docker run --gpus all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -gpu -benchmark
		
```
Рисунок 10-26

Запуск эталонного теста NVIDIA CUDA в контейнере Docker
Теперь мы можем начать игры с TensorFlow. Запустите новый контейнер запустив Jupyter Notebooks (Рисунок 10-27):
```
> docker run -u $(id -u):$(id -g) -it --gpus all -p 8888:8888 tensorflow/tensorflow:latest-gpu-py3-jupyter
		
```
Рисунок 10-27

Успешный запуск Jupyter Notebooks с помощью TensorFlow
В самой последней строке полученного при запуске контейнера вывода отыщите URL и скопируйте его в адресную полоску браузера, замените 127.0.0.1 на слово localhost и нажмите Ввод для перехода туда (Рисунок 10-28).

Рисунок 10-28

Страница приветствия Jupyter Notebooks, отображающая вложенную папку tensorflow-tutorials

Теперь вы всё настроили для применения TensorFlow с использованием CUDA NVIDIA внутри WSL 2.

DirectML для не- nVidia GPU

Для включения DirectML в GPU AMD или в ЦПУ AMD, который обладает встроенной графикой в ЦПУ, вам следует выгрузить и установить драйверы разработчика AMD.
Для включения DirectML в GPU Intel или в ЦПУ Intel, который обладает встроенной графикой в ЦПУ, вам следует выгрузить и установить драйверы разработчика Intel.

При помощи “Miniconda” мы установим TensorFlow с поддержкой DirectML.

Выгрузите и установите Miniconda:


> wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
> bash Miniconda3-latest-Linux-x86_64.sh

Создайте новую среду Python и активируйте её внутри своего текущего сеанса оболочки:
```
> conda create --name directml python=3.6
> conda activate directml
		
```
При помощи “PIP”, установщика пакетов Python, установите пакет TensorFlow:Code
```
> pip install tensorflow-directml
		
```
Проверьте что вы можете запускать рабочие нагрузки с ускорением при помощи простого примера. Вставьте следующий код в интерактивный сеанс Python, который мы запускаем исполняя python:
```
>>> import tensorflow.compat.v1 as tf
>>> tf.enable_eager_execution(tf.ConfigProto(log_device_placement=True))
>>> print(tf.add([1.0, 2.0], [3.0, 4.0]))
		
```

За дополнительными примерами обратитесь к репозиторию GitHub Microsoft.