[리눅스] 깃랩 디스크 폭증(+컨테이너 로그)

도커이미지를 사용해 깃랩 서버를 만들었는데 사용자가 거의 없는 수준임에도 불구하고 디스크 사용량이 빠르게 찼다.

(거의 하루에 1GB가 넘게?)

 

처음에는 논리적 볼륨 디스크 확장을 시도했음에도 불구하고 빠르게 꽉 찼다.

*LVM 기반 디스크 확장

 https://gotopm.tistory.com/169

[리눅스] 서버 디스크 확장하기(+LVM)

 

 

워낙 처음에 서버 요량을 30GB로 작게 잡았으니 LVM기반 확장을 해도 부족하니 아예 근본적인 디스크 확장을 해야겠다 싶었다.

그런데 디스크를 확장을 한다한들 하루에 1GB넘게 디스크 사용량이 계속해서 늘어나는데 이게 근본적인 해결책이 맞나 싶었다.

 

깃랩만 돌아가는 서버에 도대체 사용량도 거의 없는데 왜 이렇게 빨리 디스크 사용량이 늘어나는 걸까?

아무래도 로그라고 생각했다.

나는 docker-compose파일을 작성할때  아래와 같이 volume 설정을 했다.

    volumes:
      - /srv/gitlab/config:/etc/gitlab
      - /srv/gitlab/logs:/var/log/gitlab
      - /srv/gitlab/data:/var/opt/gitlab

 

즉 log파일을 /srv/gitlab/logs에 쌓이게 해놓았다.

그런데 아래 명령어로 logs폴더의 용량을 보니 600M 밖에 되지 않았다.

아니 그렇다면 하루에 1GB씩 늘어나는 것의 정체는 무엇이지.. 싶었다.

sudo du -sh /srv/gitlab/logs/

 

※du = Disk Usage
:디렉토리 또는 파일이 실제로 디스크를 얼마나 사용하고 있는지 계산하는 명령어

---

1.원인 찾기

sudo du -xhd1 / | sort -h

 

=>루트(/) 아래에 있는 각 디렉토리가 실제 디스크르 얼마나 사용하는지 계산해서 크기순으로 정렬해서 보여달라는 명령어다

 

-x 옵션은 다른 파일 시스템은 넘어가지 말라는 명령어로 지금 이 디스크만 분석하겠다는 선언

-h(human readable)옵션은 사람이 보기 좋게 K,M,G 단위로 출력

-d1(depth1) 옵션은 현재 디엑터리 바로 아래 단계까지만 보도록 하는 명령어

 / 는 분석 시작 위치로 루트부터 보겠다는 뜻

| sort -h는 결과를 정렬시키겠다는 뜻이다.

 

그러면 아래와 같은 예시처럼 나온다.

 

 

/var 디렉토리가 용량이 크게 나오니 거길 더 분석해야겠다 싶었다. 그래서 분석 위치를 /var로 잡고 다시 파고 들어갔다.

sudo du -xhd1 /var | sort -h

 

 

2.문제는 컨테이너 로그

그렇게 계속해서 파고 들어가니
/var/lib/docker =>  /var/lib/docker/containers 의 용량이 엄청 크다는 것을 발견했다.

이 폴더는 뭐하는 폴더일까?

 

Docker는 컨테이너를 실행시키면 해당 컨테이너에서 나오는 콘솔로그, 즉 stdout/ stderr를 자동으로 수집해서 

Docker는 컨테이너의 stdout/stderr를 자동으로 수집해서
이 containers폴더 안에 컨테이너id를 폴더명으로 하나 더 만들고 해당 폴더안에 log파일을 만들어 기록한다.

 

ex./var/lib/docker/containers/<컨테이너ID>/<컨테이너ID>-json.log

 

이 파일은 컨테이너 로그를 기록한 파일이다.

