이 mysql 이미지를 사용하는 컨테이너가 있나요? 아니면 docker tag이 이미지를 다시 만들었나요? 아니면 다른 버전의 mysql 미러를 사용하시나요? 아니면 debian:jessie 기반 이미지를 사용하고 있나요?

이미지는 단일 파일이 아니라 저장 레이어 모음이라는 점에 유의하세요. docker rmi -f mysql을 실행하면 실제로는 mysql:latest이 tag가 삭제되므로 첫 번째 줄은 대개 Untagged: mysql:latest입니다.

다음 논리는 스토리지 레이어를 가리키는 다른 tag이 없으면 스토리지 레이어가 실제로 삭제되고 스토리지 레이어의 다음 레이어가 아직 사용 중인지 계속 쿼리하여 삭제되지 않는다는 것입니다. 특정 시간까지 계속 삭제합니다. 스토리지 레이어에 의존하는 컨테이너나 이미지가 레이어에서 발견되면 삭제가 중지됩니다. 그래서 docker rmi을 실행하면 얼마나 많은 Deleted: sha256: ...이 나타나는지 확인할 수 있는데, 이는 삭제된 레이어 수와 삭제되지 않은 레이어 수입니다.

그래서 docker tag 이 mysql 이미지를 다시 설치하면 docker rmi을 실행할 때 untag 작업만 실행되고 스토리지 레이어는 실제로 삭제되지 않습니다.

또는 동일한 기본 이미지debian:jessie를 기반으로 하는 다른 이미지가 시스템에 있는 경우 docker rmi는 이 레이어에서만 삭제되고 앞으로는 pull도 시작됩니다. 이 레이어에서.

마찬가지로 이러한 계층형 스토리지 개념은 docker pull에도 영향을 미칩니다. docker pull을 실행하면 공식 docker:latest의 각 레이어의 체크 값을 확인한 후 로컬에서 이미 존재하는 것이 무엇인지 비교하여 풀이 반복되지 않고 현재 저장 레이어가 됩니다. 직접 사용됩니다. 존재하지 않는 경우 새 항목을 가져옵니다.

이전의 docker tag 이미지를 다시 tag다시mysql:latest한다면 지금 예를 들어보세요. 그러면 docker rmi는 실제로 이미지를 삭제하지 않았고, 다시 docker pull mysql하면 모두 찾기 저장소 계층은 로컬에서 사용할 수 있으므로 다시 가져올 필요가 없습니다. 최상위 tag를 mysql:latest로 변경하면 됩니다. sha256sum는 이미지 파일과 공식 홈페이지의 일관성을 보장할 수 있기 때문에 이런 상황에 대해 걱정할 필요도 없고, 강제로 다시 다운로드할 필요도 없습니다.

그러므로 귀하의 질문은 구체적인 상황에 따라 달라져야 합니다. 일반적으로 프로덕션 환경에서는 latest 태그를 사용하지 않는 것이 좋지만, 업그레이드 및 유지 관리가 가능하도록 버전을 명확히 지정하는 것이 좋습니다.

으아악