엉금엉금

prune이란 키워드로 안 쓰는 docker images와 container를 관리할 수 있다.

   - name: SSH Remote Commands
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PASSWORD }}
          port: 22
          timeout: 40s
          script: |
            docker login -u ${{ secrets.DOCKERHUB_USERNAME }} --password-stdin ${{ secrets.DOCKERHUB_TOKEN }}
            docker rm -f houssg-front
            docker pull ${{ secrets.DOCKERHUB_USERNAME }}/houssg-front:latest  
            docker run -d -p 80:80  \
            --name houssg-front ${{ secrets.DOCKERHUB_USERNAME }}/houssg-front:latest
            docker image prune -a -f

기존에  컨테이너만 삭제했더니 너무 많은 이미지가 생겼다. 이때 prune이라는 키워드는 사용하지 않은 이미지와 컨테이너를 제거해줄 수 있다. (image container system 키워드로 각각 이미지 컨테이너 전부다) 를 지울 수 있음.

이후 gitaction 에서는 삭제시 추가적으로 y 를 못 누르기 떄문에   -f 키워드로 바로 삭제

https://docs.docker.com/engine/reference/commandline/system_prune/

빌드에 실패했따. 
단순히 빌드 실패 뿐만  deprecated 되는 버전 사용에 따른 경고문도 떴다.

 github action 을 처음 사용해서 예시본을 참고하여 복붙하였더니 생겼던 에러고, 이를 공식문서와 

https://www.daleseo.com/github-actions-checkout/

님의 게시글을 통해서 해결하려고 했다.

우선 버전 문제 때문에 빌드오류가 났다고 초기에 판단하여서

https://github.com/marketplace?type=actions&query=checkout+ 

각각의 키워드에 대해서 검색을 하여서 분석하였다.

수정된 코드는 아래와 같다.

이 코드는 Dockerfile을 통해서 빌드를 한 이후 빌드된 프론트엔드 코드는 ec2에 배포하는 코드이다.

name: Build Image

on:
  push:
    branches:
      - 'main'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
      - name: Login to DockerHub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
      - name: Build Container Image
        uses: docker/build-push-action@v5
        with:
          context: ./houssg
          file: ./houssg/Dockerfile.prod
          platforms: linux/amd64
          push: true
          tags: ${{ secrets.DOCKERHUB_USERNAME }}/houssg-front:latest

      - name: SSH Remote Commands
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          password: ${{ secrets.SSH_PASSWORD }}
          port: 22
          timeout: 40s
          script: |
            docker login -u ${{ secrets.DOCKERHUB_USERNAME }} -p ${{ secrets.DOCKERHUB_TOKEN }} 
            docker pull ${{ secrets.DOCKERHUB_USERNAME }}/houssg-front:latest  
            docker rm -f houssg-front
            docker run -d -p 80:8080  \
            -e VITE_KAKAO_JS_KEY=${{ env.VITE_KAKAO_JS_KEY }} \
            -e VITE_KAKAO_KEY=${{ env.VITE_KAKAO_KEY }} \
            -e VITE_SERVER_URL=${{ env.VITE_SERVER_URL }} \
            ${{ secrets.DOCKERHUB_USERNAME }}/houssg-front:latest --name houssg-front ${{ secrets.DOCKERHUB_USERNAME }}/houssg-front :latest

이때 모든 uses에 대한 버전을 수정해주었고, 버전을 검색하면서 각각의 키워드가 어떤 역할을 하는지 확인하였다.

1. checkout : This action checks-out your repository under $GITHUB_WORKSPACE, so your workflow can access it

gitaction이 내 어떤 레파지토리에서 실행될 지를 결정하는 키워드인데, 기본값이 현재 레파지토리이다.따라서 별다른 설정없이 넘어갔다.

https://github.com/marketplace/actions/checkout

2. docker/setup-buildx- : This action will create and boot a builder that can be used in the following steps of your workflow if you're using Buildx or the build-push action

https://github.com/marketplace/actions/docker-setup-buildx