컨테이너 로그란? 컨테이너 안에서 실행되는 프로그램이 stddout(표준 출력), stderr(에러 출력)로 출력한 모든 내용을 
docker 엔진이 대신 파일로 저장한 기록이다.

즉, 위에서 설정했던 /srv/gitlab/logs에 쌓이는 로그 파일은 깃랩이 만드는 로그 즉 어플리케이션 로그인 것이고,

나는 깃랩을 도커로 실행하니 도커가 만드는 로그(= 컨테이너 로그)가 쌓이는 것이다. 

 

3.컨테이너 로그가 빠르게 증가한 이유

GitLab 컨테이너는 단일 프로그램이 아니다.
내가 실행한 Omnibus GitLab 도커 이미지 안에는 아래처럼 많은 프로그램들이 동시에 실행된다.

 

즉 이 모든 프로세스가 stdout,stderr를 공유한다.

그러므로 이 모든 프로세스의 콘솔에 나오는 출력을 로그로 쌓는 컨테이너 로그는 기하급수적으로 늘어난 것이다.

또한 깃랩은 아래와 같은 내부 통신이 계속해서 일어나기때문에 깃랩을 실제로 잘 사용하진 않더라도 켜놓기만 하면 로그가 엄청나게 쌓인다.

• Sidekiq 백그라운드 작업
• Prometheus / exporter 메트릭 수집
• 상태 점검(health check)
• 내부 스케줄러 작업

거기에다 Docker 의 기본적인 로그 설정은 크기에 제한이 없다. 즉 컨테이너가 살아있는 한, 로그가 무한히 쌓인다.

 

4.컨테이너 로그 정리

일단 먼저 디스크에 꽉 찬 사용량의 가장 큰 원인이 이 컨테이너 로그이니 컨테이너 로그를 초기화 할 필요가 있다.

sudo truncate -s 0 /var/lib/docker/containers/컨테이너ID/컨테이너ID.log

 

도커 컨테이너가 계속해서 실행중이기 때문에 나는 rm으로 삭제하기보다는 truncate 명령어를 실행했다.

truncate는 파일은 그대로 유지한채 내용을 0바이트로 줄이는 명령어다.

이를 통해 충분한 디스크 사용량을 확보할 수 있었다.

 

5.컨테이너 로그 로테이트 설정

하지만 그렇다고 매번 컨테이너 로그가 커질 때마다 수동으로 truncate를 하는 것은 비효율적이다.

그래서 컨테이너 로그로 로테이트 할 수 있도록 docker 로그 정책을 설정해야한다.

 

그 전에 Docker 로그 처리 구조를 살펴보자.

컨테이너 내부 프로그램
   ↓
stdout / stderr
   ↓
Docker Engine
   ↓
[ 로그 드라이버 ]
   ↓
 로그 저장(or 전달)

 

여기서 로그 드라이버란, 컨테이너에서 나온 stdout/stderr 로그를 어디에 어떤 방식으로 저장하거나 전달할지 결정하는  Docker의 출력 기기다. 아무 설정도 하지 않으면 기본적으로 로그 드라이버는 json-file이다.

그래서 컨테이너 로그가 .json 형식으로 저장되었던 것이다.

 

이 설정을 우리는 기본값이 아니라 따로 만들 필요가 있다.

/etc/docker 경로로 이동해서

daemon.json이라는 파일명을 만들어 아래 내용을 입력하여 저장시킨다.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3"
  }
}

로그 드라이버로 기본값인 json-file 그대로 한 다음 log-opts로 로그 드라이버의 동작 규칙을 설정하는 부분이다.

하나의 컨테이너 로그파일이 50MB를 넘으면 로테이션을 수행하란 말이고 최대 3개까지 로그 파일을 유지 하라는 설정이다.

 

6. 도커 재실행

daemon.json은 Docker 데몬의 첫 실행될 때 시점에 읽는 설정 파일이다.

그러므로 도커 자체를 재시작해야한다.

sudo systemctl restart docker
docker restart <container>