관리 메뉴

IT & Life

[해외] devops 도구를 사용하여 소프트웨어 제공을 가속화하는 방법 본문

프로그래밍

[해외] devops 도구를 사용하여 소프트웨어 제공을 가속화하는 방법

미운앙마 2017. 12. 7. 01:29

https://www.infoworld.com/article/3219305/devops/how-devops-tools-accelerate-software-delivery.html?nsdr=true

 

 

devops 도구를 사용하여 소프트웨어 제공을 가속화하는 방법
Devops는 약간의 철학과 많은 도구입니다. 이 도구들이 devop 마법을 작동시키는 방법은 다음과 같습니다.

 


옛날에는 데이터베이스에 대해 코드를 작성해야하는 개발자가있었습니다. 그래서 그는 데이터베이스 관리자에게 프로덕션 데이터베이스에 대한 액세스를 요청했습니다.

 

"오, 이런, 안돼."DBA가 말했다. "당신은 우리의 데이터를 만질 수 없다. 자신의 데이터베이스가 필요합니다. 작전에 물어보십시오. "

 

"오, 이런, 안돼."작전 관리자가 말했다. "우리에게는 여분의 오라클 라이센스가 없으며, 오라클 라이센스를 실행하는 서버와 서버를 확보하는 데 6 개월이 걸릴 것입니다. 그러나 나는 할 수있는 일을 할 것 "이라고 말했다.


이것이 어디로 가는지 볼 수 있습니다. 각 답변 후에도 "bwahaha"라는 소리를들을 수 있습니다. 물론 DBA와 운영 관리자는 일을하고 있지만 개발자와 비즈니스 요구는 느린 차선에 머물러 있습니다.

 

개발자가 올바른 운영 체제, 올바른 데이터베이스, 올바른 테이블 및 인덱스 스키마 및 구문 적으로 유효한 테스트 데이터의 평가판으로 이미 구성된 가상 컴퓨터를 회전시킬 수 있다면 어떻게 될까요? 그리고이 모든 일이 설정 파일과 스크립트의 제어하에 일어나서 커피 한 잔을 마시고 마신다면 어떻게 될까요? "기민한"것이 얼마나 될까요?

 

devops를 입력하십시오. 기본적으로 devops는 대답을 "아니오"로 만드는 데 사용되는 요청을 자동화하는 도구를 제공합니다. 개발자는 자신의 직업을 얻기 위해 필요한 것을 얻으며, 운영은 너무 많은 문제없이 거래가 끝날 때까지 기다릴 수 있습니다. 이러한 도구는 코딩에서 통합, 배포, 모니터링, 버그보고에 이르기까지 소프트웨어 개발 라이프 사이클의 각 단계를 지원하는 세트로 나눌 수 있습니다.

 

개발자 도구

 

개발자에게는 일하는 삶이 개발 환경을 중심으로 돌아갑니다. 여기에는 통합되거나 독립적 인 도구의 선택 일 수있는 몇 가지 요소가 있습니다.

기존 코드는 Git 또는 Team Foundation Server (TFS)와 같은 저장소에 있으며 개발자의 첫 번째 작업은 매일 (기민한 조직이 우선적으로 개최하는 매일의 스탠딩 미팅 후) 모든 코드를 체크 아웃하거나 복제하는 것입니다. 공유 저장소에서 관심있는 항목. 이상적인 세계에서, 다른 사람의 체크 인이나 푸시는 개발자 코드에 영향을 미치지 않습니다. 왜냐하면 모든 사람의 코드가 이미 병합되고, 통합되고, 테스트되기 때문입니다. 현실 세계에서는 항상 그런 것은 아니며, 어제의 변경 사항을 병합, 통합 및 테스트하는 것이 비즈니스의 두 번째 순서 일 수 있습니다.

이상적인 세상에서 모든 코드는 완벽 할 것입니다. 실제 세계에서는 완벽한 코드와 같은 것이 존재하지 않습니다. 가장 가까운 곳은 알려진 버그가없는 코드입니다.

 

개발자의 관점에서 결함 관리자 (Bugzilla, JIRA, Redmine, TFS 또는 기타 추적기 일 수 있음)를보고 "티켓"(버그 보고서 또는 작업 할당)을 처리하는 것은 다음 비즈니스 순서입니다.

 

