DevOps 튜토리얼: 도커, 쿠버네티스, 그리고 Azure DevOps

튜토리얼
Azure DevOps

이 기사에서는 DevOps에 대해 배우고, 이를 Agile 방법론과 어떻게 다른지에 대해 알아볼 것입니다. 또한 인기있는 DevOps 도구와 그들이 DevOps 생명주기에서 하는 역할에 대해 다룰 것입니다.

배울 내용

  • Docker, Kubernetes 및 Azure DevOps가 무엇인가?
  • DevOps가 무엇이며 왜 필요한가?
  • DevOps와 Agile의 차이점은 무엇인가?
  • 중요한 DevOps 도구는 무엇인가?
  • Docker가 DevOps에 어떻게 도움이 되는가?
  • Kubernetes가 DevOps에 어떻게 도움이 되는가?
  • Azure DevOps가 DevOps에 어떻게 도움이 되는가?
  • 지속적 통합 및 지속적 제공(CI/CD)가 무엇인가?
  • 인프라스트럭처의 코드(Infrastructure as Code)가 무엇인가?
  • Terraform와 Ansible이 DevOps에 어떻게 도움이 되는가?

Docker

Docker는 컨테이너화된 응용 프로그램을 빌드, 테스트 및 배포하는 데 사용되는 오픈 소스 소프트웨어 도구입니다. 그런데 컨테이너화(Containerization)란 무엇일까요? 컨테이너화(Containerization)는 모든 라이브러리와 파일을 응용 프로그램 코드와 함께 “컨테이너”라는 단일 단위에 묶어서 어떤 인프라에서든 실행할 수 있도록 하는 개념입니다.

Kubernetes

Kubernetes는 컨테이너 오케스트레이션 시스템으로, 컨테이너화된 응용 프로그램과 서비스를 관리합니다. 스케일링, 배포, 로드 밸런싱 등과 같은 컨테이너 환경에서 수행되는 작업을 처리합니다. Kubernetes는 휴대성, 효율성, 비용 효율성을 제공하며 시스템 통합, API 기반 지원 등의 기능을 제공합니다.

Azure DevOps

Azure DevOps는 소프트웨어 개발 및 배포 프로세스를 더 빠르고 조직적으로 만드는 다양한 도구와 기능을 제공하는 마이크로소프트 제품입니다. 이는 소프트웨어 개발자, 프로젝트 매니저 및 기타 참여자들이 함께 소프트웨어를 개발할 수 있는 프로세스 세트를 제공합니다. 기존 편집기 또는 IDE에 추가하여 모든 규모의 프로젝트에 대해 팀이 효과적으로 작업할 수 있도록 할 수 있습니다.

간단한 사용 사례로 시작해 보겠습니다.

무료 강좌 — 10 단계로 배우기

데브옵스란?

대부분의 소프트웨어 개발 관련 유행어와 마찬가지로, DevOps에 대한 공인된 정의는 없습니다.

정의는 아래와 같이 간단한 것부터 책의 한 페이지를 모두 차지할 만큼 복잡한 것까지 다양합니다.

DevOps는 문화적 철학, 관행, 도구의 조합으로, 조직이 응용 프로그램과 서비스를 제공하는 능력을 높은 속도로 향상시키는 것입니다 — 아마존 웹 서비스(AWS)

DevOps를 정의하려고 하기보다는 소프트웨어 개발이 DevOps로 어떻게 진화했는지를 이해해 봅시다.

폭포수 모델

폭포수 모델은 구조화된 접근 방식을 따르는 방법론입니다. 요구사항, 설계, 구현, 테스트, 배포, 유지보수의 6단계로 구성되어 있습니다. 각 단계는 이전 단계의 완료를 기반으로 구축됩니다. 초기 프로세스를 다시 방문하지 않고 이러한 단계를 통해 전진하므로, 이는 선형적인 프로세스입니다.

