brunch

You can make anything
by writing

C.S.Lewis

by 이종우 Peter Lee May 13. 2020

[번역]open source 사용 DevOps 구축서

초보자를 위한 안내서

원복 URL :  https://medium.com/@bryantjiminson/devops-has-become-the-default-answer-to-fixing-software-development-processes-that-are-slow-70ea6df015fc




DevOps는 느리거나 사일로 또는 기능 장애가있는 소프트웨어 개발 프로세스를 수정하기위한 기본 답변이되었습니다. 그러나 DevOps를 처음 사용하고 어디서부터 시작해야할지 확실하지 않은 경우에는 큰 의미가 없습니다. 이 기사에서는 DevOps 파이프 라인이 무엇인지 살펴보고 5 단계 프로세스를 제공합니다. 이 튜토리얼은 포괄적 인 것은 아니지만 나중에 시작하고 확장 할 수있는 기초를 제공해야합니다. 


내 DevOps 여행


Citi 그룹의 클라우드 팀에서 근무하면서 Citi의 클라우드 인프라를 관리하기위한 IaaS (Infrastructure-as-a-Service) 웹 애플리케이션을 개발했지만, 개발 파이프 라인을보다 효율적으로 만들고 구현하는 방법을 찾는 데 항상 관심이있었습니다. 개발팀에 긍정적 인 문화 변화. Citi의 클라우드 아키텍처 및 인프라 엔지니어링 CTO 인 Greg Lavender가 추천 한 책에서 The Phoenix Project https://www.amazon.com/dp/B078Y98RG8/ 라는 제목의 답변을 찾았습니다 . 이 책은 DevOps 원칙을 설명하는 동안 소설처럼 읽습니다.


이 책의 뒷면에있는 표는 여러 회사가 릴리스 환경에 배포하는 빈도를 보여줍니다.            


다른 회사의 DevOP 배포


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


Citi에서 DevOps를 구현하기 전에는 그렇지 않았습니다. 당시에는 팀 환경이 달라졌지만 개발 서버에 대한 배포는 매우 수동적이었습니다. 모든 개발자는 IBM WebSphere Application Server Community Edition을 기반으로 한 개발 서버에 액세스 할 수있었습니다. 문제는 여러 사용자가 동시에 배포를 시도 할 때마다 서버가 다운되어 개발자가 배포를 할 때마다 서로에게 알려야한다는 것이 문제였습니다. 또한 낮은 코드 테스트 적용 범위, 번거로운 수동 배포 프로세스 및 정의 된 작업 또는 사용자 스토리로 코드 배포를 추적 할 수있는 방법에 문제가있었습니다.


나는 무언가 해야한다는 것을 깨달았고 같은 느낌을 가진 동료를 찾았습니다. 우리는 초기 DevOps 파이프 라인을 구축하기 위해 협력하기로 결정했습니다. Jenkins에서 작업하면서 Atlassian Jira 및 BitBucket과 통합하고 코드 테스트 범위를 가상 머신과 Tomcat 애플리케이션 서버를 설정했습니다. 이 측면 프로젝트는 매우 성공적이었습니다. 개발 파이프 라인을 거의 완전히 자동화하고 개발 서버에서 거의 100 % 가동 시간을 달성했으며 코드 테스트 범위를 추적 및 개선 할 수 있었으며 Git 지점은 배포 및 Jira 작업과 관련 될 수있었습니다. 그리고 DevOps 파이프 라인을 구성하는 데 사용했던 대부분의 도구는 오픈 소스였습니다. 


Jenkins 파일 또는 Ansible과 같은 고급 구성을 활용하지 않았으므로 이제 DevOps 파이프 라인이 얼마나 기초적인지 알게되었습니다. 그러나이 간단한 프로세스는 파레토 원칙 https://en.wikipedia.org/wiki/Pareto_principle (80/20 규칙이라고도 함)으로 인해 제대로 작동했습니다.



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


여러 사람에게“DevOps 란 무엇입니까? 아마 몇 가지 다른 답변을 얻을 것입니다. 애자일과 같은 DevOps는 여러 분야를 포괄하도록 발전했지만 대부분의 사람들은 몇 가지 사항에 동의합니다. DevOps는 소프트웨어 개발 관행 또는 SDLC (Software Development Lifecycle)이며 개발자와 비 개발자는 모두 수동 작업이 자동화 된 환경에서 호흡합니다. 모두가 자신이 가장 잘하는 일을합니다. 기간 당 배치 수가 증가합니다. 처리량 증가; 유연성이 향상됩니다.


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


이 기사에서는 오픈 소스 도구를 사용하여 다음 다이어그램과 같은 DevOps 파이프 라인을 작성하는 5 단계 접근 방법에 대해 설명합니다.      



더 이상 고민하지 말고 시작합시다


1 단계 : CI / CD 프레임 워크

가장 먼저 필요한 것은 CI / CD 도구입니다. MIT 라이센스를 기반으로하는 오픈 소스 Java 기반 CI / CD 도구 인 Jenkins는 DevOps 이동을 대중화하고 사실상 표준이 된 도구입니다.


