开篇
面对复杂的系统问题，通常倾向于采用更简单的方式来解决。本文整理了许久，结合自身数年从智能AI行业到传统行业，从平台架构到业务系统，贯穿IAAS、PAAS、SAAS模式，也在多个周末中抽了很多空余时间来记录这每一次mark历程，总结出来的业务与技术背后的每一套方法经验论尤其重要，业务与技术相辅相成，合理的使用科技技术，在业务场景中方显神通。在不一样的业务实际场景下，针对项目阶段所产生的变化，制定不一样的技术方案。不论多么渺小的技术方案，放在其对应的场景下都有着不一样的意义。本文介绍了一种有效提升研发童鞋进行众多中间件部署速率，具备一键快捷部署，易维护性，并结合特定业务场景范围内的本地私有化网络隔离部署方案，后续会将常用的系统架构设计形成专栏呈现出来，文章的重点不在于实现方案，而是一种思维方式。
实践是检验真理的唯一标准，当真正实操过后参与讨论，或许会让你有一点新发现，希望对读者在思考上有点不一样的IDea
01
在我们日常开发的过程中，针对不同复杂程度的系统，通常会涉及或采用一些常用的中间件技术来提升系统的高并发、高性能、高可用，削峰填谷，上下游业务的消息发布、订阅、通知，平台层与业务层或者业务与业务之间的解耦等等。比如：
消息队列中间件：Kafka、ActiveMQ、RabbitMQ、RocketMQ
搜索引擎中间件：ElasticSearch、Solr
缓存中间件：Redis、Memcached
任务调度中间件：XXL-JOB、ElasticJob
... ...
上述，对各类技术中间件，仅仅列举了其中部分技术栈，后续会针对这些技术方案选型进行重点阐述，届时会以中间件选型的形式发布在公众号专栏："每天译点晓知识"。
02
简介
随着系统架构设计的复杂程度不断提高，对于研发、运维人员跑通整个项目流程，也意味着需要更多的资源来运行并管理这些中控服务，特别是在面对不同的环境：开发环境、测试环境、预上线环境、生产环境等等，对不同研发人员需要一套与其他人员可隔离、可调试的环境就显得格外重要。
由此可见，一套低成本、易上手、易维护，尤其是对新手也及其友好的一键式自动化部署的私有管理端，况且现如今，在各种单体架构、微服务架构存在的当下，这不仅仅能够节省我们搭建环境所耗费的大量时间，同时，也从一定程度上提升了研发整体的开发联调效率，对促进生产上线，CICD 可持续交付、集成起着重要的意义。
本文，这里仅以windows环境-本地容器私有化的一键式自动化部署实现技术方案进行展开、阐述。
03
提质增效 事项
提高开发人员的工作效率，帮助软件开发人员更快速地构建、部署和管理应用程序，使用标准化的镜像能够统一屏蔽掉安装过程不一致导致存在的一些问题，本地容器私有化，提高应用程序的安全性和可靠性，并交付可用于生产的容器化应用程序。
尤其是在开发与其他研发成员协同调试阶段，可以自助搭建环境，不用依赖企业服务器资源，环境完整可控，不留痕，界面化启/停管理自己的应用服务，镜像制作、及时清理也便捷，拆箱即用。
04
方案执行 实施
安装 Docker Desktop
访问官网
https://www.docker.com/products/docker-desktop下载对应版本，一键安装完成后即可查看其应用服务启/停控制台管理界面，进行相关服务构建、部署等功能操作。
验证 Docker Desktop
检验 windows 环境是否具备环境，输入win+R快捷命令打开cmd窗口
docker -v
Docker version 24.0.5, build ced0996从上可知，容器初始化环境已搭建完成。
设置 Docker Engine
相信各位开发者只要使用过 yum 或 pip 或 npm、cnpm install 获取镜像资源文件的，一般都会设置国内镜像源-绿色框标记区域，特别是针对网络隔离环境，已经制作好的镜像获取下载，这时就可以搭建我们本地私有镜像-蓝色框标记区域。
搭建 私有镜像仓库
# 搜索镜像
docker search registry
# 拉取镜像
docker pull registry
# 查看镜像
docker images也可以通过 Desktop 桌面程序进行拉取，可视界面化指定版本下载。
这里，通过命令的方式展示一下整个搭建流程：
docker run -itd -v D:/registry:/var/lib/registry -p 5000:5000 --restart=always --name registry registry:latest私有仓库设置为本地磁盘，小编 D 盘这里是 SSD 固态。
验证制作镜像 安装一个新的服务
这里展示一个已经制作成本地的centos镜像：
# 这里基于centos:latest制作了一个私有仓库的新镜像
docker tag centos:latest localhost:5000/centos:v1
# 推送镜像至设定的仓库
docker push localhost:5000/centos:v1也可以界面化下载镜像，启动/停止容器，就可以进入虚拟的centos终端，在本地私有镜像仓库可以查阅已经制作好的镜像文件。
也可以通过命令，查看私有仓库地址中的镜像：
curl http://ip:5000/v2/_catalog我们也可以通过命令，查看正在运行中的容器：
docker ps当然在其他操作系统上，比如在 centos 上通过 Dockerfile 制作应用服务镜像也可以参考：
docker build -t reverse-images -f ./Dockerfile Dockerfile 说明：
# 基于jdk1.8部署jar
jar包同级目录创建Dockerfile
# 基于jdk镜像
FROM jdk1.8:latest
# 创建一个目录
RUN mkdir /demo
# 将jar包copy到指定目录
ADD app.jar /demo/app.jar
# 启动命令
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","-Xmx512m","-Xms512m","/demo/app.jar"]
# 创建镜像，指定名称demo版本号为1.0.0
docker build -t='demo:1.0.0' .
# 启动容器,映射到宿主机的9999端口
docker run -di --name=demo1 -p 9999:8080 demo:1.0.0
# 有些镜像过时了，我们需要删除。使用如下的命令：-f：表示强制删除镜像；image_id：镜像id
docker rmi -f image_id 示例：这里基于 jdk1.8 构建了一个java应用镜像，配置属性文件可以挂载到宿主机上，这样就不用进入容器去修改：
"--spring.config.location=/conf/application.yml"-v /home/yxd179/docker-build/conf:/confhttps://blog.csdn.net/yxd179/article/details/89523113在可视化，管理端控制台，还可以对自己启动的应用服务进行管理，Kafka服务的启动，包括其队列集群管理控制台，启动Kafka-Manager即可查阅当前主机Broker上消费者Consumer订阅主题Topic的消费详细情况。
我们也可以对制作好的镜像进行界面概览查询，基于本地私有仓库的方式拉取镜像，也是可以支持内网隔离的，不需要联外网也可以下载，例如提前准备好的各种技术中间件：消息队列中间件、注册中心组件、数据仓库等等。
*温馨提示*：对于需要大量操作IO的数据库不建议使用，要合理设置好挂载磁盘路径，防止数据丢失，以及出现服务访问性能相关瓶颈。
Registry 说明：
# 私有镜像仓库
-itd: 在容器中打开一个伪终端进行交互操作，并在后台运行；
-v: 把宿主机的/data/registry目录绑定到容器/var/lib/registry目录(这个目录是registry容器中存放镜像文件的目录)，来实现数据的持久化;
# 在容器中启动私有镜像仓库并将私有仓库的存储目录挂载到宿主机指定目录中，这样做是为了：
# 若是容器被删除了，存储在容器中的镜像就不会被删掉(默认情况下如果容器被删除，则存放于容器中的镜像也会丢失)
-p：映射端口;访问宿主机的5000端口就访问到registry容器的服务了
--restart=always: 这是重启的策略，在容器退出时总是重启容器
--name registry: 创建容器命名为registry
registry:latest：刚pull下来的镜像05
基于应用服务制作程序启动脚本无法满足吗？
应用服务启动主流有 Docker 容器虚拟化部署，K8S部署（资源管理），一键安装启动脚本...
对系统架构复杂程度较高的系统，由于中间件以及应用服务可能存在不同版本差异，CICD 成本也不低，尤其是在微服务架构中部署运维更加复杂耗时，对研发、产品和实施工程师都是一种消耗，当然也根据不同的业务场景存在各种历史原因。而使用 Desktop 桌面应用程序的方式对实施人员界面化启/停服务较为友好，尤其是新人，对外统一屏蔽了技术上存在的一些成本，加上社区活跃维护度很高，企业版的桌面应用更是助力生产赋能提效。
06
你参与过的云平台有什么异曲同工之妙
曾记否，数年前曾参与云资源池的管理和应用的自动化编译、构建、部署等云计算相关平台基础设施研发。这里简单说下这些年的一些心得：
从业界及大趋势上来看，现在也都在DevOps->AiOps智能化运维演变，包括云原生，其实里面囊括了devops 容器技术，微服务，CICD等等，从某一种程度上说也是一种文化，系统架构设计的确是一门"艺术活"。
对于DevOps流水线，最主要是由各类任务串联起来，但对于任务本身又分为多种类型，比如：自动化执行的任务，人工执行的任务->具体如下：
自动化：主要包括代码静态检查，构建，打包，部署，单元测试，环境迁移，自定义脚本运行等。
人工执行：主要包括了检查审核，打标签基线，组件包制作等工作。
我们的流水线其实基本都由上述两类任务组合编排而成，当然，也可以完全自动化执行，中间也可以加入人工干预节点。比如流水线到了测试部署完成节点后，可以到测试环境人工验证环节，这时只有人工验证通过之后再流转到迁移发布到生产环境动作任务节点。
构建：通常采用Jenkins、Maven进行自动化构建，构建完成输出一个或多个Jar包或War包。而在DevOps下，该操作会变成打包，部署俩个操作。打包是将构建完成的内容制作为镜像，而部署是将镜像部署到具体的资源池和指定集群。
打包：基于构建完成的部署包来生成镜像。我们一般首先基于一个基础镜像文件基础上进行，然后在基础镜像文件上拷贝和写入具体的部署包文件，同时在启动相应的初始化脚本...
其实，我们要考虑构建和打包如何尽量松耦合，打包简单来理解为一个镜像的制作过程，需要的是构建产生的输出。当然，可以对其输出和需拷贝的内容在构建的时候就进行约定好。而打包则可理解为一个标准化的镜像制作作业，我们需要考虑的就是前面Dockerfile里面提到的：
a) 基于哪个基础镜像
b) 中间件容器默认目录设置
c) 初始化启动命令
这样在实际打包设计就无需指定具体的部署包和部署文件，可由编排的时候-上游输入至下游。
部署：将镜像部署推送到哪个资源池，哪个集群节点，初始化的节点配置等等这些，因为指定部署的镜像已经由上游节点传递进来了。这样能使流水线编排更加灵活。比如在进行了构建、打包后，像我们在上文提到的不同环境部署。那则是打包完成后需要对接多个应用部署任务，这都依托前面的打包结果进行自动化部署-并行进行。
测试环境部署完成后，我们需要通过专业的测试人员进行测试用例验证，通过后则可打TAG 标签后发布到 UAT 环境。这种常规化操作也可以通过流水线设计和完成，这就更容易在 CICD 持续集成看板 Dashboard 上看到整个版本构建和迁移的完整过程。其实QA/QC的协同职责我们经常谈到，若是整体能够形成闭环，则整个流水线作业即可更好的发挥出协同奇效。
all
总结
通过 Desktop 桌面应用程序来实现-基于windows环境-本地容器私有化的一键式自动化部署中间件，其可视化的界面管理不仅给我们屏蔽掉了许多在安装部署时带来的版本差异以及部署难题，同时也节省了大量童鞋学习使用中间件技术的成本。
对于接入方无需关心底层封装实现，业务侵入性较小，模式松耦合，当然知其然还是要知其所以然，这样才能更好的具备调优各种中间件的能力，本文上述有阐述，也请持续关注或私信留言予以探讨交流><
推荐阅读
Kafka | 记一次修复Kafka分区所在broker宕机故障-引发当前分区不可用的思考过程
即时通讯 | 记一次从0-1搭建IM在线实时聊天进阶思考过程
架构演进篇｜单体架构VS微服务分布式架构问答实录
始于记录，旨在检索
每天译点晓知识
源自于系统架构设计师、数据库系统认证工程师的一点分享，专注于互联网系统架构，国产数据库系统。聚焦知识小科普，分享周围小趣事，Fighting-心之所向，素履以往！ DT&AI时代【向Code致敬，Find你的N行】
Tags：重启容器