Инсталлируем Linux на MacOS при помощи QEMU

В этой статье я хочу рассказать и показать как создать  и запускать виртуальную машину с Ubuntu 20l.10 при помощи QEMU на MacOs (BigSur).

Что такое QEMU

Quick EMUlator (QEMU) это эмулятор "железа" с открытым исходным кодом (лицензия GPLv2), который для ускорения работы виртуальных машин может использовать различные акселераторы. На Linux это KVM, который встроен в ядро операционной системы, На  MacOS - это HVF. На сайте QEMU утверждается, что производительность виртуальных машин на основе QEMU близка к производительности таких машин на физическом железе. Давате проверим :).

Если тексту с картинками вы предпочитаете видео, то вот мой обзор QEMU на YouTube.

Устанавливаем QEMU

Установить QEMU на MacOS можно разными способами. У меня стоит Homebrew, с его помощью я и установил QEMU 

brew install qemu

Проверить, установлен ли QEMU можно запросив версию программы. 

qemu-system-x86_64 –version 

Если установка закончилась успешно, то вы получите что-то вроде такого сообщения.

Дополнительное приседание на Big Sur

Идем дальше. Для корректной работы QEMU на Big Sur его надо  вначале "пропатчить".Для этого создайте файл entitlements.xml с таким вот содержимым

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>com.apple.security.hypervisor</key>

    <true/>

</dict>

</plist>

Далее надо подписать qemu-system-x86_64 этим файлом

codesign -s - --entitlements entitlements.xml --force /usr/local/bin/qemu-system-x86_64

Теперь qemu-system-x86_64 готова для работы на Big Sur

Создание виртуальной машины с Ubuntu 20.10

Теперь переходим к созданию виртуальной машины для Ubuntu. Для инсталляции Ubuntu на виртуальную машину потребуется ее дистрибутив в формате ISO,  который можно скачать с официального сайта. Предположим, что он у нас находится в директории qemu-ubunut20. Все последующие команды я буду выполнять из этой директории. 

Далее для инсталляции Ubuntu нам потребуется создать файл диска виртуальной машины, где Ubuntu будет установлена. Я буду использовать формат QCOW2 и создам файл на 15 Гб. Он не будет занимать сразу 15 Гб, он изначально будет значительно меньше однако его предел - 15 Гб. Это значение можно будет изменить позже. Для создания файла диска воспользуемся командой

qemu-img create -f qcow2 ubuntu-20.10-desktop-amd64.qcow2 15G

Установка Ubuntu

Как только файл диска готов можно запустить виртуальную машину с подключённым QCOW2 диском и ISO-образом Ubuntu вот такой вот командой

qemu-system-x86_64 \

    -machine type=q35,accel=hvf \

    -smp 2 \

    -hda ubuntu-20.10-desktop-amd64.qcow2 \

    -cdrom ./ubuntu-20.10-desktop-amd64.iso \

    -m 4G \

    -vga virtio \

    -usb \

    -device usb-tablet \

    -display default,show-cursor=on

Давайте разберем параметры этой команды

• machine - Эмулируемая машина и тип акселератора. q35 - это один из последних типов машин, а HVF - это акселератор для MacOS.
• smp - Число процессоров для виртуальной машины
• m - Размер оперативной памяти для виртуальной машины
• hda - Ссылка на файл диска
• cdrom - Ссылка на ISO-файл
• vga - Графическая карта
• usb - Разрешает доступ к  USB-порту
• device - Добавляем "usb-tablet" как устройство ввода, иначе мышь может не заработать :)
• display -  Включаем отображение курсора мыши на экране. Отключено по умолчанию.

После загрузки виртуальной машины запустится инсталлятор Ubuntu. 

По окончанию инсталляции Ubuntu система предложит перезагрузиться. Вместо этого лучше закройте терминал с QEMU по Ctrl+C на MacOS. 

Запуск Ubuntu

Теперь для запуска виртуальной машины нам больше не нужен файл ISO-образа Ubuntu. По этому немного модифицируем команду запуска виртуальной машины, убрав из нее параметр cdrom. Команда для запуска достаточно объёмная, советую скопировать ее в sh-файл и хранить его в том же директории где и  файл виртуальной машины. Так будет удобнее запускать. Для этого создаем файл скрипта командой 

