초보자 가이드: DevOps 파이프라인 생성

DevOps를 처음 접하는 경우 첫 번째 파이프라인 생성을 위한 XNUMX단계 가이드를 살펴보세요.

DevOps는 느리고, 단절되거나 손상된 소프트웨어 개발 프로세스를 수정하기 위한 표준 솔루션이 되었습니다. 문제는 DevOps를 처음 접하고 어디서부터 시작해야 할지 모르는 경우 이러한 기술에 대한 이해가 부족할 수 있다는 것입니다. 이 문서에서는 DevOps 파이프라인의 정의에 대해 논의하고 이를 생성하기 위한 XNUMX단계 지침도 제공합니다. 이 튜토리얼은 완전하지는 않지만 앞으로 여정을 시작하고 지식을 확장할 수 있는 기반을 제공할 것입니다. 하지만 역사부터 시작해보자.

나의 DevOps 여정

저는 이전에 Citi의 클라우드 인프라를 관리하기 위해 IaaS(Infrastructure-as-a-Service) 웹 애플리케이션을 개발하는 Citi Group 클라우드 팀에서 일했지만, 개발 프로세스를 보다 효율적으로 만들고 긍정적인 문화적 변화를 가져오는 방법에 항상 관심이 있었습니다. 개발팀. 저는 Citi의 클라우드 아키텍처 및 인프라 부문 CTO인 Greg Lavender가 추천한 책에서 그 답을 찾았습니다. 그 책의 제목은 The Phoenix Project(피닉스 프로젝트), DevOps의 원리를 설명하지만 소설처럼 읽힙니다.

책 뒷부분의 표는 여러 회사가 릴리스 환경에서 시스템을 배포하는 빈도를 보여줍니다.

아마존: 하루 23
구글: 하루 5
넷플릭스: 하루 500
페이스북 : 하루에 한 번
트위터: 주 3회
일반 회사: 9개월에 한 번

Amazon, Google 및 Netflix 주파수는 어떻게 가능합니까? 이는 이들 회사가 거의 완벽한 DevOps 파이프라인을 생성하는 방법을 알아냈기 때문입니다.

Citi에서 DevOps를 구현하기 전까지는 이와 거리가 멀었습니다. 당시 우리 팀의 환경은 달랐지만 개발 서버에서의 배포는 완전히 수동이었습니다. 모든 개발자는 IBM WebSphere Application Server Community Edition을 기반으로 하는 하나의 개발 서버에만 액세스할 수 있었습니다. 문제는 여러 사용자가 동시에 배포를 시도할 때마다 서버가 종료되는 점이었습니다. 그래서 개발자들이 서로 의도를 전달해야 했기 때문에 꽤 고통스러웠습니다. 또한 낮은 수준의 테스트 코드 적용 범위, 번거로운 수동 배포 프로세스, 특정 작업 또는 사용자 스토리와 관련된 코드 배포를 추적할 수 없다는 문제가 있었습니다.

나는 뭔가를 해야 한다는 것을 깨달았고 같은 생각을 가진 동료를 찾았습니다. 우리는 초기 DevOps 파이프라인 구축에 협력하기로 결정했습니다. 제가 Jenkins 작업을 하고 Atlassian Jira 및 BitBucket을 통합하고 테스트 코드 적용 작업을 하는 동안 그는 Tomcat 가상 머신과 애플리케이션 서버를 설정했습니다. 이 사이드 프로젝트는 매우 성공적이었습니다. 많은 프로세스를 거의 완전히 자동화하고, 개발 서버에서 거의 100% 가동 시간을 달성했으며, 코드 추적 및 향상된 테스트 범위를 제공하고, Git 분기를 Jira 문제 또는 배포에 연결하는 기능을 추가했습니다. DevOps 파이프라인을 구축하는 데 사용한 대부분의 도구는 오픈 소스였습니다.

이제 저는 DevOps 파이프라인이 얼마나 단순했는지 이해합니다. Jenkins 파일이나 Ansible과 같은 확장을 사용하지 않았습니다. 그러나 이 간단한 파이프라인은 파레토 원칙(80/20 규칙이라고도 함)으로 인해 잘 작동했습니다.

DevOps 및 CI/CD 파이프라인에 대한 간략한 소개