젠킨스는 무엇입니까? 많은 다른 서비스 및 도구와 대화하고 조정할 수있는 일종의 마법의 범용 리모콘이라고 상상해보십시오. Jenkins와 같은 CI / CD 도구는 그 자체로 쓸모가 없지만 다른 도구와 서비스에 연결하면 더욱 강력 해집니다.


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


젠킨스 https://github.com/jenkinsci/jenkins

트래비스 CI https://github.com/travis-ci/travis-ci

크루즈 컨트롤 http://cruisecontrol.sourceforge.net/

BuildBot https://github.com/buildbot/buildbot

아파치 검프 https://gump.apache.org/

카비 http://cabie.tigris.org/


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



로컬 호스트에서 CI / CD 도구를 실행하고 있지만 현재 할 수있는 일은 많지 않습니다. DevOps 여정의 다음 단계를 따르십시오.


2 단계 : 소스 제어 관리

CI / CD 도구가 마법을 수행 할 수 있는지 확인하는 가장 좋은 방법은 아마도 소스 제어 관리 (SCM) 도구와 통합하는 것입니다. 왜 소스 컨트롤이 필요합니까? 응용 프로그램을 개발한다고 가정하십시오. 응용 프로그램을 작성할 때마다 Java, Python, C ++, Go, Ruby, JavaScript 또는 Gazillion 프로그래밍 언어를 사용하는지 여부에 관계없이 프로그래밍 중입니다. 작성한 프로그래밍 코드를 소스 코드라고합니다. 처음에는 특히 혼자 일할 때 모든 것을 로컬 디렉토리에 넣는 것이 좋습니다. 그러나 프로젝트가 커지고 다른 사람들이 공동 작업하도록 초대하면 코드 수정을 효과적으로 공유하면서 병합 충돌을 피할 수있는 방법이 필요합니다. 또한 이전 버전을 복구 할 수있는 방법이 필요합니다. 백업 및 복사 및 붙여 넣기 과정이 오래되었습니다. 당신과 당신의 팀원들은 더 나은 것을 원합니다.


이것은 SCM이 거의 필요한 곳입니다. SCM 도구는 코드를 리포지토리에 저장하고 코드를 버전 관리하며 프로젝트 멤버간에 조정함으로써 도움이됩니다.


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


Git 

Subversion

Concurrent Versions System (CVS)

Vesta

Mercurial


다음은 SCM을 추가 한 DevOps 파이프 라인의 모습입니다.      



CI / CD 도구는 소스 코드 체크인 및 체크 아웃 및 멤버 간 협업 작업을 자동화 할 수 있습니다. 나쁘지 않다? 그러나 어떻게 이것을 수십억의 사람들이 사용하고 평가할 수 있도록 작동하는 응용 프로그램으로 만들 수 있습니까?



3 단계 : 자동화 도구 구축


우수한! 코드를 확인하고 변경 사항을 소스 컨트롤에 적용하고 친구를 소스 컨트롤 개발에 협력하도록 초대 할 수 있습니다. 그러나 아직 애플리케이션을 구축하지 않았습니다. 웹 응용 프로그램으로 만들려면 컴파일하여 배포 가능한 패키지 형식으로 만들거나 실행 파일로 실행해야합니다. (JavaScript 또는 PHP와 같은 해석 된 프로그래밍 언어는 컴파일 할 필요가 없습니다.)


빌드 자동화 도구를 입력하십시오. 어떤 빌드 도구를 사용하든 관계없이 모든 빌드 자동화 도구에는 소스 코드를 원하는 형식으로 빌드하고 특정 위치에 대한 정리, 컴파일, 테스트 및 배포 작업을 자동화하는 공통 목표가 있습니다. 빌드 도구는 프로그래밍 언어에 따라 다르지만 고려해야 할 일반적인 오픈 소스 옵션이 있습니다.


Maven

Ant

Gradle

Bazel

Make

Grunt

Gulp

Buildr

Rake

A-A-P

Scons

BitBake

Cake

ASDF

Cabal


대박! 빌드 자동화 도구 구성 파일을 소스 제어 관리에 넣고 CI / CD 도구가 빌드하도록 할 수 있습니다.            



다 괜찮아요? 그러나 어디에 배치 할 수 있습니까?


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

지금까지 실행 가능하거나 배포 가능한 패키지 파일이 있습니다. 모든 응용 프로그램이 실제로 유용하려면 어떤 종류의 서비스 또는 인터페이스를 제공해야하지만 응용 프로그램을 호스팅하려면 선박이 필요합니다.

웹 응용 프로그램의 경우 웹 응용 프로그램 서버는 해당 선박입니다. 애플리케이션 서버는 배치 가능한 패키지 내부의 프로그래밍 로직을 감지하고 인터페이스를 렌더링하며 외부 세계에 소켓을 열어 웹 서비스를 제공 할 수있는 환경을 제공합니다. 응용 프로그램 서버를 설치하려면 HTTP 서버와 다른 환경 (예 : 가상 컴퓨터)이 필요합니다. 지금은 그 과정에서 이에 대해 배울 것이라고 가정 해 봅시다 (아래 컨테이너에 대해 논의 할지라도).

