Я использую метод копирования «дайджест» для всех обещаний копирования файлов, поскольку из-за того, как мы упаковываем и развертываем программное обеспечение, я не могу полагаться на mtime для критериев обновления файлов. По разным причинам я не использую подход клиент-сервер с центральным сервером конфигурации: вместо этого мы упаковываем и развертываем весь наш модуль конфигурации на каждом сервере, поэтому с точки зрения cf-engine источник и цель являются локальными на сервере. Бег.
Проблема, с которой я сталкиваюсь с этим подходом, заключается в том, что источник всегда будет обновлять цель, когда они отличаются - это то, что я хочу большинство времени, обычно потому, что источник был обновлен.
Однако, как и многие другие пользователи cfengine, мы запускаем рабочую среду, в которой иногда необходимо немедленно применять экстренные исправления - это означает, что у нас нет времени на перекомпоновку и развертывание модуля конфигурации, и исправление часто применяется путем развертывания tarball с конкретными изменениями. Конечно, это проблематично, если cf-engine появляется на 5 минут позже и отменяет изменения.
Мы хотели бы иметь возможность вносить небольшие инкрементные изменения в наши серверы без их отмены до следующего цикла развертывания, во время которого будут скопированы новые исходные файлы. Мы не рассматриваем случайное повреждение файлов или ошибочные изменения как достаточный риск, чтобы гарантировать, что cfengine постоянно откатывает развертывания к исходной копии - возможность развертывать аварийные исправления и оставлять их такими до следующего развертывания будет гораздо более ценной и полезной. .
Итак, после всего этого, мой вопрос таков: способен ли cf-engine определять, был ли это источник или цель, которые изменились, когда файлы различаются, и если да, то это их способ использовать метод копирования 'дайджест', но только если исходная сторона изменилась? Я также очень открыт для других идей и подходов, так как я все еще новичок во всей этой вещи управления конфигурацией.
Единственный способ узнать, был ли изменен источник или цель - использовать временную метку, что прекрасно умеет делать cfengine. Может, вы слишком много думаете об этом. В общем, я думаю, что либо вы позволяете cfengine управлять, либо делаете это вручную. В поисках золотого пути отсутствует дисциплина, и вы скоро сделаете ошибку. Я бы просто остановился на автоматизации.
Почему бы не поместить свою конфигурацию в систему контроля версий, обновив ее вместо перезаписи? Вместо копий файлов
hg pull -u
или
svn update
Инструмент управления версиями будет обрабатывать локальные изменения за вас, пока вы не получите возможность зафиксировать и отправить их обратно в центральный репозиторий.