在上一则“云原生植物的不同说明及恰当涵义
”里，他们说到了云原生植物的引伸涵义，是合作开发自然环境也是云自然环境，这种就能确保合作开发自然环境和生产自然环境的连续性，使最后的布署顺利开展。责任编辑就透过具体内容的范例来深入探讨云原生植物的合作开发自然环境。
合作开发业务流程主要包括撰写标识符，流程布署和增容几个各个环节。每两个各个环节都须要适当的辅助工具来协助你降低成本。上面他们就来看一下如何构筑合作开发的云自然环境以及那些辅助工具能帮你在云自然环境里提高合作开发工作效率。合作开发IDE
以前的IDE只支持应用流程的合作开发，但云原生植物须要与此同时展开合作开发自然环境（罐子）的合作开发，平庸的情况是两个IDE能与此同时全力支持二者。布季谢的是Go语言，选择的IDE是Goland（也是IDEA IntelliJ），它这类是全力支持k8s的，你只要浏览两个应用流程xml。它全力支持k8s的手动完成（Auto-complete）等机能。如下表所示图右图，这种你就保有了与此同时全力支持应用流程和k8s的IDE。
但我不得已说它对k8s的全力支持很最高级，它无法认知k8s第一类间的相互关系。除此之外，k8s命令行对文件格式要求严加，如果字符不对，或文件格式没翻转，在布署时能收起。Goland有检查和文件格式的机能，出了难题会收起，但并不是每一严重错误它都能发现。也是说当它没收起时也无法的确文件格式是对的。这已经发生好几次了，IDE没收起，但布署时有难题。
关于IntelliJ对k8s的全力支持机能，请参看IntelliJ IDEA 2018.1: Kubernetes support
自然环境构筑
音阶k8s是在Minikube上展开的，而Minikube是加装在Linux虚机内的。这就须要合作开发自然环境的用户端和虚机间能够共享资源文件，这种就可以方便快捷增容。
我的合作开发自然环境是Windows，然后在Windows装了VirtualBox应用软件包，除此之外还加装了Vagrant（它是管理应用软件包的两个应用软件）作为介面来管理VirtualBox。流程共享资源
我的Go应用流程是在Windows上的“C:\code\src\http://github.com\jfeng45\k8sdemo”产品目录下，透过Vagrant可以把用户端的产品目录装载到虚机内，这种每天在IDE上修正了k8s的命令行，在虚机内可以直接取到，不需要除此之外同步。
在Vagrant中的配置是这种的：
网络共享资源
是实现用户端（笔记本）和虚机间的互相访问，主要是从用户端访问虚机。布季谢的是Vagrant， 因此要在Vagran的命令行（Vagrantfile）里展开配置。网络的配置有不同方式，我配置的是私有网络，这是一种很灵活的方式。它的配置方法是给用户端和虚机各自设定两个固定的IP地址，这种可以双向互访。
Vagrant的配置命令：
数据库共享资源
在配置k8s时，一般会把数据库设置成两个服务。如果能在用户端上访问k8s数据库，就能提前测试数据库，尽早发现数据库的难题。一旦把虚机和用户端间的网络联通了，是可以从用户端直接访问数据库。
有关自然环境配置的详情，详情请参阅“透过构筑MySQL掌握k8s（Kubernetes）重要概念（上）：网络与持久卷”.
合作开发业务流程
合作开发业务流程通常是这种的。你先在本地的IDE上撰写标识符（包括应用流程和k8s标识符），标识符是存储在本地硬盘上的。完成之后，你进入虚机自然环境，布署k8s集群和应用流程标识符，再在k8s集群上运行标识符，测试结果。如此反复循环。
业务流程示例
他们透过两个范例来讲解业务流程。在本地撰写完标识符之后，就要增容k8s流程。先用Vagrant启动虚机，然后启动Minikube：
流程结构
上面是流程的产品目录结构。“cmd”产品目录里是主流程，“config”产品目录是负责流程配置的，“dataservice”是数据访问层，“model”是域模型层，“logs”产品目录是存储日志的。“script”包含了所有与流程布署相关的文件。其中“database”里面是数据库脚本，“kubernetes”是k8s的所有命令行，一回儿还会详细讲解。
上面是k8s的命令行产品目录结构，最外面有两个文件“k8sdemo-config.yaml”和”k8sdemo-secret.yaml”是共享资源文件，因此放在最外层。里面主要有两个子产品目录“backend”和“database”分别存后端流程和数据库的命令行。内部的结构是类似的，都有三个“yaml”文件，“backend-deployment.yaml”是布署命令行, “backend-service.yaml”是服务命令行, “backend-volume.yaml”是持久卷命令行. “.sh”是k8s命令，用来创建k8s第一类。“backend”产品目录还多了两个“docker”子产品目录用来存储backend应用的Docker镜像，database的镜像文件是直接从Docker的库中取得，因此不须要除此之外生成镜像文件。
关于k8s的核心概念，请参阅“透过实例快速掌握k8s（Kubernetes）核心概念”.
布署和增容应用流程及k8s
他们的流程有两个服务“k8sdemo-database-service”和“k8sdemo-backend-service”，先要布署“k8sdemo-database-service”，因为它不依赖于其它服务。不过还有些第一类是共享资源的须要先展开增容。有一点须要注意的是由于k8s第一类间是有依赖关系的，在你创建时是须要按照顺序来创建。顺序的布署次序是这种的Secret->ConfigMap->Volume->Deployment->Service。
布署共享资源第一类：
检查和创建情况：
布署数据库服务：
数据库创建好了之后，可以在IDE中用流程直接访问应用软件包上的库，这种比较方便快捷。但你须要设置自然环境变量。在k8s中是由configMap设置的，在Windows里须要单独设置，命令在“windowsEnv.bat”里面。内容如下表所示：
创建应用流程镜像：
布署后端服务
登录罐子，并运行流程，查看结果：
上面步骤中的k8s部分并不是每天修正应用流程之后都要运行，通常只须要运行有改动的部分。一般来讲只是布署（Deployment）会有改动，因为流程的Docker镜像变了。即使这种要完成一次增容也有不少步骤。
有关k8s的核心概念，详情请参阅“透过实例快速掌握k8s（Kubernetes）核心概念”.
综述：
从上面的业务流程可以看出，在本地云自然环境上展开合作开发和增容还是比较繁琐的，你须要在用户端和应用软件包间展开切换，还要与此同时对应用流程和k8s展开增容，中间有很多手工操作，要敲入很多命令，怎样就可以简化它呢？
Helm
k8s的两个痛点是它有很多组成部分（布署，服务，存储卷等），每一部分都要分别敲入命令展开增容，特别是当出现难题时，你须要反复删除原来的并创建新的。Helm解决了它的这个痛点。Helm是最流行的k8s包管理辅助工具，就像Java中的Maven和Go里面的“Go Module”。它的两个核心概念是“Chart”。有了它之后，你可以把k8s的各个部分作为两个整体来管理，这种就大大减少了工作量。在增容初期，你还是可以对各部分展开单独增容，这种减少复杂度。但一旦成功之后，你就可以把它当成两个整体来操作，这种大大简化了操作。Helm的另两个作用是对K8s配置的版本展开管理。
Helm文件结构
chart里两个很重要的概念是模板（template）,也是Go语言模板。模板是里面加入了编程逻辑的k8s文件。这些模板文件在使用时都要先展开模板解析，把其中的流程逻辑转化成对应的编码，最后生成k8s命令行。
以上是Helm手动生成的chart产品目录结构，在Helm里每一项目叫两个chart，它由上面几个组成部分：
“Chart.yaml”：存有这个chart的基本信息，”values.yaml”：定义模板中要用到的常量。“template”产品目录：里面存有全部的模板文件，其中最重要的是“deployment.yaml”和“service.yaml”，分别是布署和服务文件. “helpers.tpl”用来定义变量，”ingress.yaml”和”serviceaccount.yaml”分别是对外接口和服务账户，这里暂时没用， “NOTES.txt”是注释文件。“charts”产品目录: 存有这个chart依赖的所有子chart。Chart设计
现在他们就用两个范例来展示Helm的chart设计。这个范例是两个微服务应用流程，它共有三层: 前端，后端和数据库。
在k8s中，每一层是两个单独的服务，它里面有各种命令行。Helm的优势是把这些不同的服务组成两个Chart来共同管理和音阶，方便快捷了许多。
键入如下表所示命令创建chart，其中“k8sdemo”是chart的名字，这个名字很重要，服务的名字和label都是由它产生的。这之后，系统会手动创建前面说到的chart产品目录结构。然后是对已经生成的文件展开修正。
上面是最后的chart产品目录结构图。“chart”是总产品目录，里面有三个子产品目录“k8sdemo”，“k8sdemo-backend”，“k8sdemo-database”, 每两个对应两个服务，每一服务都是两个独立的chart，能单独音阶布署，chart间也可以有依赖关系。其中“k8sdemo”是父chart，与此同时也是前端服务，它的“charts”产品目录里有它依赖的除此之外两个服务。“k8sdemo-backend”是后端服务，“k8sdemo-database”是数据库服务。
加装k8sdemo：
运行流程展开测试：
由上面可以看出，使用了Helm之后，大大简化了k8s的布署和增容过程。只需一步就能完成所有k8s第一类的布署。
详情请参看用Helm3构建多层微服务
手动增容辅助工具
Helm解决了k8s的布署难题，但你修正程序之后，还是要更新Docker镜像，就可以布署，布署之后还要测试，比对结果，这里面还是有很多手工操作，有没辅助工具能手动完成这些工作？确实有这种的辅助工具，而且还有不少，它们的机能也不尽相同。这里面有一类辅助工具是相对来说比较有用的，那是手动化整个布署、增容业务流程的。它们的机能和业务流程一般是这种的。
它会手动检测流程修正，一旦发现就手动生成Docker镜像，然后调用k8s布署文件把新的镜像文件布署到k8s集群上，再调用测试流程展开测试，并在控制台显示结果。整个过程不须要你敲入一行命令，全部手动执行。这种完全消除了手工操作，使整个业务流程手动执行。你可能会说你并不想每修正一行流程就展开一下测试，而是当你须要的时候再去测试。这个机能在某些辅助工具里也是可以配置的，你可以配置两个触发器，只有当它触发之后才手动完成上述操作。
Skaffold命令行：
他们现在就用两个范例来具体内容说明，使用的辅助工具是Skaffold。Skaffold的主要部分是两个命令行，叫“skaffold.yaml”, 存放在项目的根产品目录。里面有Skaffold须要的信息，如Docker镜像的文件名，k8s的布署文件等。
上面是这个文件，它看起来很像k8s的命令行，它的类型是“Config”。里面有两个主要部分，两个是：“build”，负责生成项目的Docker镜像的，另两个是“deploy”，负责把生成的镜像布署到k8s上。
Skaffold可以帮你手动生成基础命令行。你可以敲入“skaffold init”，它会问你一些难题，并根据你的回答，手动生成“skaffold.yaml”文件。生成之后，你可以根据须要展开修正。这里面比较重要的是引用了镜像文件和k8s布署文件。如果你以前已经创建了这些文件，那么你可以复用它们。
运行Skaffold：
生成“skaffold.yaml”文件之后，键入如下表所示命令“skaffold dev”，系统会运行“skaffold.yaml”，布署k8s，并开始监控流程的修正。输出如下表所示：
你如果有测试流程，就可以在控制台输出结果。我没测试流程，就要登录到Pod上运行流程，查看结果。
获得Pod名
登录Pod，并运行流程
有关Skaffold的详情，请参看Working With Skaffold
手动增容辅助工具比较：
有四个比较流行的 手动增容辅助工具，它们是“Draft”，“Skaffold”，“Garden”，“Tilt”。
Garden：
我最先测试的是“Garden”，因为它机能强大。但测试之后发现它很不灵活，对项目的产品目录结构有特殊要求。例如，你的项目有三个微服务，那么它会建两个总项目，三个微服务每一是两个子项目，每一子项目里须要两个“Garden”的微服务命令行，总项目也要两个命令行，而且文件的名字和位置是固定的。这导致它配置起来很繁琐，而且与一般的流程结构有冲突。“Garden”的设计思想是好的，它想使用两个辅助工具来统一合作开发和布署。但由于合作开发和布署差别还是很大的，统一的结果是不伦不类。它给出的范例也都是很简单的实例，我觉得一旦应用到比较复杂的项目就会很不方便快捷。Garden的详情，请参看Introduction
Tilt：
“Tilt”是我第二个测试的，它看起来非常灵活，机能也很强大。但运行之后，它在连接Minikube时出了难题，连接不上。官方加装文档给出的默认的k8s集群是Microk8s。它的文档里也说了全力支持Minikube，但并没说明须要做哪些设置，看起来像是不须要设置就可以直接连通，不知道为什么我的Minikube会有难题。当然，也有可能是因为我启动时用的是“minikube start –vm-driver=none”，导致了连接的难题。我想如果花些时间仔细研究，难题应该可以解决，但连接Minikube是整个过程的第一步，一上来就出难题实在让我有些信心不足，就决定先放一放。Tilt的详情，请参看Tutorial: The First 15 Minutes
Skaffold：
这是我测试的第三个辅助工具。它机能很强大，也很灵活，虽然也碰到一些难题，但很快就解决了。因此我对Skaffold是很满意的。Skaffold给出的官方加装文档的浏览地址是“https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64”。 这个没法访问。你可以在GitHub的release里面浏览可执行文件，然后拷贝到“/usr/local/bin/skaffold”产品目录就可以了。Draft：
我没测试Draft。Draft现在已经不再维护了，它的合作开发者有别的任务，停止了继续合作开发。Draft应该比较容易使用，但机能不够强大。总体评论：
总的来说我对Skaffold很满意，它确实大大简化了增容业务流程。但我觉得这类辅助工具并不像我想像的那么完美。因为每天修正流程之后都要重新生成镜像，这个过程很慢。当然你可以有很多手段来优化他，例如建两个本地镜像库。除此之外这类辅助工具这类也有优化措施，例如对浏览库的优化。但总的来说跟本地自然环境还是没法比。关于这些辅助工具的比较详情，请参看The ultimate guide for local development on Kubernetes: Draft vs Skaffold vs Garden.io和Local Kubernetes development with Tilt.dev
合作开发模式：
在云原生植物合作开发模式下，你可以把项目的运行自然环境分成两部分。一部分是项目须要调用的服务和资源，这些都是布署在云自然环境上的（也是k8s集群）。你可以用Helm创建两个chart，里面包含所有本项目须要调用的k8s服务（包括数据库服务），然后把这个chart布署到k8s集群上，这部分的流程变化频率较低。一旦这些服务中的某些标识符变了，你只要重新布署chartxml了。
另一部分是项目这类的标识符和运行自然环境，这部分流程变化频率较高。这一部分既可以在k8s上运行，也可以在本地自然环境运行。它的不同决定了合作开发模式的不同。纯云原生植物合作开发模式：
在这种模式下，除了IDE和标识符是在本地，其他的所有东西都是在云自然环境。当项目标识符修正之后，须要创建新的Docker镜像文件，然后把镜像布署到k8s集群上，在k8s集群上展开增容。你可以用前面说到的手动增容辅助工具来完成这一任务。它的好处是合作开发环境和生产自然环境完全兼容，这种确保了在生产自然环境布署时没意外。缺点是增容工作效率稍低。你如果想把IDE和标识符都放在云上，也是可以的，本地只要有两个客户端来访问它们xml了。 这时是纯正的云合作开发自然环境，但它的象征意义更大，对实际工作没太大影响。
混合合作开发模式：
在这种模式下，项目是在本地增容的，而它依赖的其它微服务是布署在云自然环境上（应用软件包上的k8s上）的。由于本地自然环境和虚机的网络是联通的，本地自然环境上运行的标识符可以访问虚机内的微服务。数据库也是一样，也是布署在k8s集群上，你可以把它看成两个服务，并透过本地客户端访问数据库上的数据，这时数据库的物理位置对你是透明的，不管是在云上还是在本地都没区别。当项目的代码修正之后，你在本地运行项目并增容。如果你须要web服务器，对有些语言不成难题，例如Go，它的web服务器是用本地标识符生成的，是流程的一部分。如果你用的是Java，须要单独的服务器，那么你还须要两个本地服务器来布署修正之后的标识符。
这种方式的最大好处是增容工作效率很高。因为本项目的标识符修正频率是最高的，用这种方式能最大限度地提高它的增容速度。虽然牺牲了一点合作开发自然环境和生产自然环境的兼容性，但这也是可以弥补的。例如，你可以每隔一段时间把本地项目布署到k8s集群上（使用上面提到的增容辅助工具）和其他依赖的服务一起展开整个联调，这时的运行自然环境就和生产自然环境一致了。具体内容的布署频率根据个人和项目来定，可以是每天，也可以是3天或更多。这种既能确保平时增容的速度和工作效率，又能确保本地合作开发自然环境和生产自然环境的连续性。这种模式在我看来更有优势。
辅助工具总结：
责任编辑详细讲解了云原生植物合作开发自然环境以及须要的辅助工具，它包括上面四类：
IDE：必不可少，需全力支持k8s.k8s：是云原生植物的基石，没它就没云原生植物.Helm：不论什么合作开发模式，它都是两个不可或缺的辅助工具.手动增容辅助工具：在纯云原生植物合作开发模式下是必不可少的，在混合合作开发模式下也是须要的，但没纯云原生植物合作开发模式下那么重要。源码库
完整源码的github链接：
k8sdemo
