소규모 호스팅 회사와 같은 다중 테넌트 환경과 관련이 있습니다.
Puppet (또는 이와 유사한)이 기본이지만 중대한 질량 변화를 처리하기에 적합한 기술입니까? 예를 들면 다음과 같습니다.
내 관심사는 보안과 침입에 관한 것입니다.
필자는 프로덕션에서 꼭두각시를 사용한 적이 없으며 테스트 랩에서 빠르게 놀았 기 때문에 이것을 잘못 사용해야하므로 잘못된 방법으로 생각할 수 있습니다!
답변:
Ansible (ansible.cc)을 사용해보십시오. 당신을위한 것일 수도 있습니다. 클라이언트에서 실행중인 에이전트가 없습니다. 매우 빠르게 성장하고 있습니다.
또 다른 좋은 대안은 Salt Stack입니다.
Ansible과 Salt는 이해하기 쉽고 분산 쉘과 같이 원하는 경우 명령 줄 도구로 사용할 수 있습니다.
네, 가능합니다. 그렇게해야할지 아닌지를 결정하는 것은 당신에게 달려 있습니다.
귀하의 질문에 관하여 :
1) 충분히 공정하다. 트래픽은 SSL 기반이므로 인증서 관리가 중요합니다. 또한 클라이언트에 의해 변경 될 수 있으므로 클라이언트가 자신의 ID와 관련하여 제공하는 '사실'을 신뢰하지 마십시오. 서버의 인증을 제공하기 위해 클라이언트의 SSL 인증서를 사용하려고합니다. hiera와 같은 것을 올바르게 사용하고 코드에서 실제 호스트 블록에 기반한 if-block을 피하는 것이 정직하다면 괜찮을 것입니다.
2) 패치를 유지한다고 가정하면 안됩니다. 올바르게 구성하면 클라이언트가 puppetmaster를 공격 할 수있는 작은 벡터 만 있습니다. 즉, 손상된 경우 효과가 크므로 잠그지 않도록주의하십시오.
3) 실제로 테스트 및 배포 문제입니다. 꼭두각시 코드가 있으면 파일을 망칠 수 없습니다. 정렬하는 데 약간의 시간이 걸리지 만 필요한 경우 기본 사항은 오래 걸리지 않습니다.
Puppet (또는 이와 유사한)이 기본이지만 중대한 질량 변화를 처리하기에 적합한 기술입니까?
예, 이런 식으로 사용할 수 있습니다. 이것을 사용하여 외부 클라이언트 시스템을 지원합니다.
서버가 구성을 보지 못하게하고 싶지 않습니다.
당신이 꼭두각시를 사용하는 경우, 당신은 안 다음 autosign 수 있습니다. 자동 서명을 사용하면 호스트가 자동으로 인증서를 요청할 수 있습니다. 구성 및 권한은 인증서의 CN에 직접 연결될 것입니다. 당신은 임의의 컴퓨터가 온라인으로 들어오는 것을 원치 않으며 그들이 실제로 모든 비밀 높은 보안 기능을 갖춘 시스템이라고 주장 할 수 없습니다.
정말 편집증이라면 꼭두각시 파일 서버 설정을 조정하여 일부 시스템 만 액세스 할 수있는 공유를 만들 수 있습니다. 파일 서버 액세스는 인증서를 기반으로합니다.
Puppet이 변경해서는 안되는 변경을하거나 서버에서 수행 한 수동 변경을 되돌리기를 원하지 않습니다.
로컬 변경을 허용하는 몇 가지 방법이 있습니다.
내가 자주 사용하는 방법은 다음과 같습니다. 기본적으로 목록을에 전달 source하면 퍼펫은 목록의 각 항목을 시도합니다. 따라서 로컬 파일을 가리 키도록 목록의 첫 번째 항목을 추가합니다.
file { '/etc/ssh/sshd_config':
ensure => present,
source => ["/etc/ssh/sshd_config_local",
"puppet:///modules/ssh/$ssh_config_file"],
...
}
다른 옵션은 심볼릭 링크를 사용하는 것입니다. 꼭두각시 버전을 사용하려는 경우 파일의 꼭두각시 버전으로 심볼릭 링크됩니다. 구성을 로컬로 유지하려면 심볼릭 링크를 만들지 않습니다.
file { '/etc/ssh/sshd_config_puppet':
ensure => present,
source => "puppet:///modules/ssh/$ssh_config_file",
...
}
다른 방법은 전체 파일을 변경하는 대신 augeas를 사용하여 줄 수준을 변경하는 것입니다. 변경 사항에 대해 매우 보수적입니다.
3> 꼭두각시 나 그와 같은 도구에는 자동 실행 취소가 없습니다. 실행 취소하려면 명시 적 코드를 작성해야합니다. 또한 꼭두각시의 환경 기능을 연구하고 새 코드를 테스트하는 테스트 랩 (VM 일 수 있음)을 보유하고 코드 검토를 사용할 수 있습니다.
/var/lib/chef기본적으로 변경되는 파일을 백업합니다 (예를 들어 리소스가 중요한 데이터 등의 백업을 남기지 않도록 구성된 경우 제외). doc포맷터를 사용하면 터미널 출력에 차이가 있습니다.
Puppet이 변경해서는 안되는 변경을하거나 서버에서 수행 한 수동 변경을 되돌리기를 원하지 않습니다.
퍼펫 파일 유형을 사용하여 작성된 구성 파일의 경우 다음을 설정하여 얻을 수 있습니다.
replace => false,
응용 프로그램을 서버에 처음 배포 할 때 일부 구성 파일을 생성하는 데 사용하지만 Puppet은 해당 구성 파일에 대한 편집 내용을 덮어 쓰지 않습니다.
그러나 이것은 꼭두각시 배포 스크립트라는 Puppet의 철학에 위배됩니다.
꼭두각시가 관리하는 파일에서 포함 된 꼭두각시가 관리하지 않는 별도의 관리자 편집 가능 파일을 갖는 것이 더 좋을 수 있습니다.
꼭두각시는 구성이 동일한 많은 서버에 가장 적합합니다. 예를 들어 회사에서 제공 한 공유 웹 서버의 모든 구성을 작성한 다음 해당 서버의 N 개의 인스턴스를 만듭니다. 그 후 모든 인스턴스에서 한 번에 변경을 수행하면 (예를 들어 모든 아파치 가상 호스트에 대해 AllowOverride를 변경해야 함을 알 수 있음) 정말 쉽습니다. 또한 모든 구성 정보를 한 곳에 저장하고이를 버전 관리하에 둘 수 있습니다. 완벽한 경우에는 손상된 호스트를 버리고 새 호스트로 교체하고 동일한 호스트 이름을 설정하고 필요한 인증서에 서명하여 하드웨어 오류를 처리 할 수 있습니다. 다른 모든 것은 Puppet에 의해 수행 될 수 있습니다.
그러나 두 호스트간에 구성 공유가 거의없는 경우 꼭두각시를 사용하면 구성을 수동으로 수행하는 것보다 생산성이 떨어질 수 있습니다. 또한 꼭두각시로 서버 구성의 절반을 관리하고 나머지 절반을 수동으로 관리하는 것은 의미가 없을 수 있습니다.
요약 : 관리하려는 호스트에 대해 균일하고 구조화 된 구성을 만들 수 있다면 Puppet이 가장 친한 친구이지만 각 서비스 (호스트, 가상 호스트, 데이터베이스)를 처리해야하는 경우 특히 Puppet은 추가되지 않습니다. 많은 가치.