Pull to refresh

Comments 19

Можно в двух словах как-то рассказать о этой системе комментариев? я правильно понял, что комментарии будут в твоей собственной базе? авторизация будет по openid/oauth соцсетей?

Да, комментарии в своей базе, логин либо через аккаунт в самом Commento (email/пароль), либо через Twitter/GitHub/GitLab/Google. Facebook не поддерживается.

Сама система, наверное, неплохая, но способ дистрибуции, мягко говоря, сомнителен. На тестовой машине ещё куда ни шло. А вот в продакшен такое выпускать страшновато. Я б, например, вообще не рекомендовал docker-compose в системди юнит. И коли мы используем системди юниты, то логично каждый компонент системы оформить как отдельный юнит (она, 2019-й год — самое время учить системди, во время расцвета докеров). И как бонус — системди даёт более гибкие средства для управления порядком старта сервисов, чем докер (коллега ведь хелсчеки не пишет...).


За упоминание commento — спасибо, это хороший бонус к кругозору.

Любопытно. А можете привести аргументы, чем systemd в данном случае лучше, чем Compose?


У нас есть опыт использования Docker Compose в продакшне, довольно положительный, нареканий именно к Compose практически нет.

В конкретном случае:


  1. все держится на том, что docker-compose запускается не в детачд режиме (-d), а как основной процесс. Если какой-то контейнер упадет — ключ --abort-on-container-exit завершает компоуз и системди видит, что все сдохло. Как минимум это неэффективно — перезапустится весь стек


  2. меня очень смущает блок с вольюмами. Как будто если вольюм уже существует — оно сломается.


  3. как минимум — необходимость тащить docker-compose и деплоить файл с описанием списка контейнеров. Предпочтительнее — использовать голый docker + можно автоматизацию на базе ansible


  4. depends_on не ждет готовности контейнера, а стартует зависимый сразу же. Я писал как сделать правильный запуск в комменте тут https://habr.com/ru/post/454552/#comment_20240656 Но это требует расстановки хелсчеков, версии 2.4 компоуз-файла. Ну, и выглядит как костыль. Системди намного гибче, тем более, если нужно построить зависимость от какой-нибудь уже существующей службы (типа NFS сервера).


  5. по умолчанию — докер создает для контейнеров отдельную сеть. Стоит ли оно того — решать в каждом конкретном случае. Но много кейсов, когда эта "типа изоляция" не нужна. И можно в хост сеть публиковать сразу.


Спасибо за ответ.


Как минимум это неэффективно — перезапустится весь стек

В данном случае это нестрашно. Да и вероятность падения невысокая.


меня очень смущает блок с вольюмами. Как будто если вольюм уже существует — оно сломается.

Тут не понял, что вы имеете в виду.


необходимость тащить docker-compose и деплоить файл

Ну, это уже скорее вопрос вкуса :-)


depends_on не ждет готовности контейнера, а стартует зависимый сразу же. Я писал как сделать правильный запуск в комменте

А вот за это спасибо, я был не в курсе, что они добавили (наконец-то) HEALTHCHECK. В моих скриптах это реализовано вручную, так что есть шанс, что я перепишу на их использование.

Тут не понял, что вы имеете в виду.

поясню проще. Блок ExecStartPre выполняется всегда до старта сервиса.
Нюансы


  1. если образов в локальном кэше докера нет — они будет скачаны при docker-compose up. Это может привести к излишне долгому старту. Решайте сами допустимо ли это. По идее доставка образа до целевой машины — отдельная задача от старта сервиса. Как побочный эффект — у Вас будет одна версия сервисов, у Вашего коллеги — другая
  2. Я имел в виду, что 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?

да. Умеет сам запрашивать. И хранит сертификаты в своем конфиге.


Разве он работает с Compose?

он не с компоузом работает, а с докером. Подключаете сокет демона, прописываете аннотациями (лейблами) параметры сервисов… и полетели!

Я в своё время пользовал Прокси контейнер с поддержкой Letsencrypt от человека по имени jwilder
Этот прокси можно сразу поднять на несколько доменов/контейнеров, лишь добавлением переменных в dcompose-Файле домена для контейнера и он автоматом будет подключён к прокси, с загрузкой и обновлением сертификата.

Да, он использует похожий подход. Я не стал заморачиваться с поддержкой нескольких доменов, потому что в данном случае это было неактуально. В чём jwilder молодец, так это что у него есть куча тестов для сгенерированной кофигурации, но у него и проект намного более универсальный.

Спасибо, сервер реально работает!

А планах есть добавить авторизацию через другие платформы - Telegram, Discord, Twitch к примеру?

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

Если вы про Commento, то в настоящее время пациент скорее мёртв, чем жив.

Я сейчас активно занимаюсь разработкой его форка под названием Comentario, и всем рекомендую переходить на него. В текущей версии Comentario 2.x он полностью совместим на уровне БД с Commento — не требуется никакой конвертации, лишь немного отличается конфигурация самого сервера.

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

Я именно Comentario и имею ввиду. Отлично, что работа продолжается.

Sign up to leave a comment.

Articles