В прошлой статье (часть 1) мы установили VSCode, настроили расширение Remote-SSH, для подключения к серверу. Таким образом подготовили компьютер к разработке собственного компонента Home Assistant.
Теперь нашей задачей является настройка Docker (docker-compose) на сервере. Для этого напишем конфигурационный файл docker-compose, чтобы поднять отдельный контейнер для разработки собственного компонента Home Assistant.
Нам потребуется:
- Сервер, с установленными docker и docker-compose;
- Желательно минимальное понимание docker и docker-compose.
Напомню, сервер, по-совместительству NAS, у меня самосборный. Дешёвая материнская плата со встроенным процессором (GIGABYTE GA-E3000N), да пара планок памяти.
Для создания Docker-контейнера для умного дома воспользуемся официальным образом. Для управления контейнерами используется docker-compose. Все настройки запускаемых контейнеров хранятся в файле docker-compose.yaml. Содержимое этого файла (GitHub):
version: "3"
services:
homeassistant:
image: homeassistant/home-assistant:latest
container_name: homeassistant
environment:
- TZ=
ports:
- "8123:8123"
volumes:
- ~/docker/homeassistant/etc:/config
restart: unless-stopped
hadev:
image: homeassistant/home-assistant:latest
container_name: hadev
environment:
- TZ=
ports:
- "9999:8123"
volumes:
- ~/docker/hadev/etc:/config
- ~/dev:/config/custom_components
restart: unless-stopped
Рассмотрев код, можно понять, что запускается два контейнера на основе одного образа homeassistant/home-assistant последней версии (:latest) доступной на Docker Hub. Они различаются названием, портом, который смотрит наружу (доступен с десктопа) и монтируемыми директориями.
Я сделал именно так, потому что у меня есть контейнер с основным Home Assistant, который не хочется постоянно перезапускать при разработке - у домашних будет много вопросов, зачем моргает свет, не доступны данные и прочее =) Т.е. первый, основной, контейнер с Home Assistant работает как ни в чём не бывало, его можно не трогать. Его файлы хранятся в директории (~/docker/homeassistant/etc).
Второй же контейнер имеет свою директорию для файлов (~/docker/hadev/etc), плюс дополнительную монтируемую директорию, в которой будет храниться код нашего самодельного компонента (~/dev) . Порты отличаются для того, чтобы контейнеры опять же могли работать одновременно: каждый из контейнеров будет доступен по на своём порте, например 192.168.88.10:8123 (основной контейнер) и 192.168.88.10:9999 (контейнер для разработки). В этом и заключается ключевоe преимущество docker: чистая хост-система, беcпроблемный запуск приложений разных версий и с различными требованиями к окружению. Если кому будет интересно - могу отдельно написать про установку и настройку docker. Переменную окружения TZ (чаcовой пояс) указываете, согласно своему местоположению: например, Europe/Moscow.
Параметр restart: unless-stopped говорит о том, что контейнер будет перезапускаться, пока не будет остановлен пользователем.
Для управления контейнерами можно использоватьdocker-compose CLI (интерфейс командной строки) или, например, Portainer (Рис. 1 и 2). Если кому-то будет интересно прочитать про настройку и запуск Portainer - пишите. Это несложно и весьма удобно. На видео из первой статьи цикла можно увидеть как используется Portainer.
Итак, контейнер настроен, можно запускать. На Рисунке 3 показан экран приветствия Home Assistant. Заполняем все поля (имя пользователя, логин, пароль и подтверждение пароля):
Обратим внимание, что порт, на который доступен HA из контейнера hadev - 9999, как и указано в конфигурационном файле docker-compose (docker-compose.yaml). В адресной строке вместо домена nas (случай для моей домашней сети), у вас, скорее всего, будет Ip-адрес вашего сервера, например 192.168.88.10.
Нажимаем "Создать учётную запись" и попадаем на следующий экран настроек. По большому счёту, можем не делать настройки на этом этапе, можно только придумать удобное название (чтобы сразу видеть, что это контейнер для разработки) для Home Assistant в этом контейнере (Рис. 4):
На следующем экране настроек, который служит для добавления интеграций, можем просто нажать "Далее", поскольку у контейнера есть только одно конкретное назначение - разработка своего первого простого компонента. Поэтому никакие дополнительные интеграции не требуются. Для удобства и простотРиы, всё-таки привожу этот этап на Рисунке 5:
Наконец, видим интерфейс только что созданного Home Assistant в отдельном контейнере hadev (Рис. 6):
Рассмотрим важный момент, касающийся прав доступа к файлам контейнера. В образе Home Assistant от разработчиков используется пользователь root. Соответственно, файлы которые создаёт Home Assistant в примонтированной директории имеют владельца root. VSCode же подключается к серверу ка пользователь user. Чтобы редактировать файлы, созданные Home Assistant мы изменим их владельца на user. На работоспособность контейнера это не повлияет, поскольку у пользователя root прав больше, чем у пользователя user: root может читать, записывать, исполнять файлов, у которых владелец user, но user не может изменять файлы, у которых владелец root. Для этого применим команду chown:
$ sudo chown –R user ~/docker/hadev ~/dev
Команда выполняется с правами суперпользователя, потому что user не может менять владельца у файлов и директорий, у которых владелец root. Абзацем выше про это написано подробнее. На Рисунке 7 показан скриншот, на котором видно владельца файлов HA до и после применения команды:
Для удалённого управления сервером по SSH я использую PuTTY. Если надо рассказать, как настроить и использовать PuTTY - пишите в комментариях. Это очень просто!
Подведём итоги: в этой заметке мы настроили, запустили и сконфигурировали контейнер hadev, предназначенный для разработки собственного компонента для системы умного дома Home Assistant. Ранее мы настроили среду разработки VSCode. В следующей статье мы уже напишем и проверим в работе наш первый самодельный компонент для HA.
Первая статья цикла: создание компонента Home Assistant. Просто и в картинках. Часть 1. Настройка VSCode и Remote-SSH
Если вам интересны следующие статьи по этой и смежным темам - подписывайтесь на мой канал!
Всего хорошего!
Для опытных пользователей
Как я представлял процесс разработки (с учётом того, что не получилось из первой статьи): создаём свой образ на базе homeassistant/home-assistant:latest добавив только пользователя user, который совпадает с пользователем, который авторизуется по SSH. В Docker-compose указываем директорию монтирования постоянных данных (persistent data) в соответствии с официальным руководством (https://www.home-assistant.io/docs/installation/docker/), а директорию с кодом разрабатываемого компонента монтируем в директорию /config/custom_components. Запускаем контейнер с HA для разработки используя свободный порт. Казалось бы - всё замечательно – в локальном VSCode правь код своего компонента на удалённом сервере, да смотри как он работает в отдельном контейнере HA для разработки компонента, не трогая свой умный дом.
Не получилось: VSCode авторизован с правами пользователя user, а контейнер Homeassistant работает с правами пользователя root. Это значит, что VSCode не будет иметь прав доступа на изменение конфигов HA, а это создаёт неудобства. Пробую на базе официального образа сделать свой, добавив пользователя user. Собираю образ, поднимаю контейнер. Тишина, новый контейнер не отвечает. Заглядываем в логи и видим следующее:
s6-mkdir: warning: unable to mkdir /var/run/s6: Permission denied
Таким образом, официально образа с запуском без привилегий root в обозримом будущем не будет. Что с этим делать – каждый, видимо, решает сам.
Пруфы:
