云原生知识星球

问题描述

CloudFoundry / Diego的下一个版本将为Docker容器提供原生支持，这些容器将在多个主机[链接]之间进行编排。这听起来与Kubernetes非常相似。

当然，Kubernetes试图解决的问题更为通用，其中CloudFoundry更专注于应用程序开发。然而，对我来说，它听起来都朝着类似的方向发展，而CloudFoundry正在简单的业务流程之上添加更多功能。

所以，我想知道Kubernetes会比CloudFoundry增加更多有价值的用例吗？

高票回答

作为CloudFoundry（过去）和Kubernetes（现在）的提交者，我可能有资格回答这个问题。

PaaS平台

我喜欢将CloudFoundry称为“应用程序PaaS”，将Kubernetes称为“容器PaaS”，但鉴于两个项目都会随着时间的推移而在同一市场中竞争，因此区别相当微妙和流畅。

两者之间的区别在于CF有一个暂存层，它采用（12-factor）用户应用程序（例如jar或gem）和Heroku风格的buildpack（例如Java + Tomcat或Ruby）并生成一个Droplet（类似于Docker镜像）。CF不会将容器化接口暴露给用户，但Kubernetes会这样做。

受众人员

CloudFoundry的主要受众是希望使用Heroku风格的buildpack部署12-factor无状态应用程序的企业应用程序开发人员。

Kubernetes的受众范围更广，包括无状态应用程序和提供自己容器的有状态服务开发人员。

这种区别可能在未来发生变化：

• CloudFoundry开始接受docker镜像
• Kubernetes可以添加镜像生成层

功能比较

随着两个项目的成熟和竞争，它们的异同将发生变化。因此，请将以下特征进行比较。

CF和K8都有许多相似的功能，如容器化，命名空间，身份验证。

Kubernetes的竞争优势：

• 对共享网络堆栈的容器进行分组和扩展，而不是仅仅进行独立扩展
• 提供自己的容器
• 有状态持久层
• 更大、更活跃的OSS社区
• 具有可替换组件和第三方插件
• 免费的web GUI

CloudFoundry的竞争优势：

• 成熟的身份验证，用户分组和多租户支持[x]
• 提供自己的APP
• 包括负载均衡器
• 由BOSH部署，扩展并保持状态[x]
• 强大的日志记录和度量聚合[x]
• 企业Web GUI [x]

[x] 这些功能不是Diego的一部分或包含在Lattice中。

部署

CloudFoundry的竞争优势之一是它拥有成熟的部署引擎BOSH，可以实现核心CF组件的扩展，恢复和监控等功能。BOSH还支持许多具有可插拔云提供程序抽象的IaaS层。不幸的是，BOSH的学习曲线和部署配置管理是噩梦。（作为BOSH提交者，我想我可以准确地说出来。）

Kubernetes的部署抽象仍处于起步阶段。核心仓库中提供了多个目标环境，但它们并非全部正在运行，经过良好测试或得到主要开发人员的支持。这主要是成熟的事情。人们可能会期望这会随着时间的推移而改进并且会增加抽象。例如，DCOS上的Kubernetes允许使用单个命令将Kubernetes部署到现有DCOS群集。

历史背景

Diego是CF的Droplet执行代理的重写。它最初是在Kubernetes宣布之前开发的，随着竞争格局的演变，它已经具有更多的功能范围。它的最初目标是生成droplets（用户应用程序 + CF buildpack）并在Warden（在Go中重写时重命名为Garden）容器中运行它们。自成立以来，它也被重新打包为Lattice，它有点像CloudFoundry-lite（虽然这个名字是由现有项目拍摄的）。出于这个原因，Lattice有点像玩具一样，因为它故意减少了用户的观众和范围，显然缺少使其达到“企业就绪”的功能。CF已经提供的功能。这部分是因为Lattice用于测试核心组件，而没有来自更复杂的CF的一些开销，但您也可以在内部高信任环境中使用Lattice，其中安全性和多租户不是那么重要。

值得一提的是，CloudFoundry和Warden（它的容器引擎）也早于Docker，差不多几年了。