touch run.sh

Копируем содержимое в файл run.sh

qemu-system-x86_64 \

    -machine type=q35,accel=hvf \

    -smp 2 \

    -hda ubuntu-20.10-desktop-amd64.qcow2 \

    -m 4G \

    -vga virtio \

    -usb \

    -device usb-tablet \

    -display default,show-cursor=on

Далее надо сделать файл скрипта исполняемым

sudo chmod +x run.sh

Теперь можно запустить скрипт для старта виртуальной машины

./run.sh

Как запустить Linux GUI приложения из докер-контейнера

Признаюсь сразу,  мне было интересно попробовать это из "спортивного" интереса но я не вижу большого практического смысла в этом. В таком случае использование виртуальной машины считаю более целесообразным. В статье я расскажу про самый простой способ – запуск докер-контейнера из специально подготовленного докер-имиджа с Docker Hub. 

Если тексту с картинками вы предпочитаете видео, то вот мой обзор на YouTube.

Принцип работы с такими докер-контейнерами единый

1. Запускаем подходящий докер-контейнер. В статье я опишу несколько из них.
2. Подключаем приложение для удаленной работы с рабочим столом системы, работающей в контейнере. Это может быть VNC или  Remote Desktop. На Маке VNC клиент встроен в Finder, а Remote Desktop можно скачать из AppStore. На Windows ситуация обратная. В большинстве случаев приложение Remote Desktop входит в состав операционной системы, а VNC клиента можно скачать.

Рассмотрим работу с таким контейнером на примере одного из самых функциональных докер-имиджей - https://hub.docker.com/r/manishfoodtechs/xfcefulldesktop_ubuntu20.4

Данный имидж базируется на ubuntu 20.4 и имеет из коробки больше всего предустановленного софта – Firefox, LibreOffice и много других утилит. Автор докер-имиджа предлагает работать с контейнером через RDP. По тому команда для запуска контейнера будет иметь следующий вид. 

docker run -it -p 9096:3389 -e 3389 --shm-size 2g manishfoodtechs/xfcefulldesktop_ubuntu20.4

В этой команде «пробрасывается» порт для работы с контейнером через RDP – 3389. Поэтому, после старта контейнера нужно запустить сервер удаленного рабочего стола на основе протокола RDP

/etc/init.d/xrdp restart

Все. Теперь можно запускать Remote Desktop и подключаться к рабочему столу в контейнере. 

Я  приведу скриншоты с Remote Desktop на Маке. При подключении Remote Desktop пожалуется, что мне знает такого компьютера. Для продолжения нажмите кнопку Connect.

В качестве имени компьютера (PC Name) надо указать 127.0.0.1:9096, Username: root и Password: 123456

Не пугайтесь, иконки в системе стилизованы под Windows. Не знаю зачем, но даже иконка Firefox сделана как иконка Microsoft Edge, a иконки приложений LibreOffice стилизованы под Microsoft Office.

Можно в команду запуска докер-контейнера добавить ключ  -v $(pwd):/host  и тогда  можно  работать  с файлами из текущего директория их докер-контейнера. Полностью команда для запуска докер-контейнера будет выглядеть так

docker run -it -p 9096:3389 -e 3389 -v $(pwd):/host --shm-size 2g manishfoodtechs/xfcefulldesktop_ubuntu20.4

Если по каким-то причинам вы не хотите работать через RDP, то можно настроить контейнер для работы через VNC. В простейшем варианте, чтобы не делать свой докер-имидж это может выглядеть так.

Запускаем контейнер с открытием дефолтного порта для VNC – 5901 (вместо 3389)

docker run -it -p 5901:5901 -v $(pwd):/host --shm-size 2g manishfoodtechs/xfcefulldesktop_ubuntu20.4

Далее, после старта контейнера в контейнере через терминал устанавливаем VNC server

sudo apt install tightvncserver

 

и запускаем VNC server

sudo vncserver