여러 사람에게 “DevOps가 무엇인가요?”라고 묻는다면 아마도 여러 가지 다른 대답을 듣게 될 것입니다. Agile과 마찬가지로 DevOps는 다양한 분야에 걸쳐 발전해 왔지만 대부분의 사람들은 몇 가지 사항에 동의할 것입니다. DevOps는 소프트웨어 개발 관행 또는 소프트웨어 개발 수명 주기(SDLC)이며, 그 핵심 원칙은 개발자와 비개발자의 문화를 변화시키는 것입니다. 개발자는 다음과 같은 환경에 존재합니다.

이전에 수동으로 수행되었던 작업이 자동화되었습니다.
모두가 자신이 가장 잘하는 일을 합니다.
일정 기간 동안 구현 횟수가 증가합니다. 처리량이 증가합니다.
개발 유연성이 향상되었습니다.

DevOps 환경을 구축하는 데 올바른 소프트웨어 도구만 필요한 것은 아니지만 일부 도구는 필수적입니다. 핵심 도구는 CI/CD(지속적 통합 및 지속적 배포)입니다. 이 파이프라인에서 환경은 다양한 단계(예: DEV, INT, TST, QA, UAT, STG, PROD)로 구성되어 있으며 많은 작업이 자동화되어 개발자가 고품질 코드를 작성하고 개발 민첩성과 높은 배포 속도를 달성할 수 있습니다.

이 문서에서는 오픈 소스 도구를 사용하여 다음 다이어그램에 표시된 것과 같은 DevOps 파이프라인을 생성하는 XNUMX단계 접근 방식을 설명합니다.

1단계: CI/CD 방법

가장 먼저 필요한 것은 CI/CD 도구입니다. Java 기반의 오픈 소스 도구이자 MIT 라이선스에 따라 라이선스가 부여된 Jenkins는 DevOps를 대중화하고 사실상의 표준이 된 도구입니다.

그렇다면 젠킨스는 무엇인가? 다양한 서비스 및 도구와 대화하고 구성할 수 있는 일종의 마법의 범용 리모콘이라고 생각하세요. Jenkins와 같은 CI/CD 도구는 그 자체로는 쓸모가 없지만, 다른 도구 및 서비스와 연결될수록 더욱 강력해집니다.

Jenkins는 DevOps 파이프라인을 구축하는 데 사용할 수 있는 많은 오픈 소스 CI/CD 도구 중 하나일 뿐입니다.

젠킨스: 크리에이티브 커먼즈와 MIT
트래비스 CI: MIT
크루즈컨트롤:BSD
빌드봇: GPL
아파치 검프: 아파치 2.0
캐비: GNU

CI/CD 도구를 사용한 DevOps 프로세스는 다음과 같습니다.

로컬 호스트에서 CI/CD 도구가 실행되고 있지만 현재로서는 할 수 있는 일이 많지 않습니다. DevOps 여정의 다음 단계로 넘어가겠습니다.

2단계: 소스 제어 시스템 관리

CI/CD 도구가 제 역할을 할 수 있는지 확인하는 가장 좋은(아마도 가장 쉬운) 방법은 SCM(소스 코드 제어) 도구와 통합하는 것입니다. 소스 제어가 필요한 이유는 무엇입니까? 당신이 애플리케이션을 개발하고 있다고 가정해보자. 애플리케이션을 만들 때마다 프로그래밍을 하는 것이며 Java, Python, C++, Go, Ruby, JavaScript 또는 수많은 프로그래밍 언어를 사용하는지 여부는 중요하지 않습니다. 작성한 코드를 소스 코드라고 합니다. 처음에는, 특히 혼자 작업할 때 모든 것을 로컬 디렉토리에 넣어도 괜찮을 것입니다. 그러나 프로젝트 규모가 커지고 다른 사람들을 공동 작업에 초대하면 수정 사항을 효과적으로 공유하면서 충돌을 방지할 수 있는 방법이 필요합니다. 또한 백업을 만들고 복사/붙여넣는 것이 더 이상 사용되지 않기 때문에 이전 버전을 복원할 수 있는 방법도 필요합니다. 당신(그리고 당신의 팀원)에게는 더 나은 것이 필요합니다.

소스 코드 제어가 거의 필수가 되는 곳입니다. 이 도구는 코드를 저장소에 저장하고 버전을 추적하며 프로젝트 참가자의 작업을 조정합니다.

많은 소스 제어 도구가 있지만 Git이 표준이며 당연히 그렇습니다. 원하는 경우 다른 오픈 소스 옵션도 있지만 Git을 사용하는 것이 좋습니다.

힘내: GPLv2 및 LGPL v2.1
전복: 아파치 2.0
동시 버전 시스템(CVS): GNU
베스타: LGPL
머큐리얼: GNU GPL v2+

