tsuru.conf 参考

tsuru.conf 参考

tsuru 使用 YAML 格式的配置文件。本文档描述了各个选项的含义和样式。

标记法

tsuru 使用冒号来表示 YAML 中的嵌套。所以,无论何时当文档中提到诸如key1:key2时,指的是key2的值嵌套在值为key1的块中。比如,database:url 意思是:

  1. database:
  2. url: <value>

tsuru 配置

这一章节描述了 tsuru 的核心配置。其它章节将包含可选组件的配置,以及最后,一个完整的示例文件。

HTTP 服务器

tsuru 提供了一个 REST API, 支持 HTTP 和 HTTP/TLS (也即 HTTPS)。以下是一些会影响 tsuru's API 行为的选项:

listen

listen 定义了 tsuru web 服务器将监听的地址。 形式为 <host>:<port>。你可以忽略主机名 (比如: :8080)。这一设置没有缺省值。

use-tls

use-tls 指示 tsuru 是否使用 TLS 。这一设置是可选的,缺省为 "false"。

tls:cert-file

tls:cert-file 是配置用于域名服务的证书文件 X.509 的路径。这一设置是可选的,除非 use-tls 值为 true。

tls:key-file

tls:key-file 是配置用于域名服务的私钥文件的路径。这一设置是可选的,除非 use-tls 值为 true。

server:read-timeout

server:read-timeout 是服务器读请求的超时值。这是所有发往 tsuru 服务器请求的最大时长。

这对避免连接泄露很有用,这可以防止客户端在发送请求之前就断开链接的情况。缺省值为 0, 表示不会超时。

server:write-timeout

server:write-timeout 是服务器写请求的超时值。

这对避免连接泄露很有用,这可以防止客户端在读取 tsuru 响应前就断开连接的情况。缺省值为 0, 表示不会超时。

disable-index-page

tsuru API 提供了一个关于如何使用当前目标的基本指导的索引页。可以通过把 disable-index-page 标志设置为 true 来禁止这一页面。同样可以自定义用于索引页的模板,参见下一个配置条目来获取更多细节。

这一设置是可选的,缺省为 false

index-page-template

index-page-template 是用于索引页的模板。必须使用 Go 模板语法, tsuru 将在模板上下文中提供以下变量:

  1. - ``tsuruTarget``: tsuru API 服务于索引页的目标 URL
  2. - ``userCreate``: 一个指示用户注册是否允许的 boolean 值。
  3. - ``nativeLogin``: 一个指示 API 是否配置为使用本地授权方案的 boolean 值。
  4. - ``keysEnabled``: 一个指示 API 是否配置为管理 SSH 秘钥的 boolean 值。

它会同时包含一个用于查询配置值的函数,名为 getConfig。下面是此函数用法的一个示例:

  1. <body>
  2. {{if getConfig "use-tls"}}
  3. <p>we're safe</p>
  4. {{else}}
  5. <p>we're not safe</p>
  6. {{end}}
  7. </body>

这一设置是可选的。当 index-page-template 没有定义时,tsuru 将使用缺省模板

数据库访问

tsuru 使用 MongoDB 作为数据库管理工具来存储诸如用户、机器和容器等信息。你需要描述 tsuru 如何连接到数据库服务器。因此,必须提供一个 MongoDB 连接字符串。Database 相关选项如下:

database:url

database:url 是数据库连接字符串。这是一必须的设置,没有缺省值。字符串的例子如基本的 127.0.0.1 和更高级的 mongodb://user:password@127.0.0.1:27017/database。请参考 MongoDB 文档以获取更多细节及连接字符串的例子。

database:name

database:name 是 tsuru 所使用的数据库的名字。这是一必须的设置,没有缺省值。一个示例值是 "tsuru"。

database:logdb-url

这一设置是可选的。如果 database:logdb-url 已指定,tsuru 将使用它做为负责存储应用日志的 MongoDB 服务器的连接字符串。如果这一值没有设置,tsuru 将使用 database:url 替代。