VNC server при запуске попросит создать и подтвердить пароль для удаленного доступа к рабочему столу. На вопрос  "Would you like to enter a view-only password (y/n)?". Отвечаем “n”.

Все приготовления сделаны. Теперь можно подключать VNC клиента. На Маке VNC клиент встроен в Finder (Go->Connect to Server). В качестве стоки подключения нужно указать vnc://127.0.0.1:5901

В окне ввода пароля указываем тот пароль, который придумали на этапе запуска vncserver.

Если вам понравилась эта тема, то на Docker Hub есть и другие имиджи на Linux c GUI которые стоит попробовать. Могу посоветовать 

1. https://hub.docker.com/r/dorowu/ubuntu-desktop-lxde-vnc - есть разные версии Ubuntu. 20, 18, 16, 14. Что весьма удобно, с десктопом можно как через VNC клиента, так и есть веб-интерфейс, т.е. можно работать из браузера.
2. https://hub.docker.com/r/queeno/ubuntu-desktop/ - «голая» Ubunut 16.04. Работа через VNC
3. https://hub.docker.com/r/cyverse/ubuntu18-xfce-desktop - «голая» Ubunut 18.04. Работать с контейнером можно  как при помощи веб-интерфейса, так и через VNC  клиента.

Отладка сборки докер-имиджа

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

Если тексту с картинками вы предпочитаете видео, то вот мой обзор отладки докер-имижа на YouTube

Как известно, сборка докер-имиджа разбита на этапы и каждый такой этап выполняется в отдельном докер-контейнере, который потом формирует промежуточный докер-имидж. Самый первый контейнер  формируется из команды FROM в Dockerfile. Вот скриншот сборки для моего довольно простого докер-файла и в нем команда docker image build создала семь промежуточных докер-имиджей, а восьмой - стал финальным.

Промежуточные докер-имиджи не удаляются, а сохраняются. Их можно посмотреть командой 

docker image ls -a

Теперь переходим к самому интересному. Если сборка докер-имиджа идет не так как вы ожидали или вы не понимаете, почему докер-имидж получился таким каким получился, то можно  запустить контейнер на основе промежуточного имиджа, запустить на  нем терминал и проверить его содержимое и состояние. Сделать  это можно вот такой командой

 docker run --rm -it 09db5a1c9e94 sh

здесь

• 09db5a1c9e94 - это ID докер-имиджа который я хочу проверить. 
• флаг  --rm создаст временный докер-контейнер, который будет автоматически удален при выходе из  него.
• флаг -it переведет контейнер в интерактивный режим.

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

docker image purne

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

Удачной и легкой вам отладки!

Отладка Node.js приложения в докер-контейнере

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

Весть процесс, с большего, состоит из 3-х шагов.

1. Надо изменить запуск Node.js, чтобы он работал с включенным режимом отладки.
2. Открыть доступ к порту, указанному при включении режима отладки в Node.js.
3. Настроить инструмент для отладки. Это может быть любая IDE. Многие разработчики пользуются VS Code, я им тоже пользуюсь, на его примере я и покажу в этой статье как это сделать.

Если тексту с картинками вы предпочитаете видео, то вот мой обзор отладки Node.js приложения в докер-контейнере на YouTube

 

Я этого примера создал простое Node.js приложение и докер-файл для него. Полный пример Node.js приложения и Dockerfile к нему можно посмотреть в репозитории на GitHub.

const express = require("express");

const app = new express();

app.get("/", function(req, res){

res.send("Hello, World!");

});

const PORT = 8080;

app.listen(PORT, function(){

console.log("Listening on port " + PORT);

});

app.js

FROM node:14-alpine

WORKDIR /node-app

COPY package.json .

RUN npm install

RUN mv /node-app/node_modules /node_modules

COPY . .

CMD [ "node", "app.js" ]

EXPOSE 8080

Dockerfile

Шаг 1. Запускаем NodeJS в режиме отладки

