Для отправки вы такой же самописный сервис используете, который сам ищет почтовые сервера в целевых доменах, общается с ними по smtp и управляет очередью повторов и т.п.?
Я к тому, что прикрутить imap к существующему postfix/exim надежнее и дешевле.
Как вариант, можно ещё просто складывать почту существующим почтовым сервером в mailbox/maildir форматах и просто разбирать файлы.
В таком раскладе не нужно реализовывать проверки spf, dkim и т.п. и в дальнейшем поддерживать этот код, решать проблемы безопасности.
Да, отбойники большинство сервисов шлют или в формате https://tools.ietf.org/html/rfc3464 или используя заголовки X-Failed-Recipients
Мы у себя рассматривали gitlab-ci как альтернативу jenkins для сборки .net проекта. На текущий момент как ci он нормально работает, но есть пару моментов:
— нельзя задать какое количество сборок, для которых нужно хранить артефакты, только время их хранения.
— сам файл конфигурации хранится в репозитории как результат сложно сделать схему, когда deploy должен быть предварительно одобрен (или в ручную запущен) ограниченным количеством ответственных лиц. Это можно попробовать сделать при помощи protected branch, но никто не мешает разработчику изменить файл в своём бранче и залить что угодно на прод.
В результате как cd его пока использовать сложно.
Если есть у кого-нибудь опыт использования в реалиях, которые я описал, прошу поделиться своим опытом.
Мы используем CEPH как block-storage, Gluster насколько я знаю это именно FileSystem, соответственно тут они не конкуренты.
Основными причинами, почему мы начали использовать Ceph были:
1. Quorum-based система выбора мастера, то есть при 2n+1 нодах split-brain мы не получаем.
2. Самолечение при сбое ( то есть если произошёл отказ ceph сам создаст умершие копии / выведет — введёт osd в кластер и всё само нормализуется через некоторое время)
3. Достаточно детальная документация и адекватная производительность (при условии следования документации — 2 разные сети, одна для виртуалок, вторая под ceph)
ИМХО: кластерная система хранения должна сама отрабатывать сбои, а не требовать вмешательства администратора, всё что я читал про Gluster говорит о том, что он так не умеет.
Расскажите как на CRS125 STP на всех портах сделать.
У меня получилось только если свитч переводить в решим роутера с бриджём, после чего ожидаемо упала производительность.
github.com/aspnet/Home/issues/1093 проблема с OSX и Linux
По поводу красношапки — она вообще в RC1 не поддерживается, о чём написано в информации по релизу
В случае если нужен shared datastore, можно поднять Metadata Server и использовать для этого Ceph FS.
1. CephFS не production-ready
2. При падении основного Metadata сервера, все клиенты, которые работают с ней встают в deadlock на уровне ядра, после этого помогает только перезагрузка, что не есть хорошо
У нас подобная схема не заработала стабильно ибо:
1. Как БД использовали Precona Cluster (master-master) и он не стартовал сам в случае одновременного отключения всех нод и их последующего запуска (отказ по питанию в стойке)
2. У вас в схеме нет shared system datastore / shared file datastore — соответственно не получится загружать файлы ядер или скрипты контекстуализации. Мы делали его сначала на NFS, потом на SAMBA и он перемещался между нодами вместе с OpenNebula тут тоже возникли проблемы из-за невозможности размонтировать rbd т.к. он используется.
3. Проблемы с обновлением OpenNebula т.к. нужно обновлять все ноды.
В итоге пришли к простой схеме:
1. Всё хранится в CEPH
2. OpenNebula + MySQL для неё работают на виртуалке, которая тоже хранится в CEPH
3. На нодах лежит файл для virsh, с описанием виртуалки OpenNebula
4. corosync занимается только тем, что запускает виртуалку с OpenNebula в virsh на одной из нод и следит, чтобы она всегда работала
Как бонус — меньше кластеризованных сервисов — меньше коллизий.
Я знаю про maildir, и dovecot'товские форматы, а также не использую формат mailbox практически нигде (где остался — требования стороннего ПО).
В данном случае я показывал, что как минимум бонус в том чтобы иметь отдельный ящик на каждую учётку, а не общую помойку на всех.
Посмотрите на Opennebula, возможно она вам подойдёт
Я к тому, что прикрутить imap к существующему postfix/exim надежнее и дешевле.
Как вариант, можно ещё просто складывать почту существующим почтовым сервером в mailbox/maildir форматах и просто разбирать файлы.
В таком раскладе не нужно реализовывать проверки spf, dkim и т.п. и в дальнейшем поддерживать этот код, решать проблемы безопасности.
Да, отбойники большинство сервисов шлют или в формате https://tools.ietf.org/html/rfc3464 или используя заголовки X-Failed-Recipients
— нельзя задать какое количество сборок, для которых нужно хранить артефакты, только время их хранения.
— сам файл конфигурации хранится в репозитории как результат сложно сделать схему, когда deploy должен быть предварительно одобрен (или в ручную запущен) ограниченным количеством ответственных лиц. Это можно попробовать сделать при помощи protected branch, но никто не мешает разработчику изменить файл в своём бранче и залить что угодно на прод.
В результате как cd его пока использовать сложно.
Если есть у кого-нибудь опыт использования в реалиях, которые я описал, прошу поделиться своим опытом.
Основными причинами, почему мы начали использовать Ceph были:
1. Quorum-based система выбора мастера, то есть при 2n+1 нодах split-brain мы не получаем.
2. Самолечение при сбое ( то есть если произошёл отказ ceph сам создаст умершие копии / выведет — введёт osd в кластер и всё само нормализуется через некоторое время)
3. Достаточно детальная документация и адекватная производительность (при условии следования документации — 2 разные сети, одна для виртуалок, вторая под ceph)
ИМХО: кластерная система хранения должна сама отрабатывать сбои, а не требовать вмешательства администратора, всё что я читал про Gluster говорит о том, что он так не умеет.
У меня получилось только если свитч переводить в решим роутера с бриджём, после чего ожидаемо упала производительность.
Кстати судя по #r именно он и используется для repl в студии
По поводу красношапки — она вообще в RC1 не поддерживается, о чём написано в информации по релизу
github.com/aspnet/Announcements/issues/69
1. CephFS не production-ready
2. При падении основного Metadata сервера, все клиенты, которые работают с ней встают в deadlock на уровне ядра, после этого помогает только перезагрузка, что не есть хорошо
1. Как БД использовали Precona Cluster (master-master) и он не стартовал сам в случае одновременного отключения всех нод и их последующего запуска (отказ по питанию в стойке)
2. У вас в схеме нет shared system datastore / shared file datastore — соответственно не получится загружать файлы ядер или скрипты контекстуализации. Мы делали его сначала на NFS, потом на SAMBA и он перемещался между нодами вместе с OpenNebula тут тоже возникли проблемы из-за невозможности размонтировать rbd т.к. он используется.
3. Проблемы с обновлением OpenNebula т.к. нужно обновлять все ноды.
В итоге пришли к простой схеме:
1. Всё хранится в CEPH
2. OpenNebula + MySQL для неё работают на виртуалке, которая тоже хранится в CEPH
3. На нодах лежит файл для virsh, с описанием виртуалки OpenNebula
4. corosync занимается только тем, что запускает виртуалку с OpenNebula в virsh на одной из нод и следит, чтобы она всегда работала
Как бонус — меньше кластеризованных сервисов — меньше коллизий.
В данном случае я показывал, что как минимум бонус в том чтобы иметь отдельный ящик на каждую учётку, а не общую помойку на всех.