요리사와의 지속적인 배포 및 오케스트레이션

Question

요리사를 활용하면서 여러 호스트에 내 애플리케이션 (웹/DB/애플리케이션 계층)을 배포하는 방법을 모색 중입니다. 내가 생각해 낸 것은 요리사 레시피를 사용하여 배포의 각 단계를 개별 노드 상태으로 표시하는 것입니다. 예를 들어 X 데몬 & 모니터링을 중지하는 단계가있는 경우 특정 X 데몬이 중지 될 것으로 예상하는 요리사 레시피로 작성 될 수 있습니다. 동일한 방식으로 이슈를 공유 위치에서 웹 루트로 이동하는 배포 단계는 해당 노드의 특정 상태를 나타내는 요리사 레시피로 참조 할 수도 있습니다 (지점 A에서 지점 B로 아티팩트가 복사 됨).

전체 배포 프로세스는 기본적으로이 세 가지 일을 여러 단계로 구성됩니다 :

1. 는 현재 배포 단계에 따라 노드의 실행 목록을 수정합니다.
2. 각 노드에서 chef-client 실행
3. 실패를 기록하고 실패한 노드에서 반복 실행하거나 단계를 건너 뛰면 배치를 계속할 수 있습니다.

질문 :

• 나쁜 연습 (지속적으로 노드 상태를 변경하기 위해 내 노드의 실행 목록을 수정)하는 방식으로 요리사를 사용 있나요? 그렇다면 왜?
• 이 모든 것을 조율하는 가장 좋은 방법은 무엇입니까? 거기에 CI 도구를 사용할 수는 있지만 chef-client의 출력을 캡처하고 특정 노드에서 실행되는 chef-client를 무시하거나 무시할 수있는 방법을 알아내는 데 어려움이 있습니다.

Answer 1

이것은 실제로 요리사가 가장 좋아하는 종류가 아닙니다. 요리사는 컨버전스 구성에서 탁월합니다. 새로운 코드를 배치하거나 구성 파일을 다시 작성하는 것과 같이 수렴 된 변경을 수행하는 부분을 처리하려면 Chef를 사용하고 다른 비트에는 절차 도구를 사용하십시오.

좌표를 조정하는 도구는 Run-Deck이 더 많은 서비스 -y를 원한다면 하나의 선택입니다. 커맨드 라인 툴을 Fabric 또는 Capistrano로 보길 원할 때. 개인적으로 나는 RunDeck과 Fabric을 모두 사용하여 최상의 결과를 얻습니다. 덜 완성 된 다른 옵션으로는 Chef Push Jobs, Mcollective, Saltstack 등이 있습니다.

Answer 2

꼭두각시와 요리사는 오케스트레이션 도구가 아니며 이러한 관점에서 매우 나쁜 역할을합니다. 그것들은 오케스트레이션이되도록 고안되지 않았으며 특정 이해 관계자들이 오 케스트 레이션에 대한 고려가되도록 오케스트레이션 정의의 경계를 넓히고 있지만 중요한 사실/요구 사항은 무시하고 있습니다. 불행히도, 대규모 환경의 통합을위한 하나의 진지한 해결책을 알지 못합니다 - 대부분의 도구는 특정 요구에 특정 적이며 일부는 실제로 아직 생산 준비가되지 않았습니다. 이 작업을 수행하기 위해 자체적 인 해결 방법을 고안해야했지만 그렇게하는 것이 우아하지 않았습니다.