php 및 docker 예제를 사용한 The Twelve-Factor App 방법론에 기반한 애플리케이션 개발 및 Blue-Green 배포

약간의 이론으로 시작합시다. 무슨 일이야 열두 요소 앱?

간단히 말해서 이 문서는 SaaS 애플리케이션의 개발을 단순화하도록 설계되었으며, 개발자와 DevOps 엔지니어가 최신 애플리케이션 개발에서 가장 자주 접하게 되는 문제와 사례를 인식하도록 돕습니다.

이 문서는 Heroku 플랫폼 개발자가 작성했습니다.

Twelve-Factor App 방법론은 모든 프로그래밍 언어로 작성되고 타사 지원 서비스(데이터베이스, 메시지 큐, 캐시 등)의 모든 조합을 사용하는 애플리케이션에 적용할 수 있습니다.

이 방법론의 기반이 되는 요소 자체에 대해 간략히 설명합니다.

1. 코드베이스 – 하나의 소스 추적 코드베이스 – 다중 배포
2. 종속성 – 종속성을 명시적으로 선언하고 분리
3. 구성 – 런타임 시 구성 저장
4. 타사 서비스(지원 서비스) – 지원 서비스를 플러그형 리소스로 취급
5. 빌드, 릴리스, 실행 – 엄격하게 분리된 빌드 및 실행 단계
6. 프로세스 - 애플리케이션을 하나 이상의 상태 비저장 프로세스로 실행
7. 포트 바인딩 – 포트 바인딩을 통한 내보내기 서비스
8. 병행 – 프로세스로 앱 확장
9. 일회용 – 빠른 시작 및 정상적인 종료로 안정성 극대화
10. 애플리케이션 개발/운영 패리티 – 개발, 스테이징 및 프로덕션 환경을 최대한 유사하게 유지
11. 벌채 반출 - 로그를 이벤트 스트림으로 처리
12. 관리 작업 – 일회성 프로세스로 관리/관리 업무 수행

12가지 요소에 대한 자세한 내용은 다음 리소스를 참조하세요.

• 공식 출처 - 필독
• Habr에 대한 기사. Twelve-Factor 앱 - Twelve-Factor 앱 - 공식 번역
• Habr에 대한 기사. 7 Factor 앱에서 누락된 12가지 요소 — 개선을 위해 12가지 요소를 새롭게 살펴봅니다.

블루-그린 배포란 무엇입니까?

Blue-Green 배포는 애플리케이션을 생산 최종 고객이 자신의 변경 사항을 보지 못하는 방식으로. 즉, XNUMX으로 애플리케이션을 배포하는 중단 시간.

클래식 BG Deploy 체계는 아래 이미지와 같습니다.

• 처음에는 코드, 애플리케이션, 프로젝트가 정확히 동일한 2개의 물리적 서버가 있고 라우터(밸런서)가 있습니다.
• 라우터는 처음에 모든 요청을 서버(녹색).
• 다시 릴리스를 해야 하는 순간 다른 서버에서 전체 프로젝트를 업데이트합니다(синий), 현재 요청을 처리하고 있지 않습니다.
• 코드 입력 후 푸른 서버가 완전히 업데이트되고 라우터는 다음에서 전환하라는 명령을 받습니다. 녹색 에 синий 서버.
• 이제 모든 클라이언트는 푸른 섬기는 사람.
• 몇 시간 동안, 녹색 배포에 실패한 경우 서버는 백업 역할을 합니다. синий 서버 및 오류 및 버그의 경우 라우터는 사용자 흐름을 다시 녹색 이전 안정 버전으로 서버에 저장하고 수정 및 테스트를 위해 새 코드를 보냅니다.
• 그리고 프로세스가 끝나면 같은 방식으로 업데이트됩니다. 녹색 섬기는 사람. 업데이트 후 라우터는 요청 흐름을 다시 다음으로 전환합니다. 녹색 서버.

그것은 모두 매우 좋아 보이며 언뜻보기에는 문제가 없어야합니다.
그러나 우리는 현대 사회에 살고 있기 때문에 고전적인 계획에 표시된 것처럼 물리적 전환 옵션은 우리에게 적합하지 않습니다. 지금은 정보를 기록하고 나중에 다시 살펴보겠습니다.

