|
两年前我写过一篇文章（https://www./2015/07/under-the-hood-of-the-amazon-ec2-container-service.html），介绍了亚马逊ECS底层的细节。 我们在去年的re:Invent大会上推出了AWS Fargate，今天我想探讨Fargate如何从根本上改变容器技术的格局。 我平时花大量的时间跟我们的客户和亚马逊的高管谈论创新。我注意到的一个方面是，急剧改变我们行事方式的想法和技术很少是新的。它们常常将现有概念与某种方法、技术或能力以之前尝试从未成功的特定方式结合起来。 容器在过去的四年迅速得到了采用，这归因于旧技术（容器）与新的工具链和工作流程（即Docker）还有云计算结合起来。在我们行业，四年时间不算短，但我认为我们只是刚开始探究代码包装、设计良好的工作流程以及云计算这个组合如何能重塑开发人员迅速构建应用程序、进行创新的能力。 容器解决了一个基本的代码可移植性问题，并支持云端新的基础设施模式。有一种一致的、不可变的部署单元可供使用，每当你更改代码或想要在不同的地方运行应用程序，都可以将配置服务器和部署管道的种种复杂性抽取出来。但容器也在你的代码与代码运行的地方之间添加了另一层。我们希望能够编写代码，让代码在合适的地方运行，有合适的规模，与其他代码有合适的连接，并且落实合适的安全和访问控制措施，而容器是这条道路上的一个重要但渐进的步骤。 解决跨各种环境部署、调度和连接容器的这些更高层的问题为我们提供了容器管理工具。在我看来，容器编排总是似乎不是非常云原生。管理大型服务器集群，并优化调度都由复杂的分布式状态存储系统支持的容器，这有悖于云计算的前提。客户选择云是为了可以按需付费（payas they go），没必要乱猜容量，在不给运营部门添加负担的情况下获得深入的运营控制，构建耗散耦合的服务（其爆炸半径有限，以防止故障），以及针对运行代码所需的各种资源实现自助服务。 你应该能够编写代码并让它运行，不必为配置复杂的管理工具（无论是不是开源工具）而操心。这就是AWS Fargate的愿景。有了Fargate，你不需要搭建控制平面，选择合适的实例类型，或配置应用程序堆栈的所有其他部分，比如网络、扩展、服务发现、负载均衡，安全组、权限或密钥管理。你只需要构建容器镜像，定义希望它如何运行、在何处运行，并为实际需要的资源付费。Fargate天生与AmazonVPC、自动扩展（Auto Scaling）、弹性负载均衡（ELB）、身份及访问管理（IAM）角色和密钥管理集成起来。我们花了不少时间让Farget随时可用于生产环境，制定了确保正常运行时间达到99.99%的服务级别协议（SLA），符合支付卡行业数据安全标准（PCI）、服务组织控制（SOC）、ISO和《健康保险可携性及责任性法案》（HIPAA）等法规或标准。 借助AWS Fargate，你可以配置资源，以相比EC2实例精细得多的方式运行容器。你可以精确选择代码所需的那种CPU和内存，你支付的金额与运行的容器数量完全一致。不必乱猜处理峰值流量的容量，还能获得精准规模的好处，让你可以将大量的运营任务卸载到云上。同样就MiB而言，这可能意味着像Fargate这样的云原生技术表面上比更传统的虚拟机基础设施来得昂贵。但是如果你看一看运行应用程序的全部成本，我们认为大多数应用程序使用Fargate会来得更便宜，因为你只要为需要的资源付费。运行Fargate的那些客户看到保持应用程序顺畅运行所需的开发时间大幅节省。 容器编排解决方案组成的整个生态系统的出现有其必然性，因为没有方法直接获取云端容器。无论你使用Kubernetes、Mesos、Rancher、Nomad、ECS还是其他任何系统，这不再重要了，因为有了Fargate，没有什么要编排的。唯一要管理的是应用程序本身的构建。AWS Fargate终于让容器成为云原生。 我认为，之前我们着眼于底层基础设施，我们将看到的下一个创新领域是应用程序和服务管理。你如何把运行独立服务的不同容器互连起来，确保可见性，管理流量模式，以及在大规模环境下确保多项服务的安全？独立服务如何相互发现对方？你如何定义对通用数据存储系统的访问？你如何定义服务，将服务分组到应用程序中？云原生旨在获得尽可能大的控制权，我很想看看容器生态系统在未来几年内如何发展，让你拥有更大的控制权。我们期望与社区合作，代表我们的客户不断创新，从而在云原生道路上不断前进。 AWS Fargate已经与Amazon ECS无缝整合。你只要定义应用程序，就像为Amazon ECS定义应用程序那样。将应用程序包装成任务定义，指定所需的CPU和内存，定义每个容器需要的网络和IAM策略，然后将所有内容上传到Amazon ECS。各方面到位后， AWS Fargate就会启动，为你管理容器。 AWS Fargate支持亚马逊EKS（弹性Kubernetes服务）的功能将于2018年晚些时候推出。 以下为英文原文（供参考）： Changing the calculus of containers in the cloud I wrote to you over two years ago about what happens under the hood of Amazon ECS. Last year at re:Invent, we launched AWS Fargate, and today, I want to explore how Fargate fundamentally changes the landscape of container technology. I spend a lot of time talking to our customers and leaders at Amazon about innovation. One of the things I've noticed is that ideas and technologies which dramatically change the way we do things are rarely new. They're often the combination of an existing concept with an approach, technology, or capability in a particular way that's never been successfully tried before. The rapid embrace of containers in the past four years is the result of blending old technology (containers) with a new toolchain and workflow (i.e., Docker), and the cloud. In our industry, four years is a long time, but I think we've only just started exploring how this combination of code packaging, well-designed workflows, and the cloud can reshape the ability of developers to quickly build applications and innovate. Containers solve a fundamental code portability problem and enable new infrastructure patterns on the cloud. Having a consistent, immutable unit of deployment to work with lets you abstract away all the complexities of configuring your servers and deployment pipelines every time you change your code or want to run your app in a different place. But containers also put another layer between your code and where it runs. They are an important, but incremental, step on the journey of being able to write code and have it run in the right place, with the right scale, with the right connections to other bits of code, and the right security and access controls. Solving these higher order problems of deploying, scheduling, and connecting containers across environments gave us container management tools. Container orchestration has always seemed to me to be very not cloud native. Managing a large server cluster and optimizing the scheduling of containers all backed by a complex distributed state store is counter to the premise of the cloud. Customers choose the cloud to pay as they go, not have to guess capacity, get deep operational control without operational burden, build loosely coupled services with limited blast radii to prevent failures, and self-service for everything they need to run their code. You should be able to write your code and have it run, without having to worry about configuring complex management tools, open source or not. This is the vision behind AWS Fargate. With Fargate, you don't need to stand up a control plane, choose the right instance type, or configure all the other components of your application stack like networking, scaling, service discovery, load balancing, security groups, permissions, or secrets management. You simply build your container image, define how and where you want it to run, and pay for the resources you need. Fargate has native integrations to Amazon VPC, Auto Scaling, Elastic Load Balancing, IAM roles, and Secrets Management. We've taken the time to make Fargate production ready with a 99.99% uptime SLA and compliance with PCI, SOC, ISO, and HIPAA. With AWS Fargate, you can provision resources to run your containers at a much finer grain than with an EC2 instance. You can select exactly the CPU and memory your code needs and the amount you pay scales exactly with how many containers you run. You don't have to guess at capacity to handle spikey traffic, and you get the benefit of perfect scale, which lets you offload a ton of operational effort onto the cloud. MiB for MiB, this might mean that cloud native technologies like Fargate look more expensive than more traditional VM infrastructure on paper. But if you look at the full cost of running an app, we believe most applications will be cheaper with Fargate as you only pay what you need. Our customers running Fargate see big savings in the developer hours required to keep their apps running smoothly. The entire ecosystem of container orchestration solutions arose out of necessity because there was no way to natively procure a container in the cloud. Whether you use Kubernetes, Mesos, Rancher, Nomad, ECS or any other system no longer matters anymore because with Fargate, there is nothing to orchestrate. The only thing that you have to manage is the construction of the applications themselves. AWS Fargate finally makes containers cloud native. I think the next area of innovation we will see after moving away from thinking about underlying infrastructure is application and service management. How do you interconnect the different containers that run independent services, ensure visibility, manage traffic patterns, and security for multiple services at scale? How do independent services mutually discover one another? How do you define access to common data stores? How do you define and group services into applications? Cloud native is about having as much control as you want and I am very excited to see how the container ecosystem will evolve over the next few years to give you more control with less work. We look forward to working with the community to innovate forward on the cloud native journey on behalf of our customers. Getting Started AWS Fargate already seamlessly integrates with Amazon ECS. You just define your application as you do for Amazon ECS. You package your application into task definitions, specify the CPU and memory needed, define the networking and IAM policies that each container needs, and upload everything to Amazon ECS. After everything is setup, AWS Fargate launches and manages your containers for you. AWS Fargate support for Amazon EKS, the Elastic Kubernetes Service, will be available later in 2018。 来源：云头条 |
|
|
