소개
소프트웨어 엔지니어링은 빠르게 변화하고 경쟁이 치열한 분야입니다. 제품을 사용자에게 더 빠르게 출시하면 경쟁사보다 우위를 점할 수 있습니다. 긍정적인 면은, 기업들이 공평한 경쟁을 할 수 있도록 돕는 업계 모범 사례가 마련되어 있다는 것입니다.
지속적 통합 및 지속적 개발(CICD)은 이 경쟁이 치열한 분야에서 기업에 우위를 제공하기 위해 업계 모범 사례를 활용하는 전략의 한 예입니다.
버전 관리 도구인 Git을 사용하는 웹 기반 저장소인 GitHub는 소프트웨어 개발자, 엔지니어 및 아키텍트가 CI/CD를 구현할 수 있도록 지원합니다. 지속적 개발(CD)은 빌드, 테스트 및 배포를 자동화하는 관행입니다. 지속적 통합(CI)은 여러 사람이 동일한 프로젝트에서 협업하고, 병합 충돌에 대한 걱정 없이 코드가 제대로 작동하는지 확인할 수 있도록 합니다.
GitHub Actions를 사용하면 빌드, 테스트 및 배포를 자동화하는 단계를 작성할 수 있습니다.
이 튜토리얼에서는 GitHub Actions를 사용하여 지속적 통합(Continuous Integration)을 설정하는 방법을 배웁니다. 먼저 코드를 호스팅할 Git 저장소를 설정하는 것부터 시작합니다. 그런 다음, 코드의 변경 사항을 감시하고, 테스트를 실행할 CI 러너를 시작하고, 애플리케이션을 빌드하여 Nginx가 실행 중인 Ubuntu 22.04 서버에 배포하도록 GitHub CI 프로세스를 구성합니다.
사전 요구 사항
이 튜토리얼을 따라 하려면 다음이 필요합니다:
-
Ubuntu 22.04를 실행하는 서버. 다음 과정을 위해 이 튜토리얼을 진행할 수 있습니다: 초기 Ubuntu 서버 설정, 루트가 아닌 사용자 추가, 그리고 Ubuntu의 UFW 방화벽 활성화.
-
서버에 Node.js(가급적 14 버전 이상)를 설치해야 합니다. 다음에서 관련 튜토리얼을 제공합니다: Ubuntu에 Node.js를 설치하는 방법.
-
Nginx 서버 소프트웨어가 설치되어 있어야 합니다. 다음에서 관련 가이드를 제공합니다: Ubuntu를 실행하는 서버에 Nginx를 설치하는 방법.
-
로컬 머신에 Docker와 Docker Compose가 설치되어 있어야 격리된 개발 환경을 실행할 수 있습니다. 다음 튜토리얼을 통해 클라우드에서 Docker를 설치하고 운영하는 방법에 대해 배우려면 저희 튜토리얼을 따르십시오.
필요한 모든 것이 준비되었으므로 이제 시작해 보겠습니다.
1단계. 프로젝트 리포지토리 복제하기.
이 튜토리얼은 다음을 기반으로 진행됩니다: Reactjs, 사용자 인터페이스를 구축하기 위한 선언형 Javascript 라이브러리입니다. 처음부터 새 프로젝트를 설정하려면 다음 React 앱 설정에 관한 리소스를 사용할 수 있습니다. 간단히 진행하기 위해 이미 GitHub에 설정해 둔 이 React.js 리포지토리의 복제본을 사용하겠습니다.
우리가 복제하려는 애플리케이션은 react-router 6와 React Testing Library로 테스트를 수행하는 간단한 React 애플리케이션이며, DOM에 액세스하는 메서드를 제공합니다.
리포지토리를 복제하려면 녹색 버튼을 클릭하고 URL을 복사합니다.
작업 공간에서 터미널을 열고 아래 명령을 실행하여 앱을 복제합니다:
|
1 |
git clone git@github.com:EspiraMarvin/cicd-tut.git |
리포지토리를 복제한 후 프로젝트 디렉터리로 이동합니다:
|
1 |
cd cicd-tut |
docker-compose up 명령을 실행하여 앱을 빌드하고 실행합니다:
|
1 |
docker-compose up --build --force-recreate |
프로세스가 완료되면 다음 주소로 이동합니다. http://localhost:3000
다음과 유사한 화면이 표시됩니다:
2단계. Node.js.yml 파일 이해하기.
이 단계에서는 진행 상황을 이해하는 데 도움이 되도록 GitHub Yaml 파일의 지시문을 정의할 것입니다. 리포지토리에는 .github/workflows 디렉터리가 있으며, 이 안에는 node.js.yml 파일이 포함되어 있습니다. 이 파일에는 GitHub의 코드 리포지토리에 변경 사항을 푸시한 후 GitHub 러너가 따르는 워크플로 단계가 있습니다. YAML 구문은 GitHub Actions의 워크플로를 작성하는 데 사용됩니다. YAML 파일은 다음과 같은 확장자로 끝납니다. yaml 또는 yml.
다음의 node.js.yml 파일을 여십시오. 다음과 같이 보여야 합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
name: cicd-tut on: push: branches: [ "main" ] pull_request: branches: [ "main" ] jobs: build: # The type of runner that the job will run on runs-on: self-hosted strategy: matrix: node-version: [16.x] # Steps represent a sequence of tasks that will be executed as part of the job steps: - name: 'checkout' uses: actions/checkout@v3 - name: 'setup node actions' uses: actions/setup-node@v3 with: node-version: "16" cache: 'npm' - run: npm i - run: npm test - run: npm run build # - run: cp -r ~/actions-runner/cicd-react/react-tut-test/react-tut-test/build /var/www/react-cicd |
이 튜토리얼을 작성할 당시에는 Node.js 16의 16 버전을 사용하고 있었습니다. 이제 GitHub Actions 워크플로를 이해해 보겠습니다:
-
name
name: cicd-tut
워크플로의 이름으로, 이 이름은 리포지토리의 Actions 탭에 표시됩니다.
-
on
|
1 2 3 4 5 |
on: push: branches: [ "main" ] pull_request: branches: [ "main" ] |
on은 이벤트를 정의하는 데 사용됩니다. 이벤트는 워크플로를 자동으로 트리거하거나 나중에 실행되도록 예약할 수 있습니다. 이벤트는 단일 또는 다중일 수 있으며, 특정 브랜치, 태그 또는 파일로 워크플로 실행을 지정할 수도 있습니다. 이는 필터처럼 작동합니다.
YAML 파일에서는 다음과 같은 여러 자동 이벤트를 정의하고 있습니다.
-
코드가 리포지토리에 커밋될 때 push 이벤트가 트리거됩니다.
-
main 브랜치에 풀 리퀘스트가 생성될 때 pull_request 이벤트가 트리거됩니다.
워크플로 실행을 해당 브랜치로만 제한하기 위해 브랜치 이름 main을 지정하고 있습니다. 또한 ! 플래그 뒤에 브랜치 이름을 붙여 무시할 브랜치를 지정할 수도 있습니다.
-
jobs
워크플로는 기본적으로 하나 또는 여러 개의 작업으로 구성됩니다. 이 작업들은 첫 번째부터 마지막까지 순차적으로 실행됩니다.
|
1 2 3 4 |
jobs: build: # The type of runner that the job will run on runs-on: self-hosted |
각 작업은 다음으로 지정된 러너 환경에서 실행됩니다. runs-on. 작업은 ubuntu-latest 또는 self-hosted로 표시되는 self-hosted 러너에서 실행하도록 선택할 수 있습니다. 선택은 필요한 작업 수에 따라 달라집니다. 자체 호스팅 러너를 사용하면 리소스를 더 유연하게 제어할 수 있습니다.
다음 단계에서는 먼저 GitHub 러너에서 작업을 실행한 다음, 나중에 자체 서버에 GitHub 자체 호스팅 러너를 설정할 것입니다.
-
strategy
Strategy를 사용하면 단일 작업 정의에서 변수를 사용하여 변수 조합을 기반으로 여러 작업 실행을 자동으로 생성할 수 있습니다.
YAML 파일에는 node-version에 대한 변수가 하나 있지만, 다음과 같이 node 버전 18에 대한 변수를 하나 더 추가하면: node-version: [16.x, 18.x], matrix strategy는 16 및 18 node 버전 모두에 대해 React 애플리케이션에 대한 2개의 작업 실행을 생성합니다.
|
1 2 3 |
strategy: matrix: node-version: [16.x] |
-
steps
Steps는 작업을 구성하는 일련의 태스크입니다. Steps는 명령을 실행하거나, 태스크를 설정하거나, 공개 리포지토리의 액션 또는 Docker 레지스트리에 게시된 액션을 실행할 수 있습니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
steps: - name: 'checkout' uses: actions/checkout@v3 - name: 'setup node actions' uses: actions/setup-node@v3 with: node-version: "16" cache: 'npm' - run: npm i - run: npm test - run: npm run build |
단계(step)에는 이름이 있습니다. 선택 사항이지만, GitHub에 표시될 단계의 이름을 쉽게 식별할 수 있도록 지정하는 데 사용할 수 있습니다.
단계에서는 작업에서 실행할 액션을 선택할 수 있으며, 액션은 재사용이 가능합니다. 액션을 정의할 때 액션의 버전이 지정되는데, 이는 액션 소유자가 업데이트를 게시할 때 워크플로가 중단되는 것을 방지하므로 중요합니다.
위의 코드 스니펫에서, checkout@v3 은(는) 지정된 버전을 가진 액션의 예입니다. 3. 이 액션은 워크플로가 리포지토리에 액세스할 수 있도록 리포지토리를 체크아웃합니다.
위의 actions/setup-node@v3 와(과) 같은 일부 액션은 with 키워드를 사용하여 표시된 입력을 가지며, setup node 액션은 node 버전 16과 캐시할 npm이 필요합니다.
-
run
이 액션은 운영 체제’의 셸을 사용하여 명령줄 프로그램을 실행합니다.
위의 YAML 파일에는 세 개의 명령어가 있으며, 모두 러너 환경에서 동일한 셸을 사용하여 실행됩니다.
-
첫 번째 명령어인 npm i 은(는) React 애플리케이션에 필요한 모든 종속성을 설치합니다.
-
두 번째 명령어인 npm test 은(는) 우리가 작성한 테스트를 실행합니다. 이 테스트는 learn react 텍스트가 홈 페이지에 렌더링될 것을 기대합니다.
-
마지막으로, npm run build 명령어는 애플리케이션의 프로덕션 빌드가 포함된 빌드 디렉터리를 생성합니다. 나중에 이 빌드 디렉터리를 우리의 Nginx 서버 블록에서 사용할 것입니다..
3단계. GitHub 러너로 GitHub CI 테스트하기.
이 단계에서는 GitHub 러너를 사용하여 지속적 통합(Continuous Integration) 프로세스를 테스트합니다. 먼저 다음 파일을 여는 것으로 시작합니다. node.js.yml 파일. 액션이 실행될 러너의 유형을 다음과 같이 수정합니다. ubuntu-latest. 이것의 목적은 자체 호스팅 러너를 설정하기 전에 GitHub 러너에서 GitHub 워크플로우가 완벽하게 작동하는지 테스트하는 것입니다.
|
1 2 3 |
jobs: build: runs-on: ubuntu-latest |
귀하의 GitHub 계정에 새 리포지토리를 생성하세요. 계속하기 전에 작업 공간 디렉토리로 돌아가서 .git 디렉토리를 삭제하십시오. 보이지 않는 경우 숨김 파일을 확인하십시오. 터미널에서 다음 명령을 사용하여 디렉토리를 삭제할 수 있습니다:
|
1 |
rm -rf .git |
이제 모든 프로젝트 파일을 git add하고 커밋한 다음 리포지토리에 푸시할 수 있습니다. 진행이 막히면 프로젝트 폴더를 GitHub 리포지토리에 연결하는 (위에서 생성한) 가이드를 참조하세요.
완료되면 Code 탭을 클릭하십시오. 그러면 총 커밋 수 옆에 작은 주황색 점이 표시되며, 이를 클릭하면 워크플로우가 대기열에 추가되었음을 나타내는 아래와 유사한 모달이 표시됩니다:
이제 Details 링크를 클릭하거나 Actions 탭으로 이동하면 node.js.yml 워크플로우의 각 단계가 GitHub 러너에 의해 실행되는 것을 볼 수 있습니다:
성공하면 Actions 탭을 클릭하십시오. 다음과 같이 보일 것입니다:
이제 끝입니다. Code 탭의 작은 주황색 점이 녹색 체크 표시로 바뀔 것입니다. GitHub 러너가 애플리케이션을 성공적으로 빌드했습니다.
이제 한 단계 더 나아가 빌드 환경을 자체 Ubuntu Server Infrastructure에서 GitHub 자체 호스팅 러너를 사용하도록 변경해 보겠습니다..
4단계. 자체 호스팅 러너를 사용하도록 GitHub 워크플로우 설정하기.
서버에 자체 호스팅 러너를 설치하기 전에, 작업 공간으로 돌아가서 node.js.yml 워크플로 파일을 GitHub 자체 호스팅 러너에서 실행되도록 수정합니다.
|
1 2 3 |
jobs: build: runs-on: self-hosted |
이 단계에서는 자체 호스팅 러너가 정의되지 않았기 때문에 변경 사항을 커밋하면 작업이 대기열에 추가됩니다.
리포지토리에서
Settings 탭을 클릭하고, 왼쪽 사이드바에서
Actions, then click
Runners:
Click New self-hosted runner를 클릭하고, Linux를 운영 체제로 선택합니다.
러너를 다운로드하고 서버에 설치하는 방법을 보여주는 안내가 표시됩니다.
5단계. 서버에 GitHub 자체 호스팅 러너 설치 및 구성.
이 단계에서는 자체 호스팅 GitHub 러너를 설정합니다. 자체 호스팅 러너는 GitHub 웹사이트의 GitHub Actions에서 작업 실행을 배포하고 관리할 수 있는 시스템입니다. 자체 호스팅 러너가 GitHub 호스팅 러너보다 가지는 한 가지 장점은 유연성입니다. 운영 체제, 하드웨어 및 기타 도구를 더 제어할 수 있어 원하는 애플리케이션 요구 사항에 맞게 맞춤 설정할 수 있습니다.
자체 호스팅 러너는 다음과 같은 다양한 수준에서 추가할 수 있습니다.
-
리포지토리 수준 러너: 단일 리포지토리에 전용으로 사용됩니다.
-
조직 수준 러너: 조직 내 여러 리포지토리의 작업을 처리할 수 있습니다.
-
엔터프라이즈 수준: 여러 조직에 할당할 수 있습니다.
계속하려면 SSH를 통해 서버에 로그인합니다.
|
1 |
ssh username@server_ip |
다음 명령을 사용하여 홈 디렉터리로 이동합니다.
|
1 |
cd ~ |
그런 다음, action-runners라는 디렉터리를 생성하고 해당 디렉터리로 이동합니다:
|
1 |
mkdir actions-runner && cd actions-runner |
다음으로, 러너 패키지의 최신 버전을 다운로드합니다:
|
1 |
curl -o actions-runner-linux-x64-2.298.2.tar.gz -L https://github.com/actions/runner/releases/download/v2.298.2/actions-runner-linux-x64-2.298.2.tar.gz |
그런 다음 다음 명령어로 다운로드한 패키지의 압축을 해제합니다:
|
1 |
tar xzf ./actions-runner-linux-x64-2.298.2.tar.gz |
다시 리포지토리로 돌아가서, Settings 탭의 왼쪽 사이드 패널에서 Actions를 클릭한 다음, Runners를 클릭합니다. 이전에 했던 것처럼 단계 4.
자체 호스팅 러너를 GitHub 리포지토리에 연결하는 토큰이 포함된 명령어가 표시됩니다. GitHub 러너 코드를 압축 해제한 디렉터리 내에서 표시된 명령어를 사용하여 러너를 연결합니다. 예:
|
1 |
./config.sh --url https://github.com/EspiraMarvin/react-tut-test --token XXXXXXXXXXXXXXXXXXXXXXXXXXX |
성공적으로 인증되어야 합니다:
기본(Default) 러너 그룹을 선택하려면 Enter 키를 누릅니다.
그런 다음 러너의 이름을 입력합니다. 예: my-runner, 그리고 Enter 키를 누릅니다.
추가 레이블 추가를 건너뛰려면 Enter 키를 누릅니다. 아래 스크린샷과 같이 성공 메시지가 표시되어야 합니다:
작업 디렉터리의 이름을 입력합니다. 예: react-cicd, 다음과 같은 텍스트와 함께 성공적으로 완료되어야 합니다. settings saved.
마지막으로, 다음을 실행합니다. ./run.sh, 다음과 같이 표시되어야 합니다. Connected to Github:
하지만 이는 백그라운드에서 실행되지 않으므로, 터미널에 ctrl+c를 입력하면 러너가 중지됩니다. 러너와 계속 상호 작용할 수 있도록 러너를 서비스로 계속 실행하려면 이를 .svc.sh 서비스로 대체해야 합니다.
다음 키를 눌러 러너를 중지합니다. ctrl+c. 다음 명령을 실행하여 .svc.sh 서비스를 설치할 수 있습니다:
|
1 |
sudo ./svc.sh install |
설치가 완료되면 다음 명령어로 서비스를 시작합니다:
|
1 |
sudo ./svc.sh start |
성공적으로 실행되면 다음과 같이 표시되어야 합니다. active (running).
다음 서비스가 작동 중인지 확인하려면 svc.sh 서비스가 실행 중인지 확인하려면 다음 명령을 실행합니다:
|
1 |
sudo ./svc/sh status |
이 시점에서는 자체 호스팅 러너를 대기하며 대기열에 추가되었을 수 있는 모든 워크플로가 성공적으로 실행되어야 합니다. 파일을 편집하여 테스트해 볼 수도 있습니다. 예를 들어, 소개.tsx 파일을 수정하고 변경 사항을 커밋 및 푸시하면, 자체 호스팅 러너가 작업을 성공적으로 완료할 것입니다.
6단계. Nginx 서버 블록 설정
이 단계에서는 React 애플리케이션의 빌드 버전을 확인하기 위해 Nginx에 서버 블록을 설정합니다. 도움이 될 만한 Nginx 서버 블록 설정에 대한 튜토리얼이 있습니다.
아래는 이 튜토리얼에서 사용되는 서버 블록의 예시입니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
server { listen 80; listen [::]:80; server_name react.test; root /var/www/react-cicd/build; index index.html index.htm index.nginx-debian.html; add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options "nosniff"; charset utf-8; location / { try_files $uri $uri/ =404; } } |
다음 경로 내에 Nginx 서버 블록 설정 파일을 생성합니다: /etc/nginx/sites-available 디렉터리.
다음 명령어를 사용하여 nano 편집기로 사이트의 서버 블록 설정 파일을 엽니다:
|
1 |
sudo nano /etc/nginx/sites-available/react-cicd |
위에서 공유한 서버 블록을 복사하여 디렉터리 경로에 맞게 수정한 다음, 열려 있는 파일에 붙여넣습니다. 편집이 끝나면 ctrl+x를 누른 다음 y 및 enter 를 눌러 저장하고 종료합니다.
저장한 후, 다음 명령어를 실행하여 react-cicd 서버 블록 설정의 심볼릭 링크(symlink)를 /etc/nginx/sites-available에서 /etc/nginx/sites-enabled로 생성합니다:
|
1 |
sudo ln -s /etc/nginx/sites-available/react-cicd /etc/nginx/sites-enabled/ |
변경 사항을 적용하려면 Nginx를 재시작해야 합니다. 하지만 Nginx 서비스를 재시작하기 전에, 다음 명령어를 실행하여 Nginx 설정이 유효한지 테스트하십시오:
|
1 |
sudo nginx -t |
설정이 올바르면 테스트가 성공적으로 완료되어야 합니다.
다음 지시어의 값을 확인하십시오: server_name 지시어 “ react.test ” 서버 블록에 있나요? 이 값을 귀하의 호스트 로컬 머신의 파일입니다. 이를 통해 브라우저에서 애플리케이션을 열 수 있습니다. 이 단계는 로컬 개발 환경에서 사용되는 가상 도메인에만 필요합니다. 서버의 공인 IP에 연결된 등록된 도메인 이름이 있는 경우, 브라우저에서 도메인 이름에 이미 접속할 수 있어야 합니다.
로컬 머신에서 다음 명령어로 hosts 파일을 여십시오:
|
1 |
sudo nano /etc/hosts |
hosts 파일 내에 서버의 IP 주소를 추가하세요. 예: 127.0.0.1, 이어서 귀하의 가상 도메인 이름.
아래에 예시가 나와 있습니다. 그런 다음 파일을 닫고 저장하십시오:
|
1 |
192.168.3.123 react.test |
내부의 귀하의 서버로 돌아가기 /변수/www 디렉터리, 새 디렉터리를 생성합니다. 다음을 실행하여 이름을 react-cicd로 지정할 수 있습니다:
|
1 |
mkdir react-cicd |
이 단계에서는 다음의 마지막 명령의 주석 처리를 해제할 것입니다. 노드.js.yml 파일.
이 명령은 이전 actions-runner 디렉터리 내부에서 작업 폴더를 지정한 위치로부터 react 애플리케이션의 빌드 폴더를 복사합니다.단계 5.
그리고 ~을 놓습니다 공개 폴더를 안으로 /변수/www/반응하다-CI/CD 디렉터리.
이제 서버 블록이 우리 앱에 액세스하여 브라우저에 표시할 수 있습니다.
마지막으로, 다음 명령어로 Nginx 서비스를 재시작합니다:
|
1 |
sudo service nginx restart |
이제 다음에서 변경할 수 있습니다 소개.tsx 파일, 그 다음 변경 사항을 저장소에 커밋하고 푸시하십시오. 빌드가 성공하면 다음에서 react 앱의 빌드 버전을 확인할 수 있습니다: http://react.test 또는 지정하신 도메인 이름에서. 수정을 피하십시오 href 위치의 요소 홈.tsx 파일은 이미 작성된 테스트를 실패하게 만들 수 있습니다. Actions 탭에도 완료된 작업 빌드가 표시되어야 합니다.
결론
Github Actions를 통한 지속적 통합은 좋은 개발자 경험을 제공하고, 지속적인 테스트를 돕고, 대규모 팀에서의 협업을 더 쉽게 만들고, 개발 시간을 단축하고, 새로운 기능을 빠르게 출시하며, 실시간 피드백과 고객 만족을 제공하여 경쟁사보다 우위를 점할 수 있게 해주는 등 많은 장점이 있습니다. 이 지식을 바탕으로 다음에 대해서도 배우고 싶을 수 있습니다. Ubuntu에서 GitLab 지속적 통합(CI) 파이프라인 구축하기. 그리고 자체 관리형 GitLab 인스턴스를 사용하여 Docker 이미지를 호스팅하고 비공개 빌드를 실행하는 방법
즐거운 컴퓨팅 되세요!
댓글
아직 댓글이 없습니다. 첫 번째로 작성해 보세요.