这一设置是有用的,因为根据部署的单元的数量及应用的行为,tsuru 可能需要处理非常大量的日志消息。每个日志消息都会触发一次在 MongoDB 中的插入操作,而这会对数据库的性能形成消极的冲击。其它指标将在未来实现以提高这一性能,至于现在,拥有使用一个独占的日志服务器的能力将有助于缓解日志写入操作带来的负面冲击。

database:logdb-name

这一设置是可选的。如果 database:logdb-name 已指定,tsuru 将使用它作为存储应用日志的数据库名。如果这一值没有设置,tsuru 将使用 database:name 替代。

邮件配置

当用户请求恢复密码时,tsuru 会发送邮件给用户。为发送这些邮件,tsuru 需要一些 SMTP 方面的配置。忽略这些设置不会影响到 tsuru,但用户将不能重置他们的密码。

smtp:server

要连接的 SMTP 服务器。必须形如 <host>:<port>。例子:"smtp.gmail.com:587"。

smtp:user

用于 SMTP 服务器认证的用户。目前,tsuru 要求认证的会话。

smtp:password

用于 SMTP 服务器内认证的密码。

仓库配置

tsuru 可选用 Gandalf 来管理 git 仓库。 Gandalf 暴露了一组用于仓库管理的 REST API,而 tsuru 需要有关 Gandalf HTTP 服务器端点的信息。

repo-manager

repo-manager 代表了 tsuru-server 将使用的仓库管理器。因后向兼容的需要,缺省值为 "gandalf"。通过将 "repo-manager" 设置为 "none",用户可以停用仓库和 SSH 秘钥管理。更多细节,请参考:repository management page

git:api-server

git:api-server 是 Gandalf API 的地址。它应该定义一个完整的地址,包括协议和端口。示例值:http://localhost:9090https://gandalf.tsuru.io:9595

认证配置

tsuru 支持 nativeoauth 认证方案。

缺省方案是 native,它支持在 tsuru 的内部数据库中创建用户。它会对加密秘钥进行哈希。Tokens 在认证时生成,并使用 SHA512 来哈希。

auth 部分也会控制是否启用用户注册。当没启用时,只有管理员用户可以创建新用户。

auth:scheme

所用的认证方案。缺省值为 native,其它支持的值为 oauth

auth:user-registration

用户注册是否启用的指示值。这一设置是可选的,缺省为 false。

auth:hash-cost

auth:scheme 选择为 native 时才需要。

这一数值指示你将使用多少 CPU 时间用于哈希计算。这是一绝对值,介于 4 到 31 间, 4 最快但更不安全,而 31 最安全但非常慢。

auth:token-expire-days

auth:scheme 选择为 native 时才需要。

任何时候当用户登录时,tsuru 会对其生成一个 token ,用户可以存储这个 token。auth:token-expire-days 设置定义了 token 有效的天数。这一设置是可选的,缺省为 "7"。

auth:max-simultaneous-sessions

tsuru 可以限制一个用户可同时拥有的会话数量。这一设置是可选的,缺省为 "unlimited"。

auth:oauth

auth:scheme 设置为 "oauth" 时,auth:oauth 中的每一个配置项都将使用。请参考 rfc6749 来获取更多细节。

auth:oauth:client-id

你的 OAuth 服务器提供的客户端 id。

auth:oauth:client-secret

你的 OAuth 服务器提供的客户端密钥。

auth:oauth:scope

你的认证请求的范围。

auth:oauth:auth-url

OAuth 流的认证步骤所使用的 URL。 tsuru CLI 将收到这一 URL,并以此触发打开一浏览器,同时带上必要的参数。

在认证步骤期间, tsuru CLI 将在本地启动一个服务器并把回调设为 http://localhost:<port>, 如果 auth:oauth:callback-port 已设置,tsuru CLI 将用它的值作为 <port>。如果 auth:oauth:callback-port 不存在,tsuru CLI 将自动选择一开放端口。

回调 URL 应注册到你的 OAuth 服务器上。

如果所选的服务器要求回调 URL 与注册的主机和端口一致,你应该注册 "http://localhost:<chosen port>" 并相应地对 auth:oauth:callback-port 进行设置。

