heroku_将kubernetes全栈应用程序转换为heroku容器

heroku

In the last several years, Google’s Kubernetes project has generated huge buzz. The project has grown and evolved into a titan of the cloud infrastructure world.

在过去的几年中，谷歌的Kubernetes项目引起了极大的轰动。 该项目已经成长为云基础设施领域的巨人。

While it’s a great project and serves many purposes, it remains a complex beast. Even with the managed Kubernetes services from major cloud providers, teams have to maintain complex, interwoven architectures using an ever-expanding cosmos of plugins and paradigm shifts. With such complexity inherent with its flexibility, Kubernetes requires its own set of skills in order to implement, maintain, upgrade, and operate this diverse orchestration ecosystem.

尽管这是一个伟大的项目，可以满足许多目的，但它仍然是一个复杂的野兽。 即使使用主要云提供商的托管Kubernetes服务，团队也必须使用不断扩展的插件和范式转换来维护复杂的交织架构。 凭借其灵活性固有的复杂性，Kubernetes需要具备一套自己的技能，才能实施，维护，升级和操作这个多样化的编排生态系统。

PaaS的简单性 (The Simplicity of PaaS)

These intensive, skill-based requirements may be appropriate for some business models. However, if you want to spend your time building applications rather than managing servers and security, then you may want to consider a Platform as a Service (PaaS) rather than Kubernetes. These providers maintain the infrastructure, security, observability, and overall well-being of the environment so you can focus on the business-critical applications.

这些密集的，基于技能的要求可能适用于某些业务模型。 但是，如果您想花时间构建应用程序而不是管理服务器和安全性，那么您可能要考虑使用平台即服务(PaaS)而不是Kubernetes。 这些提供者维护环境的基础结构，安全性，可观察性和整体状态，因此您可以专注于关键业务应用程序。

One of the draws of Kubernetes is its capability to provide a uniform environment experience. An application built to fit within Kubernetes should be portable by design, ephemeral in nature, and able to live in any container-driven world, agnostic to the infrastructure (take a look at Twelve Factor Apps for more guidelines on building apps). So if an application team wanted to leave behind the complexity of a Kubernetes managed infrastructure in favor of curated PaaS, what would that look like?

Kubernetes的吸引力之一是其提供统一环境体验的能力。 构建为适合Kubernetes的应用程序应设计为可移植的，本质上是短暂的，并且可以生活在任何容器驱动的世界中，而与基础架构无关(请参阅十二因子应用程序，以获取有关构建应用程序的更多指南)。 因此，如果应用程序团队希望抛弃Kubernetes托管基础架构的复杂性，而采用策展的PaaS，那会是什么样子？

Today we’ll take a look at this simple Kubernetes driven Flask application. We’ll see how it runs, learn its requirements, and explore how we can convert it to Heroku.

今天，我们将看一下这个简单的Kubernetes驱动的Flask应用程序。 我们将看到它的运行方式，了解其需求，并探索如何将其转换为Heroku 。

应用设计 (The Application Design)

This application is a simple Flask frontend that pulls a list of actors from a Postgres database then displays them on a web site. As you can see, the infrastructure to monitor, log, serve, and generally provide up-time make up even more components than the app itself.

该应用程序是一个简单的Flask前端，可从Postgres数据库中提取演员列表，然后将其显示在网站上。 如您所见，与应用程序本身相比，用于监视，记录，提供服务并通常提供正常运行时间的基础结构构成的组件甚至更多。

To deploy the application in Kubernetes we need the pre-requisite infrastructure components, several YAMLs for the application itself, and a Helm chart for the database.

为了在Kubernetes中部署应用程序，我们需要必备的基础架构组件，针对应用程序本身的多个YAML和针对数据库的Helm图表。

• GitLab CI/CD

  亚搏体育app CI / CD

• Ambassador Edge Stack

  边缘大使

• LinkerD Service Mesh

  LinkerD服务网

• FluentD Log Collector

  FluentD日志收集器

• Elasticsearch Document Database

  Elasticsearch文档数据库

• Certificate Generation

  证书生成

• Ingress Definition

  入口定义

• Exposed Ports & Application Deployment

  公开的端口和应用程序部署

