arduino joy_如何用Joy开发Kubernetes应用

arduino joy

Let’s face it: Developing distributed applications is painful.

让我们面对现实：开发分布式应用程序很痛苦。

Microservice architectures might be great for decoupling and scalability but they are intimidatingly complex when it comes to development.

微服务体系结构可能对解耦和可伸缩性非常有用，但在开发方面它们却极其复杂。

Local Kubernetes clusters (Minikube), long build times (Docker), and awkward or even nonexistent solutions to debugging is how we started. Two years in, we have automated everything: nothing runs on my local machine anymore and I can start coding and debugging individual components on any branch in just 15 seconds. 🎉

我们是从本地Kubernetes集群(Minikube)，较长的构建时间(Docker)以及笨拙甚至不存在的调试解决方案开始的。两年以来，我们已实现了一切自动化：不再在本地计算机上运行任何东西，而且我可以在15秒内开始对任何分支上的单个组件进行编码和调试。 🎉

I now enjoy working on our project so much and believe this is one of the most streamlined setups out there. In the following I want to share that experience.

我现在非常喜欢我们的项目，并且相信这是目前最简化的设置之一。在下文中，我想分享这一经验。

从预览环境开始 (Starting with a Preview Environment)

To get started on a bugfix or feature, I just need to create a new branch on GitHub. This will immediately trigger our CI servers (we use Jenkins) which then deploys a preview application to a GKE cluster. The application lives in a namespace corresponding to the branch name and, using the preview URL, I can access and use the application.

要开始使用错误修正或功能，我只需要在GitHub上创建一个新分支即可。这将立即触发我们的CI服务器(我们使用Jenkins)，然后将预览应用程序部署到GKE集群。该应用程序位于与分支名称相对应的名称空间中，并且可以使用预览URL访问和使用该应用程序。

Since I only branched off and didn't push any changes, the build artifacts are cached and the deployment takes only a few seconds. But even once I push changes, the build will run quickly as it only rebuilds what is really necessary.

由于我只是分支机构，没有进行任何更改，因此将缓存构建工件，并且部署仅需几秒钟。但是，即使我推送更改，构建也将快速运行，因为它仅重建真正需要的内容。

开始编码 (Starting to Code)

Next up I spin up a development environment to work on my task. We use Gitpod, which similarly to a CI server prebuilds dev environments for any branch. A click on a button from any of our project’s GitHub pages starts a fresh dev environment for exactly that branch and opens it in my browser.

接下来，我启动了一个开发环境来完成我的任务。我们使用Gitpod ，它类似于CI服务器为任何分支预先构建开发环境。在我们项目的GitHub页面的任何一个上单击按钮，即可为该分支完全打开一个全新的dev环境，并在我的浏览器中将其打开。

The dev environment is up after ~15secs and awaits me with a fresh clone of our repo and the correct branch checked out. Furthermore, the project is fully built and even all dependencies are downloaded already. The terminal welcomes me with the following message:

大约15秒后，开发环境就启动了，并等待我们重新克隆我们的repo并签出正确的分支。此外，该项目已完全构建，甚至所有依赖项都已下载。终端欢迎我以下消息：

The IDE is preconfigured with all the VS Code extensions we need, in our case Kubernetes, Docker, MySQL, Go and TypeScript. It is also already connected to the Kubernetes cluster running the preview environment as well as the corresponding database. So I can, for example, type 'kubectl get all' in my terminal and see all the deployed kube objects.

IDE已预先配置了我们所需的所有VS Code扩展，例如Kubernetes，Docker，MySQL，Go和TypeScript。它也已经连接到运行预览环境的Kubernetes集群以及相应的数据库。因此，例如，我可以在终端中键入“ kubectl get all”并查看所有已部署的kube对象。

The connection is based on a secret token that every developer has to put into their user account once and which is injected when starting a dev environment.

