DevOps_public.txt

© Copyright by Alexander B. Prokopyev (the AUTHOR), Kurgan, Russia, 2022. 
All rights including exclusive rights reserved by the AUTHOR ( a.prokopyev.resume at gmail.com )
The AUTHOR allows anyone to view, read and distribute this file ONLY IN ITS ORIGINAL STATE WITHOUT ANY MODIFICATIONS. 
Any changes to this file and the copyright notice are strongly prohibited.

SaaS - хороший выбор, если достаточно средств и если IT отдел перегружен другой профильной для организации работой.
Для экономии средств при наличии квалифицированных администраторов вариант IaaS может быть все же более привлекателен при большом количестве пользователей, если провайдер SaaS не предлагает хорошей скидки за объем приобретаемой услуги.
Самым лучшим современным антиспам софтом с моей точки зрения является Rspamd: https://rspamd.com 
Хорошее описание универсального HA для почты: https://www.mail-archive.com/users@sogo.nu/msg29929.html
Среди популярных почтовых серверов можно отметить следующие:
1) Полностью открытые и бесплатные: 
1.1) docker-mailserver: https://github.com/docker-mailserver/docker-mailserver-helm,  к сожалению пока нет поддержки Rspamd, но планируют добавить. Вероятно это самая популярная open-source сборка, около 10K звезд на Github: https://github.com/docker-mailserver/docker-mailserver
HA: https://github.com/docker-mailserver/docker-mailserver/discussions/2391
1.2) mailcow: https://github.com/mailcow/mailcow-dockerized, есть поддержка Rspamd и SOGo.
1.3) mailu: https://artifacthub.io/packages/helm/mailu/mailu, есть поддержка Rspamd.
2) Полностью открытая сборка с бесплатной редакцией: iRedMail. В платной редакции iRedMail предоставляются все исходники скриптов iRedMail, интегрирован с SOGo groupware. Образ контейнера у них к сожалению пока только в предварительной бета версии: https://techviewleo.com/how-to-run-iredmail-server-in-docker-containers/, Helm чарта пока тоже нет, но зато есть скрипты установки на разные OS, в т.ч. на OpenBSD (возможны разные аппаратные архитектуры). HA (High Availability): 
https://forum.iredmail.org/topic10311-high-availability-in-different-datacenters.html
https://forum.iredmail.org/topic14800-mail-server-high-availability.html
https://docs.iredmail.org/haproxy.keepalived.glusterfs.html
3) Закрытая сборка с бесплатной редакцией образа контейнера из open-source серверов (Haraka, Dovecot, Roundcube, https://poste.io/schema.svg):
poste.io: https://poste.io/open, хотя и есть бесплатная редакция, но даже для нее к сожалению нет открытых скриптов сборки, поддерживает Rspamd и есть Helm chart: https://artifacthub.io/packages/helm/truecharts/poste
4) Среди проприетарных я бы отметил почтовый сервер Axigen. Это полностью проприетарный почтовый сервер, отличается от большинства других тем, что есть бесплатная редакция для 5-и пользователей и наличием готовой поддержки HA в Kubernetes в четвертой версии, которая пока еще в бета статусе и релиз намечается на конец 2022 года, а также существуют провайдеры SaaS, кто предоставляет почтовые сервисы на базе этого же самого софта:
https://www.axigen.com/documentation/high-availability-general-architecture-p44433427
https://www.axigen.com/documentation/high-availability-cluster-deployment-with-drbd-p44433426
https://www.axigen.com/cloud-native-mail-server/
https://www.axigen.com/documentation/deploying-an-axigen-cluster-on-kubernetes-platforms-with-axihelm-p686227505
Вероятно, его можно использовать в качестве учебного пособия для организации HA почтовика в кластере K8S для сборок типа docker-mailserver или mailu.


Далее мое мнение относительно выбора между SaaS, PaaS, IaaS, On-premises (локальная инфра).

