DevOps에서 Docker 및 Kubernetes의 역할

2020년 5월 11일 kimxp devops

개요

DevOps 란 무엇입니까?
왜 DevOps가 필요합니까?
DevOps는 민첩한 개발과 어떻게 다릅니 까?
중요한 DevOps 도구는 무엇입니까?
Docker는 DevOps를 어떻게 지원합니까?
Kubernetes는 DevOps에 어떤 도움을 줍니까?
Azure DevOps는 DevOps에 어떤 도움이됩니까?
지속적인 통합과 지속적인 제공이란 무엇입니까?
코드로 인프라 란 무엇입니까?
Terraform과 Ansible은 DevOps에 어떤 도움을 줄 수 있습니까?

DevOps 란 무엇입니까?

소프트웨어 개발을 둘러싼 대부분의 유행어와 마찬가지로 DevOps에는 정의가 없습니다.

정의는 단순 (이 두 정의 에서처럼)에서 복잡한 (전체 책을 지속 할 수 있음)까지 다양합니다.

DevOps는 애플리케이션을위한 문화적 아이디어, 사례 및 빠른 전달 도구의 조합입니다.

DevOps는 정확성과 신뢰성을 보장하면서 새로운 버전의 소프트웨어를 지속적으로 자동 제공하는 것을 목표로하는 조직 내 학제 간 협업입니다. – L Leite

DevOps를 정의하는 대신 소프트웨어 개발이 DevOps로 어떻게 발전했는지 이해해야합니다.

폭포 모델 (폭포)

수십 년 전, 소프트웨어 개발은 Waterfall 모델에 중점을 두었습니다.

폭포 모델 개발은 건설 프로젝트와 유사합니다. 예를 들어 놀라운 다리를 건설 할 수 있습니다.

몇 주에서 몇 달까지 지속될 수있는 여러 단계로 소프트웨어를 빌드합니다.

대부분의 Waterfall 프로젝트에서는 회사에서 유효한 버전의 응용 프로그램을 보는 데 몇 개월이 걸립니다.

우수한 소프트웨어 구축을위한 핵심 요소

워터 폴 모델에서 수십 년 동안 일한 후 훌륭한 소프트웨어 개발을위한 몇 가지 핵심 요소를 배웠습니다.

의사 소통
피드백
자동화

의사 소통의 중요성

소프트웨어 개발은 여러 기술을 포함한 학제 간 작업입니다.

대인 커뮤니케이션은 소프트웨어 프로젝트의 성공에 중요합니다.

워터 폴 모델에서는 요구 사항, 디자인, 아키텍처 및 배포에 대한 자세한 문서를 준비하여 커뮤니케이션을 향상 시키려고합니다.

그러나 얼마 동안 우리는

팀 내 의사 소통을 향상시키는 가장 좋은 방법은 팀을 통합하여 같은 팀에서 다양한 기술을 습득 할 수 있도록하는 것입니다.
여러 기술을 가진 부서 간 팀이 작업을 훌륭하게 만듭니다.

조기 피드백의 중요성

피드백을 빠르게받는 것이 중요합니다. 훌륭한 소프트웨어를 개발하는 것은 빠른 피드백을 얻는 것입니다.

비즈니스 기대치를 충족시키는 응용 프로그램을 구축하고 있습니까?

피드백을 받기 위해 몇 달 동안 기다릴 수 없습니다. 빨리 배우고 싶을 수도 있습니다.

프로덕션 환경에 배포하면 응용 프로그램에 문제가 있습니까?

문제를 빨리 발견할수록 해결하기가 더 쉽습니다.

최고의 소프트웨어 팀은 일반적으로 빠른 피드백입니다. 우리가 가능한 한 빨리 올바른 일을하고 있는지 알려주십시오.

자동화의 중요성

자동화가 필수적입니다. 소프트웨어 개발에는 다양한 활동이 포함됩니다. 수동 작업이 느리고 오류가 발생하기 쉽습니다.

훌륭한 소프트웨어 개발의 핵심 요소를 이해 한 후 민첩한 개발 및 DevOps로 어떻게 진화했는지 살펴 보겠습니다.

민첩한 개발