도커 컨테이너를 실행하기 위한 빌더를 만들고 실행해줍니다. 이를 통해서 도커 컨테이너가 도커 이미지를 만들 수 있게 됩니다.

3. docker/login : 도커에 로그인하게 해줍니다. with과 secret 값을 통해서 아이디와 토큰을 사용할 수 있습니다.

https://github.com/marketplace/actions/docker-login

4.docker/build-push : 도커파일을 통해 빌드하고 도커 허브에 이미지를 업로드 합니다.

5. appleboy/ssh-action :  리눅스 도커 컨테이너에서만 지원됩니다 깃허브 액션으로 원격 ssh 작업을 수행할 때 사용됩니다. 이를 통해서 ec2에서 제가 만든 도커  컨테이너를 도커허브에서 불러와서 실행할 것 입니다.

https://github.com/marketplace/actions/ssh-remote-commands

위 링크들을 통해서 각각의 액션들의 버전을 최신화 하였지만 아직 build에러를 해결하지 못했습니다.

https://stackoverflow.com/questions/66146088/docker-gets-error-failed-to-compute-cache-key-not-found-runs-fine-in-visual

똑같은 에러를 검색했더니 위의 링크가 떴는데, 저 방법은 내 에러와 연관은 있지 않았습니다.

제 문제는 초기에 context를 . 으로 하였는데, 제 실제 프로젝트의 위치가 ./houssg 였기 때문에 package.json을 찾지 못해 생긴 에러입니다.

context 의 의미 : Build's context is the set of files located in the specified

프로젝트를 하다보면 issue를 통해서 팀원과 소통하는 일이 생긴다.

우리 조는 GITHUB을 통하여서 issue 이름과 내용을 작성하고,  pull request 시에 해당 이슈를 태그하는 방식으로 이슈 추적을 하려고 했다. 하지만 이때 개개인이 다르게 issue를 작성한다면 이슈 내용 파악에 불편함을 느낄 수 있다.

따라서 통일된 Templates를 통해서 가이드라인을 제시한다면 팀원끼리 소통하는데 조금 더 수월할 수 있다.

Issue Templates 생성하기

깃헙에서 내 issue를 생성하고 싶은 레퍼지토리에 들어가서 setting을 누르고 스크롤 하면

Features에  Set up templates를 찾을 수 있다.

해당 버튼을 누르면 기초 템플릿을 설정할 수 있다.

결국 커스텀 가능하지만, 기본적인 모양이 갖춰져 있는 Feature request를 선택하고 수정하는 것을 추천합니다. (버그 수정용 템플릿이라면 위에껄 선택)

기본적인 양식은 위와 같은데 제목옆에 연필 버튼을 누르면 수정이 가능합니다.

위의 템플릿이 어떤 형식으로 되었는지 볼 수 있습니다. 위 코드와 비교해보면 **이 굵게 한다는것도 알 수 있네요

꾸미는 자세한 방법은

https://docs.github.com/ko/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax 에서 확인할 수 있습니다.

작성을 완료하고 issue를 처음 발행하려고 하면 템플릿 설정창이 뜹니다.

해당 파일을 선택하면  내가 작성했던 템플릿이 issue 작성시마다 불러와 지는것을 확인할 수 있습니다.

하지만 이렇게 만들 경우에는
매번 getStarted를 통해서 작성하는 불편함이 생긴다. 레포지토리를 보면 아래와 같은 구조로 되어있다.
(해당 폴더안에 있는 파일들을 자동으로 제안함)

이를 default 값을 미리 설정하고 싶다면 작성했단 이슈 파일명을 issue_template.md 로 변경하고 , 이전에 생성했던 폴더를 제거하면 된다.

pull_request_template 또한 동일한 과정을 거쳐 작업하면 된다.

 보통 개발을 처음 배우기 시작하면서 Git 을 배우게 된다.

깃을 처음 배울 때, 가장 자주 보는 그림은 아래와 같은 것일 거다.

실제로 깃을 내가 배우고 나서도, 이력서를 쓸 때 버전 관리를  날짜로 하였다. 

