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