나쁜 조언과 좋은 조언

책임 부인: 아래 예제는 내가 사용하는 유틸리티/방법론을 보여줍니다. 비슷한 기능을 가진 대안을 절대적으로 사용할 수 있습니다.

대부분의 예제는 어떻게든 PHP 및 Docker를 사용하는 웹 개발과 교차할 것입니다.

아래 단락에는 특정 예에 대한 요소 사용에 대한 간단한 실제 설명이 있습니다. 이 주제에 대한 더 많은 이론을 얻으려면 위의 원본 소스 링크를 참조하십시오.

1. 코드베이스

FTP 및 FileZilla를 사용하여 파일을 한 번에 하나씩 서버에 업로드하고 프로덕션 서버를 제외한 다른 곳에 코드를 저장하지 마십시오.

프로젝트에는 항상 단일 코드 베이스가 있어야 합니다. 즉, 모든 코드는 하나의 코드 베이스에서 나옵니다. 힘내 저장소. 서버(프로덕션, 스테이징, 테스트1, 테스트2 ...)는 하나의 공유 리포지토리 분기의 코드를 사용합니다. 따라서 코드 일관성을 달성합니다.

2. 종속성

폴더의 모든 라이브러리를 프로젝트의 루트에 직접 다운로드합니다. 새 코드를 현재 버전의 라이브러리가 있는 폴더로 전송하여 간단하게 업데이트하십시오. 필요한 모든 유틸리티를 다른 20개의 서비스가 실행 중인 호스트 서버에 직접 배치하십시오.

프로젝트에는 항상 명확하게 이해할 수 있는 종속성 목록이 있어야 합니다(종속성이란 환경을 의미하기도 합니다). 모든 종속성은 명시적으로 정의되고 격리되어야 합니다.
예를 들어 보자 작곡가 и 도커.

작곡가 - PHP에 라이브러리를 설치할 수 있게 해주는 패키지 관리자. Composer는 버전을 엄격하게 지정하거나 엄격하지 않게 지정하고 명시적으로 정의할 수 있는 기능을 제공합니다. 서버에는 20개의 서로 다른 프로젝트가 있을 수 있으며 각 프로젝트에는 서로 독립적인 패키지 및 라이브러리의 개인 목록이 있습니다.

도커 - 응용 프로그램이 작동할 환경을 정의하고 격리할 수 있는 유틸리티입니다. 따라서 작곡가와 마찬가지로 더 철저하게 응용 프로그램이 무엇과 작동하는지 확인할 수 있습니다. 특정 버전의 PHP를 선택하고 추가 항목 없이 프로젝트가 작동하는 데 필요한 패키지만 설치합니다. 그리고 가장 중요한 것은 패키지와 호스트 시스템 및 기타 프로젝트의 환경을 방해하지 않는 것입니다. 즉, Docker를 통해 실행되는 서버의 모든 프로젝트는 절대적으로 모든 패키지 세트와 완전히 다른 환경을 사용할 수 있습니다.

3. 구성

코드에서 바로 상수로 구성을 저장합니다. 테스트 서버용 상수와 프로덕션용 상수를 분리합니다. if else 구문을 사용하여 프로젝트의 비즈니스 로직에서 직접 환경에 따라 애플리케이션 작업을 연결합니다.

구성 - 이것은 프로젝트 배포(배포)에서 달라야 하는 유일한 것입니다. 이상적으로 구성은 환경 변수(env vars)를 통해 전달되어야 합니다.

즉, 여러 구성 파일 .config.prod .config.local을 저장하고 배포 시 .config(응용 프로그램이 데이터를 읽는 기본 구성)로 이름을 바꾸더라도 이는 올바른 접근 방식이 아닙니다. 이 경우 구성 정보는 모든 애플리케이션 개발자가 공개적으로 사용할 수 있으며 프로덕션 서버의 데이터는 손상됩니다. 모든 구성은 배포 시스템(CI/CD)에 직접 저장되어야 하며 배포 시점에 특정 환경에 필요한 서로 다른 값으로 서로 다른 환경에 맞게 생성되어야 합니다.

4. 제XNUMX자 서비스(백킹 서비스)

