Verwenden von Squid als Maven-Repository

Weiß jemand, wie man Squid verwendet, um Maven-Repositorys zu proxifizieren?

Was sind die Konfigurationsdateien dafür?

Das Hauptproblem ist, dass der Maven-Client eine HTTP-Anfrage mit Headern ausgibt, die das Cache-Verhalten steuern (und das möchte ich umgehen).

Hier ist eine typische Anfrage:

GET /maven/proxy/jboss-public/org/richfaces/richfaces-bom/4.2.0.Final/richfaces-bom-4.2.0.Final.pom HTTP/1.1
Cache-control: no-cache
Cache-store: no-store
Pragma: no-cache
Expires: 0
Accept-Encoding: gzip
User-Agent: Apache-Maven/3.0.4 (Java 1.6.0_26; Linux 2.6.32-38-generic)
Host: 192.168.2.171
Connection: Keep-Alive

Ich verwende dafür bereits Apache HTTPD (und disk_cache proxy_httpaktivierte Module), aber ich erstelle einen Spiegel, keinen Proxy.

Hier ist die Konfiguration (basierend auf dieser Site ):

<Proxy *>
Order deny,allow 
Allow from all 
</Proxy>

# central 
ProxyPass /maven/proxy/central http://repo1.maven.org/maven2
ProxyPassReverse /maven/proxy/central http://repo1.maven.org/maven2
CacheEnable disk /maven/proxy/central

# jboss-public-repository-group 
ProxyPass /maven/proxy/jboss-public http://repository.jboss.org/nexus/content/groups/public
ProxyPassReverse /maven/proxy/jboss-public http://repository.jboss.org/nexus/content/groups/public
ProxyPassReverseCookiePath /nexus /maven/proxy/jboss-public
CacheEnable disk /maven/proxy/jboss-public

# codehaus
ProxyPass /maven/proxy/codehaus http://repository.codehaus.org/
ProxyPassReverse /maven/proxy/codehaus http://repository.codehaus.org/
CacheEnable disk /maven/proxy/codehaus

CacheDirLength 2
CacheDirLevels 3

# Override default cache expiration and control 
CacheDefaultExpire 2419200
CacheMaxExpire 2419200

# Ignore requests to not serve from cache. Maven data never changes. 
CacheIgnoreCacheControl On
CacheIgnoreNoLastMod On
CacheStoreNoStore On

# Default max file size is 64K. Set to 1GB. 
CacheMaxFileSize 1073741824

apache-2.2 squid maven

— Anthony O.
quelle

Haben Sie darüber nachgedacht, stattdessen Nexus zu verwenden?

— Artbristol

Natürlich habe ich darüber nachgedacht. Ich habe auch andere getestet. Aber nichts war so schnell wie Apache im Proxy-Modus. Deshalb wollte ich einen echten Proxy verwenden und Squid verwenden, um vielleicht noch mehr Leistungen zu erzielen.

— Anthony O.

Wenn Sie Leistung wünschen, ist es sinnvoller, ein internes Artefakt-Repository wie Artifactory, Nexus oder Apache Archiva zu verwenden. Jedes Mal, wenn Sie ein neues Modul möchten, wird es aus dem Internet heruntergeladen und in Ihrem lokalen Netzwerk gespeichert. Wenn jemand in Ihrem Netzwerk dasselbe Modul benötigt, müssen Sie den Download nicht erneut im Internet durchführen. Bandbreite sparen und sich nicht um Cachesize kümmern.

— Joao Vitorino

Ich stimme @JoaoVitorino zu - die Verwendung eines Pull-Through-Caches von Artifactory ist wahrscheinlich die beste Option.

— Slm

Ich würde empfehlen, ein geeignetes Repository wie Nexus zu verwenden, das viel mehr Flexibilität ermöglicht, z. B. das Kombinieren von Central Maven mit Ihrem eigenen lokalen Artefakt in einem Repository und das Zwischenspeichern von Artefakten, die bei der ersten Anforderung von Central heruntergeladen wurden (damit Sie nicht alle Artefakte hosten müssen). nur die, die Sie benötigen), schützt Sie vor dem Löschen von Artefakten in der Zentrale (denken Sie an das Fiasko des NPM-Leftpads), ermöglicht es Ihnen, die Verwendung bestimmter Artefakte zu verhindern (sagen wir, es gibt ein defektes Artefakt mit einer Sicherheitslücke, Sie können alle Benutzer daran hindern, es zu verwenden). .

Und vor allem müssen Ihre Benutzer keine Zeit damit verschwenden, Proxy-Konfigurationen für Maven / Gradle / etc. Einrichten. was manchmal schwierig sein kann ...

Aber wenn Sie es in Squid tun müssen:

Zulässige Domains einfügen /etc/squid/mavendomains.list.

In squid.conf(oder wenn Sie Include-Dateien haben ...):

acl maven-domains dstdomain "/etc/squid/mavendomains.list"
acl allowed-networks src x.x.x.x/x
http_access allow allowed-networks maven-domains

— ETL
quelle