버전 관리, 테스트 및 지속적인 통합 / 배포와 같은 개발 관행을 시스템 관리에 어떻게 적용합니까?


18

많은 사람들이 사용하는 다양한 서비스를 사용하여 여러 서버를 관리한다고 상상해보십시오. 이제 해당 서버 중 하나에서 일부 소프트웨어를 재구성하거나 교체한다고 가정하십시오. 분명히 프로덕션 환경에있는 서버에서 작업하기를 원하지 않습니다.

이것이 코드 변경 인 경우 개발자로서 로컬 개발 시스템에서 변경을 수행하고 로컬로 테스트 한 후 변경 사항을 버전 제어 시스템에 적용합니다. 그런 다음 변경 사항을 준비 환경에 배포하고 추가 테스트를 거쳐 최종적으로 프로덕션 환경에 배포 할 수 있습니다. 필요한 경우 롤백하기도 쉽습니다.

일반적으로 또는 구체적으로 시스템 관리에서이를 어떻게 달성합니까?

(가장 떠오르는 것은 가상 머신을 사용하고 가상 머신 이미지를 버전 제어에 두는 것입니다. 그러나 현재 모르는 많은 문헌과 영리한 솔루션이 있습니다.)


이런 종류의 것을 관리하기위한 기술 도구 나 프레임 워크에 대해 질문하고 있습니까? ITIL 분야의 변경 및 릴리스 관리와 같은 사항은 언급하지 않고 후자의 옵션에 대해서는 말하기가 어렵습니다.
Rob Moir

@ DJPon3 일반적인 접근법 (어떻게 생각하는지)과 도구에 대해 알고 싶습니다. 마지막 단락을 출발점으로 자유롭게 사용하십시오.
arex1337

답변:


15

간단한 대답은 "OS 배포 관리", "구성 관리"및 "소프트웨어 패키징"입니다. 긴 대답은 다음과 같습니다.

시스템 관리에서 "시스템"을 구성하는 방식을 분석하여 Daniel Pittman의 답변에 추가하고 싶습니다.

시스템 또는 환경은 다음으로 구성됩니다.

  • 서버
  • 운영 체제
  • 구성
  • 공급 업체 패키지; 과
  • 지역 패키지

이를 포괄하는 프로세스는 다음과 같습니다.

  • OS 배포 또는 이미징
  • 구성 관리
  • 소프트웨어 패키지 관리
  • 감사 / 로깅
  • 모니터링
  • 백업

그리고 다음과 같은 비 기능적 목표를 달성하는 데 도움이되도록 이들을 결합하고 싶습니다.

  • 반복성
  • 유지 보수성
  • 측정 성
  • 공연
  • 추적 성
  • 테스트 가능성
  • 변하기 쉬운 성질

이것은 빠른 두뇌 덤프입니다. 모든 목록에 더 추가 할 수 있다고 확신합니다.

귀하의 질문은 특정 단어를 사용하지 않고 이들 중 많은 것들에 영향을 미칩니다. 예를 들어, 쉽게 배포하고 되돌릴 수 있기를 원합니다. 즉 유지 관리 성을 원합니다. 테스트 환경에서 수행하고 반복성, 테스트 가능성 및 측정 가능성을 통과 할 때까지 테스트합니다. OS 및 구성 배포의 반복성을 원하기 때문에 vm 이미지를 버전 제어에 배치하려고합니다.

이를 돕기 위해 많은 도구가 있으며, 다니엘이 언급 한 도구도 있습니다. 다른 것들은 :

  • 알려진 OS 환경을 배포하기위한 킥 스타트 (RedHat 기반), Preseed (데비안 기반), WDS (MS Windows)
  • 구성 및 패키지 관리를위한 Spacewalk / Satellite (RedHat 기반), 그룹 정책 (MS Windows)
  • 패키지 생성, 배포, 업그레이드 및 제거를위한 YUM 및 APT 패키징 시스템 (일련의 소프트웨어를 포함하는 바이너리, 데이터 및 구성 세트)
  • 모니터링을위한 Nagios, OpenNMS 및 SCOM
  • 백업용 Amanda, Bacula 및 Windows 백업 서버
  • 성능 모니터링을위한 Munin, PCP 및 Hyperic
  • 버전 관리를위한 CVS, SVN, GIT 또는 Bazaar
  • 빌드 관리를위한 Hudson 및 Jenkins
  • 테스트를위한 셀레늄 및 로봇
  • 녹음, 통신 및 추적을위한 Bugzilla, 요청 추적기 및 Jira

다시 말하지만, 이것은 포괄적 인 목록은 아니지만, 나를 안내하기 위해 머리 속에 두는 것입니다.


마빈이란? 그것에 대한 참조를 찾을 수 없거나 오타입니까?
thelsdj 2016 년

s / Marvin / Hudson /-@thelsdj :-)를 발견해 주셔서 감사합니다
nearora

16

면책 조항 : 저는 Puppet의 개발자 중 한 명입니다.

분명한 방법은 개념을 적용하는 것입니다. 개발 / 테스트 / 생산주기를 정의하고 변경 사항을 적용하는 것입니다. 버전 관리를 사용하여 시스템을 추적하십시오.

즉, 해당 경로를 시작하면 실제로 시스템 자동화를 수행하는 도구가 필요하다는 사실을 발견하게됩니다. 본질적으로 시스템 관리를 자동화하기 위해 시스템에서 해당 기술을 사용하지 않고 시스템에서 해당 기술을 사용합니다. 기계를 관리합니다.

Chef , Puppet , SaltCFEngine 과 같은 도구 는 모두 두 번째 요구를 해결하는 데 널리 사용되는 도구입니다. 이들은 시스템 관리를 버전 제어 및 테스트 할 수있는 중앙 솔루션으로 전환하는 일반적인 방향으로 작동합니다.

개발 운영의 운동은이 작업을 수행하는 방법에 대한 좋은 정보의 또 다른 원천입니다. 교훈은 개발자와 운영 직원 사이의 더 나은 협력이지만, 같은 방향으로 내려가는 경향이 있습니다.


15
이제 우리는 우리의 꼭두각시 질문에 ...에 대해 괴롭히는 누구인지
ewwhite

1

Windows 환경에서는 응용 프로그램 수명주기 관리와 관련된 이러한 문제가 System Center 2012에서 해결됩니다.

SCVMM (System Center Virtual Machine Manager)에서 서비스는 '서비스 템플릿'(예 : 클래식 3 계층 서비스)을 사용하여 정의되고 실행 환경은 '클라우드'(예 : 개발, 스테이징, 프로덕션)로 정의됩니다. 서비스 템플릿은 다른 클라우드에 버전을 지정하고 자동화 된 방식으로 롤아웃 할 수 있습니다. SCVMM은 가상 하드웨어 (VM 등) 및 소프트웨어 (OS, 앱 구성 요소 등)를 프로비저닝, 배포 및 구성하는 작업을 수행합니다.

System Center Service Manager는 프로세스 관점에서이를 함께 묶는 것입니다. 예를 들어, 이슈 관리 및 변경 제어

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.