Если ваша полиси безопасности позволяет, то по остальным критериям почти всегда нужно стремиться найти возможность использовать сначала предпочтительно SaaS. Если не получится найти подходящий SaaS, то нужно попытаться найти PaaS, и только уже потом IaaS, если не получается найти даже PaaS для вашего требуемого уровня кастомизации. Т.е. нужно идти от простого (SaaS) к сложному (IaaS). Малые компании обычно выбирают типовые готовые SaaS решения, средние иногда могут позволить себе PaaS, крупные могут быть заинтересованы в IaaS. Это чем-то напоминает выбор между использованием готового коробочного софта (аналогия с SaaS) и разработкой своего кастом софта (аналогия с PaaS и IaaS).

Если компания сама не специализируется на предоставлении определенного вида сервиса типа SaaS или PaaS, то даже ее IT отделу лучше заняться более узкоспециализированными задачами из своей предметной области, чем пытаться поднимать подобные сервисы в своей инфре. Можно найти отличные готовые решения типа Yandex 360 или Google (Apps,Docs,Gmail,WorkSpace Business, etc.), Microsoft Office 365. Не удивлюсь, если у них таким занят целый отдел или несколько отделов для каждого сложного сервиса. Очень важным преимуществом IaaS является высокая надежность инфраструктуры в дата центрах уровня Tier III Tier IV с резервированием всех систем. Реализация такого уровня резервирования в исполнении On-Premises или невозможна, или будет стоить чрезвычайно дорого. PaaS и SaaS нередко базируется на высоконадежном IaaS какого-либо крупного провайдера.
При очень большом количестве пользователей в организации для экономии средств при наличии квалифицированных администраторов вариант IaaS все же может быть более привлекателен, если провайдер SaaS не предлагает хорошей скидки за объем похожей услуги, которую можно было бы приобрести вместо самостоятельной установки сервиса в IaaS.
Хорошие диаграммы сравнения различных XaaS (Anything-as-a-Service) таких как SaaS, PaaS, IaaS, и т.п.:
https://hsto.org/r/w1560/getpro/habr/upload_files/5e3/e94/1e1/5e3e941e1ee13b03b3ab0f5000b07079.png
https://www.ispsystem.ru/sites/all/themes/ispsystem//images/news/2018/10/xaas/xaas-rus.png
Пример открытого PaaS: https://www.itweek.ru/foss/article/detail.php?ID=164455
Интересная статья про сравнение и выбор SaaS, PaaS, IaaS: https://habr.com/ru/post/645753/

Если вы надеетесь с помощью только отказоустойчивой облачной IaaS добиться отказоустойчивости своих приложений, то HA только инфры недостаточно для отказоустойчивости самого приложения, например из-за возможных багов в приложении, падении его частей из-за всплесков высокой нагрузки, эксплойтов и т.п. Отказоустойчивость профессионально администрируемых SaaS, неявно для пользователя работающих нередко в гео распределенных IaaS, крупных провайдеров обычно максимальная по сравнению с другими вариантами, они используют все популярные методики по обеспечению High Availability.
Проще всего приобрести готовый SaaS уровня business у крупного облачного провайдера, где уже решены вопросы безопасности, HA в кластерах приложений, сохранности и приватности данных. Какой бы надежный не был облачный провайдер, всегда необходимо обеспечить возможность перехода к другому и хранение регулярной бэкап реплики своих данных, иначе из-за критического сбоя провайдера или его изменившейся политики в области блокировки неугодных пользователей можно прийти к очень большим убыткам из-за приостановки ваших сервисов и утери своих данных.

При прочих равных условиях, включая намного больше факторов (особенно в области безопасности и High Availability), чем обычно учитывает среднестатистический администратор, SaaS обычно экономичнее других вариантов (PaaS, IaaS, etc.) почти всегда и особенно для случаев достижения высокой степени доступности на уровне 99.999% времени, потому что даже, чтобы нанять только опытных безопасников и/или SRE, которые смогут защитить систему от зависаний из-за эксплойтов, от утечек данных (что нередко требует специального образования и оборудования в т.ч.) и т.п., стоит относительно дорого либо требует относительно много времени для освоения, что обычно недоступно обычным админам без предварительной подготовки. Кроме того одного человека явно недостаточно для качественного администрирования хотя бы даже только одного вида сервиса и обеспечения доступности такого сервиса, нужно как минимум двое для подмены, и то это на пределе их возможностей и надежности системы, т.е. лучше больше для взаимозаменяемости, а это очень дорого при высоких требованиях к квалификации персонала. Подписка SaaS может стоить дороже подписки IaaS со сравнимыми характеристиками доступных ресурсов, но если учесть еще и затраты на администрирование, то SaaS действительно обычно итого экономичнее при прочих равных условиях.

