📡 Docker로 on-premise 환경에 배포하기

이 글은 iptables 명령어 사용법과 docker를 활용한 배포에 대해 다루고 있는 trouble shooting 문서입니다. 원하는 부분만 보시고 싶으시다면 아래로 이동하시면 됩니다.

• root 권한 부여
• port 열기
• Docker run --network option 적용

왜 이 작업을 하게 되었는가

현재 연구실에서 프로젝트를 하고 있다. 소규모 프로젝트이기도 하고, 테스팅 환경 구축이 목표이기 때문에 별도의 AWS 비용 지출이 불가하다는 이유로 연구실 workstation을 하나 할당 받아 배포하게 되었다. 클라우드가 아닌 서버에 배포를 진행해보는 것은 처음이라 여러 난항을 겪었다. 귀찮은 일을 하고싶지 않아 CI/CD 파이프라인을 구축했는데, Docker network 구조에 대한 이해도가 부족해 많은 어려움을 겪었다.

서버를 할당받고 해야 하는 작업들

일단 서버를 할당 받았다. 연구실로부터 받은 것은 ip address, port, user name, password였다. 다행히도 ssh로 접속하니 잘 되는 것을 확인할 수 있었다.

# ssh 접속 명령어
ssh {user name}@{ip address} -p {port}

서버 할당 후 배포를 위해 한 작업은 크게 2가지로 나뉘었다. 그리고 연구실은 인수인계가 제대로 이뤄지지 않을 확률이 높기 때문에 해당 과정을 문서로 남겨야 했다.

1. DB 설치 및 테스트
2. CI/CD pipeline 구축

각 task들은 Github에 issue 로 등록해 관리했다. 자세한 기록이 궁금하다면 여기를 참고하면 된다.

배포 과정에서 문제가 생겼다

기본적으로 배포는 docker를 활용했다. CI/CD pipeline을 위한 workflow 작성도 마쳤다.(CI/CD pipeline 구축 방법은 여기를 참고하면 된다.) 사실 workflow 적용 자체는 어렵지 않은 문제였다. 가장 큰 문제는 port를 열어야 한다는 것이었다. 사실 그 뒤에도 자잘하게 많은 문제가 발생했다.

포트를 열어야 한다

연구실 서버를 활용해 배포하기 때문에 서버에서 활용할 포트를 열어주는 작업을 거쳐야 했다. 문제는 어떤 서버가 열리고 어떤 서버가 죽어도 안 열리는 서버인건지 모른다는거다. 이런 일이 발생하는 이유는 학교 서버 보안 때문에 라우터나 스위치 레벨에서 방화벽이 동작하기 때문인데 그렇지 않은 포트를 찾아 헤메야 했다. 일반적으로는 40000번 이상의 포트를 열면 잘 동작한다. 그래서 열어주려 했더니 root권한이 없어서 안된다는 오류 메세지가 떴다. 따라서 root 권한부터 부여하고 포트를 열어줬다.

DB 설치 그거 docker로 하니까 되잖.. 어라 안되네?

log를 JSON 형태로 저장하기 위해 NoSQL인 MongoDB를 사용했는데, local 환경에서는 docker로 설치하고 잘 사용했던 MongoDB가 이상하게도 배포 환경에서는 container 실행이 되지 않았다. 그래서 apt-get install로 MongoDB를 설치하고 실행시켰는데 Spring 서버에서 DB를 찾지 못하는 문제가 발생했다.

해결 그거 어떻게 하는건데

root 권한 부여

일반 사용자에게 root 권한을 부여하기 위해서는 root 계정이 필요하다. 연구실에 연락해서 미리 root 계정 정보를 받아 로그인 후 진행했다.

# root 계정으로 ssh 접속
ssh root@{ip address} -p {port}

root 권한 부여를 위해서는 /etc/sudoers를 수정하면 된다. 먼저 sudoers 파일의 권한을 설정하고, vi로 수정해줬다.

# sudoers 파일 권한 확인
ls -al /etc/sudoers
# 권한 변경
chmod +w /etc/sudoers
# sudoers 열고 수정
vi /etc/sudoers

# /etc/sudoer file root 아래에 사용자 추가
{user id} ALL=(ALL) ALL

user id가 zero인 경우 zero ALL=(ALL) ALL로 수정하면 된다. 모든 작업을 완료하고 sudoers 파일의 w권한은 원상복구해야 한다.

