Docker 및 Gitlab CI를 사용한 개발 및 테스트 프로세스

나는 Inventos "Docker + Gitlab CI를 사용한 개발 및 테스트 프로세스"에서 Alexander Sigachev의 보고서 사본을 읽을 것을 제안합니다.

Docker + Gitlab CI를 기반으로 개발 및 테스트 프로세스를 막 구현하기 시작한 사람들은 종종 기본적인 질문을 합니다. 어디서부터 시작해야 할까요? 정리하는 방법? 테스트하는 방법?

이 보고서는 Docker 및 Gitlab CI를 사용하여 개발 및 테스트 프로세스에 대해 구조화된 방식으로 설명하기 때문에 좋습니다. 보고서 자체는 2017년의 것입니다. 이 보고서에서 기본, 방법론, 아이디어, 사용 경험을 배울 수 있다고 생각합니다.

누가 신경 쓰나요, 고양이 밑에서 주세요.

제 이름은 Alexander Sigachev입니다. 저는 인벤토스에서 일합니다. Docker를 사용한 경험과 회사의 프로젝트에서 이를 점진적으로 구현하는 방법에 대해 말씀드리겠습니다.

발표 주제: Docker와 Gitlab CI를 이용한 개발 프로세스.

이것은 Docker에 대한 두 번째 이야기입니다. 첫 번째 보고 당시 우리는 개발자 컴퓨터의 개발에 Docker만 사용했습니다. Docker를 사용하는 직원은 2~3명 정도였습니다. 점차 경험이 쌓이고 조금 더 나아갔습니다. 우리에 대한 링크 첫 보고.

이 보고서에는 무엇이 포함됩니까? 어떤 갈퀴를 모았는지, 어떤 문제를 해결했는지에 대한 경험을 공유하겠습니다. 모든 곳이 아름답지는 않았지만 계속 나아갈 수있었습니다.

우리의 모토는 우리가 손에 넣을 수 있는 모든 것을 도킹하는 것입니다.

우리는 어떤 문제를 해결하고 있습니까?

회사에 여러 팀이 있을 때 프로그래머는 공유 리소스입니다. 프로그래머가 한 프로젝트에서 빠져나와 잠시 다른 프로젝트에 맡겨지는 단계가 있습니다.

프로그래머가 빨리 이해하려면 프로젝트의 소스 코드를 다운로드하고 가능한 한 빨리 환경을 시작해야 이 프로젝트의 문제를 더 해결할 수 있습니다.

일반적으로 처음부터 시작하면 프로젝트에 문서가 거의 없습니다. 설정 방법에 대한 정보는 고참에게만 제공됩니다. 직원들은 하루나 이틀 만에 직장을 스스로 마련합니다. 속도를 높이기 위해 Docker를 사용했습니다.

다음 이유는 Development의 설정 표준화입니다. 내 경험상 개발자는 항상 주도권을 잡습니다. 다섯 번째 경우마다 맞춤 도메인이 입력됩니다(예: vasya.dev). 그의 옆에는 도메인이 petya.dev인 이웃 Petya가 앉아 있습니다. 그들은 이 도메인 이름을 사용하여 웹 사이트 또는 시스템의 일부 구성 요소를 개발합니다.

시스템이 커지고 이러한 도메인 이름이 구성되기 시작하면 개발 환경 충돌이 발생하고 사이트 경로가 다시 작성됩니다.

데이터베이스 설정에서도 마찬가지입니다. 누군가는 보안에 신경 쓰지 않고 빈 루트 암호로 작업합니다. 설치 단계에서 MySQL은 누군가에게 암호를 물었고 암호는 123으로 밝혀졌습니다. 개발자의 커밋에 따라 데이터베이스 구성이 지속적으로 변경되는 경우가 종종 있습니다. 누군가 수정했고 누군가 구성을 수정하지 않았습니다. 우리가 어떤 종류의 테스트 구성을 꺼냈을 때 트릭이 있었습니다. .gitignore 각 개발자는 데이터베이스를 설치해야 했습니다. 이로 인해 시작하기가 어려웠습니다. 무엇보다도 데이터베이스에 대해 기억하는 것이 필요합니다. 데이터베이스를 초기화하고, 비밀번호를 입력하고, 사용자를 등록하고, 테이블을 생성해야 합니다.

