'단일 서버 다중 관리자'에 대한 구성 관리

소규모 협회를 위해 인프라를 실행하는 서버를 설정했습니다. 지금까지 Ansible을 사용하여 구성을 관리하려고 시도했지만 큰 성공을 거두지 못했습니다. 아마도 우리는 잘못하고 있습니다.

원칙적으로이 서버는 사람들이 푸른 달에 한 번만 추가하거나 변경하는 경우가 많으므로 대부분 서버를 그대로 두는 것입니다. 따라서 시스템을 관리하지 않는 사람들은 개요를 잃어 버릴 수 있기 때문에 (세부 사항 만 기억하면 됨) 서버에서 구성되고 실행되는 모든 내용이 잘 문서화되고 명확해야합니다. 또한 시간이 지남에 따라이 서버를 관리 할 사람 그룹의 구성이 변경됩니다 (사람이 '위원회'를 떠나고 참여함에 따라).

새로운 설치를 시작하면서 무언가를 설정하고 싶을 때마다 역할을 추가했습니다 (nginx, phpfpm, postfix, firewall, sftp, munin, ..). 아마도 우리의 경험이 없기 때문에 구성이 약간의 시행 착오 과정이기 때문에 가능한 한 일련의 가능한 작업을 한 번에 정확히 입력 할 수 없었습니다. 즉, 실제로는 일반적으로 서버 에서 실행하려는 서비스를 먼저 구성한 다음 가능한 작업으로 변환합니다. 어디로 가는지 알 수 있습니다. 사람들은 작업을 테스트 한 것을 잊어 버리거나 물건을 부러 뜨릴 위험이 있거나 그렇게하는 것을 두려워합니다.

오늘날 우리는 가능한 구성이 실제로 서버에 구성된 것을 반영한다는 확신이 거의 없습니다.

현재 세 가지 주요 문제가 있습니다.

방해 할 위험없이 가능한 작업을 테스트하는 것은 어렵습니다 (읽기 : 우리에게는 좋은 방법이 없습니다).
먼저 원하는 구성을 파악한 다음이를 가능한 작업으로 변환하는 방법을 알아내는 추가 작업이 추가됩니다.
(이상적으로) 우리는 익숙 함과 일상을 쌓을 수있을만큼 자주 사용하지 않습니다.

여기서 중요한 고려 사항은 우리가 결국 무엇이든간에 초보자가 연습을하지 않고도 로프를 쉽게 배울 수 있다는 것입니다.

master"사물을 구성하고 수행 한 작업을 적어 두십시오"가 제공하지 못하는 몇 가지 보증 및 검사 (Ansible 파일을 일부와 병합하는 것과 비교할 수 있음)를 여전히 제공하는 실행 가능한 대안이 있습니까?

편집 : 우리는 /etc자식에 대한 커밋 을 고려했습니다 . 그런 식으로 비밀 (개인 키 등)을 보호 할 수있는 합리적인 방법이 있습니까? 그래도 서버 외부에서 구성 저장소를 계속 사용할 수 있습니까?

ansible configuration-management

— 주스트
소스

답변:

변경 사항을 확인하는 데 사용할 수있는 테스트 / 스테이징 VM을 시작하십시오. 먼저 수동으로 변경을 수행하는 현재의 방법은 절망적으로 실패하고 실패로 끝납니다. 귀하와 귀하의 팀은 CM을 올바르게 사용하기로 약속해야하며 그 중 일부는 테스트 시스템을 사용할 수 있습니다. 로컬 방랑 VM만으로도 충분합니다.

이는 새로운 변경 사항을 테스트하는 데 도움이 될뿐만 아니라 신입 사원 (또는 한동안 시스템을 사용하지 않은 고령 직원)이 귀사의 설정에 익숙해 지도록 테스트 베드 역할을합니다.

git에서 / etc /를 유지하는 것과 관련하여 : 아니오, 이것을하지 마십시오. 그 디렉토리는 ansible이 바꾸는 것의 작은 부분 일 뿐이며, git을 사용하면 사람들이 로컬로 변경하도록 권장 할 것입니다.

플레이 가능한 플레이 북을 git에 보관하십시오. 라이브 서버에 변경 가능한 변경 사항 만 적용 할 수 있도록 권한 제한을 고려하십시오. 다른 사람은 변경 사항이있는 끌어 오기 요청을 제출할 수 있으며, 필요한 경우 검토하고 마스터에 병합 할 수 있습니다.

— EEAA
소스

