Docker를 사용한 지속적인 전달 방식(리뷰 및 동영상)

기술 이사의 최근 연설을 바탕으로 한 출판물로 블로그를 시작하겠습니다. 디스톨 (드미트리 스톨야로프). 이 모든 행사는 2016년 다양한 전문 행사에서 열렸으며 DevOps 및 Docker 주제에 전념했습니다. Badoo 사무실에서 열린 Docker Moscow 회의 영상 중 하나는 이미 출판 온라인. 새로운 것에는 보고서의 본질을 전달하는 기사가 함께 제공됩니다. 그래서…

31월 XNUMX일 컨퍼런스에서 루트컨프 2016, "Russian Internet Technologies"(RIT++ 2016) 페스티벌의 일환으로 개최된 "지속적 배포 및 배포" 섹션은 "Docker를 사용한 지속적인 전달 모범 사례" 보고서와 함께 열렸습니다. Docker 및 기타 오픈 소스 제품을 사용하여 CD(지속적인 전달) 프로세스를 구축하기 위한 모범 사례를 요약하고 체계화했습니다. 우리는 생산 과정에서 이러한 솔루션을 사용하므로 실제 경험에 의존할 수 있습니다.

한 시간 정도 시간을 보낼 수 있는 기회가 있다면 보고서 영상, 전체 시청을 권장합니다. 그렇지 않은 경우 아래는 텍스트 형식의 주요 요약입니다.

Docker를 사용한 지속적 전달

아래의 연속 배달 우리는 Git 리포지토리의 애플리케이션 코드가 먼저 프로덕션에 들어온 다음 아카이브로 끝나는 일련의 이벤트를 이해합니다. 그녀는 다음과 같습니다 Git → 빌드 → 테스트 → 릴리스 → 운영.

보고서의 대부분은 빌드 단계(애플리케이션 어셈블리)에 할애되며 릴리스 및 운영 주제도 간략하게 다룹니다. 우리는 문제와 이를 해결할 수 있는 패턴에 대해 이야기할 것이며, 이러한 패턴의 구체적인 구현은 다를 수 있습니다.

Docker가 여기에 왜 필요한가요? 우리가 이 오픈 소스 도구의 맥락에서 지속적인 전달 방식에 대해 이야기하기로 결정한 것은 아무것도 아닙니다. 전체 보고서는 해당 용도에 대해 다루고 있지만 애플리케이션 코드 출시의 주요 패턴을 고려하면 많은 이유가 드러납니다.

기본 출시 패턴

따라서 새로운 버전의 애플리케이션을 출시할 때 우리는 확실히 다음과 같은 문제에 직면하게 됩니다. 다운타임 문제, 프로덕션 서버 전환 중에 생성됩니다. 이전 버전의 애플리케이션에서 새 버전으로의 트래픽은 즉시 전환할 수 없습니다. 먼저 새 버전이 성공적으로 다운로드되었을 뿐만 아니라 "준비"(즉, 요청을 처리할 준비가 완전히 완료되었는지) 확인해야 합니다.

따라서 한동안 두 버전의 애플리케이션(이전 버전과 새 버전)이 동시에 작동합니다. 자동으로 다음으로 연결됩니다. 공유 리소스 충돌: 네트워크, 파일 시스템, IPC 등 Docker를 사용하면 동일한 호스트(서버/가상 머신) 내에서 리소스 격리가 보장되는 별도의 컨테이너에서 다양한 버전의 애플리케이션을 실행하여 이 문제를 쉽게 해결할 수 있습니다. 물론 단열재 없이도 몇 가지 트릭을 사용할 수 있지만 기성품이고 편리한 도구가 있으면 무시하지 않는 반대 이유가 있습니다.

컨테이너화는 배포 시 다른 많은 이점을 제공합니다. 모든 애플리케이션은 다음에 따라 달라집니다. 특정 버전 (또는 버전 범위) 통역사, 모듈/확장 가용성 등 및 해당 버전. 그리고 이는 즉시 실행 가능한 환경뿐만 아니라 다음을 포함한 전체 환경에도 적용됩니다. 시스템 소프트웨어 및 해당 버전(사용된 Linux 배포판까지). 컨테이너에는 애플리케이션 코드뿐만 아니라 필요한 버전의 사전 설치된 시스템 및 애플리케이션 소프트웨어도 포함되어 있기 때문에 종속성 문제를 잊어버릴 수 있습니다.

일반화하자 기본 출시 패턴 다음 요소를 고려한 새 버전:

1. 처음에는 이전 버전의 애플리케이션이 첫 번째 컨테이너에서 실행됩니다.
2. 그런 다음 새 버전이 출시되고 두 번째 컨테이너에서 "준비"됩니다. 이 새 버전 자체에는 업데이트된 애플리케이션 코드뿐만 아니라 해당 종속성 및 시스템 구성 요소(예: OpenSSL의 새 버전 또는 전체 배포판)도 포함될 수 있다는 점은 주목할 만합니다.
3. 새 버전이 요청을 처리할 준비가 완전히 완료되면 트래픽이 첫 번째 컨테이너에서 두 번째 컨테이너로 전환됩니다.
4. 이제 이전 버전을 중지할 수 있습니다.

