EC2 인스턴스에서 도커로 된 서비스를 빌드할 때, 갑자기 ssh 연결이 끊기고 이후로 접속이 안되는 경우가 있었다.
일반적으로 10~20분 정도 기다리면 다시 접속이 가능해질 때가 있는데, 만일 2~3시간 후에도 여전히 서버가 응답을 안하고 ssh 접속이 불가하다면, EC2 인스턴스를 직접 재부팅해야 한다.
[EC2 대시보드] > [Instances]
인스턴스를 체크한 후, [Instance state] > [Reboot instance]
몇분 정도 후에는 다시 접속이 가능하다.
물론 그렇다고 도커 빌드 문제가 해결되는 것은 아니다. 다시 빌드하면 아마도 다시 인스턴스가 멈출 것이다.
인스턴스가 뻗은 직후, EC2 대시보드에서 Monitoring 탭을 보면 CPU utilization이 100%에 가깝게 치솟다가 0으로 떨어진다.
CPU 용량이 부족하기 때문에 뻗어버리는 것 같다. 사실 근본적인 원인은 인스턴스가 t2.micro라서 생기는 일이다. RAM이 1GB로 매우 적기 때문에 사실 무거운 서비스를 돌릴 수 없는 인스턴스이긴 하다. 그러나, 프리티어 안에서 해결을 해야 한다면 인스턴스 종류를 바꿀 수는 없다.
t2.micro가 도커를 감당하지 못하는 것은 아니다. 이것 저것 시도해보다가 발견한 몇가지 경험상 발견한 몇가지 팁을 적어두려고 한다.
-
도커 컴포즈를 사용한다면) 빌드를 따로 진행할 것.
로컬에서 돌릴 때는, 아무 생각 없이docker compose up --build를 사용해 build와 Up을 동시에 진행했었다. 그러나 이 경우 도커 컴포즈 파일로 정의된 여러 컨테이너를 빌드하고 띄우는 작업이 동시에 진행되기 때문에 인스턴스가 도중에 뻗을 확률이 더 높다.
따라서, 아래와 같이 build와 Up을 따로 진행 해보자.docker compose build docker compose up -
서비스 별로 빌드 따로하기
사실, docker compose build도 여러가지 서비스를 한번에 빌드하기 때문에, 서비스 별로 빌드를 따로하면 리소스를 더 적게 차지한다.docker compose serviceA docker compoes serviceB ...이런식으로 하나씩 빌드를 하면 한번에 빌드 할 때보다 수월한 것을 느낄 수 있다.
-
용량 자주 비워주기
몇번 시도하다보면 분명히 메모리 에러가 날 것이다. 혹은 disk is full... 하는 에러가 난다. 사용하지 않는 이미지, 볼륨 등이 쌓여서 공간을 차지하는데 이게 생각보다 크게 차지한다.
기본적으로docker system prune은 더이상 사용하지 않는 이미지, 컨테이너, 캐시 등을 삭제한다.
-a태그를 붙이면 현재 실행되지 않는 컨테이너의 이미지까지 모조리 삭제된다.
--volume태그를 붙이면 볼륨까지 함께 삭제되기 때문에, 아래 명령어는 신중하게 입력해야 한다.docker system prune -a --volume어쨌거나 상당히 큰 용량을 비울 수 있다!! 로컬에서 도커를 돌릴 때도 한번씩 해주면 10GB 정도 사라질 때가 있다... 물론 보관할 데이터가 없을 때 헤야 한다.
-
빌드 자체를 외부에서 할 것
위에서 말했지만, 도커로 서비스를 돌리는 것 자체보다는 빌드하는 과정에서 리소스가 많이 든다. 따라서 아예 빌드 자체를 외부에서 진행하는 것도 하나의 해결 방법이다. 도커 이미지를 빌드해서 도커 허브에 올려두고 서버에서 받아서 그대로 사용한다면 서버에서 빌드할 필요가 없으니 훨씬 낫다.
Jenkins, Bamboo, 혹은 github-actions 등을 사용해볼 수 있다.
내가 진행하는 프로젝트의 경우, 엄청나게 무거운 도커 이미지를 사용하고 있는 것도 아니었고... 해보니 대부분 리액트를 빌드하는 과정에서 서버가 뻗는 경우가 많았다. 따라서 github actions를 사용해 리액트를 빌드했고, 나머지는 인스턴스에서 빌드하는 방식을 사용했다.
