Я собираю не свой проект (но всегда можно форкнуться) и с CGO_ENABLED=1 (это никак не победить пока нет sqlite3 на чистом go). В любом случае спасибо, может получится в своем форке что-то сделать...
что json-file, что local логи не сохраняет если использовать docker-compose, поскольку после выполнения docker-compose down удаляются все контейнеры (/var/lib/docker/containers)
К сожалению опции запуска типа docker-compose up --no-recreate -d не помогают =(
> Во-первых, docker-compose тут лишний
docker-compose решает важную задачу - разруливает зависимости запуска (сначала БД, затем сервисы использующие БД и используемые для перенаправления веб-запросов, затем nginx, зависящий (proxy_pass) от вторичных сервисов)
Настройка взаимных зависимостей отдельных systemd-сервисов - еще та задачка...
> Во-вторых, у вас уже есть salt, который прекрасно умеет оркестировать контейнеры.
а не могли бы Вы поделиться ссылкой на такую оркестровку docker-контейнеров с помощью saltstack?
> Касательно с докером - я даже не знаю. Что быстрее? Выкат? Разработка?
Все вместе - разработка + выкат + тестирование. Раньше неделями могло приезжать обновление. Но самое главное - это мое время, его уходило в разы больше. Сейчас от коммита до накатывания обновления - 6 минут.
С systemd-шными сервисами (включая deb-пакеты) уже пройденый этап - много времени занимает деплой. С docker'ом все гораздо быстрее стало.
Подробнее о проекте. Часть хостов на amd64 (которые имеют честный HDD), часть хостов на RaspberryPi (arm32v7 с industrial SD-картами), сборка под 2 архитектуры. Приватный docker-репозиторий. Для деплоя используется saltstack. В docker-compose прописаны теги образов, соответствующие архитектуре. Хосты преимущественно работают без интернета. Настроен всего 1 systemd-шный сервис - собственно запуск docker-compose. Есть четкая процедура деплоя (в конфиге saltstack), в рамках которой можно делать всякие вещи (типа перемонтирования разделов файловой системы, docker pull и пр.)
Насчет SD-карт. У меня уже было 2 отказа обычных SD-карт на устройствах, работающих в режиме 24/7 - мороз + логи съели ресурс блоков. После этого карты заменил на industrial, но гарантии их безотказности нет - ресурс по перезаписи все равно исчерпается когда-либо. В связи с этим я решил перенять опыт прошивок для всяких роутеров (типа OpenWRT), где root-файловая система монтируется в read-only.
Я предполагал, что на момент деплоя монтирую файловую систему в read-write, затем перемонтирую ее в read-only. Это позволит докеру установить все необходимое для запуска.
Есть еще ранее не упомянутый нюанс. Часть моих хостов работает на архитектуре arm32v7. Без выхода в интернет. А elasticsearch собирается только для архитектуры amd64. Да и прожорлив он. 1ГБ памяти одноплатника не хватает, если заюзать какую-нибудь кастомную сборку elastic =(
Отправку логов куда-то во внешний сервис тоже не получится - мои девайсы живут без интернета
Shoolcs, на самом деле пример в статье можно выводить не просто в браузер голым текстом, а например сделать обработчик onClick() при нажатию на кнопку, в котором сделать http-cgi запрос (например, fetch'ем https://m.habr.com/post/252941/ ), ответ сервера вывести в текстовое поле. По такому принципу строятся веб-морды роутеров - кнопки всякие, поля, и, как правило, http-cgi запросы
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Спасибо)