[Sparta] 15-1. GitHub Actions

2021-10-06

To-Do

• 7시 기상
• 아침식사
• 오전운동

• 어제 새벽까지 GitHub Actions를 구동하게 하려고 정말 많은 노력을 했다.... 결국 해결하지 못했는데, 오늘 아침에 혹시 하는 마음으로 레포 이름을 바꿔서 새로 만드니까 되더라... 왜인지 정확히는 모르겠다 ..ㅠㅠ

Today I Learned

1. GitHub Actions

1. GitHub Actions란?

GitHub Actions는 Github에서 제공하는 배포 서비스이다. GIthub가 MS에 인수되면서 기존의 소스저장소의 기능에서 DevOps플랫폼으로 발전하고 있다.

GitHub을 한진물류연구원 인턴 때 부터 사용했으니까.. 대충 8개월 정도 사용하였다. 물론 협업툴로써 사용한지는 이제 2주정도 되었지만, Actions는 진짜 처음 들어봤다. (repo에 있는 actions탭이 어떤 기능일까 눌러보지도 않....) 이제부터 부지런히 알아가자...

요즘은 CI/CD의 통합이 개발의 트랜드라고 한다. 그러니까 깃헙같은 소스저장소와 배포시스템을 통합하는 것인데, 이는 점점 작아지는 어플리케이션 아키텍쳐를 더 자주 더 부담없이 배포할 수 있게 한다. Github에 push(CI)하면 AWS 인프라에 Delivery(CD)가 되어야 한다. 이러한 과정을 도와주는 서비스가 GitHub Actions이다. GitHub Actions는 간단하게는 서버에 소스를 배포하는 서비스라고 할 수 있다.

위에서 언급했듯, 이제는 Monolithic Architecture의 개발이 아닌, Micro Service Architecture의 개발로 트랜드가 넘어오기 때문에, CI/CD가 가능해졌다. 예전에는 서비스의 최신버전을 배포하려면, 결제만 몇번을 받고, 예상가능한 모든 경우의 수를 따져본 뒤, 최종의 최종을 배포했다고 한다. 하지만, 지금은 서비스의 최소단위만 따로 업데이트가 가능하니 CI/CD와 같은 효율적인 업무가 가능하여 생산성이 많이 올라갔다고 한다.

2. GitHub Actions 사용법

index.html이 local에서 수정 된 후 repo에 push되면 S3에 index.html이 업로드 되어야 한다. 따라서 GitHub Actions에서 S3에 배포할 수 있는 권한을 줘야한다.

S3에 업로드 후 CloudFront에도 변경이 되게 하려면 이미 캐싱되어있는 파일을 새롭게 캐싱해야한다. 이러한 것을 invalidation이라고 하며 이 또한 GitHub Actions에서 진행한다.

따라서 GitHub Actions과 IAM을 연동하여 S3와 CloudFront, 두개의 서비스에 접근 할 권한을 부여해야한다.

AWS 접속 > IAM 사용자 계정 접속 > 권한 추가 > 기존 정책 직접 연결 > CloudFrontFullAccess 선택 > 권한 추가

Github에 원하는 이름의 repo를 파서 local의 폴더와 remote시켜준다. 그 후 local의 루트폴더에서 .github/workflows/main.yml을 추가하며 된다. yml은 또 뭔가... 일단은 json같이 구조화된 자료를 담는 파일이라고 생각하자...

코드에디팅에는 pycharm을 사용하였다.

name: my-front # 이름, 아무거나
on: # action이 일어날 조건
  push:
    branches:
      - main # main branch가 push 되었을 때
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      AWS_REGION: 'ap-northeast-2'

    steps:
      - name: Checkout source code.
        uses: actions/checkout@master

      - name: Upload binary to S3 bucket
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --acl public-read --exclude '*' --include 'index.html'
        env:
          AWS_S3_BUCKET: ${{ secrets.BUCKET_NAME }}

      - name: Invalidate cache CloudFront
        uses: chetan/invalidate-cloudfront-action@master
        env:
          DISTRIBUTION: ${{ secrets.DISTRIBUTION_ID }}
          PATHS: '/index.html'
        continue-on-error: true

해당하는 사항을 모두 만족 후 repo에 push하려는 순간 에러 발생!

잠시 구글링해보니 내가 발급받아 사용중인 토큰에는 workflow에 접근 할 권한이 없는 것 같다... 먼저 고민하신 분들의 고견을 들어보니 이것저것 해보려 하지말고 토큰을 새로 발급받고, 이때 workflow에 체크를 하는 것이 답이라 하신다... 네...ㅠ... 다시 발급받고 windows 자격 증명 관리 > 일반 자격 증명에서 github에 관련된 모든 키를 싹 업데이트 해줬더니 잘 작동하였다.

• secrets.AWS_ACCESS_KEY_ID : IAM 생성 시 발급 받은 값
• secrets.AWS_SECRET_ACCESS_KEY : IAM 생성 시 발급 받은 값
• secrets.BUCKET_NAME : S3의 이름
• secrets.DISTRIBUTION_ID : CloudFront의 배포 ID

딱 봐도 위의 네 값은 그냥 푸시하면 안될 것 처럼 생겼다. 따라서 해당 변수를 따로 저장해주자. github에서 이렇게 보안상 중요한 변수들을 따로 저장 할 수 있게 마련해두었다.

해당 레포로 돌아가서 Settings > Secrets > New repository secret클릭 후 위의 변수 명을 name에 해당하는 값을 value에 넣고 Add secret을 눌러준다.

모든 설정을 마쳤는데... "There are no workflow runs yet."라는 메세지와 함께 작동하지 않는... github actions... 눈물이 앞을 가린다... 세시간을 넘게 잡고있다가 혹시 폴더 이름이 문제인가? 하고 Lukaid_AWS에서 lukaid-aws로 레포를 새로 파서 진행을 하지 정상작동을 하였다. 이게 정말 레포의 이름 때문인지, 아니면 새로 만드는 과정에서 뭔가 변경된게 있는건지 모르겠지만... 어쨌든 해결은 되었다 ㅠㅠ