프로찍먹러

docker system prune --all --force

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로 전환 후 개선된 점이다.

참고:

혼자 개발할때는 사용하지 않고 그냥 이런게 있구나 정도로 넘겼던 도커.

이제 막 배우기 시작하는 입장으로서 한번 개념만 정리해보자.

1. 부두 노동자

어학사전에 docker를 검색하면 부두(항만) 노동자라고 나온다. 

해외에서

화물 컨테이너가

배를 타고 부두에 도착하면

노동자들이

화물 컨테이너를 받아준다.

이를 도커로 바꿔보면

해외(도커 레지스트리)에서

화물 컨테이너(도커 이미지)가

부두(나의 PC)에 도착하면

노동자(도커)들이

화물 컨테이너를 받아준다(도커 이미지를 도커 컨테이너로 만들어 실행시킨다)

이 비유가 맞다고 확신은 못하지만 내 생각엔 맞는 것 같다.(아니라면 알려주세요ㅠㅠ)

2. 컨테이너 기반 가상화 플랫폼?

혼자 개발할때는 나의 PC에 필요한 소프트웨어들을 미리 설치해두고 개발한다. 내가 작성한 코드들은 미리 설치해둔 환경에 의존하며 실행된다. 여기까진 좋은데 내가 만든 것을 배포하려면 어떻게 해야할까? 사용자들도 나의 PC와 같은 환경이 미리 준비돼 있어야 내가 만든 SW가 정상적으로 동작할텐데 말이다. 이때 도커를 사용한다.

도커는 애플리케이션을 어떤 환경에서도 자유롭게 사용할 수 있게 해준다.

도커의 역할을 한마디로 요약해보면

"내가 만든 애플리케이션과

애플리케이션에 요구되는 환경을

몽땅 압축해서 배포하기"

and

"남이 만든 애플리케이션을

애플리케이션에 요구되는 환경과 함께

한번에 받아와서 실행하기"

정도이려나?

(피드백 달게 받습니다..)

VM과 비슷한 개념이긴 하나 VM은 OS위에 다른 OS를 생으로 다시 올린다. 각 VM은 하나의 서버를 여러 서버로 전환하는 물리적인 하드웨어의 추상화라고 하는데 이는 매우매우 무겁다.

도커는 여러 종류의 컨테이너가 동일한 시스템에서 실행되고 호스트의 OS 커널을 다른 컨테이너와 공유할 수 있기에 VM보다 부담이 적다. 즉, 실제로(HW적으로) 내 PC에서 공간을 나누진 않았지만 각각의 독립된 공간을 가진것 처럼 동작하도록 하는 기술이다.

3. 이미지, 컨테이너, 레지스트리

나의 애플리케이션, 혹은 누군가 만들어 놓은 애플리케이션의 실행에 필요한 모든 것들(라이브러리, 미들웨어, OS, 네트워크 설정 등)을 모아서 도커 이미지라는 것으로 만든다.

이 이미지들을 클라우드상에 모아놓은 곳을 레지스트리라고 한다.

대표적인 레지스트리로 도커허브가 있다.

내가 만든 이미지나 남이 만들어 놓은 이미지들을 올리고 내려받을 수 있다. 

이 이미지들을 내려받아서 실행시킨 것을 컨테이너라고 한다. 

이 고래가 도커엔진이고 위에 네모난 것들이 이미지를 내려받아 생성한 컨테이너다.

즉 도커 엔진 위에서 여러 컨테이너들이 실행중인 모습을 보여준다.

이미지를 실행한 상태인 컨테이너는 애플리케이션을 패키징/캡슐화하여 격리된 공간에서 프로세스를 동작시킨다.

일단은 내 로컬 PC 어딘가에서 프로세스가 실행되는 것이긴 한데 이 공간은 내가 접근할 수 없는 격리된 공간이다. 

컨테이너의 특징을 정리하자면