如果所选的服务器要求较为宽松,允许使用一个不同的端口,你只需简单地注册 "http://localhost",把 auth:oauth:callback-port 保持为空。

auth:oauth:token-url

OAuth 流中交换 token 步骤所用的 URL。

auth:oauth:info-url

用于获取认证用户信息的 URL。tsuru 期待一个包含一名为 email 字段的 json 响应。

tsuru 将在每个到 API 的请求上调用这一 URL 以确保 token 依然有效而没有被撤销。

auth:oauth:collection

用于存储有效的访问 tokens 的数据库集合。缺省值为 "oauth_tokens"。

auth:oauth:callback-port

认证步骤期间用于回调 URL 的端口。参见 auth:oauth:auth-url 文档以获取更多细节。

队列配置

tsuru 对异步任务使用一个工作队列。

queue:* 集合了所有的用于延迟执行的队列任务的 MongoDB 服务器的配置设置。

这一队列用于管理 IaaS 机器的创建和销毁,但将来 tsuru 可能开始将它用于更多的地方。

配置队列不是必须的,如不配置,将无法使用 IaaS 提供者来创建和删除机器。

queue:mongo-url

MongoDB 服务器用于存储任务信息的连接 url。

queue:mongo-database

用于 MongoDB 中的数据库名。 这一值优先于任何已在连接 url 中指定的数据库名字。

pubsub(发布/订阅)

pubsub 配置是可选的并取决于一个 redis 服务器实例。它只用于跟踪应用日志(运行 tsuru app-log -f)。 如无配置,运行 tsuru app-log -f 时 tsuru 将失败。

此前,这一 redis 服务器配置位于下述 redis-queue:* 键值内。对这些键值的使用已废弃,在 1.0 版本发布前,tsuru 启动时将忽略它们。

pubsub:redis-host

pubsub:redis-host 是用于发布/订阅的 Redis 服务器的主机名。这一设置是可选的,缺省值为 "localhost"。

pubsub:redis-port

pubsub:redis-port 是用于发布/订阅的 Redis 服务器的端口。这一设置是可选的,缺省值为 6379。

pubsub:redis-password

pubsub:redis-password 是用于发布/订阅的 Redis 服务器的密码。这一设置是可选的,缺省值为"",表示 Redis 服务器没有认证。

pubsub:redis-db

pubsub:redis-db 是用于发布/订阅的 Redis 服务器的数据库数量。这一设置是可选的,缺省值为 3。

pubsub:pool-max-idle-conn

pubsub:pool-max-idle-conn 是到 redis 的空闲连接的最大数目。缺省为 20。

pubsub:pool-idle-timeout

pubsub:pool-idle-timeout 是空闲连接留在到 redis 的连接池的秒数。缺省为 300。

pubsub:redis-dial-timeout

pubsub:redis-dial-timeout 是拨号超时的秒数。缺省为 0.1。

pubsub:redis-read-timeout

pubsub:redis-read-timeout 是读超时的秒数。缺省为 1800 (30 分钟)。

pubsub:redis-write-timeout

pubsub:redis-write-timeout 是写超时的秒数。缺省为 0.5。

redis-queue:host

已废弃。见 pubsub:redis-host

redis-queue:port

已废弃。见 pubsub:redis-port

redis-queue:password

已废弃。见 pubsub:redis-password

redis-queue:db

已废弃。见 pubsub:redis-db

配额管理

tsuru 能够可选地管理配额。目前,有两种可用的配额:按每个用户的应用额度和按每个应用的单元额度。

tsuru 管理员可在配置文件中控制对新用户和新应用的缺省配额,并使用 tsuru-admin 命令来改变对用户或应用的配额。配额管理缺省没有启用,为启用它,只需将所需配额设置到一个正整数即可。

quota:units-per-app

quota:units-per-app 是单元每应用配额的缺省值。所有的新应用最多能拥有的单元数目不能超过这一设置所指定的值。这一设置是可选的,缺省为 "unlimited"(没有限制)。

quota:apps-per-user

quota:apps-per-user 是应用每用户配额的缺省值。所有新用户最多能拥有的应用数目不能超过这一设置所指定的值。这一设置是可选的,缺省为 "unlimited"(没有限制)。

