Развертывание

Готовые цельные Сервисы для бизнеса и общества. Максимальная изоляция и переносимость /dir/chroot/lxc/kvm/openvz/docker.
Создавать решения, а не инструменты.
Обновление через rsync или git т.п максимально бинарно.
ОС CentOS или другие при крайней необходимости.
Пример LAMP, SmtpPop3Imap4, ldapAuthWeb один сервис один подпродукт.
Сервис работает по IP, предосталяет услуги через http/rest/get/ или сеть(smtp/imap/ldap/etc) с выделенным ip или через файлы, максимально стандартными протоколами.
Сервис предоставляется с готовым конфигом достаточным для старта и 80% случаев использования.
Все пользовательские настройки сервиса сохраняются в универсальный конфиг вида(или схожий подход)

CFG_IMAP_DOMAIN=examle.com
CFG_NET_IF1_IP=192.168.1.1 Настройки прочих программ написанных в стиле pl7 должны иметь в конфиге префикс cfg_system_var= или cfg.system.val= либо cfg['system.val']=

Дополнение 1

1. Идеология DIRECTORY_AS_APP - DIRAPP - обычно это контейнеры или чруты или каталоги или квм в каталоге
Означает что ПО распространяется в виде директории(папки) и для его запуска достаточно запустить service из папки.
/имякаталога/service start|stop|destroy|check|status
То есть файл service это унифицированный интерфейс общения с APP.
Также договариваемся, что такие ПО обычно лежать в /app/ или /opt/ или /vm/
Даже простейшие сервисы должны быть в виде DIRasAPP и как минимум там один и только один git для простейших обновлений. 2. Что такое CarbonMarket(carbonappbiznessMarket) - магазин-storage готовых настроенных приложений для /app/. Единицей продажи и установки является product_name.profile. В профайле находится список приложений DAPP для скачивания, возможно один DAPP, имя файла установки/обновления и т.п. (возможно бранч и возможно версия, но не факт)
3. carbonchroot(pl5chroot) - один из видов контейнеров и набор обвязок, используемый для быстрой разработки и улучшенной тех.поддержки используемый в carbonsoft. Отличается отдельными разделами для /etc/ /var/, отдельным /cfg/config, файлом или демоном watchdog, набором тестов, фикcов, мониторов и angel.
4. Также существуют типизированные update ы, common_update carbon_update lxcupdate lxc_update my_updateupdate

Дополнение 2

Как разработка маленького сервиса, например proxy_sms.
По мотивам http://opencarbon.ru/участники:kolko:2017-10-30_write_services.md

Все файлы сервиса располагаются в одном git репозитории
Если git больше одного, то файлы не перемешиваем /opt/proxy_sms/repo1/.git /opt/proxy_sms/repo2/.git и должен быть файл update.sh или ./service update по примеру crab_update файл обновления должен тоже обновляться.
В этот же гит кладем дополнительные в тч сторонние файлы и чужие либы, которые не входят в пакеты используемой OS.
Рекомендуется создать файл install.sh, чтобы настроить окружение OS, установить пакеты, настроить крон. Крон и т.п. лучше делать симлинком в /etc/cron.d/cron_proxy_sms → /opt/proxy_sms/skelet/etc/cron_proxy_sms
Размещаются сервис в очевидном месте например /opt/proxy_sms или /app/proxy_sms, или, если это сайт, /var/www/wiki1 или если это виртуалка /vm/proxy_sms/
Не рекомендуется размещать в home или root
Создаем грамотные .gitignore для /opt/proxy_sms/tmp|var|etc
Прописываем README
Если система должна работать с несколькими серверами, то размещаем все на одном основном сервере в виде DirAsAPP, а на другие сервера в realtime копируем файлы по ssh и запускаем или просто выполняем команды по ssh. Либо полностью создаем вспомогательные виртуальные сервера. Например, crm чтобы получить отчет по git репам копирует файл crm_git_repo.sh на gitlab, выполняет его и потом по scp забирает отчет crm_git_repo.rep
Если у вас есть программа и данные можно сделать два git /var/www/wiki1/.git /var/www/wiki1/data/.git и правильный .gitignore
Также удобно делать два ориджин origin - на github.com и origin_carbon на gitlab.carbonsoft.ru и мерджить при разработке
TODO привести подробные примеры proxy_sms, wiki1, satellite_blacklist, asr_billing

Дополнение 3 уровни