환경에 단단히 묶고 특정 환경에서 동일한 서비스에 대해 다른 연결을 사용하십시오.

실제로 이 항목은 구성에 대한 항목과 강력하게 교차합니다. 이 항목이 없으면 정상적인 구성 데이터를 만들 수 없으며 일반적으로 구성 가능성이 사라지기 때문입니다.

큐 서버, 데이터베이스, 캐싱 서비스와 같은 외부 서비스에 대한 모든 연결은 로컬 환경과 타사/프로덕션 환경 모두에서 동일해야 합니다. 즉, 응용 프로그램 코드를 변경하지 않고 언제든지 연결 문자열을 변경하여 베이스 #1에 대한 호출을 베이스 #2로 바꿀 수 있습니다. 또는 예를 들어 서비스를 확장할 때 추가 캐시 서버에 대해 특별한 방식으로 연결을 표시할 필요가 없습니다.

5. 빌드, 릴리스, 실행

릴리스를 롤백할 기회 없이 서버에 코드의 최종 버전만 보관하십시오. 디스크 공간을 채울 필요가 없습니다. 오류가 있는 코드를 생산에 투입할 수 있다고 생각하는 사람은 나쁜 프로그래머입니다!

모든 배포 단계는 서로 분리되어야 합니다.

롤백할 기회가 있습니다. 오류가 발생할 경우 이전 버전을 복원하기 위해 애플리케이션의 이전 복사본(이미 조립되고 전투 준비가 됨)에 빠르게 액세스할 수 있는 릴리스를 만듭니다. 즉, 조건부로 폴더가 있습니다. 출시 및 폴더 current, 성공적인 배포 및 조립 후 폴더 current 내부에 있는 새 릴리스에 대한 심볼릭 링크와 연결되어 있습니다. 출시 릴리스 번호의 조건부 이름으로.

여기에서 우리는 Blue-Green 배포를 기억합니다. 코드 간을 전환할 수 있을 뿐만 아니라 모든 것을 롤백할 수 있는 기능을 통해 모든 리소스와 환경 간에도 전환할 수 있습니다.

6. 프로세스

애플리케이션 상태 데이터를 애플리케이션 자체에 직접 저장합니다. 응용 프로그램 자체의 RAM에서 세션을 사용합니다. 제XNUMX자 서비스 간에 공유할 수 있는 한 최대한 많이 사용하십시오. 응용 프로그램이 하나의 프로세스만 가질 수 있고 확장을 허용하지 않는다는 사실에 연결하십시오.

세션과 관련하여 타사 서비스(memcached, redis)에 의해 제어되는 캐시에만 데이터를 저장하므로 20개의 애플리케이션 프로세스가 실행 중인 경우에도 캐시에 액세스하는 모든 프로세스가 동일한 상태에서 클라이언트와 계속 작업할 수 있습니다. 사용자가 다른 프로세스에서 응용 프로그램을 사용하고 있었던 경우. 이 접근 방식을 사용하면 사용하는 타사 서비스 사본 수에 관계없이 데이터 액세스 문제없이 모든 것이 제대로 작동합니다.

7. 포트 바인딩

웹 서버만 타사 서비스와 작업하는 방법을 알아야 합니다. 그리고 일반적으로 웹 서버 내에서 바로 타사 서비스를 올리는 것이 좋습니다. 예를 들어 Apache의 PHP 모듈로.
모든 서비스는 일부 주소 및 포트(localgost:5432, localhost:3000, nginx:80, php-fpm:9000)에 대한 호출을 통해 서로 액세스할 수 있어야 합니다. 즉, nginx에서 php-fpm 및 postgres, php-fpm에서 postgres 및 nginx로, 그리고 각 서비스 자체에서 다른 서비스에 액세스할 수 있습니다. 따라서 서비스의 상태는 다른 서비스의 상태와 연결되지 않습니다.

8. 병렬성

하나의 프로세스로 작업하면 갑자기 여러 프로세스가 서로 어울리지 않게 됩니다!

크기 조정 옵션을 그대로 둡니다. Docker Swarm은 이에 적합합니다.
Docker Swarm은 서로 다른 시스템과 동일한 시스템의 여러 컨테이너 간에 컨테이너 클러스터를 생성하고 관리하기 위한 도구입니다.

