프로찍먹러

1. Github Actions를 구성하는 요소

너무 잘 정리하신분의 글을 퍼왔다.

• 1) Workflow
  • 여러 Job으로 구성되고, Event에 의해 트리거될 수 있는 자동화된 프로세스
  • 최상위 개념
  • Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더 아래에 저장됨
• 2) Event
  • Workflow를 Trigger(실행)하는 특정 활동이나 규칙
  • 예를 들어 다음과 같은 상황을 사용할 수 있음
    • 특정 브랜치로 Push하거나
    • 특정 브랜치로 Pull Request하거나
    • 특정 시간대에 반복(Cron)
    • Webhook을 사용해 외부 이벤트를 통해 실행
  • 자세한 내용은 Events that trigger workflows 참고
• 3) Job
  • Job은 여러 Step으로 구성되고, 가상 환경의 인스턴스에서 실행됨
  • 다른 Job에 의존 관계를 가질 수 있고, 독립적으로 병렬 실행도 가능함
• 4) Step
  • Task들의 집합으로, 커맨드를 날리거나 action을 실행할 수 있음
• 5) Action
  • Workflow의 가장 작은 블럭(smallest portable building block)
  • Job을 만들기 위해 Step들을 연결할 수 있음
  • 재사용이 가능한 컴포넌트
  • 개인적으로 만든 Action을 사용할 수도 있고, Marketplace에 있는 공용 Action을 사용할 수도 있음
    • Github Marketplace와 Github Actions Repository에서 확인 가능
• 6) Runner
  • Gitbub Action Runner 어플리케이션이 설치된 머신으로, Workflow가 실행될 인스턴스
  • Github에서 호스팅해주는 Github-hosted runner와 직접 호스팅하는 Self-hosted runner로 나뉨
  • Github-hosted runner는 Azure의 Standard_DS2_v2로 vCPU 2, 메모리 7GB, 임시 스토리지 14GB
    • Self-hosted runners 참고

참고:

2. Beanstalk으로 배포하기

프로젝트 최상위에 .github/worfklows 폴더를 만들고 그 안에 .yml 스크립트로 깃헙 액션의 동작을 지정할 수 있다.

yml 파일 대부분은 처음 보더라도 대충 어떤 의미인지 알 수 있다.

name: Backend CI/CD

on:
  push:
    branches: [ develop ]

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'

      # Download AWS CLI 2
      - name: Install AWS CLI 2
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          unzip awscliv2.zip
          which aws
          sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
          
      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      # npm install for ci
      - run: npm ci

      # Build
      - run: npm run build

      # Unit test
      - run: npm run test:unit

  deploy:
    name: BeanStalk Deploy
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: ['14.x']
    needs: build
    steps:
      - uses: actions/checkout@v2

      # Initialize Node.js
      - name: Install Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}

      # Install project dependencies
      - name: Install dependencies
        run: npm install

      # Download AWS CLI 2
      - name: Install AWS CLI 2
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          unzip awscliv2.zip
          which aws
          sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      # Build
      - name: Run build
        run: npm run build

      # Make upload zip file
      - name: Generate deployment package
        run: zip -r deploy.zip . -x '*.git*' './aws/*' './node_modules/*' './dist/*' awscliv2.zip

      # Deploy to Elastic Beanstalk
      - name: Deploy to EB
        uses: einaregilsson/beanstalk-deploy@v18
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          application_name: ${{ secrets.APPLICATION_NAME }}
          environment_name: ${{ secrets.ENVIRONMENT_NAME }}
          region: ${{ secrets.AWS_REGION }}
          version_label: ${{github.SHA}}

위에서부터 살피며 내려가자

on

jobs를 실행시킬 트리거를 지정한다. 위의 코드처럼하면 develop 브랜치에 push가 발생했을때 github actions가 실행된다는 의미다.

다음처럼 여러개의 트리거를 지정할 수 있다.

  on:
    push:
      branches: [ master ]
    pull_request:
      branches: [ master ]

