项目部署时网关怎么回事_使用Kubernetes部署聊天网关（或技术按预期运行时）...

项目部署时网关怎么回事

by Richard Li

理查德·李(Richard Li)

使用Kubernetes部署聊天网关(或技术按预期运行时) (Using Kubernetes to deploy a chat gateway (or when technology works like it’s supposed to))

TL; DR (TL;DR)

This is a story about what happens when cloud technologies work like they’re supposed to. In this case, the technologies are Docker and Kubernetes.

这是一个有关云技术按预期工作时会发生什么的故事。 在这种情况下，技术是Docker和Kubernetes。

介绍 (Introduction)

At Datawire, we use Gitter so that users of our open source tools can chat with us (and each other). We like Gitter because it’s low friction to join, especially if you have a GitHub or Twitter account. However, Gitter’s mobile client isn’t great, and the notifications in general don’t work well.

在Datawire ，我们使用Gitter，以便开放源代码工具的用户可以与我们(以及彼此)聊天。 我们之所以喜欢Gitter是因为加入的摩擦很小，特别是如果您拥有GitHub或Twitter帐户。 但是，Gitter的移动客户端不是很好，并且通知通常不能很好地工作。

Since migrating a community of users is a fair bit of work, I decided to see if I could deploy a bridge between Slack (what we use internally) and our Gitter chat. A little bit of Googling led me to Matterbridge.

由于迁移用户社区是一项相当大的工作，因此我决定看看是否可以在Slack(我们在内部使用)和Gitter聊天之间搭建桥梁。 有点谷歌搜索使我到马特布里奇 。

In the rest of the article, I’ll walk through how Docker and Kubernetes actually made my life easier, and why. I found the amount of yak shaving required to be remarkably small … which made me really appreciate how far we’ve come in the cloud world.

在本文的其余部分，我将逐步介绍Docker和Kubernetes如何使我的生活更轻松，以及为什么。 我发现所需的牛剃须量非常少……这使我非常感谢我们在云计算世界中所取得的成就。

Docker很棒 (Docker is great)

I wanted to run Matterbridge locally to debug the configuration. I followed the general instructions on creating accounts for Slack and Gitter, and then put the necessary authentication tokens into a matterbridge.toml file.

我想在本地运行Matterbridge来调试配置。 我按照有关为Slack和Gitter创建帐户的一般说明进行操作，然后将必要的身份验证令牌放到matterbridge.toml文件中。

I was happy to see how Matterbridge is available as a Docker image, so I was able to just copy my configuration file into the Docker image to test out the configuration. All I needed to do was to specify my configuration file when using docker run:

我很高兴看到Matterbridge如何作为Docker映像提供，因此我能够将配置文件复制到Docker映像中以测试配置。 我需要做的就是在使用docker run时指定我的配置文件：

docker run -ti -v /tmp/matterbridge.toml:/matterbridge.toml 42wim/matterbridge

I had to make a few turns of this to debug my configuration, but it was quick and easy. The Docker image did exactly what it’s supposed to do: provide a tested runtime environment for Matterbridge so I didn’t have to debug it on my laptop.

我不得不进行一些操作来调试我的配置，但是它既快速又容易。 Docker镜像完全按照预期的方式运行：为Matterbridge提供经过测试的运行时环境，因此我不必在笔记本电脑上对其进行调试。

在云端运行 (Running in the cloud)

The next step was to deploy my configuration to the cloud. We already run a production Kubernetes cluster fronted by an API Gateway powered by Envoy, so I wanted to deploy the service into its own namespace.

下一步是将我的配置部署到云中。 我们已经运行了一个生产的Kubernetes集群，该集群以Envoy为首的API网关为前端，因此我想将服务部署到它自己的名称空间中。

To deploy to Kubernetes, I wrote a simple Dockerfile:

为了部署到Kubernetes，我编写了一个简单的Dockerfile：

FROM 42wim/matterbridge:1.9.0ADD matterbridge.toml .CMD ["/bin/matterbridge"]

Then, all I needed was a Kubernetes manifest.

然后，我只需要一个Kubernetes清单。

Kubernetes (Kubernetes)

In my Kubernetes manifest, I’m able to specify a bunch of key information about the service:

在我的Kubernetes清单中，我可以指定有关该服务的一系列关键信息：

• My update strategy, RollingUpdate

  我的更新策略， RollingUpdate

• The minimum and maximum amount of CPU and memory to allocate
  要分配的最小和最大CPU和内存量
