언제, 왜 apt-get 업데이트를 사용해야합니까?

일반적인 질문 :

어떤 사람들이 명령 apt-get update이 무엇을 하고 언제 사용 해야하는지 설명 할 수 있습니까?

비고

자세한 답변을 부탁드립니다 . 귀하의 버전이 실제로 상세하지 않다면 매뉴얼 페이지의 사본뿐만 아니라 (아래 맨 페이지에서 하나의 정의를 넣었습니다).

apt-get update : 소스에서 패키지 색인 파일을 재 동기화하는 데 사용됩니다. 사용 가능한 패키지의 색인은 /etc/apt/sources.list(5)에 지정된 위치에서 가져옵니다. 업그레이드 또는 dist-upgrade 전에 항상 업데이트를 수행해야합니다.

하위 질문 :

• 패키지 인덱스는 어디에 저장됩니까? 데이터베이스에서? 파일에?
• apt-get install캐시를 업데이트 하지 않고 수행하면 어떻게됩니까 ? 원격 패키지가 더 이상 존재하지 않고 링크가 끊어 질 가능성이 있습니까?
• deb 저장소에 대해 합의 된 정치가 있습니까? 예를 들어, 저장소에는 패키지의 마지막 버전 만 포함되어야하거나 반대로 특정 배포 릴리스에 사용 가능한 모든 버전이 포함되어야합니까?

문맥

Docker 프레임 워크를 공부하고 있기 때문에 질문 합니다. 그 기능 중 하나는 Dockerfile 이며,이 파일에서 명령을 실행하여 일종의 OS 이미지를 작성할 수 있습니다. 이 이미지의 특성 중 하나는 컨텍스트 (빌드 시간 등)에 관계없이 항상 동일해야한다는 것입니다.

apt-get update다른 시간에 명령을 실행 하면 결과가 달라져 이미지가 달라질 까봐 걱정됩니다 .

apt-get update 사용 가능한 패키지 목록을 다운로드합니다.

패키지 목록은 시간이 지남에 따라 변경 될 수 있습니다. 새 패키지가 추가되고 이전 패키지가 제거됩니다. 따라서 실제로 오래된 캐시가 있고를 시도하면 apt-get install더 이상 존재하지 않는 패키지를 다운로드하려고 할 수 있습니다.
오래된 패키지가 저장소에 보관되는 기간은 리포지토리 관리자 (배포)에 달려 있습니다. 따라서 캐시가 매우 오래된 도커와 같은 것을 사용 apt-get update하는 경우 패키지를 설치하기 전에 항상 실행해야 합니다.

패키지를 제거하고 추가하는 이유는 주로 버그 수정 및 보안 업데이트 때문입니다. PPA와 같은 타사 저장소를 사용하는 경우 아무 문제가 없습니다.

회사 환경에서 컨테이너화에 도커와 같은 것을 사용할 때는 컨테이너를 한 번 빌드 한 다음 다양한 릴리스 환경 (개발, 스테이징, 프로덕션)을 통해 컨테이너를 이동하고 매번 컨테이너를 다시 빌드하지 않아야합니다. 이것은 테스트되지 않은 다른 컨테이너를 얻지 못하게합니다.

캐시 파일이 어디에 있는지에 대한 질문에 대답하려면 /var/lib/apt/lists.

apt-get update 명령이 무엇을하고 언제 사용해야하는지 설명 할 수 있습니까?

apt-get update 배포판의 패키지 리포지토리에서 업데이트 된 인덱스를 다운로드하여 사용 가능한 모든 패키지와 정확한 버전을 나열합니다.

우분투 및 데비안과 같은 일반적인 배포판은 일반적으로 패키지 오퍼링에서 보수적이고 역 호환되므로 버전은 시간이 지나도 크게 변하지 않습니다. 보안 업데이트 또는 버그 수정으로 인해 변경됩니다. 예를 들어, MySQL은이 업그레이드 될 수 5.7.18로 5.7.19하지만에 6.x.

패키지 인덱스는 어디에 저장됩니까? 데이터베이스에서? 파일에?

일반적으로 안에 하나 이상의 파일에 저장됩니다 /var/lib/apt. Docker와 관련하여 이러한 파일은 이미지 안에 있습니다. Dockerfile을 빌드 할 때 새로 작성된 이미지로 작성되고 지속되는 새 파일 시스템 계층에 저장됩니다.

캐시를 업데이트하지 않고 apt-get install을 수행하면 어떻게됩니까?

더 이상 존재하지 않는 패키지 버전을 다운로드하려고 할 수 있습니다. 이는 가상 머신에서 매우 일반적이지만 기본 이미지가 작성된 후 분배 저장소가 새 패키지를 릴리스 한 경우 컨테이너 내부에서도 가능합니다. 배포 관리자와 Dockerfile 관리자 사이에는 조정이 없을 수 있습니다. 배포 관리자는 배포의 다운 스트림에 있으며 더 클 수 있습니다. 데비안 저장소는 하나 뿐이지 만 수천 개의 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 가상 머신을 반복적으로 구축하려고 할 때도 같은 문제가 발생합니다.

일부 시스템 관리자는 Aptly 와 같은 서비스를 사용 하여 원래 리포지토리를 미러링하고 특정 버전을 고정 할 수 있지만 업데이트를 테스트하고 변경하는 작업을 자주 수행하지 않는 한 보안 업데이트가 누락 될 위험이 있습니다. 고정 중입니다.