DevOps系列之国外大厨用Docker和Jenkins演示微服务的持续交付
本帖最后由 adminlily 于 2018-10-31 10:17 编辑Docker们手拉手，互相聊天互相吹牛，以确保所有工具和微服务都能装一个锅里。- 国外大厨名语录
Docker，微服务，持续交付是地球上目前运维圈子里最受欢迎的话题了。在由数十个微服务相互通信的环境中，测试，构建和部署过程的自动化显得尤为重要。Docker，当红小生是微服务的理想解决方案，它可以创建和运行带服务的隔离容器。
今天，我们来交流如何以流行的软件自动化工具（Jenkins）为微服务实例创建基本的持续交付流程。
1. 微服务实例构建
开篇，我先简要讲讲用于创建微服务实例的结构思路和工具。实例应用由两个彼此通信的微服务（帐户，客户），发现服务器（Eureka）和API网关（Zuul）组成，用Spring Boot和Spring Cloud框架实现，而且你可以在GitHub上download到源码。Spring Cloud支持微服务发现和网关的开箱即用 - 只要在maven项目配置文件中定义正确的依赖关系（pom.xml）。
客户、帐户REST API服务、发现服务器和gateway都在Docker里分别跑着。网关是微服务系统的切入点，它与所有其他服务交互，将请求发送到所对应的微服务器，在发现服务中搜索其地址。在每个帐户或客户微服务器有不止一个实例的情况下，请求Ribbon与Feign客户端负载平衡。
帐号和客户服务在启动后自动注册到发现服务器，之间有交互的可能 - 例如，如果我们想查找并返回所有客户的帐户详细信息。
解决方案架构如下图所示。
其实我不太想用Spring Boot和Spring Cloud框架了解这些微服务实现的细节。不过，通常Spring框架完全支持所有Netflix OSS工具（如Ribbon，Hystrix和Eureka）的微服务。
2. Dockerfiles
示例源码中每个服务都具有DockerfileDocker映像构建定义。这个Dockerfile的帐户服务，理解起来不难。我们用OpenJDK作为基础镜像，目标JAR文件添加到映像中，然后用java -jar命令运行，随后占用2222端口， 至外网。
我们还得在JAR manifest里面设置主类，在模块pom.xml中用spring-boot-maven-plugin来实现它。片段在下方可见。我们还要设置构建finalName切断目标JAR的版本号。Dockerfile和Maven构建定义与所有其他微服务相似。
3. Jenkins Pipelines
我们用pipeline插件为我们的微服务构建连续交付。除了Jenkins上的标准插件，我们还要个叫CloudBees的Docker Pipeline插件。我已经定义了四条流水线，如下图。
这是用Groovy语言写的用于发现服务的流水线定义。这里有五个执行阶段，在Checkout阶段，我们正在为项目的远程Git仓库提取更改。然后使用MVN clean install命令构建项目，并从pom.xml中读取Maven版本。在Image阶段，从发现服务Dockerfile构建Docker镜像，然后推送到本地注册表。在第四步里，我们在运行默认公开端口的内置镜像，这时候大家可以在对应的Docker看到主机名。最后，帐户pipeline的等待选项消失，也就是源pipeline构建完成。
帐户pipeline看起来很像。不过主要区别在于第四阶段，让帐户服务容器与发现容器做关联。这些容器要链接起来，因为account-service要求在发现服务器注册，并且必须能够使用主机名连接。
客户和网关也定义了类似pipeline，它们在每个微服务器的主项目目录中都可以作为Jenkinsfile。在执行期间构建的每个镜像也被推送到本地Docker注册表里。
要在主机上启用本地注册表，则需要拉取和运行Docker注册表镜像，而且要在拉取或推送时将该注册表地址用作图像名称前缀，本地注册表会显示在默认的5000端口上。
你可以通过调用REST API（例如http：// localhost：5000 / v2 / _catalog）来查看推送的镜像列表到本地注册表。
docker运行-d --name注册表-p 5000：5000注册表
4. 测试
启动构建discovery-service-pipeline，这个流水线不仅可以为发现服务运行构建，还可以在最后调用start下一个pipeline build（account-service-pipeline）。
配置一套gui'zeaccount-service-pipeline和customer-service-pipeline配置一套相同的规则，为customer-service-pipeline和gateway-service-pipeline也配置一套相同的规则。在所有流水线完成后，你就可以通过调用docker ps命令来检查运行的docker列表。此时你应该能看到五个容器：本地注册表和我们的四个微服务器。
当然你还可以通过运行命令检查每个容器的日志docker logs。例如docker logs account。如果一切正常，你应该能向http：// localhost：2222 / accounts或通过Zuul网关http：// localhost：8765 / account / account调用一个服务。
5. 结论
好了，基于Docker和Jenkins的微服务持续交付的示例忽悠完成。
我觉得如果看明白了，你应该可以轻松发现这个方案的潜在局限性。例如，实例已经把Docker串起来实现通信了，又或者实例中所有工具和微服务都在同一台机器上跑。
对于更高级的栗子，比如我们可以用运行在不同机器或Docker里的Jenkins附件来编排各种眼花缭乱的集群，包括Kubernetes工具的应用，又或者可以用Docker-in-Docker容器来虚拟一大堆Docker……
扯得有点远了……但是我希望这篇文章是对微服务和持续交付的一个很好的介绍，帮助你了解一些基础知识。文中提到的大神级工具，未来一定有更多更闪亮的应用场景。
原创： DevOps研究院
页:
[1]