程序部署到容器_如何简化容器化应用程序的部署

程序部署到容器

by Omer Levi Hevroni

由Omer Levi Hevroni

如何简化容器化应用程序的部署 (How to simplify the deployment of containerized apps)

I asked myself this question when I started to learn Kubernetes: how can we simplify the deployment of containerized apps? At first look, deploying containerized apps seems pretty simple. All you need is a bunch of YAML files, and by using kubectl (the Kubernetes command line utility), you’ll have your service up and running in your Kubernetes cluster.

当我开始学习Kubernetes时，我问了自己这个问题：如何简化容器化应用程序的部署？ 乍看之下，部署容器化应用程序似乎很简单。 您只需要一堆YAML文件，通过使用kubectl (Kubernetes命令行实用程序)，就可以在Kubernetes集群中启动并运行服务。

But, Although deploying one app is an easy task, how do you deploy hundreds of apps? At Soluto, we have more than 100 live microservices and this number keeps growing. So as we started thinking about shifting workload to our Kubernetes cluster, we faced a few challenges:

但是，尽管部署一个应用程序很容易，但是如何部署数百个应用程序呢？ 在Soluto ，我们有100多个实时微服务，并且这个数字还在不断增长。 因此，当我们开始考虑将工作负载转移到Kubernetes集群时，我们面临一些挑战：

First, Kubernetes deployment is actually more complex. There are many moving parts that you need to set up correctly: pod autoscaler, pod resources, ingress, and so on. Those parts require some experience with how Kubernetes works, and not setting it up correctly might cause issues in production. Ideally we’d have a way to simplify this, so developers can focus on writing their code and worry less about deployment.

首先，Kubernetes的部署实际上更加复杂。 您需要正确设置许多移动部件：容器自动定标器，容器资源，入口等。 这些部分需要一定的Kubernetes运作经验，并且未正确设置它可能会导致生产问题。 理想情况下，我们应该有一种简化方法，以便开发人员可以专注于编写代码，而不必担心部署。

Second, security is also a challenge. All services in production should have certain things, like Transport Layer Security (TLS). These are not necessarily complex things, but need to be taken care of nonetheless. We would like to pre-configure them so that any new deployment will be secured by default.

第二，安全性也是一个挑战。 生产中的所有服务都应具有某些特定内容，例如传输层安全性(TLS)。 这些不一定是复杂的事情，但是仍然需要加以照顾。 我们希望对其进行预配置，以便默认情况下将保护所有新部署。

寻找解决方案 (Finding a solution)

To solve these challenges and speed up and ease the adoption process, we looked for a way to create a template for Kubernetes. Something that any developer would be able to use, and would require just a few parameters (for example, the Docker image of the service) to get the service up and running in production.

为了解决这些挑战并加快并简化采用过程，我们寻求了一种为Kubernetes创建模板的方法。 任何开发人员都可以使用的东西，并且只需要几个参数(例如，服务的Docker映像)就可以在生产环境中启动并运行该服务。

On the other hand, we needed to be careful not to hide too much — developers must be able to understand what’s going on so they can handle production issues. We had to find the right level of abstraction that makes it easier to deploy to Kubernetes, without hiding too much detail.

另一方面，我们需要注意不要掩藏太多-开发人员必须能够理解正在发生的事情，以便他们能够处理生产问题。 我们必须找到合适的抽象级别，以使其更容易部署到Kubernetes，而不会隐藏太多细节。

With that in mind, we started to look for a solution. After trying a few things, we found Helm. Helm is a package manager for Kubernetes.You can use it to install any app on your cluster, and Helm will take care of getting all the required configuration files and installing them on your cluster. Helm also support updating deployments, rollbacks, and many other cool features. Each Helm package is called a “Chart”, and the charts are stored in a repository. With helm, installing Mongo, for instance, is as easy as helm install stable/mongodb.

考虑到这一点，我们开始寻找解决方案。 经过尝试几件事，我们找到了Helm 。 Helm是Kubernetes的软件包管理器。您可以使用它在集群上安装任何应用程序，Helm将负责获取所有必需的配置文件并将其安装在集群上。 Helm还支持更新部署，回滚和许多其他很酷的功能。 每个Helm程序包都称为“图表”，并且图表存储在存储库中。 使用helm，例如，安装Mongo与helm install stable/mongodb一样容易。