• PostgreSQL Helm Customizations

  PostgreSQL头盔定制

• And finally the application itself

  最后是应用程序本身

There are a lot of necessary steps just to get the application serviceable. Let’s look at the comparable requisites in Heroku.

为了使应用程序可服务，有很多必要的步骤。 让我们看一下Heroku中类似的要求。

Because the PaaS vendor has made the technology decisions for you, you do have to abide by that vendor’s decisions and opinions. However, in return you get tightly-integrated service offerings that work out of the box. What previously took weeks of research and implementation of service meshes and logging exporters has been reduced to just minutes and a few commands.

因为PaaS供应商已经为您做出了技术决策，所以您必须遵守该供应商的决策和意见。 但是，作为回报，您可以获得开箱即用的紧密集成的服务产品。 以前花了数周时间研究和实现服务网格和日志记录导出程序的时间已减少到只有几分钟和几个命令。

To deploy the same application in Heroku, we just need two steps: spin up the database and the application.

要在Heroku中部署相同的应用程序，我们只需要两个步骤：启动数据库和应用程序。

Now let’s look at how we would convert this application from Kubernetes to Heroku. We’ll look at four steps:

现在让我们看一下如何将该应用程序从Kubernetes转换为Heroku。 我们将看四个步骤：

1. Set up the infrastructure
   建立基础架构
2. Convert the application
   转换应用
3. Deploy the app
   部署应用
4. Update the app
   更新应用

1.建立基础架构(1. Setting Up the Infrastructure)

We saw the many components for Kubernetes that are necessary to ensure operability in prod. Each of these come with an install guide and recommendations, but the pattern is usually very similar:

我们看到了Kubernetes的许多组件，这些组件是确保产品可操作性所必需的。 这些都附带安装指南和建议，但是模式通常非常相似：

1. Download the control binaries.
   下载控制二进制文件。
2. Validate kubectl can reach the appropriate clusters.
   验证kubectl是否可以到达适当的群集。

3. kubectl apply -f https://dependency/spec.yaml or use the binary to create resources.

   kubectl apply -f https：//dependency/spec.yaml或使用二进制文件创建资源。

4. Verify deployment completed in appropriate security contexts and is functioning as desired.
   验证部署是否在适当的安全上下文中完成并且是否按预期运行。

Heroku’s requirements are much more straightforward: Make an account, download the heroku cli, and you’re done! Remember that a big draw to PaaS is that the validation and install (all those steps you had to do yourself with Kubernetes) are already done for you.

Heroku的要求更加简单：注册一个帐户，下载heroku cli，就完成了！ 请记住，使用PaaS的一大好处就是验证和安装(您必须使用Kubernetes完成的所有步骤)已经为您完成。

These steps provide the core infrastructure services for your app in either environment, such as TLS and traffic management, scaling, observability, and repeatability.

这些步骤可在任一环境中为您的应用程序提供核心基础结构服务，例如TLS和流量管理，扩展，可观察性和可重复性。

2.转换应用程序 (2. Converting the Application)

Now that we have established how each of the environments look for our sample app, we can look at how we need to tweak the application to work in its new PaaS home. Because many of the components have been implemented on our behalf, there is some necessary transforming before we can deploy the app.

现在，我们已经确定了每种环境如何寻找示例应用程序，接下来我们可以了解如何调整应用程序使其在新的PaaS主页中工作。 由于许多组件都是以我们的名义实现的，因此在部署应用程序之前需要进行一些必要的转换。

These steps will ensure that we can deploy the application as a container, view application logs in stdout, remotely log into the container during runtime, and customize parameters for the application from the infrastructure.

这些步骤将确保我们可以将应用程序部署为容器，在stdout中查看应用程序日志，在运行时远程登录到容器以及从基础结构中为应用程序自定义参数。

First, we have to change the Dockerfile. For our Kubernetes Dockerfile that defines our application at init time, we were largely free to design it as we wish:

首先，我们必须更改Dockerfile。 对于在初始化时定义应用程序的Kubernetes Dockerfile，我们可以根据需要自由地设计它：