또 다른 문제는 다른 버전의 라이브러리입니다. 개발자가 다른 프로젝트로 작업하는 경우가 종종 있습니다. 2017년 전(5.5년부터 - ed. note) 시작된 Legacy 프로젝트가 있습니다. 출시 당시에는 MySQL 5.7로 시작했습니다. 예를 들어 2017 이전 버전(XNUMX년 - ed. note)과 같이 보다 최신 버전의 MySQL을 구현하려는 최신 프로젝트도 있습니다.

MySQL로 작업하는 사람이라면 누구나 이러한 라이브러리가 종속성을 가져온다는 것을 알고 있습니다. 2개의 기지를 함께 운영하는 것은 다소 문제가 있습니다. 적어도 이전 클라이언트는 새 데이터베이스에 연결하는 데 문제가 있습니다. 이는 차례로 몇 가지 문제를 야기합니다.

다음 문제는 개발자가 로컬 컴퓨터에서 작업할 때 로컬 리소스, 로컬 파일, 로컬 RAM을 사용한다는 것입니다. 문제에 대한 솔루션을 개발할 때의 모든 상호 작용은 하나의 시스템에서 작동한다는 사실의 틀 내에서 수행됩니다. 예를 들어 프로덕션 3에 백엔드 서버가 있고 개발자가 파일을 루트 디렉터리에 저장하고 여기에서 nginx가 요청에 응답하기 위해 파일을 가져오는 경우입니다. 이러한 코드가 프로덕션에 들어가면 파일이 3개 서버 중 하나에 존재하는 것으로 밝혀집니다.

마이크로서비스의 방향은 현재 발전하고 있습니다. 대규모 응용 프로그램을 서로 상호 작용하는 작은 구성 요소로 나눌 때. 이를 통해 특정 작업 스택에 대한 기술을 선택할 수 있습니다. 또한 개발자 간에 작업과 책임을 공유할 수 있습니다.

JS에서 개발하는 Frondend 개발자는 Backend에 거의 영향을 미치지 않습니다. 백엔드 개발자는 우리의 경우 Ruby on Rails를 개발하고 Frondend를 방해하지 않습니다. 상호 작용은 API를 사용하여 수행됩니다.

보너스로 Docker의 도움으로 Staging에서 리소스를 재활용할 수 있었습니다. 각 프로젝트는 특성상 특정 설정이 필요했습니다. 물리적으로 가상 서버를 할당하고 별도로 구성하거나 일종의 변수 환경을 공유해야 하며 프로젝트는 라이브러리 버전에 따라 서로 영향을 줄 수 있습니다.

도구. 우리는 무엇을 사용합니까?

• 도커 자체. Dockerfile은 단일 애플리케이션의 종속성을 설명합니다.
• Docker-compose는 몇 가지 Docker 애플리케이션을 함께 제공하는 번들입니다.
• GitLab을 사용하여 소스 코드를 저장합니다.
• 우리는 시스템 통합을 위해 GitLab-CI를 사용합니다.

보고서는 두 부분으로 구성됩니다.

첫 번째 부분에서는 Docker가 개발자의 컴퓨터에서 실행되는 방식에 대해 설명합니다.

두 번째 부분에서는 GitLab과 상호 작용하는 방법, 테스트를 실행하는 방법 및 Staging으로 롤아웃하는 방법에 대해 설명합니다.

Docker는 (선언적 접근 방식을 사용하여) 필요한 구성 요소를 설명할 수 있는 기술입니다. 이것은 Dockerfile의 예입니다. 여기서 우리는 공식 Ruby:2.3.0 Docker 이미지에서 상속함을 선언합니다. Ruby 버전 2.3이 설치되어 있습니다. 필요한 빌드 라이브러리와 NodeJS를 설치합니다. 디렉토리를 생성한다고 설명합니다. /app. 앱 디렉터리를 작업 디렉터리로 설정합니다. 이 디렉토리에 필요한 최소한의 Gemfile과 Gemfile.lock을 배치합니다. 그런 다음 이 종속성 이미지를 설치하는 프로젝트를 빌드합니다. 컨테이너가 외부 포트 3000에서 수신할 준비가 되었음을 나타냅니다. 마지막 명령은 애플리케이션을 직접 시작하는 명령입니다. 프로젝트 시작 명령을 실행하면 응용 프로그램이 지정된 명령을 실행하려고 시도합니다.