팀 간의 의사 소통을 강화하고 신속한 피드백을 얻고 자동화를 도입하는 경우 민첩한 개발이 첫 번째 단계입니다.

민첩한 개발은 비즈니스 팀과 개발 팀을 하나의 팀으로 통합합니다.이 팀은 소규모 반복 (Sprints)으로 훌륭한 소프트웨어를 구축하는 데 전념합니다.

민첩한 개발의 초점은 개발주기가 몇 주 또는 며칠이 아니라 며칠 또는 며칠 내에 적은 요구에 있다는 것입니다.

애자일 개발은 팀 간의 의사 소통을 어떻게 강화합니까?

민첩한 개발은 비즈니스 및 개발 팀을 하나로 묶습니다.

비즈니스 팀은 무엇을 구축할지 정의해야합니다. 요구 사항은 무엇입니까?
개발 팀은 요구 사항을 충족하는 제품을 제작합니다. 개발에는 소프트웨어 디자인, 코딩, 테스트 및 패키징에 관련된 모든 사람이 포함됩니다.

민첩한 개발에서 비즈니스 담당자 (종종 제품 소유자라고도 함)가 종종 팀에 나타나고 팀은 비즈니스 목표를 명확하게 이해할 수 있습니다.

개발 팀이 요구 사항을 잘못 이해하고 잘못된 방식으로 진행하면 제품 소유자가 과정을 수정하고 올바른 경로를 유지하도록 도울 것입니다.

결과 : 팀이 만든 최종 제품은 회사가 원하는 것입니다.

또 다른 중요한 요소는 민첩한 개발 팀이 코딩 기술 (프론트 엔드, API 및 데이터베이스), 테스트 기술 및 비즈니스 기술과 같은 교차 기능 기술을 보유하고 있다는 것입니다.

민첩한 개발 및 자동화

애자일 개발 팀은 어떤 자동화 영역에 중점을두고 있습니까?

소프트웨어 제품에는 여러 가지 결함이있을 수 있습니다.

기능적 결함은 제품이 제대로 작동하지 않음을 의미합니다.
기술적 결함으로 인해 소프트웨어 유지 관리가 어려워집니다. 예를 들어 코드 품질 문제입니다.

일반적으로 민첩한 개발 팀은 자동화를 사용하여 가능한 한 빨리 기술적 및 기능적 결함을 감지하는 데 중점을 둡니다.

민첩한 개발 팀은 자동화 된 테스트에 중점을 둡니다. 방법과 클래스를 테스트하기 위해 우수한 단위 테스트를 작성하십시오. 뛰어난 통합 테스트를 작성하여 모듈 및 응용 프로그램을 테스트하십시오. 민첩한 개발 팀은 또한 SONAR와 같은 도구를 사용하여 응용 프로그램의 코드 품질을 평가하여 코드 품질에 집중합니다.

우수한 자동 테스트와 우수한 코드 품질 검사가 있다면 충분합니까?

가능한 한 자주 실행할 수도 있습니다. 민첩한 개발 팀은 지속적인 통합에 중점을 둡니다. 코드 제출, 단위 테스트, 자동 테스트 및 코드 품질 검사를 실행하십시오. 연속 통합 파이프 라인에서 자동으로 수행됩니다. 민첩한 개발 초기에 가장 인기있는 CI / CD 도구는 Jenkins였습니다.

애자일 개발은 즉각적인 피드백을 어떻게 촉진합니까?

가장 중요한 요소는 회사가 몇 개월을 기다리지 않고도 최종 제품을 볼 수 있다는 것입니다. 각 버전 반복이 끝나면 제품은 모든 이해 관계자에게 시연됩니다. 다음 버전 반복의 끝에 우선 순위를 부여 할 때 모든 피드백이 채택됩니다. 결과 : 팀이 만든 최종 제품은 회사가 원하는 것입니다.

즉각적인 피드백을위한 또 다른 중요한 요소는 지속적인 통합입니다. 코드를 버전 관리에 제출한다고 가정하면, 30 분 안에 코드로 인해 유닛 테스트 또는 통합 테스트가 실패하면 피드백을받습니다. 코드가 코드 품질 표준을 충족하지 않거나 단위 테스트에서 코드 범위가 충분하지 않으면 피드백을받습니다.