• The number of replicas of the service
  服务的副本数

Here is my basic manifest:

这是我的基本清单：

---apiVersion: apps/v1beta1kind: Deploymentmetadata:  name: {{build.name}}  namespace: {{service.namespace}}spec:  replicas: 1  strategy:    type: RollingUpdate  template:    metadata:      labels:        app: {{build.name}}    spec:      containers:      - name: {{build.name}}        image: {{build.images["Dockerfile"]}}        imagePullPolicy: IfNotPresent        resources:          requests:            memory: 0.1G            cpu: 0.1          limits:            memory: {{service.max_memory}}            cpu: {{service.max_cpu}}

(Note that I’m using Forge to template and manage the service, so this is a templated Kubernetes manifest).

(请注意，我正在使用Forge来模板化和管理服务，所以这是一个模板化的Kubernetes清单)。

With this manifest, I was able to get my service up and running in Kubernetes.

有了这个清单，我就能在Kubernetes中启动并运行我的服务。

我在Git的Matterbridge服务 (My Matterbridge Service in Git)

In summary, my service consists of:

总而言之，我的服务包括：

• A Dockerfile
  Dockerfile
• A (templated) Kubernetes manifest
  (模板化的)Kubernetes清单

• A matterbridge.toml configuration file

  matterbridge.toml配置文件

all of which I was able to check into a Git repository.

所有这些我都能够检入Git存储库。

前Kubernetes世界 (The pre-Kubernetes world)

The ease with which I was able to get a service reliably made me reflect on how I would have done this in the VM-days. I would’ve had to:

我能够轻松获得可靠的服务使我反思了在VM时代应该如何做到这一点。 我将不得不：

• Provision a VM (and/or create an auto-scaling group)
  设置VM(和/或创建自动伸缩组)
• Install the necessary runtime dependencies on the VM via some bash script hackery (or use Ansible, or build a custom AMI)
  通过一些bash脚本黑客在虚拟机上安装必要的运行时依赖项(或使用Ansible或构建自定义AMI)
• Copy my configuration to the VM
  将我的配置复制到VM

Moreover, if I wanted to make the above reproducible, I would have had to use Terraform, Ansible, CloudFormation, or one of these types of tools. Here is the example from the Terraform documentation on how to create an EC2 instance:

而且，如果我想使上述内容可重复，则必须使用Terraform，Ansible，CloudFormation或这些类型的工具之一。 这是Terraform文档中有关如何创建EC2实例的示例 ：

# Create a new instance of the latest Ubuntu 14.04 on an# t2.micro node with an AWS Tag naming it "HelloWorld"provider "aws" {  region = "us-west-2"}data "aws_ami" "ubuntu" {  most_recent = true  filter {    name   = "name"    values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]  }  filter {    name   = "virtualization-type"    values = ["hvm"]  }  owners = ["099720109477"] # Canonical}resource "aws_instance" "web" {  ami           = "${data.aws_ami.ubuntu.id}"  instance_type = "t2.micro"  tags {    Name = "HelloWorld"  }}

As a developer, many of the options above (region, instance type) are things that I don’t really care about. Yet, this is the current abstraction if I want to commit infrastructure-as-code.

作为开发人员，上面的许多选项(区域，实例类型)都是我并不真正关心的事情。 但是，如果要提交基础结构代码，这是当前的抽象。

摘要 (Summary)

Kubernetes is more than just a container scheduler. It really gives you the primitives you need to control how your service gets run, without bogging you down in the details of deployment. We’re definitely embracing the mentality of having a small team of ops folks manage the Kubernetes cluster, while the rest of the development team just manages their services via the Kubernetes primitives.

Kubernetes不仅仅是一个容器调度程序。 它确实为您提供了控制服务运行方式所需的原语，而不会使您陷入部署细节中。 我们确实拥抱有一个小团队OPS的人管理Kubernetes集群的心态，而开发团队的其他成员通过Kubernetes元只是管理他们的服务。

While it’s not always sunshine and roses in Kubernetes-land, in my case of deploying Matterbridge, it was. You’ll have to wait for another article to read about challenges!

虽然在Kubernetes-land并不总是阳光和玫瑰花，但在我部署Matterbridge的情况下却是。 您必须等待另一篇文章来阅读有关挑战的信息！

翻译自: https://www.freecodecamp.org/news/using-kubernetes-to-deploy-a-chat-gateway-or-when-technology-works-like-its-supposed-to-a169a8cd69a3/

项目部署时网关怎么回事