이것은 docker-compose 파일의 최소 예입니다. 이 경우 두 컨테이너 간에 연결이 있음을 보여줍니다. 이것은 데이터베이스 서비스와 웹 서비스에 직접 연결됩니다. 대부분의 경우 웹 애플리케이션에는 데이터 저장을 위한 백엔드로 일종의 데이터베이스가 필요합니다. 우리는 MySQL을 사용하고 있기 때문에 예제는 MySQL이지만 다른 데이터베이스(PostgreSQL, Redis)를 사용하는 것을 방해하는 것은 없습니다.

Docker 허브의 공식 소스에서 MySQL 5.7.14의 이미지를 변경 없이 가져옵니다. 현재 디렉토리에서 웹 애플리케이션을 담당하는 이미지를 수집합니다. 처음 실행하는 동안 이미지를 수집합니다. 그런 다음 여기에서 실행 중인 명령을 실행합니다. 돌아가면 Puma를 통한 실행 명령이 정의된 것을 볼 수 있습니다. Puma는 Ruby로 작성된 서비스입니다. 두 번째 경우에는 재정의합니다. 이 명령은 필요 또는 작업에 따라 임의로 지정할 수 있습니다.

또한 개발자 호스트 시스템의 포트를 컨테이너 포트의 3000에서 3000으로 전달해야 한다고 설명합니다. 이는 Docker에 직접 내장된 iptables 및 해당 메커니즘을 사용하여 자동으로 수행됩니다.

이전과 마찬가지로 개발자는 사용 가능한 모든 IP 주소에 액세스할 수도 있습니다. 예를 들어 127.0.0.1은 시스템의 로컬 또는 외부 IP 주소입니다.

마지막 줄은 웹 컨테이너가 db 컨테이너에 의존한다고 말합니다. 웹 컨테이너의 시작을 호출하면 docker-compose가 먼저 데이터베이스를 시작합니다. 이미 데이터베이스 시작 시(실제로 컨테이너 실행 후! 이는 데이터베이스의 준비 상태를 보장하지 않음) 백엔드인 애플리케이션을 실행합니다.

이렇게 하면 데이터베이스가 실행되지 않을 때 오류를 방지하고 데이터베이스 컨테이너를 중지할 때 리소스를 절약하여 다른 프로젝트를 위한 리소스를 확보할 수 있습니다.

프로젝트에서 데이터베이스 고정화를 사용할 수 있는 이유는 무엇입니까? 모든 개발자를 위해 MySQL 버전을 수정합니다. 이렇게 하면 버전이 다를 때, 구문, 구성, 기본 설정이 변경될 때 발생할 수 있는 일부 오류를 피할 수 있습니다. 이렇게 하면 데이터베이스, 로그인, 암호에 대한 공통 호스트 이름을 지정할 수 있습니다. 우리는 이전에 가지고 있던 구성 파일의 이름과 충돌의 동물원에서 멀어지고 있습니다.

기본값과 다른 개발 환경에 대해 보다 최적의 구성을 사용할 수 있는 기회가 있습니다. MySQL은 기본적으로 취약한 시스템용으로 구성되어 있으며 기본적으로 성능이 매우 낮습니다.

Docker를 사용하면 원하는 버전의 Python, Ruby, NodeJS, PHP 인터프리터를 사용할 수 있습니다. 일종의 버전 관리자를 사용할 필요가 없습니다. 이전에 Ruby는 프로젝트에 따라 버전을 변경할 수 있는 rpm 패키지를 사용했습니다. 또한 Docker 컨테이너 덕분에 코드를 원활하게 마이그레이션하고 종속성과 함께 버전을 지정할 수 있습니다. 인터프리터와 코드의 버전을 이해하는 데 문제가 없습니다. 버전을 업데이트하려면 이전 컨테이너를 내리고 새 컨테이너를 올립니다. 문제가 발생하면 새 컨테이너를 내리고 이전 컨테이너를 올릴 수 있습니다.

이미지를 빌드한 후 개발 및 프로덕션의 컨테이너는 모두 동일합니다. 이것은 특히 대규모 설치에 해당됩니다.

Frontend에서는 JavaScipt와 NodeJS를 사용합니다.

이제 ReacJS에 대한 마지막 프로젝트가 있습니다. 개발자는 컨테이너의 모든 것을 실행하고 핫 리로드를 사용하여 개발했습니다.

다음으로 JavaScipt 어셈블리 작업이 시작되고 정적으로 컴파일된 코드가 nginx 저장 리소스를 통해 제공됩니다.

