configuration management devops practices
DevOps Practices의 구성 관리 란 무엇입니까?
의 개념 DevOps의 지속적인 테스트 이전 튜토리얼에서 자세히 설명했습니다.
DevOps에서 구성 관리의 주요 하이라이트는
- 코드로서의 인프라
- 코드로 구성
읽어야 함 => 독점 DevOps 튜토리얼 시리즈
일할 비디오 게임 회사
DevOps 실무에서는 '코드로서의 인프라'및 '코드로서의 구성'의 많은 이점이 있습니다.
-
- 구성은 버전 제어
- 자동화 및 표준화
- 종속성 제거
- 오류없는 인프라 설정
- 운영 및 개발 팀 간의 협업 강화
- 구성 드리프트 수정
- 인프라를 유연한 리소스로 취급
- 자동화 된 인프라 확장
- 설정의 일관성 유지
비디오 파트 4 블록 1 : 구성 관리– 23 분 7 초
성적 증명서:
이 부분에서 우리는 DevOps의 구성 관리, 릴리스 관리 및 애플리케이션 성능 모니터링.
여기서 블록 1에서는 구성 관리에 중점을두고 구성 관리가 무엇이며 DevOps 및 기존 방법에서 어떻게 다른지 이해합니다.
먼저 구성 관리 란 무엇입니까?
이름 자체에서 설명하는 구성 관리는 소프트웨어 응용 프로그램이 호스팅하는 환경의 모든 구성을 관리하는 것입니다.
아시다시피, 우리는 단위 테스트, 통합 테스트, 시스템 테스트, 승인 테스트 및 최종 사용자 테스트를 시작으로 DevOps의 SDLC 전체에 걸쳐 다른 환경을 가지고 있습니다.
또한 이전 자습서에서 이러한 테스트를위한 환경 설정이 사전 프로덕션 및 프로덕션 환경으로 이동함에 따라 점점 더 복잡해질 것이라고 설명했습니다.
따라서 기본적으로 구성 관리는 이러한 각 환경의 모든 구성을 관리하는 자동화 된 프로세스입니다.
그렇다면 기존 구성 관리와 DevOps 구성 관리의 차이점은 무엇입니까?
기존의 구성 관리 방법에서 팀은 공식 문서를 통해 다양한 환경의 이러한 구성을 관리하는 데 사용되었으며 각 구성은 문서에 기록되고 구성 팀 또는 관리자는 이러한 문서의 버전 제어를 처리하는 데 사용되었습니다.
그리고 변경 될 때 그는 환경을 설정하고 구성을 수동으로 관리하는 책임도 맡게됩니다.
이제 DevOps에서는 일반적으로 이러한 모든 구성 관리 프로세스가 매우 잘 자동화되고 구성이 코드 또는 스크립트의 형태로 캡슐화되고 버전 제어 도구를 통해 제어됩니다.
이러한 맥락에서 단일 버전 제어 도구를 통해 환경을 관리 할 때 운영 팀이 개발과 통합되었다고 할 수 있습니다.
따라서 DevOps에서 구성 관리의 주요 하이라이트는
-
-
- 코드로서의 인프라
- 코드로 구성
-
실제로 '코드로서의 인프라'는 무엇을 의미합니까? 전체 환경 정의를 공식 문서에 기록하는 대신 코드 또는 스크립트로 정의합니다.
그렇다면 환경 정의에는 무엇이 포함됩니까? 환경 정의에는 일반적으로 서버 설정, 네트워크 구성 및 IT 인프라 설정의 일부인 다른 컴퓨팅 리소스 설정이 포함됩니다. 따라서 이러한 모든 세부 정보는 파일 또는 코드 형태로 작성되고 버전 관리 도구에 체크인됩니다.
버전 제어에 체크인 된이 스크립트 또는 코드는 환경을 정의하거나 해당 환경을 업데이트하는 단일 소스가됩니다.
간단하게 예 , 특정 환경에 서버를 추가해야하는 경우 추가 된 서버로 새 환경을 수동으로 이동 및 회전하거나 찾는 대신 이러한 정보를 환경 스크립트에 업데이트하고 전달 파이프 라인을 실행하면됩니다. 시스템 관리자의 도움이 필요합니다.
따라서 여기서 장점은 개발자 또는 테스터가 개발 또는 테스트 활동을 위해 서버를 설정하기 위해 시스템 관리자 전문가 일 필요가 없다는 것입니다.
따라서 DevOps에 설정된 인프라는 완전히 자동화되며 기본적으로 서버 설치, 구성, OS 설치부터 이러한 인스턴스의 통신 채널이 구축 될 때까지 버전 제어에 체크인되는 스크립트를 따릅니다. 소프트웨어.
코드로서의 구성은 무엇입니까?
코드로서의 구성은 서버 또는 기타 리소스의 모든 구성을 코드 또는 스크립트로 정의하고 버전 제어로 확인하는 것입니다.
버전 제어에 체크인 된 이러한 구성 스크립트는 인프라 및 해당 구성을 자동화 된 방식으로 설정하기 위해 배포 파이프 라인의 일부로 실행됩니다.
구성 정의에는 소프트웨어를 성공적으로 실행하기위한 권장 설정을 정의하는 매개 변수가 포함됩니다. 또는 소프트웨어 응용 프로그램을 설정하기 위해 처음에 실행할 명령 집합입니다. 또는 설정할 소프트웨어의 각 구성 요소 또는 특정 사용자 역할, 사용자 권한 등의 구성 일 수도 있습니다.
단순한 예 기능 토글을 설정하는 것입니다. 여기서 기본값은 구성 매개 변수의 일부로 설정됩니다.
방화벽에 다른 포트를 추가하는 것은 다른 것입니다. 예 , 스크립트에서 업데이트 할 수 있으며 나중에 이러한 스크립트가 전송 파이프 라인의 일부로 실행됩니다.
시장에서 인프라 자동화를 수행하기 위해 여러 도구를 사용할 수 있습니다. 그중 Chef, Puppet, Terraform 등은 거의 없으며 Chef 및 Puppet은 루비 기반 구성 관리 도구 인 반면 Terraform은 프로비저닝 도구입니다.
또한 요즘에는 거의 모든 애플리케이션이 클라우드, AWS에서 호스팅되기 때문에 자체적으로 RESTAPI를 제공하며이를 위해 활용할 수 있습니다.
인프라와 구성을 코드로 정의하는 대신 DevOps의 구성 관리 이점에 대한 방대한 목록이 있습니다.
하나씩 살펴 보겠습니다.
모든 구성 및 인프라 세부 정보는 버전이 제어되므로 DevOps 구현에 큰 이점이 있습니다.
#1) 이를 통해 팀은 자동화 된 방식으로 서버 및 구성에 대한 변경 사항을 관리 할 수 있으며 오류가 발생할 경우 짧은 시간 내에 신속하게 디버깅 할 수 있으며 고객을 방해하지 않고 이전 버전으로 빠르게 롤백 할 수 있습니다.
#두) 이러한 스크립트는 중앙 서버에 있고 팀의 모든 사람이 각 스크립트에 무엇이 있고 각 버전에서 변경된 사항을 알고 있기 때문입니다. 또한 팀은 최신 버전에 문제가있는 경우 이전 버전으로 돌아갈 수 있습니다.
서버 충돌이 발생하면 수동으로 복원하는 데 시간이 얼마나 걸렸을 지 상상해보십시오. 이제 인프라를 스크립트 및 버전 제어로 정의하여 이전 버전으로 이동하여 즉시 복원 할 수 있습니다.
#삼) 구성을 코드로 관리하면 누군가 실수로 시스템을 변경하는 것을 방지하고 나중에 생산 과정에서 발생하는 손상을 방지 할 수 있습니다.
구성 관리가 완전히 자동화되어 있기 때문에 설정 또는 업데이트를위한 수동 개입이 완전히 제거됩니다.
이전에 사람들이 이러한 구성을 수동으로 수행하기 위해 인적 자원에 의존하고 특정 구성이 누락되거나 필요에 따라 설정되지 않았을 때 비용, 품질 및 시간에 미치는 영향을 상상해보십시오.
따라서 구성 관리 자동화는 시간을 절약 할뿐만 아니라 이러한 인적 오류를 제거하고 품질을 향상시키는데도 도움이되었습니다. 또한 코딩 표준은 팀이 구성 가이드를 작성하는 각 사람의 환상을 따르는 대신 코딩 및 자동화에서 지정된 표준을 따르는 데 도움이되었습니다.
앞에서 설명한 것처럼 코드로 제공되는 구성은 구성 관리자 또는 구성 팀이라고하는 한 사람이나 팀에 대한 종속성을 제거했습니다. 개발 팀은 구성 팀이 와서 인프라 또는 구성 문제를 해결할 때까지 기다릴 필요가 없습니다.
또는 완전히 자동화되고 버전이 제어되는 인프라 및 구성 설정에도 사용할 수 있습니다. 따라서 개발자 또는 테스터 팀의 누구든지 서버를 회전하고 개발 및 테스트 목적을위한 구성을 수행 할 수 있습니다. 따라서 서버 및 구성 설정은 사람이 독립적이되었습니다.
이는 또한 일반적으로 이전의 경우에 사용되는 활동을 위해 개발 및 QA 팀 모두에서 동일한 서버를 사용하지 않도록합니다.
자동화 및 버전 제어와 함께 공통 코드로 정의 된 인프라 및 구성은 모든 환경과 설정을 표준화합니다. 따라서 개발자가 디버깅 작업을 쉽게 수행 할 수있을뿐만 아니라 오류없는 인프라 설정으로 인한 인적 오류를 제거합니다. 그렇지 않으면 조기에 감지하지 않으면 큰 피해를 입힐 수 있습니다.
여기에서 Dev와 Ops 간의 명확한 협업을 확인할 수 있습니다. 두 팀 모두 인프라 설정을 수행하기 위해 단일 소스에 의존하고 두 팀 모두 전체 구성 관리 자동화 및 설정에 적극적으로 참여합니다.
공동 목표를 달성하기 위해 함께 협력하면 팀, 개발 및 운영 간의 협업이 강화됩니다.
구성 드리프트 수정
구성 드리프트 란 무엇입니까?
일정 기간 동안 누적되는 수동 업데이트로 인해 때때로 발생하는 서버 간의 작은 차이와 불일치를 구성 드리프트라고합니다.
이는 좋은 상황이 아닙니다. 서버의 이러한 불일치로 인해 매니페스트, 플레이 북과 같은 특정 프로그램 파일이 모든 서버에서 안정적으로 실행되지 않아 자동화 실패가 발생하기 때문입니다. 따라서 팀이 구성 자동화를 효과적으로 사용하도록하려면이를 피해야합니다.
인프라 및 구성을 코드 및 버전으로 관리하는 것은 팀이 모든 서버에서 구성을 일관되게 유지함으로써 다양한 환경 간 또는 개발 및 프로덕션 설정 간의 모든 종류의 구성 드리프트를 방지하거나 수정하는 데 도움이되었습니다.
따라서 팀은 개발 설정에서 프로덕션 환경과 유사한 구성 설정을 가장 잘 보장 할 수 있습니다. 이는 또한 개발 환경에서 프로덕션 문제를 시뮬레이션하는 데 도움이됩니다.
따라서 이는 팀 구성원이 인프라에서 시도 할 수있는 모든 종류의 예기치 않은 변경을 방지하는 데 도움이됩니다. 저장소에 코드.
인프라와 구성을 코드로 제공함으로써 팀은 고객의 동적 비즈니스 요구를 충족하는 유연한 리소스로 관리 할 수있었습니다.
지금은 일종의 플러그 앤 플레이입니다. 팀은 구체적으로 특정 서버 또는 네트워크에 들어가서 변경할 수 있습니다. 프로비저닝 서버를 업데이트하거나 특정 네트워크에서 스토리지를 추가 또는 수정하거나 OS를 업데이트 할 수도 있으며 모든 것이 유연한 리소스로 독립적으로 업데이트 될 수 있습니다.
이전에는 하나의 구성 매개 변수를 변경하는 데 실제로 많은 시간이 소요되었습니다. 특히 모든 서버에서 업데이트해야했지만 지금은 한 번만 수행하면됩니다. 스크립트를 업데이트하고 버전 관리 도구에 업로드하면 모두 완료됩니다.
기존 인프라를 완전히 폐기하고 다른 인프라를 완전히 가져올 수있는 유연성이 있습니다. 따라서 인프라 및 구성 관리가 이제 매우 쉬워졌습니다. 클라우드 기반 솔루션은 필요에 따라 컴퓨팅 또는 스토리지 리소스를 추가하고 필요하지 않을 때는 축소하여 인프라를 자동으로 확장 할 수있게했습니다.
이를 통해 수요에 따라 리소스 사용을 최적화 할 수 있습니다. 머신의 크기를 늘려 인프라를 확장하려는 경우 즉시 수행 할 수 있습니다. 마찬가지로 확장하거나 다른 설정을 추가하거나 더 많은 프런트 엔드를 추가하려는 경우 코드에서 업데이트하고 자동화 된 파이프 라인을 실행하기 만하면 몇 초 만에이를 수행 할 수 있습니다.
마지막으로 제어 된 환경에서 코드로 제공되는 인프라는 다양한 설정에서 환경의 일관성을 유지하는 데 도움이됩니다. 이는 문제 디버깅에도 도움이됩니다. 이전에 구성 드리프트에 대해 이야기하면서 어느 정도 다룬이 점입니다.
이것으로 DevOps의 구성 관리, 코드로서의 인프라 및 구성과 그 이점에 대한 설명을 마치겠습니다.
다가오는 튜토리얼에서 DevOps의 릴리스 관리 측면.