Хмм… давайте выйдем из контекста какого-либо коммерческого продукта, из сферы хостинга приложений. Просто вы настраиваете linux сервер под себя. Вот статья просто про один такой прием настройки системы под себя. Вне зависимости от кейса — одна у вас система или их много, собираете вы box vagrant'a для разработчиков или билдите docker образ для хостинга приложения. Вот все) Не больше. Поэтому категоричность вашего комментария вводит в недоумение.
На примере CLI PHP в статье показан стандартный и беспроблемный подход по настройке. Это прием из другой плоскости системного администрирования, чем хостинг приложений. На месте PHP версий могли быть совсем другие бинарники, например, не относящиеся к вебу вообще.
Вы мой любимый тип клиентов) "Ничего знать не хочу, сделайте так чтобы чух-чух". Все-таки кроме хостинга приложений существует масса вариантов где используется Linux и если вы не хотите узнавать что-то новое, то другим может быть вполне полезным.
У update-alternatives есть возможность задать альтернативные директории для конфигов и симлинок. Через /etc/profile.d можно добавить уникальный кастомный путь в PATH для каждого пользователя. Для простоты использования update-alternatives --altdir.. --admindir.. можно завернуть в алиас для пользователя через тот же /etc/profile.d. Таким образом каждый пользователь сможет менять дефолтную версию PHP для себя. Скорее всего, при создании пользователя, директории нужно будет создавать отдельно каким-нибудь костылем :)
Заменить emacs на vim в качестве дефолтного редактора в системе (привет Ctrl+x+e и т.д.) тоже через контейнер?) Более того, речь в статье как сменить дефолтную %nameit% в системе. Вполне пригодится для корректной настройки системы при билде вашего Docker образа. Так сказать быть более system compliance.
Написал бы я как поднять несколько версий PHP-FPM и не задолбаться с сокетами, портами и секьюрити аспектом, вот бы мне было стыдно после вашего комментария :)
Вопрос в критичности ваших сервисов. Если мы говорим о каком-нибудь pet project'e то это вполне себе решение, для небольшого домашнего бизнеса тоже подходит. Если вы хотите SLA то есть как минимум Amazon SES.
Потому что работает :) Мой провайдер не режет. Другие, 465 и 587, даже не пробовал использовать. Я в статье привел конфиг msmtprc и там есть директива tls on.
Да, KitchenCI гоняет формулы и тесты в рамках одного сервера. Для автоматического тестирования мультисерверной инфраструктуры нужен другой инструмент для создания и прогона тестов. Сами тесты могут быть на том же Serverspec'e, например. То что вы описали, это вполне возможно хоть на том же Jenkins'e, правда не понятно на сколько удобно будет разбирать результаты.
Мы действительно говорим о разном уровне. Подход описанный в статье, позволяет быстрее разрабатывать отдельные формулы. Поднимать мультисерверную инфраструктуру и прогонять все тесты после каждого коммита может оказаться слишком дорого и избыточно.
Я со своим проектом до такой проблемы еще не дорос :) И, к сожалению, специализированного инструмента не знаю. Может кто еще подскажет)
Не вижу в вашем случае зачем нужно делать инкрементальные бэкапы. Dropbox идеально сам справляется с этой задачей. Сохраняете каждый день свой полный бэкап под одним и тем же именем, а Dropbox позаботится о версионности. Сейчас посмотрел у себя — у файл бэкапа доступно последние 30 версий, при этом файл занимает всего 1.5Гб.
Так как приложение ограничено только своей директорией, то можно не боятся, что в случае компрометации вашего приложения уйдет что-то еще кроме бэкапов.
и как
cagefs
поможет поменять дефолтную системную версию PHP или сменить системный редактор? Ну или поменять pager для листания манов?)Хмм… давайте выйдем из контекста какого-либо коммерческого продукта, из сферы хостинга приложений. Просто вы настраиваете linux сервер под себя. Вот статья просто про один такой прием настройки системы под себя. Вне зависимости от кейса — одна у вас система или их много, собираете вы box vagrant'a для разработчиков или билдите docker образ для хостинга приложения. Вот все) Не больше. Поэтому категоричность вашего комментария вводит в недоумение.
На примере CLI PHP в статье показан стандартный и беспроблемный подход по настройке. Это прием из другой плоскости системного администрирования, чем хостинг приложений. На месте PHP версий могли быть совсем другие бинарники, например, не относящиеся к вебу вообще.
Вы мой любимый тип клиентов) "Ничего знать не хочу, сделайте так чтобы чух-чух". Все-таки кроме хостинга приложений существует масса вариантов где используется Linux и если вы не хотите узнавать что-то новое, то другим может быть вполне полезным.
А если речь идет про CLI?
Почему трудно? Просто я не был уверен, что в моей системе от семерки ничего не развалится, поэтому поставил 5.6
Если вас все устраивает — вперед)
Я идею со скелетоном отверг для себя. Ну не нравится мне такое хранить в домашнем каталоге.
У
update-alternatives
есть возможность задать альтернативные директории для конфигов и симлинок. Через/etc/profile.d
можно добавить уникальный кастомный путь вPATH
для каждого пользователя. Для простоты использованияupdate-alternatives --altdir.. --admindir..
можно завернуть в алиас для пользователя через тот же/etc/profile.d
. Таким образом каждый пользователь сможет менять дефолтную версию PHP для себя. Скорее всего, при создании пользователя, директории нужно будет создавать отдельно каким-нибудь костылем :)Ну это то, что в голову с ходу приходит :)
Заменить emacs на vim в качестве дефолтного редактора в системе (привет Ctrl+x+e и т.д.) тоже через контейнер?) Более того, речь в статье как сменить дефолтную %nameit% в системе. Вполне пригодится для корректной настройки системы при билде вашего Docker образа. Так сказать быть более system compliance.
Написал бы я как поднять несколько версий PHP-FPM и
незадолбаться с сокетами, портами и секьюрити аспектом, вот бы мне было стыдно после вашего комментария :)Справедливости ради, надо сказать, что sensu есть и бесплатный (MIT). Доступны пакеты для разных платформ: https://sensuapp.org/downloads
Сравнение с enterprise версией можно почитать по ссылке https://sensuapp.org/features#compare
Использовал тот, что идет в комплекте с Plesk'ом:
Например на http://pastebin.com/. Уверен, что кроме меня найдутся и другие кому тоже интересно)
Вопрос в критичности ваших сервисов. Если мы говорим о каком-нибудь pet project'e то это вполне себе решение, для небольшого домашнего бизнеса тоже подходит. Если вы хотите SLA то есть как минимум Amazon SES.
О какие новости. Понаблюдаю за своим ящиком и логами. Спасибо за предупреждение.
Потому что работает :) Мой провайдер не режет. Другие, 465 и 587, даже не пробовал использовать. Я в статье привел конфиг
msmtprc
и там есть директиваtls on
.Мы действительно говорим о разном уровне. Подход описанный в статье, позволяет быстрее разрабатывать отдельные формулы. Поднимать мультисерверную инфраструктуру и прогонять все тесты после каждого коммита может оказаться слишком дорого и избыточно.
Я со своим проектом до такой проблемы еще не дорос :) И, к сожалению, специализированного инструмента не знаю. Может кто еще подскажет)
Так как приложение ограничено только своей директорией, то можно не боятся, что в случае компрометации вашего приложения уйдет что-то еще кроме бэкапов.
У нас в Plesk'e мы решили проблему хранения бэкапов на внешних источниках тем, что шифруем пароли и подписываем сам бэкап. И да, у нас есть расширение для хранения бэкапов в Dropbox'e:
devblog.plesk.com/2013/10/dropbox-backup-extension/
devblog.plesk.com/2014/07/dropbox-backup-2-0/
Если интересно, могу подготовить обзор на русском языке.