이는 소스 코드 제어가 추가된 DevOps 파이프라인의 모습입니다.

CI/CD 도구는 검토, 소스 코드 획득 및 구성원 간의 협업 프로세스를 자동화할 수 있습니다. 나쁘지 않다? 하지만 수십억 명의 사람들이 사용하고 감상할 수 있도록 어떻게 작동하는 애플리케이션으로 전환할 수 있을까요?

3단계: 빌드 자동화 도구 생성

엄청난! 코드를 검토하고 소스 제어를 변경할 수 있으며 친구를 초대하여 개발에 협력할 수 있습니다. 하지만 아직 애플리케이션을 만들지 않았습니다. 웹 애플리케이션을 만들려면 배포 가능한 배치 형식으로 컴파일하고 패키지하거나 실행 파일로 실행해야 합니다. (JavaScript나 PHP와 같은 해석된 프로그래밍 언어는 컴파일할 필요가 없습니다.)

빌드 자동화 도구를 사용하세요. 어떤 빌드 자동화 도구를 사용하기로 결정했는지에 관계없이 모두 동일한 목표를 가지고 있습니다. 즉, 소스 코드를 원하는 형식으로 빌드하고 정리, 컴파일, 테스트 및 특정 환경에 배포 작업을 자동화하는 것입니다. 빌드 도구는 프로그래밍 언어에 따라 다르지만 다음은 몇 가지 일반적인 오픈 소스 옵션입니다.

이름
라이센스
프로그래밍 언어

메이븐
아파치 2.0
자바

개미
아파치 2.0
자바

요람
아파치 2.0
자바

Bazel
아파치 2.0
자바

확인
GNU
해당 사항 없음

툴툴 거리는 소리
MIT
자바 스크립트

꿀꺽 꿀꺽 마시다
MIT
자바 스크립트

빌더
아파치
루비

갈퀴
MIT
루비

AAP
GNU
Python

SC콘
MIT
Python

비트베이크
GPLv2
Python

케이크
MIT
C#

ASDF
국외 거주자 (MIT)
리스프

카발
BSD
하스켈

엄청난! 빌드 자동화 도구 구성 파일을 소스 제어 시스템에 넣고 CI/CD 도구가 모든 것을 통합하도록 할 수 있습니다.

모든 것이 괜찮지 않나요? 하지만 애플리케이션을 어디에 배포해야 할까요?

4단계: 웹 애플리케이션 서버

지금은 실행 가능하거나 설치 가능한 패키지 파일이 있습니다. 모든 애플리케이션이 진정으로 유용하려면 일종의 서비스나 인터페이스를 제공해야 하지만 애플리케이션을 호스팅할 컨테이너가 필요합니다.

웹 애플리케이션 서버는 바로 그러한 컨테이너입니다. 서버는 배포되는 패키지의 논리를 정의할 수 있는 환경을 제공합니다. 서버는 또한 인터페이스를 제공하고 소켓을 외부에 노출시켜 웹 서비스를 제공합니다. 이를 설치하려면 HTTP 서버와 일부 환경(예: 가상 머신)이 필요합니다. 지금은 이에 대해 더 자세히 알게 될 것이라고 가정하겠습니다(아래에서 컨테이너에 대해 다루겠습니다).

여러 오픈 소스 웹 애플리케이션 서버가 있습니다.

이름
라이센스
프로그래밍 언어

여자 꽁무니를 쫓아 다니다
아파치 2.0
자바

흑 옥의
아파치 2.0
자바

와일드 플라이
GNU 약소 공개
자바

유리고기
CDDL 및 GNU 덜 공개
자바

장고
3절 BSD
Python

폭풍
아파치 2.0
Python

구니콘
MIT
Python

Python
MIT
Python

울타리
MIT
루비

Node.js를
MIT
자바 스크립트

DevOps 파이프라인을 사용할 준비가 거의 완료되었습니다. 잘했어요!

여기서 멈추고 통합을 직접 처리할 수 있지만 코드 품질은 앱 개발자가 걱정해야 할 중요한 사항입니다.

5단계: 코드 테스트 범위

테스트 구현은 또 다른 번거로운 요구 사항일 수 있지만 개발자는 애플리케이션의 버그를 조기에 파악하고 코드 품질을 개선하여 최종 사용자가 만족할 수 있도록 해야 합니다. 다행히도 코드를 테스트하고 품질 개선을 위한 권장 사항을 제공하는 오픈 소스 도구가 많이 있습니다. 더 좋은 점은 대부분의 CI/CD 도구가 이러한 도구에 연결되어 프로세스를 자동화할 수 있다는 것입니다.