소프트웨어 개발의 초기 몇십 년은 폭포수 모델을 중심으로 이루어졌으며, 부동산 프로젝트를 구축하는 것과 같은 방식으로 소프트웨어 개발에 접근했습니다 — 예를 들어, 다리를 건설하는 것과 같습니다.

소프트웨어는 몇 주에서 몇 달에 걸쳐 여러 단계에서 구축됩니다.

대부분의 폭포수 프로젝트에서는 비즈니스가 애플리케이션의 작동 버전을 보기까지 몇 달이 걸립니다.

훌륭한 소프트웨어를 구축하기 위한 핵심 요소

폭포수 모델에서 몇 십 년 동안 일하면서, 우리는 우수한 소프트웨어를 개발하는 데 중요한 몇 가지 요소를 이해했습니다:

  • 소통
  • 피드백
  • 자동화

소통의 중요성

사람들 간의 소통은 소프트웨어 프로젝트의 성공에 필수적입니다.

폭포수 모델에서 우리는 요구 사항, 디자인, 아키텍처 및 배포에 대한 1000페이지 분량의 문서를 준비하여 소통을 강화하려고 노력했습니다.

그러나 시간이 지남에 따라 우리는 발견했습니다:

  • 팀 내의 소통을 강화하는 가장 좋은 방법은 그들을 함께 모이게 하는 것입니다. 그리고 다양한 기술을 가진 사람들을 한 팀에 모으는 것입니다.
  • 다양한 기술을 갖춘 다기능 팀은 탁월하게 작동합니다.

조기 피드백의 중요성

빠른 피드백을 받는 것은 중요합니다. 우수한 소프트웨어를 개발하는 것은 빠른 피드백을 받는 데 달려 있습니다.

  • 비즈니스 기대치를 충족하는 애플리케이션을 개발하고 있습니까?
  • 제품화되면 애플리케이션이 문제가 발생할까요?

몇 달 후에 알고 싶지 않습니다. 문제를 발견하는 것이 빨리일수록 해결하기 쉽습니다.

우수한 소프트웨어 팀은 빠른 피드백을 가능하게 하는 구조로 구성되어 있는 것을 발견했습니다.

자동화의 중요성

자동화는 중요합니다. 소프트웨어 개발에는 다양한 활동이 포함됩니다. 수동으로 작업하는 것은 느리고 오류가 발생하기 쉽습니다. 자동화를 도입할 기회를 항상 찾는 것이 중요하다는 것을 이해했습니다.

소프트웨어를 개발하는 핵심 요소를 이해한 후, Agile과 DevOps로 발전한 과정을 살펴보겠습니다.

Agile로의 발전

Agile은 점진적인 발전, 빈번한 피드백 및 개발 생애 주기 동안 변화하는 요구 사항에 대응할 수 있는 능력을 강조하는 접근 방식입니다. Agile은 교차 기능 팀이 짧은 개발 주기로 작업하도록 촉진하여 지속적인 개선을 촉진하고 최종 사용자에게 가치를 신속하게 제공합니다. 이는 팀 간의 향상된 커뮤니케이션, 피드백 수집 및 자동화 도입을 통해 우리의 학습을 구현하기 위한 진화의 첫 걸음이었습니다.

Agile은 비즈니스 팀과 개발 팀을 하나의 팀으로 통합하여 스프린트라고 불리는 작은 반복 작업으로 훌륭한 소프트웨어를 구축하도록 합니다.

개발의 각 단계에 몇 주 또는 몇 달을 소모하는 대신, Agile은 사용자 스토드라고 불리는 작은 요구 사항을 몇 일 내에, 때로는 같은 날 안에 개발 주기를 통해 진행하는 데 집중합니다.

Agile이 팀 간의 커뮤니케이션을 어떻게 향상시켰나요?