민첩한 개발이 성공 했습니까? 예 물론 이죠 Agile은 비즈니스와 개발 팀 간의 커뮤니케이션을 개선하고 다양한 결함을 조기에 발견하는 데 중점을 두어 소프트웨어 개발을 새로운 차원으로 끌어 올렸습니다.

그러나 새로운 도전이 생겨났다.

마이크로 서비스 아키텍처의 진화

이제 우리는 천천히 마이크로 서비스 아키텍처로 전환하고 있으며 전체적인 대규모 애플리케이션을 구축하는 대신 많은 작은 API를 구축하기 시작했습니다.

새로운 도전은 무엇입니까?

운영 및 유지 보수가 더욱 중요해졌습니다. 한 달이 아닌 매주 수백 개의 작은 마이크로 서비스를 출시해야합니다. 마이크로 서비스의 문제점을 디버그하고 마이크로 서비스에서 발생하는 상황을 이해하는 것이 중요해집니다.

이제 소프트웨어 개발에 새로운 유행어 인 DevOps를 사용할 차례입니다.

DevOps의 출현

DevOps의 초점은 무엇입니까?

DevOps의 초점은 개발 팀과 운영 팀 간의 커뮤니케이션을 강화하는 것입니다.

배포를 쉽게하는 방법?
운영 및 유지 관리 팀이 개발 팀의 역할을 더 잘 이해하도록하는 방법은 무엇입니까?

DevOps는 팀 간의 의사 소통을 어떻게 향상 시킵니까?

DevOps는 운영 및 유지 관리 팀을 개발 팀과 더 가깝게 만듭니다.

보다 성숙한 기업에서는 개발 팀과 운영 및 유지 관리 팀이 같은 팀입니다. 그들은 공통의 목표를 공유하기 시작했고, 두 팀은 다른 팀이 직면 한 문제를 이해하기 시작했습니다.

DevOps 팀이 중점을 둔 자동화 영역은 무엇입니까?

민첩한 개발 (연속 통합 및 테스트 자동화)의 주요 영역 외에도 DevOps 팀은 서버에서 소프트웨어 구성, 응용 프로그램 배포 및 프로덕션 환경 모니터링과 같은 운영 팀 자동화를 지원하기 위해 노력하고 있습니다. 핵심 용어는 지속적인 배포 및 코드 형태의 인프라입니다.

지속적인 배포는 테스트 환경에 새로운 버전의 소프트웨어를 지속적으로 배포하는 것입니다. Google 및 Facebook과 같은보다 성숙한 조직에서 Continuous Delivery는 소프트웨어를 프로덕션에 지속적으로 배포 할 수 있도록 도와줍니다.

코드로서의 인프라는 인프라를 애플리케이션 코드로 취급하는 것입니다. 자동화 된 구성을 사용하여 인프라 (서버,로드 밸런서 및 데이터베이스)를 만들 수 있습니다. 인프라를 버전 관리하여 추적 할 수 있습니다.

DevOps는 즉각적인 피드백을 어떻게 촉진합니까?

DevOps는 O & M 및 개발 팀을 하나로 모았습니다. O & M과 개발은 동일한 팀의 일부이므로 전체 팀은 O & M 및 개발과 관련된 문제를 이해합니다.

모든 운영 및 유지 관리 문제는 개발자가 신속하게 관심을 갖습니다.
소프트웨어를 시작할 때 발생하는 모든 문제는 운영 및 유지 관리 팀의 초기 관심을 불러 일으 킵니다.

DevOps는 지속적인 통합, 지속적인 제공 및 인프라를 코드로 권장합니다.

지속적인 전달로 인해 테스트 또는 환경을 손상시키는 코드 변경 또는 구성 변경을 수행하면 몇 시간 내에 알게됩니다.
“코드로 인프라”를 사용하기 때문에 개발자는 운영 팀의 도움없이 환경을 직접 구성하고 코드를 배포하며 문제를 찾을 수 있습니다.

우리는 민첩한 개발과 DevOps가 사물을 단순하게 만드는 두 가지 요소라고 말하지만 실제로 DevOps의 의미에 대한 정의는 받아 들여지지 않습니다.