swarm을 사용하여 각 프로세스에 할당할 리소스 수와 동일한 서비스의 프로세스 수를 결정할 수 있으며 지정된 포트에서 데이터를 수신하는 내부 밸런서가 자동으로 프로세스에 프록시합니다. 따라서 서버의 부하가 증가한 것을 확인하고 더 많은 프로세스를 추가하여 특정 프로세스의 부하를 줄일 수 있습니다.

9. 일회용

프로세스 및 데이터 작업에 대기열을 사용하지 마십시오. 하나의 프로세스를 종료하면 전체 애플리케이션의 작동에 영향을 미칩니다. 하나의 서비스가 중단되면 모든 서비스가 중단됩니다.

각 프로세스와 서비스는 언제든지 끌 수 있으며 이는 다른 서비스에 영향을 미치지 않아야 합니다. . 모든 프로세스는 부드럽게 종료되어야 종료 시 데이터가 영향을 받지 않고 다음에 시스템을 켤 때 올바르게 작동할 수 있습니다. 즉, 중단된 경우에도 데이터에 영향을 미치지 않아야 합니다(트랜잭션 메커니즘이 여기에 적합하고 데이터베이스에 대한 쿼리는 그룹에서만 작동하며 그룹에서 적어도 하나의 쿼리가 실패하거나 오류와 함께 실행된 경우) , 그룹의 다른 쿼리는 결국 실행되지 않습니다).

10. 애플리케이션 개발/운영 패리티

애플리케이션의 프로덕션, 스테이징 및 로컬 버전은 달라야 합니다. 프로덕션에서는 Yii Lite 프레임워크와 로컬 Yii가 있으므로 프로덕션에서 더 빠르게 작동합니다!

실제로 모든 배포 및 코드 작업은 거의 동일한 환경에 있어야 합니다(물리적 하드웨어에 대해 말하는 것이 아닙니다). 또한 모든 개발 직원은 필요한 경우 프로덕션에 코드를 배포할 수 있어야 하며 특수한 힘으로 인해 프로덕션에서만 애플리케이션을 올릴 수 있는 특수 교육을 받은 DevOps 부서가 아닙니다.

Docker도 이에 도움이 됩니다. 이전의 모든 사항에 따라 docker를 사용하면 프로덕션 환경과 로컬 시스템 모두에 환경을 배포하는 프로세스에서 하나 또는 두 개의 명령을 입력해야 합니다.

11. 로깅(로그)

우리는 파일과 데이터베이스에 로그를 기록합니다! 로그에서 파일과 데이터베이스를 정리하지 않습니다. 9000페타 바이트와 규범을 위한 하드 드라이브를 구입합시다.

모든 로그는 이벤트 스트림으로 간주되어야 합니다. 애플리케이션 자체가 로그 처리를 처리해서는 안 됩니다. 로그는 stdout으로 발행되거나 udp와 같은 프로토콜을 통해 전송되어야 애플리케이션이 로그에 문제를 일으키지 않습니다. Graylog는 이를 위해 잘 작동합니다. udp를 통해 모든 로그를 수락하는 Graylog(이 프로토콜을 사용하면 패킷의 성공적인 수신에 대한 응답을 기다릴 필요가 없음)는 어떠한 방식으로도 응용 프로그램을 방해하지 않으며 로그 구조화 및 처리에만 관여합니다. 응용 프로그램 논리는 이러한 접근 방식과 함께 작동하도록 변경되지 않습니다.

12. 관리 작업

데이터, 데이터베이스 등을 업데이트하려면 api에서 별도로 생성된 엔드포인트를 사용하십시오. 이 엔드포인트를 연속으로 2번 실행하면 모든 것이 복제될 수 있습니다. 그러나 당신은 바보가 아니며 두 번 클릭하지 않을 것이며 마이그레이션이 필요하지 않습니다.