Agile은 비즈니스 팀과 개발 팀을 하나로 모았습니다.

  • 비즈니스는 무엇을 구축할지 정의할 책임이 있습니다. 요구 사항은 무엇인가요?
  • 개발은 요구 사항을 충족하는 제품을 구축할 책임이 있습니다. 개발에는 소프트웨어의 설계, 코딩, 테스트 및 패키징에 관련된 모든 사람이 포함됩니다.

애자일 방법론에서는 비즈니스 대표인 ‘제품 소유자’가 항상 팀과 함께 있으며, 팀은 비즈니스 목표를 명확히 이해합니다.

개발 팀이 요구 사항을 이해하지 못하고 잘못된 방향으로 가고 있을 때, 제품 소유자는 그들이 올바른 길로 돌아가도록 도와줍니다.

결과: 팀이 구축하는 최종 제품은 비즈니스가 원하는 것입니다.

또 다른 중요한 요소는 애자일 팀이 다양한 기술을 보유하고 있다는 것입니다: 코딩 기술(프론트엔드, API, 데이터베이스), 테스팅 기술, 비즈니스 기술. 이는 함께 소프트웨어를 개발해야 하는 사람들 간의 커뮤니케이션을 강화합니다.

애자일과 자동화

애자일 팀이 집중하는 자동화 영역은 무엇인가요?

소프트웨어 제품에는 다양한 결함이 있을 수 있습니다:

  • 기능적 결함은 제품이 예상대로 작동하지 않는 것을 의미합니다.
  • 기술적 결함은 소프트웨어 유지보수를 어렵게 만듭니다. 예를 들어, 코드 품질 문제 등.

일반적으로, 애자일 팀은 가능한 빨리 기술적 및 기능적 결함을 발견하기 위해 자동화에 집중합니다.

애자일 팀은 또한 코드 품질에 중점을 두고 있습니다. SONAR와 같은 도구가 응용 프로그램의 코드 품질을 평가하는 데 사용됩니다.

훌륭한 자동화 테스트와 뛰어난 코드 품질 검사가 있다면 충분할까요? 핵심은 이러한 프로세스를 자주 실행하는 것입니다. 애자일 팀은 지속적인 통합(Continuous Integration)을 강조하며, 버전 관리에 대한 커밋이 일련의 작업을 유발합니다. 여기에는 유닛 테스트, 자동화 테스트 및 코드 품질 검사가 포함되며, 모두 지속적인 통합 파이프라인에 원활하게 통합됩니다. 초기 애자일 시대에 널리 채택된 CI/CD 도구인 젠킨스(Jenkins)는 이러한 자동화 프로세스를 조정하는 데 중요한 역할을 했습니다.

애자일은 즉각적인 피드백을 어떻게 촉진했나요?

가장 중요한 요소는 비즈니스가 최종 제품을 보기 위해 몇 달을 기다릴 필요가 없다는 것입니다. 매 스프린트가 끝날 때마다 제품은 아키텍처 및 비즈니스 팀을 포함한 모든 이해관계자에게 데모됩니다. 모든 피드백은 수집되며 다음 스프린트를 위한 사용자 스토리의 우선 순위를 정하는 데 반영됩니다. 결과: 팀이 구축하는 최종 제품은 비즈니스가 원하는 것입니다.

즉각적인 피드백을 가능하게 하는 또 다른 중요한 요소는 지속적인 통합입니다. 예를 들어, 제가 버전 관리에 코드를 커밋한다고 가정해 보겠습니다. 30분 이내에 제 코드가 유닛 테스트 실패나 통합 테스트 실패를 유발하는지에 대한 피드백을 받게 됩니다. 제 코드가 코드 품질 기준을 충족하지 않거나 유닛 테스트에서 충분한 코드 커버리지를 가지지 않는 경우에도 피드백을 받게 됩니다.

애자일은 성공적이었나요? 네. 확실히요. 비즈니스와 개발 팀 간의 커뮤니케이션을 개선하고 다양한 결함을 조기에 발견하는 데 집중함으로써, 애자일은 소프트웨어 개발을 한 단계 발전시켰습니다.