그러다가 깃을 어떠한 경우에 활용하면 효율적인가에 대해서 배울 기회가 생겨서 이렇게 공유하게 되었다.

깃을 사용할 때는 크게 5가지의 시나리오가 있다.

1. 혼자 작업을 할 때 한 컴퓨터에서 버전 관리.

이력서를 쓸 때, 이력서를 계속 보완하게 될 것이다. 그러다보면 수정한 것보다 전 버전이 마음에 든 경우도 있을 수 있다. 모든 버전을 저장한다고 생각해보자. 이 경우 어떤 이력서가 최신 것인지 구별하기도 어렵고 , 파일도 너무 많아질 것이다.

이를 관리하기 위해서 깃을 사용하면 좋다.

git init 명령어를 통해서 해당 폴더를 깃으로 관리하게 되는 경우, 커밋 내역을 통해서 내가 어떻게 수정했는지 확인도 가능하고, 원하는 버전으로 롤백 또한 가능하다. (굳이 여러 파일로 나누지 않더라도)

2. 혼자 작업을 하는데, 다른 컴퓨터에서 사용할 경우

 발표 자료를 준비했다고 생각해보자. 보통 우리는 클라우드 혹은 usb에 해당 파일을 저장한다. 하지만 git push 기능을 통해서 git hub에 파일을 저장해 놓은 경우에는 굳이 클라우드 혹은 usb를 사용하지 않더라도 해당 파일을 사용할 수 있다.

이때 사용되는 기능이 저장소에 저장하는 git push 와 저장소를 복제하는 git clone 이다.

3.   혼자 작업을 하지만, 다른 컴퓨터에서도 작업할 경우

 git push를 통해서 내가 현재 작업한 내용을 원격 저장소에 백업을 해놓았지만, 이 내용이 원격 저장소에서는 같지만 내 컴퓨터와 회사 컴퓨터에서는 다를 수가 있다.

이를 해결할 수 있는 것이 git pull 이다. 원격 저장소에 저장된 내용을 바탕으로 내 컴퓨터에 저장된 내용을 최신화 하는 과정이다.  이 과정에서 실수로  내 컴퓨터를 최신화하지 않고 작업을 한다면, 회사에서 작업한 내용과 내가 작업한 내용이 겹칠 수가 있다. 이를 충돌이라고 하는데, git 을 통해서는 해당 충돌 내용을 비교해서 내가 필요한 내용을 취합 할 수 있다.

충돌의 경우는 결국 추가 작업이기 때문에 git에서는 pull을 먼저해야지만 내 내용을 push할 수 있도록 되어 있고, 가급적이면 작업전에 pull을 먼저 하는게 좋다.

4. 혼자 작업을 하지만, 공통된 부분 말고 따로 관리하고 싶을 때

이력서를 쓴다고 생각해보자. 모든 회사에 같은 이력서를 제출할 수는 없다. 이때 사용할 수 있는 기능이 git branch이다.

개인 신상과 같이 공통된 내용은 최상단 브랜치에서 관리를 하고,  브랜치 기능을 통해서 각각의 회사별 이력서를 관리할 수 있다.

5. 여러 명에서 같은 파일을 통해 작업을 하는 경우

여러 명에서 같은 파일을 통해 작업을 한다고 생각을 해보자. 매번 충돌이 일어날 것이다. 이를 매번 해결하는 과정도 복잡하고, 사람 수가 늘수록 작업에 큰 지장을 줄 것이다. (pull을 했는데, 바로 다음 사람이 push한 경우 또 pull을 해야한다

이를 해결할 수 있는 방법이 git branch이다.

각각의 브랜치에서 작업을 하는 경우, 매번 pull을 할 필요 없고 최종적으로 내 작업이 끝날 때만 git merge를 하면 된다.

git merge는 가지처럼 뻣어나간 각각의 branch에서 작업한 내용을 합치는 기능이다.

이러한 깃의 활용도가 늘어나면 git branch 전략을 사용하여서, 배포할 웹 혹은 앱의 현재버전, 배포준비 버전, 핫픽스 버전, 개발 버전 등등 나뉘어서 작업할 수 있다.