Первое что надо сделать - это запустить Node.js в докер-контейнере в режиме отладки. Делается это передачей ключа --inspect при старте Node (вот здесь можно почитать подробнее). В Dockerfile у нас уже есть инструкция по запуску Node и переопределить настройки запуска Nods в контейнере можно разными способами - например, параметрами команды docker container run или можно создать файл для docker-compose и там переопределить ряд параметров. Вариант с docker-compose мне кажется более удобным.

version: '3.4'

services:

nodeapp:

build: .

ports:

- 8080:8080

command: node --inspect=0.0.0.0:9229 app.js

docker-compose.yml (not finished)

Шаг 2. Открываем доступ к порту

Теперь, дополнительно к порту на котором работает приложение нам надо открыть доступ к порту через который работает инспектор. Для этого обновляем docker-compose файл, чтобы открыть доступ к порту 9229, который мы указали в параметрах инспектора.

Зачастую так же удобно переопределить и путь к коду Node.js приложения, чтобы можно было внести изменения в код и убедиться, что приложение работает так как ожидается. Финальная версия docker-compose файла так же находится в репозитории на GitHub.

version: '3.4'

services:

nodeapp:

build: .

ports:

- 8080:8080

- 9229:9229

volumes:

- .:/node-app

command: node --inspect=0.0.0.0:9229 app.js

docker-compose.yml (final)

Запускаем docker-compose с флагом  --build :

docker-compose up --build

Шаг 3. Настраиваем VS Code и запускаем отладку

Теперь подключаем VS Code. Для этого надо добавить конфигурацию отладки в VS Code.

Для  начала надо перейти на панель отладки в VS Code

Далее, если launch.json есть, то надо добавить новую конфигурацию, 

Если launch.json еще не был создан, то его надо создать, кликнув на линку "create a launch.json file"

В появившемся списке шаблонов конфигураций можно выбрать "Node.js: Attach to Remote Program" а если такой нет, то любую и заменить ее на мой пример (файл на GitHub).

{

"address": "127.0.0.1",

"localRoot": "${workspaceFolder}",

"name": "Attach to Remote",

"port": 9229,

"remoteRoot": "/node-app",

"request": "attach",

"skipFiles": [

"<node_internals>/**"

],

"type": "pwa-node"

}

На что здесь важно  обратить внимание

• address - IP-адрес машины где запущен докер-контейнер. 
• port - порт через который работает Node Inspector. Он должен быть такой же как мы указывали в ключе --inspect.
• remoteRoot - путь в докер-контейнере, где находится код приложения.

Теперь можно запускать отладчик. Для этого нужно нажать кнопку "Start Debugging". 

В коде приложения можно ставить точки останова (breakpoints), проверять значения переменных и  полей объектов и пр.

Что можно сделать еще

Если пойти дальше и модифицировать немного Dockerfile можно с эпизодической отладки приложения перейти на полноценную разработку в Docker-контейнере. Это может быть удобно в случае когда надо разрабатывать и поддерживать приложения на разных версиях Node.js. Для этого нужно установить в docker-контейнер forever или любое другое приложение, которое  будет перезапускать Node при изменении кода и соответственно у нас немного изменится команда для запуска приложения. Новый докер-файл (я его назвал Dockerfile.dev) и docker-compose.dev.yml будут выглядеть так. 

FROM node:14-alpine

WORKDIR /node-app

RUN npm install -g forever

COPY package.json .

RUN npm install

RUN mv /node-app/node_modules /node_modules

COPY . .

CMD [ "forever", "-w", "app.js" ]

EXPOSE 8080

Dockerfile.dev

version: '3.4'

services:

nodeapp:

build:

context: .

dockerfile: Dockerfile.dev

ports:

- 8080:8080

- 9229:9229

volumes:

- .:/node-app

command: forever -w -c "node --inspect=0.0.0.0:9229" app.js

docker-compose.dev.yml

Поскольку у нового docker-compose файла имя отличное от дефолтного, то запускать его надо с немного другой командой

docker-compose -f docker-compose.dev.yml up --build

Play with Docker (PWD) - докер в твоем браузере