여기에서 나는 우리의 마지막 프로젝트의 계획을 제시했습니다.

어떤 작업이 해결되었습니까? 우리는 모바일 장치가 상호 작용하는 시스템을 구축할 필요가 있었습니다. 그들은 데이터를 받습니다. 한 가지 가능성은 이 장치에 푸시 알림을 보내는 것입니다.

이를 위해 우리는 무엇을 했습니까?

JS의 관리 부분, Ruby on Rails의 REST 인터페이스를 통해 작동하는 백엔드와 같은 구성 요소로 응용 프로그램을 나누었습니다. 백엔드는 데이터베이스와 상호 작용합니다. 생성된 결과는 클라이언트에 제공됩니다. 관리자 패널은 REST 인터페이스를 통해 백엔드 및 데이터베이스와 상호 작용합니다.

푸시 알림을 보낼 필요도 있었습니다. 그 전에는 모바일 플랫폼에 알림을 전달하는 메커니즘을 구현하는 프로젝트가 있었습니다.

우리는 다음 체계를 개발했습니다. 브라우저의 운영자는 관리자 패널과 상호 작용하고, 관리자 패널은 백엔드와 상호 작용하며, 작업은 푸시 알림을 보내는 것입니다.

푸시 알림은 NodeJS에 구현된 다른 구성 요소와 상호 작용합니다.

대기열이 구축된 다음 해당 메커니즘에 따라 알림이 전송됩니다.

여기에는 두 개의 데이터베이스가 그려져 있습니다. 현재 Docker의 도움으로 서로 관련이 없는 2개의 독립적인 데이터베이스를 사용하고 있습니다. 또한 공통 가상 네트워크가 있으며 물리적 데이터는 개발자 컴퓨터의 다른 디렉터리에 저장됩니다.

동일하지만 숫자입니다. 여기서 코드 재사용이 중요합니다.

이전에 라이브러리 형태의 코드 재사용에 대해 이야기했다면 이 예제에서는 푸시 알림에 응답하는 서비스가 완전한 서버로 재사용됩니다. API를 제공합니다. 그리고 우리의 새로운 개발은 이미 그것과 상호작용하고 있습니다.

당시 우리는 NodeJS 버전 4를 사용하고 있었습니다. 현재(2017년 - ed. note) 최근 개발에서는 NodeJS 버전 7을 사용합니다. 새로운 버전의 라이브러리를 포함하는 새로운 구성 요소에는 문제가 없습니다.

필요한 경우 푸시 알림 서비스에서 NodeJS 버전을 리팩터링하고 올릴 수 있습니다.

그리고 API 호환성을 유지할 수 있다면 이전에 사용했던 다른 프로젝트로 교체하는 것도 가능할 것입니다.

Docker를 추가하려면 무엇이 필요합니까? 필요한 종속성을 설명하는 Dockerfile을 리포지토리에 추가합니다. 이 예에서 구성 요소는 논리적으로 분류됩니다. 이것은 백엔드 개발자의 최소 집합입니다.

새 프로젝트를 만들 때 원하는 생태계(Python, Ruby, NodeJS)를 설명하는 Dockerfile을 만듭니다. docker-compose에서는 필요한 종속성인 데이터베이스를 설명합니다. 우리는 그러한 버전의 데이터베이스가 필요하고 거기에 데이터를 저장한다고 설명합니다.

정적 서비스를 제공하기 위해 nginx와 함께 별도의 세 번째 컨테이너를 사용합니다. 사진 업로드가 가능합니다. 백엔드는 정적을 제공하는 nginx가 있는 컨테이너에도 마운트되는 미리 준비된 볼륨에 넣습니다.

nginx, mysql 구성을 저장하기 위해 필요한 구성을 저장하는 Docker 폴더를 추가했습니다. 개발자가 자신의 컴퓨터에서 리포지토리의 git 복제를 수행하면 이미 로컬 개발을 위한 프로젝트가 준비된 것입니다. 어떤 포트나 어떤 설정을 적용할지 질문할 필요가 없습니다.

다음으로 admin, inform-API, 푸시 알림과 같은 여러 구성 요소가 있습니다.