日志

Tsuru 支持三种日志偏好,可以全部启用或不启用。tsuru 的缺省行为是把全部日志发送到 syslog,但它也能将日志发送到标准错误流或一文件中。可在任何时间在 tsuru 配置中使用这三种偏好的任意组合。(例如: 把日志同时写到 stderr 和 syslog 中,或者到一个文件和 stderr,又或者同时到所有的偏好中)。

同时可以通过调试标志启用或者不启用调试日志。

调试

false 是缺省值,所以你不会在日志中看到恼人的输出,为开启它,将其设为 true,例如: debug: true

log:file

使用它来指定一个日志文件的路径。如果没有指定,tsuru-server 将不会把日志写到任何文件中。

log:disable-syslog

log:disable-syslog 指示 tsuru-server 是否应禁用 syslog 的使用。 false 是缺省值。如果是 true,tsuru-server 将不会发送任何日志到 syslog 中。

log:syslog-tag

log:syslog-tag 是附着在每一日志行中的标签,缺省值为 "tsr"。

log:use-stderr

log:use-stderr 指示 tsuru-server 是否应把日志写到标准错误流中。缺省值是 false

路由器

截至 0.10.0, 你的所有的路由器配置应在 routers:<router name> 格式的条目下。

routers:<router name>:type (type: hipache, galeb, vulcand)

指示这一路由配置的类型。tsuru 所支持的标准路由器是 hipache。同时也有对 galebvulcand 的实验性支持。

根据不同的类型,有特定的配置选项可用。

routers:<router name>:domain (type: hipache, galeb, vulcand)

运行你的路由器的服务器的域名。tsuru 创建的应用将有一个形如 http://<app-name>.<domain&gt; 的地址。

routers:<router name>:redis-server (type: hipache)

被 Hipache 路由器所使用的 Redis 服务器。这同一个服务器(或它的一个 redis 从属(slave))必须配置在你的 hipache.conf 文件中。

routers:<router name>:api-url (type: galeb, vulcand)

Galeb 或 vulcand 管理 API 的 URL。

routers:<router name>:username (type: galeb)

Galeb 管理员(manager)用户名。

routers:<router name>:password (type: galeb)

Galeb 管理员密码。

routers:<router name>:environment (type: galeb)

用于创建虚拟主机和后端池子的 Galeb 管理员环境。

routers:<router name>:farm-type (type: galeb)

用于创建虚拟主机和后端池子的 Galeb 管理员 farm 类型。

routers:<router name>:plan (type: galeb)

用于创建虚拟主机和后端池子的 Galeb 管理员计划。

routers:<router name>:project (type: galeb)

用于创建虚拟主机、后端池子和池子的 Galeb 管理员项目。

routers:<router name>:load-balance-policy (type: galeb)

用于创建后端池子的 Galeb 管理员负载平衡政策。

routers:<router name>:rule-type (type: galeb)

用于创建规则的 Galeb 管理员规则类型。

Hipache

hipache:redis-server

Hipache 路由器所用的 Redis 服务器。 这同一个服务器(或是一个它的 redis 从属(slave))必须配置在你的 hipache.conf 文件中。

这一设置已经废弃,请用 routers:<router name>:type = hipacherouters:<router name>:redis-server 替代。

hipache:domain

运行你的 hipache 服务器的服务器的域名。tsuru 所创建的应用将有一个形如 http://<app-name>.<hipache:domain&gt; 的地址。

这一设置已经废弃,请用 routers:<router name>:type = hipacherouters:<router name>:domain 替代。

定义提供商(provisioners)

tsuru 有对提供商的扩展支持。一个提供商是一个满足 provision.Provisioner 接口的 Go 类型。缺省情况下,tsuru 将使用 DockerProvisioner (由字符串 "docker" 标识),目前是唯一支持的提供商 (Ubuntu Juju 过去也曾支持,但对它的支持已从 tsuru 中移除)。

提供商

provisioner 是 tsuru 所用的提供商的名字的字符串。这一设置是可选的,缺省为 "docker"。

Docker 提供商配置

docker:collection