서로 다른 버전의 애플리케이션을 별도의 컨테이너에 배포하는 이러한 접근 방식은 또 다른 편의성을 제공합니다. 빠른 롤백 이전 버전으로 전환합니다(결국 트래픽을 원하는 컨테이너로 전환하는 것으로 충분합니다).

마지막 첫 번째 추천은 선장조차도 결점을 찾을 수 없는 것처럼 들립니다.[Docker로 Continuous Delivery를 구성할 때] 도커 사용 [그리고 그것이 무엇을 제공하는지 이해합니다]" 이것은 모든 문제를 해결할 수 있는 만병통치약이 아니라 훌륭한 기반을 제공하는 도구라는 점을 기억하십시오.

재현성

"재현성"이란 응용 프로그램을 실행할 때 직면하게 되는 일반화된 문제 집합을 의미합니다. 우리는 그러한 경우에 대해 이야기하고 있습니다.

• 스테이징을 위해 품질 부서에서 확인한 스크립트는 프로덕션에서 정확하게 재현되어야 합니다.
• 애플리케이션은 다양한 리포지토리 미러에서 패키지를 받을 수 있는 서버에 게시됩니다(시간이 지남에 따라 설치된 애플리케이션의 버전도 함께 업데이트됩니다).
• “모든 것이 현지에서 나에게 적합합니다!” (...개발자는 프로덕션에 참여할 수 없습니다.)
• 이전(보관된) 버전에서 확인해야 할 사항이 있습니다.
• ...

이들의 일반적인 본질은 사용된 환경의 완전한 준수(인적 요소의 부재 포함)가 필요하다는 사실로 귀결됩니다. 재현성을 어떻게 보장할 수 있나요? Docker 이미지 만들기 Git의 코드를 기반으로 테스트 사이트, 프로덕션, 프로그래머의 로컬 컴퓨터 등 모든 작업에 사용합니다. 동시에 수행되는 작업을 최소화하는 것이 중요합니다. 후 이미지 조립: 단순할수록 오류가 발생할 가능성이 줄어듭니다.

인프라는 코드이다

인프라 요구 사항(서버 소프트웨어의 가용성, 해당 버전 등)이 공식화 및 "프로그래밍"되지 않은 경우 애플리케이션 업데이트 출시는 재앙적인 결과를 초래할 수 있습니다. 예를 들어, 스테이징에서 이미 PHP 7.0으로 전환하고 이에 따라 코드를 다시 작성했습니다. 그러면 일부 오래된 PHP(5.5)를 사용하여 프로덕션에 나타나는 모습은 확실히 누군가를 놀라게 할 것입니다. 인터프리터 버전의 주요 변경 사항을 잊을 수는 없지만 "악마는 세부 사항에 있습니다": 종속성의 사소한 업데이트에 놀라움이 있을 수 있습니다.

이 문제를 해결하기 위한 접근 방식은 다음과 같습니다. IaC(코드로서의 인프라, “코드로서의 인프라”) 애플리케이션 코드와 함께 인프라 요구 사항을 저장하는 작업이 포함됩니다. 이를 사용하면 개발자와 DevOps 전문가는 동일한 Git 애플리케이션 저장소에서 작업할 수 있지만 서로 다른 부분에서 작업할 수 있습니다. 이 코드를 통해 Docker 이미지가 Git에 생성되며, 여기에서 인프라의 모든 세부 사항을 고려하여 애플리케이션이 배포됩니다. 간단히 말해서, 이미지 조합을 위한 스크립트(규칙)는 소스 코드와 동일한 저장소에 있어야 하며 함께 병합되어야 합니다.

다층 애플리케이션 아키텍처의 경우(예: Docker 컨테이너 내에서 이미 실행 중인 애플리케이션 앞에 nginx가 있음) Docker 이미지는 각 계층에 대해 Git의 코드에서 생성되어야 합니다. 그런 다음 첫 번째 이미지에는 인터프리터 및 기타 "밀접한" 종속성이 있는 애플리케이션이 포함되고 두 번째 이미지에는 업스트림 nginx가 포함됩니다.

Docker 이미지, Git과의 통신

Git에서 수집한 모든 Docker 이미지를 임시 이미지와 릴리스라는 두 가지 범주로 나눕니다. 임시 이미지 Git에서 브랜치 이름으로 태그가 지정되고 다음 커밋으로 덮어쓸 수 있으며 미리 보기용으로만 롤아웃됩니다(프로덕션용 아님). 이것이 릴리스와의 주요 차이점입니다. 어떤 특정 커밋이 있는지 알 수 없습니다.