이 모든 것을 시작하기 위해 우리는 dockerized-app이라는 또 다른 저장소를 만들었습니다. 현재 우리는 각 구성 요소 전에 여러 리포지토리를 사용합니다. 그들은 논리적으로 다릅니다. GitLab에서는 폴더처럼 보이지만 개발자 컴퓨터에서는 특정 프로젝트의 폴더입니다. 한 수준 아래는 결합될 구성 요소입니다.

이것은 dockerized-app의 내용에 대한 예시입니다. 또한 모든 구성 요소의 상호 작용에 필요한 구성을 채우는 Docker 디렉터리를 여기로 가져옵니다. 프로젝트 실행 방법을 간략하게 설명하는 README.md가 있습니다.

여기서는 두 개의 docker-compose 파일을 적용했습니다. 이는 단계적으로 실행할 수 있도록 수행됩니다. 개발자가 코어로 작업할 때 푸시 알림이 필요하지 않고 단순히 docker-compose 파일을 시작하므로 리소스가 저장됩니다.

푸시 알림과 통합해야 하는 경우 docker-compose.yaml 및 docker-compose-push.yaml이 시작됩니다.

docker-compose.yaml과 docker-compose-push.yaml이 한 폴더에 있기 때문에 하나의 가상 네트워크가 자동으로 생성됩니다.

구성품 설명. 구성 요소 수집을 담당하는 고급 파일입니다. 여기서 주목할만한 것은 무엇입니까? 여기에서 밸런서 구성 요소를 소개합니다.

이것은 nginx를 실행하는 기성품 Docker 이미지와 Docker 소켓에서 수신 대기하는 애플리케이션입니다. 동적으로 컨테이너를 켜고 끌 때 nginx 구성을 재생성합니다. 우리는 세 번째 수준의 도메인 이름으로 구성 요소 처리를 배포합니다.

개발 환경의 경우 .dev 도메인인 api.informer.dev를 사용합니다. .dev 도메인이 있는 애플리케이션은 개발자의 로컬 컴퓨터에서 사용할 수 있습니다.

또한 구성이 각 프로젝트로 전송되고 모든 프로젝트가 동시에 함께 시작됩니다.

그래픽으로 볼 때 클라이언트는 브라우저 또는 밸런서에 요청하는 도구인 것으로 나타났습니다.

도메인 이름 밸런서는 연결할 컨테이너를 결정합니다.

관리자 JS를 제공하는 nginx일 수 있습니다. 이것은 API를 제공하는 nginx이거나 이미지 업로드의 형태로 nginx에 제공되는 정적 파일일 수 있습니다.

다이어그램은 컨테이너가 가상 네트워크에 의해 연결되고 프록시 뒤에 숨겨져 있음을 보여줍니다.

개발자의 머신에서는 IP를 알고 있는 컨테이너에 접근할 수 있지만 원칙적으로 이를 사용하지 않습니다. 직접 액세스할 필요가 거의 없습니다.

애플리케이션을 도커화하기 위해 어떤 예를 살펴봐야 할까요? 제 생각에는 좋은 예가 MySQL의 공식 도커 이미지입니다.

꽤 도전적입니다. 많은 버전이 있습니다. 그러나 그 기능을 통해 추가 개발 과정에서 발생할 수 있는 많은 요구 사항을 충족할 수 있습니다. 시간을 보내고 모든 것이 어떻게 상호 작용하는지 파악하면 자체 구현에 문제가 없을 것이라고 생각합니다.

Hub.docker.com에는 일반적으로 직접 이미지를 빌드할 수 있는 원시 데이터가 포함된 github.com에 대한 링크가 포함되어 있습니다.

또한 이 리포지토리에는 초기 초기화 및 애플리케이션 시작의 추가 처리를 담당하는 docker-endpoint.sh 스크립트가 있습니다.

또한 이 예에서는 환경 변수를 사용하여 구성하는 기능이 있습니다. 단일 컨테이너를 실행할 때 또는 docker-compose를 통해 환경 변수를 정의함으로써 우리는 docker가 MySQL 또는 우리가 원하는 모든 루트에 대한 빈 암호를 설정해야 한다고 말할 수 있습니다.

임의의 암호를 생성하는 옵션이 있습니다. 우리는 사용자가 필요하고 사용자에 대한 암호를 설정해야 하며 데이터베이스를 만들어야 한다고 말합니다.