사용 가능한 많은 오픈 소스 웹 응용 프로그램 서버가 있습니다.


Tomcat

Jetty

WildFly

GlassFish

Django

Tornado

Gunicorn

Python Paste

Rails

NodeJS


이제 DevOps 파이프 라인을 거의 사용할 수 있습니다. 잘 했어!            



여기서 멈추고 독자적으로 더 통합 할 수는 있지만 코드 품질은 응용 프로그램 개발자가 염려해야 할 중요한 사항입니다.


5 단계 : 코드 테스트 범위


코드 테스트 조각을 구현하는 것도 번거로운 요구 사항이지만 개발자는 애플리케이션의 오류를 조기에 파악하고 최종 사용자가 만족할 수 있도록 코드 품질을 개선해야합니다. 운 좋게도 코드를 테스트하고 품질을 개선 할 수있는 방법을 제안 할 수있는 많은 오픈 소스 도구가 있습니다. 또한 대부분의 CI / CD 도구는 이러한 도구에 연결하여 프로세스를 자동화 할 수 있습니다.


코드 테스트 에는 테스트 작성 및 실행을 돕는 코드 테스트 프레임 워크 와 코드 품질 향상을 돕는 코드 품질 제안 도구 라는 두 가지 부분이 있습니다.


코드 테스트 프레임 워크

JUnit


EasyMock

Mockito

PowerMock

PyTest

Hypothesis

Tox


코드 품질 보증 시스템


Cobertura

CodeCover

Coverage.py

Emma

JaCoco

Hypothesis

Tox

Jasmine

Karma

Mocha

Jest


위에서 언급 한 대부분의 도구와 프레임 워크는 Java, Python 및 JavaScript 용으로 작성된 것입니다.


 C ++ 및 C #은 독점 프로그래밍 언어이므로 (GCC는 오픈 소스이지만) 코드 테스트 적용 범위 도구를 구현 했으므로 DevOps 파이프 라인은이 자습서의 시작 부분에 표시된 DevOps 파이프 라인 다이어그램과 유사해야합니다.


선택적 단계


컨테이너

위에서 언급 한 것처럼 가상 머신이나 서버에서 애플리케이션 서버를 호스팅 할 수 있지만 컨테이너는 널리 사용되는 솔루션입니다.컨테이너 https://opensource.com/resources/what-are-linux-containers 란? 짧은 설명은 VM에 응용 프로그램 크기를 압도하는 운영 체제의 풋 프린트가 필요하고 컨테이너는 응용 프로그램을 실행하기 위해 몇 개의 라이브러리와 구성 만 있으면된다는 것입니다. VM에는 여전히 중요한 용도가 있지만 컨테이너는 응용 프로그램 서버를 포함하여 응용 프로그램을 호스팅하기위한 간단한 솔루션입니다.


컨테이너에는 다른 옵션이 있지만 Docker와 Kubernetes가 가장 많이 사용됩니다.


https://www.docker.com/

https://kubernetes.io/


https://opensource.com/resources/what-docker


https://opensource.com/business/15/1/introduction-docker

https://opensource.com/resources/what-is-kubernetes

https://opensource.com/article/17/11/kubernetes-lightning-talk


미들웨어 자동화 도구

우리의 DevOps 파이프 라인은 주로 협업 적으로 응용 프로그램을 구축하고 배포하는 데 중점을 두었지만 DevOps 도구로 수행 할 수있는 다른 많은 작업이 있습니다. 그 중 하나는 IaC (Infrastructure as Code) 도구를 활용하는 것으로 미들웨어 자동화 도구라고도합니다. 이 도구는 미들웨어 소프트웨어의 설치, 관리 및 기타 작업을 자동화하는 데 도움이됩니다. 예를 들어 자동화 도구는 웹 응용 프로그램 서버, 데이터베이스 및 모니터링 도구와 같은 응용 프로그램을 올바른 구성으로 가져와 응용 프로그램 서버에 배포 할 수 있습니다.

고려해야 할 몇 가지 오픈 소스 미들웨어 자동화 도구는 다음과 같습니다.


Ansible

SaltStack

Chef

Puppet


미들웨어 자동화 도구에 대한 자세한 내용은 다음 Opensource.com  http://opensource.com/ 기사를 확인하십시오 .


https://opensource.com/article/19/2/quickstart-guide-ansible

https://opensource.com/article/19/1/automating-deployment-strategies-ansible

https://opensource.com/article/18/12/configuration-management-tools



이것은 Opensource.com을 통해 쓴 원본 기사의 사본입니다 : https://opensource.com/article/19/4/devops-pipeline

작가의 이전글 [번역] 당신이 데이터전문가가 될 수 없는 9가지 이유

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari