Автоматизировать настройку сервера с помощью исходных сборок
У меня есть сервер CentOS5.4, для которого у меня есть "сценарий сборки". Сервер работает как веб-сервер, который запускает apache+PHP для нашего проприетарного приложения.
Сценарий сборки, в основном, запускает установку базовой ОС и библиотек, которые мне нужны. Затем я должен пойти и скопировать пользовательские двоичные файлы apache и PHP, созданные для нашей среды. Наконец, я копирую наш репозиторий исходного кода.
У меня есть пара проблем с этим, и хотел бы совет по улучшению:
1) Если я создаю новый сервер, я хочу, чтобы все было так же, как и другие серверы. Но во время установки на других серверах я сделал немедленное обновление yum. Если я сделаю это в настоящее время на новом сервере, все виды библиотек будут отличаться.
2) Копирование всего вручную - отстой. Я собираюсь создать сценарий оболочки, который будет rscync и scp весь соответствующий исходный код и файлы конфигурации, но я хочу посмотреть, есть ли лучший способ в первую очередь.
3) Было бы идеально создать образ дампа жесткого диска, а затем просто скопировать его прямо на новый сервер. НО, для нескольких серверов я использую программный рейд в зеркальном режиме. Кроме того, оборудование немного отличается. Имеет ли это значение? Будет ли конфигурация raid режима зеркала просто поднята и перестроена конфигурация raid на втором диске после того, как я вернусь из загрузки? Будет ли конфликтовать оборудование другого сервера с моей базовой установкой?
Надеюсь, кто-то выйдет из левого поля и скажет: "Нет, идиот, просто пользовательский сервер-клон enterprise 2k ++;) ". Я хотел бы этот продукт. Спасибо за ваши ответы заранее.
2 ответа
CentOS - операционная система корпоративного уровня. Обновления пакетов не увеличивают основную версию, часто переносят исправления обратно и хорошо проверены перед выпуском. Риск минимальный. Чтобы снизить риск, проверьте сами обновления и свое приложение на них, а затем запланируйте регулярные обновления в своей инфраструктуре.
Поместите свое приложение на файловый сервер и напишите сценарий сборки, чтобы развернуть приложение. Некоторые люди предпочитают использовать свой предпочтительный инструмент упаковки для развертывания внутренних пользовательских приложений, но это может быть так же просто, как тарбол или рекурсивный перенос.
Создание изображений - это то, что становится все менее распространенным. Когда он используется, он обычно применяется к рабочим станциям или к средам с более статичными стандартами сборки. Исторически, он использовался на крупных предприятиях, которые создавали много серверов, поскольку его было быстрее создавать из образа. Обычно я избегаю этого на серверах UNIX, но если время сборки стало необычно чувствительным, я бы начал с сравнения с другими методами.
Существует множество инструментов управления конфигурацией, которые вы также можете использовать для поддержания своих стандартов. Spacewalk является аналогом Open Source спутникового сервера RedHat.
Более подробно об установлении сборок и стандартов серверов я подробно рассказал в следующих статьях:
Управление приложением на нескольких серверах или PXE против cfEngine/Chef/Puppet
1) Пока вы выполняете регулярные обновления на всех своих машинах, это не будет проблемой. Я знаю, что вы упомянули настройку "машины". Здесь мы используем виртуализацию - я создал "базовый" контейнер и держу его выключенным - используя инструменты, предоставляемые Virtuozzo, я могу "клонировать" это изображение снова и снова. Когда мне нужно обновить этот клон, я запускаю его, запускаю обновления, затем выключаю. Хотя это прекрасно работает для всех новых контейнеров, мне все равно нужно выполнять обновления для всех остальных работающих контейнеров (хотя я мог бы просто сохранить тот же "устаревший" образ и реплицировать), чего я добился, имея нужную мне конфигурацию программного обеспечения (все приложения, код, двоичные файлы и т. д. развернуты и настроены) и раскрутка "новых серверов" совсем несложно
2) Думали ли вы о создании RPM из вашего исходного кода? Хотя написание настоящих spec-файлов было кошмаром, если вы просто запускаете PHP-код, на самом деле ничего не нужно "компилировать", это означает, что просто пишете spec-файл, который берет исходные файлы из RPM и помещает их в правильном месте в дополнение к возможному запуску нескольких скриптов установки для Apache/ вашего приложения. Это может помочь вам отследить, на каком сервере работает какая версия вашего кода, и предложить способ лучше поддерживать вашу инфраструктуру.
3) Я действительно не могу ответить на эту часть вашего вопроса.