들어가며
주인 기분 안좋다고 3일동안 이렇게 안 반겨줘도 되는데.....
3일동안 젠킨스와 있었던 일들을 알아보자.
⛔️ 문제상황
기존 라즈베리파이로 유지하던 MySQL서버가 라즈베리파이가 죽어버리며 데이터가 다 날아가는 문제가 생겼다.
라즈베리파이를 살려도 또 언제 이런 상황이 발생할지 모르는 상황
그래서 MySQL을 VM에 Docker로 올려서 사용하기로 결정하였다.
그래서 기존의 yml을 새로운 yml로 변경하고 Jenkins Credentials에 새로운 yml파일을 넣은 뒤 배포를 진행했는데 서버가 죽었다.
왜 자꾸 죽는거야...
yml파일이 Credentials에 적용이 안된줄 알고
sh 'cat seugi/src/main/resources/application.yml'로 콘솔로그를 출력했는데
바뀐 yml파일로 잘 나오는 것이다
미치고 환장할 노릇이다
왜 Credentials을 세팅한 파일에선 잘 나오는데 왜 yml이 안바뀌는걸까...........................
나는 우리의 친구 챗지피티에게 물어봤다.
com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
at 이런 오류가 서버측 콘솔에 출력되는데
분명 나는 yml을 제대로 세팅했거든? 근데 왜 그런거야
우리 지피티는 친절하게 헛소리를 해줬다.
그거 디비문제임 ㅇㅇ
뭐시라? AWS 에서 제공해주는 RDS가 문제라고??????????
친절하게 헛소리하는 지피티를 두고 나는 다른 가능성을 생각했다
디비는 RDS를 쓰고있고 로컬에서 도커 빌드해서 올리면 잘 돌아가면.. 내가봤을땐 yml파일 구성에 문제가 있는 것 같은데 jar파일을 까보면 답이 나오지 않을까?
그래서 jar 파일을 까봤는데
jar파일안에 yml이 잘 있다. 다만 구버전으로..
왜 업데이트가 안된 구버전 yml이 존재한걸까?
젠킨스의 빌드과정은 workspace라는 개념이 있다.
젠킨스가 어떤 아이템의 스크립트를 작동할때 사용되는 환경인데
이 환경의 파일들은 빌드마다 초기화 되지 않는다. (Workspace clean up)
즉 새 yml파일을 올려도 변경되지 않았던 것이다.
그래서 이걸 따로 설정해줘야하는데
빌드 이전 workspace를 날리는 방법이 있고 기존과 똑같이 저장해서 계속 사용하는 방식이 존재하는데 우린 빌드 이전 workspace를 날리는 방법을 알아보자.
수동으로 워크스페이스 날리기
날씨 표시 된 부분을 클릭하고
왼쪽에 Workspaces 를 클릭한다
그럼 이런 파일구조경로링크(?) 가 보일껀데 이걸 클릭하면
사진과 같이 우리가 빌드시 사용되는 파일들이 나온다
여기서 자신이 새로 세팅한 파일인지 확인하고 아니라면
깔끔하게 그냥 워크스페이스 자체를 날려버리자.
(다만 중요한 파일이 없다는 가정하에)
그리고 빌드 스크립트를 실행하면 이전 파일들이 똑같은 상태로 복구 될 것이니
깔끔히 아래 명령어를 콘솔창에 쳐서 마음편히 보내주자
sudo rm -rf /var/lib/jenkins/workspace/seugi-server그냥 명령어로 그 자체를 날린 뒤 다시 빌드를 수행하면 다시 워크스페이스가 생기고 그 아려 파일들이 생길 것이다.
Clean up Plugin
매번 저 작업을 하기 귀찮다면
Cleanup Plugin 를 깔고 아래와 같은 스크립트를 젠킨스 실행시 앞단에 사용하면 된다.
post {
always {
// 빌드 후 워크스페이스 클린업
cleanWs()
}
}그럼 빌드시마다 워크스페이스를 초기화 시켜준다.
z존 짱짱