Использование inotify для синхронизации удаленных серверов со статическим контентом
Ожидает приглашения
Собственно началось все с того, что на одном из проектов которые я сопровождаю потребовалось создание зеркал со статическим контентом в дата-центре на другом континенте(почему такая потребность возникла другой вопрос). В связи с тем, что канал может быть нестабильным от идей распределенных файловых систем пришлось отказаться. И так, что нам было нужно?
Поразмыслив я вспомнил о inotify. Поискав готовые решения работающие с данной подсистемой ядра натолкнулся на pirsyncd, который под мои задачи полностью подходил.
Как это выглядит в теории: пользователь нашего финского сервера что-то делает с файлами в нужной директории, наш наблюдающий за этой директорией pirsyncd видит, что там что-то изменилось с файлами и rsync`ом через ssh приводит директорию на удаленном сервере к тому же виду в котором она существует на основном. Таким образом мы и получаем зеркалирование.
Вроде все хорошо, но что-то меня смущало в этой стройной схеме. А смущало меня то, что бывает всякое и наш pirsyncd может упасть. Тут-то я и вспомнил о runit`е, супервизоре сервисов который я использую в некоторых проектах(о нем писали на Хабре).
Вот, теперь стройная схема у меня в голове появилась, сервис стартуется runit`ом, если он упадет, то runit его поднимет обратно, а когда он живой и здоровый он следит за нужной директорией и сливает её на удаленный сервер.
Дело за малым, настроить все это.
Я не стану повторять за статьями про runit как именно настраивать, если будут вопросы, то в комментариях могу привести свой пример.
- Файл залитый на сервер находящийся в Финляндии должен уйти на сервер находящийся в Австралии сам
- Файл может быть залит как по ftp, так и по sftp/scp, то есть не привязаться, скажем к хуку фтп-демона
- Все должно происходить само, без вмешательство в процесс зеркалирования живых людей
- Сделано должно было быть в течении нескольких часов
Поразмыслив я вспомнил о inotify. Поискав готовые решения работающие с данной подсистемой ядра натолкнулся на pirsyncd, который под мои задачи полностью подходил.
Как это выглядит в теории: пользователь нашего финского сервера что-то делает с файлами в нужной директории, наш наблюдающий за этой директорией pirsyncd видит, что там что-то изменилось с файлами и rsync`ом через ssh приводит директорию на удаленном сервере к тому же виду в котором она существует на основном. Таким образом мы и получаем зеркалирование.
Вроде все хорошо, но что-то меня смущало в этой стройной схеме. А смущало меня то, что бывает всякое и наш pirsyncd может упасть. Тут-то я и вспомнил о runit`е, супервизоре сервисов который я использую в некоторых проектах(о нем писали на Хабре).
Вот, теперь стройная схема у меня в голове появилась, сервис стартуется runit`ом, если он упадет, то runit его поднимет обратно, а когда он живой и здоровый он следит за нужной директорией и сливает её на удаленный сервер.
Дело за малым, настроить все это.
- Скачиваем pirsyncd с официального сайта
- Проверяем наличие у нас питона и python ctypes, а так же rsync`а
- Генерируем беспарольный ключик и настраиваем права на удаленной стороне
- Тестово запускаем без runit`а и смотрим все ли работает
- Если все работает, ставим runit и настраиваем его на запуск нашего демона
- Наслаждаемся результатом своей работы
Я не стану повторять за статьями про runit как именно настраивать, если будут вопросы, то в комментариях могу привести свой пример.