Какой формат конфигурации вы используете для компиляции и почему?
Пример (вам не нужно отвечать в качестве примера, но укажите настройку вашего каталога):
<Layout MyPersonalizedLayout>
prefix: /usr
exec_prefix: ${prefix}
bindir: ${prefix}/bin
sbindir: ${prefix}/sbin
libdir: ${prefix}/lib/application_name
libexecdir: ${prefix}/lib/application_name/modules
installbuilddir: ${prefix}/lib/application_name/build
mandir: ${prefix}/man
sysconfdir: /etc/application_name
includedir: ${prefix}/include/application_name
localstatedir: /var
runtimedir: ${localstatedir}/run/application_name
logfiledir: ${localstatedir}/log/application_name
</Layout>
Какие шаги вы обдумываете и какие ошибки выполняете перед перекомпиляцией или обновлением приложения?
Как вы отслеживаете все параметры конфигурации, которые вы в последний раз использовали для компиляции приложения?
Вы периодически делаете резервные копии из файлов конфигурации? Как часто ?
У вас есть особая / другая система обновления, чтобы вы могли поддерживать последнее работающее приложение, пока новое не будет готово к запуску?
Вы обычно тестируете компиляцию перед тем, как использовать ее на своем рабочем сервере, что вы должны учитывать перед этим?
Я не из тех, кто использует менеджеры установки, такие как yum, apt-get и другие, хотя я верю, что они отлично подходят для некоторых вещей, я предпочитаю иметь собственный контроль и возможности в приложениях, которыми мне нужно управлять, поэтому я бы хотелось бы знать, как все этому угрожают.
Если на этот вопрос будет больше трех ответов, я сделаю его вики-сообществом, а пока я прошу вас не объединять его
Я предпочитаю стандартизировать свои системные сборки, используя в основном сценарии и исходный код. Другие часто любят использовать инструменты управления конфигурацией и создание собственных пакетов из исходников для собственного диспетчера пакетов своих дистрибутивов. Если вы правильно стандартизируете свою сборку, эти методы в основном дают одинаковые результаты, и это просто разные способы работы.
Я до сих пор использую системные пакеты и собственные утилиты для сборки системы. В RHEL Kickstart абсолютно необходим для начальной сборки. Для обычных пользовательских утилит я обычно использую пакеты по умолчанию. Я компилирую только из исходников для роли основного сервера. Например: база данных, веб-сервер, прокси-сервер, балансировщик нагрузки и т. Д.
A1: Я предпочитаю следовать Стандарт иерархии файловой системы как только возможно.
A2: Это сложная тема. Если для обновления требуются обновленные библиотеки, эти библиотеки могут потребоваться и для другого программного обеспечения. Все основные требования для роли сборки я стараюсь компилировать по исходникам. Библиотеки, которые я часто использую для разных сборок и перекомпилирую любое программное обеспечение, которое скомпилировано для них, поскольку я редко компилировал статически. Если ваши изменения протестированы и правильно подготовлены к производству, вы можете минимизировать большинство рисков.
A3: Параметры конфигурации обычно указываются в сборке, когда они применяются ко всем серверам. В случае уникальной конфигурации, такой как конкретный VirtualHost в кластере веб-серверов, я буду поддерживать эти файлы конфигурации в Система контроля версий. После программной сборки сервера составляется контрольный список системы для проверки работоспособности и настройки любых параметров, которые лучше всего обрабатывать вручную. Вы также можете использовать систему управления конфигурацией, чтобы помочь здесь, но в зависимости от того, насколько хорошо ваша сборка стандартизирована, она может оказаться устаревшей.
A4: Да. Еженедельное резервное копирование всех уникальных файлов конфигурации.
A5: Система обновления - это в первую очередь логика, которая встроена в исходный сценарий и окружена сценарием-оболочкой. Это позволяет поддерживать обновления как часть сборки. Иногда более простой набор скриптов с использованием for петли в bash и трубопровод меняется через ssh. Идея состоит в том, чтобы все изменения, прежде всего, были должным образом стандартизированы.
A6: Все изменения тестируются и проверяются в тестовой среде перед запуском в производство. Все ожидаемые функции должны быть проверены на работоспособность.
Честно говоря, я мог бы написать книгу на эту тему, основываясь на вашем вопросе как таковом. По сути, вы спрашиваете, как правильно спроектировать, стандартизировать и поддерживать производственную среду. Мой ответ не является исчерпывающим, и существуют фундаментальные стандарты, которые должны применяться ко всем подходам. Вы, вероятно, выиграете от фундамента, заложенного в книге Практика системного и сетевого администрирования.
Я также написал другие ответы на эту тему. Смотрите также:
Управление приложением на нескольких серверах или PXE против cfEngine / Chef / Puppet
автоматизировать настройку сервера с помощью исходных сборок
Как вы отслеживаете все параметры конфигурации, которые вы в последний раз использовали для компиляции приложения?
Это зависит от того, как я создаю приложение. Если я создаю пакет Debian, я сохраню содержимое папки debian / в SVN.
Если я собираюсь установить без диспетчера пакетов, я создам сценарий или make-файл и сохраню его в SVN.
Вы периодически делаете резервные копии из файлов конфигурации?
Репозиторий SVN создается ежедневно.
Вы обычно тестируете компиляцию перед тем, как использовать ее на своем рабочем сервере, что вы должны учитывать перед этим?
Я почти всегда тестирую, но то, как я тестирую, зависит от приложения и того, для чего оно предназначено.
Я создаю SRPM для программного обеспечения, которое использую, а затем создаю резервные копии. Таким образом, у меня есть бесконечно воспроизводимый метод чистого построения любого кода, который я использую в любой имеющейся у меня системе.