이전 글 : 24-12-23
개요
이전에 실행했던 프로젝트를 같은 환경에서 그대로 실행할 수 있어야, 프로젝트를 발전시킬 수 있다. 오늘은 이전 프로젝트를 그대로 실행할 수 있도록 해보자.
이전 프로젝트 : Step To Dance
여러가지 요소를 고민했다.
- python 서버인 fastApi 서버를 또한 쓰고있어 다양한 언어에 대한 강점이 드러난다.
- “숏폼” 같은 중요도가 떨어지는 도메인을 제거하거나 축소시켜, 간단한 msa가 가능하다.
- 동작 유사도를 계산하는 방식 등에서 무궁무진한 발전이 가능하다.
다만 위험성으로는
- 춤 영상 업로드 같은 기능을 고려할 때 s3등을 사용해야 할 가능성이 높다.
- ai 기능 사용에 따라 서버 비용이 많이 드는지 모니터링을 자주해줘야한다.
정도가 있다. 발전 가능성을 보고 선택한 만큼 신중하게 개발해보고, 무료로 하는 데 한계가 있다면 빠르게 다른 프로젝트로 바꿔야 될 수도 있다.
Issue
1. 프로젝트 완전 복구
프로젝트가 완전히 복구되도록 이전에 작성한 포팅메뉴얼을 보고 따라하는 중이지만, 쉽지않다.
jenkins 스크립트는 간단하다는 이유로 아예 기록도 안해놨다…
새로 작성했는데 별거 없어 쉽긴했다.
그 과정에서의 자잘한 문제들을 아래에 정리했다.
2. jenkins 내 docker compose가 없는 문제
jenkins 내부에 docker, docker compose 설치해주고 DooD가 가능하도록 docker.sock 파일을 volume으로 마운트해줬다. 이론상 해결되어야 하지만 아래 문제가 터지게 된다…
3. kt 클라우드 용량 문제
jenkins에서 빌드도 안되고,,, 서버에서 새로운 작업 자체가 시작이 안되는 문제에 직면하게 된다. 별다른 에러 메시지도 jenkins 빌드 중에 뜨지 않아서 곤란한 상황이었다…
3-1. 디스크 추가(실패)
kt 클라우드 메뉴얼을 잘못 읽고 디스크를 추가하면 되는 줄 알고.. 디스크를 추가하고 루트디렉터리 / 에 열심히 마운트를 시도했다… 하지만 이런식으로 증설할 수는 없는 것이었다.
3-2. 서버 종료 후 kt 콘솔에서 기본 용량 증설(성공)
이거 찾느라 1시간을 그냥 날렸다. 익숙하지 않아서 그렇다고 탓을 하고싶지만, 솔직히 내 하드웨어 지식이 부족했다고 생각한다. fdisk 툴을 사용한 경험이 있었다면 훨씬 빠르게 문제의 해결책을 찾았을 것 같다.
서버용량 증설을 하는 과정에서 기존의 스왑영역이 중간에 끼어 있었다.

(1)스왑영역을 해제하고, (2) 파티션 새로 할당, (3) 스왑 영역 재할당의 작업을 해 주었다.
- 스왑영역 해제
# 본인 서버에서 스왑파일의 이름이 swapfile인지, swapon -s를 통해 확인해주세요.
# 따라할 분이 있다면..
sudo swapoff /swapfile
sudo rm -rf /swapfile
sudo vim /etc/fstab # /swapfile swap swap defaults 0 0 과 같은 내용을 지운다.
- 파티션 새로 할당.
sudo fdisk /dev/xvda
d # 기존의 파일시스템과 필요없는 다른 파티션을 지웁니다.
4 # swap 파티션
d
3 # 파일시스템
n # 새로 파일시스템 할당
# 이후 엔터만 누르면 새로 파티션이 할당되었습니다.
w # 저장
# 이후 서버 리부트
- 스왑영역 재할당
free -h
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
sudo echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h
4. docker compose 에러
INSTALL WARNING: User: missing rw permissions on JENKINS_HOME: /var/jenkins_home
Can not write to /var/jenkins_home/copy_reference_file.log. Wrong volume permissions?
touch: cannot touch '/var/jenkins_home/copy_reference_file.log': Permission denied
설상가상으로 위 에러가 떴다… 해결하는데는 한시간이 넘게 걸린 듯 하다.
kt 클라우드는 기본적으로 ubuntu
, root
외에 다른 cloud
라는 유저를 하나 더 가진다. 이때 mount를 하기 위해 볼륨을 생성하며, cloud
소유의 파일을 만들고, 접근할 수 없다며 에러가 떴다.
결론적으로 docker compose 파일 내 user: "0"
을 추가했다. root의 uid 가 0이기 때문이다.
5. jenkins 내부 docker 설치 문제…
to be comtinued…
후기
이런 자잘한 내용을 모두 기록하는게 맞는가… 라는 생각이 들지만, 나중에 이 글을 다시 읽을때 오늘 느낀점을 모두 다시 떠올릴 수 있게 되기를 바라며 최대한 세세히 작성했다.
문제의 원인은 서버 모니터링이 제대로 되지 않아서 그랬다.
그래서 이번 msa 개발을 하며 grafana
와 prometheus
를 사용하여 모니터링하는 방식을 얼른 도입하고싶어졌다.
자잘한 문제가 많았다. 그냥 lightsail 같은 쉬운 서버를 쓰고싶다는 생각이 마구마구 든다. 하지만 이런것도 이겨낼 수 있어야 a-z를 할 줄 안다고 할 수 있지 않겠나 라는 마음가짐으로 계속해나가겠다.