Еще раз повторю, что абсолютно необходима взаимозаменяемость провайдеров и наличие регулярной локальной реплики данных облачного сервиса, иначе вы - заложник того или иного провайдера и находитесь в состоянии Vendor Lock со всеми вытекающими последствиями, включая геополитические.

Примеры SaaS: для популярных CMS типа Wordpress, Typo3 и т.п. обычно можно найти SaaS или PaaS, удовлетворяющий большинству требований клиентов, заинтересованных в создании своего современного вебсайта. Для сайта визитки вполне достаточно SaaS, чьим наполнением справится копирайтер или в запущенных случаях эникей. Программисты занимаются программированием. Если программист занимается наполнением сайта, то это уже не программист, а офисный работник по набору текста, хорошо если он еще разбирается в PR и рекламе, что одновременно с программированием большая редкость и бессмысленность при узкой специализации кроме редких случаев разработки инструментов для рекламы и продвижения.

Пример IaaS: для сильно кастомизируемого сервиса почты можно использовать IRedMail OCI container для развертывания в IaaS.
Конечно, использование облачных сервисов возможно, только когда полиси безопасности компании разрешает использование облачных сервисов, но очень сомнительно, чтобы какая-то среднестатистическая компания могла самостоятельно обеспечить у себя защищенность данных от хакеров (не от спецслужб) выше, чем крупные облачные сервисы хотя бы из-за разницы в уровне квалификации их сотрудников.

Масштабирование (scaling).
Обычно проще (быстрее и предсказуемее) нарастить объемы виртуального сервера (вертикальное масштабирование) даже в локальной инфраструктуре "On premises". Если не хватает ресурсов на текущем гипервизоре, то можно мигрировать гостевую виртуальную машину на другой уже заранее подготовленный более мощный хост гипервизора (при наличии), чем пытаться оперативно проапгрейдить физический сервер. Еще проще масштабировать контейнеры, особенно с помощью автоматизированного оркестратора типа Kubernetes, когда появляется еще и возможность горизонтального масштабирования (увеличение количества) контейнеров.

Безопасность.
К сожалению, VM не является панацеей с точки зрения безопасности и абсолютно надежной изоляции кода гостевой системы от хоста, а значит и других гостевых машин. В поисковиках можно найти упоминания exploit-ов типа escape (to host) from VM. И уж тем более контейнеры не являются защитой от хакеров в плане изоляции микросервисов, но зато они прекрасно изолируют контейнеры, в которых нет злого умысла в коде приложений, защищают от ошибок программистов, мейнтейнеров пакетов софта и администраторов от непреднамеренной попытки софта или скриптов негативно повлиять на окружение (например, по ошибке удалить нужный файл системной библиотеки или избыточного потребления каких-либо ресурсов). Улучшить безопасность и изоляцию контейнеров можно за счет их запуска в персональных (для каждого контейнера свое ядро Linux) микровиртуалках Firecracker, которые также могут работать под управлением оркестратора типа Kubernetes как и обычные (на ядре хоста) контейнеры.

