새해가 다가오고있었습니다. 전국의 아이들은 이미 산타클로스에게 편지를 보내거나 스스로를 위해 선물을 만들었고, 주요 소매업체 중 하나인 그들의 주요 집행자는 판매의 신격화를 준비하고 있었습니다. XNUMX월에는 데이터 센터의 부하가 몇 배로 증가합니다. 따라서 회사는 서비스 수명이 다한 장비 대신 데이터 센터를 현대화하고 수십 대의 새 서버를 가동하기로 결정했습니다. 이로써 소용돌이치는 눈송이를 배경으로 이야기가 끝나고 스릴러가 시작됩니다.

장비는 판매가 최고조에 달하기 몇 달 전에 현장에 도착했습니다. 물론 운영 서비스는 서버를 프로덕션 환경으로 가져오기 위해 서버에서 구성하는 방법과 내용을 알고 있습니다. 하지만 우리는 이를 자동화하고 인적 요소를 제거해야 했습니다. 또한 회사에 중요한 SAP 시스템 세트를 마이그레이션하기 전에 서버를 교체했습니다.

새로운 서버의 시운전은 마감일에 엄격하게 묶여 있었습니다. 그리고 이를 이동한다는 것은 수십억 개의 선물 배송과 시스템 마이그레이션이 모두 위태로워지는 것을 의미했습니다. Frost 신부와 산타클로스로 구성된 팀조차도 날짜를 변경할 수 없었습니다. 창고 관리를 위해 SAP 시스템을 31년에 한 번만 이전할 수 있습니다. 1월 20일부터 15월 XNUMX일까지 축구장 XNUMX개 크기에 달하는 이 소매업체의 거대한 창고는 XNUMX시간 동안 작업을 중단합니다. 그리고 이것은 시스템을 이동하는 유일한 기간입니다. 서버를 도입할 때 실수할 여지가 없었습니다.

분명히 말씀드리자면 제 이야기는 우리 팀에서 사용하는 도구와 구성 관리 프로세스를 반영합니다.

구성 관리 컴플렉스는 여러 수준으로 구성됩니다. 핵심 구성 요소는 CMS 시스템입니다. 산업 운영에서 수준 중 하나가 없으면 필연적으로 불쾌한 기적이 발생할 것입니다.

OS 설치 관리

첫 번째 수준은 물리적 서버와 가상 서버의 운영 체제 설치를 관리하는 시스템입니다. 인적 요소를 제거하여 기본 OS 구성을 생성합니다.

이 시스템을 사용하여 추가 자동화에 적합한 OS가 포함된 표준 서버 인스턴스를 받았습니다. "쏟아지는" 동안 그들은 최소한의 로컬 사용자 세트와 공개 SSH 키는 물론 일관된 OS 구성을 받았습니다. 우리는 CMS를 통해 서버를 관리할 수 있었고 OS 수준에서 "아래"에 놀라운 일이 없다고 확신했습니다.

설치 관리 시스템의 "최대" 작업은 BIOS/펌웨어 수준에서 OS까지 서버를 자동으로 구성하는 것입니다. 여기서 많은 부분은 장비 및 설정 작업에 따라 달라집니다. 이기종 장비의 경우 다음을 고려할 수 있습니다. 레드피쉬 API. 모든 하드웨어가 한 공급업체의 제품인 경우 기성 관리 도구(예: HP ILO Amplifier, DELL OpenManage 등)를 사용하는 것이 더 편리한 경우가 많습니다.

물리적 서버에 OS를 설치하기 위해 우리는 운영 서비스와 합의된 설치 프로필 세트를 정의하는 잘 알려진 Cobbler를 사용했습니다. 인프라에 새 서버를 추가할 때 엔지니어는 서버의 MAC 주소를 Cobbler의 필수 프로필에 연결했습니다. 처음으로 네트워크를 통해 부팅할 때 서버는 임시 주소와 새로운 OS를 받았습니다. 그런 다음 대상 VLAN/IP 주소 지정으로 전송되어 그곳에서 계속 작업했습니다. 예, VLAN을 변경하는 데는 시간이 걸리고 조정이 필요하지만 프로덕션 환경에 실수로 서버를 설치하는 경우를 대비해 추가적인 보호 기능을 제공합니다.