나는 Agile을 사용하여 놀라운 팀들과 함께 일하는 멋진 경험을 했다. 소프트웨어 엔지니어링은 요구사항부터 애플리케이션을 실제로 운영하는 것까지 소프트웨어를 구축하는 모든 노력을 나타내며, 처음으로 프로그래밍만큼 즐거웠다.

하지만 진화는 멈추는가? 아니요.

새로운 도전이 나타났다.

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

우리는 마이크로서비스 아키텍처로 나아가기 시작했고, 큰 모놀리식 애플리케이션을 만드는 대신 여러 개의 작은 API를 구축하기 시작했다.

새로운 도전은 무엇이었나?

운영의 중요성이 더 커졌다. 한 달에 한 번의 모놀리식 릴리스 대신, 매주 수백 개의 작은 마이크로서비스 릴리스를 하게 된다. 마이크로서비스 간의 디버깅 문제와 마이크로서비스에서 발생하는 상황을 파악하는 것이 중요해졌다.

소프트웨어 개발에서 새로운 유행어를 사용할 때가 되었다. DevOps.

DevOps의 출현

DevOps의 초점은 무엇이었나?

DevOps의 초점은 개발 팀과 운영 팀 간의 커뮤니케이션을 향상시키는 것이었다.

  • 배포를 더 쉽게 만드는 방법은?
  • 운영 팀이 수행하는 작업을 개발 팀에 더 가시화하는 방법은?

DevOps는 팀 간의 커뮤니케이션을 어떻게 향상시켰나?

DevOps는 운영 팀을 개발 팀과 더 가깝게 만들었다.

  • 보다 성숙한 기업에서는 개발 및 운영 팀이 하나의 팀으로 일했습니다. 그들은 공통 목표를 공유하기 시작했고 양쪽 팀이 직면한 도전에 대해 이해하기 시작했습니다.
  • 기업에서는 데브옵스 진화 초기 단계에서 운영팀 대표가 스프린트 — 스탠드업 및 회고에 참여할 수 있습니다.

데브옵스 팀이 주로 집중하는 자동화 영역은 무엇인가요?

애자일의 주요 영역에 추가하여 — 지속적 통합 및 테스트 자동화 — 데브옵스 팀은 서버 프로비저닝, 서버 소프트웨어 구성, 응용프로그램 배포, 그리고 프로덕션 환경 모니터링과 같은 여러 운영팀의 활동을 자동화하는 데 주력했습니다. 연속 배포, 지속적 전달, 그리고 인프라스트럭처 코드 같은 중요 용어들이 있습니다.

연속 배포는 테스트 환경에 새로운 소프트웨어 버전을 지속적으로 배포하는 것을 의미합니다. Google 및 Facebook과 같이 보다 성숙한 조직에서는 지속적 전달이 도와주어 하루에 수백 번의 프로덕션 배포를 할 수 있습니다.

인프라스트럭처 코드는 인프라를 애플리케이션 코드와 같이 처리하는 것을 말합니다. 구성을 사용하여 서버, 로드 밸런서, 데이터베이스와 같은 인프라를 자동화된 방식으로 생성합니다. 인프라를 버전 관리하며 시간이 지남에 따른 인프라 변경을 추적할 수 있습니다.

데브옵스가 즉각적인 피드백을 어떻게 촉진했나요?

DevOps는 운영 및 개발 팀을 하나로 결합시킨다. 운영 및 개발이 동일한 팀의 일부이기 때문에 전체 팀은 운영 및 개발과 관련된 도전에 대해 이해한다.

  • 운영 문제가 발생하면 개발자들로부터 빠른 관심을 받는다.
  • 소프트웨어를 빠르게 사용 가능하게 하기 위한 도전 사항이 발생하면 운영 팀의 조기 관심을 받는다.

