Comments 19
Можно в двух словах как-то рассказать о этой системе комментариев? я правильно понял, что комментарии будут в твоей собственной базе? авторизация будет по openid/oauth соцсетей?
Чем Remark42 не угодил?
Сама система, наверное, неплохая, но способ дистрибуции, мягко говоря, сомнителен. На тестовой машине ещё куда ни шло. А вот в продакшен такое выпускать страшновато. Я б, например, вообще не рекомендовал docker-compose в системди юнит. И коли мы используем системди юниты, то логично каждый компонент системы оформить как отдельный юнит (она, 2019-й год — самое время учить системди, во время расцвета докеров). И как бонус — системди даёт более гибкие средства для управления порядком старта сервисов, чем докер (коллега ведь хелсчеки не пишет...).
За упоминание commento — спасибо, это хороший бонус к кругозору.
Любопытно. А можете привести аргументы, чем systemd в данном случае лучше, чем Compose?
У нас есть опыт использования Docker Compose в продакшне, довольно положительный, нареканий именно к Compose практически нет.
В конкретном случае:
все держится на том, что docker-compose запускается не в детачд режиме (-d), а как основной процесс. Если какой-то контейнер упадет — ключ --abort-on-container-exit завершает компоуз и системди видит, что все сдохло. Как минимум это неэффективно — перезапустится весь стек
меня очень смущает блок с вольюмами. Как будто если вольюм уже существует — оно сломается.
как минимум — необходимость тащить docker-compose и деплоить файл с описанием списка контейнеров. Предпочтительнее — использовать голый docker + можно автоматизацию на базе ansible
depends_on не ждет готовности контейнера, а стартует зависимый сразу же. Я писал как сделать правильный запуск в комменте тут https://habr.com/ru/post/454552/#comment_20240656 Но это требует расстановки хелсчеков, версии 2.4 компоуз-файла. Ну, и выглядит как костыль. Системди намного гибче, тем более, если нужно построить зависимость от какой-нибудь уже существующей службы (типа NFS сервера).
по умолчанию — докер создает для контейнеров отдельную сеть. Стоит ли оно того — решать в каждом конкретном случае. Но много кейсов, когда эта "типа изоляция" не нужна. И можно в хост сеть публиковать сразу.
Спасибо за ответ.
Как минимум это неэффективно — перезапустится весь стек
В данном случае это нестрашно. Да и вероятность падения невысокая.
меня очень смущает блок с вольюмами. Как будто если вольюм уже существует — оно сломается.
Тут не понял, что вы имеете в виду.
необходимость тащить docker-compose и деплоить файл
Ну, это уже скорее вопрос вкуса :-)
depends_on не ждет готовности контейнера, а стартует зависимый сразу же. Я писал как сделать правильный запуск в комменте
А вот за это спасибо, я был не в курсе, что они добавили (наконец-то) HEALTHCHECK
. В моих скриптах это реализовано вручную, так что есть шанс, что я перепишу на их использование.
Тут не понял, что вы имеете в виду.
поясню проще. Блок ExecStartPre выполняется всегда до старта сервиса.
Нюансы
- если образов в локальном кэше докера нет — они будет скачаны при docker-compose up. Это может привести к излишне долгому старту. Решайте сами допустимо ли это. По идее доставка образа до целевой машины — отдельная задача от старта сервиса. Как побочный эффект — у Вас будет одна версия сервисов, у Вашего коллеги — другая
- Я имел в виду, что docker volume create НЕ МОЖЕТ создать тот же вольюм повторно. А, следовательно, команда (наверное, но это не точно) должна сфейлиться. Если нужно игнорировать код возврата, то пишем
blablabla || true
. Но, повторюсь, что это не точно, т.к. я не уверен, что docker volume create дает код возврата. И опять же хорошая идея — вольюмы нарезать в процессе установки софта (доставки), а не во время запуска.
Извините, вышенаписанное может быть похоже на буквоедство, можете это таковым и считать.
У Вас очень правильный подход — в целом, набор сервисов, описание того, что происходит. Вопрос только к самой реализации.
если образов в локальном кэше докера нет — они будет скачаны при docker-compose up. Это может привести к излишне долгому старту. Решайте сами допустимо ли это. По идее доставка образа до целевой машины — отдельная задача от старта сервиса. Как побочный эффект — у Вас будет одна версия сервисов, у Вашего коллеги — другая
С этим полностью согласен, поэтому в README у меня упоминается, что нужно сделать pull
и build
вручную.
Я имел в виду, что docker volume create НЕ МОЖЕТ создать тот же вольюм повторно.
Это верно, но у меня там и стоит "-", который как раз сообщает systemd, что код возврата неважен:
ExecStartPre=-/usr/bin/docker volume create certbot_etc_volume
Тогда единственное, что мне остается добавить — что указанный конфиг работает, только если все опубликовано на белом IP. Т.к. в противном случае Let's Encrypt не сможет подтвердить владение доменом (хотя и это можно обойти, если подтверждение по DNS и провайдер DNS умеет в API). Т.е. для эксперимента на отделенной от интернета машине — кейс не прокатит.
Nginx c cerbot можно спокойно заменить на Traefik и включить acme
Мы использовали Traefik, но с Docker Swarm. Разве он работает с Compose?
Он умеет сам запрашивать сертификаты с Let's Encrypt?
Этот прокси можно сразу поднять на несколько доменов/контейнеров, лишь добавлением переменных в dcompose-Файле домена для контейнера и он автоматом будет подключён к прокси, с загрузкой и обновлением сертификата.
Спасибо, сервер реально работает!
А планах есть добавить авторизацию через другие платформы - Telegram, Discord, Twitch к примеру?
Вопрос возник от того, что аудитория разная, гитлаб и гитхаб учетку имеют узкий круг IT специалистов, а гугл не у всех даже залогинен. Молодежь так вообще с мессенджеров не вылазит.
Если вы про Commento, то в настоящее время пациент скорее мёртв, чем жив.
Я сейчас активно занимаюсь разработкой его форка под названием Comentario, и всем рекомендую переходить на него. В текущей версии Comentario 2.x он полностью совместим на уровне БД с Commento — не требуется никакой конвертации, лишь немного отличается конфигурация самого сервера.
Comentario вскоре будет поддерживать авторизацию через многие другие провайдеры, версия 3.x будет значительно продвинутее.
Собственный сервер Commento с Docker Compose