Ansible을 통한 업그레이드가 종종 "멱등성"으로 간주되는 이유는 무엇입니까?

Ansible을 통한 업그레이드가 종종 "멱등성"으로 간주되는 이유는 무엇입니까?

나는 멱등성 함수가 응용 프로그램을 본질적으로 변경하지 않고(예: 숫자에 0을 추가하거나 해당 숫자에 1을 곱하는 등) 여러 번 반환될 수 있는 결과를 반환한다는 것을 알고 있습니다.

some_package_manager upgrade X -y이러한 의미에서 Ansible + cron 스케줄링을 통해 수행되는 작업은 state=latest멱등성이 없습니다. 결과가 본질적으로 애플리케이션을 변경하기 때문입니다. 각각의 새로운 업그레이드에는 새로운 기능이 있습니다.

그렇다면 "멱등성 Ansible 애드혹 명령/플레이북"이라는 개념은 언제, 왜, 언제 등장했을까요?

답변1

"발기부전"은 구성 관리 시스템의 속성인 경우가 많으며 Ansible은 그 중 하나일 뿐입니다.인형또한 Ansible과 마찬가지로 자신을 멱등성으로 설명합니다. 둘 다 엄격한 멱등성을 깨는 방법을 제공하므로 "준멱등성"이라고 말하는 것이 더 정확합니다.

나는 귀하의 문제가 부분적으로 멱등성(idempotence)의 보다 공식적인 의미에 대한 오해에서 발생한다고 생각합니다. 이는 몇 번이나 적용해도 동일한 결과를 제공하는 연산입니다.

0을 더하거나 1을 곱하는 것은 모두 멱등성의 정의를 만족하지만 우리는 이를 멱등성이라고 부릅니다.사소하게멱등성. 이는 무작동(no-ops)이며 일반적으로 멱등성은 반드시 무작동이 아닙니다.

몇 가지 예는 멱등성에 대한 보다 일반적인 직관을 얻는 데 도움이 될 수 있습니다.

  • 숫자를 숫자로 나눕니다.
  • 그 자체에서 숫자를 뺍니다.
  • 3D 개체를 표면에 편평화: 일단 편평하게 만든 후에는 더 편평하게 만들어도 모양이 더 이상 변경되지 않습니다.
  • 불타는 통나무: 완전히 연소되면 더 많은 불꽃을 가하면 더 이상 타는 것을 방지할 수 있습니다.
  • 커피를 뜨거운 물에 녹이려면 숟가락을 사용하세요. 일단 커피가 녹으면 더 이상 저어주어도 커피가 "더 녹지" 않습니다.
  • 개에게 "앉아"라고 요청하기: 이 명령은 처음에는 작동하지만 이후의 "앉아" 명령은 작동하지 않습니다.
  • 한 컴퓨터에서 다른 컴퓨터로 구성 파일 복사: 첫 번째 복사 후 파일을 다시 복사하면 대상 파일이 더 이상 변경되지 않습니다.

마지막 두 예는 구성 관리 시스템의 맥락에서 멱등성이 의미하는 것과 가장 가깝습니다. 가장 간단한 방법은 파일을 복사하거나 명령을 실행하여 원격 컴퓨터를 원하는 상태로 만드는 것입니다. 리모컨이 해당 상태에 있으면 파일을 복사하거나 명령을 다시 실행해도 아무런 효과가 없습니다.

멱등성이 Ansible이나 Puppet과 같은 구성 관리 시스템의 바람직한 속성으로 장려되는 이유는 많은 수의 서버를 관리할 때 동일한 구성을 가능한 한 많은 서버가 갖는 것이 가장 편리하기 때문입니다. 일관성을 강화하려면 필요한 구성 파일을 복사하고 방화벽 등을 동일한 방식으로 설정합니다. 하지만 이 작업을 반복적으로 수행할 수 있다는 점은 좋은 일입니다. 대규모 서버 팜을 운영할 때 일부 유지 관리나 업그레이드로 인해 어느 부분이 약간 벗어난지 계산하는 데 시간을 낭비하고 싶지 않기 때문입니다. 모든 서버에 "선호하는 구성을 채택하세요"라고 한 번에 알릴 수 있기를 원할 뿐입니다.

그것은 마치 개들의 집을 관리하려고 할 때 개들이 모두 앉기를 원하는 것과 같습니다. 개 중 일부는 이미 앉아 있었지만 다른 개들은 서 있었습니다. "앉아" 명령을 내리는 것은 이미 앉아 있는 사람들에게는 영향을 미치지 않지만 전체 방을 원하는 통합 구성으로 가져옵니다.

관련 정보