GitLab CI/CD 및 Envoy로 Laravel 애플리케이션 테스트 및 배포
소개
GitLab은 애플리케이션을 지속적 통합으로 제공하며 새 코드 변경 사항을 원할 때 언제든지 프로덕션 서버에 쉽게 배포할 수 있습니다.
이 튜토리얼에서는 Laravel 애플리케이션을 초기화하고 Envoy 작업을 설정하는 방법을 보여주며, GitLab CI/CD 및 지속적인 전달을 통해 테스트하고 배포하는 방법을 살펴보겠습니다.
우리는 여러분이 Laravel, Linux 서버 기본 사항 및 GitLab 사용 방법에 대한 기본적인 경험이 있다고 가정합니다.
Laravel은 PHP로 작성된 고품질 웹 프레임워크입니다. 환상적인 문서를 갖춘 커뮤니티가 있습니다. 통상적인 라우팅, 컨트롤러, 요청, 응답, 뷰 및 (블레이드) 템플릿 외에 Laravel은 기본적으로 캐시, 이벤트, 지역화, 인증 및 기타 여러 가지 추가 서비스를 제공합니다.
우리는 PHP를 기반으로 하는 SSH 작업 실행기 Envoy를 사용할 것입니다. 클린하고 미니멀한 Blade 문법을 사용하여 리모트 서버에서 실행할 수 있는 작업을 설정합니다. 이를 통해 리포지토리에서 프로젝트를 복제하거나, Composer 종속성을 설치하고 Artisan 명령을 실행하는 등의 작업을 수행할 수 있습니다.
GitLab에서 Laravel 앱 초기화
우리는 새 Laravel 프로젝트를 설치했다고 가정하고, 이제 유닛 테스트를 시작하고 프로젝트용으로 Git을 초기화해봅시다.
유닛 테스트
현재 Laravel(버전 8.0)의 모든 새 설치에는 ‘Feature’ 및 ‘Unit’이라는 두 가지 유형의 테스트가 tests 디렉토리에 포함되어 있습니다. 다음은 test/Unit/ExampleTest.php
의 유닛 테스트 예시입니다:
<?php
namespace Tests\Unit;
...
class ExampleTest extends TestCase
{
public function testBasicTest()
{
$this->assertTrue(true);
}
}
이 테스트는 특정 값을 참으로 단언하는 것과 같습니다.
Laravel은 기본적으로 PHPUnit
을 사용합니다. vendor/bin/phpunit
을 실행하면 녹색 출력이 표시됩니다:
vendor/bin/phpunit
OK (1 test, 1 assertions)
이 테스트는 나중에 GitLab CI/CD로 앱을 지속적으로 테스트하는 데 사용될 것입니다.
GitLab으로 푸시
로컬에서 앱을 구동했다면, 이제 코드베이스를 원격 저장소에 푸시할 차례입니다. GitLab에서 laravel-sample
이라는 새 프로젝트를 만들어 보세요. 그 후 프로젝트 홈페이지에 표시된 명령 줄 지침을 따라 우리의 머신에서 저장소를 초기화하고 첫 번째 커밋을 푸시해봅시다.
cd laravel-sample
git init
git remote add origin git@gitlab.example.com:<USERNAME>/laravel-sample.git
git add .
git commit -m 'Initial Commit'
git push -u origin main
프로덕션 서버 설정
Envoy와 GitLab CI/CD를 설정하기 전에 빠르게 프로덕션 서버가 배포에 준비되어 있는지 확인해봅시다. 저희는 Ubuntu 16.04에 LEMP 스택(Linux, NGINX, MySQL 및 PHP)을 설치했습니다.
새 사용자 생성
우리는 이제 웹사이트를 배포하는 데 사용할 새 사용자를 만들고 Linux ACL을 사용하여 필요한 권한을 부여할 것입니다:
# deployer 사용자 생성
sudo adduser deployer
# /var/www 디렉토리에 대해 읽기-쓰기-실행 권한을 deployer 사용자에게 부여
sudo setfacl -R -m u:deployer:rwx /var/www
Ubuntu 서버에 ACL이 설치되어 있지 않다면 다음 명령을 사용하여 설치하세요:
sudo apt install acl
SSH 키 추가
GitLab의 개인 저장소에서 프로덕션 서버로 앱을 배포하고자 한다고 가정해보겠습니다. 먼저 배포자 사용자를 위해 암호 없는 새 SSH 키 쌍을 생성해야 합니다.
그 후 우리는 SSH를 사용하여 서버에 deployer 사용자로 연결할 비공개 키를 복사해 배포 프로세스를 자동화할 수 있도록 하고자 합니다:
# 서버상의 deployer 사용자로
#
# 공개 키 내용을 authorized_keys에 복사
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# 비공개 키 텍스트 블록을 복사
cat ~/.ssh/id_rsa
이제 이를 .gitlab-ci.yml
에서 우리의 원격 서버로 쉽게 deployer 사용자로 연결하기 위해 나중에 사용할 것입니다. 이는 보안 목적으로 .gitlab-ci.yml
밖에 저장된 사용자 정의 변수로써 프로젝트 CI/CD 변수입니다.
KEY 필드에 SSH_PRIVATE_KEY
라는 이름을 추가하고, VALUE 필드에 앞서 복사한 비공개 키를 붙여넣으세요. 이 변수는 나중에 .gitlab-ci.yml
에서 우리의 원격 서버에 암호를 입력하지 않고도 deployer 사용자로 쉽게 연결하기 위해 사용될 것입니다.
우리는 또한 서버로부터 SSH 프로토콜을 통해 우리의 저장소에 액세스할 수 있는 권한을 부여하는 배포 키로 이 공개 키를 프로젝트 > 설정 > 저장소에 추가해야 합니다.
# 서버상의 deployer 사용자로
#
# 공개 키 복사
cat ~/.ssh/id_rsa.pub
제목 필드에 원하는 이름을 추가하고, 공개 키를 키 필드에 붙여넣으세요.
이제 deployer
사용자가 저장소에 액세스할 수 있는지 확인하기 위해 서버에서 우리의 저장소를 복제해봅시다.
# 서버상의 deployer 사용자로
#
git clone git@gitlab.example.com:<USERNAME>/laravel-sample.git
Are you sure you want to continue connecting (yes/no)?
라는 메시지가 나오면 yes로 대답하세요. 이렇게 하면 GitLab.com이 알려진 호스트에 추가됩니다.
NGINX 구성
이제 웹 서버 구성이 public
이 아니라 current/public
을 가리키도록 합니다.
기본 NGINX 서버 블록 구성 파일을 다음과 같이 열어보세요.
sudo nano /etc/nginx/sites-available/default
구성은 다음과 같아야 합니다.
server {
root /var/www/app/current/public;
server_name example.com;
# 나머지 구성
}
/var/www/app/current/public
의 앱 이름을 해당 응용 프로그램의 폴더 이름으로 바꿀 수 있습니다.
Envoy 설정
그러면 Laravel 앱이 프로덕션을 위해 준비된 상태입니다. 다음으로 Envoy를 사용해 배포합니다.
Envoy를 사용하려면 먼저 라라벨에서 제공하는 지침을 사용하여 로컬 머신에 설치해야 합니다.
Envoy 작동 방식
Envoy의 장점은 블레이드 엔진이 필요하지 않으며 작업을 정의하는 데 블레이드 구문만 사용한다는 것입니다. 먼저 루트 폴더의 Envoy.blade.php
를 만들어 Envoy를 테스트하는 간단한 작업을 정의합니다.
@servers(['web' => 'remote_username@remote_host'])
@task('list', ['on' => 'web'])
ls -l
@endtask
@servers
디렉티브 안에 있는 배열은 키(web
)와 서버 주소(deployer@192.168.1.1
과 같은)를 포함하고 있습니다. 그런 다음 @task
디렉티브 안에는 작업이 실행될 때 서버에서 실행해야 하는 bash 명령어가 정의됩니다.
로컬 머신에서 run
명령어를 사용하여 Envoy 작업을 실행하세요.
envoy run list
이전에 정의한 list
작업이 실행되어 서버에 연결하고 디렉토리 내용을 나열해야 합니다.
Laravel의 종속성이 아닌 Envoy를 사용하기 때문에 PHP 애플리케이션에 대해 사용할 수 있습니다.
제로 다운타임 배포
프로덕션 서버로 배포할 때마다 Envoy는 GitLab 저장소에서 앱의 최신 릴리스를 다운로드하여 미리보기 릴리스로 교체합니다. Envoy는 이를 다운타임 없이 수행하므로 누군가가 사이트를 리뷰할 수 있는 동안 배포 중에 걱정할 필요가 없습니다. 저희 배포 계획은 GitLab 저장소에서 최신 릴리스를 복제하고 Composer 종속성을 설치한 후 새 릴리스를 활성화하는 것입니다.
@setup 디렉티브
배포 프로세스의 첫 번째 단계는 @setup 디렉티브 내에서 일련의 변수를 정의하는 것입니다. app
을 응용 프로그램의 이름으로 변경할 수 있습니다.
...
@setup
$repository = 'git@gitlab.example.com:<USERNAME>/laravel-sample.git';
$releases_dir = '/var/www/app/releases';
$app_dir = '/var/www/app';
$release = date('YmdHis');
$new_release_dir = $releases_dir .'/'. $release;
@endsetup
...
-
$repository
는 우리 저장소의 주소입니다. -
$releases_dir
디렉토리는 앱이 배포되는 위치입니다. -
$app_dir
는 서버에 설치된 앱의 실제 위치입니다. -
$release
에는 날짜가 포함되어 있어 앱의 새 릴리스를 배포할 때마다 현재 날짜로 된 새 폴더를 얻을 수 있습니다. -
$new_release_dir
는 작업을 더 깔끔하게 만들기 위해 사용되는 새 릴리스의 전체 경로입니다.
@story 디렉티브
@story 디렉티브는 단일 작업으로 실행할 수 있는 일련의 작업을 정의할 수 있게 합니다. 여기서 clone_repository
, run_composer
, update_symlinks
라는 세 개의 작업이 정의됩니다. 이러한 변수는 작업 코드를 더 깔끔하게 만드는 데 사용됩니다.
...
@story('deploy')
clone_repository
run_composer
update_symlinks
@endstory
...
이제 이 세 가지 작업을 하나씩 만들어 보겠습니다.
저장소 복제
첫 번째 작업은 releases
디렉토리를 만든 다음 (존재하지 않는 경우) 저장소의 main
브랜치(기본값)를 $new_release_dir
변수로 지정된 새 릴리스 디렉토리로 복제합니다. releases
디렉토리에는 모든 배포가 저장됩니다.
...
@task('clone_repository')
echo 'Cloning repository'
[ -d {{ $releases_dir }} ] || mkdir {{ $releases_dir }}
git clone --depth 1 {{ $repository }} {{ $new_release_dir }}
cd {{ $new_release_dir }}
git reset --hard {{ $commit }}
@endtask
...
프로젝트가 성장함에 따라 Git 히스토리는 시간이 지남에 따라 매우 길어질 것입니다. 릴리스마다 디렉토리를 만들기 때문에 각 릴리스에 프로젝트의 히스토리를 다운로드할 필요가 없을 수도 있습니다. --depth 1
옵션이 시스템 시간과 디스크 공간을 절약하는 훌륭한 솔루션입니다.
Composer를 사용하여 종속성 설치
이 작업은 새 릴리스 디렉토리로 이동하여 Composer를 실행하여 응용 프로그램 종속성을 설치합니다.
...
@task('run_composer')
echo "Starting deployment ({{ $release }})"
cd {{ $new_release_dir }}
composer install --prefer-dist --no-scripts -q -o
@endtask
...
새 릴리스 활성화
새 릴리스의 요구 사항을 준비한 후에는 해당 요구 사항에서 저장소 디렉터리를 제거하고 응용 프로그램의 storage
디렉토리와 .env
파일을 새 릴리스로 향하는 두 개의 심볼릭 링크를 만들어야 합니다. 그런 다음 응용 프로그램 디렉토리에 current
라는 이름으로 새 릴리스를 가리키는 또 다른 심볼릭 링크를 만들어야 합니다. current
심볼릭 링크는 항상 앱의 최신 릴리스를 가리킵니다.
...
@task('update_symlinks')
echo "Linking storage directory"
rm -rf {{ $new_release_dir }}/storage
ln -nfs {{ $app_dir }}/storage {{ $new_release_dir }}/storage
echo 'Linking .env file'
ln -nfs {{ $app_dir }}/.env {{ $new_release_dir }}/.env
echo 'Linking current release'
ln -nfs {{ $new_release_dir }} {{ $app_dir }}/current
@endtask
전체 스크립트
스크립트는 준비되었지만, deployer@192.168.1.1
을 사용하는 서버의 디렉토리로 변경하고 싶습니다. 그리고 /var/www/app
을 앱을 배포하려는 디렉토리로 변경하세요.
마지막으로, 우리의 Envoy.blade.php
파일은 다음과 같아야 합니다:
@servers(['web' => 'deployer@192.168.1.1'])
@setup
$repository = 'git@gitlab.example.com:<USERNAME>/laravel-sample.git';
$releases_dir = '/var/www/app/releases';
$app_dir = '/var/www/app';
$release = date('YmdHis');
$new_release_dir = $releases_dir .'/'. $release;
@endsetup
@story('deploy')
clone_repository
run_composer
update_symlinks
@endstory
@task('clone_repository')
echo '저장소 복제 중'
[ -d {{ $releases_dir }} ] || mkdir {{ $releases_dir }}
git clone --depth 1 {{ $repository }} {{ $new_release_dir }}
cd {{ $new_release_dir }}
git reset --hard {{ $commit }}
@endtask
@task('run_composer')
echo "배포 시작 ({{ $release }})"
cd {{ $new_release_dir }}
composer install --prefer-dist --no-scripts -q -o
@endtask
@task('update_symlinks')
echo "저장소 디렉토리 링크 중"
rm -rf {{ $new_release_dir }}/storage
ln -nfs {{ $app_dir }}/storage {{ $new_release_dir }}/storage
echo '.env 파일 링크 중'
ln -nfs {{ $app_dir }}/.env {{ $new_release_dir }}/.env
echo '현재 릴리스 링크 중'
ln -nfs {{ $new_release_dir }} {{ $app_dir }}/current
@endtask
어떤 배포 전에, 우리 애플리케이션 storage
폴더를 서버의 /var/www/app
디렉토리로 수동으로 복사해야 합니다.
그 일을 당신을 돕기 위해 다른 Envoy 작업을 만들고 싶을지도 모릅니다.
또한 Laravel을 위해 우리의 프로덕션 환경 변수를 설정하기 위해 동일한 경로에 .env
파일을 생성합니다.
이것들은 지속적인 데이터이며, 매번 새로운 릴리스에 대해 공유될 것입니다.
이제 envoy run deploy
를 실행하여 앱을 배포할 필요가 있지만, GitLab이 이 작업을 CI의 환경을 통해 자동으로 처리할 수 있기 때문에 그럴 필요는 없습니다. 이것은 이 튜토리얼의 후따른 설명될 것입니다.
이제 Envoy.blade.php를 커밋하고 main
브랜치로 푸시하는 시간입니다.
협업이 이 튜토리얼의 범위를 벗어나므로 기능 브랜치를 사용하지 않고 직접 main
에 커밋해야합니다.
실제 프로젝트에서 팀은 이슈 트래커와 병합 요청를 사용하여 코드를 여러 브랜치로 이동시킬 수 있습니다.
git add Envoy.blade.php
git commit -m 'Envoy 추가'
git push origin main
GitLab의 지속적 통합
우리는 GitLab에서 앱을 처리할 수 있게 하였고 또 수동으로 배포할 수도 있습니다. 그러나 지속적 전달 방법으로 자동으로 실행할 수 있도록 한 걸음을 나아가 보겠습니다. 가장 이른 시일에 문제를 인지하도록 매 커밋을 자동화된 테스트 세트로 검증하고, 그 이후에 테스트 결과에 만족하다면 대상 환경으로 배포할 수 있어야 합니다.
GitLab CI/CD는 Docker 엔진을 사용하여 앱의 테스트와 배포 과정을 처리할 수 있게 합니다. Docker에 익숙하지 않다면 자동화된 빌드 설정을 참조하세요.
GitLab CI/CD를 사용하여 앱을 빌드, 테스트 및 배포하려면 작업 환경을 준비해야 합니다. 이를 위해 Laravel 앱이 실행되기 위해 필요한 최소한의 요구 사항을 갖춘 Docker 이미지를 사용할 것입니다. 이 작업을 처리하기 위해 다른 방법이 있지만, 빠른 옵션이 있는 경우 빌드 속도가 느려질 수 있으므로 이해하기 힘들어합니다.
컨테이너 이미지 생성
우리의 앱의 루트 디렉토리에 다음 내용으로 Dockerfile을 만들어 보겠습니다:
# 작업 후속 명령을 위한 기본 이미지 설정
FROM php:7.4
# 패키지 업데이트
RUN apt-get update
# PHP 및 composer 종속성 설치
RUN apt-get install -qq git curl libmcrypt-dev libjpeg-dev libpng-dev libfreetype6-dev libbz2-dev
# 로컬 저장소에서 검색된 패키지 파일 지우기
RUN apt-get clean
# 필요한 확장 기능 설치
# 여기에서 테스트 및 배포 과정에서 필요한 다른 확장 기능을 설치할 수 있습니다
RUN docker-php-ext-install mcrypt pdo_mysql zip
# Composer 설치
RUN curl --silent --show-error "https://getcomposer.org/installer" | php -- --install-dir=/usr/local/bin --filename=composer
# Laravel Envoy 설치
RUN composer global require "laravel/envoy=~1.0"
우리는 공식 PHP 7.4 Docker 이미지를 추가하였으며, Debian buster의 최소 설치가 포함되어 있고, PHP가 미리 설치되어 있어 우리의 사용 사례에는 완벽합니다.
우리는 필요한 PHP 확장 기능을 설치하기 위해 docker-php-ext-install
(공식 PHP Docker 이미지에서 제공)을 사용하였습니다.
GitLab 컨테이너 레지스트리 설정
이제 우리가 Dockerfile
을 갖고 있는데 이것을 GitLab 컨테이너 레지스트리에 빌드하고 푸시해 보겠습니다.
레지스트리는 이미지를 나중에 사용하기 위해 저장하고 태깅하는 곳입니다. 개발자들은 비공개 이미지를 위해 자신의 레지스트리를 유지하기 원할 수 있으며, 테스트에서만 사용되는 일회성 이미지를 위해 공개 레지스트리를 사용하기 원할 수 있습니다. GitLab 컨테이너 레지스트리를 사용하면 또 다른 서비스를 설정하고 관리할 필요가 없으며 또는 공개 레지스트리를 사용할 필요가 없습니다.
GitLab 프로젝트 저장소에서 Registry 탭으로 이동하세요.
이 탭을 보기 위해서는 프로젝트의 Settings > General > Visibility, project features, permissions로 이동해 컨테이너 레지스트리를 활성화해야 할 수도 있습니다.
머신에 컨테이너 레지스트리를 사용하기 위해 우리는 먼저 GitLab 사용자 이름과 비밀번호를 사용하여 GitLab 레지스트리에 로그인해야 합니다. 먼저 머신에 Docker가 설치되어 있는지 확인하세요. 그런 다음 다음 명령을 실행하세요:
docker login registry.gitlab.com
그런 다음 이미지를 빌드하고 GitLab에 푸시할 수 있습니다:
docker build -t registry.gitlab.com/<USERNAME>/laravel-sample .
docker push registry.gitlab.com/<USERNAME>/laravel-sample
축하합니다! 첫 번째 Docker 이미지를 GitLab 레지스트리에 성공적으로 푸시했습니다. 페이지를 새로 고쳐 이 이미지를 확인할 수 있어야 합니다:
또한 이미지를 빌드하고 머신에서 푸시하는 대신 GitLab CI/CD를 사용하여 Docker 이미지를 빌드하고 푸시할 수 있습니다.
이 이미지를 .gitlab-ci.yml
구성 파일에서 앱의 테스트와 배포 과정을 처리하기 위해 더 이상 사용하게 될 것입니다.
Dockerfile
파일을 커밋해 보겠습니다.
git add Dockerfile
git commit -m 'Dockerfile 추가'
git push origin main
GitLab CI/CD 설정
GitLab CI/CD를 사용하여 앱을 빌드하고 테스트하려면 저장소 루트에 .gitlab-ci.yml
이라는 파일이 필요합니다. 이는 Circle CI와 Travis CI와 유사하지만 GitLab에 내장되어 있습니다.
우리의 .gitlab-ci.yml
파일은 다음과 같을 것입니다:
default:
image: registry.gitlab.com/<USERNAME>/laravel-sample:latest
services:
- mysql:5.7
...
구동 에이전트는 .gitlab-ci.yml
에 정의된 스크립트를 실행합니다.
image
키워드는 구동 에이전트가 사용할 이미지를 지정합니다.
services
키워드는 주 이미지에 연결된 추가 이미지를 정의합니다.
여기서 우리는 이전에 만든 컨테이너 이미지를 주 이미지로 사용하고 MySQL 5.7을 서비스로 사용합니다.
default:
image: registry.gitlab.com/<USERNAME>/laravel-sample:latest
services:
- mysql:5.7
...
…
GitLab CI/CD를 사용하면 CI/CD 변수를 작업에서 사용할 수 있습니다. 우리는 기본적으로 루트로 생성된 슈퍼 유저 root가 있는 MySQL을 데이터베이스 관리 시스템으로 정의했습니다.
데이터베이스 이름으로 MYSQL_DATABASE
변수와 root
의 비밀번호로 MYSQL_ROOT_PASSWORD
변수를 정의하여 MySQL 인스턴스의 구성을 조정해야 합니다.
공식 MySQL 도커 이미지에서 MySQL 변수에 대해 더 알아보십시오.
또한 DB_HOST
를 mysql
로, DB_USERNAME
를 root
로 설정합니다. 이는 라라벨 특정 변수입니다.
우리는 MySQL 도커 이미지를 서비스로 사용하며 주 도커 이미지에 연결된 서비스로 사용하기 때문에 DB_HOST
를 127.0.0.1
이 아닌 mysql
로 정의합니다.
variables:
MYSQL_DATABASE: homestead
MYSQL_ROOT_PASSWORD: secret
DB_HOST: mysql
DB_USERNAME: root
…
unit_test
작업에서 실행될 스크립트 키워드의 배열로 필요한 셸 스크립트를 정의했습니다.
이러한 스크립트는 라라벨을 준비하는 몇 가지 Artisan 명령이며, 스크립트의 끝에 우리는 PHPUnit
으로 테스트를 실행할 것입니다.
unit_test:
script:
# 앱 종속성 설치
- composer install
# .env 설정
- cp .env.example .env
# 환경 키 생성
- php artisan key:generate
# 마이그레이션 실행
- php artisan migrate
# 테스트 실행
- vendor/bin/phpunit
deploy_production
작업은 앱을 프로덕션 서버에 배포합니다.
Envoy를 사용하여 앱을 배포하려면 SSH 개인 키를 설정해야 했습니다.
SSH 키가 성공적으로 추가되면 Envoy를 실행할 수 있습니다.
앞에서 언급했듯이, GitLab은 지속적 배포 방법도 지원합니다.
environment
키워드는 GitLab에 이 작업이 production
환경으로 배포됨을 알립니다.
url
키워드는 GitLab 환경 페이지에서 우리 애플리케이션에 대한 링크를 생성하는 데 사용됩니다.
rules:if
키워드는 이 작업이 main
브랜치를 빌드할 때에만 실행되어야 함을 GitLab CI/CD에 알립니다.
마지막으로 when: manual
은 작업을 자동으로 실행하는 것에서 수동 조치로 변경합니다.
deploy_production:
script:
# 개인 SSH 키를 빌드 환경에 추가
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
- eval $(ssh-agent -s)
- ssh-add <(echo "$SSH_PRIVATE_KEY")
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
# Envoy 실행
- ~/.composer/vendor/bin/envoy run deploy
environment:
name: production
url: http://192.168.1.1
when: manual
rules:
- if: $CI_COMMIT_BRANCH == "main"
배포 환경에 대해 추가 작업을 추가하여 프로덕션 배포 전에 애플리케이션을 최종 테스트할 수도 있습니다.
GitLab CI/CD 활성화하기
우리는 GitLab CI/CD로 앱을 테스트하고 배포하는 데 필요한 모든 것을 준비했습니다.
이를 위해 .gitlab-ci.yml
을 main
브랜치에 커밋하고 푸시하면 파이프라인이 트리거되며, 이를 프로젝트의 파이프라인에서 실시간으로 확인할 수 있습니다.
여기서 우리는 테스트와 배포 단계를 볼 수 있습니다.
테스트 단계에는 unit_test
빌드가 실행 중입니다.
이를 선택하여 구동 에이전트의 출력을 확인할 수 있습니다.
코드가 성공적으로 파이프라인을 거쳤다면, 오른쪽에 있는 실행()을 선택하여 프로덕션 서버에 배포할 수 있습니다.
배포 파이프라인이 성공적으로 통과하면 파이프라인 > 환경으로 이동합니다.
원하는 대로 작동하지 않으면, 앱의 최신 작동 버전으로 롤백할 수 있습니다.
이 아플리케이션 구조가 배포 이후 프로덕션 서버에서 어떻게 보이는지 궁금하다면, current
, releases
, storage
라는 세 개의 디렉토리가 있습니다.
current
디렉토리는 최신 릴리스를 가리키는 심볼릭 링크입니다.
.env
파일은 라라벨 환경 변수가 포함됩니다.
current
디렉토리에 이동하면 애플리케이션 내용을 볼 수 있습니다.
current
디렉토리로 들어가보면, .env
가 /var/www/app/.env
파일을 가리키고, storage
가 /var/www/app/storage/
디렉토리를 가리키는 것을 확인할 수 있습니다.
결론
우리는 GitLab CI/CD를 구성하여 자동화된 테스트를 수행하고, Continuous Delivery 방법을 사용하여 Laravel 애플리케이션을 코드베이스에서 직접 Envoy를 통해 프로덕션 환경에 배포했습니다.
또한, Envoy는 우리가 사용자 정의 bash 스크립트를 작성하지 않고 Linux 마법을 사용하지 않고 애플리케이션을 배포하는 데 큰 도움이 되었습니다.