该连接基于一个秘密令牌，每个开发人员都必须将其放入用户帐户一次，并在启动开发环境时将其注入。

Although these ephemeral dev environments run in my browser, they provide all the state-of-the-art tools, allowing me to code, compile, run and debug code as well as interact with the database and the cluster.

尽管这些短暂的dev环境在我的浏览器中运行，但是它们提供了所有最新的工具，使我能够进行代码编写，编译，运行和调试代码以及与数据库和集群进行交互。

Of course, I can now push any of my code changes to GitHub and wait for the CI to update my preview environment accordingly. Since the build is caching heavily, small changes are deployed in a minute or so. Most of the time, however, a minute is way too long. We need an instant, hot-reloading experience that allows to debug any service in the context of the full application. Enter Telepresence.

当然，我现在可以将任何代码更改推送到GitHub，然后等待CI相应地更新我的预览环境。由于构建会大量缓存，因此一分钟左右即可部署少量更改。但是，大多数情况下，一分钟太长了。我们需要即时的热重装体验，以便可以在整个应用程序的上下文中调试任何服务。 输入网真 。

使用网真进行调试 (Debugging with Telepresence)

I want to be able to debug any individual service in the context of the full application. Instead of waiting for redeploys, our components have proper launch configs to debug them using Telepresence.

我希望能够在整个应用程序的上下文中调试任何单个服务。我们的组件无需等待重新部署，而是拥有适当的启动配置，可以使用Telepresence对其进行调试。

Telepresence replaces a Kubernetes deployment with a proxy that forwards all communication to a locally running process. So in short I can start a local debug session and have it working in the context of my preview environment.

网真用代理将Kubernetes部署替换为代理，该代理将所有通信转发到本地运行的进程。简而言之，我可以启动本地调试会话，并使其在预览环境中正常工作。

This works fantastically and is the best way I’ve seen so far for debugging Kubernetes services. It allows me to reuse all the existing debugging tools available.

这工作得非常好，是迄今为止到目前为止调试Kubernetes服务的最佳方式。它允许我重用所有可用的现有调试工具。

推送和审查 (Pushing and Review)

Once I’m happy with my changes, I push to my branch and create a Pull Request. I can do that from within Gitpod which is quite convenient.

对更改感到满意后，我将推送到分支并创建“拉取请求”。我可以在Gitpod中完成此操作，这非常方便。

Jenkins will now update the preview environment and Gitpod prebuilds a new dev environment. So when a colleague wants to start reviewing my changes, they can try them out immediately and quickly launch a dev environment for deeper inspection. From within Gitpod they can add comments to the code and even approve (or reject) the PR.

Jenkins现在将更新预览环境，而Gitpod将预先构建一个新的开发环境。因此，当一位同事希望开始查看我的更改时，他们可以立即尝试这些更改并快速启动开发环境以进行更深入的检查。他们可以从Gitpod内部向代码添加注释，甚至批准(或拒绝)PR。

结论 (Conclusion)

Achieving fast turnarounds and automated setups for distributed applications is hard but an absolute necessity for getting into a productive flow. Any friction in this will have a bad effect on the productivity of your team.

实现分布式应用程序的快速周转和自动设置是困难的，但是绝对需要进入生产流程。任何摩擦都会对您团队的生产力产生不良影响。

A fast build with preview environments and the slick Telepresence-based debugging experience have been an enjoyable productivity boost for us. If Gitpod didn’t exist we’d have to build it ;).

快速的预览环境构建和出色的基于网真的调试经验为我们带来了令人愉悦的生产力提升。如果Gitpod不存在，则必须构建它；)。

Do you have questions? Reach out, we are happy to help.

你有问题吗？伸出援助之手，我们很乐意提供帮助。

Note: Some of the features in Telepresence require system calls that are currently only allowed in Gitpod self-hosted.

注意：网真中的某些功能需要系统调用，当前仅在Gitpod自托管中才允许。