구성 관리 도구가 배포 도구로 사용하기에 적합합니까?

질문에 대한 나의 대답 의 뒷면 : DevOps가 어떻게 소프트웨어 에스크로 절차를 개선하도록 도울 수 있습니까? Tensibai는 다음과 같은 질문을했습니다.

꼭두각시 나 요리사 위에 Capistrano가 필요한 것은 무엇입니까?

내 답변은 Noah Gibbs의 기사 "우리는 Capistrano와 Chef가 모두 필요합니까?"에 대한 링크를 게시하는 것이 었습니다. . 개인적으로, 나는 여전히 다음에 가장 적합한 Noah의 견해에 동의합니다.

• Capistrano와 같은 전문 배포 도구를 사용하여 배포하십시오.
• 구성 관리를 위해 Chef와 같은 전문 구성 관리 도구를 사용하십시오.

각 도구 유형이 작업을 완료하는 데 사용하는 기본 접근 방식은 매우 다릅니다.

• 구성 관리 도구 -시스템의 원하는 상태를 생성하고 유지하는 데 관한 것이며 본질적으로 dem 등합니다. 구성 관리 도구의 예로는 Chef , Puppet , Ansible , PowerShell DSC , Salt Stack이 있습니다.

• 배포 도구 – 호스팅 환경에 소프트웨어 버전 을 제공하는 것과 관련하여 여러 시스템에서 여러 버전의 소프트웨어를 유지 관리하고 "현재"버전을 관리하는 기능을 제공하며 본질적으로 본질적입니다. 배포 도구의 예는 Capistrano , Octopus Deploy , Deployer 및 Command.io 입니다.

구성 관리 도구가 배포 도구를 수행 할 수 있다고 생각하며 변경 불가능한 인프라 의 경우 대상의 소프트웨어 버전을 유지 관리 할 필요가 없으므로 작업에 가장 적합한 도구입니다.

질문 : Chef, Ansible 및 Puppet과 같은 구성 관리 도구가 dem 등원 및 명령 모델을 모두 충족 할 수있을 정도로 성숙 되었습니까?

이러한 맥락에서 일반적인 조언을 즉시 적용 할 수 있어야합니다. 작업에 적합한 도구를 사용하십시오.

그러나 요즘에는 소프트웨어 툴 이 거의 관련 분야로 기능을 확장하고 실제로 여러 가지 이유로 툴셋 이 되는 거의 악의적 인 경향을 무시할 수는 없습니다 .

예를 들어 많은 파일 관리 도구에는 이미지보기 기능이 포함되고 많은 이미지 처리 도구에는 파일 관리 기능이 포함됩니다. 파일을 옮기거나 도구 중 하나를 사용하여 이미지를 볼 수도 있습니다.

이로 인해 주요 기능 / 기능이 다른 경우에도 소프트웨어 개발 프로세스의 전체 부분을 여러 도구로 덮거나 겹칠 수 있습니다.

정말 정확한 기능에 귀결 그래서 당신이 달성하고자하는 특정 프로세스를 얼마나 잘 하나의 도구 또는 다른 하나는 일을 당신의 맥락에서 . 주관성 / 선호도 / 편의가 포함되어 있습니다.

이 질문을 주로 의견 기반으로 만들기;)

구성 관리 도구는 시스템을 알려진 상태로 만드는 데 사용됩니다. 배포 도구는 새 프로그램 파일 및 프로그램 데이터를 시스템에 배포합니다. 하루가 끝나면 두 가지 유형의 도구는 다음과 같은 조합을 수행합니다.

• 시스템의 현재 상태를 확인하십시오.
• 시스템으로 파일을 전송하십시오.
• 영구 데이터 (예 : 구성 파일, 데이터베이스 데이터, 레지스트리 설정) 추가 또는 변경
• 프로그램을 시작하거나 다시 시작하십시오.

구성 관리 도구에는 시스템 상태를 지정하는 선언적 언어가 있습니다. 배포 도구에는 시스템에 필요한 작업을 지시하는 명령형 언어가 있습니다. DevOps 담당자는 두 가지를 모두 수행해야합니다.

배포 도구 Capistrano를 사용하면 웹 서버가 활성화되도록 시스템에 언어를 사용하는 것이 어색합니다. 웹 서버를 다시 시작하려면 명령을 실행하고 웹 서버가 작동 중인지 확인하기 위해 다른 명령을 실행해야합니다. 웹 서버를 알려진 상태로 만드는 것은 어려운 일입니다.

구성 관리 도구 Ansible을 사용하면 웹 서버를 다시 시작하는 것이 어색합니다. 이 언어를 사용하면 웹 서버에 "업"을 지시 할 수 있지만, 특별히 다시 시작하려면 상태를 "다시 시작"으로 설정해야합니다. 그러나 웹 서버가 다시 시작되었는지 확인하는 쉬운 방법은 없습니다. 이것은 일회성 작업을 가능하게하는 Ansible의 문제입니다.

일부 사람들은 하나의 도구로 두 가지 유형의 작업을 모두 수행하고 거친 가장자리에서 작업하는 것을 선호합니다. 다른 사람들은 거의 똑같은 일을하지만 거친 가장자리가없는 두 가지 도구를 선호합니다. 이 질문에 대답하기 위해 "적절 함"은 맛의 문제입니다. 이 답변은 이유를 설명합니다.