用于存储容器信息的数据库集合名字。

docker:port-allocator

端口分配器的选项。有两个可能的值:

  • docker: 信任 Docker 来分配端口。它意味着无论何时当容器重启时,端口可能改变(通常,它会改变)。
  • tsuru: 把端口分配留给 tsuru,所以映射到容器的端口绝不会改变。
    缺省值为 "docker"。

docker:registry

为使 tsuru 能与多个 docker 节点一起工作,你需要一个 docker-registry。它的形式应是 hostname:port, 这一方案不能没有。

docker:registry-max-try

tsuru 将尝试发送一镜像去登记的次数。

docker:registry-auth:username

登记认证所用的用户名。这一设置是可选的,对无需认证的登记,可以忽略。

docker:registry-auth:password

登记认证所用的密码。这一设置是可选的,对无需认证的登记,可以忽略。

docker:registry-auth:email

登记认证所用的邮件。这一设置是可选的,对无需认证的登记,可以忽略。

docker:repository-namespace

用于应用和平台镜像的 Docker 仓库命名空间。镜像在 docker 上将被打上如 <docker:repository-namespace>/<platform-name> 和 <docker:repository-namespace>/<app-name> 的标签。

docker:bs:image

docker:bs:image 是用于创建 big sibling 容器的 Docker 镜像的名字。 缺省值为 "tsuru/bs", 它代表了由 tsuru 团队所维护的托管在 Docker Hub 上的官方镜像

docker:bs:socket

docker:bs:socket 是 Docker 主机上的 Unix socket 的路径。它应被配置以使得 bs 可以通过 socket 而不是 TCP 来连接到 Docker。这是一可选的设置,一旦忽略,bs 将通过 TCP 端点来与 Docker API 交流。

docker:bs:syslog-port

docker:bs:syslog-port bs 容器用于收集日志的 Docker 节点的端口。缺省值是 1514。

docker:max-workers

当启动新容器时所创建线程的最大数量,以使得 tsuru 在比如启动 1000 个单元的过程中不会启动太多的线程,缺省为 0,表示没有限制。

docker:router

用于分配请求到单元上的缺省路由器。这必须是路由器配置中 routers:<name> 键值所对应的名字,参见 routers

因后向兼容性上的缘由,值 hipache 也被支持,它将依次使用或者来自 router:hipache: 或者来自 hipache: 的可用配置。

注意到截至 0.10.0,路由器可以与计划相关联,如果当创建一个应用时所选计划中已有一个路由器值时,这一值将被使用,而不是用设在 docker:router 上的值。

定义在 docker:router 上的路由器只会在选中计划中没有指定时才会使用。

docker:deploy-cmd

当一个新的部署发生时,在你的平台上将被调用的命令。tsuru's basebuilder 仓库所支持的平台的缺省值是 /var/lib/tsuru/deploy

docker:security-opts

这一设置描述了一系列将被传给容器的安全选项。这一设置必须是一个列表,没有缺省值。即使没人愿意指定哪怕一个值,依然需要使用列表的标记法:

  1. docker:
  2. ...
  3. security-opts:
  4. - apparmor:PROFILE

对于可用选项的更多细节,请参考 Docker 文档: https://docs.docker.com/reference/run/#security-configuration

docker:segregate

已废弃。截至 tsuru 0.11.1,使用隔离调度器是缺省设置。参见 segregate scheduler 以获取更多细节。

docker:scheduler:total-memory-metadata

这值描述了哪个元数据键将用于描述一个 docker 节点可用的内存总数量,以字节为单位。

docker:scheduler:max-used-memory

这应是一个介于 0.0 和 1.0 间的值,它用于描述对一个服务器可用的总内存中有多少比例将预留用于应用单元。

可用内存的总量可基于由 docker:scheduler:total-memory-metadata 配置设置所描述的节点元数据来找到。

如果值已设置,tsuru 将基于用于创建应用的计划所要求的内存,来试图找到一个有足够未保留内存的节点来满足单元的创建。如果找不到有足够未保留内存的节点,tsuru 将忽略内存限制,让调度器选择任何一个节点。