우리 프로젝트에서는 초기화를 담당하는 Dockerfile을 약간 통합했습니다. 거기에서 우리는 응용 프로그램이 사용하는 사용자 권한의 확장으로 만들기 위해 필요에 맞게 수정했습니다. 이를 통해 나중에 애플리케이션 콘솔에서 간단히 데이터베이스를 생성할 수 있었습니다. Ruby 애플리케이션에는 데이터베이스를 생성, 수정 및 삭제하는 명령이 있습니다.

이것은 github.com에서 MySQL의 특정 버전이 어떻게 보이는지에 대한 예입니다. Dockerfile을 열고 설치가 어떻게 진행되는지 확인할 수 있습니다.

docker-endpoint.sh는 진입점을 담당하는 스크립트입니다. 초기 초기화 중에 몇 가지 준비 단계가 필요하며 이러한 모든 작업은 초기화 스크립트에서만 수행됩니다.

두 번째 부분으로 넘어 갑시다.

소스 코드를 저장하기 위해 gitlab으로 전환했습니다. 이것은 시각적 인터페이스가 있는 상당히 강력한 시스템입니다.

Gitlab의 구성 요소 중 하나는 Gitlab CI입니다. 나중에 코드 전달 시스템을 구성하거나 자동 테스트를 실행하는 데 사용할 일련의 명령을 설명할 수 있습니다.

Gitlab CI 2 토크 https://goo.gl/uohKjI - Ruby Russia 클럽의 보고서 - 매우 상세하며 관심을 가질 것입니다.

이제 Gitlab CI를 활성화하기 위해 필요한 사항을 살펴보겠습니다. Gitlab CI를 시작하려면 프로젝트의 루트에 .gitlab-ci.yml 파일을 넣기만 하면 됩니다.

여기서는 테스트, 배포와 같은 일련의 상태를 실행하려고 한다고 설명합니다.

애플리케이션을 빌드하기 위해 docker-compose를 직접 호출하는 스크립트를 실행합니다. 이것은 단지 백엔드 예시일 뿐입니다.

다음으로 데이터베이스를 변경하고 테스트를 실행하기 위해 마이그레이션을 실행해야 한다고 말합니다.

스크립트가 올바르게 실행되고 오류 코드를 반환하지 않으면 시스템은 배포의 두 번째 단계를 진행합니다.

배포 단계는 현재 스테이징을 위해 구현됩니다. 가동 중지 시간이 없는 재시작을 구성하지 않았습니다.

우리는 모든 용기를 강제로 끈 다음 테스트 중 첫 번째 단계에서 수집한 모든 용기를 다시 들어 올립니다.

우리는 현재 환경 변수에 대해 개발자가 작성한 데이터베이스 마이그레이션을 실행하고 있습니다.

이것은 마스터 분기에만 적용된다는 참고 사항이 있습니다.

다른 분기를 변경할 때 실행되지 않습니다.

분기별로 롤아웃을 구성할 수 있습니다.

이를 더 체계화하려면 Gitlab Runner를 설치해야 합니다.

이 유틸리티는 Golang으로 작성되었습니다. 종속성이 필요하지 않은 Golang 세계에서 흔히 볼 수 있는 단일 파일입니다.

시작할 때 Gitlab Runner를 등록합니다.

Gitlab 웹 인터페이스에서 키를 얻습니다.

그런 다음 명령줄에서 초기화 명령을 호출합니다.

대화식으로 Gitlab Runner 설정(Shell, Docker, VirtualBox, SSH)

Gitlab Runner의 코드는 .gitlab-ci.yml 설정에 따라 모든 커밋에서 실행됩니다.

웹 인터페이스의 Gitlab에서 시각적으로 어떻게 보이는지. GItlab CI를 연결하고 나면 현재 빌드 상태를 나타내는 플래그가 있습니다.

커밋이 4분 전에 만들어졌고 모든 테스트를 통과했으며 문제가 발생하지 않았음을 알 수 있습니다.

빌드를 자세히 살펴볼 수 있습니다. 여기서 우리는 두 상태가 이미 통과되었음을 알 수 있습니다. 스테이징에서 상태 및 배포 상태를 테스트합니다.

특정 빌드를 클릭하면 .gitlab-ci.yml에 따라 프로세스에서 실행된 명령의 콘솔 출력이 나타납니다.

이것이 우리 제품 히스토리의 모습입니다. 성공적인 시도가 있었음을 알 수 있습니다. 테스트가 제출되면 다음 단계로 진행되지 않고 스테이징 코드가 업데이트되지 않습니다.