Sound like an excellent solution! We can define a chart for each type of service — like one for all our web APIs, which will handle things like load balancer and TLS — and the developer simply needs to specify the required parameters using Helm’s configuration files.

听起来是一个极好的解决方案！ 我们可以为每种服务类型定义一个图表，就像所有Web API一样，可以处理诸如负载平衡器和TLS之类的图表，开发人员只需使用Helm的配置文件指定所需的参数即可。

头盔：让我们看看它是如何完成的 (Helm: Let’s see how it’s done)

In order to use Helm, we first need to install it. Helm has two components: Helm client running on your computer, and Tiller, a server-side component running on your cluster. Then, we need to create the chart by using this simple Helm CLI command: helm create web-api

为了使用Helm，我们首先需要安装它。 Helm有两个组件：在计算机上运行的Helm客户端和在群集上运行的服务器端组件Tiller。 然后，我们需要使用以下简单的Helm CLI命令创建图表： helm create web-api

After running this command, you’ll notice the creation of a new folder named “web-api”. Within this folder, you’ll find all the familiar Kubernetes configuration files: deployment, service, ingress, and so on. Now it’s time to customize a bit: we can add a horizontal pod autoscaler, define the default resources the pod requires, and of course, enable TLS by default.

运行此命令后，您会注意到创建了一个名为“ web-api”的新文件夹。 在此文件夹中，您会找到所有熟悉的Kubernetes配置文件：部署，服务，入口等。 现在是时候自定义一点了：我们可以添加一个水平的pod自动缩放器 ，定义pod所需的默认资源，当然，默认情况下启用TLS。

Everything is highly customizable based on the Go templating mechanism. So anything we add can be overridden later by the developer, in case the default configuration doesn’t work as needed.

一切都基于Go模板机制高度可定制。 因此，如果默认配置无法按需工作，开发人员以后可以覆盖我们添加的所有内容。

So now we have a chart — but how can we consume it? The chart has to exist in a Helm repository, which is basically a server with a few Zip archives (which are all the charts in the repository) and one index file that is consumed by the CLI. You can manually set up your repo using any storage service like Azure Blob or AWS S3, but the simplest option is Chart Museum.

因此，现在我们有了一个图表，但是如何使用它呢？ 该图表必须存在于Helm存储库中 ，该存储库基本上是一台服务器，其中包含一些Zip存档(存储库中的所有图表)和一个CLI占用的索引文件。 您可以使用任何存储服务(例如Azure Blob或AWS S3)手动设置存储库，但最简单的选择是Chart Museum 。

Chart museum is a Helm repository with a CRUD API to manage your charts. It supports basic authentication so you can restrict who can push new charts to your Helm repository. Helm doesn’t supply any museum-as-a-service solution, so you’re gonna have to roll your own. But it’s dead simple — simply use its docker image.

图表博物馆是一个带有CRUD API的Helm存储库，用于管理您的图表。 它支持基本身份验证，因此您可以限制谁可以将新图表推送到您的Helm存储库。 Helm不提供任何博物馆即服务解决方案，因此您将不得不自己动手。 但这非常简单， 只需使用其docker映像即可。

Now we can build a CI/CD pipeline for our web-api chart, to ease the process of modifying it:

现在，我们可以为我们的Web-api图表构建CI / CD管道，以简化对其进行修改的过程：

• Run some kind of tests, to make sure that the new version is not broken. I’ll discuss how in the next paragraph.
  运行某种测试，以确保新版本未损坏。 我将在下一段中讨论。
• Pack the new chart, using Helm CLI.
  使用Helm CLI打包新图表。
• Push the new package to our Chart Museum instance, using Chart Museum’s API.
  使用Chart Museum的API将新程序包推送到我们的Chart Museum实例。

测试出来 (Testing it out)

Now our chart is ready to be used by developers! But wait… how can we know that the chart actually works? And how can we make sure it will continue to work? This is why we need to write tests for our chart (like we write for anything else).

现在，我们的图表已可供开发人员使用！ 但是，等等……我们如何知道该图表确实有效？ 以及我们如何确保它会继续起作用？ 这就是为什么我们需要为图表编写测试的原因(就像我们为其他任何东西编写的一样)。

There are basically two things we want to test.

我们基本上要测试两件事。

