[Trouble Shooting] Git Actions CI/CD

문제 발생

CI/CD 학습 중 Git Action 으로 실습을 하는 도중 문제가 생겼다.
아래는 배포를 위한 action 내 ubuntu에서 실행 될 구문이다.

        run: |
          echo "${{ secrets.EC2_PRIVATE_KEY }}" > private_key.pem
          chmod 600 private_key.pem
          scp -i private_key.pem -o StrictHostKeyChecking=no build/libs/cicd-study-${{ needs.build.outputs.release }}.jar ${{ secrets.EC2_USER_NAME }}@${{ secrets.EC2_HOST }}:/home/${{ secrets.EC2_USER_NAME }}/cicd-study-${{ needs.build.outputs.release }}.jar
          ssh -i private_key.pem -o StrictHostKeyChecking=no ${{ secrets.EC2_USER_NAME }}@${{ secrets.EC2_HOST }} "pgrep java" | xargs kill -9; nohup java -jar /home/${{ secrets.EC2_USER_NAME }}/cicd-study-${{ needs.build.outputs.release }}.jar > app.log 2>&1 &"
          rm -f private_key.pem 

첫 번째 상황 - 문제해결

분명, ec2로 서버가 띄워져야할텐데 서버가 띄워지지 않았다.
버그다!

문제를 해결하기 위해 원인을 찾아봤다.

        run: |
          echo "${{ secrets.EC2_PRIVATE_KEY }}" > private_key.pem
          chmod 600 private_key.pem
          echo "scp start"
          scp -i private_key.pem -o StrictHostKeyChecking=no build/libs/cicd-study-${{ needs.build.outputs.release }}.jar ${{ secrets.EC2_USER_NAME }}@${{ secrets.EC2_HOST }}:/home/${{ secrets.EC2_USER_NAME }}/cicd-study-${{ needs.build.outputs.release }}.jar
          echo "ssh start"
          ssh -i private_key.pem -o StrictHostKeyChecking=no ${{ secrets.EC2_USER_NAME }}@${{ secrets.EC2_HOST }} "pgrep java" | xargs kill -9; nohup java -jar /home/${{ secrets.EC2_USER_NAME }}/cicd-study-${{ needs.build.outputs.release }}.jar > app.log 2>&1 &"
          rm -f private_key.pem 
         

echo를 추가해서 어느 부분부터 문제인지 알아봤다.
scp start 만 출력하네..?

scp가 문제겠구니 하고 ec2에 접속해봤다.
내가 예상한 jar파일은 정상적으로 옮겨져있었다.
어라..? 근데 ssh start가 출력이 안됐는데,,,

분명, jar파일이 옮겨져 있다는 것은 scp가 문제는 없다는 것이다.
그럼, 중간에 끊겼나??

ls -l *.jar 명령으로 확인해보니 적은 용량이 전송되었던 것이다.
아.. 뭐지..? 진짜 중간에 끊겼나 보다..

그래서 scp -vvv 를 통해 확인해보기로 했다!
근데 무슨 로그 내용이 너무 어려워서 그냥 계속 출력되는 것만 확인했다.
아.. 무한 루프구나! 연결이 중간에 끊기나 보구나..

until - do - while로 중간에 echo 명령을 찍도록 했는데, 진짜 계속 실패하는 것이다. 뭐지..?
ssh known 문제인가..?

		until scp -i private_key.pem -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null build/libs/cicd-study-${{ needs.build.outputs.release }}.jar ${{ secrets.EC2_USER_NAME }}@${{ secrets.EC2_HOST }}:/home/${{ secrets.EC2_USER_NAME }}/cicd-study-${{ needs.build.outputs.release }}.jar
        do
        echo "SCP transfer failed, retrying..."
        sleep 5
        done

UserKnownHostsFile=/dev/null 으로 Known 파일도 무시하도록 해봤다.
실패했다.

도대체 왜 안되는거야..?
혹시나 싶어서 ls -l *.jar를 계속 찍어봤다

와...;;; 그냥 ubuntu to ubuntu scp 속도가 더럽게 느린거였다...
아........... 내 시간

그냥 꾹 참고 배포해보니 scp로 전송이 다되는데까지 7분 50초가 소모됐다.

이대로면 매번 배포할 때마다 너무 많은 시간이 걸린다...

echo "rsync transfer start"
rsync -avz -e "ssh -i private_key.pem -o StrictHostKeyChecking=no" build/libs/cicd-study-${{ needs.build.outputs.release }}.jar ${{ secrets.EC2_USER_NAME }}@${{ secrets.EC2_HOST }}:/home/${{ secrets.EC2_USER_NAME }}/
echo "rsync transfer completed"

scp 대신, rsync를 사용했다.
이 녀석에 대해 공부하진 않았지만 일단 해보자!는 생각으로 해봤다.
와.. scp로 7분50초 걸리던게 10초..?

두번째 상황 - 문제 해결

이제 jar 파일 전송 문제는 해결했는데, 또 다른 문제가 발생했다.
남은건 ssh 문제다.

ssh 각 구문을 다 따로 나누어 echo를 찍어봤다.

		  # 1. SSH 연결 테스트
          ssh -i private_key.pem -o StrictHostKeyChecking=no ${{ secrets.EC2_USER_NAME }}@${{ secrets.EC2_HOST }} "echo 'Connection test successful'"
          echo "successed ssh connection"
          
           # 2. Java 프로세스 종료
          ssh -i private_key.pem -o StrictHostKeyChecking=no ${{ secrets.EC2_USER_NAME }}@${{ secrets.EC2_HOST }} << 'ENDSSH'
          if pgrep -f 'java -jar'; then
          pkill -f 'java -jar'
          echo "Java process killed"
          else
          echo "No Java process found"
          fi
          ENDSSH
          echo "successed kill java"
          
          # 3. 새 Java 프로세스 시작
          ssh -i private_key.pem -o StrictHostKeyChecking=no ${{ secrets.EC2_USER_NAME }}@${{ secrets.EC2_HOST }} "nohup java -jar /home/${{ secrets.EC2_USER_NAME }}/cicd-study-${{ needs.build.outputs.release }}.jar > app.log 2>&1 &"
          echo "deply success"

java 프로그램 kil 하는 부분이 문제였다.
단순 kill 명령이 아니라 java가 실행 중 일때만 종료되도록 했다.