# sudoer 파일 권한 원상 복구
chmod -w /etc/sudoers

port 열기

루트 계정에서 로그아웃하고 할당 받았던 계정으로 다시 로그인해 iptables 명령어로 포트를 열어줬다. 아래는 iptables 명령어 중 사용 빈도가 높은 것들이다. 이 케이스의 경우, OUTPUT은 모두 열어줘도 문제가 되지 않아 전체 포트를 다 열어줬다.

# iptables 목록 출력
sudo iptables -nL

# iptables 특정 포트 INPUT 접근 허용
sudo iptables -I INPUT 1 -p tcp --dport {port} -j ACCEPT

# iptables 전체 포트 OUPUT 접근 허용
sudo iptables -P OUTPUT ACCEPT

# iptables 특정 포트 접근 허용 다시 차단
sudo iptables -D INPUT -p tcp --dport {port} -j ACCEPT

Docker 실행 시 network option 설정

DB 연결 문제 발생 원인

DB 연결 문제는 나의 무지로부터 비롯된 것이었다. Spring 서버에서 deploy profile을 별도로 설정해주었는데, 이는 아래와 같다. 사실 내용만 놓고 보면 local profile과 동일하지만, 차후 환경이 변경될 것을 대비해 profile로 분리했다.

# application-deploy.yml
spring:
  config:
    activate:
      on-profile: deploy

  data:
    mongodb:
      # 차후 배포 환경이 변경될 시 수정
      uri: mongodb://localhost:27017/lingo-db

위 코드에서 data.mongodb.uri가 localhost로 설정되어 있는 것을 확인할 수 있는데, 원인은 Docker network 구조에 대해 무지했다는 것이다. 더 정확히 말하자면 MongoDB의 uri를 localhost로 설정했기 때문에 Spring 서버 입장에서는 자신의 ip 주소에서 MongoDB를 찾지만 실제로 localhost에는 MongoDB가 없다. 서버 입장에서 localhost는 docker에서 제공하는 가상 네트워크이기 때문이다. 더 자세한 내용은 여기를 참고하면 된다.

Docker run 시 network option 적용

이 문제를 해결하기 위해서는 빌드된 SpringApplication을 Docker로 실행 시 도커가 제공하는 가상 네트워크(veth)를 사용하는 것이 아니라 직접 host 네트워크에 붙여서 사용하면 된다.

# network option 적용
docker run --name {name} --network=host -d {image}

위 코드처럼 --network=host를 적용하면 직접 host에 연결돼 예상한대로 동작하는 것을 확인할 수 있었다. 해당 옵션이 모든 배포 과정에서 적용되어야 하기 때문에 Github worlflow의 main.yml에도 적용해주었다. 그리고 workflow를 재실행해 배포 과정에 적용되는 것을 확인했다. test api를 전송해 DB에 제대로 저장되는 것을 확인하고 코드를 merge해 모든 작업을 마쳤다.

그래서 뭘 느꼈는데

모든 해결책은 구글링에 있다

이 문제를 해결하기 위해 ChatGPT에 내 상황을 모두 설명해 여러 해결책을 받았지만, 모두 제대로 동작하지 않았다. 정확히 말하면 나도 잘 몰라서 GPT에게 잘 설명해주지 못한 것 같다. 많은 도움이 됐던 건 망연자실해서 구글링했던 결과들이었다. 역시 직접 찾아보고 적용해보는 게 제일 빠르다는 걸 느꼈다.

그냥 해서는 안된다, 이해하자

이전까지는 Docker를 활용하는 데에는 큰 이해가 필요하지 않다고 생각했었다. 그런데 Docker network와 같은 로직을 가지고 있다는 것을 알게 되어 더 공부가 필요하다는 것을 절실하게 느꼈다. 특히 쿠버네티스나 카프카 같은 기술을 활용하기 위해서는 더 공부해야겠다고 생각했다.. 컴퓨터망 수업에서 네트워크에 대해서 좀 공부했다고 생각했는데, 정말 먼지만큼 아는구나 싶었다.

그래도 해냈다

오늘 안에 해결하는 것이 목표였는데, 해내고 trouble shooting 문서까지 다 작성한걸 보니 나쁘지 않은 등가교환인 것 같다. 특히 문제 상황에 대해 대처하면서 많이 발전하는 것 같다. 다음에 비슷한 문제가 발생했을 때는 더 빠르게 해결할 수 있기를 바란다.