jobs

jobs는 Build와 Deploy로 구성된다. 그리고 각각 name을 지정한 것을 볼 수 있다.

Configure AWS Credentials

      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

코드 내부에 aws를 사용한 부분이 다수 존재하기에 runner에 aws cli를 설치해 주어야한다.

${{ secrets.블라블라 }}

이 부분은 깃허브 - Settings - Secrets 탭에서 Name-Value를 지정할 수 있다.

${{ secrets.블라블라 }} 에서 블라블라에 Name을 입력해주면 대응되는 Value를 사용할 수 있다.

npm ci

이거는 npm install과 같은 역할이다.

다만,

ci 과정에서 쓰는 install이다.

거의 두배 이상 빠른 속도를 보여준다.

npm install은 package.json 내부의 dependencies와 devDependencies를 기준으로 패키지 파일을 설치하는 반면

npm ci는 package-lock.json의 lockfile을 기준으로 패키지를 설치한다.

이렇게 되면 package.json내의 파일과 package-lock.json 내의 버전 등이 다를 경우,

package-lock.json을 기준으로 package.json 파일을 수정하며, 명시되지 않은 부분에서는 오류를 발생시키므로 Application 관리에 있어서 안정성을 확보할 수 있다.

npm run build

# Build
- run: npm run build

package.json에 build 스크립트를 실행한다.

이때 한가지 사용한것이 

npm install concurrently --save

이거다.

빌드시 .env파일을 비롯한 여러 설정파일들이 존재해야하는데,

이런 중요파일들은 S3에서 다운로드해야만 한다.

따라서 build 스크립트 이전에 수행되는 prebuild스크립트에서 중요 파일들을 미리 다운 받는 행동을 먼저 해야한다.

그런데 중요 파일들이 2개 이상일 경우 prebuild 안에서 동시에 스크립트가 수행될 수 있도록 해주는 concurrently를 사용했다.

"scripts": {
	...
    "prebuild": "concurrently \"aws s3 cp s3://blahblah .env\" \"aws s3 cp s3://blahblah somethingimportant.json \"",
    "build": "tsc",
    ...
  },

이렇게 concurrently 키워드를 쓰고 ""로 묶어서 스크립트를 넣어주면 된다.

deploy - Make upload zip file

# Make upload zip file
- name: Generate deployment package
  run: zip -r deploy.zip . -x '*.git*' './aws/*' './node_modules/*' './dist/*' awscliv2.zip

Beanstalk에 올리기위한 zip 파일을 생성한다.

zip 명령어로 압축파일을 생성하고 다음 step에서 S3로 업로드하고, Beanstalk에 배포된다.

이때, 압축파일에 포함시키지 않을 파일들을 -x 옵션으로 지정하는데,

node_modules를 지정하지 않았더니 문제가 생겼었다. (node_modules를 zip에 포함시켰더니)

어자피 .ebextensions에 npm install 키워드가 있기에 node_modules를 zip에 안넣어도 되지만,

어자피 덮어쓰기가 될 줄 알고 딱히 신경쓰지 않았었다.

그랬더니 안됏따아아아ㅏㅏ

정확히는 

 ./lib/cli

를 찾을 수 없다고 에러가 발생했다. 저게 뭔지 모르겠다.

* .ebextensions란 Beanstalk 구성파일로, Beanstalk에 배포될 때 최초에 실행되는 커맨드라고 보면된다.

우연히 node_modules를 제외시키면서 문제가 해결되긴 했는데 왜 내부에서 충돌이 난것인지는 모르겠다.

혹시 명쾌한 답을 아신다면 댓글 부탁드립니다.

삽질한 점

• ci때와 cd때 둘다 aws cli를 설치해야한다.
• zip할때 node_modules를 빼줘야한다.

참고:

이번에 새로운 CICD를 구축할 일이 생겼는데 어떤 툴을 사용할지 조사하게 됐다.

