현재 위치 - 회사기업대전 - 기업 정보 조회 - 프로그래머가 자동화된 운영 및 유지 관리에 대해 알아야 할 사항

프로그래머가 자동화된 운영 및 유지 관리에 대해 알아야 할 사항

개발자의 경우 운영 및 유지 관리는 그의 책임이 아닐 수 있습니다. 하지만 개발자로서 자동화된 운영과 유지보수의 전체 과정을 이해할 수는 없습니다. 정보 시스템의 경우 개발과 운영 및 유지 관리가 본질적으로 통합되어 있기 때문에 특히 일부 소규모 회사의 경우 운영 및 유지 관리 담당자 자체가 시간을 내어 겸직을 맡는 개발자일 수 있습니다.

자동화된 운영 및 유지 관리는 본질적으로 개발과 운영 및 유지 관리 사이에 있으며, 많은 경우에는 많은 코드를 작성해야 합니다. 따라서 모든 개발자는 자동화된 운영 및 유지 관리에 대한 관련 지식이 필요합니다.

잘 이해된 개발자는 운영 및 유지 관리 관련 작업을 수행하지 않더라도 프로젝트를 운영 및 유지 관리 담당자 등에 전달할 때 무엇이 ​​중요한지, 무엇을 구성해야 하는지 알 수 있습니다. 그러나 실제 작업에서 개발자는 자신만 알고 운영 및 유지보수 담당자는 모르는 몇 가지 함정을 운영 및 유지보수 인력에게 남겨두는 경우가 많습니다. 그 결과, 운영 및 유지보수 담당자가 여러 번 시도했지만 작동하지 않는다는 사실을 발견했을 때 개발자를 찾았습니다. 몇 가지 조사 끝에 개발자는 특정 환경에서 어떤 포트를 사용해야 하는지 알려주었습니다. 이는 운영 및 유지보수 인력의 시간을 낭비할 뿐만 아니라, 통신 업무량도 증가시킨다.

일부 현장 문제의 경우 운영 및 유지 관리 담당자가 현장에서 문제를 찾을 수 없는 경우에도 마찬가지입니다. 개발자가 재현하는 것은 매우 어렵습니다. 예를 들어, 어떤 회사에서는 운영 및 유지보수 담당자가 고객 현장에서 문제점을 발견했습니다. 정중한 인트라넷에서 로그를 내보내어 개발자에게 보내는 데 많은 노력이 필요했습니다. 그러나 개발자가 로그를 주의 깊게 조사한 결과 네트워크에 문제가 있음을 발견했습니다. 개발자가 네트워크가 연결되지 않은 이유를 아는 것은 분명히 불가능합니다. 어쩌면 네트워크 케이블이 전혀 연결되어 있지 않을 수도 있습니다.

그래서 오늘은 자동화된 운영 및 유지 관리에 대해 프로그래머가 알아야 할 사항에 대해 이야기해 보겠습니다.

1. 자동화된 운영 및 유지 관리의 개념

정보화 시대의 지속적인 발전으로 초기 소수의 서버가 거대한 데이터 센터로 발전했으며 더 이상 수동 작업만으로는 불가능합니다. 기술, 비즈니스, 관리 및 기타 요구 사항을 충족합니다. 한 명의 운영 및 유지 관리 담당자가 여러 서버를 수동으로 구성하는 것이 가능합니다. 수백 또는 수천 개의 서버를 구성하는 것은 피곤하고 오류가 발생하기 쉽습니다. 그러면 운영 및 유지보수 작업을 위한 표준화, 자동화, 구조 최적화, 프로세스 최적화 등이 필요합니다. 모든 측면에서 운영 및 유지보수 서비스 비용을 절감합니다. 그 중 자동화는 처음에는 수동 작업을 대체하는 출발점으로 널리 연구 및 적용되었습니다.

소위 자동화된 운영 및 유지 관리란 수동 개입을 최소화하면서 스크립트와 제3자 도구의 조합을 사용하여 연중무휴 24시간 비즈니스 시스템의 효율적이고 안정적인 운영을 보장하는 것을 의미합니다. 이는 모든 비즈니스 시스템 운영 및 유지관리의 궁극적인 목표입니다.

운영 및 유지 관리의 개발 성숙도에 따라 운영 및 유지 관리는 대략 세 단계로 나눌 수 있습니다.

(1) 순수 수동 및 반복적인 소프트웨어 배포 및 운영 및 유지 관리에 의존 ;

(2) 스크립트 작성을 통해 소프트웨어를 편리하게 배포하고 운영합니다.