另一方面，Kubernetes是一个相对较新的项目，由Google根据BORG和Omega多年的容器使用情况开发而成。Kubernetes可以被认为是谷歌的第三代容器编排，就像Diego是Pivotal / VMware的第三代容器编排一样（v1在VMware编写; v2在VMware与Pivotal Labs帮助; v3在Pivotal接管项目后）。

原文链接

Kubernetes vs. CloudFoundry

问题描述

Kubernetes似乎都是将容器部署到集群云中。它似乎没有提及开发和临时环境（或类似环境）。

在开发期间，您希望尽可能接近生产环境并进行一些重要更改：

• 在本地部署（或至少在您和您可以访问的地方部署）
• 在页面刷新时使用最新的源代码（假设它是一个网站；理想情况下，本地文件保存页面自动刷新，如果您安装源代码并使用像Yeoman这样的东西可以完成）

同样，人们可能希望在非公共环境进行持续集成。

Kubernetes是否支持这种开发环境，或者是必须构建的东西，希望在生产过程中它仍然可以工作？

高票回答

更新（2016-07-15）

随着Kubernetes 1.3的发布，Minikube现在是在本地机器上运行Kubernetes进行开发的推荐方式。

原文链接

How to create a local development environment for Kubernetes?

问题描述

我很困惑Ingress和Load Balancer在Kubernetes中的角色。

据我所知，Ingress用于将来自互联网的传入流量映射到群集中运行的服务。

Load Balancer的作用是将流量转发到主机。在这方面，Ingress与Load Balancer有何不同？与Amazon ELB和ALB相比，kubernetes中的Load Balancer的概念是什么？

高票回答

Load Balancer：kubernetes LoadBalancer是指向不在您的kubernetes集群中但存在于其他地方的外部负载均衡器的服务。假设您的pod可以从外部路由，它们可以与您的pod一起使用。Google和AWS本身就提供此功能。就Amazon而言，在AWS中运行时直接映射到ELB，kubernetes可以为部署的每个LoadBalancer服务自动配置和配置ELB实例。

Ingress：Ingress实际上只是将一组规则传递给正在监听它们的控制器。您可以部署一组Ingress规则，但除非您有可以处理它们的控制器，否则不会发生任何事情。如果配置为执行此操作，则LoadBalancer服务可以侦听Ingress规则。

您还可以创建NodePort服务，该服务在群集外部具有可外部路由的IP，但指向群集中存在的Pod。这可能是一个Ingress控制器。

Ingress Controller只是一个配置为解释入口规则的pod。nginx是kubernetes支持的最受欢迎的Ingress控制器之一。就亚马逊而言，ALB可用作Ingress控制器。

例如，这个nginx控制器能够获取你定义的入口规则并将它们转换为一个nginx.conf文件，它在它的pod中加载和启动。比如说你定义了一个Ingress如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
   ingress.kubernetes.io/rewrite-target: /
 name: web-ingress
spec:
  rules:
  - host: kubernetes.foo.bar
    http:
      paths:
      - backend:
          serviceName: appsvc
          servicePort: 80
        path: /app

然后，如果您检查nginx控制器的pod，您将在/etc/nginx.conf中看到定义的以下规则:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

