库存变更 架构设计_有时变更是不好的:不可变的基础架构

库存变更 架构设计

介绍 (Introduction)

“Season of Scale” is a blog and video series to help enterprises and developers build scale and resilience into your design patterns. In this series we plan on walking you through some patterns and practices for creating apps that are resilient and scalable, two essential goals of many modern architecture exercises.

“规模的季节”是一个博客和视频系列,可帮助企业和开发人员将规模和适应性构建到您的设计模式中。 在本系列中,我们计划引导您完成一些模式和实践,以创建具有弹性和可扩展性的应用程序,这是许多现代体系结构练习的两个基本目标。

In Season 1, we’re covering Infrastructure Automation and High Availability:

在第1季中,我们将介绍基础架构自动化和高可用性:

  1. Patterns for scalable and resilient applications

    可伸缩和弹性应用程序的模式

  2. Infrastructure as code

    基础架构即代码

  3. Immutable infrastructure (this article)

    不变的基础架构 (本文)

  4. Where to scale your workloads

    在哪里扩展工作负载

  5. Globally autoscaling web services

    全局自动缩放Web服务

  6. High Availability (Autohealing & Auto updates)

    高可用性(自动修复和自动更新)

In this article I’ll walk you through the basics behind immutable infrastructure.

在本文中,我将向您介绍不可变基础结构背后的基础知识。

观看视频 (Check out the video)

评论 (Review)

We learned about Critter Junction, a multiplayer gaming company that’s gained massive popularity in the last few months. Online players can interact with one another in a virtual world that follows life simulation as a critter.

我们了解了多人游戏公司Critter Junction,该公司在最近几个月中获得了广泛的欢迎。 在线玩家可以在虚拟世界中相互交流,而虚拟世界将生命模拟为小动物。

Image for post

They were used to the classic approach to infrastructure creation, which was to manually provision it…which was timely and error prone. Luckily, they’ve since adopted infrastructure as code (IAC) to automate provisioning of cloud resources with code. They can create templates for reproducibility and store config files in a source version control. Now they’re looking to optimize their DevOps practices during upgrades, and follow best practices for ultimate scalability and auditability.

他们习惯于经典的基础架构创建方法,即手动配置它,这是及时且容易出错的。 幸运的是,他们此后采用了基础架构即代码 (IAC)来自动使用代码来配置云资源。 他们可以创建可重复性的模板,并将配置文件存储在源版本控制中。 现在,他们正在寻求在升级过程中优化DevOps的实践,并遵循最佳实践以实现最终的可扩展性和可审计性。

可变基础设施 (Mutable infrastructure)

Have you ever heard the phrase “Change is the only constant in life?” While that may be accurate for most things, you don’t want it to be true for your infrastructure.

您是否曾经听过“改变是生活中唯一不变的东西”这一短语? 尽管对于大多数事情来说这可能是正确的,但是您不希望它对您的基础架构是正确的。

“Mutable” means “capable of change”

“多变”是指“能够改变”

Mutable infrastructure means cloud resources that can be changed — the same server is used for updates, patches, and configuration changes. For our friends at Critter Junction, they started with virtual machines that hosted their web servers.

可变的基础架构意味着可以更改的云资源-同一服务器用于更新,补丁和配置更改。 对于我们在Critter Junction的朋友而言,他们从托管Web服务器的虚拟机开始。

Their VMs were originally designed to be mutable because of the short-term flexibility it gave them. Each VM could more precisely fit the apps that ran on it, and it was easy to run custom updates for each machine. The team often became attached to individual machines, which was occasionally useful if they needed to fix specific problems quickly.

他们的VM最初被设计为可变的,因为它赋予了它们短期的灵活性。 每个VM可以更精确地适合其上运行的应用程序,并且为每台计算机运行自定义更新很容易。 团队经常加入到单独的机器上,这在他们需要快速解决特定问题时偶尔会很有用。

For example, they ran a VM with NGINX and version 1 of their web server with data written locally. When they wanted to switch to Apache, it was easy for them to perform an upgrade on the server directly and run version 2.

例如,他们使用NGINX和Web服务器的版本1运行VM,并在本地写入数据。 当他们想要切换到Apache时,很容易直接在服务器上执行升级并运行版本2。

Image for post

On the surface this seems great. They were using an existing server and didn’t have to worry about moving the data around to other machines, or creating a new machine. But in the real world, things can go wrong. The Apache upgrade could have failed for a number of reasons, like networking issues. In their case, some of the servers updated quickly, while others got hung up on installation.

从表面上看,这似乎很棒。 他们使用的是现有服务器,而不必担心将数据移至其他计算机或创建新计算机。 但是在现实世界中,事情可能会出错。 Apache升级可能由于多种原因而失败,例如网络问题。 在他们的情况下,一些服务器快速更新,而另一些则挂断了安装。

Image for post