• 가상머신과 비교하여 컨테이너의 생성이 쉽고 효율적이다.
• 컨테이너 이미지를 통한 배포와 롤백이 간단하다.
• 언어나 프레임워크에 상관없이 애플리케이션을 동일한 방식으로 관리한다.
• 개발, 테스팅, 운영 환경은 물론 로컬 PC와 클라우드까지 동일한 환경을 구축한다.
• 특정 클라우드 벤더에 종속적이지 않다.

4. 레이어

도커 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기에 용량이 보통 수백MB다.

따라서 기존 이미지에서 살짝 무언가가 추가된 이미지를 다시 받는다고

이미지 전체를 다시 받으면 용량적으로 비효율적이다.

따라서 이미지는 레이어로 구성되어있다.

이미지1이 A+B+C의 레이어(구성 요소)로 이루어져있는데

C를 수정한 A+B+C*의 이미지를 받아야 한다면 C레이어만 C*로 수정된다.

위 그림에서 MySQL의 버전이 변경된 새로운 이미지를 내려 받는 경우를 생각해보면 될 것이다.

이미지를 내려받을 때 다음과 같은 로그가 나온다.

$ docker pull mysql

Using default tag: latest
latest: Pulling from library/mysql
69692152171a: Extracting [=======>                                           ]  4.129MB/27.15MB
1651b0be3df3: Download complete 
951da7386bc8: Download complete 
0f86c95aa242: Download complete 
37ba2d8bd4fe: Download complete 
6d278bb05e94: Download complete 
497efbd93a3e: Download complete 
f7fddf10c2c2: Download complete 
16415d159dfb: Downloading [>                                                  ]  2.157MB/115.8MB
0e530ffc6b73: Download complete 
b0a4a1a77178: Waiting 
cd90f92aa9ef: Waiting

69692152171a와 같은 한 줄 한 줄이 모두 레이어이다. 

이런 레이어가 한 겹 한 겹 쌓이고 하나의 이미지로 만들어진다.

이후 이 이미지를 docker run으로 실행하면 도커가 관리하는 파일 시스템 영역에 이미지를 복사한다.

복사 후 이미지 레이어 최상단에 컨테이너 레이어를 추가한다. 이로써 이미지는 컨테이너가 된다.

그리고 사용자에겐 Union File System을 사용하여 레이어가 스택 구조로 쌓인 이미지를 하나의 파일 시스템처럼 보이게 한다.

컨테이너 레이어는 변경 가능하고,

이미지 레이어는 변경 불가능하다.

컨테이너 레이어는 컨테이너 종료 시 소멸되고,

이미지 레이어는 삭제되지 않는다.

레이어를 사용하면 위에 말했 듯 애플리케이션의 일부를 변경할 경우 이미지 전체를 다시 다운받지 않고

변경된 부분의 레이어만 교체해 주면 된다.

5. 정리

그림으로 도커의 전반적인 동작을 정리해보자

왼쪽에 (Code, OS, Other Dependencies)가 Dockerfile로 합쳐지고 이를 build하여 도커 이미지를 생성함을 볼 수 있다.

이렇게 생성된 이미지는 내 PC에 있는 도커엔진에서 실행되어 컨테이너 상태가 된다.

또 왼쪽에 EXE파일로 실행한 프로세스를 확인할 수 있는데 이건 내 PC위에서 실행되는 일반적인(도커가 아닌) 프로세스를 표현한 것 같다.

자 이제 이렇게 내 PC에서 실행되고 있는 두 프로세스(도커 컨테이너와 일반 프로세스)를 그림 우측처럼 다른 환경으로 옮기면 어찌될까?

도커를 통한 공유(배포)는 애플리케이션 실행을 위한 환경이 모두 준비된 이미지를 배포하기에 다른 환경이라도 이를 받아줄 수 있는 도커 엔진만 있다면 정상적으로 동작한다.

단, 일반적인 프로세스라고 표현한 저 애플리케이션은 내 PC와 다른 환경이기에 동작하지 않을 수도 있다.

참고: