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

➖ Очевидные проблемы своего почтового сервера, которые нужно решать:

◽️Отказоустойчивость и доступность.
◽️Доверие к своему IP адресу, транспорт почты.
◽️Борьба со спамом.

➕ Плюсы своего почтового сервера:

🟢 Дёшево на длинном интервале.
🟢 Ящики могут быть очень большого объёма, платите только за свои диски.
🟢 Накручиваете любую функциональность и интеграции, никаких ограничений.

Я предлагаю убрать проблемы следующим образом. У многих провайдеров есть услуга в виде почты. Она может продаваться как отдельно, так и в составе каких-то других услуг, например, виртуального хостинга. Вот пример такой услуги. Показываю не в качестве рекламы, а просто как пример, как это может выглядеть со стороны хостера.

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

Настройка у провайдера может разниться. Я сталкивался с разными вариантами. Можно создать один почтовый ящик, куда будет сыпаться вся почта, адресованная на ящики домена. Это наиболее простой и удобный вариант. Один раз настроил и больше к провайдеру не обращаешься. Возможно придётся создать каждый почтовый ящик, куда вы хотите принимать почту.

⇨ Далее вы берёте свой почтовый сервер, добавляете туда пользователей. В настройках сервера указываете, что почту для пользователя нужно брать с внешнего сервера. Указываете учётные данные для доступа в ящик, где лежит почта. Также указываете в своём сервере, что отправку нужно делать через внешний релей провайдера.

Настройки серверов могут разниться. Я по такой схеме работал с Kerio и Postfix. В Kerio вообще всё просто. Он может забирать разом всю почту из общего ящика провайдера, куда валится почта для всего домена и раскладывать его по локальным ящикам пользователей на основе адреса получателя. Либо можно для каждого конкретного ящика указать ящик у провайдера, откуда он будет забирать почту. Ну и в качестве сервера для отправки указывается почтовый сервер провайдера.

У Postfix принцип такой же, но больше ручной работы. Забирать почту у провайдера можно через Fetchmail. Настраивать можно конфигами в консоли, либо с помощью RoundCube или PostfixAdmin. У них есть интеграция с Fetchmail. Ну а отправка настраивается на сервере через параметр relayhost. Более того, если вы хотите для разных доменов использовать разные сервера для отправки, то используете параметр transport_maps, которому можно указать список доменов и соответствие внешних smtp серверов, через которые будет отправка.

❗️Обращаю внимание на последний момент с transport_maps. Меня не раз спрашивали, как в рамках одного почтового сервера и нескольких доменов делать отправку так, чтобы не было видно, что они связаны между собой. С помощью внешних почтовых серверов и Postfix это легко настраивается. Арендуете разные услуги внешнего сервера SMTP и настраиваете на своём почтовом сервере отправку через них, используя разный сервер для каждого домена.

📌 Итак, что мы получаем на выходе:

1️⃣ Почта с сервера провайдера забирается по протоколу POP3 с удалением после получения. За место нам платить не надо. Это существенно уменьшает стоимость.
2️⃣Провайдер сам отправляет почту и организует доступность сервера. Даже если у нас что-то сломается или нам нужно будет заменить свой сервер, вся почта будет прилетать на сервер провайдера. А когда наш оживёт, заберёт почту. Нам не нужно решать вопросы доступности. Мы не теряем почту в случае своих аварий.
3️⃣ Локально мы можем сколько угодно хранить почту, не переживая за занимаемое место.

Существенный минус один – нужно в двух местах делать настройки: на своем сервере и провайдерском.

Схема 100% рабочая и эффективная. Я не раз использовал.

#mailserver

Как только поднимается тема контейнеров, неизменно начинается обсуждение производительности. Что туда можно засунуть, что нет и т.д. Особое внимание уделяют СУБД. Когда-то давно я увидел тесты работы форка MySQL - Percona:

⇨ Measuring Percona Server Docker CPU/network overhead

Там запускают СУБД в разных режимах. Приведу сразу результаты:

1️⃣ Железо - 7100 транзакций в секунду. Это максимум. 
2️⃣ БД в контейнере, подключение с хоста через замапленный tcp порт - 2200 транз/c. Самый слабый результат, так как подключение идет через проброс порта в iptables. 
3️⃣ БД в контейнере, который подключен напрямую в сеть хоста через net=host, подключение с хоста. Результат - те же самые 7100 транз/c.
4️⃣ БД в контейнере, подключение из другого контейнера. Контейнеры соединены между собой через docker bridge. Результат - 6300 транз/c.

Судя по этим тестам, сама по себе работа в контейнере никакого статистически значимого штрафа производительности не добавляет. Накладные расходы появляются там, где возникают дополнительные промежуточные звенья в виде NAT или Bridge, что в общем то логично. Запуск через docker run -p 8080:8080, добавляет новую прослойку в виде iptables и его проброса портов через DNAT. Надо ещё понимать, что эти же прослойки и вне контейнера возникнут, если у вас нагрузка, например, распределена между виртуальными машинами.

Казалось бы всё просто и понятно, можно не париться и не переживать по этому поводу. Минимизирует сетевые прослойки и получаем, как везде говорят, маленькие накладные расходы, которые можно игнорировать. Но не так давно смотрел другие тесты:

▶️ Насколько тормозит Docker? Тестируем сетевые режимы

Там автор провёл прикладные тесты таких же режимов работы, только для веб сервера Angie с разными статическими страницами (большая и маленькая). Результаты немного другие:

- Запуск на хосте - 100% производительности
- Docker c net=host - 67% и 79% от хоста в зависимости от страницы
- Docker с -p 8080:80 45% и 54%

Картина уже совсем другая. И даже с net=host разница с запуском на хосте значительная. При этом плавает от характера нагрузки. Чем больше rps, тем более заметна разница.

При этом нельзя выделить какую-то универсальную величину, на которую можно ссылаться при вычислении накладных расходов. Они очень сильно разнятся от характера нагрузки. В тестах с СУБД, насколько я понимаю, основная нагрузка была на CPU при выполнении сложных запросов. А в веб сервере отдавались несжатые данные маленькими объёмами, нагрузки на CPU было меньше, а вот системных вызовов в разы больше.

Так что с контейнерами не всё так однозначно, чтобы можно было сказать, что штраф незначительный, можно не учитывать. Где-то может быть значительный. Тот же прокси сервер для веб проектов имеет смысл запускать не в контейнере, а напрямую на хосте. Никаких особых проблем с деплоем и настройкой не будет, но сходу можно получить 20-30% прироста производительности на ровном месте.

И в завершении подытожу, что если с контейнерами хотите получить максимальную производительность, то точно нужно использовать сетевой режим host.

#docker #devops