maven build和push image中遇到的坑（学习过程记录）
最近在做jenkins的持续集成构建，其中一项是要实现docker容器化部署。项目本身是maven项目，我对于maven和docker都没有什么认知基础，于是求助百度和官网，从头开始啃起。遇到了不少的坑，所幸没有放弃，一点一点地填上来了，在这里把学习过程简单记录一下。
什么是maven？
看了不少的解释，大同小异，但如果你没接触，只会觉得抽象和不可理喻。还是把官网的解释翻译过来，毕竟这是最权威的。Maven，是一个犹太语词汇，意思是知识的积累，最初在Jakata Turbine项目中用来简化构建过程。当时有一些项目（有各自Ant build文件），仅有细微的差别，而JAR文件都由CVS来维护。于是希望有一种标准化的方式构建项目，一个清晰的方式定义项目的组成，一个容易的方式发布项目的信息，以及一种简单的方式在多个项目中共享JARs。由此产生了一个现在可以被用于构建和管理任何基于java的工程的工具。
简单地说，Maven是一个工具，用来管理java工程中众多的依赖jar包，由此简化java工程的构建和发布。在maven中最重要的就是pom.xml文件，全称是项目对象模型（Project Object Model），它用来描述具体的项目。maven的生命周期在运行mvn install的时候被调用，然后maven执行一系列有序的步骤，运行许多默认的插件目标，这些目标完成了像编译和创建一个jar文件这样的工作。
由此看来，maven并不神秘和复杂，常用的命令也就那么几个。很多时候maven项目和docker结合在一起使用，一起作为容器发布。
什么是docker？
docker可以说是现今IT行业最热门的概念了。各行各业都在以容器化部署为目标，它使用方便、高效、轻巧又可靠。引用百度百科的定义：Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
我用到的docker常用命令有以下：
查看已有的docker镜像
这个非常好用，可以确认镜像是否生成成功。
删除镜像
docker rmi image_name
使用dockerfile打包镜像
docker build --no-cache -t image_repository:imageTag .
no-cache表示创建镜像的过程中不使用缓存，-t表示镜像的名称和标签，注意最后的.一定要有，否则会报错
push镜像
#把制作好的docker镜像推送至指定harbor仓库
docker push image_repository:dockerTag
docker登录
docker login -u harbor_username --password harbor_pwd harbor_ip
重启docker守护进程
systemctl daemon-reload
重启docker服务
systemctl restart docker
需要注意的是，在每次docker配置信息变更时，都需要刷新，也就是重启docker守护进程或docker服务。
知识点梳理完毕，说一下这次打包过程中遇到的坑：
1.使用mvn build和mvn push镜像和docker 的build和push有什么区别？
两种方法我都试了一下，对比感受是没有区别，mvn命令打包和push貌似也是调用了docker的打包和push，当然前提是你要安装maven的docker插件，否则会报错，类似这样
这种情况下，可以直接用docker的build和push命令，同样可以产生镜像并推送到仓库成功。
2.在push镜像时，报错提示443端口号connection refused
网上百度了很久，解决方案基本上没有能用的，有说服务端没有监听端口，导致连接被拒绝，用netstat -an |grep 443查询后，结果发现并不是，也有说这个监听端口被其他的ip占用，如127.0.0.1，结果发现也并不是。最后还是只能去看官网https://docs.docker.com/config/daemon/systemd/，这里提到了docker守护进程的配置，主要的推荐方法是使用/etc/docker/路径下的daemon.json文件去配置，打开这个文件，发现这里面有一项insecure-registries，网上查了一下，dockerfile上传镜像必须通过https的方式，因此这里需要把要上传的仓库地址写到这一项里面。
设置完了之后需要重启docker服务生效。
3.在push镜像时，报错提示unauthorized: authentication required
同样的是在官网中提示了，这是由于未添加https代理的环境变量，按照官网的方法，创建这个文件
sudo mkdir -p /etc/systemd/system/docker.service.d
然后添加https代理的配置文件
touch /etc/systemd/system/docker.service.d/https-proxy.conf
增加以下环境信息
[Service] Environment="HTTPS_PROXY=https://proxy.example.com:443/"
最后重启docker守护进程和docker服务
$ sudo systemctl daemon-reload $ sudo systemctl restart docker
搞定！终于迎来了期盼中的画面
这次的经历很宝贵，从无知到了解，需要的只是不懈的努力而已。在软件测试的300条忠告中（具体名字不记得了，很好的一本书），提到对于一个很复杂的概念，不要被吓到，一点点地熟悉它，等你慢慢熟悉后，你会有新的思路，新的认识，新的理解。这是一个不断靠近的过程，就像敏捷，谁也没有上帝视角，我们只能做一个不断提升自己认知的普通人。
