배포 자동화를 해보자-1(Github Actions)

ㅇ 배포 자동화

클릭 이나 명령어 입력을 통해서 전체 배포과정을 진행하는것

왜할까? 수동으로 배포를 할때보다 자동으로 하는게 시간절약되고, 휴먼에러를 방지 할 수 있다.

 

ㅇ 배포 자동화 파이프라인

소스코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조.

파이프라인을 크게 세단계로 나눌 수 있다.

Source 단계 : 원격 저장소에 관리되고 있는 소스코드의 변경이 일어날 경우, 다음단계로 전달함.

Build 단계 : 전달받은 코드를 컴파일, 빌드, 테스트해 가공함. build단계를 거쳐 생성된 결과물을 다음 단계로 전달함.

Deploy 단계 : 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행함.

 

ㅇ AWS 개발자 도구

개발자 도구 섹션에서 제공하는 서비스를 활용해 배포자동화 파이프라인을 구축할 수 있다.

CodeCommit - Source 단계를 구성할때 사용함. 깃헙같이 버전관리 도구임. 깃헙에 비해 CodeCommit은 보안과 관련된 기능에 강점을 가짐.

CodeBuild - Build 단계에서 사용함. 유닛 테스트, 컴파일, 빌드단계에서 필수적으로 실행되어야 할 작업들을 실행 가능함.

CodeDeploy - Deploy 단계에서 사용. 실행되고 있는 서버애플리케이션에 실시간으로 변경 사항을 전달할 수 있음. 

CodePipeline - 각 단계를 연결하는 파이프라인을 구축할때 사용함.

 

ㅇ Github Actions

깃헙액션은 깃헙에서 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화 하는 CI/CD 플랫폼이다. 레포지토리에서 pull request나 push같은 이벤트를 시작으로 GitHub 작업 워크플로우를 구성할 수있고, 각 작업은 가상머신이나 컨테이너 내부에서 실행된다. 워크플로우는 .yml파일로 구성되고, 여러개의 워크플로우를 만들 수도 있다. 

내가 코드스테이츠에서 배운 workflow는 이렇다. 

ㅇ S3

배포자동화에서는 저장소로 사용하고, Github Actions 에서 빌드한 결과물이 압축되어 S3로 전송되고 버킷에 저장됨.

ㅇ Code Deploy

S3에 저장되어있는 빌드 결과물을 EC2 인스턴스로 이동. 프로젝트 최상단에 appepec.yml 파일에의해 특정 동작을 함.

Code Deploy Agent의 설치가 필요함.

 

ㅇ gradle.yml 파일 만들기

먼저 github에 들어가서 Actions에 들어가서, java with gradle을 선택했다.

조금 수정해보자.

name: Java CI with Gradle

on:
  push:
    branches: [ "dev" ]
  pull_request:
    branches: [ "dev" ]

permissions:
  contents: read
  
env:
  S3_BUCKET_NAME: b-knockknock

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
    - name: Build with Gradle
      run: |
        cd back/KnockKnock
        ./gradlew build
#       uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
#       with:
#         arguments: build
    
    # build한 후 프로젝트를 압축합니다.
    - name: Make zip file
      run: zip -r ./practice-deploy.zip .
      shell: bash
    
    # Access Key와 Secret Access Key를 통해 권한을 확인합니다.
    # 아래 코드에 Access Key와 Secret Key를 직접 작성하지 않습니다.
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }} # 등록한 Github Secret이 자동으로 불려옵니다.
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} # 등록한 Github Secret이 자동으로 불려옵니다.
        aws-region: ap-northeast-2
    
    # 압축한 프로젝트를 S3로 전송합니다.
    - name: Upload to S3
      run: aws s3 cp --region ap-northeast-2 ./practice-deploy.zip s3://b-knockknock/practice-deploy.zip
    - name: Grant execute permission for gradlew
      run: chmod +x ./gradlew build

오른쪽 위에 Commit changes ... 를 눌러준다.

하하하

역시나.

gradle/wrapper/gradle-wrapper.properties를 못찾는다고한다.

 

내가 잘못생각하고 있었다.

먼저 기본 폼을 사용해야 한다. 

기본 폼에서 gradle-wrapper 파일까지의 경로를 수정했다.

name: Java CI with Gradle

on:
  push:
    branches: [ "dev" ]
  pull_request:
    branches: [ "dev" ]

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
    - name: Build with Gradle
      run: |
        cd back/KnockKnock
        ./gradlew build
#       uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
#       with:
#         arguments: build

요롷게 수정하고, S3 버킷을 만들러 갔다.

ㅇ 버킷만들기

버킷을 간단하게 만들고, 정적 웹 사이트 호스팅을 활성화 하고 끝.

 

ㅇ Github Secret 등록하기

github 레포지토리에서 Settings 클릭 > Secrets > Actions 탭으로 이동하고 [New repository secret] 클릭

여기에 AWS 페이지에서 맨오른쪽

자기이름을 누르고 보안자격 증명눌러서 비밀번호를 만들어준다.

그러고 다시 gradle.yml을 수정해주는데, 처음에 했던 gradle.yml 파일로 다시 해본다.

오우씻

드디어 됐다. 너무 행복하다.

 

그리고 S3 버킷으로 가면 짜잔

이렇게 잘 전달된걸 볼 수 있다!

 

ㅇ CodeDeploy

다음단계는 배포그룹생성이다.

aws에서 codedeploy를 치고 애플리케이션으로 들어가 생성해준다! 그다음에 배포그룹을 생성해보자.

 

다음편에 계속-