마스터 브랜치(현재 마스터 버전을 지속적으로 확인하기 위해 별도의 사이트에 자동으로 롤아웃할 수 있음), 릴리스가 있는 브랜치, 특정 혁신의 브랜치 등 임시 이미지를 수집하는 것이 합리적입니다.

임시 이미지 미리보기를 프로덕션으로 변환해야 하는 경우 개발자는 특정 태그를 추가합니다. 태그별로 자동 수집 출시 이미지 (해당 태그는 Git의 태그에 해당함) 스테이징으로 롤아웃됩니다. 품질부서의 검증에 성공하면 생산에 들어갑니다.

dapp

설명된 모든 것(롤아웃, 이미지 어셈블리, 후속 유지 관리)은 Bash 스크립트 및 기타 "즉석" 도구를 사용하여 독립적으로 구현할 수 있습니다. 그러나 이렇게 하면 어느 시점에서 구현이 매우 복잡해지고 제어성이 저하될 수 있습니다. 이를 이해하여 우리는 CI/CD 구축을 위한 전문화된 워크플로우 유틸리티를 만들게 되었습니다. dapp.

소스 코드는 Ruby, 오픈 소스로 작성되었으며 다음에 게시되었습니다. GitHub의. 불행하게도 문서화는 현재 도구의 가장 약한 부분이지만 우리는 이에 대해 노력하고 있습니다. 그리고 우리는 dapp에 대해 한 번 이상 글을 쓰고 이야기할 것입니다. 왜냐하면... 우리는 관심 있는 전체 커뮤니티와 그 기능을 진심으로 공유하고 싶지만 그동안 문제와 끌어오기 요청을 보내거나 GitHub에서 프로젝트 개발을 따르십시오.

13년 2019월 XNUMX일 업데이트됨: 현재 프로젝트 dapp 이름이 워프, 코드가 Go에서 완전히 다시 작성되었으며 문서가 크게 개선되었습니다.

Kubernetes

전문적인 환경에서 이미 상당한 인정을 받은 또 다른 기성 오픈 소스 도구는 다음과 같습니다. Kubernetes, Docker 관리 클러스터. Docker 기반 프로젝트 운영에서 이를 사용하는 주제는 보고서 범위를 벗어나므로 프레젠테이션은 몇 가지 흥미로운 기능에 대한 개요로 제한됩니다.

출시를 위해 Kubernetes는 다음을 제공합니다.

• 준비 상태 프로브 - 새 버전의 애플리케이션 준비 상태를 확인합니다(트래픽을 해당 버전으로 전환하기 위해).
• 롤링 업데이트 - 컨테이너 클러스터의 순차적 이미지 업데이트(종료, 업데이트, 실행 준비, 트래픽 전환)
• 동기 업데이트 - 다른 접근 방식으로 클러스터의 이미지를 업데이트합니다. 먼저 컨테이너의 절반에서, 그다음 나머지에서 업데이트합니다.
• 카나리아 릴리스 - 제한된(소수) 수의 컨테이너에서 새 이미지를 시작하여 이상 현상을 모니터링합니다.

Continuous Delivery는 새 버전의 릴리스일 뿐만 아니라 Kubernetes에는 후속 인프라 유지 관리를 위한 다양한 기능(모든 컨테이너에 대한 내장 모니터링 및 로깅, 자동 확장 등)이 있습니다. 이 모든 기능은 이미 작동 중이며 적절한 조치를 기다리고 있습니다. 귀하의 프로세스에 구현하십시오.

최종 권장 사항

1. 도커를 사용하세요.
2. 모든 요구 사항에 맞는 애플리케이션의 Docker 이미지를 만듭니다.
3. "인프라는 코드이다"라는 원칙을 따르십시오.
4. Git을 Docker에 연결합니다.
5. 출시 순서를 규제합니다.
6. 기성 플랫폼(Kubernetes 또는 기타)을 사용하십시오.

비디오 및 슬라이드

공연영상(약 XNUMX시간) 유튜브에 게시됨 (리포트 자체는 5분부터 시작됩니다. 이 순간부터 플레이하려면 링크를 따라가세요).

보고서 발표:

PS

우리 블로그의 주제에 대한 다른 보고서:

• «werf - Kubernetes의 CI/CD용 도구(개요 및 비디오 보고서)» (Dmitry Stolyarov; 27년 2019월 XNUMX일 DevOpsConf에서);
• «데이터베이스와 Kubernetes» (Dmitry Stolyarov; HighLoad++에서 8년 2018월 XNUMX일);
• «Kubernetes 및 GitLab을 사용한 CI/CD 모범 사례» (Dmitry Stolyarov; HighLoad++에서 7년 2017월 XNUMX일);
• «소규모 프로젝트에서의 Kubernetes 경험» (Dmitry Stolyarov; 6년 2017월 XNUMX일 RootConf에서).

출처 : habr.com