InfoGrab Docs

GitLab CI/CD에서 SCP를 통한 배포로 Composer 및 npm 스크립트 실행

요약

이 가이드에서는 GitLab CI/CD를 사용하여 npm 스크립트를 통해 자산을 컴파일하면서 PHP 프로젝트의 의존성을 빌드하는 방법을 다룹니다. PHP 및 Node.js의 사용자 정의 버전으로 자체 이미지를 만들 수 있습니다.

이 가이드에서는 GitLab CI/CD를 사용하여 npm 스크립트를 통해 자산을 컴파일하면서 PHP 프로젝트의 의존성을 빌드하는 방법을 다룹니다.

PHP 및 Node.js의 사용자 정의 버전으로 자체 이미지를 만들 수 있습니다. 간략성을 위해 이 가이드에서는 PHP와 Node.js가 모두 설치된 기존 Docker 이미지를 사용합니다.

image: tetraweb/php

다음 단계는 zip/unzip 패키지를 설치하고 composer를 사용할 수 있도록 하는 것입니다. 이를 before_script 섹션에 배치합니다:

before_script:
  - apt-get update
  - apt-get install zip unzip
  - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
  - php composer-setup.php
  - php -r "unlink('composer-setup.php');"

이를 통해 모든 요구 사항이 준비됩니다. 다음으로 composer install을 실행하여 모든 PHP 의존성을 가져오고 npm install을 실행하여 Node.js 패키지를 로드합니다. 그런 다음 npm 스크립트를 실행합니다. before_script 섹션에 명령을 추가합니다:

before_script:
  # ...
  - php composer.phar install
  - npm install
  - npm run deploy

이 경우 npm deploy 스크립트는 다음을 수행하는 Gulp 스크립트입니다:

  1. CSS 및 JS 컴파일
  2. 스프라이트 생성
  3. 다양한 자산(이미지, 폰트) 복사
  4. 일부 문자열 교체

이 모든 작업은 모든 파일을 라이브 서버에 배포할 준비가 된 build 폴더에 넣습니다.

라이브 서버로 파일 전송 방법#

rsync, SCP 또는 SFTP와 같은 여러 옵션이 있습니다. 지금은 SCP를 사용합니다.

이 작업을 수행하려면 GitLab CI/CD 변수(gitlab.example/your-project-name/variables에서 액세스 가능)를 추가해야 합니다. 이 변수의 이름을 STAGING_PRIVATE_KEY로 지정하고 서버의 개인 SSH 키로 설정합니다.

보안 팁#

업데이트가 필요한 폴더에만 액세스할 수 있는 사용자를 만드세요.

해당 변수를 만든 후 실행 시 Docker 컨테이너에 키가 추가되었는지 확인합니다:

before_script:
  # - ....
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  - mkdir -p ~/.ssh
  - eval $(ssh-agent -s)
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'

이 스크립트는 다음 작업을 수행합니다:

  1. ssh-agent가 사용 가능한지 확인하고 없으면 설치합니다.
  2. ~/.ssh 폴더를 만듭니다.
  3. 스크립트 실행 환경이 bash를 실행하고 있는지 확인합니다.
  4. 호스트 확인을 비활성화합니다. 모든 연결은 새 환경에서 발생하므로 호스트 확인을 비활성화하면 GitLab이 매번 연결 전에 서버의 신원을 확인하고 수락하도록 사용자에게 요청하지 않습니다.

이것이 기본적으로 before_script 섹션에 필요한 모든 것입니다.

배포 방법#

Docker 이미지에서 서버로 build 폴더를 배포하려면 새 잡을 만듭니다:

stage_deploy:
  artifacts:
    paths:
      - build/
  rules:
    - if: $CI_COMMIT_BRANCH == "dev"
  script:
    - ssh-add <(echo "$STAGING_PRIVATE_KEY")
    - ssh -p22 server_user@server_host "mkdir htdocs/wp-content/themes/_tmp"
    - scp -P22 -r build/* server_user@server_host:htdocs/wp-content/themes/_tmp
    - ssh -p22 server_user@server_host "mv htdocs/wp-content/themes/live htdocs/wp-content/themes/_old && mv htdocs/wp-content/themes/_tmp htdocs/wp-content/themes/live"
    - ssh -p22 server_user@server_host "rm -rf htdocs/wp-content/themes/_old"

분석:

  1. rules:if: $CI_COMMIT_BRANCH == "dev"는 이 빌드가 dev 브랜치에 푸시가 있을 때만 실행됨을 의미합니다. 이 블록을 완전히 제거하고 모든 푸시에서 모든 것이 실행되도록 할 수 있습니다(하지만 아마도 이것은 원하지 않을 것입니다).
  2. ssh-add ...는 웹 UI에 추가한 개인 키를 Docker 컨테이너에 추가합니다.
  3. ssh를 사용하여 연결하고 새 _tmp 폴더를 만듭니다.
  4. scp를 사용하여 연결하고 build 폴더(npm 스크립트에 의해 생성됨)를 이전에 생성한 _tmp 폴더에 업로드합니다.
  5. ssh를 사용하여 다시 연결하고 live 폴더를 _old 폴더로 이동한 다음 _tmp를 live로 이동합니다.
  6. SSH에 연결하여 _old 폴더를 제거합니다.

artifacts 섹션은 GitLab CI/CD에게 build 디렉토리를 유지하도록 지시합니다(나중에 필요에 따라 다운로드할 수 있습니다).

이 방법을 사용하는 이유#

스테이지 서버에만 사용하는 경우 두 단계로 수행할 수 있습니다:

- ssh -p22 server_user@server_host "rm -rf htdocs/wp-content/themes/live/*"
- scp -P22 -r build/* server_user@server_host:htdocs/wp-content/themes/live

문제는 서버에 앱이 없는 짧은 시간이 있다는 것입니다.

따라서 프로덕션 환경에서는 추가 단계를 통해 언제든지 작동하는 앱이 있을 수 있습니다.

다음 단계#

이것이 WordPress 프로젝트였기 때문에 실제 코드 스니펫이 포함되어 있습니다. 추구할 수 있는 몇 가지 추가 아이디어:

  • 기본 브랜치에 대한 약간 다른 스크립트를 사용하면 해당 브랜치에서 프로덕션 서버에 배포하고 다른 브랜치에서 스테이지 서버에 배포할 수 있습니다.
  • 라이브로 푸시하는 대신 WordPress 공식 저장소에 푸시할 수 있습니다.
  • 즉석에서 i18n 텍스트 도메인을 생성할 수 있습니다.

최종 .gitlab-ci.yml은 다음과 같습니다:

stage_deploy:
  image: tetraweb/php
  artifacts:
    paths:
      - build/
  rules:
    - if: $CI_COMMIT_BRANCH == "dev"
  before_script:
    - apt-get update
    - apt-get install zip unzip
    - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
    - php composer-setup.php
    - php -r "unlink('composer-setup.php');"
    - php composer.phar install
    - npm install
    - npm run deploy
    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
    - mkdir -p ~/.ssh
    - eval $(ssh-agent -s)
    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
  script:
    - ssh-add <(echo "$STAGING_PRIVATE_KEY")
    - ssh -p22 server_user@server_host "mkdir htdocs/wp-content/themes/_tmp"
    - scp -P22 -r build/* server_user@server_host:htdocs/wp-content/themes/_tmp
    - ssh -p22 server_user@server_host "mv htdocs/wp-content/themes/live htdocs/wp-content/themes/_old && mv htdocs/wp-content/themes/_tmp htdocs/wp-content/themes/live"
    - ssh -p22 server_user@server_host "rm -rf htdocs/wp-content/themes/_old"

GitLab CI/CD에서 SCP를 통한 배포로 Composer 및 npm 스크립트 실행

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

이 가이드에서는 GitLab CI/CD를 사용하여 npm 스크립트를 통해 자산을 컴파일하면서 PHP 프로젝트의 의존성을 빌드하는 방법을 다룹니다. PHP 및 Node.js의 사용자 정의 버전으로 자체 이미지를 만들 수 있습니다.

이 가이드에서는 GitLab CI/CD를 사용하여 npm 스크립트를 통해 자산을 컴파일하면서 PHP 프로젝트의 의존성을 빌드하는 방법을 다룹니다.

PHP 및 Node.js의 사용자 정의 버전으로 자체 이미지를 만들 수 있습니다. 간략성을 위해 이 가이드에서는 PHP와 Node.js가 모두 설치된 기존 Docker 이미지를 사용합니다.

image: tetraweb/php

다음 단계는 zip/unzip 패키지를 설치하고 composer를 사용할 수 있도록 하는 것입니다. 이를 before_script 섹션에 배치합니다:

before_script:
  - apt-get update
  - apt-get install zip unzip
  - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
  - php composer-setup.php
  - php -r "unlink('composer-setup.php');"

이를 통해 모든 요구 사항이 준비됩니다. 다음으로 composer install을 실행하여 모든 PHP 의존성을 가져오고 npm install을 실행하여 Node.js 패키지를 로드합니다. 그런 다음 npm 스크립트를 실행합니다. before_script 섹션에 명령을 추가합니다:

before_script:
  # ...
  - php composer.phar install
  - npm install
  - npm run deploy

이 경우 npm deploy 스크립트는 다음을 수행하는 Gulp 스크립트입니다:

  1. CSS 및 JS 컴파일
  2. 스프라이트 생성
  3. 다양한 자산(이미지, 폰트) 복사
  4. 일부 문자열 교체

이 모든 작업은 모든 파일을 라이브 서버에 배포할 준비가 된 build 폴더에 넣습니다.

라이브 서버로 파일 전송 방법#

rsync, SCP 또는 SFTP와 같은 여러 옵션이 있습니다. 지금은 SCP를 사용합니다.

이 작업을 수행하려면 GitLab CI/CD 변수(gitlab.example/your-project-name/variables에서 액세스 가능)를 추가해야 합니다. 이 변수의 이름을 STAGING_PRIVATE_KEY로 지정하고 서버의 개인 SSH 키로 설정합니다.

보안 팁#

업데이트가 필요한 폴더에만 액세스할 수 있는 사용자를 만드세요.

해당 변수를 만든 후 실행 시 Docker 컨테이너에 키가 추가되었는지 확인합니다:

before_script:
  # - ....
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  - mkdir -p ~/.ssh
  - eval $(ssh-agent -s)
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'

이 스크립트는 다음 작업을 수행합니다:

  1. ssh-agent가 사용 가능한지 확인하고 없으면 설치합니다.
  2. ~/.ssh 폴더를 만듭니다.
  3. 스크립트 실행 환경이 bash를 실행하고 있는지 확인합니다.
  4. 호스트 확인을 비활성화합니다. 모든 연결은 새 환경에서 발생하므로 호스트 확인을 비활성화하면 GitLab이 매번 연결 전에 서버의 신원을 확인하고 수락하도록 사용자에게 요청하지 않습니다.

이것이 기본적으로 before_script 섹션에 필요한 모든 것입니다.

배포 방법#

Docker 이미지에서 서버로 build 폴더를 배포하려면 새 잡을 만듭니다:

stage_deploy:
  artifacts:
    paths:
      - build/
  rules:
    - if: $CI_COMMIT_BRANCH == "dev"
  script:
    - ssh-add <(echo "$STAGING_PRIVATE_KEY")
    - ssh -p22 server_user@server_host "mkdir htdocs/wp-content/themes/_tmp"
    - scp -P22 -r build/* server_user@server_host:htdocs/wp-content/themes/_tmp
    - ssh -p22 server_user@server_host "mv htdocs/wp-content/themes/live htdocs/wp-content/themes/_old && mv htdocs/wp-content/themes/_tmp htdocs/wp-content/themes/live"
    - ssh -p22 server_user@server_host "rm -rf htdocs/wp-content/themes/_old"

분석:

  1. rules:if: $CI_COMMIT_BRANCH == "dev"는 이 빌드가 dev 브랜치에 푸시가 있을 때만 실행됨을 의미합니다. 이 블록을 완전히 제거하고 모든 푸시에서 모든 것이 실행되도록 할 수 있습니다(하지만 아마도 이것은 원하지 않을 것입니다).
  2. ssh-add ...는 웹 UI에 추가한 개인 키를 Docker 컨테이너에 추가합니다.
  3. ssh를 사용하여 연결하고 새 _tmp 폴더를 만듭니다.
  4. scp를 사용하여 연결하고 build 폴더(npm 스크립트에 의해 생성됨)를 이전에 생성한 _tmp 폴더에 업로드합니다.
  5. ssh를 사용하여 다시 연결하고 live 폴더를 _old 폴더로 이동한 다음 _tmp를 live로 이동합니다.
  6. SSH에 연결하여 _old 폴더를 제거합니다.

artifacts 섹션은 GitLab CI/CD에게 build 디렉토리를 유지하도록 지시합니다(나중에 필요에 따라 다운로드할 수 있습니다).

이 방법을 사용하는 이유#

스테이지 서버에만 사용하는 경우 두 단계로 수행할 수 있습니다:

- ssh -p22 server_user@server_host "rm -rf htdocs/wp-content/themes/live/*"
- scp -P22 -r build/* server_user@server_host:htdocs/wp-content/themes/live

문제는 서버에 앱이 없는 짧은 시간이 있다는 것입니다.

따라서 프로덕션 환경에서는 추가 단계를 통해 언제든지 작동하는 앱이 있을 수 있습니다.

다음 단계#

이것이 WordPress 프로젝트였기 때문에 실제 코드 스니펫이 포함되어 있습니다. 추구할 수 있는 몇 가지 추가 아이디어:

  • 기본 브랜치에 대한 약간 다른 스크립트를 사용하면 해당 브랜치에서 프로덕션 서버에 배포하고 다른 브랜치에서 스테이지 서버에 배포할 수 있습니다.
  • 라이브로 푸시하는 대신 WordPress 공식 저장소에 푸시할 수 있습니다.
  • 즉석에서 i18n 텍스트 도메인을 생성할 수 있습니다.

최종 .gitlab-ci.yml은 다음과 같습니다:

stage_deploy:
  image: tetraweb/php
  artifacts:
    paths:
      - build/
  rules:
    - if: $CI_COMMIT_BRANCH == "dev"
  before_script:
    - apt-get update
    - apt-get install zip unzip
    - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
    - php composer-setup.php
    - php -r "unlink('composer-setup.php');"
    - php composer.phar install
    - npm install
    - npm run deploy
    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
    - mkdir -p ~/.ssh
    - eval $(ssh-agent -s)
    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
  script:
    - ssh-add <(echo "$STAGING_PRIVATE_KEY")
    - ssh -p22 server_user@server_host "mkdir htdocs/wp-content/themes/_tmp"
    - scp -P22 -r build/* server_user@server_host:htdocs/wp-content/themes/_tmp
    - ssh -p22 server_user@server_host "mv htdocs/wp-content/themes/live htdocs/wp-content/themes/_old && mv htdocs/wp-content/themes/_tmp htdocs/wp-content/themes/live"
    - ssh -p22 server_user@server_host "rm -rf htdocs/wp-content/themes/_old"