모든 관리 작업은 릴리스 수준에서 모든 코드와 동일한 환경에서 수행되어야 합니다. 즉, 데이터베이스 구조를 변경해야 하는 경우 일종의 시각적 데이터베이스 관리 도구를 통해 열 이름을 변경하고 새 이름을 추가하여 수동으로 수행하지 않습니다. 이를 위해 별도의 스크립트를 생성합니다. 마이그레이션은 모든 환경에서 동일한 공통적이고 이해하기 쉬운 결과로 수행됩니다. 데이터로 프로젝트를 채우는 것과 같은 다른 모든 작업의 ​​경우 유사한 방법론을 적용해야 합니다.

PHP, Laravel, Laradock, Docker-Compose의 구현 예

PS 모든 예제는 MacOS에서 만들어졌습니다. 대부분은 Linux에서도 작동합니다. 죄송합니다, Windows 사용자 여러분, 저는 오랫동안 Windows를 사용하지 않았습니다.

PC에 어떤 버전의 PHP도 설치되어 있지 않고 아무 것도 설치되어 있지 않은 상황을 상상해 보십시오.
최신 버전의 docker 및 docker-compose를 설치합니다. (이것은 온라인에서 찾을 수 있습니다)

docker -v && 
docker-compose -v

1. 넣어 라라독

git clone https://github.com/Laradock/laradock.git && 
ls

Laradock에 관해서는 많은 컨테이너와 보조 항목이 수집되는 매우 멋진 일이라고 말할 것입니다. 그러나 생산을 수정하지 않고 Laradock을 그대로 사용하려면 중복성 때문에 권장하지 않습니다. Laradock의 예제를 기반으로 컨테이너를 만드는 것이 더 낫습니다. 그러면 거기에 있는 모든 것을 동시에 필요로 하는 사람이 없기 때문에 많은 최적화가 있을 것입니다.

2. 애플리케이션이 작동하도록 Laradock을 구성합니다.

cd laradock && 
cp env-example .env

2.1. 편집기에서 habr 디렉토리(laradock이 복제된 상위 폴더)를 엽니다. (내 PHPStorm의 경우)

이 단계에서는 프로젝트 이름만 입력합니다.

2.2. 작업 공간 이미지를 시작합니다. (귀하의 경우 이미지가 한동안 빌드됩니다)
Workspace는 개발자를 대신하여 프레임워크 작업을 위해 특별히 준비된 이미지입니다.

와 함께 컨테이너 내부로 이동

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. 라라벨 설치하기

composer create-project --prefer-dist laravel/laravel application

2.4. 설치 후 프로젝트가 있는 디렉토리가 생성되었는지 확인하고 Compose를 종료합니다.

ls
exit
docker-compose down

2.5. PHPStorm으로 돌아가서 .env 파일에서 laravel 애플리케이션의 올바른 경로를 설정합니다.

3. 모든 코드를 Git에 추가합니다.

이를 위해 Github(또는 다른 곳)에 리포지토리를 생성합니다. 터미널의 habr 디렉토리로 이동하여 다음 코드를 실행해 봅시다.

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

모든 것이 정상인지 확인합니다.

편의상 Git용 시각적 인터페이스를 사용하는 것이 좋습니다. GitKraken. (추천 링크는 여기)

4. 발사!

시작하기 전에 포트 80 및 443에 아무것도 걸려 있지 않은지 확인하십시오.

docker-compose up -d nginx php-fpm

따라서 우리 프로젝트는 3개의 개별 서비스로 구성됩니다.

• nginx - 웹 서버
• php-fpm - 웹 서버에서 요청을 수신하기 위한 php
• 작업 공간 - 개발자를 위한 PHP

현재 우리는 다음과 같이 4개 항목 중 12개 항목에 해당하는 애플리케이션을 만들었습니다.

1. 코드베이스 - 모든 코드는 하나의 저장소에 있습니다.

2. 종속성 - 우리의 모든 종속성은 application/composer.json과 각 컨테이너의 각 Dockerfile에 명시적으로 작성됩니다.

3. 타사 서비스(지원 서비스) - 각각의 서비스(php-fom, nignx, workspace)는 자신의 생명을 유지하며 외부에서 연결되어 하나의 서비스로 작업해도 다른 서비스에 영향을 미치지 않습니다.

4. 프로세스 각 서비스는 하나의 프로세스입니다. 각 서비스는 내부 상태를 저장하지 않습니다.

5. 포트 바인딩

docker ps