이클립스 나 비주얼 스튜디오와 같은 IDE는 종종 결함 관리자 또는 더 깊은 관계에있는 윈도우를 가지고 있지만 최소한 개발자는 브라우저 탭을 열어 티켓을 볼 수 있습니다. 개발자는 어제의 프로젝트를 계속 진행하거나 더 높은 우선 순위의 티켓이 있으면 처리합니다. 마찬가지로 IDE는 리포지토리와 긴밀하게 통합되지만 개발자는 체크 인 및 체크 아웃을 위해 명령 줄 콘솔을 열어야합니다. 삼각형을 완성하기 위해 버그 추적기는 종종 소스 코드 저장소와 통합됩니다.

 

코드 편집기는 대개 IDE의 핵심 구성 요소입니다. devops 목적을위한 최고의 코드 편집기는 검사중인 코드의 저장소 상태를 보여주기 때문에 오래된 소스 코드를보고 있다면 즉시 알 수 있습니다. 또한 병합 충돌을 도입하기 전에 복사본을 새로 고칩니다.

 

개발자의 빌드 도구는 작성중인 프로그래밍 언어에 따라 다르지만 컴파일 된 언어의 경우 개발자는 IDE에서 빌드를 시작하고 편집 목적으로 오류 및 경고를 캡처 할 수 있기를 원합니다. 또한 코드 편집기가 언어 구문을 알고 있으면 코딩 중에 백그라운드에서 오류를 표시하고 색상을 사용하여 구문을 강조 표시하여 개발자가 예를 들어 무엇을 이름으로 의도했는지 시각적으로 확인할 수 있도록 도와줍니다. 이미 정의 된 변수가 정확합니다.

 

개발자가 코드를 작성하고 테스트 할 때 디버거를 실행하는 데 대부분의 시간을 소비합니다. 그들이 devop을 구현 한 조직에 있으면 실제 환경을 충실히 반영한 가상화 환경에서 디버깅을 할 수 있습니다. 이 기능이 없으면 개발자는 서버 작업을 표현하기 위해 스텁 코드를 사용하거나 원격 데이터베이스를 위해 로컬 데이터베이스를 사용해야 할 수 있습니다.

 

테스트 주자는 개발자가 단위 테스트 및 회귀 테스트를 쉽고 정기적으로 실행할 수 있도록 도와줍니다. 이상적으로 테스트 프레임 워크는 IDE 및 모든 로컬 리포지토리와 통합되므로 체크인 후 즉시 새 코드를 테스트 할 수 있으며 개발자는 디자인을 염두에 두어야합니다. 개발자의 테스트는 개발자가 디버깅하고 테스트 한 소스 코드와 함께 공유 저장소를 통해 코드 통합 환경으로 이동해야합니다.

 


코드 통합 도구

 

코드 통합 도구는 공유 저장소에서 코드를 가져 와서 빌드하고 테스트하고 결과를보고합니다. 이는 자동화 된 빌드 도구, 자동화 된 테스트 실행기, 전자 메일 및 결함 관리자를 통한 자동보고 및 리포지토리에 대한 작업에 연결되는 Jenkins와 같은 연속 통합 서버를 사용하여 수행됩니다.

 

예를 들어 빌드가 성공하고 모든 테스트가 통과되면 현재 소스 코드와 빌드 된 라이브러리 및 실행 파일을 모두 리포지토리의 현재 빌드 번호로 태그 할 수 있습니다. 치명적 테스트가 실패하면 관련 체크 인을 공유 리포지토리에서 제외하고 버그 수정을 위해 책임 개발자에게 반환 할 수 있습니다.

 

일부 프로젝트는 증분 빌드 시간이 작은 경우 모든 코드 푸시에 대해 지속적인 통합을 구현합니다. 다른 프로젝트에서는 코드 푸시 후에 지연이 발생하여 여러 푸시를 다음 빌드로 결합 할 수 있습니다. 자동 빌드 및 테스트를 사용하는지 여부와 상관없이 대부분의 프로젝트는 코드 푸시 후 또는 필요에 따라 하루 종일 통합되는지 여부와 같이 새롭게 프로비저닝 된 테스트 환경에서 야간 "클린"빌드 및 테스트를 실행합니다.

 