(3) 소프트웨어를 효율적으로 배포하고 운영하기 위해 타사 도구를 사용합니다. 자동화된 운영 및 유지 관리에서 해결해야 할 문제

일반적으로 자동화된 운영 및 유지 관리에서는 자동 배포 및 구성, 위험 조기 경고, 이벤트 중 문제 해결 및 사후 문제를 해결해야 합니다. -실패 관리.

3. 자동화된 운영 및 유지 관리에 일반적으로 사용되는 도구

자동화된 운영 및 유지 관리에 일반적으로 사용되는 도구는 다음과 같습니다.

1. Ansible

Ansible은 Python을 기반으로 개발된 자동화된 운영 및 유지 관리 도구로, 다양한 운영 및 유지 관리 도구(puppet, cfengine, Chef, func, fabric)의 장점을 통합하고 배치 시스템 구성, 배치 프로그램 배포, 명령을 일괄적으로 실행합니다.

Ansible에는 다음과 같은 기능이 있습니다.

(1) 모듈화: 특정 모듈을 호출하여 특수 작업을 완료합니다.

(2) 세 가지 핵심 모듈: Paramiko(Python의 SSH 구현), PyYaml 및 jinja2(모듈 언어).

(3) 사용자 정의 모듈을 지원하고 모든 프로그래밍 언어를 사용하여 모듈을 작성할 수 있습니다.

(4) Python 언어를 기반으로 합니다.

(5) Python 및 SSH(기본적으로 설치됨) 기반의 간단한 배포, 에이전트 없음, 에이전트 필요 없음, KPI 의존 없음(SSL 필요 없음).

(6) OpenSSH 기반의 보안

(7) 멱등성(Idempotence): 작업을 한 번 실행하면 n번 실행한 것과 동일한 효과가 있으며, 반복 실행으로 인해 예상치 못한 상황이 발생하지 않습니다. 실행.

(8) 플레이북 정렬 작업, YAML 형식, 정렬 작업을 지원하고 풍부한 데이터 구조를 지원합니다.

(9) 더욱 강력한 다계층 솔루션 역할.

2. Chef

Chef는 모든 환경에 서버와 애플리케이션을 배포, 복구, 업데이트하고 관리할 수 있는 강력한 자동화 도구입니다.

Chef는 크게 Chef Server, Workstation, Chef Client의 세 부분으로 나뉩니다. 사용자는 Workstation에서 요리책을 작성합니다. 그런 다음 Knife 명령을 통해 Chef Server에 업로드합니다. 마지막으로 Chef Client를 설치하고 배포합니다. 따라서 Cookbook을 작성하는 것은 전체 자동화 배포에서 중요한 역할을 합니다.

Chef 서버는 모든 구성 데이터를 포함하고 Chef-Client의 각 노드를 설명하는 레시피, 요리책 및 메타데이터를 저장합니다. 구성 세부 정보는 Chef-Client를 통해 노드에 제공됩니다. 모든 변경 사항은 Chef Server를 통해 배포되어야 합니다. 변경 사항을 푸시하기 전에 인증 키를 사용하여 노드와 워크스테이션이 서버와 페어링되었는지 확인한 다음 워크스테이션과 노드 간의 통신을 허용합니다.

워크스테이션은 Chef 서버 및 Chef 노드와 상호 작용하는 데 사용됩니다. 요리책을 만드는 데에도 사용됩니다. 워크스테이션은 모든 상호 작용이 일어나는 곳이며, 요리책이 생성, 테스트, 배포되고 워크스테이션에서 코드가 테스트되는 곳입니다.

Chef 명령줄 도구는 이 정책을 통해 Cookbook이 생성, 테스트, 배포되고 Chef Server에 업로드되는 곳입니다.

Knife는 ChefNodes와 상호작용하는 데 사용됩니다.

Test Kitchen은 Chef 코드를 확인하는 데 사용됩니다.

Chef-Repo는 Chef 명령줄 도구를 통해 Cookbook이 생성, 테스트 및 유지 관리되는 저장소입니다.

노드는 Chef에 의해 관리되며 각 노드는 Chef-Client를 설치하여 구성됩니다. ChefNodes는 물리적 클라우드, 클라우드 호스트 등과 같은 머신입니다.

Chef-Client는 노드 등록 및 인증, 노드 객체 구축 및 노드 구성을 담당합니다.

Chef-Client는 각 노드에서 로컬로 실행되어 해당 노드를 구성합니다.