DevOps는 지속적 통합, 지속적 전달 및 코드로서의 인프라를 장려한다.

  • 지속적 전달 덕분에 코드 변경이나 구성 변경으로 테스트나 스테이징 환경을 망가뜨릴 수 있는 경우 몇 시간 내에 알 수 있다.
  • 코드로서의 인프라 덕분에 개발자는 운영팀의 도움 없이도 환경을 자체 프로비저닝하고 코드를 배포하며 문제를 스스로 찾을 수 있다.

나는 애자일과 DevOps를 두 가지 단계로 볼 수 있다. 이들은 서로 경쟁하는 것이 아니라 함께 우리가 훌륭한 소프트웨어를 개발하는 데 도움을 준다.

내가 알기로 애자일과 DevOps가 함께 하는 목표는 다음과 같은 것들이다:

  • 비즈니스, 개발 및 운영팀 간의 커뮤니케이션과 피드백을 촉진
  • 자동화로 인한 고통을 완화

DevOps 이야기

다음은 예시 이야기이다:

  • 당신은 팀에서 주목받는 개발자이며 빠른 수정이 필요하다.
  • GitHub 저장소로 이동한다.
  • 프로젝트를 빠르게 체크아웃한다.
  • 로컬 환경을 빠르게 생성한다.
  • 변경 사항을 만듭니다. 테스트합니다. 단위 및 자동화 테스트를 업데이트합니다.
  • 커밋합니다.
  • QA로 배포되었다는 이메일을 받습니다.
  • 일부 통합 테스트가 자동으로 실행됩니다.
  • QA 팀에게 승인을 요청하는 이메일이 전송됩니다. 수동 테스트를 수행하고 승인합니다.
  • 몇 분 후에 코드가 프로덕션 환경에 적용됩니다.
  • 이것이 이노베이티브 기업인 Netflix, Amazon, Google과 같은 기업에서 매일 발생하는 일상적인 일이라는 것을 알고 계셨나요?

이것이 데브옵스의 이야기입니다.

데브옵스 = 개발 + 운영

데브옵스는 소프트웨어 개발의 자연스러운 진화입니다. 데브옵스는 단순히 도구나 프레임워크 또는 자동화만이 아닙니다. 이 모든 것의 결합입니다.

데브옵스는 사람, 프로세스, 제품에 초점을 맞춥니다. 데브옵스의 사람 부분은 문화와 훌륭한 마인드셋을 만드는 데 집중합니다 — 빠른 피드백을 중요시하고 개방적인 커뮤니케이션을 장려하며 고품질 소프트웨어를 중요시하는 문화입니다.

애자일은 비즈니스와 개발 팀 간의 간극을 좁히는 데 도움이 되었습니다. 개발 팀은 비즈니스의 우선 순위를 이해하고 비즈니스와 협력하여 가장 가치 있는 이야기를 먼저 제공했지만, 개발 및 운영 팀은 정렬되어 있지 않았습니다.

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

  • 개발팀의 목표는 가능한 한 많은 새로운 기능을 프로덕션 환경으로 가져오는 것입니다.
  • 운영팀의 목표는 제품 환경을 최대한 안정적으로 유지하는 것이었습니다.

보시다시피, 제품화하는 것이 어렵다면, 개발팀과 운영팀은 일치하지 않습니다.

DevOps는 개발팀과 운영팀이 공유하는 목표로 일치하도록 하는 데 목표를 두고 있습니다.

개발팀은 운영팀과 협력하여 운영적인 도전을 이해하고 해결합니다. 운영팀은 스크럼 팀의 일부이며 개발 중인 기능을 이해합니다.

이것을 어떻게 가능하게 할까요? 개발팀과 운영팀 사이의 벽을 허물어 보세요!

개발팀과 운영팀을 함께 모으는 방법

옵션 1

성숙한 DevOps 기업에서는 개발팀과 운영팀이 동일한 스크럼 팀의 일부로서 일하고 서로의 책임을 공유합니다.

옵션 2

그러나, DevOps 진화의 초기 단계에 있다면, 어떻게 개발팀과 운영팀이 공통의 목표를 가지고 함께 일할 수 있게 할까요?