민첩한 개발과 DevOps는 훌륭한 소프트웨어를 개선하고 구축하는 데 도움이되는 두 단계라고 생각합니다. 그들은 서로 경쟁하지는 않지만 함께 훌륭한 소프트웨어 제품을 구축하는 데 도움을 줄 수 있습니다.

제 경우에는 민첩한 개발과 DevOps가 보완 적입니다.

비즈니스, 개발 및 운영 및 유지 관리 팀 간의 커뮤니케이션 및 피드백 촉진
자동화를 통해 고통을 덜어줍니다.

DevOps의 이야기

팀의 스타 개발자라면 소프트웨어 문제를 신속하게 해결해야합니다.

품목을 체크 아웃해야합니다.

로컬 환경을 빠르게 만들어야합니다.

코드를 수정해야합니다.

단위 테스트와 자동 테스트를 업데이트해야합니다.

제출 코드를 제출해야합니다.

품질 검사가 수행 될 것임을 알리는 이메일이 발송됩니다.

일부 통합 테스트는 자동으로 실행됩니다.

품질 관리팀에 승인을 요청하는 이메일이 발송됩니다. 그들은 수동 테스트를 수행하고 승인합니다.

몇 분 안에 코드가 생산에 투입됩니다.

이것은 DevOps의 이야기입니다.

DevOps = 개발 + 운영

DevOps는 소프트웨어 개발의 자연스러운 개발입니다. DevOps는 단순한 도구가 아니라 프레임 워크는 자동화입니다. 이것은 이들 모두의 조합입니다.

DevOps는 사람, 프로세스 및 제품에 중점을 둡니다. DevOps의 “사람”부분은 개방적인 의사 소통을 장려하고 신속한 피드백, 즉 고품질 소프트웨어를 소중히 여기는 문화 인 좋은 사고 모델을 만드는 문화에 관한 것입니다.

민첩한 개발은 비즈니스 팀과 개발 팀 간의 격차를 해소합니다. 개발 팀은 비즈니스의 우선 순위를 이해하고 비즈니스와 협력하여 가장 소중한 이야기를 먼저 제공합니다. 그러나 개발 팀과 운영 및 유지 관리 팀은 일관성이 없습니다.

그들은 다른 목표를 가지고 있습니다.

개발 팀의 목표는 가능한 한 많은 새로운 기능을 프로덕션에 배치하는 것입니다.

운영팀의 목표는 프로덕션 환경을 가능한 한 안정적으로 유지하는 것입니다.

보시다시피, 제품을 생산하기가 어려운 경우 개발자와 운영 담당자는 일관성을 유지할 수 없습니다.

DevOps는 Dev 및 Ops 팀이 공통 목표를 달성 할 수 있도록하는 것을 목표로합니다.

개발 팀은 운영 및 유지 관리 팀과 협력하여 운영 및 유지 관리 문제를 이해하고 해결합니다. Ops 팀은 Scrum 팀의 구성원이며 개발 기능을 이해합니다.

우리는 어떻게 이것을 할 수 있습니까?

개발자와 운영자 사이의 격벽을 깰!

개발자 및 O & M 직원 조합-옵션 1

성숙한 DevOps 엔터프라이즈에서 Dev와 Ops는 동일한 Scrum 팀의 일원이며 서로 책임을 공유합니다.

개발자 및 운영 및 유지 보수 담당자 조합 옵션 2

그러나 DevOps 진화의 초기 단계에 있다면 Dev와 Ops는 어떻게 공통의 목표를 공유하고 함께 협력 할 수 있습니까?

다음을 수행 할 수 있습니다.

시작할 수있는 한 가지는 개발 팀이 운영 팀의 일부 책임을 공유하도록하는 것입니다. 예를 들어, 개발 팀은 프로덕션 배포 후 첫 주 내에 새 버전의 릴리스를 담당 할 수 있습니다. 이를 통해 개발 팀은 새 버전을 출시 할 때 직면하는 운영 문제를 이해하고 더 나은 솔루션을 찾기 위해 단합 할 수 있습니다.
당신이 할 수있는 또 다른 일은 Scrum 활동에 운영 및 유지 관리 팀의 대표를 참여시키는 것입니다.
다음으로 개발 팀이 운영 및 유지 관리 팀이 직면 한 문제를보다 명확하게 파악할 수 있습니다. 운영 및 유지 관리에 문제가 발생하면 개발 팀을 솔루션 팀의 일원으로 만드십시오.

