GitLab CI/CD 및 Envoy로 Laravel 애플리케이션 테스트 및 배포

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

소개

GitLab은 지속적 통합(Continuous Integration)을 통해 애플리케이션을 테스트하고, 원하는 시점에 신규 코드 변경 사항을 쉽게 프로덕션 서버에 배포할 수 있습니다.

이 튜토리얼에서는 Laravel 애플리케이션을 초기화하고 Envoy 작업을 설정한 다음, GitLab CI/CD 및 지속적 전달(Continuous Delivery)를 통해 테스트하고 배포하는 방법을 안내합니다.

Laravel, Linux 서버의 기본적인 지식, 그리고 GitLab 사용 방법에 대한 기본적인 경험이 있다고 가정합니다.

Laravel은 PHP로 작성된 고품질 웹 프레임워크입니다. 놀라운 문서를 제공하는 훌륭한 커뮤니티를 갖고 있으며, 라우팅, 컨트롤러, 요청, 응답, 뷰 및 (블레이드) 템플릿뿐만 아니라 캐시, 이벤트, 로케일화, 인증 등 다양한 추가 서비스를 기본으로 제공합니다.

우리는 PHP 기반의 SSH 작업 실행기로 Envoy를 사용할 것입니다. 이는 깨끗하고 간소한 블레이드 구문을 사용하여 리모트 서버에서 실행할 작업을 설정하는 데 사용됩니다. 예를 들면, 리포지터리에서 프로젝트를 복제하거나, 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);
    }
}

이 테스트는 주어진 값이 true인지 확인하는 매우 간단한 테스트입니다.

Laravel은 기본적으로 PHPUnit을 사용합니다. vendor/bin/phpunit을 실행하면 녹색 출력을 확인할 수 있어야 합니다.

vendor/bin/phpunit
OK (1 test, 1 assertions)

이 테스트는 나중에 GitLab CI/CD를 통해 앱을 계속 테스트하는 데 사용될 것입니다.

GitLab에 푸시

로컬에서 앱을 실행한 상태이므로, 이제 코드베이스를 원격 리포지터리에 푸시해야 합니다. laravel-sample이라는 이름의 새 프로젝트를 GitLab에 만든 후, 프로젝트 홈페이지에 표시된 명령줄 지침을 따라 기계에서 리포지터리를 초기화하고 첫 번째 커밋을 푸시합니다.

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 키 쌍을 생성해야 합니다. 그 후, 해당 프로젝트의 CI/CD 변수로 SSH_PRIVATE_KEY를 추가하고, 공개 키를 프로젝트 > 설정 > 리포지터리의 배포 키(Deploy Key)로 추가합니다.

그 후에, 키를 사용하여 원격 서버에 연결할 수 있는지 확인하기 위해 서버에서 리포지터리를 복제해봅시다.

NGINX 구성

웹 서버 구성이 current/public이 아닌 public을 가리키도록 수정해봅시다.

server {
    root /var/www/app/current/public;
    server_name example.com;
    # 기타 설정
}

위의 경로 /var/www/app/current/public에서 앱 이름을 본사 애플리케이션의 폴더 이름으로 바꿔주시면 됩니다.

Envoy 설정

이제 Laravel 앱이 프로덕션 배포 준비가 되었습니다. 이제 Envoy를 사용하여 배포해봅시다.

Envoy를 사용하려면, 먼저 Laravel에서 제공하는 지침을 따라 로컬 머신에 Envoy를 설치해야합니다.

Envoy 작동 방식

Envoy는 Blade 엔진이 필요하지 않으며, 작업을 정의하기 위해 블레이드 구문만 사용합니다. 먼저 앱의 루트에 Envoy.blade.php를 만들고 간단한 작업을 정의해보겠습니다.

@servers(['web' => 'remote_username@remote_host'])

@task('list', ['on' => 'web'])
    ls -l
@endtask

