주문형 RPM 이미지를 생성하는 방법

주문형 RPM 이미지를 생성하는 방법

내 로컬 네트워크에 Fedora 패키지용 RPM 저장소를 생성하고 싶습니다. 저장소 제한으로 인해 처음에는 저장소를 비우고 패키지에 액세스한 후 패키지를 다운로드하고 싶습니다.

배경

저는 로컬 가상 머신을 자주 사용합니다. 새 VM을 생성하고 Fedora를 설치할 때마다 인터넷에서 많은 패키지가 다운로드되며 다운로드한 패키지의 대부분은 동일합니다. 프로세스 속도를 높이기 위해 동일한 네트워크에 있는 서버에 RPM을 캐시하고 싶습니다.

createrepo& 조합으로 비슷한 질문에 답변했습니다 reposync. reposync몇 개의 패키지만 필요할 때 전체 저장소를 사전 복제하고 싶지 않기 때문에 이 부분이 마음에 들지 않습니다 .

이상적인 솔루션

내 로컬 네트워크의 서버가 Fedora 설치를 위한 RPM 저장소 역할을 하도록 하고 싶습니다. .config 구성의 모든 메타데이터를 전달해야 합니다 /etc/yum.repo.d/*. 서버는 요청된 RPM이 로컬 캐시에 존재하는 경우 이를 전달해야 하며, 그렇지 않은 경우 다운로드하여 전달해야 합니다.

https://mirrors.fedoraproject.org/...덜 야심적인 접근 방식은 http 프록시를 사용하는 대신 단일 RPM 저장소를 구성하는 것입니다 .

업데이트 날짜: 2015년 11월 2일

이미 웹에서 nginx를 실행하고 있으므로 proxy_passproxy_cache. 다소 효과적이지만 IMHO에는 장점보다 단점이 더 많습니다.

  • 에 구성된 각 저장소에 대해 별도의 구성을 만듭니다 /etc/yum.repo.d/*.
  • 백업 미러로 인해 에서 사용할 수 없습니다 metadata.https://mirrors.fedoraproject.org/

댓글에서 제안한 대로 nginx를 제거하고 설치했습니다 squid. squid나에게 잘 작동합니다. 이 구성을 사용하면 store_id_programRPM이 원래 어디에서 왔는지에 상관없이 대체 미러를 사용하여 계속 캐시에 적중할 수도 있습니다.

답변1

여기에서 rpm 캐싱을 위해 미세 조정된 squid.conf를 찾을 수 있습니다:

https://github.com/spacewalkproject/spacewalk/blob/master/proxy/installer/squid.conf

메모리와 포트 설정만 수정하면 됩니다.

답변2

당신이 좋은 해결책을 찾았는지 확신할 수 없지만, 나는 결국 빠르고 작은 Go 프로그램을 작성하게 되었습니다. 캐싱 프록시 역할을 하고 RPM을 보존하지만 데이터베이스 파일의 업스트림을 프록시하므로 항상 정확합니다. 현재 CentOS, Fedora EPEL 및 Arch Linux용으로 구성되어 있습니다.

다음에서 볼 수 있습니다:https://github.com/yobert/remirror

답변3

apt-cacher-ng좋은 결과. 우리는 한동안 그것을 사용해 왔으며 훌륭하게 작동합니다. 그리고 효율성을 위해 http 미러(https 미러 아님)만 사용하는 것을 기억하세요(물론 https 트래픽을 보거나 캐시할 수는 없습니다).

http 미러만 사용하도록 Fedora 공식 저장소를 구성하려면 &protocol=http구성 URL 끝에 추가 하면 됩니다 metalink. 예를 들어 fedora저장소의 경우 다음과 같습니다.

metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch&protocol=http

https://www.unix-ag.uni-kl.de/~bloch/acng/

캐싱 프록시. 주로 Debian(및 Debian 기반) 배포판을 포함하되 이에 국한되지 않는 Linux 배포자의 패키지 파일과 함께 사용하도록 지정되었습니다. 그 목적을 이해하려면 Apt-Cacher 설명서를 참조하세요.

답변4

Yum 위키에는 페이지가 포함되어 있습니다.캐싱 솔루션 검토

그 중 일부는 주제와 관련이 있습니다.

  • 설치하다"스마트 거울", 그리고 등록이미지 관리자.

    Pros
        Zero configuration, on the client side.
        Post setup it mostly just works and everything should be immediate.
        Only downloads what is required by the users.
        Fully automated server side, once setup/working. 
    Cons
        Requires setting up a local Squid + Apache-httpd + IntelligentMirror to serve the data.
        If the server is down then metalinks/MM will route you to an external mirror.
        Only intelligently caches packages, not metadata. 
    
  • (베타) avahi-packages-server.py 및 yum avahi 지원(참조:http://james.fedorapeople.org/yum/avahi)

    Pros
        Zero configuration client.
        Zero configuration server.
        Only downloads what is required by the users. 
    Cons
        Not upstream yet (still beta).
        A client that doesn't run the avahi server side doesn't share it's downloads (so all clients need to run the "server").
        Requires working avahi on the network. 
    

관련 정보