배포 도구 및 환경


 

빌드를 전개하도록 연속 통합 서버를 설정하면 모든 테스트를 통과 한 후에 소프트웨어 전개 및 구성 관리 도구에 의존하게됩니다. 이들은 종종 런타임 플랫폼과 추가 인프라에 따라 달라집니다.

 

반면에 Anabilities, Chef, Puppet, Salt 및 Vagrant와 같은 일부 구성 관리 도구는 널리 지원되는 언어를 사용하여 다양한 플랫폼에서 작동합니다. Ansible과 Salt는 Python 기반 시스템입니다. Chef, Puppet 및 Vagrant는 Ruby 기반입니다.

 

Anabilities는 YAML에서 조리법을 사용하고 SSH를 통해 노드를 관리합니다. 요리사는 Ruby 도메인 별 언어를 사용하여 구성 레시피를 작성하고 Erlang 서버는 물론 Ruby 클라이언트를 사용합니다.

 

Puppet은 사용자 정의 선언 언어를 사용하여 시스템 구성을 설명합니다. Puppet은 대개 시스템 구성을 위해 에이전트 / 마스터 아키텍처를 사용하지만 독립형 아키텍처에서도 실행될 수 있습니다. 퍼핏 포지에는 2,500 개 이상의 미리 정의 된 모듈이 있습니다.

 

원래 원격 서버 관리 도구 인 Salt는 수상 경력이있는 오픈 소스, 클라우드 기반의 구성 관리 및 원격 실행 응용 프로그램으로 발전했습니다. Salt는 Linux, Unix, Windows 및 MacOS 시스템을 관리 및 배포 할 수 있으며 여러 클라우드에서 자원을 조율 할 수 있습니다. Vagrant는 VirtualBox, VMware 및 기타 가상 시스템 관리자를위한 래퍼 역할을하는 개발 환경을위한 특수한 구성 관리 도구입니다. Vagrant는 구성에 종속적 인 버그를 재현하는 과정에서 벗어납니다.

 

PaaS (서비스 형 플랫폼)는 클라우드 생태계에서 흥미로운 틈새 시장을 차지합니다. 기본적으로 IaaS (서비스로서의 인프라) 위에 위치하는 개발, 테스트 및 배포 플랫폼입니다. PaaS는 구내에 배치하거나 공용 클라우드 제공 업체에 의해 서비스로 제공 될 수 있습니다. 예를 들어 Pivotal Cloud Foundry PaaS는 VMware의 사설 클라우드 버전 위에 설치하거나 Amazon EC2와 같은 공용 IaaS 클라우드에서 실행할 수 있습니다.

 

PaaS는 인프라, 스토리지, 데이터베이스, 정보 및 프로세스를 서비스로 포함합니다. PaaS는 컴퓨터, 디스크, 데이터베이스, 정보 스트림 및 비즈니스 프로세스 또는 메타 응용 프로그램을 하나의 "스택"또는 "샌드 박스"에 모두 묶어 놓은 것으로 생각하십시오. PaaS가 IaaS를 능가하는 곳이 있다면 IaaS의 모든 프로비저닝을 자동화하는 것입니다. 리소스 및 응용 프로그램을 사용하면 엄청난 시간을 절약 할 수 있습니다.

 

두 종류의 VM이 있습니다 : VM과 같은 시스템 VM과 Java 가상 머신과 같은 프로세스 VM입니다. 배포 도구의 목적을 위해 Cloud Foundry와 같은 PaaS 또는 PostgreSQL과 같은 서버 응용 프로그램을 배포 할 수있는 시스템 VM에 관심이 있습니다. VM을 사내 구축 형 또는 오프 - 프레미스 전용 또는 IaaS 클라우드 전용 서버 하드웨어에 배치 할 수 있습니다. 시스템 VM은 탁월한 소프트웨어 격리 기능을 제공하지만 일부 하이퍼 바이저 오버 헤드가 발생하고 많은 RAM을 사용합니다. 다양한 하이퍼 바이저 및 IaaS 인프라는 부하 격리와 VM을 필요로하는 VM에 과도한 CPU 용량 할당을위한 다양한 알고리즘을 제공합니다.

 