다음은 할 수 있는 몇 가지 방법입니다:

  • 개발팀이 운영팀의 일부 책임을 공유하도록 합니다. 예를 들어, 개발팀이 제품 출시 후 첫 주에 새 릴리스에 대한 책임을 맡을 수 있습니다. 이는 개발팀이 운영팀이 새 릴리스를 배포하는 데 직면하는 도전을 이해하고 함께 더 나은 해결책을 찾을 수 있도록 돕습니다.
  • 또 다른 할 수 있는 일은 운영팀 대표를 스크럼 활동에 참여시키는 것입니다. 스탠드업 및 회고에 참여하도록 합니다.
  • 다음으로 할 수 있는 일은 운영 팀이 직면한 문제를 개발 팀에게 더 가시화하는 것입니다. 운영에서 어떤 문제에 직면했을 때, 개발 팀을 솔루션 작업에 참여시키세요.

어떤 방법을 선택하든, 벽을 허물고 개발 팀과 운영 팀이 함께할 수 있는 방법을 찾아보세요.

자동화로 인해 또 다른 흥미로운 옵션이 나타납니다. 인프라를 코드로 관리하고 개발자를 위한 자기 프로비저닝을 활성화함으로써 운영 팀과 개발 팀이 이해할 수 있는 공통 언어인 코드를 만들 수 있습니다.

DevOps 사용 사례

아래 그림을 고려해 보세요:

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

  1. Terraform과 Azure DevOps를 사용한 코드 기반의 인프라로 Kubernetes 클러스터를 프로비저닝하는 것.
  2. Azure DevOps를 사용하여 마이크로서비스를 위한 Docker 이미지를 빌드하고 Kubernetes 클러스터에 배포하는 지속적 배포.

이것이 복잡하게 들리나요?

우리가 이를 분해해 보고 이해해 보겠습니다.

먼저 #2 — 지속적 배포부터 시작해 보겠습니다.

#2: Azure DevOps와 Jenkins를 이용한 DevOps 지속적 배포

자주 실행하지 않는 훌륭한 테스트와 코드 품질 검사에 무슨 의미가 있나요?

소프트웨어를 충분히 자주 배포하지 않는다면 배포 자동화는 무슨 의미가 있나요?

개발자가 버전 관리 시스템에 코드를 커밋하면 다음 단계가 실행됩니다:

  • 단위 테스트
  • 코드 품질 검사
  • 통합 테스트
  • 애플리케이션 패키징 — 배포 가능한 버전의 애플리케이션 구축. 도구 — Maven, Gradle, Docker
  • 애플리케이션 배포 — 새로운 애플리케이션이나 애플리케이션의 새로운 버전을 라이브로 전환
  • 애플리케이션을 테스트하기 위해 테스트 팀에 이메일 발송

테스트 팀의 승인이 있는 즉시 애플리케이션은 다음 환경에 즉시 배포됩니다.

이를 지속적 배포(Continuous Deployment)라고 합니다. 프로덕션까지 지속적으로 배포하면 이를 지속적 전달(Continuous Delivery)이라고 합니다.

가장 인기 있는 CI/CD 도구는 Azure DevOps와 Jenkins입니다.

#1: DevOps 인프라를 코드로 Terraform을 이용하여

예전에는 환경을 만들고 애플리케이션을 수동으로 배포했습니다.

서버를 생성할 때마다 수동으로 수행해야 했습니다.

  • 소프트웨어 버전을 업데이트해야 합니다.
  • 보안 패치를 수동으로 설치해야 합니다.

수동으로 수행하면 다음과 같은 결과가 발생합니다:

  • 오류 발생 가능성이 높음
  • 복제 환경이 어렵습니다

코드로서의 인프라(Infrastructure as Code)

코드로서의 인프라 — 인프라를 애플리케이션 코드와 동일하게 취급합니다.