They were left with some servers running version 2 successfully, some that upgraded the app but couldn’t run it, and some servers that were still running version 1.Many of their VMs were failing in slightly different ways, and they were now facing:

他们留下了一些成功运行版本2的服务器,一些升级了应用程序但无法运行的服务器以及一些仍在运行版本1的服务器,其中许多VM的故障方式略有不同,现在面临的问题是:

  • Complexity with user traffic being routed to different running versions of their webserver

    将用户流量路由到其Web服务器的不同运行版本的复杂性
  • An inability to roll back to a previous version

    无法回滚到以前的版本
  • And undocumented update statuses, making it impossible to track versions

    以及未记录的更新状态,因此无法跟踪版本

不变的基础设施:更好的方法 (Immutable infrastructure: the better way)

Instead of changing each of their existing VMs, they should have changed their environment to be immutable.

他们应该更改其环境以使其不可变 ,而不是更改其每个现有的VM。

Once a VM is deployed, it can’t be modified: no updates, no patches, no configuration changes.

部署虚拟机后,将无法对其进行修改:无更新,无补丁,无配置更改。

If you want to change application code or apply a patch, you instead would build a new image and deploy it as a replacement. Because new environments can be spawned in the cloud in a matter of minutes, immutable infrastructure is easy to architect and deploy.

如果要更改应用程序代码或应用补丁,则可以构建一个新映像并将其部署为替代映像。 由于可以在几分钟内在云中产生新的环境,因此不可变的基础架构易于构建和部署。

拿2 (Take 2)

After some long hours restoring version 1 of their application, here’s how Critter Junction handled their next deployment. Instead of making changes in place to each machine, they created a brand new VM image with Apache and version 2 of their app and moved any locally written data to an attached persistent disk. After some testing to make sure the new image was working, they spun up multiple servers using the new image. Now they could safely switch traffic to their new VMs and shut down the instances running version 1.

在长时间的恢复他们的应用程序的版本1之后,这就是Critter Junction处理下一次部署的方式。 他们没有在每台计算机上进行更改,而是使用Apache和其应用程序的版本2创建了一个全新的VM映像,并将所有本地写入的数据移动到了连接的永久磁盘上。 经过测试以确保新映像正常工作后,他们使用新映像启动了多台服务器。 现在,他们可以安全地将流量切换到新的虚拟机,并关闭运行版本1的实例。

Image for post

On Google Cloud, it looked like this for their team:

在Google Cloud上,他们的团队看起来像这样:

  1. They used Cloud Build to set up continuous integration with their repository, automating building and testing.

    他们使用Cloud Build来建立与存储库的持续集成,从而自动化构建和测试。

  2. VMS were specified using image families, so they could have multiple versions of their images and deprecate the newest version if they needed to roll back.

    VMS是使用映像系列指定的,因此它们可以具有其映像的多个版本,并在需要回滚时不推荐使用最新版本。

  3. And, they specified all of their resources using Cloud Deployment Manager in order to automatically provision it.

    并且,他们使用Cloud Deployment Manager指定了所有资源,以便自动进行配置。

容器呢? (What about containers?)

It’s the same pattern when working with containers: create a complete runtime environment and deliver that as an image. With containers, the run time environment is a program and the files it needs to run. With immutable infrastructure, you’re delivering a whole operating system configured as needed, along with the programs and their files. In both cases you continuously deliver versioned images.

使用容器时,这是相同的模式:创建一个完整的运行时环境并将其作为映像提供。 对于容器,运行时环境是一个程序及其需要运行的文件。 借助不变的基础架构,您将交付根据需要配置的整个操作系统以及程序及其文件。 在这两种情况下,您都持续交付版本化的映像。

Image for post

结论 (Conclusion)

Creating immutable infrastructure gave Critter Junction protection from configuration drift, since they now know the exact state of their machines and can avoid any unexpected surprises. In addition, they can now easily track versions, roll back releases, and have a more consistent testing process thanks to the documented differences between their environments. Immutable infrastructure might sound at odds with an agile architecture. But in reality, it gives you agility because you know the specifics and code status for every resource in your environment. Stay tuned to find out what’s in store for Critter Junction.

创建不可变的基础结构为Critter Junction提供了防止配置漂移的保护,因为他们现在知道机器的确切状态,并且可以避免任何意外的意外。 此外,由于记录的环境之间的差异,他们现在可以轻松地跟踪版本,回滚发行版,并具有更一致的测试过程。 不变的基础架构可能与敏捷架构不一致。 但实际上,它为您提供了灵活性,因为您知道环境中每种资源的详细信息和代码状态。 请继续关注,以了解Critter Junction的内容。

And remember, always be architecting.

记住,永远是建筑师。

后续步骤和参考: (Next steps and references:)

翻译自: https://medium.com/google-cloud/sometimes-change-is-bad-immutable-infrastructure-624a8e3482d6

库存变更 架构设计

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值