1. We want to test our template — for example, if an ingress is supposed to exist with a TLS and specific rules (defined by the developer), we should test the generated template and make sure the ingress was created correctly.
   我们要测试模板-例如，如果应该使用TLS和特定规则(由开发人员定义)来存在一个入口，则应该测试生成的模板并确保正确创建了入口。
2. We want to test that the files are valid Kubernetes configurations and that they work as expected.
   我们要测试文件是否有效的Kubernetes配置以及它们是否按预期工作。

Testing the first thing is relatively simple — check out this sample repo to see just how simple it is.

测试第一件事是相对简单的-检查此样本回购以了解它有多简单。

This allows us to test the generated Kubernetes files, by using kubetest. This is great, but can be complex and messy, especially when having a lot of branching in your template files.

这使我们可以使用kubetest测试生成的Kubernetes文件。 这很好，但是可能很复杂且混乱，尤其是当模板文件中有很多分支时。

A better solution is required — one that will allow us to do unit testing for the templates, without generating Kubernetes files. This wasn’t a problem until recently when we started to have a lot of branching in our templates, and we’re now looking for options.

需要一种更好的解决方案-一种解决方案，使我们可以对模板进行单元测试，而无需生成Kubernetes文件。 直到最近我们开始在模板中进行大量分支时，这才成为问题，现在我们正在寻找选项。

The second thing — testing that Kubernetes files are valid — is a bit more tricky. For now, at Soluto we’re using Helm’s version mechanism: each chart has a version, and all of our services will use the latest stable version. When a new chart version is pushed, we can test this version on a specific service. If it works correctly, update the rest of the services. Another option is to test that using minikube, but it was too complex for our needs.

第二件事-测试Kubernetes文件是否有效-有点棘手。 目前，在Soluto，我们正在使用Helm的版本机制：每个图表都有一个版本，并且我们所有的服务都将使用最新的稳定版本。 当推送新的图表版本时，我们可以在特定服务上测试该版本。 如果正常，请更新其余服务。 另一个选择是使用minikube进行测试，但这对于我们的需求而言太复杂了。

最后：部署！ (Finally: Deploying!)

So now we have a CI/CD pipeline for our Helm charts, and we have prepared a Helm chart that the developers can use. Now, when a new developer wants to deploy a new service to production, all they have to do is:

因此，现在我们为Helm图表提供了CI / CD管道，并准备了供开发人员使用的Helm图表。 现在，当新开发人员想要将新服务部署到生产中时，他们要做的就是：

1. Add our repository to their local Helm using helm repo add chartmuseum http://<chart-museum-url>2. Create a new Helm config file and specify the required parameters (for example, docker image of the service)3. Run helm upgrade —install <service-name> chartmusuem/web-api -f<path_to_config_file> and that’s it. The service is alive.

1.使用helm repo add chartmuseum http://<chart-museum-u rl> 2将我们的存储库添加到其本地Helm。 创建一个新的Helm配置文件并指定所需的参数(例如，服务的docker映像)3 . Run helm upgrade —install <service-name> chartmusuem/web-api -f<path_ . Run helm upgrade —install <service-name> chartmusuem/web-api -f<path_ path_to_config_file>即可。 该服务仍然有效。

And to make it even easier to understand, I’ve created a sample repository. The repository contains all the things that I’ve discussed in this blog post: a generic chart for a web app that can be deployed with this chart and chart museum. Check it out to better understand what’s going on — and there is even a walkthrough to help you get started.

为了使其更易于理解，我创建了一个示例存储库 。 该存储库包含我在此博客文章中讨论的所有内容：可以与此图表和图表博物馆一起部署的Web应用程序的通用图表。 进行检查以更好地了解发生了什么—甚至还​​有一个演练可以帮助您入门。

Thank you for reading along. If you have any questions, or you need help getting started with Helm, feel free to reach out either via the comments here or via Twitter.

感谢您的阅读。 如果您有任何疑问，或者需要有关Helm入门的帮助，请随时通过此处的评论或Twitter与我们联系 。

Happy Helming!

快乐的头盔！

Originally posted on Soluto’s Blog

最初发布在Soluto的博客上

翻译自: https://www.freecodecamp.org/news/how-can-we-simplify-deployment-of-containarized-apps-a2effd01a662/

程序部署到容器