코드로서의 인프라 이해를 위해 알아야 할 몇 가지 중요한 사항은 다음과 같습니다:

  • 인프라 팀은 가치 추가 작업에 집중합니다(일상 작업 대신)
  • 오류가 적고 실패로부터 빠른 복구가 가능함
  • 서버가 일관성이 있음(구성 변화 방지)

가장 인기 있는 IaC 도구는 Ansible과 Terraform입니다.

전형적으로 IaC의 단계는 다음과 같습니다:

  • 템플릿에서 서버 프로비저닝(클라우드에서 활성화됨)
  • 소프트웨어 설치
  • 소프트웨어 구성

서버 프로비저닝

일반적으로 프로비저닝 도구를 사용하여 서버를 프로비저닝하고 새 서버를 네트워킹 기능으로 준비합니다. 가장 인기 있는 프로비저닝 도구는 Cloud Formation과 Terraform입니다.

Terraform을 사용하면 로드 밸런서, 데이터베이스, 네트워킹 구성 등 인프라 전체와 함께 서버를 프로비저닝할 수 있습니다. Packer 및 AMI(아마존 머신 이미지)와 같은 도구를 사용하여 사전 생성된 이미지를 사용하여 서버를 생성할 수 있습니다.

구성 관리

구성 관리 도구는 다음과 같이 사용됩니다:

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

인기있는 구성 관리 도구는 Chef, Puppet, Ansible 및 SaltStack입니다. 이러한 도구는 기존 서버에 소프트웨어를 설치하고 관리하기 위해 설계되었습니다.

DevOps에서 Docker와 Kubernetes의 역할

마이크로서비스 세계에서 몇몇 마이크로서비스는 Java로 빌드되고, 몇몇은 Python으로 빌드되며, 몇몇은 JavaScript로 빌드될 수 있습니다.

다른 마이크로서비스는 애플리케이션을 빌드하고 서버에 배포하는 다른 방법을 가집니다. 이는 운영팀의 작업을 어렵게 만듭니다. 여러 유형의 애플리케이션을 유사한 방식으로 배포하는 방법은 무엇일까요? 컨테이너와 Docker가 등장합니다.

Docker를 사용하면 언어에 상관없이 마이크로서비스 이미지를 빌드할 수 있습니다. 이러한 이미지를 어떤 인프라에서든 동일한 방식으로 실행할 수 있습니다. 이는 운영을 간소화합니다.

쿠버네티스는 다양한 유형의 컨테이너를 조율하고 클러스터에 배포하는 데 도움을 줌.

쿠버네티스는 또한 다음을 제공합니다:

  • 서비스 검색
  • 로드 밸런싱
  • 중앙 집중식 구성

도커와 쿠버네티스는 데브옵스를 쉽게 만듭니다.

중요한 데브옵스 지표

다음은 추적하고 시간이 지남에 따라 개선할 수 있는 중요한 데브옵스 지표 중 일부입니다.

  • 배포 빈도 — 애플리케이션을 얼마나 자주 본립에 게시합니까?
  • 마케팅 시간 — 기능을 코딩에서 본립까지 얼마나 걸리나요?
  • 새 릴리스 실패율 — 릴리스 중 얼마나 많은 수가 실패하나요?
  • 수정 리드 타임 — 프로덕션 수정을 만들고 본립에 게시하는 데 얼마나 걸리나요?
  • 회복 평균 시간 — 주요 문제에서 프로덕션 환경을 복구하는 데 얼마나 걸리나요?

데브옵스 최상의 실천

민첩한 프로젝트 관리

민첩한 프로젝트 관리는 소프트웨어 애플리케이션을 개발하기 위한 반복적인 접근 방식입니다. 이 관행을 통해 팀은 개발 속도를 향상시키고 다양한 고객 요구에 잘 대응할 수 있습니다. 민첩한 방법론은 예전의 장기 릴리스 주기가 있던 전통적인 폭포수 방법론과는 다릅니다. 민첩은 스크럼과 칸반 프레임워크를 사용하여 소프트웨어를 고객의 요구에 따라 제공합니다.