Play with Docker (PWD) это проект разработанный для изучения докера. Сервис может быть очень полезен тем, кто изучает докер так как дает возможность попробовать весь функционал докера прямо из браузера и не требуется ничего устанавливать локально. При это работает все исключительно быстро и буквально в течении секунды создается новая "виртуальная машина".

Сервис предоставляет на 4 часа до 5 как-бы виртуальных Linux-машин, на которых уже установлена последняя версия Docker Community Edition.  Сервис построен по технологии Docker-in-Docker. Так что это не настоящие виртуальные машины, а по сути докер-контейнеры с Linux. 

Если тексту с картинками вы предпочитаете видео, то вот мой обзор Play-with-Docker на YouTube 

Доступ к сервису бесплатный, требуется лишь логин на Docker Hub. Хостинг проекта спонсируется Docker Inc. и, ксати, на одной из конференций DockerCon утверждалось, что Docker Inc сама использует его  для обучения своих новых сотрудников.

Итак,  краткий перечень того, что позволяет Play with Docker

1. Конечно же запускать разные докер-контейнеры. Например, рекомендую попробовать мой любимый nginx. Сервис автоматически проксирует запросы к контейнеру "виртуальной машины". Так что если вы развернете контейнер с каким-нибудь веб-сервером у вас есть возможность посмотреть в браузере, как работает сайт.

2. Урл можно шэрать и тогда несколько человек будут работать с одной и той же сессией "виртуальной машины"

3. К "виртуальным машинам" можно подключаться по ssh работать с докером через ваш локальный терминал.

4. Из коробки работает автокомплит! И в браузере и в терминале при подключении по ssh, что конечно  очень удобно когда изучаешь докер.

5. Есть шаблоны для swarm режима. Можно очень быстро создать конфигурации с нодами-manager и worker

Для чего может быть полезен Play with Docker

1. Во первых, конечно же для изучения докера. Например, для изучения swarm режима, когда, по хорошему, нужно несколько машин. Для тех, кто изучает докер, на сервисе есть так же набор уроков https://training.play-with-docker.com/ (от основ, до деплоймента на прод).

2. Если вы хотите попробовать какие-то "фишки" новой версии докера, а у вас установлена старая версия.

3. Сервис может быть полезен для проведения "удаленных" интервью по докеру. Можно создать сессию, поделиться урлом с разработчиком, который проходит интервью и попросить его продемонстрировать навык работы с докером.

Health Check для докер-контейнера

С версии докера 1.12 в докер-контейнере появилась возможность проверки работоспособности контейнера – так называемый health check. 

Типичный health check организуется периодическим вызовом некой команды, которая проверяет «жив» ли сервис, который исполняется в контейнере. Так, для веб-сервера который отвечает за работу некоторого сайта это может быть команда curl которая проверяет переделённую страницу веб-сайта, это может быть оценка используемой памяти сервисом или загрузка процессора в течении некоторого времени.

Статус «здоровья» докер-контейнера до первой проверки принимает значение “starting”. После любой успешной проверки он становится “healthy”. Если тест «падает» несколько раз подряд в течении определенного интервала, то такой контейнер считается «плохим» (unhealthy). Статус докер-контейнера можно проверить командами “docker ps” и “docker container ls”.

Если тексту с картинками вы предпочитаете видео, то вот мой обзор healthcheck для docker container на YouTube.

Как включить health check для докер-контейнера

Health check для докер-контейнера может быть указан в нескольких местах

1. В командах “docker run” и “docker container run”
2. В файле Dockerfile
3. В файле Docker compose
4. В команде docker service create

Рассмотрим установку health check на примере Dockerfile. Для Dockerfile она имеет вот такой формат. Вот здесь можно посмотреть спецификацию команды helalthcheck для dockerfile 

            HEALTHCHECK [OPTIONS] CMD command

• OPTIONS – параметры проверки «здоровья» докер-контейнера. Их можно не указывать, если вас устраивают дефолтные параметры.
• command – непосредственно команда из оболочки (shell) которая проверяет состояние докер-контейнера.

Например, она может выглядеть так. 

        HEALTHCHECK --interval=30s --timeout=1s --retries=3 --start-period=10s CMD curl --fail http://localhost:80/ping.html || exit 1

