Версионность конфигураций серверов на базе debian/ubuntu

Доброго времени суток, уважаемое сообщество.
Решил поделиться небольшой идеей, возможно кому-то будет интересно и полезно.

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

Немного о себе


Сам я web-программист, какое-то время сидел на ubuntu, сервера (VPS) практически все на debian. Большого опыта нет в администрировании серверов, в отличии от коллег и хостеров, но всегда очень привлекало знания в эту сторону. Я мог часами сидеть в консоли и решать те или иные задачи. Когда время заканчивалось, более опытные коллеги забирали игрушки задачи и рассказывали что я делаю не так. Но всегда было интересно, что именно они сделали сами и как происходят настройки более нагруженных проектов. Все проекты мы храним в bitbucket, используя систему управления версиями Mercurial. В один прекрасный день решили поддерживать актуальную версию проектов на серверах используя этот же инструмент и очень облегчили себе жизнь. Теперь поднять на сервере последние обновления можно в две команды:

hg pull && hg up

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

Идея на миллион


Получив новый сервер (VPS) на базе debain, я недолго думая создал репозитарий в папке с конфигурациями.

Новый сервер
Все команды производим из под root-пользователя.
Первым делом обновляем ПО на сервере:
apt-get update && apt-get upgrade

Ставим пакет Mercurial (появился в debian 6, но видел статьи установки и под debian 5):
apt-get install mercurial

Переходим в папку с конфигурациями:
cd /etc

Создаем репозитарий:
hg init

на что будет создана скрытая папка ".hg"
Немного расскажем о себе:
nano /etc/.hg/hgrc

Укажем данные:
[ui]
username = User <****@gmail.com>


Уже сейчас можно узнать о всех файлах запустив команду:
hg status

Меркуриал лишь покажет список файлов, которые для него еще новые.

Укажем что хотим добавить все новые файлы в следующий коммит:
hg add

И наконец зафиксируем первое состояние конфигураций:
hg commit -m 'first commit'

Теперь можно спокойно установить и настроить остальное ПО.

В любой момент можно проверить состояние конфигураций используя команду:
hg status

Что именно изменили в файлах можно узнать командой:
hg diff ./путь до файла

Откатить изменения можно командой:
hg revert ./путь до файла

Еще лучше будет ознакомиться со всеми командами:
hg help


Публикация

Когда поднимаем новый сервер или обновляем старый все время вспоминаешь:
  • Где твои памятки по настройке сервера
  • На каком проекте уже поднимал подобное ПО
  • Какой root-пароль от сервера (чтоб прочитать конфиги)

и список может быть большим.

Решил все залить в приватный репозитарий. Повторюсь, что мы используем bitbucket. Создаем на нем репозитарий, получаем путь, что то вроде:
https://bitbucket.org/username/etc-project-a

открываем заново конфигурацию нашего репозитария:
nano /etc/.hg/hgrc

И укажем ниже:
[paths]
default = https://bitbucket.org/username/etc-project-a

Выполним команду:
hg push

На что меркуриал спросит вас данные авторизации на сервере битбакет. Приятная новость, что можно настроить авторизацию по ssh-ключу.

Теперь наши конфигурации в сухом, прохладном месте. Вы всегда можете посмотреть как настроен тот или иной сервер и на примерах поднять новый. Для этого вам надо клонировать репозитарий на локальную машину, либо воспользоваться вполне удобным web-интерфейсом от битбакет.

Плюсы:
  • Храним версии конфигураций
  • Всегда можно откатить к стабильному варианту
  • Можно в одну команду определить что натворили без вас
  • Быстро можно узнать как настроен сервер не авторизовываясь на нем

Минусы:
  • Не забывать коммитнуть последние изменения

Хотел по крону добавить автоматические коммиты, но подумал, что лучше оставить такое простое решение. Возможно есть другие уже готовые решения о чем я бы с радостью ознакомился. Кто знает, может эта небольшая статья поможет вам придумать более простое и полезное решение о котором, я надеюсь, вы тоже с нами поделитесь.

Спасибо.
Поделиться публикацией
Комментарии 17
    +4
    etckeeper, не?
      +1
      Благодарю за наводку.
      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.

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

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


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

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

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

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

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

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

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

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


              Вы какими-то не теми хостерами пользуетесь. Нормальные хостеры предлагают git/svn/mercurial из коробки в составе базового набора ПО.
              0
              Ничего хорошего, будет больше сервисов, людей, система станет не управляемой.
              Потом появится вики с документацией по настройкам, потом на нее все забьют. И будут несколько носителей истины, их нельзя будет уволить, сложно заменить, да и не помнит человек всего.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                Самое читаемое