Так, где инструкция по созданию локального registry и его настройка? И еще один нескромный вопрос, а вы не рассматриваете вариант с увеличением время жизни сборочных машин?
Моя инструкция не отличается оригинальность, а является переводом статьи с блога docker.com с дополнениями в виде картинок. Запуск образа binfmt можно добавить в автозагрузку. У вас в качестве источника кэша используется - registry. В каком-то смысле для большинства случаев это не имеет смысл. Например, у меня Docker-образ который состоит из трех частей: ОС Alpine, слой с Runtime .NET, и слой с компилированной программой. При первой сборке, Alpine и Runtime загрузятся из реестра. При второй сборке, слой с Alpine и Runtime будет взят уже с локального кэша. Слой с компиляцией программы это постоянно изменяемый слой при каждой сборке. Таким образом, нет никакой необходимости в подобной опции для взятия кэша. Кэш имеет смысл применять при большой вариации запуска одного и того же приложения в различных окружениях. Но на практике это сложно представить, потому что многие компании сейчас пытаются реализовать микросервисную архитектуру и не превращать Docker-контейнер в многофункционального динозавра. Если идет речь про локальный репозиторий образов, то тогда следовало бы дополнить пост инструкцией как его создать. Но если у вас есть рабочий кейс, то тогда хотелось бы его увидеть.
Что-то как то много букв и слишком сложно. У вас по факту идет сборка не под процессор от Apple, а для архитектуры aarch64. Кэширование слоев в Buildx отрабатывает автоматически. На мой взгляд моя инструкция проще и короче. Вы еще не добавили в текст команду для очистки кэша, а то так место быстро закончится при постоянных сборках:
Весь вопрос в сопряжение самого устройства. Как вариант можно взять устройство Tuya или Sonoff, например это. Перепрошить его на ESPHome, и подвязать к Home Assistant.
NameSilo.com. Лишнее не спрашивает, скан паспорта и подтверждение с места работы как это требуют отечественные регистраторы не требуется. Ежегодно не требует подтверждение что ты не превратился в пингвина. Принимает все платежные системы включая Bitcoin. По скидке можно сразу купить на 10 лет. Все мои домены на нем, уже несколько лет. Говорят что еще средне абузоустойчивый, но проверять нет желания. ИМХО, западный регистратор - это отношения, отечественный регистратор - это сношение с тобой.
Готовые решения будут существенно дороже самосборных и обладать один/двумя недостатками. 1) привязка передачи данных к своим облачным сервисам, как это реализуют "умные" розетки, светильники и т.д. 2) свой аппаратно/программный центр сбора данных. ИМХО, самое простое и универсальное решение это взять связку:
18650 Lithium Battery Shield V8
ESP-WROOM-32
температурный датчик BMx
В ESP-WROOM-32 загрузить прошивку ESPHome. Настроить соединение по BLE - BLE Client Sensor. На одноплатный компьютер установить Home Assistant нативно или в варианте Docker контейнера. Для отображения панели управления на экране, запускать браузер как в примере.
А если браузер с web-интерфейсом или почтовый клиент запускать в песочнице и пользователю не работать с правами администратора? Мне так кажется, как специалисту по ИБ, этот ваш сотрудник работал в ОС с правами Администратора. Для корректности, уточните пожалуйста набор привилегий учетной записи этого сотрудника, включая набор привилегий для его любимого почтового клиента через который произошло заражение.
Для этого вообще существует отдельная специальность - промышленный дизайн. Понятно дело, датчик спрятанный в глубине корпуса будет показывать уже температуру внутри корпуса, а не в комнате. Так всегда, напечатать на 3D принтере не проблема, хоть завтра, но вот сделать правильный и красивый корпус, тут необходимо весьма подумать.
Мне следовало сначала написать обобщенный пост, а потом уже техническую реализацию разных модулей. Исправлюсь, напишу что имелось в виду и какова конечная цель. Цель не в создание метеостанции, а в создание демо-проекта проверки технологий, проведение испытаний технологий в малых системах. Если задавать технический заголовок, то он будет очень длинным. Потому что необходимо охватить: Docker, работу с устройством Linux framebuffer, брокер сообщений RabbitMQ и AvaloniaUI. А с Docker проблем нет, он просто работает, и про него нечего писать. Единственный момент, в контейнер передается напрямую устройства /dev/fbX и другие устройства GPIO. Может быть, на этом следовало бы заострить внимание. Потому что подобный подход решает многие проблемы с безопасностью, которые в Windows Embedded решаются еще теми петлями. На Linux все получается более лаконично и просто. Но сравнение с Windows Embedded это уже другая тема.
Можно запускать систему на eMMC. На Banana Pi M64 напаяно 8 Гб, вполне достаточно. eMMC не использовал по двум причинам: 1) лишний раз не тратить ресурсы микросхемы; 2) понизить технические характеристики для явного обнаружения узких мест. На некоторых платах, таких как Cubieboard и Cubietruck размещен разъем SATA. Cubietruck с SATA показывает прирост скорости произвольного доступа по сравнению с microSD на Banana Pi M64 до 50%. Но нужно учитывать, что на Cubietruck установлен достаточно старый SoC. С m.2 продается неплохая плата ROCK PI 4C с поддержкой NVME до 2 Тб.
Прошу меня извинить, если быканул. Как раз таки вы написали "Если вы планируете выпуск (допустим) миллиона устройств". Вы указали на конкретную разработку, но не суть важна. Просто есть компания Toradex и ее успешный бизнес. Я очень много взял материала с их сайта. В своих системах они успешно используют Docker. И тут в комментариях начинается, вопросы про стрельбу из пушки по воробьям. Ребята, нужно понимать что мир на МК не заканчивается. Это не разработка метеостанции, это проверка технологий для использования на подобных малых одноплатных компьютерах, в тех сферах где Arduino/STM32 не будет использоваться в качестве основной системы. Да признаю, это нужно было четко написать в самом начале. Материал по факту это наработка технологий и проверка рабочих гипотез, и все. Я просто видел много систем, где брали плату на STM32 и подключали к ноутбуку. Хотя на самом деле можно было прекрасно обойтись платой в стиле банана с подключенным монитором или LCD с емкостным экраном.
Ключевое слово "Если". Ни кто не планирует продавать метеостанцию на банане. И далее будет распознавание голоса и видео с с Home Assistant. В самом начале написано: "Пример метеостанции является демонстрацией встраиваемого решения работы с GPIO...". Это техническое демо, а не законченная система для продажи. И вывод прочитайте, все же: "Данная реализация проекта была проверкой работоспособности первоначальной идеи работы с GPIO из Docker-контейнеров и вывода полноценного UI на LCD ...". Блин, похоже никто не осилил статью, и до конца не смог дочитать.
Мой подход заключается в постепенном наращивание функциональности, и создания "кубиков" приложений для универсального одноплатного компьютера. Хочешь метеостанцию, воткни датчик BME280 и загрузи нужный Docker-контейнер. Хочешь умную колонку, воткни хорошую плату с ЦАП, и загрузи Docker-контейнер. Идея заключается в конструирование устройства. Где брокер-сообщений является внутренней универсальной шиной передачи данных. А Docker-контейнеры сервисами обслуживающие периферийные устройства. Похоже это нужно было вынести в самое начало поста)
Это не интересно. Получается что твоя система будет зависеть от соседей, а это ненадежно. А воздух между прочем там другой, соседский).
Так, где инструкция по созданию локального registry и его настройка? И еще один нескромный вопрос, а вы не рассматриваете вариант с увеличением время жизни сборочных машин?
Моя инструкция не отличается оригинальность, а является переводом статьи с блога docker.com с дополнениями в виде картинок. Запуск образа binfmt можно добавить в автозагрузку. У вас в качестве источника кэша используется - registry. В каком-то смысле для большинства случаев это не имеет смысл. Например, у меня Docker-образ который состоит из трех частей: ОС Alpine, слой с Runtime .NET, и слой с компилированной программой. При первой сборке, Alpine и Runtime загрузятся из реестра. При второй сборке, слой с Alpine и Runtime будет взят уже с локального кэша. Слой с компиляцией программы это постоянно изменяемый слой при каждой сборке. Таким образом, нет никакой необходимости в подобной опции для взятия кэша. Кэш имеет смысл применять при большой вариации запуска одного и того же приложения в различных окружениях. Но на практике это сложно представить, потому что многие компании сейчас пытаются реализовать микросервисную архитектуру и не превращать Docker-контейнер в многофункционального динозавра. Если идет речь про локальный репозиторий образов, то тогда следовало бы дополнить пост инструкцией как его создать. Но если у вас есть рабочий кейс, то тогда хотелось бы его увидеть.
Что-то как то много букв и слишком сложно. У вас по факту идет сборка не под процессор от Apple, а для архитектуры aarch64. Кэширование слоев в Buildx отрабатывает автоматически. На мой взгляд моя инструкция проще и короче. Вы еще не добавили в текст команду для очистки кэша, а то так место быстро закончится при постоянных сборках:
Зачетный проект! Но это будет температура у соседей, а не у тебя.
Весь вопрос в сопряжение самого устройства. Как вариант можно взять устройство Tuya или Sonoff, например это. Перепрошить его на ESPHome, и подвязать к Home Assistant.
Как раз таки верно, давление — 0.01 hPa ( < 10 cm). Температура — 0.01° C. Влажность – 3%.
NameSilo.com. Лишнее не спрашивает, скан паспорта и подтверждение с места работы как это требуют отечественные регистраторы не требуется. Ежегодно не требует подтверждение что ты не превратился в пингвина. Принимает все платежные системы включая Bitcoin. По скидке можно сразу купить на 10 лет. Все мои домены на нем, уже несколько лет. Говорят что еще средне абузоустойчивый, но проверять нет желания. ИМХО, западный регистратор - это отношения, отечественный регистратор - это сношение с тобой.
Готовые решения будут существенно дороже самосборных и обладать один/двумя недостатками. 1) привязка передачи данных к своим облачным сервисам, как это реализуют "умные" розетки, светильники и т.д. 2) свой аппаратно/программный центр сбора данных. ИМХО, самое простое и универсальное решение это взять связку:
18650 Lithium Battery Shield V8
ESP-WROOM-32
температурный датчик BMx
В ESP-WROOM-32 загрузить прошивку ESPHome. Настроить соединение по BLE - BLE Client Sensor. На одноплатный компьютер установить Home Assistant нативно или в варианте Docker контейнера. Для отображения панели управления на экране, запускать браузер как в примере.
Потому что точность датчика позволяет. Сотые доли по ощущениям определить сложно, но изменение температуры с шагом в 0.3 градуса уже чувствуется.
А если браузер с web-интерфейсом или почтовый клиент запускать в песочнице и пользователю не работать с правами администратора? Мне так кажется, как специалисту по ИБ, этот ваш сотрудник работал в ОС с правами Администратора. Для корректности, уточните пожалуйста набор привилегий учетной записи этого сотрудника, включая набор привилегий для его любимого почтового клиента через который произошло заражение.
Для этого вообще существует отдельная специальность - промышленный дизайн. Понятно дело, датчик спрятанный в глубине корпуса будет показывать уже температуру внутри корпуса, а не в комнате. Так всегда, напечатать на 3D принтере не проблема, хоть завтра, но вот сделать правильный и красивый корпус, тут необходимо весьма подумать.
В моем случае нет js и html. Буду смотреть какие есть графические библиотеки для Uno Platform.
Мне следовало сначала написать обобщенный пост, а потом уже техническую реализацию разных модулей. Исправлюсь, напишу что имелось в виду и какова конечная цель. Цель не в создание метеостанции, а в создание демо-проекта проверки технологий, проведение испытаний технологий в малых системах. Если задавать технический заголовок, то он будет очень длинным. Потому что необходимо охватить: Docker, работу с устройством Linux framebuffer, брокер сообщений RabbitMQ и AvaloniaUI. А с Docker проблем нет, он просто работает, и про него нечего писать. Единственный момент, в контейнер передается напрямую устройства /dev/fbX и другие устройства GPIO. Может быть, на этом следовало бы заострить внимание. Потому что подобный подход решает многие проблемы с безопасностью, которые в Windows Embedded решаются еще теми петлями. На Linux все получается более лаконично и просто. Но сравнение с Windows Embedded это уже другая тема.
Прикольный интерфейс, круглый циферблат можно добавить как скин.
Зачем, если есть Armbian и он вполне устраивает?
Можно запускать систему на eMMC. На Banana Pi M64 напаяно 8 Гб, вполне достаточно. eMMC не использовал по двум причинам: 1) лишний раз не тратить ресурсы микросхемы; 2) понизить технические характеристики для явного обнаружения узких мест. На некоторых платах, таких как Cubieboard и Cubietruck размещен разъем SATA. Cubietruck с SATA показывает прирост скорости произвольного доступа по сравнению с microSD на Banana Pi M64 до 50%. Но нужно учитывать, что на Cubietruck установлен достаточно старый SoC. С m.2 продается неплохая плата ROCK PI 4C с поддержкой NVME до 2 Тб.
Прошу меня извинить, если быканул. Как раз таки вы написали "Если вы планируете выпуск (допустим) миллиона устройств". Вы указали на конкретную разработку, но не суть важна. Просто есть компания Toradex и ее успешный бизнес. Я очень много взял материала с их сайта. В своих системах они успешно используют Docker. И тут в комментариях начинается, вопросы про стрельбу из пушки по воробьям. Ребята, нужно понимать что мир на МК не заканчивается. Это не разработка метеостанции, это проверка технологий для использования на подобных малых одноплатных компьютерах, в тех сферах где Arduino/STM32 не будет использоваться в качестве основной системы. Да признаю, это нужно было четко написать в самом начале. Материал по факту это наработка технологий и проверка рабочих гипотез, и все. Я просто видел много систем, где брали плату на STM32 и подключали к ноутбуку. Хотя на самом деле можно было прекрасно обойтись платой в стиле банана с подключенным монитором или LCD с емкостным экраном.
Ключевое слово "Если". Ни кто не планирует продавать метеостанцию на банане. И далее будет распознавание голоса и видео с с Home Assistant. В самом начале написано: "Пример метеостанции является демонстрацией встраиваемого решения работы с GPIO...". Это техническое демо, а не законченная система для продажи. И вывод прочитайте, все же: "Данная реализация проекта была проверкой работоспособности первоначальной идеи работы с GPIO из Docker-контейнеров и вывода полноценного UI на LCD ...". Блин, похоже никто не осилил статью, и до конца не смог дочитать.
Мой подход заключается в постепенном наращивание функциональности, и создания "кубиков" приложений для универсального одноплатного компьютера. Хочешь метеостанцию, воткни датчик BME280 и загрузи нужный Docker-контейнер. Хочешь умную колонку, воткни хорошую плату с ЦАП, и загрузи Docker-контейнер. Идея заключается в конструирование устройства. Где брокер-сообщений является внутренней универсальной шиной передачи данных. А Docker-контейнеры сервисами обслуживающие периферийные устройства. Похоже это нужно было вынести в самое начало поста)