server {
    server_name kubernetes.foo.bar;
    listen 80;
    listen [::]:80;
    set $proxy_upstream_name "-";
    location ~* ^/web2\/?(?<baseuri>.*) {
        set $proxy_upstream_name "apps-web2svc-8080";
        port_in_redirect off;

        client_max_body_size                    "1m";

        proxy_set_header Host                   $best_http_host;

        # Pass the extracted client certificate to the backend

        # Allow websocket connections
        proxy_set_header                        Upgrade           $http_upgrade;
        proxy_set_header                        Connection        $connection_upgrade;

        proxy_set_header X-Real-IP              $the_real_ip;
        proxy_set_header X-Forwarded-For        $the_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $best_http_host;
        proxy_set_header X-Forwarded-Port       $pass_port;
        proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
        proxy_set_header X-Original-URI         $request_uri;
        proxy_set_header X-Scheme               $pass_access_scheme;

        # mitigate HTTPoxy Vulnerability
        # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
        proxy_set_header Proxy                  "";

        # Custom headers

        proxy_connect_timeout                   5s;
        proxy_send_timeout                      60s;
        proxy_read_timeout                      60s;

        proxy_redirect                          off;
        proxy_buffering                         off;
        proxy_buffer_size                       "4k";
        proxy_buffers                           4 "4k";

        proxy_http_version                      1.1;

        proxy_cookie_domain                     off;
        proxy_cookie_path                       off;

    rewrite /app/(.*) /$1 break;
    rewrite /app / break;
    proxy_pass http://apps-appsvc-8080;

    }

Nginx刚刚创建了一条规则来路由http://kubernetes.foo.bar/app以指向群集中的服务appsvc。

示例介绍了如何在kubernetes集群中使用nginx ingress控制器。希望这可以帮助！

原文链接

Ingress vs Load Balancer

问题描述

1 - 我正在阅读文档，我对措辞有点困惑。它说：

ClusterIP：在集群内部IP上公开服务。选择此值使服务只能从群集中访问。这是默认的ServiceType

NodePort：在每个Node的IP上公开静态端口（NodePort）服务。将自动创建NodePort服务到ClusterIP服务的路由。您可以通过请求：来从群集外部请求NodePort服务。

LoadBalancer：使用云提供商的负载均衡器在外部公开服务。将自动创建外部负载均衡器到NodePort和ClusterIP服务的路由。

NodePort服务类型是否仍然使用ClusterIP，而只是在不同的端口，该端口对外部客户端开放？那么在这种情况下，：与：相同？

或者，NodeIP是否是运行kubectl get nodes得到的IP，而不是用于ClusterIP的虚拟IP？

2 - 同样在以下链接的图表中：

http://kubernetes.io/images/docs/services-iptables-overview.svg

客户端在节点内是否有任何特殊原因？我认为在ClusterIP服务类型的情况下，它需要在Cluster内。如果为NodePort绘制一个类似的图表，那么把客户端画在Node和Cluster之外是否有效，或者我是否忽略了什么？

高票回答

ClusterIP公开以下内容：

• spec.clusterIp:spec.ports[*].port

您只能在群集内访问此服务。可以从spec.clusterIp端口访问它。如果设置了spec.ports [*].targetPort，它将从端口路由到targetPort。调用kubectl get services时获得的CLUSTER-IP是内部在集群内分配给此服务的IP。

NodePort公开以下内容：

• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

如果通过nodePort的方式从节点的外部IP访问此服务，它会将请求路由到spec.clusterIp:spec.ports[*].port，然后将其路由到spec.ports [*].targetPort，如果设置。也可以使用与ClusterIP相同的方式访问此服务。

您的NodeIP是节点的外部IP地址。您无法从:spec.ports [*].nodePort访问您的服务。

LoadBalancer公开以下内容：

• spec.loadBalancerIp:spec.ports[*].port
• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

您可以从负载均衡器的IP地址访问此服务，该IP地址将您的请求路由到nodePort，而nodePort又将请求路由到clusterIP端口。您可以像访问NodePort或ClusterIP服务一样访问此服务。

原文链接

What’s the difference between ClusterIP, NodePort and LoadBalancer service types in Kubernetes

问题描述

我对所有这些都比较陌生，并且在尝试理解列出的这些技术时遇到了麻烦。

虽然，所有这些技术都试图解决不同的问题，但也有共同点。我想了解哪些是相同的，哪些是不同的。少数技术的组合很可能非常适合，如果是这样的话，他们是什么？

我列出了其中的一些以及问题，但如果有人详细列出所有问题并回答问题，那将会很棒。

1. Kubernetes vs Mesos:

   Apache的Mesos和Google的Kubernetes有什么区别提供了很好的洞察力，但我无法理解为什么Kubernetes应该运行在Mesos之上。两个开源解决方案的结合更多的是什么？

2. Kubernetes vs Core-OS Fleet:

   如果我使用kubernetes，是否需要Core-OS Fleet？

3. Docker-Swarm如何适应上述所有内容？

高票回答

我认为Mesos和Kubernetes主要是为了解决运行集群应用程序的类似问题，他们有不同的历史和解决问题的不同方法。

Mesos将精力集中在非常通用的调度上，并插入多个不同的调度程序。这意味着它使Hadoop和Marathon等系统能够在同一个调度环境中共存。Mesos不太关注运行时容器。Mesos存在于对容器的广泛关注之前，并且已经重新更新以支持容器。

相比之下，Kubernetes从一开始就被设计成一个用于从容器构建分布式应用程序的环境。它包括用于复制和服务发现的原语作为核心原语，其中 - 在Mesos中是通过框架添加这些原语。Kubernetes的主要目标是构建，运行和管理分布式系统的系统。

Fleet是一个较低级别的任务分发者。它对于引导群集系统很有用，例如CoreOS使用它将kubernetes代理和二进制文件分发到群集中的计算机，以便启动kubernetes群集。它并不是真正意图解决相同的分布式应用程序开发问题，更像是集群的systemd / init.d / upstart。如果您运行kubernetes，则不需要它，您可以使用其他工具（例如Salt，Puppet，Ansible，Chef，…）来完成相同的二进制分发。

Swarm是Docker努力扩展现有的Docker API，使一组机器看起来像一个Docker API。从根本上说，我们在Google和其他地方的经验表明，节点API不足以支持群集API。你可以在这里看到一堆讨论：
https://github.com/docker/docker/pull/8859和这里：
https://github.com/docker/docker/issues/8781

原文链接

Docker-Swarm, Kubernetes, Mesos & Core-OS Fleet

问题描述

我一直在创建类型为deploy的pod，但我看到一些文档使用的type是pod，更具体地说是多容器pod的文档：

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

但是要创建pod，我可以使用deployment类型：

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

我注意到pod文档说：

create命令可用于直接创建pod，也可以通过Deployment创建pod或pods。强烈建议您使用deployment来创建pod。它会监视失败的pod，并根据需要启动新的pod以维持指定的数量。如果您不希望deployment监视您的pod（例如，您的pod正在编写非持久性数据，或者您的pod的生命非常短暂），则可以直接创建一个pod。

注意：我们建议使用“deployment”来创建pods。

但是这引出了一个问题：kind类型为pod有什么好处？你能以某种方式参考deployment中的pod吗？我没有看到办法。看起来使用pod获得的是一些额外的元数据，但没有任何deployment选项，如副本或重启策略。没有持久数据的pod有什么用，可以在重启后保存下来？我想我也可以创建一个deployment的多容器pod。

高票回答

Pod和Deployment都是Kubernetes API中的完整对象。Deployment通过ReplicaSet管理创建Pod。它归结为Deployment将使用模板中的规范创建Pod。您不太可能需要直接为生产用例创建Pod。

原文链接

What is the difference between a pod and a deployment?

问题描述

我试图删除一个有12个pod的ReplicationController，但是发现一些pod卡在了Terminating状态。

我的Kubernetes集群安装在Ubuntu虚拟机上，包括一个master节点和三个worker节点。

这个问题可能是什么原因？

1
2
3
4
5
6

NAME        READY     STATUS        RESTARTS   AGE
pod-186o2   1/1       Terminating   0          2h
pod-4b6qc   1/1       Terminating   0          2h
pod-8xl86   1/1       Terminating   0          1h
pod-d6htc   1/1       Terminating   0          1h
pod-vlzov   1/1       Terminating   0          1h

高票回答

您可以使用以下命令强制删除POD。

1

kubectl delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>

原文链接

Pods stuck in Terminating status

问题描述

虽然分析了Docker，Google Cloud和Kubernetes，但还没有清楚地理解它们， 在我看来这些产品是重叠但不兼容的。

例如，需要重新编写docker-compose文件，以便可以将应用程序部署到Kubernetes。

有人可以从较高层次描述Docker，Docker-Compose，Docker Cloud和Kubernetes重叠的位置以及哪一个依赖于另一个吗？

高票回答

Docker :

Docker是一种容器技术，可以让您对应用程序进行容器化。Docker是使用其他技术的核心。

Docker Compose:

允许配置和启动多个docker容器。当你想要启动多个docker容器并且不想使用docker run分别启动每个Docker容器时，可以使用Docker compose启动。

Docker Swarm:

Docker swarm用于在多个主机上运行和连接容器。Docker swarm是一个容器集群管理和编排工具。它管理在多个主机上运行的容器，并执行缩放，在崩溃时启动新容器，网络容器……

Docker swarm是生产环境中的docker。它是嵌入在Docker引擎中的本机docker编排工具。名为stack file的docker swarm文件与docker compose文件非常相似。

Kubernetes:

由Google开发的容器编排工具。Kubernetes的目标与Docker swarm的目标非常相似。

Docker Cloud:

一种付费的企业级docker服务，允许您在云服务器或本地服务器上构建和运行容器。它提供了一个Web UI和一个中央控制面板来运行和管理容器，同时在用户友好的Web界面中提供所有docker功能。

Update:

Docker Clou“部分”功能停止使用

1

Docker Cloud上提供应用程序，节点和群集集群管理的服务将于5月21日关闭......自动构建和注册表存储服务将不会受到影响并将继续可用

原文链接

What’s the difference between docker compose and kubernetes?

问题描述

Apache的Mesos和Google的Kubernetes有什么区别？我知道两者都是服务器集群管理软件。有没有人可以详细说明主要区别在哪里？ - 什么时候会优先采用哪种框架？

高票回答

Kubernetes是一个开源项目，为虚拟机或“裸金属”场景带来“谷歌风格”的集群管理功能。它适用于现代操作系统环境（如CoreOS或Red Hat Atomic），可管理轻量级计算“节点”。它是用Golang编写的，具有轻量级，模块化，可移植性和可扩展性。我们（Kubernetes团队）正在与许多不同的技术公司（包括策划Mesos开源项目的Mesosphere）合作，将Kubernetes建立为与计算集群交互的标准方式。我们的想法是根据我们在Google的经验，重现我们看到人们需要构建群集应用程序的模式。其中一些概念包括：

• pods - 将容器组合在一起的方法
• replication controllers - 一种处理容器生命周期的方法
• labels - 查找和查询容器的方法
• services - 一组执行共同功能的容器。

因此，仅使用Kubernetes，您就会拥有一些简单，易于启动，可移植和可扩展的功能。在群集上运行应用程序，而无需担心单个计算机。在这种情况下，群集就像VM一样是一种灵活的资源。它是一个逻辑计算单元，可以快速轻松地开启，使用，调整大小，关闭。

使用Mesos，在基本视觉方面存在相当多的重叠，但产品在其生命周期中处于完全不同的点并且具有不同的优点。Mesos是一个分布式系统内核，它将许多不同的机器拼接成逻辑计算机。它诞生于一个拥有大量物理资源来创建大型静态计算集群的世界。最棒的是，许多现代可扩展的数据处理应用程序在Mesos（Hadoop，Kafka，Spark）上运行良好，这很好，因为您可以在同一个基本资源池上运行它们，以及新的容器打包应用程序。它比Kubernetes项目更重，但由于像Mesosphere这样的人的工作，它变得更容易和更容易管理。

现在真正有趣的是，Mesos目前正在适配添加大量Kubernetes概念并支持Kubernetes API。因此，它将成为获取Kubernetes应用程序更多功能的门户（高可用性主，更高级的调度语义，扩展到大量节点的能力），如果您需要它们，并且非常适合运行生产工作负载（Kubernetes仍处于alpha状态）。

当被问到时，我倾向于说：

1. 如果您不熟悉集群的世界，Kubernetes是一个很好的起点；它是最快，最简单，最轻松的方式来启动并开始尝试面向集群的开发。它提供了非常高的可移植性，因为它得到了许多不同提供商（Microsoft，IBM，Red Hat，CoreOs，MesoSphere，VMWare等）的支持。
2. 如果您有现有的工作负载（Hadoop，Spark，Kafka等），Mesos会为您提供一个框架，让您可以将这些工作负载相互交错，并混合使用包括Kubernetes应用程序在内的一些新工具。
3. 如果您需要Kubernetes框架中社区尚未实现的功能，Mesos会为您提供一个类似方案。

原文链接

What’s the difference between Apache’s Mesos and Google’s Kubernetes

用于将Microsoft Word .doc文档转换为任何其他支持格式（如.txt .rtf .pdf）的简单实用程序。

也可用于将.txt，.rtf转换为.doc或.pdf格式。

注：主机上必须安装Microsoft Word。

特点

1. 将Doc / RTF / Text文件转换为任何Word SaveAs类型Doc / Text / RTF / PDF
2. 单个文件转换
3. 多个/目录文件转换
4. 转换后删除
5. 每次转换时可调用Webhook

举例

单个文件转换

将Microsoft Word文档转换为文本

1

docto -f C:\Directory\MyFile.doc -O "C:\Output Directory\MyTextFile.txt" -T wdFormatText

将Microsoft Word文档转换为PDF（需要支持此功能的Microsoft Word版本）

1

docto -f C:\Directory\MyFile.doc -O "C:\Output Directory\MyTextFile.pdf" -T wdFormatPDF

多文件和文件夹转换

将目录及其子目录中的所有Microsoft Word文档转换为PDF

1

docto -f "C:\Dir with Spaces\FilesToConvert\" -O "C:\DirToOutput" -T wdFormatPDF  -OX .pdf

转换后删除原始文件（-R）

1

docto -f "C:\Dir with Spaces\FilesToConvert\" -O "C:\DirToOutput" -T wdFormatPDF  -OX .pdf -R

Webhooks

添加Webhook以在每次转换时触发（-W）

1

docto -f "C:\Dir with Spaces\FilesToConvert\" -O "C:\DirToOutput" -T wdFormatPDF  -OX .pdf  -W http://toflidium.com/webhooks/docto/webhook_test.php

Webhook是一个可以在每次转换时调用的URL，使您能够在转换文件时从外部响应。

命令行支持参数列表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

参数标记不区分大小写。大小写可以混合使用。
  -H  查看各参数使用方法
      --help -?
  -F  输入文件或目录
      --inputfile
  -FX 如果输入为目录，指定源文档的扩展名。默认“.doc”（包括“.docx”）
      --inputextension
  -O  输出文件或目录以存放转换后的文档
      --outputfile
  -OX 如果-F为目录，指定转换后的文档扩展名。请包含'.'，如'.pdf'
      --outputextension
  -T  格式（类型），可以使用数字或wdSaveFormat常量表示，参考：http://msdn.microsoft.com/en-us/library/microsoft.office.interop.word.wdsaveformat.aspx
      --format
  -TF 强制转换格式
      --forceformat
  -L  日志级别，1 ERRORS, 2 STANDARD, 5 CHATTY, 10 VERBOSE，默认值为2
      --loglevel
  -C  兼容模式整数值，参考：https://msdn.microsoft.com/en-us/library/office/ff192388.aspx
      --compatability
  -M  忽略__MACOSX\目录下的所有文件，默认为True
      --ignoremacos
  -G  写日志文件到指定目录
      --writelogfile
  -GL 日志文件名称，默认为'DocTo.Log'
      --logfilename
  -Q  以安静模式输出日志
      --quiet
  -R  转换成功后移除源文件，默认为false
      --deletefiles
  -W  Webhook钩子，通过URL调用响应事件
  -HW Webhook帮助
  -X  暂停COM错误：默认为True。如果您在某些文件未转换时遇到问题，请将此设置为false以忽略错误并继续批处理作业
      --halterror
  -V  版本号

错误码:
200 : 指定的文件格式无效
201 : 输入参数不足。如输入文件，输出文件和类型为必选参数
202 : 转换错误
203 : 未知的转换命令
220 : Word或COM错误
221 : Word未安装

兼容模式：
wdCurrent   : 65535 等效于最新版本的Microsoft Word
wdWord2003  : 11    Word 2010将设置为与Word 2003最兼容的模式。在此模式下禁用Word 2010新增功能
wdWord2007  : 12    Word 2010将设置为与Word 2007最兼容的模式。在此模式下禁用Word 2010新增功能
wdWord2010  : 14    Word 2013将设置为与Word 2010最兼容的模式。在此模式下禁用Word 2013新增功能 
wdWord2013  : 15    默认值。支持所有Word 2013功能