조사하는겸 기록해보자

보고계십니까 엘리님...

1. CI/CD란?

"개발부터 배포까지 모든 단계를 자동화 하는 것"

CI

CI는 Continuous Integration의 약자로 지속적 통합이라는 의미이다.
애플리케이션의 새로운 코드들이 자동으로 빌드 및 테스트 되어 레포지토리에 통합되는 것을 의미한다.

CI의 포인트는

• 개발자들은 최대한 작은 단위로 만들어서 개발해가며 빈번하게 merge해야한다.
• 애플리케이션들의 빌드, 테스트, 병합하는 과정을 주기적으로, 자동화시켜야 한다.

이런 포인트를 따라가면

• 병합시 충돌을 예방할 수 있고,
• 코드의 결함이나 문제점을 빠르게 발견할 수 있다.

또 문제점을 빠르게 발견할 뿐 아니라 빠르게 해결할 수 있다.

왜? 작은 단위로 빈번하게 merge하기에 문제 발생 범위가 작기 때문이다(빈번하게 merge해도 빌드, 테스트가 자동이라 간편)

결과적으로 코드의 품질이 올라간다.

CD

CD는 Continuous Delivery/Deployment의 약자로 지속적 제공/배포라는 의미이다.
CI를 통해서 빌드, 테스트가 완료되어 배포될 준비가 끝난 애플리케이션을 개발자가 수동으로, 혹은 자동으로 배포를 진행하는 것.

(수동일때를 Continuous Delivery, 자동일때를 Continuous Deployment라고 한다. 최종단계의 자동화 여부로 나눈다고 하는듯?)

CI/CD 파이프라인

5줄 요약하자면,

1. 개발자가 작은 단위로 코드를 짜고 메인 리포지토리에 merge를 하면,
2. 자동으로 빌드되고,
3. 자동으로 테스트되어,
4. 릴리즈되고(배포준비완료),
5. 배포된다.

2. CI/CD를 위한 도구

정말 많다.

https://ichi.pro/ko/hyeonjae-sayong-ganeunghan-choegoui-ci-cd-dogu-27gaji-194611649728144

이 중에서 가장 대중적인 후보 3가지를 골라서 장단점을 조사해보았다.

Jenkins

무료라는 점과 많은 사용자를 가졌다는 점이 매력적이다.

특히 많은 문서와 선례들을 통해서 거의 모든 문제상황에 대처할 수 있을 것이다.

다만 하나같이 설정과 운영하는 측면에서 불편하다는 평이 많다.

손도 많이 가고 특히 별도의 서버를 준비해 거기에 설치하여 운영하는 방식이라 무료지만 실제론 무료가 아닌? 그런 느낌

(주로 t2.medium을 권하더라)

규모가 작은 프로젝트에서는 그렇게 추천하진 않는다.

Travis

• 깃허브와 연동
• 빌드 과정을 한 눈에 이해하기 쉽다.
• 초기 설정이 젠킨스에 비해 간편(YML 파일을 통한 설정)
• 별도의 서버 필요 없다. travis에서 알아서 VM으로 호스팅 해준다.
• 기업용의 경우 다소 비싸다(월 129달러)
• 로컬에서 CI환경과 동일한 빌드환경을 제공하지 않는다.
• 젠킨스에 비해 플러그인이 다양하지 않다.
• .travis.yml 파일을 수정하고 테스트하려면 git push를 반복해야한다.

Github Actions

요즘 대세는 깃헙액션인것 같다.

빠르고, 서드파티가 필요없기 때문에.

다만 얘도 설정이 다소 복잡하다는 평이 있지만 젠킨스만큼은 아니고 그만큼 정교한 작업이 가능하다는 뜻이기도 하다.

(직접 써봐야 알겠지만ㅠ)

다음은 뱅크샐러드에서 Travis를 사용하다가 Github Actions로 전환 후 개선된 점이다.

참고: