Вопросы Теги

Возможные возобновляемые игры [например, with site.retry]?

Лучший способ выполнить такую ​​операцию - использовать команду find . У него много подходов; Я объясню два из них:

1) Относительные временные интервалы
В этом подходе вы можете точно указать начальные и конечные временные метки, а затем отфильтровать каждый файл, не измененный / доступный / измененный в этот период. Вы можете сделать это с помощью команды touch , сохранив файл с определенной меткой времени .
В следующем примере мы создаем два маркера ( timestamp_begin_file и timestamp_end_file ), для которых установлено значение 3 ЧАСА НАЗАД и 1 ЧАС НАЗАД . Затем мы используем newerct и ! параметры newerct для выбора файлов новее , затем 3 часа и не новее , затем 1 час (в этом примере мы просто посмотрим на изменить время). Все выбранные файлы будут скопированы в папку $ DESTINATION_PATH . 

touch -t $(date -d '3 HOUR AGO' +%Y%m%d%H%M.%S) timestamp_begin_file
touch -t $(date -d '1 HOUR AGO' +%Y%m%d%H%M.%S) timestamp_end_file
find "$FOLDER" -newerct timestamp_begin_file ! -newermt timestamp_end_file -exec cp {} $DESTINATION_PATH \;

2) Абсолютные интервалы времени
Вы можете использовать параметры newermt , чтобы отфильтровать ненужные файлы в определенный интервал дат. Здесь мы выбираем только файлы, измененные в течение дня 2007-06-07 : 

find . -type f -newermt 2007-06-07 ! -newermt 2007-06-08 -exec cp {} $DESTINATION_PATH \;

Как я уже сказал, существует множество других альтернатив (как предложил @Jaleks, -a / m / ctime , но из-за отсутствия информации мы не можем знать, какой корпус вам подходит).

Дополнительную информацию о фильтрации времени в find см. На странице руководства find

2
02.12.2016, 16:53
2 ответа

Ansible docs упоминают это, но только вскользь. «Некоторые ошибки могут помешать запуску обработчика, например, если хост становится недоступным». Нет никаких предложений, что делать в этом случае.

Упоминается - обработчики силы . Здесь есть некоторая путаница. Проблема # 4777 запрашивает параметр - force-handlers , который запускал бы все обработчики, независимо от того, были ли они уведомлены, чтобы разрешить восстановление в этой ситуации. Этот вопрос был закрыт с комментарием «теперь это реализовано». Рассказчик: не было реализовано. Я открыл новый выпуск , чтобы запросить такую ​​функцию.

К сожалению, я считаю, что этот комментарий заставил некоторых предложить - force-handlers в качестве решения этой проблемы на stackexchange или где-либо еще, когда это не так.

Полное решение изменило бы ansible для записи базы данных ожидающих обработчиков. (Обработчик будет записан немедленно, когда задача обнаружит, что изменение собирается быть внесено).

Если не считать этого, вы бы хотели избежать таких перерывов.Потому что вам нужно будет внимательно просмотреть оба обработчика и все задачи, обусловленные | измененным , и обязательно запустить их на повторных целевых объектах.

Мораль: может быть полезно использовать обработчики и избегать разбрызгивания | изменено в учебнике.

Менее элегантное, но столь же правильное решение могло бы включать изменение анзибля с возможностью принудительного запуска всех обработчиков. Или, возможно, рассматривать все непропущенные задачи как измененные. Если исходный запуск требовал перезапуска службы, вполне разумно запланировать второй запуск, который перезапускает службу. Недостатком является то, что при первоначальном запуске требовалось только перезапускать некоторые службы.

Вы также можете избежать прерывания воспроизведения, используя доступный «режим вытягивания». Или, если основная проблема заключается в том, что ansible запускается удаленно, вы можете запустить ansible на сервере на том же сайте, используя постоянный сеанс с screen / tmux .

0
27.01.2020, 22:44

В принципе, возобновляемые воспроизведения могут быть реализованы путем прикосновения к файлу отметок времени после перезапуска службы. Тогда условием для перезапуска службы является то, находится ли отметка времени перезапуска до времени изменения файла конфигурации. (На основе make ).

В случае файлов конфигурации это также возможно с использованием собственных доступных модулей: 

- name: Create Mysql configuration file
  template: src=my.cnf.j2 dest=/etc/my.cnf

- name: query  | mysql has been restarted with new config file
  template: src=my.cnf.j2 dest=/ansible-managed/mysql/restarted/my.cnf
  check_mode: yes
  register: mysql_restarted

- name: ensure | mysql has been restarted with new config file
  service: name=mysqld state=restarted
  when: mysql_restarted|changed    

- name: record | mysql has been restarted with new config file
  template: src=my.cnf.j2 dest=/ansible-managed/mysql/restarted/my.cnf

(или, например, 

- name: query  | mysql has been restarted with new config file
  copy: remote_src=yes src=/etc/my.cnf dest=/ansible-managed/mysql/restarted/my.cnf
  check_mode: yes
  register: mysql_restarted

, хотя remote_src будет только работать с отдельными файлами конфигурации, не каталоги)

0
27.01.2020, 22:44

Теги

Похожие вопросы