코드 테스트는 테스트를 작성하고 실행하는 데 도움이 되는 코드 테스트 프레임워크와 코드 품질을 향상시키는 데 도움이 되는 제안 도구라는 두 부분으로 구성됩니다.

코드 테스트 시스템

이름
라이센스
프로그래밍 언어

JUnit
Eclipse Public License
자바

EasyMock
아파치
자바

모키 토
MIT
자바

파워목
아파치 2.0
자바

파이테스트
MIT
Python

가설
모질라
Python

독극물
MIT
Python

코드 개선을 위한 추천 시스템

이름
라이센스
프로그래밍 언어

적용 범위
GNU
자바

코드커버
이클립스 퍼블릭(EPL)
자바

Coverage.py
아파치 2.0
Python

엠마
공통 공중 라이선스
자바

자코코
Eclipse Public License
자바

가설
모질라
Python

독극물
MIT
Python

재스민 속
MIT
자바 스크립트

업
MIT
자바 스크립트

모카
MIT
자바 스크립트

농담
MIT
자바 스크립트

위에서 언급한 대부분의 도구와 프레임워크는 Java, Python 및 JavaScript용으로 작성되었습니다. 왜냐하면 C++ 및 C#은 독점 프로그래밍 언어이기 때문입니다(GCC는 오픈 소스임에도 불구하고).

이제 테스트 적용 범위 도구를 구현했으므로 DevOps 파이프라인은 이 튜토리얼의 시작 부분에 표시된 다이어그램과 유사하게 보일 것입니다.

추가 단계

컨테이너

앞서 말했듯이 가상 머신이나 서버에서 서버를 호스팅할 수 있지만 컨테이너가 널리 사용되는 솔루션입니다.

컨테이너란 무엇입니까? 간단히 설명하면 가상 머신에는 애플리케이션 크기를 초과하는 엄청난 양의 운영 체제 메모리가 필요한 반면, 컨테이너에는 애플리케이션을 실행하는 데 몇 가지 라이브러리와 구성만 필요하다는 것입니다. 분명히 가상 머신의 중요한 용도는 여전히 있지만 컨테이너는 애플리케이션 서버를 포함하여 애플리케이션을 호스팅하기 위한 경량 솔루션입니다.

다른 컨테이너 옵션도 있지만 가장 인기 있는 것은 Docker와 Kubernetes입니다.

도커: 아파치 2.0
쿠버네티스: 아파치 2.0

중간 자동화 도구

DevOps 파이프라인은 주로 협업 애플리케이션 생성 및 배포에 중점을 두고 있지만 DevOps 도구를 사용하여 수행할 수 있는 다른 작업도 많이 있습니다. 그 중 하나는 미들웨어 자동화 도구라고도 알려진 IaC(Infrastructure as Code) 도구를 사용하는 것입니다. 이러한 도구는 미들웨어의 설치, 관리 및 기타 작업을 자동화하는 데 도움이 됩니다. 예를 들어 자동화 도구는 웹 애플리케이션 서버, 데이터베이스, 모니터링 도구와 같은 애플리케이션을 올바른 구성으로 추출하여 애플리케이션 서버에 배포할 수 있습니다.

다음은 몇 가지 오픈 소스 미들웨어 자동화 도구입니다.

Ansible: GNU 퍼블릭
솔트스택: 아파치 2.0
셰프: 아파치 2.0
꼭두각시: Apache 또는 GPL

SkillFactory에서 유료 온라인 강좌를 수강하여 원하는 직업을 처음부터 구하거나 기술 및 급여 측면에서 레벨 업하는 방법에 대한 자세한 내용을 알아보세요.

• DevOps 과정 (12개월)

더 많은 강좌

• 기계 학습 과정 (12주)
• 처음부터 데이터 과학 직업 교육 (12개월)
• 모든 시작 수준의 분석가 직업 (9개월)
• 웹 개발 과정을 위한 Python (9개월)

유용한

• 450개의 무료 아이비 리그 과정
• 2020년 데이터 과학 동향
• 데이터 과학은 죽었습니다. 비즈니스 과학 만세
• 스테로이드에 대한 데이터 과학: 의사결정 인텔리전스 소개
• 가장 성공적이고 가장 추악한 데이터 과학 프로젝트: Cambridge Analytica

출처 : habr.com