일반적인 질문들:
누군가 이 명령의 기능 apt-get update과 실제로 사용해야 하는 경우를 설명해 줄 수 있습니까?
논평
하나 주세요자세한 답변. 버전이 매우 상세하지 않은 한 맨페이지의 복사본만은 아닙니다(아래 맨페이지에 정의를 추가했습니다).
적절한 업데이트 받기: 소스에서 패키지 인덱스 파일을 다시 동기화하는 데 사용됩니다. 사용 가능한 패키지의 색인은 /etc/apt/sources.list(5)에 지정된 위치에서 가져옵니다. 업그레이드 또는 dist-upgrade 전에 항상 업데이트를 수행해야 합니다.
하위 질문:
- 패키지 색인은 어디에 저장되나요? 데이터베이스에? 파일에?
- 캐시를 업데이트하지 않으면
apt-get install어떻게 되나요 ? 원격 패키지가 더 이상 존재하지 않고 링크가 끊어질 가능성이 있습니까? - deb 저장소와 관련하여 합의된 정책이 있습니까? 예를 들어, 리포지토리에는 패키지의 마지막 버전만 포함해야 합니까, 아니면 반대로 특정 배포에 사용 가능한 모든 버전을 포함해야 합니까?
문맥
연구중이라 이런 질문을 드려요도커 프레임워크. 그 특징 중 하나는도커파일, 파일의 특정 명령을 실행하여 특정 운영 체제 이미지를 구축할 수 있습니다. 이 이미지의 한 가지 속성은 컨텍스트(빌드 시간 등)에 관계없이 항상 동일해야 한다는 것입니다.
apt-get update다른 시간에 명령을 실행하면 결과가 달라지고 이미지도 달라질까 봐 걱정됩니다 .
답변1
apt-get update사용 가능한 패키지 목록을 다운로드하세요.
패키지 목록은 시간이 지남에 따라 변경될 수 있습니다. 새 패키지가 추가되고 이전 패키지가 제거됩니다. 따라서 매우 오래된 캐시가 있고 를 실행하려고 하면 apt-get install더 이상 존재하지 않는 패키지를 다운로드하려고 시도할 수 있습니다.
오래된 패키지가 저장소에 남아 있는 기간은 저장소 관리자(배포판)에 따라 다릅니다. 따라서 캐시가 매우 오래된 docker와 같은 것을 사용하는 경우 apt-get update패키지를 설치하기 전에 항상 실행해야 합니다.
패키지를 제거하고 추가하는 이유는 주로 버그 수정과 보안 업데이트 때문입니다. 그러나 PPA와 같은 타사 저장소를 사용하면 모든 일이 발생합니다.
기업 환경에서 Docker와 같은 컨테이너화 도구를 사용하는 경우 매번 컨테이너를 다시 빌드하는 대신 컨테이너를 한 번 빌드한 후 해당 컨테이너를 다양한 릴리스 환경(개발, 스테이징, 프로덕션)으로 이동해야 합니다. 이렇게 하면 테스트되지 않은 다른 컨테이너를 얻지 못하게 됩니다.
캐시 파일의 위치에 대한 질문에 답하려면 /var/lib/apt/lists.
답변2
apt-get update 명령의 기능과 실제로 사용해야 하는 경우를 누군가 설명해 줄 수 있습니까?
apt-get update배포판의 패키지 저장소에서 업데이트된 색인을 다운로드하여 사용 가능한 모든 패키지와 정확한 버전을 나열합니다.
Ubuntu 및 Debian과 같은 일반적인 배포판은 일반적으로 패키지 제공에서 보수적이고 이전 버전과 호환되므로 보안 업데이트나 버그 수정으로 인해 시간이 지나도 버전이 많이 변경되지 않습니다. 예를 들어, mysql은 5.7.18에서 로 업그레이드할 수 있지만 5.7.19에서는 업그레이드할 수 없습니다 6.x.
패키지 색인은 어디에 저장되나요? 데이터베이스에? 파일에?
일반적으로 하나 이상의 파일에 저장됩니다 /var/lib/apt. Docker의 맥락에서 이러한 파일은 이미지 내부에 있습니다. Dockerfile이 빌드되면 새로 빌드된 이미지로 생성되고 유지되는 새 파일 시스템 레이어에 저장됩니다.
캐시를 업데이트하지 않고 apt-get install을 수행하면 어떻게 됩니까?
더 이상 존재하지 않는 패키지 버전을 다운로드해 볼 수 있습니다. 이는 가상 머신에서 흔히 발생하지만 배포 저장소가 기본 이미지를 빌드한 후 새 패키지를 게시하는 경우 컨테이너 내부에서도 발생할 수 있습니다. 배포판의 다운스트림에 있고 그 수가 더 많을 수 있는 배포판 관리자와 Dockerfile 관리자 사이에는 조정이 없을 수 있습니다. Debian 저장소는 하나뿐이지만 jessie이를 기반으로 하는 수천 개의 컨테이너 이미지와 Dockerfile이 있습니다 .
또한 우분투 미러와 같은 일부 업스트림 미러는다운로드한 색인 삭제이미지를 더 작게 만들고 오래된 파일을 피하세요. 따라서 기본 이미지 버전별로 최신 인덱스를 제공하기보다는 기본 이미지 위에 빌드할 때 업데이트된 인덱스를 다운로드 받아야 할 것으로 예상된다.
원격 패키지가 더 이상 존재하지 않고 링크가 끊어질 가능성이 있습니까?
물론, 색인에 저장된 버전은 매우 정확하기 때문에 5.7.19(단순화, 더 유사함 5.7.19-0ubuntu1).
deb 저장소와 관련하여 합의된 정책이 있습니까? 예를 들어, 리포지토리에는 패키지의 마지막 버전만 포함해야 합니까, 아니면 반대로 특정 배포에 사용 가능한 모든 버전을 포함해야 합니까?
업데이트가 출시되면 이전 마이너 버전이 빠르게 제거되는 것이 매우 일반적입니다. 바이너리의 무게는 수십 메가바이트에 지원되는 모든 버전과 아키텍처를 곱할 수 있기 때문에 이것이 서버 공간을 절약하기 위한 것이라고 가정합니다. 따라서 일반적 mysql-5.7.18으로 후속 ;에서 수정하는 것은 불가능합니다 apt-get install. mysql-5.7.19릴리스에 게시 되면 이전 버전은 제거됩니다.
공평하게 말하면 Docker의 이러한 불확실성은 apt-get update모든 배포판의 패키지 관리와 함께 제공되는 문제입니다. EC2 또는 Vagrant 가상 머신을 반복적으로 구축하려고 하면 동일한 문제가 발생합니다.
일부 시스템 관리자는 다음과 같은 프로그램을 사용합니다.적절하게원본 리포지토리를 미러링하고 특정 버전을 고정할 수 있지만 업데이트를 테스트하고 고정한 항목을 변경하기 위해 자주 실행되는 별도의 프로세스가 없으면 보안 업데이트가 누락될 위험이 있습니다.