Cookbook은 Chef 프레임워크의 중요한 기본 기능 중 하나입니다. Chef Server는 대상 머신에 설치 및 배포할 때 Runlist를 사용합니다. Runlist에는 특정 Cookbook이 포함되어 있으므로 대상 머신의 최종 배포 작업은 Cookbook에 속합니다. Cookbook의 경우 여러 구성 요소가 포함되어 있습니다. Cookbook을 레시피, 파일, 템플릿, 라이브러리, 메타데이터 및 기타 정보가 포함된 컨테이너 또는 패키지로 간단히 이해할 수 있습니다. 이 정보는 대상 시스템을 구성하는 데 사용됩니다.

3. Puppet

Puppet은 Linux 및 Unix 플랫폼을 위한 중앙 집중식 구성 관리 시스템입니다. 소위 구성 관리 시스템은 파일, 사용자, 프로세스, 소프트웨어 패키지 등을 관리하는 것입니다. . 서버에서 실행될 수 있습니다. 각 클라이언트는 SSL 인증서를 통해 서버에 연결하고 이 시스템의 구성 목록을 가져온 다음 목록을 기반으로 구성 작업을 완료합니다. 따라서 하드웨어 성능이 상대적으로 높으면 수천 대의 장치가 작동합니다. 클라이언트 구성, 서버 경로 및 소프트웨어가 일관되어야 한다면 시스템을 매우 쉽게 유지 관리할 수 있습니다.

클라이언트 Puppet은 로컬 팩터를 호출하고 해당 팩터는 호스트 이름, 메모리 크기, IP 주소 등과 같은 호스트의 공통 변수를 감지합니다. 그런 다음 Puppetd는 이 정보를 Puppet 서버로 보냅니다.

Puppet 서버는 클라이언트의 호스트 이름을 감지한 다음 매니페스트에서 해당 노드 구성을 감지하고 팩터 정보에서 보낸 이 콘텐츠를 구문 분석합니다.

Puppet 서버는 Puppet 클라이언트와 관련된 코드와 일치하는 경우에만 구문 분석할 수 있으며, 그 외의 코드는 구문 분석 작업으로 나누어집니다. 그런 다음 중간에 있는 의사 코드가 Puppet 클라이언트로 전송됩니다.

Puppet 클라이언트는 의사 코드를 수신한 후 실행하고, 실행이 완료된 후 실행 결과를 Puppet 서버로 보냅니다. ;

p>

그런 다음 Puppet 서버는 클라이언트의 실행 결과를 로그에 기록합니다.

4. 솔트스택(Saltstack)

솔트스택(SaltStack)은 파이썬을 기반으로 개발된 C/S 자동화 운영 및 유지관리 도구 모음입니다. 배포가 쉽고 확장성이 좋으며 수만 대의 서버를 쉽게 관리할 수 있고 충분히 빠릅니다. 서버와의 통신(밀리초)입니다. SaltStack은 오케스트레이션, 원격 실행, 구성 관리 등을 위한 동적 인프라 통신 버스를 제공합니다. 하위 계층에서는 ZeroMQ 메시지 큐 게시/구독 통신을 사용하고, 인증 관리를 위해 SSL 인증서 발급을 사용하며, 전송을 위해 AES 암호화를 사용합니다.

솔트스택 아키텍처에서는 서버를 마스터, 클라이언트를 미니언이라고 합니다.

마스터와 미니언 모두 데몬 모드에서 실행되며 항상 구성 파일에 정의된 ret_port(미니언 요청 수락) 및 게시_포트(메시지 게시) 포트를 수신합니다. Minion이 실행되면 연결 인증을 위해 구성 파일에 정의된 마스터 주소 ret_port 포트에 자동으로 연결됩니다.

실제로 솔트스택에는 전통적인 C/S 아키텍처 외에 마스터리스(masterless)라는 아키텍처도 있는데, 이는 별도의 마스터 서버를 설치할 필요가 없고 각 머신에 미니언 측만 설치하면 된다. 그런 다음 이것을 사용하십시오. 머신은 머신의 구성 관리 메커니즘 서비스 모드만 담당합니다.

Saltstack은 다음과 같은 기능을 제공합니다.

(1) 원격 실행: (명령 일괄 실행) 마스터에서 명령이 실행되면 모든 미니언에서 실행됩니다.

(2) 구성 관리/상태 관리: (달성하려는 상태를 설명하면 솔트스택이 이를 실행합니다.)

(3) 클라우드 관리(cloud): 클라우드를 관리하는 데 사용됩니다. 호스트

(4) 이벤트 중심: 수동 실행, 특정 값에 도달하면 자동으로 트리거됨

이 네 가지 자동화된 운영 및 유지 관리 도구의 비교는 현재 주류입니다. 기본적으로 ansible과 saltstack을 사용하세요.

copyright 2024회사기업대전