一文带你弄懂 Maven 拉包原理
Posted 陈树义
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一文带你弄懂 Maven 拉包原理相关的知识，希望对你有一定的参考价值。
业务需求开发的时候，我们总是会遇到拉不到依赖包的情况。此时如果不清楚 Maven 拉取依赖包的原理，那么很可能找不到问题所在。今天树哥就带大家了解下 Maven 拉包的原理，让你在遇到问题的时候能快速解决！
三种仓库
在 Maven 中，仓库指的是存放代码构建的一个位置。从分类上来说，Maven 仓库有两种类型，分别是：
- 本地仓库（Local）
- 远程仓库（Remote）
本地仓库，是存在于本地的一个仓库，它用来缓存下载的依赖包。这样就不用每次都通过网络去拉取依赖包了，提高了依赖拉取速度，减轻了仓库服务器的压力。
远程仓库，如其名字所述，其实位于远程服务器的一个仓库。例如有些公司自己对外开放了一些 API，需要将这些 API 的依赖开放出去，这时候就可以将 API 的 Jar 包放到公司自己的远程仓库中。公司的客户可以通过连接该仓库下载 Jar 包。例如你们公司开发了自己的基础工具类，并将其打成了一个 Jar 包。此时你可以将该 Jar 包部署到公司自己的远程仓库中，公司其他开发伙伴配置该远程仓库，从而可以拉取到该 Jar 包依赖。
在网上其他资料中，还会提到 Maven 仓库有另一个类型 —— 中央仓库（Central）。但在我看来，中央仓库其实是一个特殊的远程仓库。 它的特殊之处在于，它是 Maven 官方提供的，其中包括了大量常用的库，基本上大多数的依赖包都可以在这里找到。另外一个特殊之处在于，中央仓库的地址是内置在 Maven 源码中的，即默认会向中央仓库拉取依赖，这个在后续的依赖搜索顺序中会讲到。
而我们经常说的私服，其实也是一个特殊的远程仓库，其特殊之处在于：它只对公司内部开放，方便存放一些本团队创建的开发库。我们经常说的阿里云 Maven 库，其实就是一个远程仓库，只不过其是对所有人开放罢了。
依赖搜索顺序
弄懂了仓库的类型，我们继续来了解下依赖的搜索顺序。
我们在开发过程中找不到依赖包，有多种原因，例如：
- 依赖包确实没有放到远程仓库
- 仓库配置有问题
- 等等
为了弄清楚到底是什么原因导致依赖找不到，我们需要了解 Maven 是如何找一个依赖的。简单来说，Maven 搜索依赖的算法如下：
- 首先，在本地仓库搜索，如果找不到则继续下一步。
- 接着，在中央仓库搜索，如果找不到则继续下一步。
- 最后，在远程仓库中搜索，如果找不到则抛出错误。如果没有设置远程仓库，那么抛出错误。如果找到了依赖，那么就下载到本地仓库缓存。
简单地说，Maven 搜索遵循简单的顺序 —— 本地仓库 -> 中央仓库 -> 远程仓库。弄明白了这个依赖搜索顺序，可以帮助我们更好地排查问题。但这可能还不够，我们还需要搞清楚 Maven setting.xml 中的一些配置信息，从而可以排查是否是配置出现了问题。例如：有时候我们配置了 mirror 镜像，会把对某个仓库的请求转发到另一个仓库，这时候你要是不懂 mirror 配置，你就找不到问题所在了。
配置信息
关于仓库的一些常见的配置项有：
- repositories
- mirror
- server
- 等等
下面我们将一个个讲解他们的作用。
repositories 标签
repositories 标签用于定义远程仓库，其配置范例如下所示：
<repositories>
<repository>
<!--公司镜像的唯一标识，这个配置要注意，不能与mirrorOf配置的相同，不然会被拦截，重定向到外网的镜像仓库 -->
<id>nexus</id>
<!--仓库描述，随意写 -->
<name>xxxx</name>
<!-- 公司私有仓库地址，这个很重要不能错-->
<url>http://xxx:8081/nexus/content/groups/public</url>
<!-- 是否开启 releases 包的下载及更新策略 -->
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
</releases>
<!-- 是否开启 snapshots 包的下载及更新策略 -->
<snapshots>
<enabled>false</enabled>
<checksumPolicy>warn</checksumPolicy>
</snapshots>
<layout>default</layout>
</repository>
</repositories>
repositories 标签既可以在 setting.xml 文件配置，也可以在 pom.xml 文件中配置。Maven 在拉取依赖的时候，是按照声明的顺序从上到下去对应的远程仓库拉取依赖的。
mirror 标签
mirror 标签用于定义仓库镜像，其相当于一个拦截器。当 mirror 的 mirrorOf 值与 repository 的 id 相同时，repository 定义的仓库会被拦截，转而使用 mirror 中定义的仓库地址。配置范例如下：
<!--使用xx公司私有仓库替换Maven默认的中央仓库 -->
<mirrors>
<mirror>
<!--自己公司的镜像的唯一标识,在mirror标签中，其实没啥用：如xiaoyaziyun -->
<id>xiaoyaziyun</id>
<!--仓库描述，随意写 -->
<name>xx公司私有仓库地址</name>
<!--xx公司私有仓库地址，这个很重要不能错-->
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<!--`central`为Maven中央仓库的标识，替换Maven源码内默认的是中央仓库地址-->
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
如上图配置所示，Maven 会用 http://maven.aliyun.com/nexus/content/groups/public/ 这个仓库镜像替换 Maven 中央仓库，其中 central 是 Maven 中央仓库的 ID 标识。我们经常说用阿里云的 Maven 仓库可以提速，其实就是使用这种方法实现的。
server 标签
大部分远程仓库无须认证就可以访问，但我们自己搭建的 Maven 仓库，处于安全方面的考虑，我们会设置访问权限。此时，我们需要在 setting.xml 文件中配置 server标签。配置示例如下代码所示：
<settings>
<!--配置远程仓库认证信息-->
<servers>
<server>
<id>shuyi-tech-repo</id>
<username>admin</username>
<password>admin123</password>
</server>
</servers>
</settings>
上面的配置为 repository id 为 shuyi-tech-repo 的远程仓库配置了用户名和密码，其中用户名为 admin，密码为 admin123。这里通过 server.id 与 reposiroty.id 标签将认证信息与仓库绑定在一起，因此在配置的时候需要保持这两个信息一致，否则可能导致访问失败。
其他标签
proxy标签：服务器不能直接访问外网时需要设置的代理服务，不常用。
profiles标签：上面提到mirror，配置多个只会一个有效，如果需要多仓库配置，可以在profiles节点下配置多个profile，但是配置需要激活，特别麻烦，也不常用。
配置文件优先级
对于 Maven 来说，我们会看到有多个配置文件：
- 项目 pom.xml 文件
.m2/settings.xml文件- Maven 安装目录
/conf/settings.xml文件
如果一个配置同时存在于多个位置，那么到底以哪个为准呢？简单地说，这几个配置文件的优先级是怎样的呢？如果没搞懂这个问题，那么我们排查问题的时候可能会一团糟。
其实三者的优先级是 pom.xml >/用户/.m2/settings.xml>/maven安装目录/conf/settings.xml。如果要设置全局 Maven 仓库配置，需要在 Maven 安装目录 /conf 下找到 settings.xml 来修改。
参考资料
一文带你弄懂Kubernetes应用配置管理
不论什么样的应用，基本都有配置文件，在企业中，大部分会用到配置中心，比如apollo、nacos等，也有一些公司直接使用Kubernetes自带的配置管理，主要有：
Secret ConfigMap Secret 如果把配置信息保存在Secret中，其会被加密存放到Etcd中，Pod可以通过以下两种种方式使用它：
通过环境变量的方式 通过挂载的方式 指定拉取镜像的Secret 一般情况下，通过Secret保存的配置信息都是敏感信息，比如数据库的账号密码、认证服务的账号密码等，且Secret不宜过大，因为如果使用大的Secret，则将大量占用API Server和kubelet的内存。
创建Secret 创建Secret的方式主要有两种：
使用YAML文件创建 使用kubectl命令创建 使用YAML文件创建 使用YAML文件创建，就要熟悉Secret的配置详情，可以通过kubectl explain secret去查看。其主要字段有apiVersion，data，kind，metadata，type。
比如创建一个简单的Secret如下：
apiVersion: v1
kind: Secret
metadata:
name: my-secret-volume
type: Opaque
data:
user: cm9vdA==
password: UEBzc1cwcmQ=
其中apiVersion、kind和metadata是常用字段，这里就不赘述了。type表示secret的类型，主要有以下几种：
Qpaque：可以定义任意数据。 kubernetes.io/service-account-token：配置ServiceAccount Token。 kubernetes.io/dockercfg：配置docker认证文件。 kubernetes.io/dockerconfigjson：配置docker认证文件。 kubernetes.io/basic-auth：配置基础认证。 kubernetes.io/ssh-auth：配置ssh认证。 kubernetes.io/tls：配置TLS证书。 bootstrap.kubernetes.io/token：配置bootstrap token。 如果在创建Secret的时候没有指定类型，默认使用Qpaque类型。另外data的数据的值是需要base64转码。
使用kubectl命令创建 在使用kubectl创建的时候，如果不熟悉子命令信息，可以通过kubectl explain secret查看。
我们使用以下命令创建一个Secret：
$ kubectl create secret generic secret-auth-test --from-literal=username=joker --from-literal=password=123
创建完成后，可以看到username和password的值被自动加密了，如下：
$ kubectl get secrets secret-auth-test -oyaml
apiVersion: v1
data:
password: MTIz
username: am9rZXI=
kind: Secret
metadata:
creationTimestamp: "2022-07-25T07:44:18Z"
name: secret-auth-test
namespace: default
resourceVersion: "652834"
uid: ff1b756a-6b38-4b68-a47c-c51988729b68
type: Opaque
除了直接在命令行输入数据，还可以从文件创建，如下：
$ echo -n admin > ./username.txt
$ echo -n 1f2d1e2e67df > ./password.txt
然后通过--from-file引入文件，如下：
$ kubectl create secret generic db-user-pass \\
--from-file=./username.txt \\
--from-file=./password.txt
创建后的secret值都是加密的，如果要获取明文信息，通过以下命令即可：
$ kubectl get secret db-user-pass -o jsonpath=.data.password | base64 --decode
默认情况下，secret是使用base64加密的，所以解密可以直接使用base64解密。
使用Secret Secret只是一个静态资源，最终，我们是想使用它，在实际中，主要通过以下方式使用：
通过环境变量的方式。 通过挂载的方式。 指定拉取镜像的Secret。 我们在上面创建了secret-auth-test的Secret，下面分别使用以上三种方式进行使用。
通过环境变量使用Secret 在Pod的对象中，有spec.containers.env.valueFrom.secretKeyRef字段，该字段可以用来引用Secret字段，如下：
apiVersion: v1
kind: Pod
metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: secret-auth-test
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: secret-auth-test
key: password
这样就会把Secret里的信息注入到容器环境变量里，应用可以直接通过读取环境变量来使用。
通过挂载的方式使用Secret 可以使用挂载的方式，将Secret以文件的形式挂载到容器中，如下：
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: secret-auth-test
这样就会把数据挂载到/etc/foo这个目录里，如下：
$ kubectl exec -it mypod -- /bin/sh
# ls -l /etc/foo
total 0
lrwxrwxrwx 1 root root 15 Jul 25 08:30 password -> ..data/password
lrwxrwxrwx 1 root root 15 Jul 25 08:30 username -> ..data/username
如果Secret里有多个键值，还可以只挂载某一个数据，如下：
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: secret-auth-test
items:
- key: username
path: my-group/my-username
上面指定volumes.secret.items.path用来指定username的子目录，如下：
$ kubectl exec -it mypod-password -- /bin/bash
root@mypod-password:/data# cat /etc/foo/my-group/my-username
joker
除此之外，还可以指定权限，如下：
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
volumes:
- name: foo
secret:
secretName: secret-auth-test
defaultMode: 0400
然后可以看到被挂载的Secret的权限如下：
$ kubectl exec -it mypod-permision -- /bin/bash
root@mypod-permision:/etc/foo# ls -l
total 0
lrwxrwxrwx 1 root root 15 Jul 25 08:38 password -> ..data/password
lrwxrwxrwx 1 root root 15 Jul 25 08:38 username -> ..data/username
root@mypod-permision:/etc/foo# ls ..data/password -l
-r-------- 1 root root 3 Jul 25 08:38 ..data/password
注意：我们进/etc/foo目录直接使用ls -l查看到的权限是777，但是仔细的人可以发现其实质是一个链接文件，我们真正要看的权限是被链接的文件，也就是上面的..data/password。
在拉取镜像的时候使用Secret 我们在前面列举了很多YAML文件，都没有配置imagePullSecret，主要是那些镜像都是Dockerhub官方的镜像，对外是公开的。
然而，在实际的生产中，不会将自己公司的镜像对外公开，这非常的不安全。如果镜像仓库加密了，在下载镜像的时候要docker login，在Kubernetes中，也免不了该操作。
为此，Kubernetes提供了imagePullSecret字段，该字段用来指定拉取镜像的Secret，这个Secret会保存镜像仓库的认证信息。
（1）首先创建镜像认证信息的Secret。
kubectl create secret \\
docker-registry pull-registry-secret \\
--docker-server=registry.test.cn \\
--docker-username=ops \\
--docker-password=ops123123 \\
（2）在Pod中使用。
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
imagePullSecrets:
- name: pull-registry-secret
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
volumes:
- name: foo
secret:
secretName: secret-auth-test
defaultMode: 0400
这样就可以拉取私有仓库里的镜像了。
总结 综上，我们可以通过Secret保管其他系统的敏感信息（比如数据库的用户名和密码），并以Mount的方式将Secret挂载到Container中，然后通过访问目录中文件的方式获取该敏感信息。当Pod被API Server创建时，API Server不会校验该Pod引用的Secret是否存在。一旦这个Pod被调度，则kubelet将试着获取Secret的值。如果Secret不存在或暂时无法连接到API Server，则kubelet按一定的时间间隔定期重试获取该Secret，并发送一个Event来解释Pod没有启动的原因。一旦Secret被Pod获取，则kubelet将创建并挂载包含Secret的Volume。只有所有Volume都挂载成功，Pod中的Container才会被启动。在kubelet启动Pod中的Container后，Container中和Secret相关的Volume将不会被改变，即使Secret本身被修改。为了使用更新后的Secret，必须删除旧Pod，并重新创建一个新Pod。
ConfigMap ConfigMap和Serect类似，不同之处在于ConfigMap保存的数据信息是不需要加密的，比如一些应用的配置信息，其他的用法和Secret一样。
创建ConfigMap 同样，我们可以使用两种方式来创建ConfigMap:
通过命令行方式，也就是kubectl create configmap。 通过YAML文件方式； 通过命令创建ConfigMap 如果不熟悉ConfigMap对象的字段，可以通过kubectl explain configmap来查看，如果想查看创建configmap的示例，可以通过kubectl create configmap -h查看，如下：
Examples:
# Create a new config map named my-config based on folder bar
kubectl create configmap my-config --from-file=path/to/bar
# Create a new config map named my-config with specified keys instead of file basenames on disk
kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt
# Create a new config map named my-config with key1=config1 and key2=config2
kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2
# Create a new config map named my-config from the key=value pairs in the file
kubectl create configmap my-config --from-file=path/to/bar
# Create a new config map named my-config from an env file
kubectl create configmap my-config --from-env-file=path/to/foo.env --from-env-file=path/to/bar.env
从上面可以看出，创建ConfigMap可以从给定一个目录来创建。例如，我们定义了如下一些配置文件：
$ mkdir configmap-demo
$ cd configmap-demo
$ ll
total 8
-rw-r--r-- 1 root root 25 Sep 6 17:07 mysqld.conf
-rw-r--r-- 1 root root 25 Sep 6 17:07 redis.conf
$ cat mysqld.conf
host=127.0.0.1
port=3306
$ cat redis.conf
host=127.0.0.1
port=6379
然后使用一下命令来进行创建：
$ kubectl create configmap my-configmap --from-file=../configmap-demo/
然后通过一下命令查看创建完的configmap：
$ kubectl get cm
NAME DATA AGE
kube-root-ca.crt 1 21d
my-configmap 2 9s
$ kubectl describe cm my-configmap
Name: my-configmap
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
mysqld.conf:
----
host=127.0.0.1
port=3306
redis.conf:
----
host=127.0.0.1
port=6379
BinaryData
====
Events: <none>
我们可以看到两个key对应的是文件的名字，value对应的是文件的内容。如果要看键值的话可以通过如下命令查看：
$ kubectl get configmap my-configmap -o yaml
apiVersion: v1
data:
mysqld.conf: |
host=127.0.0.1
port=3306
redis.conf: |
host=127.0.0.1
port=6379
kind: ConfigMap
metadata:
creationTimestamp: "2022-07-25T09:20:43Z"
name: my-configmap
namespace: default
resourceVersion: "667706"
uid: 46cb52e9-0936-4934-9628-ac20efcfd893
当然，我们还可以通过文件来创建一个configmap，比如我们定义一个如下的配置文件：
$ cat nginx.conf
user nobody;
worker_processes 1;
error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;
pid logs/nginx.pid;
events
worker_connections 1024;
http
include mime.types;
default_type application/octet-stream;
log_format main $remote_addr - $remote_user [$time_local] "$request"
$status $body_bytes_sent "$http_referer"
"$http_user_agent" "$http_x_forwarded_for";
access_log logs/access.log main;
sendfile on;
tcp_nopush on;
keepalive_timeout 65;
gzip on;
server
listen 80;
server_name localhost;
location /
root html;
index index.html index.htm;
error_page 500 502 503 504 /50x.html;
location = /50x.html
root html;
然后通过如下命令创建一个nginx的configmap：
$ kubectl create configmap nginx-configmap --from-file=nginx.conf
查看创建后的信息：
$ kubectl get configmap nginx-configmap -o yaml
apiVersion: v1
data:
nginx.conf: |
user nobody;
worker_processes 1;
error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;
pid logs/nginx.pid;
events
worker_connections 1024;
http
include mime.types;
default_type application/octet-stream;
log_format main $remote_addr - $remote_user [$time_local] "$request"
$status $body_bytes_sent "$http_referer"
"$http_user_agent" "$http_x_forwarded_for";
access_log logs/access.log main;
sendfile on;
tcp_nopush on;
keepalive_timeout 65;
gzip on;
server
listen 80;
server_name localhost;
location /
root html;
index index.html index.htm;
error_page 500 502 503 504 /50x.html;
location = /50x.html
root html;
kind: ConfigMap
metadata:
creationTimestamp: "2022-07-25T09:24:29Z"
name: nginx-configmap
namespace: default
resourceVersion: "668283"
uid: a025da28-6817-4605-8daf-375b676282c1
注：在一条命令中--from-file可以指定多次。
另外，通过帮助文档我们可以看到我们还可以直接使用字符串进行创建，通过--from-literal参数传递配置信息，同样的，这个参数可以使用多次，格式如下：
$ kubectl create configmap my-cm-daemo --from-literal=db.host=localhost --from-literal=db.port=3306
通过YAML创建ConfigMap 通过YAML文件创建就比较简单，我们可以参考上面输出的yaml信息，比如定义如下一个YAML文件：
apiVersion: v1
kind: ConfigMap
metadata:
name: my-cm-daemon2
labels:
app: cm-daemon
data:
redis.conf: |
host=127.0.0.1
port=6379
然后创建即可。
使用ConfigMap ConfigMap中的配置数据可以通过如下方式进行使用：
设置环境变量值。 在数据卷中创建config文件。 通过环境变量使用ConfigMap 我们直接通过在pod.spec.containers.env.valueFrom.configMapKeyRef中引用ConfigMap即可，如下：
apiVersion: v1
kind: Pod
metadata:
name: env-configmap
labels:
app: env-configmap-mysql
spec:
containers:
- name: test-configmap
image: busybox
command:
- "/bin/sh"
- "-c"
- "env"
env:
- name: DB_HOST
valueFrom:
configMapKeyRef:
name: my-cm-daemo
key: db.host
- name: DB_PORT
valueFrom:
configMapKeyRef:
name: my-cm-daemo
key: db.port
envFrom:
- configMapRef:
name: my-cm-daemo
创建后，可以通过日志查看环境变量输出，如下：
$ kubectl logs env-configmap | grep DB DB_PORT=3306 DB_HOST=localhost 通过数据卷使用ConfigMap 基本原理和Secret一样。
在这里，通过指定pod.spec.volumes.configMap.name来指定ConfigMap，然后挂载到容器里，如下：
apiVersion: v1
kind: Pod
metadata:
name: volume-configmap-test
spec:
containers:
- name: volume-configmap-test
image: busybox
command: [ "/bin/sh", "-c", "cat /etc/config/redis.conf" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: my-configmap
我们可以通过日志查看ConfigMap是否挂载进去了。
$ kubectl logs volume-configmap-test
host=127.0.0.1
port=6379
我们也可以在ConfigMap值被映射的数据卷里去控制路径，如下：
apiVersion: v1
kind: Pod
metadata:
name: volume-path-configmap
spec:
containers:
- name: volume-path-configmap-test
image: busybox
command: [ "/bin/sh","-c","cat /etc/config/path/to/msyqld.conf" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: my-configmap
items:
- key: mysqld.conf
path: path/to/msyqld.conf
另外，当ConfigMap以数据卷的形式挂载进Pod的时，这时更新ConfigMap（或删掉重建ConfigMap），Pod内挂载的配置信息会热更新。虽然配置信息更新，应用到底能不能使用，主要还是依赖应用是否也会热更新。
总结 ConfigMap在实际中用的还是比较多，主要都是一些应用的配置文件，比如Nginx配置文件，MySQL配置文件，这类配置文件如果想放到私有的配置中心需要额外花费更多的精力，而放到ConfigMap，则方便很多，而且多数都以挂载的方式放进容器里。
以上是关于一文带你弄懂 Maven 拉包原理的主要内容，如果未能解决你的问题，请参考以下文章
一文带你弄懂Visual Studio：运行时库及MT/MTDMD/MDD