Хост - это только возможности ос и железа, он максимально тупой, это просто голая ОС.
Нода - это набор утилит для инициализации сети, стореджа, ядра и гипервизоров, например /node/bin/node.(этот уровень может отсутствовать)
Base - это набор утилит для запуска, настройки и управления приложениями и/или виртуальными машинами. Например в pl5ctl - /app/asr_fiscal/service, или в carbon_cloud - /node/bin/vm, или в devops_crab - carbon_lxc
Cloud Visor - это набор утилит для централизованной оркестровки node,vm,конфигов,бекапов и специфичных облачных сервисов. Обычно это виртуальная машина с ключами ко всем нодам.

Дополнение 4 Авторизация

Если на предприятии, то Централизованная система авторизации OpenLdap с многогрупповостью, кэширование авторизации sss.
Если облачные сервисы, то oAuth2 с провайдером аутентификации. Провайдер желательно с дополнительной защитой при установке и проверке пароля например дайджест, чтоб в ssl не передавался в открытом виде.

Дополнение 5 веб интерфейс и cmd

Все должно быть утилитами удобно скриптоваться и отлаживаться из командной строки uixway и/или GitCtl style.
Демоны должны запускать отдельные утилиты, кроме редких случаев реальных проблем с производительностью.
Веб-интерфейс к системным вещам должен в конечном итоге запускать утилиты и быть к ним просто интерфейсом, кроме редких случаев когда утилит нет. Либо общая библиотека для веб-бекенда и утилит с вызовом одних и тех.же функций и возможностью отладки из консоли.

Дополнение 6 многоязычность

Всегда реализуется возможность добавления дополнительных языков стандартными средствами.

Дополнение 7 устаканилось

Стандартное взаимодействие это rest или просто get или файлы.

Максимальная живучесть вачдог, софтдог, ангелы, форки и тп

Возможность легкой миграции на другой хост

Возможность полного бекапа и восстановления, точки восстановления

Подсистема сбора и отображения всей информации о службах и нодах через snmp или carbon_monitoring

Возможность легкого включения дебага любой проги по единой схеме, стандартизация логлевелов и формата логов
Рассмотреть событийность и бродкаст события в тч сетевые ipc net единый монитор событий. NET-DBUS NET-RPC, http, https, XML-RPC, SoaP. Идея единой шины событий предприятия.

Не заниматься оптимизацией приложений и файлов в них, пусть будет много лишнего, centos minimal.

ВАЖНО Излишняя безопасность вредна!
ВАЖНО Излишняя технологичность и непривычность для пользователя вредны!
ВАЖНО НЕ пакетная система, а бинарная или rsync!

Вся кастомизация под клиента должна быть в отдельном каталоге и желательно хуками или хук с патчем его вызова.

Централизованное развертывание и обновления софта.
Древовидная структура служб предприятия с возможностью переноса.

Помощь админу, различные демоны для отслеживания состояния системы и логов, carbon_monitoring с отправкой и евентами в единую бд.
Kickstart
kexec+kdump
Максимально не трогаем хостовую ОС, от нее нам надо только ядро и может быть крон и может быть сеть
Откат на старые версии приложений и хоста
Конфиг файл должен в себе содержать комментарий к переменной, ее виджет, ее рендж. Как минимум в виде коммента.

Дополнение 6 к обсуждению идеи и todo

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

Возможность нормальной мягкой перезагрузки с полным прибиванием и умаунт всего, только инит оставляем и потом он все запускает с нуля, тк аппаратные шняги сильно тормозят по сути init 1; init3

В начале любого скрипта должна быть возможность его отключения и должен быть Include BASE или что то в этом роде для хуков и переменных переопределения

Разобраться и стандартизировать с uid,gid

Сервер должен быть доступен сразу после груба или даже при грубее ssh

Проблема LAMP и вложенности не решена.
Профили наборов приложений и их пересечения не стандартизованы.
Посмотреть много полезного у Майкрософт рхел и новел по ролям серверов и инфраструктуре предприятий.

В кртичных к безопасноcти и надежности проектах

То что изменяется нельзя исполнять, то что исполняется нельзя изменять. Рута делать красным.
High Available
Контрольная сумма приложений или исполняемых файлов.
При установке системы генерируется уникальный RSA ключ.
Ядро повышенной защищенности от осв, с настроенными cap, античрут и киллером rootkit.

мандатного управления доступом

списки контроля доступа

ролевую модель