如何可靠地使用docker-compose的本地Maven镜像代理？
我正在努力将我们的Maven构build过程迁移到我们现有的Java项目的Docker中。 我是一位使用Maven的经验丰富的Java开发人员，但仍在学习Docker。
我们的主要问题是，默认情况下，工件没有被caching，所以我们每五分钟下载一半的互联网，加上我们在当地老年人Nexus服务器上也有东西。 由于这是自动集成testing，我们不希望在Docker之外构build工件。
仔细考虑之后，我发现一个好的解决scheme可以是为每个开发人员运行一个Maven镜像代理，在这里可以保存本地configuration，然后Docker实例就可以引用这个代理。 手动运行Nexus3容器
docker run -p 8081:8081 --name nexus sonatype/nexus3 （加上一些手动configuration代理我们的内部存储库）到目前为止工作得很好，但不是由docker-compose控制的。
不幸的是，除了硬编码机器的外部IP号码之外，我不能看到客人访问主机（其中端口8081可用）的方式，并且我也看不到一种方式使docker组合负责确保联系人容器运行时，我的dockerbuild设需要它。
我目前使用这个作为Docker中的settings.xml文件：
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> <mirrors> <mirror> <id>local-nexus</id> <name>Local Nexus</name> <!-- Host external IP number --> <url>http://1.2.3.4:8081/repository/sbforge_central/</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors> <localRepository>/usr/share/maven/ref/repository</localRepository> </settings>
我应该如何处理这个？ 我看到两种情况。
-
我怎样才能得到一个可靠的主机名称？ Linux是必需的，其他平台将是不错的。
-
如何使docker-compose控制这个容器，以便在运行
docker-compose build以便docker可以确保nexus容器的主机名parsing？ 将成品包装起来时不需要。
还是有更聪明的方法？
我希望我得到了正确的，但我看到以下选项来解决您的问题：
1. [已更新]在settings.xml中使用env参数
你可以在docker-compose.yml使用一个环境variables，并在settings.xml中设置它： ${env.EXTERNAL_NEXUS_HOST} ？
2. Nexus依赖
docker-compose build不会让你为其他服务设置条件，但是你可以使用docker-compose run --rm和depends_on
version: '2' services: # Whatever this might look like, it's just an example mvn: image: mvn depends_on: - nexus command: mvn deploy nexus: image: sonatype/nexus3
这是否解决任何问题，或者我弄错了你？
按照https://stackoverflow.com/users/4527948/asger-askov-blekinge离线build议，在docker-compose控制的networking中主机的默认networking地址是172.17.0.1。 为mavenbuild议的修改版本的pom.xml：3-jdk-9-slim image（在图像中移动本地仓库）如下所示：
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> <mirrors> <mirror> <id>local-nexus</id> <name>Local Nexus</name> <url>http://172.17.0.1:8081/repository/maven_central/</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors> <localRepository>/usr/share/maven/ref/repository</localRepository> </settings>
这对于我们在进行非部署构build时最为有用，因为我们可以在Nexus中轻松地将我们的内部存储库与Maven Central进行合并，从而将复杂性移植到构build之外。
不是一个答案，但评论不允许这么大的评论：
也许我在这里误解了一件事情：但是，我是一个经验丰富的Maven开发人员，您是什么意思？您是否开发Maven插件等？或者您是使用Maven的Java开发人员吗？此外，为什么工件没有被caching你是否通过Maven构build？你是否删除了每个构build的本地caching？你之前是否使用过一个版本库pipe理器？为什么你不想在Docker之外构build工件？是否使用Jenkins这样的CI服务器？为什么使用版本库pipe理器在Docker中，但是没有为仓库数据安装一个卷？和Docker-Compose的关系在哪里？除了Docker-compose不负责保持服务的可用性和可用性。
您的settings.xml的configuration看起来像是共享本地caching莫名其妙？ 我希望你不要这样做…这是行不通的…
更新：
正如我之前问的，为什么你需要在Docker Container内部构build？ 它比外面慢很多，最好是用于这样的目的一个CI服务器…. docker-compose不能真正的协调事物，因为它不能确定一个服务是否正常运行（这必须由你自己的服务来处理）
此外，你不能抽象的本地caching，因为你需要它来build立你的jar / war / ear的…（顺便说一句：我现在与Docker工作了大约2年;与Maven工作了大约10年;我Apache Maven PMC成员）…
关键是你必须映射Docker容器的本地caching在容器被删除后没有被删除的卷上。因此，每次启动“构build容器”时，都必须将容器赋予Container。 。其他方面，它会被删除（容器内的本地caching），当你停止对你的Nexus3容器也是如此的容器…你也必须映射到Nexus3容器的容量，否则代理的想法只是砸了… 。
关于用docke-compose创意的一些话 如果你定义了一个像depends_on nexus东西，这将会在Maven执行之前启动Nexus3容器，但是直到Nexus3真的可以使用的时候才会启动它（这大概需要2-3分钟）…所以最后这种（通常是build造速度超过2-3分钟）…所以你必须在一个单独的区域（例如Mesos类环境中）启动Nexus3容器，这个区域运行总是对你的系统是至关重要的基础设施来支持Maven构build…我也build议开始使用像jenkins一样的CI解决scheme来处理所有的构build…