Docker와 같은 소프트웨어 컨테이너는 VM보다 훨씬 적은 오버 헤드로 대부분의 경우 충분한 소프트웨어 분리를 제공합니다. 필자가 익숙한 모든 PaaS 시스템은 소프트웨어 컨테이너에서 응용 프로그램을 포장합니다. 예를 들어, OpenShift는 기어라는 컨테이너에서 응용 프로그램을 실행하고 SELinux를 사용하여 기어를 격리했습니다. 현재 Docker를 기본 컨테이너 형식 및 런타임으로 사용합니다. 마찬가지로 Cloud Foundry는 Warden Linux 컨테이너에서 응용 프로그램을 실행하는 데 사용되었지만 Open Container Initiative 사양을 준수하는 Docker 및 기타 컨테이너를 지원하는 Diego라는 새로운 컨테이너 관리 시스템을 도입했습니다.

 

반면 Docker는 PaaS 시스템과 독립적으로 작업 할 수 있으므로 devop의 배포를 크게 단순화 할 수 있습니다. Docker는 여러 대의 클라우드를 하나의 큰 머신처럼 보이게 할 수 있으며 빌드 자동화, 지속적인 통합, 테스트 및 기타 devops 작업에 사용될 수 있습니다. Docker는 Linux 전용 솔루션으로 시작되었지만 최근에는 Windows에 대한 지원도받습니다.

 

소프트웨어 라이프 사이클의 대대적 인 계획에서 각 기능은 설계에서 개발, 테스트, 생산 단계로 이동하는 반면 버그 보고서는 각 단계에서 분류 및 수정을 위해 개발자에게 피드백을 제공합니다. 매년 출시되는 제품의 경우 한 단계에서 다른 단계로 이동하는 것이 수동 프로세스가 될 수 있습니다. 매주 또는 격주로 출시되는 민첩한 제품의 경우 릴리스 관리가 종종 자동화됩니다. 자동화해야 할 부분 중 하나는 릴리스 프로세스 관리입니다. 또한 팀은 테스트, 버그 추적, 빌드, 패키징, 구성 및 승격 프로세스를 자동화해야합니다.

 

런타임 모니터링 도구

 

제품에 대한 수락 테스트에는 대개 성능 테스트가 포함되며 현실적인 사용자 프로필로 전면적 인 부하 테스트까지 진행될 수 있습니다. 그렇더라도 사용 환경의 급증, 시간이 지남에 따라 나타나는 메모리 누수, 디스크의 불량 지점, 과부하 된 서버 또는 업데이트 속도를 저하시키는 불완전한 데이터베이스 인덱스 등의 이유로 응용 프로그램 성능이 실제 환경에서 변경 될 수 있습니다.

 

응용 프로그램 성능 모니터링은 응용 프로그램에서 중요한 핵심 성과 지표에 대한 메트릭을 지속적으로 작성하기위한 것입니다. 이들은 일반적으로 페이지를 보거나 트랜잭션을 완료하는 시간 및 CPU 및 메모리 사용과 같은 시스템 메트릭과 같은 사용자 메트릭으로 분류됩니다. 일반적으로 시스템 메트릭은 항상 사용 가능합니다. 네트워크 모니터링 장비를 사용하여 수집되는 수동 사용자 메트릭은 응용 프로그램이 많이 사용되는 경우 가장 중요합니다. 응용 프로그램 요청을 생성하고 응답 시간을 측정하여 수집 한 활성 사용자 메트릭은 종종 비 첨두 부하 기간 동안 예약됩니다.

 

응용 프로그램이 원하는대로 수행되지 않을 때 근본 원인을 파악하는 것은 실망스럽고 시간이 많이 소요되는 프로세스 일 수 있습니다. 최근까지 근본 원인 분석을 돕기위한 DDCM (심층 다이브 모니터링) 에이전트는 생산에 너무 많은 오버 헤드를 발생 시켰습니다. 문제를 파악하기 위해 잠시 동안 전원을 켜야 만하고, 전원을 끄면 전체 용량으로 생산을 재개 할 수 있습니다. 그러나 지난 몇 년 동안 시장에 나와있는 새로운 DDCM 제품은 최소한의 오버 헤드로 다양한 언어 및 프레임 워크를 모니터링하여 근본 원인 분석 프로세스를 간소화 할 수 있다고 주장합니다.

 