도커를 구현할 때 스테이징에서 어떤 작업을 해결했습니까? 우리 시스템은 구성 요소로 구성되어 있으며 전체 시스템이 아니라 리포지토리에서 업데이트된 구성 요소 중 일부만 다시 시작해야 했습니다.

이를 위해 모든 것을 별도의 폴더로 분쇄해야 했습니다.

이 작업을 수행한 후 Docker-compose가 각 아빠에 대한 자체 네트워크 공간을 생성하고 이웃의 구성 요소를 보지 못한다는 사실에 문제가 있었습니다.

우회하기 위해 Docker에서 수동으로 네트워크를 생성했습니다. 이 프로젝트에 이러한 네트워크를 사용한다고 Docker-compose로 작성되었습니다.

따라서 이 메시로 시작하는 각 구성 요소는 시스템의 다른 부분에 있는 구성 요소를 봅니다.

다음 문제는 스테이징을 여러 프로젝트로 분할하는 것입니다.

이 모든 것이 아름답고 생산에 최대한 가깝게 보이려면 WEB의 모든 곳에서 사용되는 포트 80 또는 443을 사용하는 것이 좋습니다.

어떻게 해결했습니까? 우리는 모든 주요 프로젝트에 하나의 Gitlab Runner를 할당했습니다.

Gitlab을 사용하면 여러 분산형 Gitlab Runner를 실행할 수 있습니다. 이 Runner는 혼란스러운 방식으로 모든 작업을 차례로 수행하고 실행합니다.

집이 없기 때문에 프로젝트 그룹을 볼륨 문제 없이 대처할 수 있는 Gitlab Runner 하나로 제한했습니다.

우리는 nginx-proxy를 별도의 시작 스크립트로 옮기고 그 안의 모든 프로젝트에 대한 그리드를 추가했습니다.

우리 프로젝트에는 하나의 그리드가 있고 밸런서에는 프로젝트 이름별로 여러 개의 그리드가 있습니다. 도메인 이름으로 더 프록시할 수 있습니다.

우리의 요청은 포트 80의 도메인을 통해 들어오고 이 도메인을 제공하는 컨테이너 그룹으로 확인됩니다.

또 어떤 문제가 있었나요? 이것은 모든 컨테이너가 기본적으로 루트로 실행되는 것입니다. 이것은 시스템의 루트 호스트와 다른 루트입니다.

그러나 컨테이너에 들어가면 루트가 되며 이 컨테이너에서 생성하는 파일은 루트 권한을 갖습니다.

개발자가 컨테이너에 들어가 파일을 생성하는 몇 가지 명령을 수행한 다음 컨테이너를 떠난 경우 액세스 권한이 없는 작업 디렉터리에 파일이 있는 것입니다.

어떻게 해결할 수 있습니까? 컨테이너에 포함될 사용자를 추가할 수 있습니다.

사용자를 추가할 때 어떤 문제가 발생했습니까?

사용자를 생성할 때 동일한 그룹 ID(UID)와 사용자 ID(GID)가 없는 경우가 많습니다.

컨테이너에서 이 문제를 해결하기 위해 ID가 1000인 사용자를 사용합니다.

우리의 경우 이것은 거의 모든 개발자가 Ubuntu OS를 사용한다는 사실과 일치했습니다. 그리고 Ubuntu에서 첫 번째 사용자의 ID는 1000입니다.

계획이 있습니까?

도커 설명서를 읽으십시오. 프로젝트가 활발히 진행 중이며 문서가 변경되고 있습니다. XNUMX~XNUMX개월 전에 받은 데이터는 이미 서서히 구식이 되어가고 있습니다.

우리가 해결한 문제 중 일부는 표준 수단으로 이미 해결되었을 가능성이 높습니다.

그래서 나는 오케스트레이션으로 직접 가기 위해 이미 더 나아가고 싶습니다.

한 가지 예는 바로 사용할 수 있는 Docker Swarm이라는 Docker의 기본 제공 메커니즘입니다. Docker Swarm 기술을 기반으로 프로덕션에서 무언가를 실행하고 싶습니다.

컨테이너를 생성하면 로그 작업이 불편해집니다. 이제 로그가 격리되었습니다. 그들은 컨테이너에 흩어져 있습니다. 작업 중 하나는 웹 인터페이스를 통해 로그에 편리하게 액세스하는 것입니다.

출처 : habr.com