자동화로 인해 또 다른 흥미로운 옵션이 등장했습니다. 인프라를 코드로 사용하고 개발자를위한 사전 구성을 사용하면 운영 및 개발 팀이 이해할 수있는 공통 언어 코드를 작성할 수 있습니다.

DevOps 사용 사례

이 그림은 두 가지 간단한 워크 플로우를 보여줍니다

아니요 1 : Terraform 및 Azure DevOps를 사용하여 Kubernetes 클러스터의 인프라를 구성하십시오.
아니요 2 : Azure DevOps를 사용하여 마이크로 서비스를 지속적으로 배포하여 마이크로 서비스의 Docker 이미지를 Kubernetes 클러스터에 빌드하고 배포합니다.

이 소리가 복잡합니까?

그것을 분해하고 시도하고 이해합시다.

2 번부터 시작하겠습니다. 첫 번째는 연속 배포입니다.

아니요 2 : Azure DevOps 및 Jenkins를 사용한 지속적인 DevOps 배포

테스트 및 코드 품질 검사를 자주 실행하지 않으면 어떻게 사용됩니까?
소프트웨어를 충분히 자주 배포하지 않으면 배포 자동화의 용도는 무엇입니까?

개발자가 코드를 버전 제어 시스템에 제출하면 즉시 다음 단계를 수행합니다.

단위 테스트.
코드 품질 검사
통합 테스트.
응용 프로그램 패키징 — 배포 가능한 응용 프로그램 버전을 구축합니다.
응용 프로그램 배포를 통해 새로운 버전의 응용 프로그램을 사용할 수 있습니다.
응용 프로그램 테스트를 위해 테스트 팀으로 이메일을 보냅니다.

테스트 팀이 승인하면 응용 프로그램은 즉시 다음 환경에 배포됩니다.

이것을 연속 배포라고합니다. 프로덕션 환경에 계속 배포하는 경우이를 연속 배달이라고합니다.

가장 널리 사용되는 CI / CD 도구는 Azure DevOps 및 Jenkins입니다.

아니요 1 : Terraform을 사용하여 DevOps에서 인프라를 코드로 구현

과거에는 환경을 만들고 응용 프로그램을 수동으로 배포했습니다.

서버가 작성 될 때마다 수동으로 수행해야합니다.

Java 버전을 업데이트해야하는 경우 어떻게합니까?
보안 패치를 적용해야합니까?

수동으로 수행하십시오.

결과는 어떻습니까?

오류 확률이 높습니다.
환경을 복제하기가 어렵습니다.

코드로서의 인프라

애플리케이션 코드와 같은 인프라를 코드 처리하는 인프라

이것들은 인프라, 즉 코드가 이해해야 할 중요한 것들입니다.

인프라 팀은 일상적인 작업 대신 부가 가치 작업에 중점을 둡니다.
오류가 적을수록 오류를 신속하게 복구 할 수 있습니다.
서버는 일관성이 있습니다 (구성 편차를 피하십시오).

가장 많이 사용되는 IaC 도구는 Ansible 및 Terraform입니다.

일반적으로 다음은 IaC의 단계입니다.

클라우드를 통해 활성화 된 템플릿을 통해 서버 구성
소프트웨어 설치
구성 소프트웨어

서버 구성

가장 널리 사용되는 구성 도구는 CloudFormation 및 Terraform입니다.

Terraform을 사용하면로드 밸런서, 데이터베이스, 네트워크 구성 등과 같은 서버 및 인프라의 일부를 사전 구성 할 수 있습니다. Packer 및 AMI와 같은 도구를 사용하여 미리 생성 된 이미지를 사용하여 서버 (Amazon Machine Image)를 생성 할 수 있습니다.

구성 관리

구성 관리 도구가 사용됩니다

소프트웨어 설치
구성 소프트웨어

널리 사용되는 구성 관리 도구는 Chef, Puppet, Ansible 및 SaltStack입니다. 기존 서버에 소프트웨어를 설치하고 관리하도록 설계되었습니다.