HashiСorp Packer를 사용하여 준비된 템플릿을 기반으로 가상 서버를 만들었습니다. 이유는 같았습니다. OS 설치 시 발생할 수 있는 인적 오류를 방지하기 위해서였습니다. 그러나 물리적 서버와 달리 Packer는 PXE, 네트워크 부팅 및 VLAN 변경이 필요하지 않습니다. 이로 인해 가상 서버를 더욱 쉽고 간단하게 만들 수 있게 되었습니다.

쌀. 1. 운영 체제 설치를 관리합니다.

비밀 관리

모든 구성 관리 시스템에는 일반 사용자에게 숨겨야 하는 데이터가 포함되어 있지만 시스템을 준비하는 데 필요합니다. 이는 로컬 사용자 및 서비스 계정의 비밀번호, 인증서 키, 다양한 API 토큰 등입니다. 일반적으로 "비밀"이라고 합니다.

처음부터 이러한 비밀을 저장할 위치와 방법을 결정하지 않은 경우 정보 보안 요구 사항의 심각도에 따라 다음과 같은 저장 방법을 사용할 수 있습니다.

• 구성 제어 코드 또는 저장소의 파일에서 직접;
• 전문 구성 관리 도구(예: Ansible Vault)
• CI/CD 시스템(Jenkins/TeamCity/GitLab/등) 또는 구성 관리 시스템(Ansible Tower/Ansible AWX)
• 비밀은 "수동으로" 전송될 수도 있습니다. 예를 들어, 지정된 위치에 배치된 다음 구성 관리 시스템에서 사용됩니다.
• 위의 다양한 조합.

각 방법에는 고유한 단점이 있습니다. 가장 큰 문제는 비밀에 대한 액세스에 대한 정책이 부족하다는 것입니다. 즉, 누가 특정 비밀을 사용할 수 있는지 결정하는 것이 불가능하거나 어렵습니다. 또 다른 단점은 액세스 감사와 전체 수명 주기가 부족하다는 것입니다. 예를 들어 코드 및 여러 관련 시스템에 작성된 공개 키를 신속하게 교체하는 방법은 무엇입니까?

우리는 중앙 집중식 비밀 저장소인 HashiCorp Vault를 사용했습니다. 이를 통해 우리는 다음을 수행할 수 있었습니다.

• 비밀을 안전하게 유지하세요. 이는 암호화되어 있으며 누군가가 Vault 데이터베이스에 대한 액세스 권한을 얻더라도(예: 백업에서 복원하여) 그곳에 저장된 비밀을 읽을 수 없습니다.
• 비밀에 대한 액세스를 위한 정책을 구성합니다. 사용자와 애플리케이션은 "할당된" 비밀만 사용할 수 있습니다.
• 비밀에 대한 액세스를 감사합니다. 비밀이 포함된 모든 작업은 Vault 감사 로그에 기록됩니다.
• 비밀 작업의 본격적인 "라이프 사이클"을 구성합니다. 생성, 취소, 만료일 설정 등이 가능합니다.
• 비밀에 접근해야 하는 다른 시스템과 쉽게 통합할 수 있습니다.
• 또한 엔드 투 엔드 암호화, OS 및 데이터베이스의 일회용 비밀번호, 공인 센터 인증서 등을 사용합니다.

이제 중앙 인증 및 권한 부여 시스템으로 넘어가겠습니다. 그것 없이도 가능했지만 많은 관련 시스템에서 사용자를 관리하는 것은 너무 쉽지 않습니다. LDAP 서비스를 통해 인증 및 권한 부여를 구성했습니다. 그렇지 않으면 Vault는 사용자에 대한 인증 토큰을 지속적으로 발행하고 추적해야 합니다. 그리고 사용자를 삭제하고 추가하는 것은 "내가 이 사용자 계정을 모든 곳에서 생성/삭제했습니까?"라는 퀘스트로 바뀌게 됩니다.

우리는 시스템에 비밀 관리 및 중앙 인증/권한 부여라는 또 다른 수준을 추가합니다.

쌀. 2. 비밀 관리.

구성 관리

우리는 핵심인 CMS 시스템에 도달했습니다. 우리의 경우 이는 Ansible과 Red Hat Ansible AWX의 조합입니다.

Ansible 대신 Chef, Puppet, SaltStack을 사용할 수 있습니다. 우리는 몇 가지 기준에 따라 Ansible을 선택했습니다.