这一设置,与 docker:scheduler:total-memory-metadata 一起,同样被用于节点自动伸缩(scaling)。见 node auto scaling 来获取更多细节。

docker:cluster:storage

这一设置已被移除。你不应再去定义它,目前 docker 集群唯一可用的存储是 mongodb

docker:cluster:mongo-url

用于存储有关 docker 集群信息的 mongodb 服务器的连接 URL。

docker:cluster:mongo-database

用于存储有关 docker 集群信息的数据库名。

docker:run-cmd:bin

将在应用镜像上调用以启动应用的命令。tsuru's basebuilder 仓库所支持的平台的缺省值是 /var/lib/tsuru/start

docker:run-cmd:port

将被容器暴露给节点网络的 tcp 端口。tsuru's basebuilder 仓库所定义的平台所期待的缺省值是 8888

docker:user

tsuru 用于启动容器的用户。basebuilder 平台所期待的值是 ubuntu

docker:healing:heal-nodes

标志值用于指示 tsuru 是否应该去修复那些失败次数已达到指定值的节点。仅当节点是由 tsuru 它自己使用 IaaS 配置来创建时,节点修复才可用。缺省为 false

docker:healing:active-monitoring-interval

向各个 docker 节点调用 <server>/_ping 时所间隔的秒数。如果值为 0 或没有设置,tsuru 将永远不会调用 ping URL。缺省为 0。

docker:healing:disabled-time

当节点失效后到 tsuru 禁用节点所间隔的秒数。当 heal-nodes 设置为 true 时这一设置才有效。缺省为 30 秒。

docker:healing:max-failures

在触发修复操作前,一个节点连续失败的次数。当 heal-nodes 设置为 true 时才有效。缺省为 5 次。

docker:healing:wait-new-time

修复过程中,tsuru 等待创建新节点的秒数。当 heal-nodes 设置为 true 时才有效。缺省为 300秒(5分钟)。

docker:healing:heal-containers-timeout

容器失去响应到触发容器重建的秒数。当容器不再以 started 状态调用设置单元状态 URL(/apps/{app}/units/{unit}) 时,将被认为失去了响应。如果值为 0 或者没有设置,tsuru 将不会试图去修复无响应的容器。缺省为 0。

docker:healing:events_collection

mongodb 中用于存储被触发的修复事件的信息的集合名字。缺省为 healing_events

docker:healthcheck:max-time

以秒计算的等待部署时间健康检查成功的最大时间。缺省为 120 秒。

docker:image-history-size

使用 tsuru app-deploy-rollback 回滚时可用镜像的数量。tsuru 将试图删除旧的镜像,但可能因其已用作为新镜像的一层而无法成功。tsuru 将继续试图删除这些旧的镜像直到它们不再用作为分层。缺省为 10 个镜像。

docker:auto-scale:enabled

启用节点自动伸缩。见 node auto scaling 以获取更多细节。缺省为 false。

docker:auto-scale:wait-new-time

在扩展过程中 tsuru 应等待新节点创建的秒数。缺省为 300 秒(5 分钟)。

docker:auto-scale:group-by-metadata

出现在用于组合节点到集群中的节点的元数据的名字。见 node auto scaling 以获取更多细节。缺省为空(所有节点属于同一个集群)。

docker:auto-scale:metadata-filter

docker:auto-scale:group-by-metadata 所指定的元数据的值。如果已设置,tsuru 将只会对由这个值所定义的集群中的节点运行自动扩展算法。

docker:auto-scale:max-container-count

每个节点的容器的最大数量,用于基于计数的扩展。见 node auto scaling 以获取更多细节。

docker:auto-scale:prevent-rebalance

当增加新节点时或是需要再平衡时防止再平衡发生,见 node auto scaling 以获取更多细节。

docker:auto-scale:run-interval

自动扩展算法的两次周期性运行所间隔的秒数。缺省为 3600 秒 (1 小时)。

docker:auto-scale:scale-down-ratio

收缩时所用的比率。必须大于 1.0。见 node auto scaling 以获取更多细节。缺省为 1.33。

IaaS 配置