맞습니다. 이상적인 시나리오입니다. 나는 그것을 얻는다. 문제는, 우리는 회사가 아니며, 풀 타임으로 일하는 사람들이 없다는 것입니다. 아마도 나는 이것의 규모를 불충분하게 분명하게 만들었을 것이다. 모든 추가 부분 (예 : vagrantfile)은 전달해야 할 복잡성을 더하고 두 가지 구성 (즉, 자동화 자동화와 같은 것들을 조롱해야하는 하나의 테스트 시스템)을 실행해야한다. 단순성을 돕지 않습니다.

— Joost

글쎄, 당신은 당신의 문제를 해결하는 방법을 물었고 나는 대답했다. 위의 내용은 우리 회사에서 일하는 방식과 정확히 일치합니다. 예, 테스트에 필요한 서버 공간과 시간 측면에서 추가 비용이 발생하지만, 필요한 경우 몇 분 안에 서버를 다시 구축 할 수 있다는 매우 높은 수준의 확신을 가지고 있기 때문에 그만한 가치가 있습니다.

— EEAA

핵심적으로 이것은 기술적 인 문제가 아니라 문화 및 자원 문제입니다. 구성 관리를 사용하지 않았습니다. 당신이 회사인지 아닌지는 관계가 없습니다. 작업을 올바르게 수행하는 방법에 대한 도움을 요청하고 준비 환경을 갖추는 것이 그 일부입니다.

— EEAA

IMHO, 그렇습니다. 하지만 동료에게 확신을 줄 수 있는지 여부는 또 다른 질문입니다. 서버를 관리하는 사람들로부터 어느 정도의 의도를 요구하지 않는 간단한 방법은 없습니다. 최신 CM 시스템 중에서 가장 빠른 속도를내는 것이 가장 쉬운 방법입니다. 당신은 할 시간에 서버 변경 사항을 추적합니다. 이를 안정적으로 수행하는 유일한 방법은 CM을 사용하는 것입니다.

— EEAA

@ThomWiggers "we"를 사용한 이후 두 팀이 같은 팀에 있다고 가정합니다. 좋아, 당신은 이것을 올바르게하는 방법을 물었다. 나는 대답했다. 당신이 제대로하고 싶거나하지 않습니다. CM을 제대로 수행하려면 시간, 돈 및 의도가 필요합니다. LE를 통한 인증서 조달 및 배포와 같은 요구 사항이있는 경우 Digital Ocean을 사용하여 월 $ 5US의 가상 머신을 세워 테스트에 사용하십시오. 변경 사항을 테스트 한 다음 종료하려는 경우 필요할 때 배포 할 수도 있습니다.

— EEAA

아마도 우리의 경험이 없기 때문에 구성이 약간의 시행 착오 과정이기 때문에 가능한 한 일련의 가능한 작업을 한 번에 정확히 입력 할 수 없었습니다. 즉, 실제로는 일반적으로 서버에서 실행하려는 서비스를 먼저 구성한 다음 가능한 작업으로 변환합니다.

(테스트 환경을 가지고 있지 같은) 다른 문제가 있지만, 당신은 일을하지 않음으로써 큰 개선 할 수 있습니다 이 .

하나 Ansible의 핵심 설계 목표는 될 것입니다 나무 등 , 어떤 당신의 각본을 여러 번 실행하면 아무것도 변경하지 않도록 수단 (당신이 연극을 변경 한 경우 제외). 따라서 새 소프트웨어를 구성 할 때 다음 단계는 다음과 같습니다.

Ansible 작업을 변경하십시오.
플레이 북을 실행하십시오.
시스템을 검사하고 올바르지 않은 경우 1 단계로 돌아가십시오.
변경 사항을 적용하십시오.

Ansible에서 처음으로 올바른 것을 작성한다고 생각하지 않는다면 다른 코드와 마찬가지로 어쨌든 작성하고 올바르게 될 때까지 반복하십시오. 이렇게하면 개발 프로세스 중 어느 시점에서든 모든 변경 사항이 이미 Ansible에 있었기 때문에 변경 내용을 확인하는 것을 잊을 가능성이 크게 줄어 듭니다.

— Monica Cellio의 보이콧 SE
소스

그렇습니다. 이것은 훌륭한 조언입니다. 이 작업을 수행하고 항상 서버를 알려진 정상 상태로 되돌릴 수 있는지 확인하는 것은 매우 자유 롭습니다. 일이 남쪽으로 가면 서버를 핵 공격하고 다시 배포하십시오.

— EEAA

저는 이것이 현재와 현재의 위치 사이에서 매우 견고한 중간 지에 동의합니다. 물론, 이것이 우리가 시작한 방법입니다. 우리가 지금 어디에 있는지에 대한 주된 이유는 2 단계가 전체주기를 너무 오래 걸렸기 때문이라고 생각합니다. 우리가 플레이 북을 잘못하고 있었을 수도 있습니다. 이제 Ansible 작업을 작성하는 데 조금 더 정통 해 졌으므로 다시 시도해 볼 가치가 있습니다. 경험상, 전체주기는 얼마나 오래 걸리며 얼마나 자주 반복됩니까? 나는 모든 숫자가 모든 종류의 가정을 기반으로한다는 것을 알고 있습니다.