• 첫째, 다양성이다. 제어를 위해 미리 만들어진 모듈 세트 인상을 준다. 충분하지 않은 경우 GitHub 및 Galaxy에서 검색할 수 있습니다.
• 둘째, 관리되는 장비에 에이전트를 설치 및 지원하고, 로드를 방해하지 않는다는 것을 증명하고, "북마크"가 없음을 확인할 필요가 없습니다.
• 셋째, Ansible은 진입 장벽이 낮습니다. 유능한 엔지니어는 제품 작업 첫날 문자 그대로 작업 플레이북을 작성합니다.

하지만 프로덕션 환경에서 Ansible만으로는 충분하지 않았습니다. 그렇지 않으면 액세스를 제한하고 관리자의 작업을 감사하는 데 많은 문제가 발생할 수 있습니다. 접근을 제한하는 방법은 무엇입니까? 결국 각 부서는 "자체" 서버 세트를 관리(읽기: Ansible 플레이북 실행)해야 했습니다. 특정 직원만 특정 Ansible 플레이북을 실행하도록 허용하는 방법은 무엇입니까? 아니면 Ansible을 실행하는 서버와 장비에 대한 많은 현지 지식을 설정하지 않고 누가 플레이북을 시작했는지 추적하는 방법은 무엇입니까?

이러한 문제의 대부분은 Red Hat에 의해 해결됩니다. 앤서블 타워, 또는 그의 오픈 소스 업스트림 프로젝트 앤서블 AWX. 그래서 우리는 고객을 위해 그것을 선호했습니다.

그리고 CMS 시스템의 초상화를 한 번 더 터치해 보겠습니다. Ansible 플레이북은 코드 저장소 관리 시스템에 저장되어야 합니다. 우리는 그것을 가지고있다 깃랩 CE.

따라서 구성 자체는 Ansible/Ansible AWX/GitLab의 조합으로 관리됩니다(그림 3 참조). 물론 AWX/GitLab은 단일 인증 시스템으로 통합되고, Ansible 플레이북은 HashiCorp Vault와 통합됩니다. 구성은 모든 "게임의 규칙"이 지정되는 Ansible AWX를 통해서만 프로덕션 환경에 들어갑니다. 즉, 누가 무엇을 구성할 수 있는지, CMS용 구성 관리 코드를 어디서 얻을 수 있는지 등이 지정됩니다.

쌀. 3. 구성 관리.

테스트 관리

우리의 구성은 코드 형식으로 제공됩니다. 따라서 우리는 소프트웨어 개발자와 동일한 규칙을 따라야 합니다. 우리는 프로덕션 서버에 대한 구성 코드의 개발, 지속적인 테스트, 전달 및 적용 프로세스를 구성해야 했습니다.

이 작업이 즉시 수행되지 않으면 구성을 위해 작성된 역할은 지원 및 수정이 중단되거나 프로덕션에서 시작이 중단됩니다. 이 통증에 대한 치료법은 알려져 있으며 이 프로젝트에서 입증되었습니다.

• 각 역할은 단위 테스트로 다뤄집니다.
• 구성을 관리하는 코드가 변경될 때마다 테스트가 자동으로 실행됩니다.
• 구성 관리 코드의 변경 사항은 모든 테스트와 코드 검토를 성공적으로 통과한 후에만 프로덕션 환경에 릴리스됩니다.

코드 개발 및 구성 관리는 더욱 차분해지고 예측 가능해졌습니다. 지속적인 테스트를 구성하기 위해 GitLab CI/CD 툴킷을 사용하고 앤서블 분자.

구성 관리 코드가 변경될 때마다 GitLab CI/CD는 Molecule을 호출합니다.

• 코드 구문을 확인하고,
• Docker 컨테이너를 올리고,
• 생성된 컨테이너에 수정된 코드를 적용하고,
• 역할의 멱등성을 확인하고 이 코드에 대한 테스트를 실행합니다(여기서 세분성은 Ansible 역할 수준에 있습니다. 그림 4 참조).

우리는 Ansible AWX를 사용하여 프로덕션 환경에 구성을 제공했습니다. 운영 엔지니어는 사전 정의된 템플릿을 통해 구성 변경 사항을 적용했습니다. AWX는 사용될 때마다 GitLab 마스터 브랜치에서 최신 버전의 코드를 독립적으로 "요청"했습니다. 이러한 방식으로 우리는 프로덕션 환경에서 테스트되지 않았거나 오래된 코드의 사용을 제외했습니다. 당연히 코드는 테스트, 검토 및 승인 후에만 마스터 브랜치에 입력되었습니다.