tsuru 使用 IaaS 配置来自动创建新的 docker 节点并用 docker-node-add 命令把它们加到你的集群中。见 adding nodes 以获取更多关于如何使用这一命令的细节。

注意
你需配置 queue 才能使用 IaaS。

常规设置

iaas:default

当不指定 iaas=<iaas_name> 作为元数据来调用 docker-node-add 时 tsuru 将使用的缺省 IaaS。缺省为 ec2

iaas:node-protocol

在所创建的节点中访问 docker api 时所用的协议。缺省为 http

iaas:node-port

在所创建的节点中 docker API 将被访问时所用的端口。缺省为 2375

iaas:collection

数据库中包含有关所创建机器的信息的集合名字。缺省为 iaas_machines

EC2 IaaS

iaas:ec2:key-id

你的 AWS 秘钥 id。

iaas:ec2:secret-key

你的 AWS 机密秘钥。

iaas:ec2:user-data

响应 body 作为用户数据被发送到 ec2 时的 url。缺省会到一个将运行 tsuru now installation 的脚本。

iaas:ec2:wait-timeout

等待一个机器创建的秒数。缺省为 300(5分钟)。

CloudStack IaaS

iaas:cloudstack:api-key

你的 api 秘钥。

iaas:cloudstack:secret-key

你的秘钥。

iaas:cloudstack:url

cloudstack api 的 url。

iaas:cloudstack:user-data

响应 body 作为用户数据被发送到 cloudstack 时的 url。缺省会到一个将运行 tsuru now installation 的脚本。

iaas:cloudstack:wait-timeout

等待一个机器创建的秒数。缺省为 300(5分钟)。

DigitalOcean IaaS

iaas:digitalocean:token

与 DigitalOcean API 通信时所用的访问 token。

iaas:digitalocean:url

DigitalOcean API 的 URL。 这是可选的,缺省为 "https://api.digitalocean.com/"。

iaas:digitalocean:user-data

响应 body 作为用户数据被发送到 DigitalOcean 时的 URL。缺省会到一个将运行 tsuru now installation 的脚本。

自定义 IaaS

你可以基于现存的提供商自定义一个 IaaS。任何 iaas:custom:<name> 格式的配置键值将创建一个新的叫做 name 的 IaaS。

iaas:custom:<name>:provider

基础提供者名字,它可以是以下支持的提供者之一:cloudstackec2

iaas:custom:<name>:<any_other_option>

对此 IaaS,这将覆盖 iaas:<provider>:<any_other_option> 的值。作为一例子,下述配置允许你调用 tsuru-admin docker-node-add iaas=region1_cloudstack …

  1. iaas:
  2. custom:
  3. region1_cloudstack:
  4. provider: cloudstack
  5. url: http://region1.url/
  6. secret-key: mysecretkey
  7. cloudstack:
  8. api-key: myapikey

示例文件

以下是一个完整的例子:

  1. listen: "0.0.0.0:8080"
  2. debug: true
  3. host: http://<machine-public-addr>:8080 # This port must be the same as in the "listen" conf
  4. auth:
  5. user-registration: true
  6. scheme: native
  7. database:
  8. url: <your-mongodb-server>:27017
  9. name: tsurudb
  10. pubsub:
  11. redis-host: <your-redis-server>
  12. redis-port: 6379
  13. queue:
  14. mongo-url: <your-mongodb-server>:27017
  15. mongo-database: queuedb
  16. git:
  17. api-server: http://<your-gandalf-server>:8000
  18. provisioner: docker
  19. docker:
  20. router: hipache
  21. collection: docker_containers
  22. repository-namespace: tsuru
  23. deploy-cmd: /var/lib/tsuru/deploy
  24. cluster:
  25. storage: mongodb
  26. mongo-url: <your-mongodb-server>:27017
  27. mongo-database: cluster
  28. run-cmd:
  29. bin: /var/lib/tsuru/start
  30. port: "8888"
  31. routers:
  32. hipache:
  33. type: hipache
  34. domain: <your-hipache-server-ip>.xip.io
  35. redis-server: <your-redis-server-with-port>

原文: http://doc.oschina.net/tsuru-paas?t=53190