• interval – указывает как часто надо проверять состояние докер-контейнера. По умолчанию - 30 секунд
• timeout – если выполнение команды занимает больше времени чем указано в этом параметра, то он считается не успешным. По умолчанию - 30 секунд.
• retries  -  число не успешных проверок выполненных подряд, после чего докер-контейнер считается «плохим» (unhealthy). По умолчанию - 3  попытки.
• start-period – время, которое дается контейнеру на первоначальную загрузку.. По умолчанию - 0 секунд

Пример. Простейщий dockerfile с healthcheck

FROM nginx

RUN echo "ping" >> /usr/share/nginx/html/ping.html

HEALTHCHECK --interval=30s --timeout=10s --retries=5 --start-period=10s \

 CMD curl --fail http://localhost:80/ping.html || exit 1

Собираем образ командой 

docker image build  -t testhl .

и запускаем докер-контейнер

docker run --rm -d -p 80:80 testhl

Страница ping.html статическая, генерируется при сборке докер-образа, так что health check исправно определяется как “healthy”.

Меняем health check чтобы он выдавал ошибку, пересобираем докер-образ и запускаем докер-контейнер заново.

FROM nginx

RUN echo "ping" >> /usr/share/nginx/html/ping.html

HEALTHCHECK --interval=30s --timeout=10s --retries=5 --start-period=10s \

    CMD curl --fail http://localhost:80/ping2.html || exit 1

 

Страницы ping2.html в моем веб-сайте нет, так что health check через некоторое время определяется как unhealthy.

Автоматический перезапуск «проблемного» докер-контейнера

От одного понимания, что контейнер «испортился» пользы не много. Гораздо удобнее, было бы если докер мог бы перезапустить «проблемный» контейнер. К сожалению, «из коробки» такое работает только в режиме Docker Swarm, когда вы управляете кластером из докер-контейнеров. Более подробно про Swarm можно почитать https://docs.docker.com/engine/swarm/key-concepts/ 

Чтобы добиться такого же и для одного докер-контейнера нужно сделать следующее. 

1. Заменить exit 1 на kill 1 в инструкции HEALTHCHECK
2. Запускать докер-контейнер с опцией –restart always

Пример

1. Меняем Dockerfile следующим образом

FROM nginx

RUN echo "ping" >> /usr/share/nginx/html/ping.html

HEALTHCHECK --interval=30s --timeout=10s --retries=5 --start-period=10s \

    CMD curl --fail http://localhost:80/ping2.html || kill 1

    2. Собираем новый имидж

    3. Запускаем имидж вот такой командой.

        docker container run --restart always -d -p 80:80 testhl

Обратите внимание, мне пришлось убрать опцию “--rm” так как она конфликтует с “--restart”

Обратите внимание на значения в поле STATUS. Я его проверял в разные интервалы времени и видно, что контейнер некоторое время работал (статус был up 5  seconds, up 22 seconds) и затем был перезапущен (статус стал up 11 seconds).

Azure Static Web Apps - еще один способ бесплатного хостинга статического веб-сайта

В прошлой статье я рассказывал как можно использовать Azure Storage Account для хостинга статических веб-сайтов. А сейчас я хочу рассказать еще об одном сервисе Azure для подобных задач - Azure Static Web Apps.

На данный момент сервис находится в стадии Preview и его использование бесплатно. В рамках бесплатного использования Azure разрешает задеплоить до 10 сайтов, веб-приложений. Полагаю, что, когда сервис выйдет из preview эта квота такой и останется.

Кстати, если тексту с картинками вы предпочитаете видео, то вот мой обзор Azure Static Web Apps на YouTube

Azure Free Account

Как обычно, хочу напомнить, что если сейчас у вас нет, аккаунта на Azure, то можно создать бесплатный. Вот здесь, в лекции "Step-by-step: Create Azure account and access to free resources" я рассказываю и показываю как его создать за 5 минут.

Деплоймент веб-сайта

Как и в случае с Storage Account, сервис Static Web Apps — это serverless решение и обладает всеми его преимуществами но при имеет и несколько существенных отличий от деплоймента при помощи Storage Account. Вот, наиболее важные, на мой взгляд

