[CI/CD] github action 맛보기 기록

2022. 6. 28. 20:47기타

반응형

 

<봐도 도움안됨 주의 ! > - 미래의 저를 위해 작성한 게시글입니다..

 


 

airbnb 클론 프로젝트에서, github action을 통한 CI/CD를 구축해보는 요구사항이 있어 맛볼 기회가 있었습니다.

사실 github action이라는 말을 들어보기 전까지는 CI/CD라는 것 자체를 알지 못했습니다. 모든게 생소해서 과정은 조금 고생스러웠지만 해놓고 나니 너무 편하고 좋은 기억이 많이 남네요. 추후에도 이 감동과 편리함을 기억하고자 미래의 스스로를 위해 작성합니다.

 

더보기

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법입니다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다. CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 "인테그레이션 헬(integration hell)")을 해결하기 위한 솔루션입니다.

(출처: https://www.redhat.com/ko/topics/devops/what-is-ci-cd )

 

어플리케이션 개발자는 코드에만 집중해! 나머지는 내가 해줄게! 느낌입니다.

 

 


 

 

요구사항은 다음과 같았습니다.

  • 배포 서버에는 항상 동작하고 있는 버전이 배포되어 있어야 한다. 지정 브랜치를 이용해서 서비스를 배포한다.
  • GitHub Action을 학습하고 이를 이용해 배포를 진행한다.
  • Docker를 학습하고 도커 이미지를 이용해 배포를 진행한다.

 

지정 브랜치 배포? 오케이. github action? 흠.. Docker? 흠..

 

 도커도 모르고 깃헙 액션도 잘 모르니 막막했지만 우리의 갓허브는 저같은 뉴비를 위해 액션 전용 템플릿 공유 플랫폼도 만들어두셨습니다 대박... 

올라와있는 워크플로우들...

 

 

 

원하는 워크플로우를 찾았다면, 개발환경에 맞게 작성해줍니다

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-gradle

name: Java CI with Gradle

on:
  workflow_dispatch: 
#   branches: [BE]

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      working-directory: ./BE/airbnb

    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew
        working-directory: ${{env.working-directory}}

      - name: Build with Gradle
        run: ./gradlew compileQuerydsl
        working-directory: ${{env.working-directory}}

      - name: Build and Push Docker Image
        uses: mr-smithers-excellent/docker-build-push@v4
        with:
          image: ${{ secrets.DOCKERHUB_ID }}/team07-airbnb
          registry: docker.io
          dockerfile: ${{env.working-directory}}/Dockerfile
          username: ${{ secrets.DOCKERHUB_ID }}
          password: ${{ secrets.DOCKERHUB_PASSWORD }}

      - name: Deploy 😆 - multiple host
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.EC2_WAS_IP }}
          username: ec2-user
          key: ${{ secrets.PRIVATE_KEY }}
          envs: GITHUB_SHA
          script: |
            docker pull team07-airbnb:backend-${GITHUB_SHA::7}
            docker tag team07-airbnb:backend-${GITHUB_SHA::7} airbnb:backend-${GITHUB_SHA::7}
            docker stop server
            docker run -d --rm -e profile=$profile -e MYSQL_DATABASE_USERNAME=$MYSQL_DATABASE_USERNAME -e MYSQL_DATABASE_URL=$MYSQL_DATABASE_URL -e MYSQL_DATABASE_PASSWORD=$MYSQL_DATABASE_PASSWORD -e github_client_id=$github_client_id -e github_secret_key=$github_secret_key -e jwt_secret=$jwt_secret -e jwt_expire_length=$jwt_expire_length --name server -p 8080:8080 airbnb:backend-${GITHUB_SHA::7}

 

 

 

민감정보를 github로 공개할 수는 없다! 레포지토리 별로 시크릿을 등록할 수 있음. -> 추후 ${{ secrets.xxx }} 로 접근하면 됨

secret 정보를 감추기 위해 따로 등록한다.

 

 

 build.gradle과 같은 위치에 Dockerfile도 미리 만들어두어야 한다.

FROM openjdk:11-jdk
COPY ./BE/airbnb/build/libs/*.jar airbnb.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/airbnb.jar"]

 

 

...도커 설정은 알아서 잘 하렴 미래의 나야.. 나 말고도 정보가 많으니 너에게 맡긴다..

 

 

완성!

풀리퀘스트 머지나 커밋이 있을 때마다 감지해서 자동으로 올려주는 기능도 있는데, 학습 프로젝트에는 좀 과한 것 같아서 수동으로 Run하도록 설정했다.

 

 

잘 된다. 빨간색인 건 빌드가 안되는 프로젝트를 코드리뷰 없이 머지했다가 생긴 참사..

 

가장 많이 헤맨 부분은

ec2에 환경변수를 설정하는 부분이었습니다. 아직도 약간 의문이긴 하지만... 아마존 리눅스 /etc/profile 에 profile설정 정보나 DB 민감정보 등을 담아뒀었는데 아무리 해도 그 환경변수를 가져오지 못하는 것었습니다.. 코드스쿼드 브레인이 모두 모여 삽질을 한 결과 

bashrc에 환경변수를 옮겼더니 허무하게 되었더라는 해프닝..

echo로 찍어도 잘 나오는데 왜 안되느냔 말이다....

기쁨의 뽀뽀선언

 

샤인의 조언

https://ttend.tistory.com/768

 

etc/profile, .profile, /etc/bashrc .bashrc

etc/profile과 .profile의 차이 유닉스 시스템을 운영하는 경우 환경 설정 등을 위해서 /etc/profile이나 .profile을 편집해야 하는 경우가 있다. 근데 어떤 책은 .profile에 추가하라고 나오고 어떤 블로그는

ttend.tistory.com

환경변수 설정에도 단계가 있었습니다 -_-;; 알고 싶지 않은 지식이 쌓이는 것 같습니다. 침착맨은 이걸 과잉지식이라고 하던가요.. 환경변수 심화내용. 어떻게 알았냐구요? 저도 알고 싶지 않았습니다......

여전히 재현 못하고 있는 상황이라서 마음에 묻고 넘기려고 합니다... 찝찝해라..

 

 

 

 

 

github action의 작동원리를 알지는 못합니다.. 너무 깊은 것 같아서 아직은 '사용할 수 있다' 정도 단계에서 멈추고 다른 더 중요한 공부를 하려고 합니다..

 

그리고.. 굳이 도커를 써야 하나요? 에 대한 답변..?

https://www.44bits.io/ko/post/why-should-i-use-docker-container

 

왜 굳이 도커(컨테이너)를 써야 하나요? - 컨테이너를 사용해야 하는 이유

컨테이너는 서버 애플리케이션을 배포하고 서버를 운영하는 표준적인 기술이 되어가고 있습니다. 하지만 처음 사용해본다면 그 장점이 잘 와닿지 않을 수도 있습니다. 왜 굳이 도커 컨테이너를

www.44bits.io

 

반응형