FROM python:3WORKDIR /usr/src/appCOPY requirements.txt ./RUN pip install — no-cache-dir -r requirements.txtRUN touch /tmp/healthy && echo “healthy” >> /tmp/healthy && cat /tmp/healthyENV FLASK_ENV=developmentENV FLASK_APP=myapp.pyCOPY myapp.py .CMD [ “flask”, “run”, “ — host=0.0.0.0” ]

The image is simple: use a maintained base image, set a work directory, add the python requirements, set some default environment variables, add the application code, and start the server.

该映像很简单：使用维护的基本映像，设置工作目录，添加python要求，设置一些默认环境变量，添加应用程序代码并启动服务器。

In a later step we’ll use this Dockerfile to build our application, push it to a Docker registry, and have Kubernetes pull the image to its local servers to start the app.

在下一步中，我们将使用此Dockerfile来构建应用程序，将其推送到Docker注册表，并让Kubernetes将映像拉至其本地服务器以启动该应用程序。

In Heroku, due to our desire to use Python-specific base images, we have to add a few packages for Heroku’s container management interfaces. Our new Dockerfile looks like this:

在Heroku中，由于我们希望使用特定于Python的基本映像，因此我们必须为Heroku的容器管理接口添加一些软件包。 我们的新Dockerfile如下所示：

FROM python:3WORKDIR /usr/src/appCOPY requirements.txt ./RUN pip install — no-cache-dir -r requirements.txtRUN apt-get update && \   apt-get install -y \   curl \   openssh-serverADD ./.profile.d /app/.profile.dRUN rm /bin/sh && ln -s /bin/bash /bin/shRUN echo “healthy” >> /tmp/healthy && \   cat /tmp/healthyENV FLASK_ENV=developmentENV FLASK_APP=myapp.pyCOPY myapp.py .CMD python3 myapp.py

Here we’re defining the same image as before, but with a few tweaks.

在这里，我们定义的图像与以前相同，但有一些调整。

• First, we have a new apt-get series of installations to add curl & ssh to our image. We also add a script (heroku-exec.sh) to define the ssh environment:
  首先，我们有一个新的apt-get系列安装，可以在图像中添加curl和ssh。 我们还添加了一个脚本(heroku-exec.sh)来定义ssh环境：

[ -z "$SSH_CLIENT" ] && source <(curl --fail --retry 3 -sSL "$HEROKU_EXEC_URL")

[ -z "$SSH_CLIENT" ] && source <(curl --fail --retry 3 -sSL "$HEROKU_EXEC_URL")

• Then, we have to explicitly declare our default shell by linking /bin/bash to /bin/sh.
  然后，我们必须通过将/ bin / bash链接到/ bin / sh来显式声明我们的默认shell。
• Next, we have to change the way the image is instantiated by specifying the flask runtime parameters in the myapp.py file so that we may use Heroku-defined environment variables to allow the app to take traffic once deployed.
  接下来，我们必须通过在myapp.py文件中指定flask运行时参数来更改图像实例化的方式，以便我们可以使用Heroku定义的环境变量来允许应用程序在部署后进行流量。