위의 코드에서 @servers 지시문 내에는 서버 주소(‘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 '리포지터리 복제중'
    [ -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 "배포 시작 ({{ $release }})"
    cd {{ $new_release_dir }}
    composer install --prefer-dist --no-scripts -q -o
@endtask

...

새 릴리스 활성화

새 릴리스의 요구 사항을 준비한 후에 하는 다음 작업은, storage 디렉터리를 제거하고 애플리케이션의 storage 디렉터리 및 .env 파일을 새 릴리스로 가리키는 두 개의 심볼릭 링크를 생성하는 것입니다. 그런 다음, 앱 디렉터리에 current라는 이름으로 새 릴리스에 대한 또 다른 심볼릭 링크를 생성해야 합니다. current 심볼릭 링크는 우리 앱의 최신 릴리스를 항상 가리킵니다:

...

@task('update_symlinks')
    echo "storage 디렉터리 링크 설정"
    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

ln 명령에 대한 옵션으로 -nfs를 사용하는데, 이것은 storage, .env 및 current이 더 이상 미리보기 릴리스를 가리키지 않고 강제로 새 릴리스를 가리키도록 하는 것을 의미합니다 (-nfs에서 -f는 강제로 한다는 의미입니다). 이것은 여러 배포를 수행할 때의 경우입니다.

완전한 스크립트

스크립트는 준비되었지만, 반드시 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 "storage 디렉터리 링크 설정"
    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

어떤 배포 전에 한 가지 더 해야 할 일은, 첫 번째 배포 시에 서버의 /var/www/app 디렉터리로 애플리케이션 storage 폴더를 매뉴얼으로 복사하는 것입니다. 또한 Laravel을 위한 프로덕션 환경 변수를 설정하기 위해 /var/www/app 경로에 .env 파일을 만들어야 할 것입니다. 이것은 지속적인 데이터입니다. 새 릴리스로 공유될 것입니다.

이제 envoy run deploy를 실행하여 앱을 배포해야 할 것입니다, 그런데 이 작업은 필요하지 않을 것입니다. 왜냐하면 GitLab은 환경을 통해 CI가 자동으로 처리할 수 있기 때문입니다. 이는 이 튜토리얼의 나중에 설명할 것입니다.

이제 Envoy.blade.php를 커밋하고 main 브랜치에 푸시해야 합니다. 이 튜토리얼의 범위를 벗어나므로 피처 브랜치를 사용하지 않고 직접 main에 커밋하겠습니다. 실제 프로젝트에서 팀들은 이슈 트래커 및 Merge Request을 사용하여 코드를 브랜치 간에 이동할 수 있습니다:

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 이미지를 사용할 것입니다. 또한 기타 방법도 있지만, 이러한 방법을 사용하면 빌드가 느려질 수 있으므로 더 빠른 옵션을 사용해야 합니다.

컨테이너 이미지 생성

Root 디렉터리에 다음 내용을 갖춘 Dockerfile을 생성해 봅시다.

# 후속 지시에 대한 기본 이미지 설정
FROM php:7.4

# 패키지 업데이트
RUN apt-get update

# PHP 및 컴포저 의존성 설치
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

# 컴포저 설치
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 이미지를 추가했는데, 이것은 PHP가 사전 설치된 Debian buster의 최소 설치로 우리의 사용 사례에 완벽하게 작동합니다.

우리는 필요한 PHP 확장 기능을 설치하기 위해 docker-php-ext-install(공식 PHP Docker 이미지에서 제공함)를 사용했습니다.

GitLab 컨테이너 레지스트리 설정

이제 Dockerfile이 준비되었으니 GitLab 컨테이너 레지스트리에 이미지를 빌드하고 푸시해 봅시다.

레지스트리는 이미지를 저장하고 나중에 사용하기 위한 곳입니다. 개발자는 사설이나 회사 이미지, 또는 테스트에만 사용되는 일회용 이미지를 유지하고 싶어할 수 있습니다. GitLab 컨테이너 레지스트리를 사용하면 또 다른 서비스를 설정하고 관리할 필요가 없으며, 공개 레지스트리를 사용할 필요도 없습니다.

GitLab 프로젝트 리포지터리에서 레지스트리 탭으로 이동합니다.

이 탭을 보려면 프로젝트의 설정 > 일반 > 가시성, 프로젝트 기능, 권한 아래에서 컨테이너 레지스트리를 활성화해야 할 수 있습니다.

자신의 머신에서 컨테이너 레지스트리를 사용하려면 먼저 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

축하합니다! 첫 번째 도커 이미지를 GitLab 레지스트리에 푸시했습니다. 페이지를 새로고침하면 이미지가 표시됩니다.

또한 컴퓨터에서 그렇게 하는 대신 GitLab CI/CD를 사용하여 도커 이미지를 빌드하고 푸시할 수 있습니다.

이 이미지를 나중에 .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

variables:
  MYSQL_DATABASE: homestead
  MYSQL_ROOT_PASSWORD: secret
  DB_HOST: mysql
  DB_USERNAME: root

stages:
  - test
  - deploy

unit_test:
  stage: test
  script:
    - cp .env.example .env
    - composer install
    - php artisan key:generate
    - php artisan migrate
    - vendor/bin/phpunit

deploy_production:
  stage: deploy
  script:
    - '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'
    - ~/.composer/vendor/bin/envoy run deploy --commit="$CI_COMMIT_SHA"
  environment:
    name: production
    url: http://192.168.1.1
  when: manual
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

정말 많은 내용이군요? 한 단계씩 살펴보겠습니다.

이미지와 서비스

러너(runner)들은 .gitlab-ci.yml에서 정의된 스크립트를 실행합니다. image 키워드는 러너에게 사용할 이미지를 알려줍니다. services 키워드는 주 이미지에 링크된 추가 이미지를 정의합니다. 여기서 우리는 이전에 만든 컨테이너 이미지를 주 이미지로 사용하고 MySQL 5.7을 서비스로 사용합니다.

default:
  image: registry.gitlab.com/<USERNAME>/laravel-sample:latest
  services:
    - mysql:5.7

...

다양한 PHP 버전 및 데이터베이스 관리 시스템으로 앱을 테스트하려면 각 테스트 작업에 대해 다른 image 및 services 키워드를 정의할 수 있습니다.

CI/CD 변수

GitLab CI/CD는 작업에서 CI/CD 변수를 사용할 수 있습니다. 기본적으로 MySQL은 기본적으로 생성된 슈퍼유저 루트로 제공됩니다.

따라서 MySQL을 데이터베이스 관리 시스템으로 정의하고 MYSQL_DATABASE 변수를 데이터베이스 이름으로, MYSQL_ROOT_PASSWORD 변수를 root의 비밀번호로 정의해야 합니다. 공식 MySQL Docker 이미지에서 MySQL 변수에 대해 자세히 알아보십시오(https://hub.docker.com/_/mysql).

또한 Laravel의 특정 변수인 DB_HOST를 mysql로, DB_USERNAME를 root로 설정합니다. 우리는 MySQL Docker 이미지를 서비스로 사용하기 때문에 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_PRIVATE_KEY를 설정해야 했습니다. 만약 SSH 키가 성공적으로 추가되었다면 Envoy를 실행할 수 있습니다.

이전에 언급했듯이, GitLab은 지속적 배포 방법을 지원합니다. environment 키워드는 이 작업이 production 환경으로 배포됨을 GitLab에 알려줍니다. 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 브랜치에 커밋 및 푸시하세요. 이렇게 하면 프로젝트의 Pipelines에서 실시간으로 확인할 수 있는 파이프라인이 트리거됩니다.

여기에서 Test와 Deploy 단계를 볼 수 있습니다. Test 단계에는 unit_test 빌드가 실행됩니다. 이를 선택하여 실행기의 출력을 볼 수 있습니다.

코드가 파이프라인을 성공적으로 통과하면, 우리는 오른쪽에 있는 Run ()을 선택하여 프로덕션 서버로 배포할 수 있습니다.

배포 파이프라인이 성공적으로 통과하면, Pipelines > Environments로 이동하세요.

원하는 대로 작동하지 않는 경우, 앱의 최신 작동 버전으로 롤백할 수 있습니다.

오른쪽에 특정한 외부 링크 아이콘을 선택하면, GitLab이 프로덕션 웹사이트를 엽니다. 우리의 배포가 성공적으로 완료되었고, 애플리케이션이 작동 중임을 확인할 수 있습니다.

배포 후 프로덕션 서버의 애플리케이션 디렉터리 구조를 확인하고 싶다면, current, releases, storage라는 세 개의 디렉터리를 확인할 수 있습니다. current 디렉터리는 최신 릴리스를 가리키는 심볼릭 링크입니다. .env 파일에는 라라벨 환경 변수가 포함되어 있습니다.

current 디렉터리로 이동하면 애플리케이션 내용을 볼 수 있습니다. .env가 /var/www/app/.env 파일을 가리키고 있으며 storage는 /var/www/app/storage/ 디렉터리를 가리키고 있음을 확인할 수 있습니다.

결론

우리는 GitLab CI/CD를 구성하여 자동화된 테스트를 수행하고 지속적 배포 방법을 사용하여 코드베이스에서 라라벨 애플리케이션을 프로덕션으로 배포했습니다.

또한 Envoy는 사용자 정의 bash 스크립트를 작성하거나 Linux 매직을 수행하지 않고도 애플리케이션을 배포하는 데 도움이 되었습니다.

GitLab CI/CD 및 Envoy로 Laravel 애플리케이션 테스트 및 배포

소개

GitLab에서 Laravel 앱 초기화

단위 테스트

GitLab에 푸시

프로덕션 서버 구성

새 사용자 생성

SSH 키 추가

NGINX 구성

Envoy 설정

Envoy 작동 방식

제로 다운타임 배포

@setup 지시문

@story 지시문

리포지터리 복제

Composer를 사용하여 의존성 설치

새 릴리스 활성화

완전한 스크립트

GitLab를 이용한 지속적 통합

컨테이너 이미지 생성

GitLab 컨테이너 레지스트리 설정

GitLab CI/CD 설정

이미지와 서비스

CI/CD 변수

첫 번째 작업으로서의 단위 테스트

프로덕션 배포

GitLab CI/CD 활성화

결론

도움말

기능 사용 가능성과 제품 평가판

도움받기