적절한 도구 집합 사용

소프트웨어 개발자와 시스템 관리자는 고부가가치 애플리케이션을 구축하기 위해 DevOps 라이프사이클의 각 단계에서 적절한 DevOps 도구를 선택하고 사용해야 합니다.

다음은 DevOps 엔지니어, 시스템 관리자 및 기타 이해관계자가 사용할 수 있는 도구의 몇 가지 예입니다:

  1. Jira와 같은 도구는 팀이 작업을 더 작고 관리하기 쉬운 조각으로 분리하는 데 도움을 줄 수 있으며, 이는 팀의 생산성을 높이는 데 기여합니다.
  2. Jenkins와 Bitbucket과 같은 도구는 테스트 단계부터 배포 단계까지 코드 흐름을 자동화하는 데 도움을 줄 수 있습니다.
  3. Slack, GetFeedback 등의 도구는 DevOps 팀이 채팅 도구와 설문 플랫폼을 통합하여 실시간 피드백을 수집하고 검토하는 데 도움을 줄 수 있습니다.

지속적 통합/지속적 배포

지속적 통합(CI)과 지속적 배포(CD)는 조직이 소프트웨어를 신속하고 효과적으로 배포할 수 있도록 돕는 현대적인 소프트웨어 개발 관행입니다. CI에서는 개발자가 애플리케이션 코드를 여러 번 공유 저장소에 지속적으로 커밋합니다. CD에서는 코드가 빠르고 매끄럽게 프로덕션에 배포됩니다. CD는 또한 통합이 지연이나 문제 없이 이루어지도록 보장합니다.

보안 통합

보안은 소프트웨어 개발 프로세스의 중요한 부분입니다. 사이버 범죄와 데이터 침해 사례가 증가하는 현재 세상에서 조직들은 시스템에 보안을 통합하는 중요성을 깨닫고 있습니다. 과거에는 보안이 일반적으로 소프트웨어 개발 수명주기의 마지막 단계에서 고려되었지만, DevSecOps의 등장으로 보안은 응용 프로그램 개발의 첫날부터 고려되고 통합되고 있습니다.

가시성은 마이크로서비스 및 클라우드 아키텍처를 사용하는 복잡한 응용 프로그램을 개발할 때 중요합니다. 가시성은 DevOps 팀이 다양한 응용 프로그램의 복잡한 구조(microservices, 클라우드 앱 등)을 이해하고 환경의 미래 요구 사항을 해결하는 데 도움이 됩니다. Kubernetes 가시성 및 Splunk는 가장 좋은 가시성 플랫폼 중 일부입니다.

DevOps 성숙도 신호

  • DevOps 구현의 성숙도를 어떻게 측정합니까?
  • 개발 프로세스에서 배포까지 걸리는 시간은 전반적으로 만족스러워야 합니다
  • 새 코드 배포의 빈도 결정하기
  • 사건이나 예기치 않은 사건으로부터의 평균 복구 시간(MTTR)은 가능한 낮아야 합니다성공적인 배포가 실패한 배포를 능가해야 합니다
  • 빠르고 믿을만한 릴리스는 높은 투자 수익률(ROI)을 끌어낼 것입니다.

DevOps 전환의 최상의 실천 방법

  • 리더십의 참여가 중요합니다
  • 선행 비용이 필요합니다
  • 팀을 돕기 위해 COE를 설치하십시오
  • 적절한 애플리케이션과 팀을 선택하십시오
  • 작은 규모로 시작하십시오
  • 학습 공유하기(뉴스레터, 커뮤니케이션, COEs)
  • 탐구와 자동화 마인드를 가진 사람들을 격려하십시오
  • DevOps 팀을 인정하세요

Source:
https://dzone.com/articles/devops-tutorial-devops-with-docker-kubernetes-and