보시다시피 각 서비스는 자체 포트에서 실행되며 다른 모든 서비스에서 사용할 수 있습니다.

6. 병행

Docker를 사용하면 자동 로드 밸런싱을 통해 동일한 서비스의 여러 프로세스를 생성할 수 있습니다.

컨테이너를 중지하고 플래그로 시작 --규모

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

보시다시피 php-fpm 컨테이너에는 복사본이 있습니다. 이 컨테이너로 작업할 때 아무것도 변경할 필요가 없습니다. 또한 포트 9000에서 계속 액세스하고 Docker는 우리를 위해 컨테이너 간의 로드를 조절합니다.

7. 일회용 - 각 컨테이너는 다른 컨테이너에 해를 끼치지 않고 죽일 수 있습니다. 컨테이너를 중지하거나 다시 시작해도 후속 시작 시 애플리케이션 작동에 영향을 미치지 않습니다. 각 컨테이너는 언제든지 들어 올릴 수 있습니다.

8. 애플리케이션 개발/운영 패리티 우리의 모든 환경은 동일합니다. 프로덕션의 서버에서 시스템을 실행하면 명령에서 아무 것도 변경할 필요가 없습니다. 모든 것이 동일한 방식으로 Docker를 기반으로 합니다.

9. 벌채 반출 - 이러한 컨테이너의 모든 로그는 스트림으로 이동하고 Docker 콘솔에서 볼 수 있습니다. (이 경우 사실 다른 집에서 만든 용기로 관리를 안하면 안될수도 있습니다)

 docker-compose logs -f

다만, PHP나 Nginx의 Default 값도 파일에 로그를 쓴다는 점에서 함정이 있다. 12가지 요소를 충족하려면 다음이 필요합니다. 비활성화하다 각 컨테이너의 구성에서 개별적으로 파일에 로그를 기록합니다.

Docker는 stdout뿐만 아니라 위에서 언급한 graylog와 같은 항목에도 로그를 보낼 수 있는 기능을 제공합니다. 그리고 graylog 내에서 우리가 원하는 대로 로그로 작업할 수 있으며 응용 프로그램은 어떤 식으로든 이를 인식하지 못합니다.

10. 관리 작업 - 모든 관리 작업은 12개 요인 응용 프로그램의 제작자가 원하는 대로 정확하게 숙련공 도구 덕분에 laravel에 의해 해결됩니다.

예를 들어 일부 명령이 실행되는 방법을 보여 드리겠습니다.
우리는 컨테이너에 들어갑니다.

 
docker-compose exec workspace bash
php artisan list

이제 모든 명령을 사용할 수 있습니다. (데이터베이스와 캐시를 설정하지 않았으므로 명령의 절반은 캐시 및 데이터베이스와 함께 작동하도록 설계되었기 때문에 올바르게 실행되지 않습니다.)

11. 구성 그리고 12. 빌드, 릴리스, 실행

나는 이 부분을 Blue-Green Deployment에 할애하고 싶었지만, 이 기사에서 다루기에는 너무 자세한 내용이었습니다. 나는 이것에 대해 별도의 기사를 쓸 것입니다.

요컨대 개념은 다음과 같은 CI/CD 시스템을 기반으로 합니다. 젠킨스 и 깃랩 CI. 둘 다 특정 환경과 관련된 환경 변수를 설정할 수 있습니다. 따라서 이 시나리오에서 항목 c 구성.

그리고 에 대한 포인트 빌드, 릴리스, 실행 라는 두 유틸리티의 내장 함수로 해결 관로.

관로 어셈블리, 릴리스 및 실행 단계를 강조 표시하여 배포 프로세스를 여러 단계로 나눌 수 있습니다. 또한 Pipeline에서는 백업을 비롯한 무엇이든 만들 수 있습니다. 이 도구는 무한한 잠재력을 가지고 있습니다.

애플리케이션 코드가 켜져 있습니다. 깃허브.
이 리포지토리를 복제할 때 하위 모듈을 초기화하는 것을 잊지 마십시오.

추신: 이러한 모든 접근 방식은 다른 유틸리티 및 프로그래밍 언어와 함께 사용할 수 있습니다. 가장 중요한 것은 본질이 다르지 않다는 것입니다.

출처 : habr.com