if __name__ == “__main__”:   port = int(os.getenv(“PORT”, 5000))   app.run(debug=True, host=’0.0.0.0', port=port)

One final consideration is the database. With Kubernetes we can utilize its fungible capacity to host clustered or replicated databases to protect against corruption or node failure. We must use a Helm chart, design the database architecture from scratch, or use an external hosting solution for our database.

最后要考虑的是数据库。 借助Kubernetes，我们可以利用其可替代的功能托管集群或复制的数据库，以防止损坏或节点故障。 我们必须使用Helm图表，从头开始设计数据库体系结构，或者为我们的数据库使用外部托管解决方案。

However, this isn’t necessary when using hosted services. With Heroku, we simply need to add the hosted database via our dashboard. The replication and resiliency become the provider’s concern to manage.

但是，使用托管服务时不需要这样做。 使用Heroku，我们只需要通过仪表板添加托管数据库。 复制和弹性成为提供商管理的关注点。

(Remember that in both database implementations, replication and resiliency are not replacements for tested backups! Always backup and validate your core data.)

(请记住，在这两种数据库实现中，复制和弹性都不是经测试的备份的替代品！请始终备份和验证核心数据。)

With this, we have our application container images and databases ready to be deployed.

这样，我们就可以部署应用程序容器映像和数据库了。

3.运行应用程序 (3. Running the Application)

Assuming we have the core infrastructure installed, the databases provisioned for our cluster, and appropriate role-based access control (RBAC) configurations associated with our service accounts, we can now focus on the application deployment.

假设我们已经安装了核心基础结构，为集群配置的数据库以及与我们的服务帐户关联的适当的基于角色的访问控制(RBAC)配置，我们现在可以集中精力进行应用程序部署。

We do not have an explicit CI/CD pipeline defined in our example. So to manually deploy our application to Kubernetes we must do the following using the kubectl binary:

我们的示例中没有定义明确的CI / CD管道。 因此，要将应用程序手动部署到Kubernetes，我们必须使用kubectl二进制文件执行以下操作：

docker logindocker build -t myorg/myapp:0.0.1 -t myorg/myapp:latest .docker push myorg/myapp:0.0.1; docker push myorg/myapp:latestkubectl apply -f ./spec/

As we can see, once we deploy the core infrastructure and validate the YAMLs, it’s not that hard to manually roll code to our Kubernetes clusters.

如我们所见，一旦我们部署了核心基础架构并验证了YAML，那么将代码手动滚动到我们的Kubernetes集群就不那么困难了。

By taking a look at Heroku’s deployment scheme, we have their own custom binary with which we can interact with their APIs.

通过查看Heroku的部署方案，我们有自己的自定义二进制文件，可以与它们的API进行交互。

heroku loginheroku container:loginheroku container:push web -a myappheroku container:release web -a myapp

Here we trust Heroku’s tagging and deployment of our applications rather than employ our own tagging and release functionality — though it is largely the same amount of manual release rigor.

在这里，我们信任Heroku对应用程序的标记和部署，而不是采用我们自己的标记和发布功能-尽管它与手动发布的严格程度基本相同。

It’s also fair to call out that deployment and release pipelines built into either platform may entirely obfuscate all this effort; however, that, too, must be designed, built, and maintained in either environment.

公平地讲，内置在两个平台中的部署和发布管道可能会完全混淆所有这些工作； 但是，也必须在任何一种环境中进行设计，构建和维护。

At this point, we have defined processes for deploying the applications in both environments.

至此，我们已经定义了在两种环境中部署应用程序的过程。

4.更新应用程序 (4. Updating the Application)

When deploying an already existing application into Kubernetes, you would use a different command rather than apply:

在将现有应用程序部署到Kubernetes时，您将使用其他命令而不是apply ：

docker build -t myorg/myapp:0.0.2 -t myorg/myapp:latest .kubectl rollout deployment/myapp -n myapp --record --image=myapp:0.0.2

With Heroku we simply follow the same process again:

使用Heroku，我们只需再次遵循相同的过程即可：

heroku container:push web -a myappheroku container:release web -a myapp

With this last step, we have a process to iteratively deploy our application to our environments.

通过最后一步，我们有了一个将应用程序迭代部署到环境中的过程。

结论 (Conclusion)

Shakespeare wrote “A rose by any other name would smell as sweet.” Similarly our application works the same as it would in any containerized environment, Capulet or Montague, since it’s not the application itself that has to conform but rather its surroundings.

莎士比亚写道：“任何其他名字的玫瑰都会闻起来很甜。” 同样，我们的应用程序的工作原理与任何容器化环境(Capulet或Montague)相同，因为不是必须遵循应用程序本身，而是其周围环境。

Outside of our cheesy analogy, we explored what a simple application requires to run in the complex and highly customizable Kubernetes environments, as well as what is required to get the same level of functionality from Heroku, our managed infrastructure provider. In the end, both were simple to deploy to and run with, but Heroku proved to be much less intensive in its prerequisites to get started.

除了俗气的类比之外，我们还探讨了在复杂且可高度自定义的Kubernetes环境中运行简单应用程序所需的内容，以及从托管基础架构提供商Heroku获得相同级别功能所需的内容。 最后，两者都很容易部署和运行，但是事实证明，Heroku入门的先决条件不那么复杂。

翻译自: https://levelup.gitconnected.com/converting-a-kubernetes-fullstack-application-to-heroku-containers-f8de25e2ac09

heroku