Azure Service Fabric是否与Docker相同？ [英] Does Azure Service Fabric do the same thing as Docker?

问题描述

我的想法是，人们使用Docker来确保本地环境与生产相同，我可以停止思考他们的应用程序在哪里运行，平衡机制应该在最佳位置分配应用程序。 / p>

我是100％的网络，我将与我们的数据库一起移动到云端，什么不能移动将无缝桥接，所以企业的东西和云将成为一个子网络。

所以我想知道，或许Service Fabric已经做了与Docker一样的事情，加上它作为地址转换服务（fabric：/ /对于织物空间中的进程有一点像DNS）加上（对于一些重要的）鼓励按需工作者分配 - 巨大的可扩展性perk。

1. Can Service Fabric可以成功地替代Docker吗？


2. 是否获得观众和受理？因为否则甚至最大的发明可能会失败。

解决方案

这是令人困惑的，因为Docker（公司）正在试图在一切云中争夺权利。

• Docker Engine（大多数人称之为Docker）是集装箱化技术。
  
  
  
  
  • 进程隔离
  
  
  • 网络隔离
  
  
  • 一致的应用程序环境
  
  


• Docker Hub 是一个图像注册表。它存储Docker图像，以便您可以在部署过程中下载它们。


• Docker Cloud 是Docker的业务流程系统。
  
  
  
  
  • 上下调整应用程序
  
  
  • 将应用程序彼此连接
  
  
  • 与Docker Hub集成的CI测试（这不是编排的一部分，只是另一件事）
  
  






服务Fabric是一个编排系统。它可以协调Docker容器，但如果您专门为Fabric构建，它也可以更紧密地与您的服务集成。 （Docker对于容器内运行是完全不可知的。）





所以服务结构大部分与Docker Cloud相当，尽管它不是一个确切的比赛。还有一些其他基于Docker的编排解决方案（Kubernetes可能是最大的），还有其他基于云的微服务解决方案（Heroku可能是最知名的）。





服务架构的主要缺点是它是一种Microsoft技术，因此您将会比运行Docker的程度更大程度上与Azure绑定。另一个是Docker有更广泛的选择来构建你的堆栈：上面列出的所有三个Docker - 至少有一个开源代码（这也是Docker的一个很大的劣势），因为没有人为您编写单一的最佳实践文档）。





如果您喜欢Microsoft，如果将cobbling系统整合在一起并不重要，那么Service Fabric应该是对Docker生态系统的好选择。 （还可以在其下运行Docker容器。）




My thinking is that people use Docker to be sure that local environment is the same as production and that I they can stop thinking about where are their apps running physically and balancing mechanisms should just allocate apps in best places for that moment.

I'm 100% web based and I'm going to move to cloud together with our databases, and what cannot be moved will be seamlessly bridged so the corporate stuff and the cloud will become one subnetwork.

And so I'm wondering, maybe Service Fabric already does the same thing that Docker does plus it gives as address translation service (fabric:// that acts a bit like DNS for the processes in fabric space) plus (important for some) encourages on demand worker allocation - huge scalability perk.

1. Can Service Fabric successfully replace Docker?
2. Is it gaining audience and acceptance? Because otherwise even the greatest invention can fail.

解决方案

It's confusing since Docker (the company) is trying to stake claims in everything cloud.

• Docker Engine (what most people call "Docker") is a containerization technology. It can give you
  • Process isolation
  • Network isolation
  • Consistent application environment
• Docker Hub is an image registry. It stores Docker images so you can download them as part of your deployment.
• Docker Cloud is an orchestration system for Docker. It can give you
  • Scale your applications up and down
  • Connect your applications to each other
  • CI testing, integrated with Docker Hub (this isn't part of orchestration, just another thing it does)

Service Fabric is an orchestration system. It can orchestrate Docker containers, but it can also integrate more tightly with your services if you build specifically for Fabric. (Docker is completely agnostic about what runs inside a container.)

So Service Fabric is mostly comparable to Docker Cloud, though it's not an exact match. There are some other Docker-based orchestration solutions (Kubernetes is probably the biggest) and there are other cloud-based micro-service solutions (Heroku is probably the best-known).

The primary disadvantage of Service Fabric is that it's a Microsoft technology and so you're going to be tied to Azure to a greater degree than if you were running Docker. The other is that Docker has a broader range of choices for building your stack: all three Docker-things I listed above have at least one open-source alternative (this is also a big disadvantage of Docker, since nobody's laying out a single Best Practices For You document).

If you love Microsoft and if cobbling systems together is not something that's important to you, then Service Fabric should be a fine alternative to the Docker ecosystem. (And you can still run Docker containers under it.)

这篇关于Azure Service Fabric是否与Docker相同？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！