Pull to refresh

Comments 17

Благодарю за наводку.
etckeeper manages /etc be stored in a git, mercurial, bazaar, or darcs repository. By default each of the commands operates on /etc, but a different directory can be specified to operate on a clone of the /etc repository located elsewhere.

Ну..., возможно. Статья больше рассказать о таком решении. А данный продукт заточен на подобную работу, вернее «точит» тот же меркурал на подобную работу. Будет ли поддерживаться продукт дальше? И какие еще явные плюсы у него? Очень много вопросов и сомнений. Мне например намного удобнее максимально использовать один продукт, который я знаю и вполне нормально выполняет поставленные мной задачи. Человеку, который только хочет попробовать и еще пробует разные решения, возможно поможет сделать выбор
У него как минимум одно важное отличие — он запоминает права (владелец, доступ) файлов. Согласитесь, это критически важная информация для конфигурационных файлов в каталоге /etc
Отличная идея, мне кажется. Единственное что смущает — настройки в каком-то другом месте, так же подверженном атакам. Новая точка, куда зловред может приложить усилия. Или по ошибке можно расшарить все конфиги не тем, кому надо :) Менее секурно.
И ещё вопрос — что делать с конфигами вне /etc/ (например /opt/nginx/conf/*)?
За это и люблю Debian, что все конфиги лежат в одном месте:
/etc/nginx

Как вариант могу предложить:
mv /opt/nginx/conf /etc/nginx/conf
ln -s /etc/nginx/conf /opt/nginx/conf


Либо более подробнее ознакомиться с mercurial, возможно найдете для себя решение.
Почему хостеры не предлагают подобное ПО у себя на shared-хостингах остается загадкой.

Потому что сидящим на shared хостингах оно нафиг не нужно.

Чем не устраивают системы подобные puppet-у?
Потому что сидящим на shared хостингах оно нафиг не нужно.

Как минимум один человек есть. Ради меня конечно никто ничего поднимать не будет. У нас бывают клиенты, которые хотят именно обычный shared-хостинг и по ресурсам очень даже подходят именно обычные хостинги. VPS сейчас не такой дорогой, я это понимаю, но за собой тянет администрирование, которое клиент не готов оплачивать. В этот же список старые клиенты, которые у нас давно на обычных хостингах. И вот когда нужно заливать обновления по ftp, задаешь себе именно такие вопросы.

Чем не устраивают системы подобные puppet-у?

Благодарю. Очень интересно, буду изучать.

В целом хотелось простого решения, я сам люблю узнавать новое, но у коллег не всегда есть на такое время. И лучшим пока решением использовать те инструменты, которые использует вся компания. Это не значит, что мы не готовы к новым знаниям, просто необходимо самому изучить этот вопрос и рассказать остальным, что это хорошо и оправдает себя через какое то время. В моем подходе с меркуриал другим ничего и делать не надо было, сам время от времени смотрю кто что изменил и фиксирую. Пока не первый человек в компании и я лишь могу предложить какие-то фоновые инструменты, а не обязанности на весь коллектив, который уже работает по накатанной
А что делать со списком необходимых пакетов? Хранить рядом и ставить потом руками?
Вы про пакеты необходимые для вашего сайта? Тут скорее относится к вашему проекту, я бы все же хранил этот список вместе с исходниками сайта. Возможно какой-то обновляемый шелл-скрипт, который сам поднимет максимальное кол-во пакетов для вашего сайта, остальное ручками.

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


Вы какими-то не теми хостерами пользуетесь. Нормальные хостеры предлагают git/svn/mercurial из коробки в составе базового набора ПО.
Совершено верно, но нормальных хостеров еще найти надо. В наших степях это практически невозможно, зато запретить все могут:
2. 4. Для регистрации доменного имени, регистрант предоставляет заявку с достоверной и полной информацией в электронной или письменной форме согласно приложению к настоящим Правилам. Требованием к серверному оборудованию является его физическое место нахождения на территории Республики Казахстан. Все заявки регистрантов рассматриваются в порядке их поступления в регистратуру или регистратору.

Приказ Министра связи и информации Республики Казахстан от 7 сентября 2010 года № 220
Об утверждении Правил регистрации, пользования и распределения доменного пространства казахстанского сегмента сети Интернет


Солнце не всем одинаково светит.
Ничего хорошего, будет больше сервисов, людей, система станет не управляемой.
Потом появится вики с документацией по настройкам, потом на нее все забьют. И будут несколько носителей истины, их нельзя будет уволить, сложно заменить, да и не помнит человек всего.

Так делать нельзя.

Если хотите масштабируемый, управляемый, документируемый сервис, пакуйте в пакеты.
И конфигурации тоже.
Это не сложно, это нужно и обязательно.

PS более 10 лет системного администрирования
Можно об этом подробнее? Очень хочется почитать более опытных людей в этом направлении. Если будет оформлено в виде статьи, то будет здорово.

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

Система версий конфигураций в данном случаи не помогает держать актуальную версию, она лишь ведет лог и помогает вернуть рабочее состояние. Плюс можно дать доступ до истории изменений новичкам по которым они могу узнать все что происходило на сервере, конечно пока идут коммиты. Например:
2013-02-03 добавлен конфиги nginx — установили nginx
2013-03-03 добавлен новый хост и настроен с fpm — поднят хост с fpm

такие небольшие истории и помогут новичкам да и опытным людям ничего не забыть при настройке.

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

На счет лога изменений:
при пересборке пакета меняется версия и вносятся коментарии в changelog, + в пакете есть полный список зависимостей.

Чего в системе контроля за версиями в принципе нет, а для развертывания это ой как нужно. Также в этом варианте нет контроля с какими параметрами собран пакет (пакеты), в общем это увеличивает время развертывания сервиса на порядки, и каждый раз это будут новые танцы с бубном.

Если используется пакетирование, то все сводится к одной команде aptitude install пакет,
который подтягивает по зависимостям все что ему требуется, включая сам софт и настройки.
Если требуется полностью скопировать сервер, это также умещается в одну — две команды.

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

Если программист под *nix не может упаковать свою программу в пакет, он по всей видимости ошибся с выбором профессии.
И не надо говорить что для этого есть системные администраторы, это не их зона ответственности.

Никто лучше автора не знает в каком окружении должна работать программа.

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

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

Понимаем, что есть более профессиональные люди и компании, но они не могут охватить весь спрос и тем более берут весьма хорошие деньги, поэтому и остальным хватает хорошего куска «пирога». Мы тоже встречаем код от которого голова кругом, но есть у нас правило, что программист писал это все не со зла и сделал лучшим способом на тот момент. Возможно опыта не хватило или кто-то стоял над душой. Есть задача и от тебя требуется решения, если у тебя нет решений лишь в этом случаи даем задуматься, а там ли вы находитесь. Поэтому, с огромным извинениями, мы будем собирать велосипеды, пока не будет найден более правильный вариант тем или иным способом. Видели бы меня до хабра :)

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

Пакеты пока далеки от нас, единственный опыт сборка пакета из чужих исходников через утилиту. Но буду теперь копать в эту сторону. Благодарю за наводку.
Sign up to leave a comment.

Articles