TL; DR : 그냥 사용 Ansbile, 그것은이다 모두 구성 및 배포 도구 :

몇 가지 유형의 배포가 있습니다.

• 응용 프로그램 기반 (파일, 아카이브 패키지)

• 컨테이너 기반 (VM, Habitat, LXC, Docker 포함)

• 기능 기반 (마이크로 서비스 / 람다 / 기능)

이 경우 서버의 응용 프로그램 업데이트에 대해서만 이야기한다고 가정합니다.

배포를 위해서는 두 가지 일이 발생해야합니다.

1. 올바른 파일 또는 패키지는 서버로 이동해야합니다.
2. 구성 및 서비스 상태를 변경해야합니다.

이제 (1)에 대해 여러 전략을 사용할 수 있습니다.

• 아티팩트 리포지토리 / 동기화
• 패키지 리포지토리 / 패키지 관리자
• 버전 관리 시스템 / 업데이트 + 컴파일 (선택 사항)
• 파일 전송 프로토콜 (scp, rsync, ftp)
• 배포 도구

(2)의 경우 다음을 사용할 수 있습니다.

• 구성 관리 도구
• 배포 도구

따라서 배포 도구는 한 번에 배포하는 방법이지만 항상 최선의 전략은 아닙니다. 배포에 이러한 방법을 조합하여 사용하려는 경우가 있습니다. 이미 서버에서 이미 패키지 관리자를 사용했을 가능성이 높습니다. 어쨌든 구성 도구를 실행할 가능성이 높습니다. 일부 구성 도구의 문제는 여러 서버간에 적절한 오케스트레이션 이었지만 이제 Chef 및 Puppet조차도 상당히 잘 수행 할 수 있습니다. Ansible은 항상 이것에 능숙했습니다.

에서 개인적인 경험 , 나는 모든 조합을 사용했지만, 현재 우리는 배포 및 구성 관리를위한 Ansible 동기화 및 VCS 및 파일 전송을위한 패키지 저장소에 대한 카피 스트라 노를 사용하지만, 카피 스트라 노에 문제가있다 그리고 우리는 그것을 멀리 이동하는 기획된다 배포, 유지 관리 및 구성 관리에 모두 Ansible을 통합하십시오.

응용 프로그램 배포에는 많은 하위 문제가 있으므로 찾기가 어렵습니다. 구성 관리 시스템은 수렴적이고 "원하는 시스템 상태"와 함께 작동하는 모델링 작업에 탁월합니다. 앱 배포와 관련하여 이는 컴퓨터에 비트 배포, 구성 파일 관리 및 시스템 서비스 설정과 같은 작업에 유용합니다. 가장 나쁜 점은 본질적으로 절차적인 것, 특히 데이터베이스 마이그레이션 및 서비스 다시 시작입니다. 나는 보통 수렴 논리를 Chef에 넣고 외부 절차 도구 (보통 내 경우에는 Fabric)를 사용하여 나머지 수 비트를 처리하고 실제 수렴을 시퀀싱합니다.

따라서 기본적으로 가장 적합한 부분에 두 가지를 모두 사용해야합니다.

소프트웨어 및 기존 서버 또는 Docker 컨테이너 내부에 코드를 배포하는 경우 대답은 비교적 간단합니다. 아니요, 둘 다 필요 하지는 않지만 다른 도구 나 유틸리티가 가치를 더하고 작업에 적합한 도구 인 경우 둘 다 원할 수 있습니다 그러나 서버와 운영 체제를 배포 할 때는 상황이 더 복잡해집니다.

DevOps 사고 방식의 부가 가치 중 하나는 인프라를 코드로 취급하고 고도로 탄력적 인 환경에서 가상 머신 또는 베어 메탈을 자주 배치 또는 파괴하는 것입니다. 구성 관리 시스템은 서버를 쉽게 네트워크 부팅하고 킥 스타트 할 수 없으며 배포 중이나 후에 또는 경우에 따라 라이센스 및 권한을 위해 리포지토리, 패키지 및 업데이트 / 패칭을 관리 할 수 ​​없습니다.

Amazon Web Services의 경우 API를 통해 대부분 편리하게 관리 할 수 ​​있지만 자체 데이터 센터를 관리해야하는 사용자에게는 이것이 옵션이 아닙니다. 이러한 이유로 Foreman 프로젝트 (및 브랜드를 변경 한 Red Hat )는 Katello 시나리오를 배치 할 때 Katello , Candlepin 및 Ansible, Foreman 또는 Puppet과 같은 구성 관리자 를 함께 번들로 제공해야한다는 것을 알게되었습니다 .

따라서 Ops 측의 집 측 Dev 측에서 소프트웨어 코드 배포를위한 구성 관리 도구를 사용하여 벗어날 수는 있지만 그 대답이 "아니요. 구성 관리 도구가 아닙니다. 배포 도구로 사용하기에 적합 "그렇게하면 휠을 심각하게 다시 발명해야하므로 실용적이지 않습니다. 대신 구성 관리 도구를 사용하여 다른 도구에서 배포를 시작해야합니다.