버그보고 및 재생 도구

 

우리는 결함 관리자를 일찍 언급했지만 실제로 사용법을 자세히 설명하지는 않았습니다. 가장 좋은 경우보고 된 결함에는 자세한 설명, 근본 원인, 문제를 재현하는 스크립트가 수반되며 관련 코드를 가장 잘 알고있는 개발자에게 할당됩니다. 최악의 경우 버그 리포트는 좌절 된 사용자가 기술 지원을 요청하고 다음 행을 따라 대화를 포함합니다.

 

기술 지원 : 무엇이 잘못 되었나요?
사용자 : 그것은 망 쳤다.
기술 지원 : 뭐하고 있었 니?
사용자 : 내가 항상하는 일. 그것은 어제 일했습니다.
기술 지원 : 어제부터 변경된 사항이 있습니까?
사용자 : 아무것도 변경하지 않았다.


말할 필요도없이 그러한 보고서는 개발자가 문제를 해결할 수 있도록 기술 지원 부서에서 충분한 설명과 문제를 재현 할 수있는 단계를 찾아내는 기술이 필요합니다. 또한 사용자 컴퓨터에 진단을 원격으로 입력하고 실행해야 할 수도 있습니다.

 

때로는 이러한 문제가 개발자의 컴퓨터에서 재현되지 않습니다. 한 가지 일반적인 이유는 개발 상자가 너무 빠르며 문제를 표시하기에는 너무 많은 메모리가 있다는 것입니다. 또 다른 가능성은 개발자가 사용자가 부족한 라이브러리를 설치했다는 것입니다. 세 번째는 사용자가 다른 애플리케이션을 설치하여 사용자의 작업을 방해한다는 것입니다.

 

사용자의 런타임 환경을 결정하면 개발자는 구성 관리 도구를 사용하여 VM에서 유사한 런타임 환경을 만들 수 있습니다. 특히, 방랑제는 그러한 목적으로 사용됩니다. 테스트 VM은 개발자의 컴퓨터, 서버 또는 IaaS 클라우드에서 로컬로 실행할 수 있습니다.

 

경우에 따라 사용자의 문제를 재현하는 단계로 인해 프로덕션 데이터베이스가 변경됩니다. 이러한 상황에서는 PaaS에서 실행중인 프로덕션 응용 프로그램의 축소 된 복사본을 만들어 변경 내용을 프로덕션 환경으로 전파하지 않는 것이 유용합니다.

 

문제점에 대한 수정 사항이 식별되고 변경 사항 세트가 코드 저장소에 추가되면 수정 된 어플리케이션은 적어도 회귀 테스트되어야하며 모든 승인 테스트가 실행되는 것이 바람직합니다. 변경 사항이 승인되면 릴리스 관리자 또는 고객 서비스 관리자는 변경 내용을 프로덕션에 전파할지 또는 나중에 통합 할 것인지 또는 사용자에게 패치 또는 작동 가능한 해결 방법을 제공할지 여부를 결정해야합니다.

 

끝이없는 서클

 

휠체어에 바퀴가 달린 마차에 대한 에스겔의 비전처럼 현대의 민첩한 애플리케이션 라이프 사이클이 약간 들리면 괜찮습니다. 하나의 휠 세트는 스프린트를 나타냅니다. 일반적으로 1 주에서 2 주 정도 소요되며, 그 후 응용 프로그램 버전이 개발 단계에서 테스트 단계로 릴리스됩니다. 또 하나의 휠 세트는 개발에서부터 테스트 단계, 생산 단계에 이르기까지 주어진 빌드의 상승을 나타냅니다. 내부 휠 세트는 스토리 카드 또는 응용 프로그램 기능의 수명주기를 나타냅니다. 가장 작은 바퀴는 버그보고 및 수정을 나타냅니다.

 

이 복잡한 환경에서 개발 숍은 어느 단계에서든 쉽게 어려움을 겪을 수 있습니다. Devop의 목적은 개발자가 실제 기능을 빌드하고 실제 버그를 수정하는 데 집중할 수 있도록 깨끗한 ​​테스트 데이터베이스를 가져 오거나 빌드를 승격하는 것과 같은 일상적인 작업이 빠르고 쉽다는 것을 확인하는 것입니다.

Comments