Во-первых, Static Web Apps (по крайней мере, на данный момент) требует привязки к аккаунту на GitHub и работает напрямую репозиториями на GitHub. Т. е. в отличие от Azure Storage Account файлы с локального компьютера с ним не задеплоишь

Во-вторых, сервис Static Web Apps позволяет в рамках этого же приложения. иметь и серверный код на основе Azure Functions.

И в-третьих, в сервисе ест ь возможность хранить конфигурационные параметры для веб-приложения (разного рода connection strings, secrets и пр.).

Перейдем непосредственно к тому, как работать с этим сервисом

1. В Azure Portal найдите сервис Static Web Apps. Проще всего это сделать через панель поиска.

2. Далее нажимаем на синюю кнопку Create static web app.

3. В форме Create Static Web App (Preview) нужно указать следующие поля

• Resource group. Можно выбрать любою или создать новую кликнув на ссылку "Create new". Я создал новую и назвал ее MyStaticWebAppRG.
• Static Web App details  - Name. Можно указать все что вам нравится.
• Static Web App details  - Region. Место на земном шаре, где бы вы хотели задеплоить ваше приложение. Сервис еще в стадии Preview и не все регионы доступны.

Bот как эта форма выглядит в моем случае

4. Далее надо нажать на кнопку Sign in with GitHub. Откроется форма логина на GitHub. После успешного логина на форме Create Static Web App (Preview) появятся дополнительные поля для выбора организации, репозитория и бранчи. 

На GitHub я создал репозиторий StaticWebapp и залил в него веб-сайт из прошлой статьи

Вот как эти поля выглядят в моем случае

5. На вкладке Build можно указать, где расположены файлы сайта и где код сервисов. У моего репозитория простая структура, нет сервисов на Azure Functions, а файлы веб-сайта расположены сразу в корне. И поэтому в моем случае эти поля пустые.

6. Следующий шаг – нажимаем кнопку Review + create. .Azure проверит параметры и если все ОК переведет вас на последнюю вкладку Review + create. Здесь в последний раз можно проверить параметры и нажимаем синюю кнопку Create. 

7. Создание Static Web App происходит довольно быстро. У меня заняло где-то 30 секунд. Далее нажимаем Go to recourse чтобы попасть на страницу веб-приложения в Azure 

7. На этом в общем-то и все, сайт задеплоен. По клику на Browse или линку в URL в отдельной вкладке браузера откроется index.html сайта.

Интересны изменения, которые произошли с GitHub репозиторием. Azure добавил в него GitHub Workflow файл. Теперь, с его помощью на любое изменение в master бранче моего репозитория сайт будет автоматически передеплоен.

Вторая интересная фишка, заключается в том, что на каждый Pull Request Azure Static Web App создаст отдельный деплоймент сайта, который можно найти на Serttings/Enviroments

Как только pull request будет смержен, Staging деплоймент так же удалится.

Как вы, может быть уже заметили, в интерфейсе Static Web Apps нет возможности указать стартовую страницу сайта (например, что-то отличное от дефолтного index.html) или страницу для обработки 404. Все это и многое другое можно сделать при помощи специального routes.json файла. Он должен быть расположен в коне веб-сайта. Более детально со спецификацией этого файла можно познакомиться в документации.

Что можно сделать еще

Сайту так же можно указать доменное имя в элементе Settings/Custom domains. 

Что интересно, в отличие от решения на Storage Account в Settings нет опции Azure CDN. Все потому, что Azure CDN автоматически используется для веб-приложений задеплоенных при помощи Azure Static Web Apps. И что особенно приятно, платить за нее не надо.

Итог

В этой статье мы познакомились со Azure Static Web Apps. Если сравнивать это решение с деплойментом статических веб-сайтов при помощи Azure Storage Account, то все упирается в наличие репозитория на GitHub. По крайней мере сейчас. Если ваш репозиторий на GitHub, то конечно, этот вариант «из коробки» более прост удобен для работы. В добавок он поддерживает  серверную функциональность на основе Azure Functinos.