DigitalOcean에서 자체 호스팅된 Discourse 사이트를 운영 중이며 디스크 용량이 25GB입니다. 방금 Discourse 이미지를 업데이트하려고 했는데 "계속하려면 더 많은 공간이 필요합니다"라는 메시지가 떴습니다. Docker 이미지와 컨테이너를 정리해도 여전히 0.4GB가 부족합니다.
공간을 절약하는 방법에 대한 조언이 있을까요? 지금 업데이트를 진행하기 위한 방법과 향후 공간을 절약하는 방법 모두에 대해 알고 싶습니다. 곧 디스크 용량을 확장해야 한다는 것은 알고 있지만, 적어도 한 번 더 Discourse 이미지 업데이트를 무사히 마칠 수 있도록 도와주시면 감사하겠습니다.
백업을 로컬에 저장하고 있나요?
그렇다면 오래된 백업 몇 개를 삭제하면 도움이 될 수 있습니다. 0.4GB(즉, 400MB)는 관리 가능한 수준입니다.
호스트 시스템의 공간을 정리해 보는 것도 좋습니다.
공간이 충분한지 확인한 후 서버를 재부팅하고 다시 시도해 보세요.
DigitalOcean의 백업 기능을 사용하고 있습니다. 백업 중 하나를 수동으로 삭제할 수 있는 옵션을 찾지 못했습니다.
이를 어떻게 진행해야 하나요? 저는 프로그래밍 경험이 없지만, 방향을 제시해 주시면 무엇을 해야 하는지, 왜 해야 하는지 이해할 수 있는 수준입니다.
재부팅을 시도해 보았지만 변화가 없습니다.
사용하지 않는 Docker 객체를 정리해 보세요
지금 시점에서라면, 나중에 그걸로 인한 번거로움을 피하기 위해 지금 바로 리사이즈 작업을 하는 게 나을 것 같습니다.
docker volume ls 명령으로 볼륨이 하나뿐인 것을 확인했기 때문에, 사용하지 않는 볼륨을 제외하고 나머지를 모두 정리했습니다.
시도해 보셨나요?
./launcher cleanup
간단한 검색을 통해 이 매우 흥미로운 코멘트를 발견했습니다.
중간에 생성된 태그가 없는 이미지가
<none> <none>으로 표시되는 이유를 이해하는 것이 중요합니다. 이는 사용 중인 경우 삭제할 수 없기 때문에(이미 확인하셨듯이) 이러한 상황을 피하기 위함입니다.태그가 없는 이미지가 생성되는 이유는 이미지를 빌드한 후
Dockerfile을 변경하고 다시 빌드했을 때 이전 빌드의 일부 레이어를 재사용하기 때문입니다. 이제 새 버전의 이미지가 일부 레이어를 사용하고 있으므로 삭제할 수 없는 태그가 없는 이미지가 하나 더 생긴 것입니다.해결 방법은 다음과 같습니다:
- 이미지의 새 버전을 삭제하고
- 태그가 없는 이미지를 삭제한 후
- 새 버전의 이미지를 다시 빌드하여 모든 레이어를 소유하도록 합니다.
그러면 이전 태그가 없는 이미지와 새 이미지의 모든 레이어를 포함하는 단일 태그가 지정된 이미지만 남게 됩니다.
~jr
도커 이미지에서 2.64 GB라는 용량이 나올 거라고는 예상하지 못해서, 지금 그 안에서 무슨 일이 일어나고 있는지 파악해 보고 있습니다. 만약 이 이미지가 전혀 필요하지 않다면, 리사이즈가 필요한 단계까지는 아직 꽤 먼 셈이죠.
다음 명령을 실행해 보셨나요?
./launcher cleanup
다만, 리사이즈를 권합니다. 25GB로 이렇게 오래 버텨오신 게 오히려 놀랍습니다.
또한 shared/backups/default 폴더도 확인해 보셨나요?
DigitalOcean의 백업 기능을 포럼 백업 수단으로 신뢰하지 않는 것이 훨씬 나을 것입니다.
얼마나 오래라고요? 그런 흔적은 전혀 보이지 않는데요 - 저는 20GB에서 포럼 하나를, 25GB에서 다른 포럼 하나를 문제없이 운영하고 있다는 것은 알고 있습니다.
shared 디렉터리에는 많은 백업 데이터(예: shared/standalone/backups/default)가 있을 수 있습니다. 또한 오래된 데이터베이스 복사본이나 오래된 로그 파일이 있을 수도 있습니다. 다음을 실행해 보시는 것을 추천합니다.
du -kx / | sort -n | tail -49
또는 이와 유사한 명령을 실행하세요.
더 큰 인스턴스로 전환하면 돈을 더 쓰더라도 시간을 절약할 수 있다는 점을 참고할 만합니다. 반대로, 시간을 더 쓰더라도 비용을 절약하는 선택도 가능합니다.
이 부분이 조금 걱정됩니다. DO가 전체 시스템 백업에 도움을 줄 수 있겠지만, 저라면 Discourse 백업 방법을 알고, 안전한 로컬 사본을 확보하는 방법을 아는 편이 더 마음이 놓일 것 같습니다. 그리고 백업을 정리하는 방법도 알아야겠죠. (만약 불행히도 DO에서 인스턴스와 계정이 삭제되는 상황이 발생하면, 데이터가 살아남아 있기를 원할 것입니다.)
우리도 Discourse 백업 기능을 사용하는데, 거기에 있는 오래된 백업들을 정리하지 않았다는 사실을 깨달았습니다.
Discourse 인터페이스를 통해 최신 백업을 제외한 모든 백업을 삭제하고, 최신 백업을 내 로컬 드라이브로 다운로드했습니다. 이제 충분한 공간을 확보하기까지 100MB도 채 남지 않았습니다.
var/discourse에서 해당 명령을 실행하면 다음과 같은 결과가 나옵니다.
656876 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff/var/www/discourse/vendor
819624 /var/log/journal/e734ad1931dbee4740881cc15c9e7a9a
826292 /var/discourse/shared/standalone
826296 /var/discourse/shared
831476 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home/discourse/.cache/yarn/v6
831484 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home/discourse/.cache/yarn
831492 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home/discourse/.cache
832188 /var/discourse
845992 /lib/modules
850136 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home/discourse
850144 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home
898764 /var/lib/docker/overlay2/58e9df9d9e2e10efb3dcf68771edd172664f8d91e3aa2e0b280fd4549bfd2a91/diff/usr/lib
966656 /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765/diff/var/www/discourse
966660 /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765/diff/var/www
966664 /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765/diff/var
991800 /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765/diff
991816 /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765
994980 /var/lib/docker/overlay2/2749f8a24b3e28af399b256ecab7f2db0cb146939a0ef56e83858a0e696c3df6/diff/usr/lib
1089092 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49/diff/var/www/discourse
1089096 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49/diff/var/www
1130168 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49/diff/var
1177644 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49/diff
1177660 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49
1224436 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff/var/www/discourse
1224440 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff/var/www
1224444 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff/var
1234612 /lib
1248080 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff
1248096 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d
1342320 /var/lib/docker/overlay2/58e9df9d9e2e10efb3dcf68771edd172664f8d91e3aa2e0b280fd4549bfd2a91/diff/usr
1516440 /usr
1543656 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/var/www/discourse
1543664 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/var/www
1558580 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/var
1659548 /var/lib/docker/overlay2/58e9df9d9e2e10efb3dcf68771edd172664f8d91e3aa2e0b280fd4549bfd2a91/diff
1659564 /var/lib/docker/overlay2/58e9df9d9e2e10efb3dcf68771edd172664f8d91e3aa2e0b280fd4549bfd2a91
2040472 /var/lib/docker/overlay2/2749f8a24b3e28af399b256ecab7f2db0cb146939a0ef56e83858a0e696c3df6/diff/usr
2171304 /var/log/journal/d893af269dfb5f73239a5b6761d49ea0
2388612 /var/lib/docker/overlay2/2749f8a24b3e28af399b256ecab7f2db0cb146939a0ef56e83858a0e696c3df6/diff
2388628 /var/lib/docker/overlay2/2749f8a24b3e28af399b256ecab7f2db0cb146939a0ef56e83858a0e696c3df6
2461904 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff
2461924 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058
3064672 /var/log/journal
3276268 /var/log
10107180 /var/lib/docker/overlay2
10131984 /var/lib/docker
10396840 /var/lib
14869684 /var
20007992 /
다음에 대한 처리 방법에 관한 추가 지침을 받았습니다:
상세 내용은 다음과 같습니다:
1
이미지를 삭제하는 명령어는 다음과 같습니다:
docker rmi {image_name}여기서
{image_name}은 삭제하려는 이미지의 이름입니다. 이미지 ID를 사용하여 이미지를 삭제할 수도 있습니다(예:docker rmi {image_id}).<none>이라는 이름을 가진 이미지를 삭제하려면 이 방법을 사용해야 합니다.예를 들어, 다음과 같은 이미지가 있다고 가정해 보겠습니다:
REPOSITORY TAG IMAGE ID CREATED SIZE my-new-image latest c18f86ab8daa 12 seconds ago 393MB <none> <none> b1ee72ab84ae About a minute ago 393MB my-image latest f5a5f24881c3 2 minutes ago 393MB
my-new-image가<none>이미지의 일부 레이어를 사용하고 있기 때문에<none>이미지를 삭제할 수 없는 경우가 있을 수 있습니다. 해야 할 일은 다음과 같습니다:docker rmi my-new-image:latest docker rmi b1ee72ab84ae docker built -t my-new-image .이 명령은
<none>이미지의 레이어를 재사용하고 있는my-new-image:latest를 제거합니다. 그런 다음 이미지 IDb1ee72ab84ae를 사용하여<none>이미지를 삭제합니다. 마지막으로 필요한 모든 레이어를 생성하여my-new-image를 다시 빌드합니다.또한
<none>“태그가 없는” 이미지를 여전히 사용하고 있는 중지된 컨테이너가 없는지 확인하십시오. 종료된 것을 포함하여 모든 이미지를 보려면docker ps -a를 사용하십시오. 해당 컨테이너가 있으면docker rm {container_id}를 사용하여 컨테이너를 제거한 다음<none>이미지 삭제를 다시 시도하십시오.
여러분의 생각은 어떠신가요?
여기서 개선할 수 있는 부분이 있다고 생각합니다:
이전 대화를 참고해 보세요:
그리고
이렇게 하니 문제가 해결되었고, 정책도 함께 변경했습니다!
<none> 이미지 관련 문제를 계속 추적해 보고 싶습니다(2GB 이상의 공간을 차지하는 것은 말이 안 되니까요). 하지만 업그레이드를 위해 충분한 공간을 확보해야 한다는 가장 시급한 문제는 여러분 덕분에 해결되었습니다! 감사합니다!!
전적으로 동의합니다! 지금은 새로운 것을 배우는 데서 많은 재미를 느끼고 있어서, 그 시간을 투자하는 것이 가치가 있다고 생각합니다.