쌀. 4. GitLab CI/CD의 역할 자동 테스트.

생산 시스템의 운영과 관련된 문제도 있습니다. 실제로 CMS 코드만으로 구성을 변경하는 것은 매우 어렵습니다. 엔지니어가 코드 편집, 테스트, 승인 등을 기다리지 않고 "지금 여기" 구성을 변경해야 하는 경우 긴급 상황이 발생합니다.

결과적으로 수동 변경으로 인해 동일한 유형의 장비에서 구성에 불일치가 나타납니다(예: sysctl 설정이 HA 클러스터 노드에서 다르게 구성됨). 또는 장비의 실제 구성이 CMS 코드에 지정된 구성과 다릅니다.

따라서 지속적인 테스트 외에도 프로덕션 환경에서 구성 불일치가 있는지 확인합니다. 우리는 가장 간단한 옵션을 선택했습니다. 즉, 변경 사항을 적용하지 않고 계획된 구성과 실제 구성 간의 모든 불일치를 알리는 "모의 실행" 모드에서 CMS 구성 코드를 실행하는 것입니다. 우리는 프로덕션 서버에서 "-check" 옵션을 사용하여 모든 Ansible 플레이북을 주기적으로 실행하여 이를 구현했습니다. 언제나 그렇듯이 Ansible AWX는 플레이북을 시작하고 최신 상태로 유지하는 역할을 담당합니다(그림 5 참조).

쌀. 5. Ansible AWX에서 구성 불일치를 확인합니다.

확인 후 AWX는 불일치 보고서를 관리자에게 보냅니다. 문제가 있는 구성을 연구한 다음 조정된 플레이북을 통해 수정합니다. 이것이 우리가 프로덕션 환경에서 구성을 유지하는 방법이며 CMS는 항상 최신 상태로 동기화됩니다. 이는 CMS 코드가 "프로덕션" 서버에서 사용될 때 불쾌한 "기적"을 제거합니다.

이제 Ansible AWX/GitLab/Molecule으로 구성된 중요한 테스트 계층이 생겼습니다(그림 6).

쌀. 6. 테스트 관리.

어려운? 나는 논쟁하지 않습니다. 그러나 이러한 복잡한 구성 관리는 서버 구성 자동화와 관련된 많은 질문에 대한 포괄적인 답변이 되었습니다. 이제 소매업체의 표준 서버는 항상 엄격하게 정의된 구성을 갖습니다. CMS는 엔지니어와 달리 필요한 설정을 추가하고, 사용자를 생성하고, 수십, 수백 가지의 필수 설정을 수행하는 것을 잊지 않습니다.

오늘날 서버 및 환경 설정에는 "비밀 지식"이 없습니다. 필요한 모든 기능은 플레이북에 반영되어 있습니다. 더 이상 창의성이나 모호한 지침이 없습니다. “일반 Oracle처럼 설치하지만 몇 가지 sysctl 설정을 지정하고 필수 UID를 사용하여 사용자를 추가해야 합니다. 운영하는 사람들한테 물어보면 다 알잖아요".

구성 불일치를 감지하고 사전에 수정하는 기능은 마음의 평화를 제공합니다. 구성 관리 시스템이 없으면 일반적으로 다르게 보입니다. 어느 날 생산에 "촬영"될 때까지 문제가 누적됩니다. 그런 다음 보고가 수행되고 구성이 확인되고 수정됩니다. 그리고 그 사이클은 다시 반복됩니다

물론, 우리는 서버 출시를 며칠에서 몇 시간으로 가속화했습니다.

음, 새해 전야에 아이들이 즐겁게 선물 포장을 풀고 어른들이 종소리를 들으며 소원을 빌고 있을 때 우리 엔지니어들은 SAP 시스템을 새 서버로 마이그레이션했습니다. 산타클로스도 최고의 기적은 잘 준비된 기적이라고 말할 것이다.

추신: 우리 팀은 고객이 구성 관리 문제를 최대한 간단하게 해결하기를 원한다는 사실을 자주 접합니다. 이상적으로는 마치 마술처럼 하나의 도구를 사용하는 것입니다. 하지만 인생에서는 모든 것이 더 복잡합니다(예, 묘책은 다시 제공되지 않았습니다). 고객 팀에 편리한 도구를 사용하여 전체 프로세스를 만들어야 합니다.

저자: Sergey Artemov, 부서 설계자 DevOps 솔루션 "제트 인포시스템즈"

출처 : habr.com