☰

재개 가능한 재생이 가능합니까(예: site.retry 사용)?

tag-icon • tag-icon ansible
재개 가능한 재생이 가능합니까(예: site.retry 사용)?

Ansible을 사용할 때 종종 "멱등성"이라는 속성이 사용됩니다. 역할을 두 번째로 적용하면 동일한 결과를 얻을 수 있습니다. 예를 들어 구성 파일에 동일한 줄의 두 번째 복사본을 추가하지 않습니다.

"복구 가능"이라고 부를 수 있는 또 다른 속성이 있습니다. 컨트롤러와 대상 사이에 네트워크 파티션이 발생하는 경우 파티션이 해결된 후 중단된 재생을 다시 실행할 수 있나요?

안시푸르힌트이 속성은 실패한 대상을 나열하고 재시도를 허용하여 구현됩니다.

그런데 실제 사례를 보면 이런 속성이 없는 것 같습니다. 스크립트가 올바르게 복구되지 않는 상황을 식별할 수 있는 방법을 제안하십시오.

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

- name: Start Mysql Service
  service: name=mysqld state=started enabled=yes

예를 들어, ansible-examples의 위 코드 조각은 "복구 가능" 속성을 구현하지 못합니다. 프로필이 생성된 후 "restart mysql" 핸들러가 실행되기 전에 재생이 중단되면 "restart mysql" 핸들러가 실행되지 않습니다.

답변1

원칙적으로 서비스 재시작 후 타임스탬프 파일을 터치하면 재개 가능한 재생이 가능합니다. 그러면 서비스를 다시 시작하기 위한 조건은 다시 시작 타임스탬프가 구성 파일의 수정 시간보다 이전인지 여부입니다. (에서 영감을 받다 make).

구성 파일의 경우 기본 ansible 모듈을 사용할 수도 있습니다.

- 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그럴 지라도오직디렉터리가 아닌 별도의 구성 파일을 사용하세요.)

답변2

앤서블 문서말하는하지만 그건 그렇고. "호스트에 연결할 수 없는 등 특정 오류로 인해 여전히 핸들러가 실행되지 않을 수 있습니다."

여기에 약간의 혼란이 있다고 언급합니다 --force-handlers. 질문4777 화--force-handlers이 상황에서 복구를 허용하기 위해 알림 여부에 관계없이 모든 핸들러를 실행하는 옵션을 요청합니다 . 질문은 "현재 구현됨" 주석으로 끝납니다. 내레이터: 구현되지 않았습니다. 하나 열었어요새로운 질문그런 기능을 요청합니다.

불행하게도 이 의견으로 인해 일부 사람들은 stackexchange나 다른 곳에서 이 문제를 해결하자고 제안했지만 --force-handlers사실은 그렇지 않았습니다.

완전한 해결책은 보류 중인 핸들러를 기록하도록 ansible의 데이터베이스를 수정하는 것입니다. (작업이 임박한 변경 사항을 감지하는 즉시 핸들러가 기록됩니다.)

그 외에도 그러한 방해를 피하고 싶을 것입니다. 처리기와 조건부 작업을 모두 다시 확인 |changed하고 재시도 대상에서 모든 작업을 실행해야 하기 때문입니다.

교훈: 핸들러를 사용하고 |changed스크립트 전체에 핸들러가 퍼지는 것을 피하는 것이 유용할 수 있습니다.

덜 우아하지만 똑같이 올바른 솔루션은 ansible을 수정하고 모든 핸들러를 강제로 실행하는 옵션을 제공하는 것입니다. 아니면 건너뛰지 않은 모든 작업을 변경된 것으로 처리할 수도 있습니다. 원래 실행에서 서비스를 다시 시작해야 하는 경우 서비스를 다시 시작하기 위해 두 번째 실행을 예약하는 것이 완전히 무리한 것은 아닙니다. 단점은 원래 실행 중이었던 경우에만 다시 시작하면 된다는 것입니다.일부제공하다.

재생 중단을 방지하기 위해 ansible "풀 모드"를 사용할 수도 있습니다. 또는 ansible이 원격으로 실행되기 때문에 주요 문제가 발생하는 경우 screen/를 사용하여 영구 세션을 사용하여 동일한 사이트의 서버에서 ansible을 실행할 수 있습니다 tmux.

관련 정보