Бэкапы.
Бэкапить на ленты - хорошая практика, потому что каждый экземпляр ленты не зависит от какой-либо электроники, привязанной к ней, в отличии от HDD и ленты можно хранить в сейфах офлайн. Кроме того лента не такая хрупкая при падениях и ударах как HDD. Относительно небольшие объемы данных надежнее всего дублировать еще и на M-DISC (по описанию до 1000 лет хранения данных): https://en.wikipedia.org/wiki/M-DISC
Если еще не используется IaC, то историю конфигов можно хранить хотя бы инструментами типа etckeeper. Но самое простое - это использовать файловую систему с поддержкой создания снэпшотов состояний FS и реплик файловой системы на других хостах для бэкапов, наверно самой лучшей (самой надежной и самой удобной) такой файловой системой является ZFS. Иногда требуется посмотреть состояние файла, над которым работал сотрудник в прошлом, поэтому все работы сотрудников лучше хранить в VCS, например, GIT (если они занимают не слишком много места, как например работы видеомонтажеров), или хотя бы в регулярных автоматических снэпшотах FS типа ZFS.  Самый быстрый и простой вариант  (кроме данных баз данных) - это остановка софта и снятие снэпшота ZFS, состояние софта самой СУБД можно сохранять точно также. Для сохранности данных СУБД, где нельзя утерять ни одной транзакции, у нас обычно есть механизм Point in Time Recovery (в журналах WAL, накатываемых на полный бэкап базы), но и для некоторых баз данных (если утеря части данных после снэпшота допустима в отдельных случаях) снэпшоты данных базы данных тоже могут быть полезными, потому что откатиться к ним намного быстрее, чем восстанавливаться из бэкапа с последующим накатом архивных логов WAL. В любом случае перед установкой нового софта даже на компьютеры пользователей нужно стараться делать бэкапы файлов, на которые может повлиять обновление, или хотя бы их снэпшот и стараться, чтобы создавался бэкап или снэпшот достаточно быстро, например, с помощью zfs snapshot снимок создается почти мгновенно. И конечно нужно стремиться по возможности уходить от обычных персональных компьютеров у пользователей к тонким клиентам, тогда админить придется только сервера, что намного легче.
При использовании облачных сервисов в любом случае нужны автоматические регулярные бэкапы данных из облака в свою инфру, при этом нужно использовать безопасное рабочее место администратора и безопасный бэкап сервер с аппаратными криптоключами для аутентификации и многое другое из области безопасности. К правилу создания бэкапов 3-2-1 я бы добавил, что важно не только иметь два дополнительных отдельных носителя данных, но и подключать каждый из них только к своему дополнительному отдельному бэкап хосту, чтобы исключить разрушение файловой системы (особенно постепенное незаметное что случается для FS типа ext3/4, NTFS, FAT и т.п, которые защищены от незаметных потерь данных значительно слабее ZFS) от неисправного оборудования типа сбойного контроллера дисков или самих дисков, вирусов, троянов и т.п. С другой стороны сложные FS типа ZFS и XFS для сохранности своих структур данных  очень требовательны к качеству оперативной памяти. Т.е. для каждой копии нужно иметь отдельный компьютер для работы с этой копией, причем желательно хотя бы раз в год запускать на них memtest непрерывно на пару-тройку дней для проверки оперативки. Иначе в случае выхода из строя или повторяющихся небольших сбоев, например, RAM, можно полностью потерять файловую систему (особенно сложную типа ZFS, XFS и т.п.), подключенную к хосту. Вероятность выхода из строя RAM одновременно на двух бэкап хостах значительно меньше. Однажды я наблюдал даже частично неисправную относительно дорогую фирменную серверную ECC память, с которой хост на серверной плате Supermicro продолжал работать и постепенно медленно разрушал таблицы базы данных, пока СУБД не заметила отклонение в целостности своих структур данных. В случае использования зеркал ZFS можно держать хотя бы одну часть каждого vdev зеркала в офлайн состоянии как с точки зрения ZFS пула, так и физически (есть корзины с кнопками отключения выбранных дисков), и лишь изредка синхронизировать такие диски с общим пулом после отключения локальной сети (и тем более интернет), чтобы частично уменьшить вероятность воздействия удаленно управляемых троянов (особенно невидимых буткитов) на целостность и корректность бэкапов в целом. Также может быть полезна хорошая защита бэкап серверов по питанию, хотя бы подключение через скоростные отсечки от перенапряжения типа УЗМ51М, мощные фильтры помех типа Most EHV, гальваническую развязку через понижающий (и одновременно он же разделительный) трансформатор 220В->110В, чтобы в случае отгорания нуля и попадания в линии питания серверов повышенного напряжения (до 380В), на блок питания даже только кратковременно приходило все же не более 380В/2=190В, что легко и с большим запасом выдержит любой качественный  блок питания уровня Gold с входным диапазоном примерно от 100В до 280В. Бэкап сервера лучше подключать к локальной сети с гальванической развязкой через медиаконверторы по оптике.

Мониторинг.
В случае разбора инцидента удобнее смотреть на проблему из мониторинга с обеих сторон (пользовательской и админской) на момент времени возникновения этого инцидента.
Для мониторинга удобно применять Zabbix:
https://artifacthub.io/packages/helm/zabbix-community/zabbix