— Joost

이 반복 프로세스에서 경험 한 다른 문제는 변경 작업을 작성하고 서버를 변경하며 변경 사항이 잘못된 것을 발견하고 작업을 업데이트하고 플레이 북을 다시 적용 할 때 발생합니다. 이제 서버에는 작업의 첫 번째 반복과 두 번째 변경의 두 가지 변경 사항이 혼합되어 있습니다. 일반적으로 두 번째 반복은 첫 번째 반복을 덮어 쓰지만 반드시 그런 것은 아닙니다. 1) 수동으로 SSH를 실행 취소하기 위해 또는 2) 항상 새로 설치를 시작하는 것보다 '정리'하는 합리적인 방법이 있습니까?

— Joost

또한 서버가 하나만있는 경우

— Thom Wiggers

"경험에서 전체주기는 얼마나 오래 걸리며 얼마나 자주 반복됩니까?" -1 월에 Ansible을 사용하기 시작했습니다. 약 6 월경에는 대부분의 작업에 대해 Ansible에서 전체 프로세스를 수작업보다 빠르게 수행하는 시점에 도달했습니다 . 과정의 특정 시간은 프로젝트에 따라 몇 분에서 몇 주까지 (일부 특별한 소프트웨어의 경우) 있습니다. 플레이 북 자체의 실행으로 인해 속도가 느려지는 것을 발견하면 반복 루프 중에 태그 를 사용하여 서브 세트 만 실행하는 것이 좋습니다.

— Monica Cellio에 대한 보이콧 SE

Ansible은 이전 생산성 수준을 초과하기 전에 램프 업 시간이 있지만 일단 시스템 상태가되면 쉽게 확인할 수 있습니다. 연습이 최종 목표와 동기화되지 않은 것으로 보입니다. 견고한 엔지니어링 방식을 유지하면서 CM 툴셋을 사용하여 생산성을 높일 수 있지만이를 올바르게 구성하는 데 시간이 걸립니다. 안정성과 엔터프라이즈 확장 성을 위해 본질적으로 거래 효율성과 구현이 용이합니다. 숙련 된 전문 프로그래머가 못생긴 해킹을 작성하지 않는 것과 동일한 방식으로 결과는 항상 이점보다 중요합니다.

초보자에게는 평범한 비극이 예상된다면 명확한 소유권없이 요리사가 너무 많을 수 있습니다. 각 비즈니스 우선 순위는 시스템 엔지니어링 문제가 광범위하게 분산되어 있지 않고 남아있는 것이 담당 엔지니어에게 직접 반영되지 않는 한 매번 시스템 엔지니어링 문제보다 우선합니다.

CM 툴셋은 관리자가 엔지니어링 할 수 없으며 이것이 바로 내가 깨닫게 된 것입니다. 기존 작업을 재사용하거나 건전한 기반을 확장 할 수는 있지만, 많은 양의 관행이 필요합니다. 엔지니어가 할 수있는 일은 단순히 관리자가 할 수있는 것이 아닙니다. Ansible의 많은 개념은 코드베이스와 거의 동일합니다. 관리자 파이썬을 가르치고 유능한 결과를 기대할 수 있습니까? 아니요, 가장 확실하지는 않지만 해킹 작업을 기대하므로 해킹 작업을 견딜 수 있도록 작업을 충분히 구조화해야합니다.

따라서 성공을 위해 필요한 것을 설정하고 불필요한 관리 지점을위한 솔루션을 엔지니어링해야합니다. 관리자가 실제로 수행 할 수있는 작업에 대해 저수준 시스템 복잡성을 거래하십시오. CM 툴셋은 건축 또는 디자인 불일치로부터 당신을 구하지 않습니다.

따라서 구현은 현재 상태에 가장 방해가되지 않는 경로에 따라 달라지기 때문에 순서는 변경 될 수 있습니다.

비즈니스 관련 워크 플로 관련 시스템 작업을 전용 Rundeck으로 옮깁니다.
상자에서 작업을 분할하면 지금 상자에 두 개 이상의 상자가있을 수 있습니다.
보다 체계적인 방식으로 CM을 재 구현하고 기능이나 역할이 아닌 객체를 나타내는 플레이 북을 더 잘 구현할 수 있습니다. 각 시스템은 한 번의 플레이로 설명해야합니다.

— JM 베커
소스