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

Готовые цельные Сервисы для бизнеса и общества. Максимальная изоляция и переносимость /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. Идеология 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

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

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

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

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

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

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

Читать далее: команды agile scrum