配置
7. Maven 资源
Spring Cloud Dataflow 支持通过 Maven (maven:
).
如果要覆盖特定的 Maven 配置属性(远程存储库、代理等)或在代理后面运行数据流服务器,
启动数据流服务器时,需要将这些属性指定为命令行参数,如以下示例所示:
$ java -jar spring-cloud-dataflow-server-2.11.5.jar --spring.config.additional-location=/home/joe/maven.yml
前面的命令假定maven.yaml
类似于以下内容:
maven:
localRepository: mylocal
remote-repositories:
repo1:
url: https://repo1
auth:
username: user1
password: pass1
snapshot-policy:
update-policy: daily
checksum-policy: warn
release-policy:
update-policy: never
checksum-policy: fail
repo2:
url: https://repo2
policy:
update-policy: always
checksum-policy: fail
proxy:
host: proxy1
port: "9010"
auth:
username: proxyuser1
password: proxypass1
默认情况下,协议设置为http
.如果代理不需要用户名和密码,则可以省略身份验证属性。此外,默认情况下,mavenlocalRepository
设置为${user.home}/.m2/repository/
.
如前面的示例所示,您可以指定远程存储库及其身份验证(如果需要)。如果远程存储库位于代理后面,则可以指定代理属性,如前面的示例所示。
您可以为每个远程存储库配置指定存储库策略,如前面的示例所示。
关键policy
适用于snapshot
和release
存储库策略。
因为这些是 Spring Boot@ConfigurationProperties
您需要通过将它们添加到SPRING_APPLICATION_JSON
环境变量。以下示例显示了 JSON 的结构:
$ SPRING_APPLICATION_JSON='
{
"maven": {
"local-repository": null,
"remote-repositories": {
"repo1": {
"url": "https://repo1",
"auth": {
"username": "repo1user",
"password": "repo1pass"
}
},
"repo2": {
"url": "https://repo2"
}
},
"proxy": {
"host": "proxyhost",
"port": 9018,
"auth": {
"username": "proxyuser",
"password": "proxypass"
}
}
}
}
'
7.1. 马车
对使用Wagon
使用 Maven 传输。目前,这个
存在以支持http
基于存储库
并且需要手动启用。
基于货车http
通过设置maven.use-wagon
财产
自true
.然后,您可以为每个远程启用抢占式身份验证
存储 库。配置松散地遵循 HttpClient HTTP Wagon 中的类似模式。
在撰写本文时,Maven 自己网站上的文档略有误导性
并且缺少大多数可能的配置选项。
这maven.remote-repositories.<repo>.wagon.http
命名空间包含所有 Wagonhttp
相关设置,其正下方的键映射到 Supportedhttp
方法 — 即all
,put
,get
和head
,就像在 Maven 自己的配置中一样。
在这些方法配置下,您可以设置各种选项,例如use-preemptive
.用于发送身份验证的简单抢占式配置
header 包含对指定远程存储库的所有请求,如下所示:
maven:
use-wagon: true
remote-repositories:
springRepo:
url: https://repo.example.org
wagon:
http:
all:
use-preemptive: true
auth:
username: user
password: password
而不是配置all
方法,您可以调整get
和head
仅请求,如下所示:
maven:
use-wagon: true
remote-repositories:
springRepo:
url: https://repo.example.org
wagon:
http:
get:
use-preemptive: true
head:
use-preemptive: true
use-default-headers: true
connection-timeout: 1000
read-timeout: 1000
headers:
sample1: sample2
params:
http.socket.timeout: 1000
http.connection.stalecheck: true
auth:
username: user
password: password
有设置use-default-headers
,connection-timeout
,read-timeout
请求headers
和 HttpClientparams
.有关参数的更多信息,
请参阅 Wagon ConfigurationUtils。
8. 安全
默认情况下,数据流服务器不安全,并在未加密的 HTTP 连接上运行。 您可以通过启用 HTTPS 来保护 REST 端点以及数据流仪表板 并要求客户端使用 OAuth 2.0 进行身份验证。
附录 Azure 包含详细信息,如何 设置 Azure Active Directory 集成。 |
默认情况下,REST 端点(管理、管理和运行状况)以及仪表板 UI 不需要经过身份验证的访问权限。 |
虽然理论上你可以选择任何 OAuth 提供程序与 Spring Cloud Data Flow,我们建议使用 CloudFoundry 用户帐户和身份验证 (UAA) 服务器。
UAA OpenID 不仅经过认证并被 Cloud Foundry 使用,而且您可以 也可以在本地独立部署方案中使用它。此外,UAA 不是 只提供自己的用户存储,但也提供了全面的LDAP集成。
8.1. 启用 HTTPS
默认情况下,仪表板、管理和运行状况终结点使用 HTTP 作为传输。
您可以通过在application.yml
,如以下示例所示:
server:
port: 8443 (1)
ssl:
key-alias: yourKeyAlias (2)
key-store: path/to/keystore (3)
key-store-password: yourKeyStorePassword (4)
key-password: yourKeyPassword (5)
trust-store: path/to/trust-store (6)
trust-store-password: yourTrustStorePassword (7)
1 | 由于默认端口是9393 ,您可以选择将端口更改为更常见的 HTTP 典型端口。 |
2 | 密钥存储在密钥库中的别名(或名称)。 |
3 | 密钥库文件的路径。您还可以使用类路径前缀指定类路径资源 - 例如:classpath:path/to/keystore . |
4 | 密钥库的密码。 |
5 | 密钥的密码。 |
6 | 信任库文件的路径。您还可以使用类路径前缀指定类路径资源 - 例如:classpath:path/to/trust-store |
7 | 信任存储的密码。 |
如果启用了 HTTPS,它将完全取代 HTTP 作为协议 REST 端点和数据流仪表板交互。纯 HTTP 请求 失败。因此,请确保相应地配置 Shell。 |
使用自签名证书
出于测试目的或在开发过程中,创建自签名证书可能很方便。 首先,请执行以下命令创建证书:
$ keytool -genkey -alias dataflow -keyalg RSA -keystore dataflow.keystore \
-validity 3650 -storetype JKS \
-dname "CN=localhost, OU=Spring, O=Pivotal, L=Kailua-Kona, ST=HI, C=US" (1)
-keypass dataflow -storepass dataflow
1 | CN 是这里的重要参数。它应该与您尝试访问的域匹配 - 例如,localhost . |
然后将以下行添加到您的application.yml
文件:
server:
port: 8443
ssl:
enabled: true
key-alias: dataflow
key-store: "/your/path/to/dataflow.keystore"
key-store-type: jks
key-store-password: dataflow
key-password: dataflow
这就是您需要为数据流服务器执行的所有作。启动服务器后,
您应该能够在localhost:8443/
. 由于这是一个自签名证书,您应该在浏览器中点击警告,该警告你需要忽略。
切勿在生产中使用自签名证书。 |
自签名证书和 Shell
默认情况下,自签名证书是 shell 的问题,其他步骤 是使 shell 使用自签名证书所必需的。两种选择 可用:
-
将自签名证书添加到 JVM 信任库。
-
跳过证书验证。
将自签名证书添加到 JVM 信任库
为了使用 JVM 信任库选项,您需要 从密钥库导出先前创建的证书,如下所示:
$ keytool -export -alias dataflow -keystore dataflow.keystore -file dataflow_cert -storepass dataflow
接下来,您需要创建一个 shell 可以使用的信任库,如下所示:
$ keytool -importcert -keystore dataflow.truststore -alias dataflow -storepass dataflow -file dataflow_cert -noprompt
现在,您已准备好使用以下 JVM 参数启动 Data Flow Shell:
$ java -Djavax.net.ssl.trustStorePassword=dataflow \
-Djavax.net.ssl.trustStore=/path/to/dataflow.truststore \
-Djavax.net.ssl.trustStoreType=jks \
-jar spring-cloud-dataflow-shell-2.11.5.jar
如果您在通过 SSL 建立连接时遇到问题,您可以启用其他
通过使用和设置 |
不要忘记使用以下命令以数据流服务器为目标:
dataflow:> dataflow config server --uri https://localhost:8443/
8.2. 使用 OAuth 2.0 进行身份验证
为了支持身份验证和授权,Spring Cloud Data Flow 使用 OAuth 2.0。 它允许您将 Spring Cloud Data Flow 集成到单点登录 (SSO) 中 环境。
从 Spring Cloud Data Flow 2.0 开始,OAuth2 是唯一的机制 用于提供身份验证和授权。 |
使用以下 OAuth2 授权类型:
-
授权码:用于 GUI(浏览器)集成。访问者将重定向到您的 OAuth 服务进行身份验证
-
密码:由 shell(和 REST 集成)使用,因此访问者可以使用用户名和密码登录
-
客户端凭据:直接从 OAuth 提供程序检索访问Tokens,并使用 Authorization HTTP 标头将其传递给数据流服务器
目前,Spring Cloud Data Flow 使用不透明的Tokens,不透明 Tokens (JWT)。 |
您可以通过两种方式访问 REST 终结点:
-
基本身份验证,它使用密码授予类型向 OAuth2 服务进行身份验证
-
访问Tokens,它使用客户端凭据授予类型
设置身份验证时,您确实应该启用 HTTPS 同样,尤其是在生产环境中。 |
您可以通过将以下内容添加到application.yml
或通过设置
环境变量。以下示例显示了CloudFoundry用户帐户和身份验证(UAA)服务器所需的最低设置:
spring:
security:
oauth2: (1)
client:
registration:
uaa: (2)
client-id: myclient
client-secret: mysecret
redirect-uri: '{baseUrl}/login/oauth2/code/{registrationId}'
authorization-grant-type: authorization_code
scope:
- openid (3)
provider:
uaa:
jwk-set-uri: http://uaa.local:8080/uaa/token_keys
token-uri: http://uaa.local:8080/uaa/oauth/token
user-info-uri: http://uaa.local:8080/uaa/userinfo (4)
user-name-attribute: user_name (5)
authorization-uri: http://uaa.local:8080/uaa/oauth/authorize
resourceserver:
opaquetoken:
introspection-uri: http://uaa.local:8080/uaa/introspect (6)
client-id: dataflow
client-secret: dataflow
1 | 提供此属性会激活 OAuth2 安全性。 |
2 | 提供程序 ID。您可以指定多个提供程序。 |
3 | 由于 UAA 是 OpenID 提供程序,因此您必须至少指定openid 范围。
如果提供程序还提供其他范围来控制角色分配,
您还必须在此处指定这些范围。 |
4 | OpenID 端点。用于检索用户信息,例如用户名。命令的。 |
5 | 包含用户名的响应的 JSON 属性。 |
6 | 用于自省和验证直接传入的Tokens。命令的。 |
您可以使用 curl 验证基本身份验证是否正常工作,如下所示:
curl -u myusername:mypassword http://localhost:9393/ -H 'Accept: application/json'
因此,您应该会看到可用 REST 终结点的列表。
当您使用 Web 浏览器访问根 URL 时,并且
启用安全性,则将您重定向到仪表板 UI。要查看
REST 端点列表,请指定application/json Accept 页眉。还要确定
添加Accept 标头,使用 Postman (Chrome) 等工具
或 RESTClient (Firefox)。 |
除了基本身份验证之外,您还可以提供访问Tokens,以 访问 REST API。为此,请检索 OAuth2 访问Tokens,并将该访问Tokens传递给 REST API 使用授权 HTTP 标头,如下所示:
$ curl -H "Authorization: Bearer <ACCESS_TOKEN>" http://localhost:9393/ -H 'Accept: application/json'
8.3. 自定义授权
前面的内容主要涉及身份验证,即如何评估 用户的身份。在本节中,我们将讨论可用的授权选项,即谁可以做什么。
授权规则在dataflow-server-defaults.yml
(部分
Spring Cloud Data Flow Core 模块)。
由于安全角色的确定是特定于环境的,
默认情况下,Spring Cloud Data Flow 将所有角色分配给经过身份验证的 OAuth2
用户。这DefaultDataflowAuthoritiesExtractor
class 用于此目的。
或者,您可以让 Spring Cloud Data Flow 通过以下方式将 OAuth2 范围映射到数据流角色
设置布尔属性map-oauth-scopes
让您的提供者true
(默认值为false
).
例如,如果您的提供商的 ID 是uaa
,则属性将为spring.cloud.dataflow.security.authorization.provider-role-mappings.uaa.map-oauth-scopes
.
角色映射
默认情况下,所有角色都分配给登录 Spring Cloud Data Flow 的用户。但是,您可以设置属性:
spring.cloud.dataflow.security.authorization.provider-role-mappings.uaa.map-oauth-scopes: true
这将指示底层DefaultAuthoritiesExtractor
将OAuth 范围映射到相应的权限。支持以下范围:
-
范围
dataflow.create
映射到CREATE
角色 -
范围
dataflow.deploy
映射到DEPLOY
角色 -
范围
dataflow.destroy
映射到DESTROY
角色 -
范围
dataflow.manage
映射到MANAGE
角色 -
范围
dataflow.modify
映射到MODIFY
角色 -
范围
dataflow.schedule
映射到SCHEDULE
角色 -
范围
dataflow.view
映射到VIEW
角色
此外,还可以将任意范围映射到每个数据流角色:
spring:
cloud:
dataflow:
security:
authorization:
provider-role-mappings:
uaa:
map-oauth-scopes: true (1)
role-mappings:
ROLE_CREATE: dataflow.create (2)
ROLE_DEPLOY: dataflow.deploy
ROLE_DESTROY: dataflow.destoy
ROLE_MANAGE: dataflow.manage
ROLE_MODIFY: dataflow.modify
ROLE_SCHEDULE: dataflow.schedule
ROLE_VIEW: dataflow.view
1 | 启用从 OAuth 范围到数据流角色的显式映射支持 |
2 | 启用角色映射支持后,必须提供所有 7 个 Spring Cloud Data Flow 角色ROLE_CREATE、ROLE_DEPLOY、ROLE_DESTROY、ROLE_MANAGE、ROLE_MODIFY、ROLE_SCHEDULE ROLE_VIEW。 |
您可以将 OAuth 范围分配给多个 Spring Cloud Data Flow 角色,从而灵活地调整授权配置的粒度。 |
组映射
从作用域映射角色有其自身的问题,因为它可能并不总是可行的更改给定身份提供者中的这些。如果可以定义组声明在从身份提供者返回的Tokens中,这些也可以用于映射到服务器角色。
spring:
cloud:
dataflow:
security:
authorization:
provider-role-mappings:
uaa:
map-oauth-scopes: false
map-group-claims: true
group-claim: roles
group-mappings:
ROLE_CREATE: my-group-id
ROLE_DEPLOY: my-group-id
ROLE_DESTROY: my-group-id
ROLE_MANAGE: my-group-id
ROLE_MODIFY: my-group-id
ROLE_SCHEDULE: my-group-id
ROLE_VIEW: my-group-id
您还可以通过提供自己的 Spring bean 定义来自定义角色映射行为,该定义扩展 Spring Cloud Data Flow 的AuthorityMapper
接口。 在这种情况下,自定义 Bean 定义优先于Spring Cloud Data Flow 提供的默认定义。
默认方案使用七个角色来保护 Spring Cloud Data Flow 公开的 REST 端点:
-
ROLE_CREATE:用于任何涉及创建的内容,例如创建流或任务
-
ROLE_DEPLOY:用于部署流或启动任务
-
ROLE_DESTROY:用于涉及删除流、任务等的任何内容。
-
ROLE_MANAGE:对于启动管理终结点
-
ROLE_MODIFY:对于任何涉及改变系统状态的事情
-
ROLE_SCHEDULE:用于计划相关作(例如计划任务)
-
ROLE_VIEW:对于与检索状态相关的任何内容
如本节前面所述,指定了所有与授权相关的默认设置
在dataflow-server-defaults.yml
,它是 Spring Cloud Data Flow Core 的一部分
模块。不过,如果需要,您可以覆盖这些设置,例如
在application.yml
.配置采用 YAML 列表的形式(如一些
规则可能优先于其他规则)。因此,您需要复制和粘贴
整个列表并根据您的需要进行定制(因为无法合并列表)。
始终参考您的版本application.yml 文件,因为以下代码段可能已过时。 |
默认规则如下:
spring:
cloud:
dataflow:
security:
authorization:
enabled: true
loginUrl: "/"
permit-all-paths: "/authenticate,/security/info,/assets/**,/dashboard/logout-success-oauth.html,/favicon.ico"
rules:
# About
- GET /about => hasRole('ROLE_VIEW')
# Audit
- GET /audit-records => hasRole('ROLE_VIEW')
- GET /audit-records/** => hasRole('ROLE_VIEW')
# Boot Endpoints
- GET /management/** => hasRole('ROLE_MANAGE')
# Apps
- GET /apps => hasRole('ROLE_VIEW')
- GET /apps/** => hasRole('ROLE_VIEW')
- DELETE /apps/** => hasRole('ROLE_DESTROY')
- POST /apps => hasRole('ROLE_CREATE')
- POST /apps/** => hasRole('ROLE_CREATE')
- PUT /apps/** => hasRole('ROLE_MODIFY')
# Completions
- GET /completions/** => hasRole('ROLE_VIEW')
# Job Executions & Batch Job Execution Steps && Job Step Execution Progress
- GET /jobs/executions => hasRole('ROLE_VIEW')
- PUT /jobs/executions/** => hasRole('ROLE_MODIFY')
- GET /jobs/executions/** => hasRole('ROLE_VIEW')
- GET /jobs/thinexecutions => hasRole('ROLE_VIEW')
# Batch Job Instances
- GET /jobs/instances => hasRole('ROLE_VIEW')
- GET /jobs/instances/* => hasRole('ROLE_VIEW')
# Running Applications
- GET /runtime/streams => hasRole('ROLE_VIEW')
- GET /runtime/streams/** => hasRole('ROLE_VIEW')
- GET /runtime/apps => hasRole('ROLE_VIEW')
- GET /runtime/apps/** => hasRole('ROLE_VIEW')
# Stream Definitions
- GET /streams/definitions => hasRole('ROLE_VIEW')
- GET /streams/definitions/* => hasRole('ROLE_VIEW')
- GET /streams/definitions/*/related => hasRole('ROLE_VIEW')
- POST /streams/definitions => hasRole('ROLE_CREATE')
- DELETE /streams/definitions/* => hasRole('ROLE_DESTROY')
- DELETE /streams/definitions => hasRole('ROLE_DESTROY')
# Stream Deployments
- DELETE /streams/deployments/* => hasRole('ROLE_DEPLOY')
- DELETE /streams/deployments => hasRole('ROLE_DEPLOY')
- POST /streams/deployments/** => hasRole('ROLE_MODIFY')
- GET /streams/deployments/** => hasRole('ROLE_VIEW')
# Stream Validations
- GET /streams/validation/ => hasRole('ROLE_VIEW')
- GET /streams/validation/* => hasRole('ROLE_VIEW')
# Stream Logs
- GET /streams/logs/* => hasRole('ROLE_VIEW')
# Task Definitions
- POST /tasks/definitions => hasRole('ROLE_CREATE')
- DELETE /tasks/definitions/* => hasRole('ROLE_DESTROY')
- GET /tasks/definitions => hasRole('ROLE_VIEW')
- GET /tasks/definitions/* => hasRole('ROLE_VIEW')
# Task Executions
- GET /tasks/executions => hasRole('ROLE_VIEW')
- GET /tasks/executions/* => hasRole('ROLE_VIEW')
- POST /tasks/executions => hasRole('ROLE_DEPLOY')
- POST /tasks/executions/* => hasRole('ROLE_DEPLOY')
- DELETE /tasks/executions/* => hasRole('ROLE_DESTROY')
- GET /tasks/thinexecutions => hasRole('ROLE_VIEW')
# Task Schedules
- GET /tasks/schedules => hasRole('ROLE_VIEW')
- GET /tasks/schedules/* => hasRole('ROLE_VIEW')
- GET /tasks/schedules/instances => hasRole('ROLE_VIEW')
- GET /tasks/schedules/instances/* => hasRole('ROLE_VIEW')
- POST /tasks/schedules => hasRole('ROLE_SCHEDULE')
- DELETE /tasks/schedules/* => hasRole('ROLE_SCHEDULE')
# Task Platform Account List */
- GET /tasks/platforms => hasRole('ROLE_VIEW')
# Task Validations
- GET /tasks/validation/ => hasRole('ROLE_VIEW')
- GET /tasks/validation/* => hasRole('ROLE_VIEW')
# Task Logs
- GET /tasks/logs/* => hasRole('ROLE_VIEW')
# Tools
- POST /tools/** => hasRole('ROLE_VIEW')
每行的格式如下:
HTTP_METHOD URL_PATTERN '=>' SECURITY_ATTRIBUTE
哪里:
-
HTTP_METHOD是一种 HTTP 方法(例如 PUT 或 GET),大写。
-
URL_PATTERN 是一种 Ant 风格的 URL 模式。
-
SECURITY_ATTRIBUTE 是一个 SpEL 表达式。请参阅基于表达式的访问控制。
-
其中每个字符都由一个或空格字符(空格、制表符等)分隔。
请注意,上面是一个 YAML 列表,而不是地图(因此使用“-”破折号在每行的开头)位于spring.cloud.dataflow.security.authorization.rules
钥匙。
授权 — Shell 和仪表板行为
启用安全性后,仪表板和 shell 是角色感知的,这意味着,根据分配的角色,并非所有功能都可见。
例如,用户没有必要角色的 shell 命令被标记为不可用。
目前,shell 的 |
相反,对于仪表板,UI 不显示页面或页面元素 用户未获得授权。
保护 Spring Boot 管理端点
启用安全性后,Spring Boot HTTP 管理端点的保护方式与其他 REST 端点相同。管理 REST 端点
可在以下位置找到/management
并要求MANAGEMENT
角色。
中的默认配置dataflow-server-defaults.yml
如下:
management:
endpoints:
web:
base-path: /management
security:
roles: MANAGE
目前,您不应自定义默认管理路径。 |
8.4. 设置 UAA 身份验证
对于本地部署场景,我们建议使用 CloudFoundry 用户 帐户和身份验证 (UAA) 服务器,已通过 OpenID 认证。 虽然 UAA 由 Cloud Foundry 使用, 它也是一个功能齐全的独立 OAuth2 服务器,具有企业功能,例如 LDAP 集成。
要求
您需要签出、构建和运行 UAA。为此,请确保您:
如果您在安装 uaac 时遇到问题,您可能必须将GEM_HOME
环境
变量:
export GEM_HOME="$HOME/.gem"
您还应该确保~/.gem/gems/cf-uaac-4.2.0/bin
已添加到您的路径中。
为 JWT 准备 UAA
由于 UAA 是 OpenID 提供程序并使用 JSON Web Tokens (JWT),因此它需要具有 用于签署这些 JWT 的私钥:
openssl genrsa -out signingkey.pem 2048
openssl rsa -in signingkey.pem -pubout -out verificationkey.pem
export JWT_TOKEN_SIGNING_KEY=$(cat signingkey.pem)
export JWT_TOKEN_VERIFICATION_KEY=$(cat verificationkey.pem)
稍后,一旦 UAA 启动,您可以在访问时看到密钥uaa:8080/uaa/token_keys
.
在这里,uaa 在 URL 中uaa:8080/uaa/token_keys 是主机名。 |
下载并启动 UAA
要下载并安装 UAA,请运行以下命令:
git clone https://github.com/pivotal/uaa-bundled.git
cd uaa-bundled
./mvnw clean install
java -jar target/uaa-bundled-1.0.0.BUILD-SNAPSHOT.jar
UAA 的配置由 YAML 文件驱动uaa.yml
,或者您可以编写配置脚本
使用 UAA 命令行客户端:
uaac target http://uaa:8080/uaa
uaac token client get admin -s adminsecret
uaac client add dataflow \
--name dataflow \
--secret dataflow \
--scope cloud_controller.read,cloud_controller.write,openid,password.write,scim.userids,sample.create,sample.view,dataflow.create,dataflow.deploy,dataflow.destroy,dataflow.manage,dataflow.modify,dataflow.schedule,dataflow.view \
--authorized_grant_types password,authorization_code,client_credentials,refresh_token \
--authorities uaa.resource,dataflow.create,dataflow.deploy,dataflow.destroy,dataflow.manage,dataflow.modify,dataflow.schedule,dataflow.view,sample.view,sample.create\
--redirect_uri http://localhost:9393/login \
--autoapprove openid
uaac group add "sample.view"
uaac group add "sample.create"
uaac group add "dataflow.view"
uaac group add "dataflow.create"
uaac user add springrocks -p mysecret --emails [email protected]
uaac user add vieweronly -p mysecret --emails [email protected]
uaac member add "sample.view" springrocks
uaac member add "sample.create" springrocks
uaac member add "dataflow.view" springrocks
uaac member add "dataflow.create" springrocks
uaac member add "sample.view" vieweronly
上述脚本设置数据流客户端以及两个用户:
-
用户 springrocks 有两个作用域:
sample.view
和sample.create
. -
用户查看器只有一个范围:
sample.view
.
添加后,您可以快速仔细检查 UAA 是否创建了用户:
curl -v -d"username=springrocks&password=mysecret&client_id=dataflow&grant_type=password" -u "dataflow:dataflow" http://uaa:8080/uaa/oauth/token -d 'token_format=opaque'
前面的命令应生成类似于以下内容的输出:
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to uaa (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'dataflow'
> POST /uaa/oauth/token HTTP/1.1
> Host: uaa:8080
> Authorization: Basic ZGF0YWZsb3c6ZGF0YWZsb3c=
> User-Agent: curl/7.54.0
> Accept: */*
> Content-Length: 97
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 97 out of 97 bytes
< HTTP/1.1 200
< Cache-Control: no-store
< Pragma: no-cache
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Thu, 31 Oct 2019 21:22:59 GMT
<
* Connection #0 to host uaa left intact
{"access_token":"0329c8ecdf594ee78c271e022138be9d","token_type":"bearer","id_token":"eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vbG9jYWxob3N0OjgwODAvdWFhL3Rva2VuX2tleXMiLCJraWQiOiJsZWdhY3ktdG9rZW4ta2V5IiwidHlwIjoiSldUIn0.eyJzdWIiOiJlZTg4MDg4Ny00MWM2LTRkMWQtYjcyZC1hOTQ4MmFmNGViYTQiLCJhdWQiOlsiZGF0YWZsb3ciXSwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDkwL3VhYS9vYXV0aC90b2tlbiIsImV4cCI6MTU3MjYwMDE3OSwiaWF0IjoxNTcyNTU2OTc5LCJhbXIiOlsicHdkIl0sImF6cCI6ImRhdGFmbG93Iiwic2NvcGUiOlsib3BlbmlkIl0sImVtYWlsIjoic3ByaW5ncm9ja3NAc29tZXBsYWNlLmNvbSIsInppZCI6InVhYSIsIm9yaWdpbiI6InVhYSIsImp0aSI6IjAzMjljOGVjZGY1OTRlZTc4YzI3MWUwMjIxMzhiZTlkIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImNsaWVudF9pZCI6ImRhdGFmbG93IiwiY2lkIjoiZGF0YWZsb3ciLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJzcHJpbmdyb2NrcyIsInJldl9zaWciOiJlOTkyMDQxNSIsInVzZXJfaWQiOiJlZTg4MDg4Ny00MWM2LTRkMWQtYjcyZC1hOTQ4MmFmNGViYTQiLCJhdXRoX3RpbWUiOjE1NzI1NTY5Nzl9.bqYvicyCPB5cIIu_2HEe5_c7nSGXKw7B8-reTvyYjOQ2qXSMq7gzS4LCCQ-CMcb4IirlDaFlQtZJSDE-_UsM33-ThmtFdx--TujvTR1u2nzot4Pq5A_ThmhhcCB21x6-RNNAJl9X9uUcT3gKfKVs3gjE0tm2K1vZfOkiGhjseIbwht2vBx0MnHteJpVW6U0pyCWG_tpBjrNBSj9yLoQZcqrtxYrWvPHaa9ljxfvaIsOnCZBGT7I552O1VRHWMj1lwNmRNZy5koJFPF7SbhiTM8eLkZVNdR3GEiofpzLCfoQXrr52YbiqjkYT94t3wz5C6u1JtBtgc2vq60HmR45bvg","refresh_token":"6ee95d017ada408697f2d19b04f7aa6c-r","expires_in":43199,"scope":"scim.userids openid sample.create cloud_controller.read password.write cloud_controller.write sample.view","jti":"0329c8ecdf594ee78c271e022138be9d"}
通过使用token_format
参数,您可以请求Tokens为:
-
不透明
-
JWT
9. 配置 - 本地
9.1. 功能切换
Spring Cloud Data Flow Server 提供了一组特定的功能,可以在启动时启用/禁用这些功能。这些功能包括用于以下目的所有生命周期作和 REST 端点(服务器和客户端实现,包括 shell 和 UI):
-
流(需要 Skipper)
-
任务
-
任务计划程序
可以通过在启动数据流服务器时设置以下布尔属性来启用和禁用这些功能:
-
spring.cloud.dataflow.features.streams-enabled
-
spring.cloud.dataflow.features.tasks-enabled
-
spring.cloud.dataflow.features.schedules-enabled
默认情况(需要 Skipper)和任务处于启用状态,并且默认情况下禁用任务计划程序。
其余的/about
端点提供有关已启用和禁用的功能的信息。
9.2. Java主页
在启动 Spring Cloud Data Flow 或 Skipper Server 时,他们可能需要知道 Java 17 主页的位置,才能成功启动 Spring Boot 3 应用程序。
通过传递以下属性,可以提供路径。
java -jar spring-cloud-dataflow-server/target/spring-cloud-dataflow-server-{project-version}.jar \
--spring.cloud.dataflow.defaults.boot3.local.javaHomePath=/usr/lib/jvm/java-17 \
--spring.cloud.dataflow.defaults.boot2.local.javaHomePath=/usr/lib/jvm/java-1.8
9.3. 数据库
关系数据库用于存储流和任务定义以及已执行任务的状态。 Spring Cloud Data Flow 为 MariaDB、MySQL、Oracle、PostgreSQL、Db2、SQL Server 和 H2 提供模式。服务器启动时会自动创建模式。
MariaDB、MySQL(通过 MariaDB 驱动程序)、PostgreSQL、SQL Server 的 JDBC 驱动程序无需额外配置即可使用。要使用任何其他数据库,您需要将相应的 JDBC 驱动程序 jar 放在服务器的类路径上,如此处所述。 |
要配置数据库,必须设置以下属性:
-
spring.datasource.url
-
spring.datasource.username
-
spring.datasource.password
-
spring.datasource.driver-class-name
-
spring.jpa.database-platform
这username
和password
无论数据库如何,都是相同的。但是,url
和driver-class-name
每个数据库都不同,如下所示。
数据库 | spring.datasource.url | spring.datasource.driver-class-name | spring.jpa.数据库平台 | 包括Drivers |
---|---|---|---|---|
MariaDB 10.0 - 10.1 |
jdbc:mariadb://${db-hostname}:${db-port}/${db-name} |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MariaDB10方言 |
是的 |
MariaDB 10.2 |
jdbc:mariadb://${db-hostname}:${db-port}/${db-name} |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MariaDB102方言 |
是的 |
MariaDB 10.3 - 10.5 |
jdbc:mariadb://${db-hostname}:${db-port}/${db-name} |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MariaDB103方言 |
是的 |
MariaDB 10.6+ |
jdbc:mariadb://${db-hostname}:${db-port}/${db-name} |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MariaDB106方言[1] |
是的 |
MySQL 5.7 的 |
jdbc:mysql://${db-hostname}:${db-port}/${db-name}?permitMysqlScheme |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MySQL57方言 |
是的 |
MySQL 8.0+ |
jdbc:mysql://${db-hostname}:${db-port}/${db-name}?allowPublicKeyRetrieval=true&useSSL=false&autoReconnect=true&permitMysqlScheme[2] |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MySQL8Dialect |
是的 |
PostgresSQL |
jdbc:postgres://${db-hostname}:${db-port}/${db-name} |
org.postgresql.驱动程序 |
移除休眠默认值 |
是的 |
SQL 服务器 |
jdbc:sqlserver://${db-hostname}:${db-port};数据库名称=${db-name}&encrypt=false |
com.microsoft.sqlserver.jdbc.SQLServer驱动程序 |
移除休眠默认值 |
是的 |
DB2 |
jdbc:db2://${db-hostname}:${db-port}/{db-name} |
com.ibm.db2.jcc.DB2驱动程序 |
移除休眠默认值 |
不 |
神谕 |
JDBC:oracle:thin:@${db-hostname}:${db-port}/{db-name} |
oracle.jdbc.Oracle驱动程序 |
移除休眠默认值 |
不 |
9.3.1. H2
当没有配置其他数据库时,Spring Cloud Data Flow 使用 H2 数据库的嵌入式实例作为默认实例。
H2 适用于开发目的,但不建议用于生产用途,也不支持作为外部模式。 |
9.3.2. 数据库配置
在本地运行时,数据库属性可以作为环境变量或命令行参数传递给数据流服务器。例如,要使用命令行参数使用 MariaDB 启动服务器,请执行以下命令:
java -jar spring-cloud-dataflow-server/target/spring-cloud-dataflow-server-2.11.5.jar \
--spring.datasource.url=jdbc:mariadb://localhost:3306/mydb \
--spring.datasource.username=user \
--spring.datasource.password=pass \
--spring.datasource.driver-class-name=org.mariadb.jdbc.Driver
同样,要使用环境变量启动 MariaDB 服务器,请执行以下命令:
SPRING_DATASOURCE_URL=jdbc:mariadb://localhost:3306/mydb
SPRING_DATASOURCE_USERNAME=user
SPRING_DATASOURCE_PASSWORD=pass
SPRING_DATASOURCE_DRIVER_CLASS_NAME=org.mariadb.jdbc.Driver
SPRING_JPA_DATABASE_PLATFORM=org.hibernate.dialect.MariaDB106Dialect
java -jar spring-cloud-dataflow-server/target/spring-cloud-dataflow-server-2.11.5.jar
9.3.3. 模式处理
在默认情况下,数据库模式使用 Flyway 进行管理,如果它可以向数据库用户授予足够的权限。
以下是启动 Skipper 服务器时发生的情况的描述:
-
Flyway 检查是否
flyway_schema_history
table 存在。 -
如果架构不为空,则执行基线(到版本 1)作为数据流表如果使用共享数据库,则可能会到位。
-
如果模式为空,则 flyway 假定从头开始。
-
完成所有需要的架构迁移。
下面是启动 Dataflow 服务器时发生的情况说明:
-
Flyway 检查是否
flyway_schema_history_dataflow
table 存在。 -
如果模式不为空,则基线(到版本 1)作为 Skipper 表如果使用共享数据库,则可能会到位。
-
如果模式为空,则 flyway 假定从头开始。
-
完成所有需要的架构迁移。
我们的源代码模式中有模式 ddl,如果使用配置禁用 Flyway,则可以手动使用 |
9.4. Deployer 属性
您可以使用本地部署程序的以下配置属性来自定义流和任务的部署方式。
使用数据流 shell 进行部署时,可以使用语法deployer.<appName>.local.<deployerPropertyName>
.有关 shell 用法示例,请参见下文。
在数据流服务器中配置本地任务平台和在 Skipper 中配置本地平台以部署流时,也会使用这些属性。
部署程序属性名称 | 描述 | 默认值 |
---|---|---|
workingDirectoriesRoot |
所有创建的进程将在其中运行并创建日志文件的目录。 |
java.io.tmpdir |
envVarsTo 继承 |
传递给已启动应用程序的环境变量的正则表达式模式数组。 |
<WINDOWS 上的“TMP”、“LANG”、“LANGUAGE”、“LC_.*”、“PATH”、“SPRING_APPLICATION_JSON”>和 Unix 上的 <“TMP”、“LANG”、“LANGUAGE”、“LC_.*”、“PATH”> |
deleteFilesOnExit |
是否在 JVM 出口上删除已创建的文件和目录。 |
true |
javaCmd |
运行 java 的命令 |
Java |
javaHomePath.<bootVersion> |
JDK 安装路径,用于启动应用程序,具体取决于其注册的引导版本。 |
系统属性 |
shutdown超时 |
等待应用关闭的最大秒数。 |
30 |
java选项 |
要传递给 JVM 的 Java 选项,例如 -Dtest=foo |
<无> |
inheritLogging |
允许将日志重定向到触发子进程的进程的输出流。 |
false |
调试端口 |
用于远程调试的端口 |
<无> |
例如,要在ticktock
stream,请使用以部署属性。
dataflow:> stream create --name ticktock --definition "time --server.port=9000 | log"
dataflow:> stream deploy --name ticktock --properties "deployer.time.local.javaOpts=-Xmx2048m -Dtest=foo"
为方便起见,您可以将deployer.memory
属性来设置 Java 选项-Xmx
,如以下示例所示:
dataflow:> stream deploy --name ticktock --properties "deployer.time.memory=2048m"
在部署时,如果将-Xmx
选项中的deployer.<app>.local.javaOpts
属性,以及deployer.<app>.local.memory
选项,则javaOpts
属性具有优先权。此外,javaOpts
部署应用程序时设置的属性优先于数据流服务器的spring.cloud.deployer.local.javaOpts
财产。
9.5. 日志记录
Spring Cloud 数据流local
服务器自动配置为RollingFileAppender
用于日志记录。
日志记录配置位于名为logback-spring.xml
.
默认情况下,日志文件配置为使用:
<property name="LOG_FILE" value="${LOG_FILE:-${LOG_PATH:-${LOG_TEMP:-${java.io.tmpdir:-/tmp}}}/spring-cloud-dataflow-server-local.log}"/>
使用 logback 配置RollingPolicy
:
<appender name="FILE"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOG_FILE}</file>
<rollingPolicy
class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<!-- daily rolling -->
<fileNamePattern>${LOG_FILE}.${LOG_FILE_ROLLING_FILE_NAME_PATTERN:-%d{yyyy-MM-dd}}.%i.gz</fileNamePattern>
<maxFileSize>${LOG_FILE_MAX_SIZE:-100MB}</maxFileSize>
<maxHistory>${LOG_FILE_MAX_HISTORY:-30}</maxHistory>
<totalSizeCap>${LOG_FILE_TOTAL_SIZE_CAP:-500MB}</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>${FILE_LOG_PATTERN}</pattern>
</encoder>
</appender>
要检查java.io.tmpdir
对于当前的 Spring Cloud Data Flow Serverlocal
服务器
jinfo <pid> | grep "java.io.tmpdir"
如果要更改或覆盖任何属性LOG_FILE
,LOG_PATH
,LOG_TEMP
,LOG_FILE_MAX_SIZE
,LOG_FILE_MAX_HISTORY
和LOG_FILE_TOTAL_SIZE_CAP
,请将它们设置为系统属性。
9.6. 流
数据流服务器将流生命周期的管理委托给 Skipper 服务器。设置配置属性spring.cloud.skipper.client.serverUri
到 Skipper 的位置,例如
$ java -jar spring-cloud-dataflow-server-2.11.5.jar --spring.cloud.skipper.client.serverUri=https://192.51.100.1:7577/api
流的部署方式和平台的配置是通过配置platform accounts
在 Skipper 服务器上。
有关更多信息,请参阅有关平台的文档。
9.7. 任务
数据流服务器负责部署任务。
数据流启动的任务将其状态写入数据流服务器使用的同一数据库。
对于 Spring Batch Jobs 的任务,作业和步骤执行数据也存储在此数据库中。
与 Skipper 启动的流一样,任务可以启动到多个平台。
如果未定义平台,则名为default
使用 LocalDeployerProperties 类的默认值创建,该值汇总在表 Local Deployer Properties 中
要为本地平台配置新的平台帐户,请在spring.cloud.dataflow.task.platform.local
部分在您的application.yaml
文件或通过其他 Spring Boot 支持的机制。
在以下示例中,两个名为localDev
和localDevDebug
被创建。
键,例如shutdownTimeout
和javaOpts
是本地部署程序属性。
spring:
cloud:
dataflow:
task:
platform:
local:
accounts:
localDev:
shutdownTimeout: 60
javaOpts: "-Dtest=foo -Xmx1024m"
localDevDebug:
javaOpts: "-Xdebug -Xmx2048m"
通过将一个平台定义为default 允许您跳过使用platformName 否则需要使用它。 |
启动任务时,使用任务启动选项传递平台帐户名称的值--platformName
如果未传递platformName
,则值default
将被使用。
将任务部署到多个平台时,任务的配置需要连接到与数据流服务器相同的数据库。 |
您可以配置在本地运行的数据流服务器,以将任务部署到 Cloud Foundry 或 Kubernetes。有关更多信息,请参阅有关 Cloud Foundry 任务平台配置和 Kubernetes 任务平台配置的部分。
有关跨多个平台启动和计划任务的详细示例,请参阅此部分 dataflow.spring.io 上任务的多平台支持。
9.8. 安全配置
9.8.1. CloudFoundry用户帐户和身份验证(UAA)服务器
有关如何配置本地测试和开发的详细信息,请参阅 CloudFoundry 用户帐户和身份验证 (UAA) 服务器配置部分。
9.8.2. LDAP 身份验证
LDAP 身份验证(轻量级目录访问协议)是间接的 由 Spring Cloud Data Flow 使用 UAA 提供。UAA 本身提供全面的 LDAP 支持。
虽然您可以使用自己的 OAuth2 身份验证服务器,但 LDAP 支持 此处记录的需要使用 UAA 作为身份验证服务器。对于任何 其他提供商,请查阅该特定提供商的文档。 |
UAA 支持针对 LDAP(轻量级目录访问协议)进行身份验证 服务器使用以下模式:
与外部身份提供程序(如 LDAP)集成时,身份验证 在 UAA 内变得被链接。UAA 首先尝试使用 用户对 UAA 用户存储在外部提供程序之前的凭据, LDAP的。有关更多信息,请参阅用户帐户中的链式身份验证和身份验证 LDAP 集成 GitHub 文档。 |
LDAP 角色映射
OAuth2 身份验证服务器 (UAA) 提供全面的支持 用于将 LDAP 组映射到 OAuth 范围。
存在以下选项:
-
ldap/ldap-groups-null.xml
不会映射任何组 -
ldap/ldap-groups-as-scopes.xml
组名称将从 LDAP 属性中检索。例如CN
-
ldap/ldap-groups-map-to-scopes.xml
组将使用 external_group_mapping 表映射到 UAA 组
这些值通过配置属性指定ldap.groups.file controls
.在被窝里
这些值引用 Spring XML 配置文件。
在测试和开发期间,可能需要进行频繁的更改 LDAP 组和用户,并查看 UAA 中反映的内容。但是,用户 信息在登录期间被缓存。以下脚本 有助于快速检索更新的信息:
|
9.8.3. Spring Security OAuth2 资源/授权服务器示例
对于本地测试和开发,您还可以使用资源和授权 Spring Security 提供的服务器支持。它 允许您通过配置 SecurityFilterChain 轻松创建自己的 OAuth2 服务器。
可以在以下位置找到示例:Spring Security Samples
9.8.4. 数据流 Shell 身份验证
使用 Shell 时,可以通过用户名和密码提供凭据 或通过指定 credentials-provider 命令。如果您的 OAuth2 提供程序支持 密码授予类型,您可以使用以下命令来启动数据流 Shell:
$ java -jar spring-cloud-dataflow-shell-2.11.5.jar \
--dataflow.uri=http://localhost:9393 \ (1)
--dataflow.username=my_username \ (2)
--dataflow.password=my_password \ (3)
--skip-ssl-validation \ (4)
1 | 可选,默认为 localhost:9393。 |
2 | 命令的。 |
3 | 如果未提供密码,系统会提示用户输入密码。 |
4 | 可选,默认为false ,忽略证书错误(使用自签名证书时)。谨慎使用! |
请记住,启用 Spring Cloud Data Flow 的身份验证时, 基础 OAuth2 提供程序必须支持密码 OAuth2 授权类型 如果您想通过用户名/密码身份验证使用 Shell。 |
在数据流 Shell 中,还可以使用以下命令提供凭据:
server-unknown:>dataflow config server \
--uri http://localhost:9393 \ (1)
--username myuser \ (2)
--password mysecret \ (3)
--skip-ssl-validation \ (4)
1 | 可选,默认为 localhost:9393。 |
2 | 命令的。。 |
3 | 如果启用了安全性,但未提供密码,系统会提示用户输入密码。 |
4 | 可选,忽略证书错误(使用自签名证书时)。谨慎使用! |
下图显示了用于连接和验证数据的典型 shell 命令 流服务器:

成功定位后,应看到以下输出:
dataflow:>dataflow config info
dataflow config info
╔═══════════╤═══════════════════════════════════════╗
║Credentials│[username='my_username, password=****']║
╠═══════════╪═══════════════════════════════════════╣
║Result │ ║
║Target │http://localhost:9393 ║
╚═══════════╧═══════════════════════════════════════╝
或者,您可以指定 credentials-provider 命令,以便
直接传入持有者Tokens,而不是提供用户名和密码。
这可以在 shell 内部工作,或者通过提供--dataflow.credentials-provider-command
command-line 参数。
使用 credentials-provider 命令时,请注意您的 指定的命令必须返回 Bearer Tokens(以 Bearer 为前缀的访问Tokens)。 例如,在 Unix 环境中,可以使用以下简单命令:
|
9.9. 关于 API 配置
Spring Cloud Data Flow About Restful API 结果包含显示名称 版本,如果指定了,则为每个主要依赖项提供 URL 包括 Spring Cloud Data Flow。结果(如果启用)还包含 shell 依赖项的 sha1 和/或 sha256 校验和值。信息 为每个依赖项返回的 可以通过设置以下内容来配置 性能:
属性名称 | 描述 |
---|---|
spring.cloud.dataflow.version-info.spring-cloud-dataflow-core.name |
用于核心的名称 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-core.version |
用于核心的版本 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-dashboard.name |
用于仪表板的名称 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-dashboard.version |
用于仪表板的版本 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-implementation.name |
用于实现的名称 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-implementation.version |
用于实现的版本 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-shell.name |
要用于 shell 的名称 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-shell.version |
用于 shell 的版本 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-shell.url |
用于下载 shell 依赖项的 URL |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-shell.checksum-sha1 |
与 shell 依赖项信息一起返回的 Sha1 校验和值 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-shell.checksum-sha256 |
与 shell 依赖项信息一起返回的 Sha256 校验和值 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-shell.checksum-sha1-url |
如果 |
spring.cloud.dataflow.version-info.spring-cloud-dataflow-shell.checksum-sha256-url |
如果 |
9.9.1. 启用 Shell 校验和值
默认情况下,不显示 shell 依赖项的校验和值。如果
您需要启用此功能,请将spring.cloud.dataflow.version-info.dependency-fetch.enabled
属性设置为 true。
9.9.2. URL 的保留值
您可以插入保留值(用大括号括起来) 确保链接是最新的 URL:
-
repository
:如果使用 Data Flow,存储库是指 repo-spring-io 存储库。否则,它 指的是 Maven Central。 -
version
:插入 jar/pom 的版本。
例如
https://myrepository/org/springframework/cloud/spring-cloud-dataflow-shell/{version}/spring-cloud-dataflow-shell-\{version}.jar
生产
https://myrepository/org/springframework/cloud/spring-cloud-dataflow-shell/2.1.4/spring-cloud-dataflow-shell-2.11.0.jar
如果您使用2.11.0
Spring Cloud Data Flow Shell 版本。
10. 配置 - Cloud Foundry
本节介绍如何配置 Spring Cloud Data Flow 服务器的功能,例如安全性和要使用的关系数据库。 它还描述了如何配置 Spring Cloud Data Flow shell 的功能。
10.1. 功能切换
数据流服务器提供了一组特定的功能,您可以在启动时启用或禁用这些功能。这些功能包括用于以下内容的所有生命周期作和 REST 终结点(服务器、客户端实现,包括 Shell 和 UI):
-
流
-
任务
您可以通过在启动数据流服务器时设置以下布尔属性来启用或禁用这些功能:
-
spring.cloud.dataflow.features.streams-enabled
-
spring.cloud.dataflow.features.tasks-enabled
默认情况下,所有功能都处于启用状态。
REST 端点 (/features
) 提供有关启用和禁用功能的信息。
10.2. Deployer 属性
您可以使用数据流服务器的 Cloud Foundry 部署程序的以下配置属性来自定义应用程序的部署方式。
使用数据流 shell 进行部署时,可以使用语法deployer.<appName>.cloudfoundry.<deployerPropertyName>
.有关 shell 用法示例,请参见下文。
在 Data Flow 服务器中配置 Cloud Foundry Task 平台和 Skipper 中的 Kubernetes 平台以部署 Streams 时,也会使用这些属性。
部署程序属性名称 | 描述 | 默认值 |
---|---|---|
服务业 |
要绑定到已部署应用程序的服务的名称。 |
<无> |
主机 |
要用作路由一部分的主机名。 |
由 Cloud Foundry 派生的主机名 |
域 |
映射应用程序路由时要使用的域。 |
<无> |
路线 |
应用程序应绑定到的路由列表。与主机和域互斥。 |
<无> |
构建包 |
用于部署应用程序的 buildpack。已弃用的 buildpack。 |
|
构建包 |
用于部署应用程序的 buildpack 列表。 |
|
存储 |
要分配的内存量。默认单位为兆字节,支持“M”和“G”后缀 |
1024米 |
磁盘 |
要分配的磁盘空间量。默认单位为兆字节,支持“M”和“G”后缀。 |
1024米 |
健康检查 |
要对已部署的应用程序执行的运行状况检查类型。值可以是 HTTP、NONE、PROCESS 和 PORT |
端口 |
healthCheckHttp端点 |
http 运行状况检查将使用的路径, |
/健康 |
健康检查超时 |
运行状况检查的超时值(以秒为单位)。 |
120 |
实例 |
要运行的实例数。 |
1 |
enableRandomAppNamePrefix |
标志以启用为应用名称添加随机前缀的前缀。 |
true |
api超时 |
阻止 API 调用的超时(以秒为单位)。 |
360 |
状态超时 |
状态 API作超时(以毫秒为单位) |
5000 |
使用SpringApplicationJson |
指示应用程序属性是否馈送到 |
true |
暂存超时 |
为暂存应用程序分配的超时。 |
15分钟 |
启动超时 |
为启动应用程序分配的超时。 |
5分钟 |
appName前缀 |
用作已部署应用程序名称前缀的字符串 |
Spring Boot 属性 |
删除路由 |
取消部署应用程序时是否同时删除路由。 |
true |
java选项 |
要传递给 JVM 的 Java 选项,例如 -Dtest=foo |
<无> |
pushTasks启用 |
是推送任务应用程序还是假设应用程序在启动时已经存在。 |
true |
autoDeleteMavenArtifacts |
是否在部署时自动从本地存储库中删除 Maven 工件。 |
true |
env.<key> |
定义顶级环境变量。这对于自定义 Java 构建包配置非常有用,该配置必须作为顶级环境变量包含在应用程序清单中,因为 Java 构建包无法识别 |
部署程序确定应用程序的类路径中是否包含 Java CfEnv。如果是,则应用所需的配置。 |
以下是使用 Cloud Foundry 部署属性的一些示例:
-
您可以设置用于部署每个应用程序的 buildpack。例如,要使用 Java 离线构建, 设置以下环境变量:
cf set-env dataflow-server SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_BUILDPACKS java_buildpack_offline
-
设置
buildpack
现在已被弃用,取而代之的是buildpacks
如果需要,这允许您传递多个。有关这方面的更多信息,请参阅 Buildpack 的工作原理。 -
您可以自定义 Cloud Foundry 使用的运行状况检查机制,以使用
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_HEALTH_CHECK
环境变量。当前支持的选项 是http
(默认值),port
和none
.
您还可以设置环境变量来指定基于 HTTP 的运行状况检查端点和超时:SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_HEALTH_CHECK_ENDPOINT
和SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_HEALTH_CHECK_TIMEOUT
分别。这些默认为/health
(Spring Boot 默认位置)和120
秒。
-
还可以使用 DSL 指定部署属性。例如,如果您想为
http
应用程序到 512m,并将 Postgres 服务绑定到jdbc
应用程序,您可以运行以下命令:
dataflow:> stream create --name postgresstream --definition "http | jdbc --tableName=names --columns=name"
dataflow:> stream deploy --name postgresstream --properties "deployer.http.memory=512, deployer.jdbc.cloudfoundry.services=postgres"
可以为流应用和任务应用分别配置这些设置。要更改任务的设置,
替代
|
10.3. 任务
数据流服务器负责部署任务。
数据流启动的任务将其状态写入数据流服务器使用的同一数据库。
对于 Spring Batch Jobs 的任务,作业和步骤执行数据也存储在此数据库中。
与 Skipper 一样,任务可以启动到多个平台。
当数据流在 Cloud Foundry 上运行时,必须定义任务平台。
要配置面向 Cloud Foundry 的新平台帐户,请在spring.cloud.dataflow.task.platform.cloudfoundry
部分在您的application.yaml
文件。
在以下示例中,两个名为dev
和qa
被创建。
键,例如memory
和disk
是 Cloud Foundry Deployer 属性。
spring:
cloud:
dataflow:
task:
platform:
cloudfoundry:
accounts:
dev:
connection:
url: https://api.run.pivotal.io
org: myOrg
space: mySpace
domain: cfapps.io
username: [email protected]
password: drowssap
skipSslValidation: false
deployment:
memory: 512m
disk: 2048m
instances: 4
services: rabbit,postgres
appNamePrefix: dev1
qa:
connection:
url: https://api.run.pivotal.io
org: myOrgQA
space: mySpaceQA
domain: cfapps.io
username: [email protected]
password: drowssap
skipSslValidation: true
deployment:
memory: 756m
disk: 724m
instances: 2
services: rabbitQA,postgresQA
appNamePrefix: qa1
通过将一个平台定义为default 允许您跳过使用platformName 否则需要使用它。 |
启动任务时,使用任务启动选项传递平台帐户名称的值--platformName
如果未传递platformName
,则值default
将被使用。
将任务部署到多个平台时,任务的配置需要连接到与数据流服务器相同的数据库。 |
您可以配置 Cloud Foundry 上的数据流服务器,以将任务部署到 Cloud Foundry 或 Kubernetes。有关更多信息,请参阅有关 Kubernetes 任务平台配置的部分。
有关跨多个平台启动和计划任务的详细示例,请参阅此部分 dataflow.spring.io 上任务的多平台支持。
10.4. 应用程序名称和前缀
为了帮助避免与 Cloud Foundry 中跨空间的路由发生冲突,一种命名策略为
已部署的应用程序可用,并且默认启用。您可以使用以下命令覆盖默认配置并设置相应的属性cf set-env
命令。
例如,如果要禁用随机化,可以使用以下命令覆盖它:
cf set-env dataflow-server SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_ENABLE_RANDOM_APP_NAME_PREFIX false
10.5. 自定义路由
作为随机名称的替代方法,或者为了更好地控制已部署应用使用的主机名,您可以使用 自定义部署属性,如以下示例所示:
dataflow:>stream create foo --definition "http | log"
sdataflow:>stream deploy foo --properties "deployer.http.cloudfoundry.domain=mydomain.com,
deployer.http.cloudfoundry.host=myhost,
deployer.http.cloudfoundry.route-path=my-path"
前面的示例绑定了http
app 到myhost.mydomain.com/my-path
网址。请注意,这个
示例显示了所有可用的自定义选项。在实践中,您只能使用三者中的一两个。
10.6. Docker 应用程序
从版本 1.2 开始,可以使用以下命令将基于 Docker 的应用程序注册和部署为流和任务的一部分 Cloud Foundry 的数据流。
如果您使用 Spring Boot 和基于 RabbitMQ 的 Docker 镜像,则可以提供通用的部署属性
以方便将应用程序绑定到 RabbitMQ 服务。假设您的 RabbitMQ 服务名为rabbit
,您可以提供以下内容:
cf set-env dataflow-server SPRING_APPLICATION_JSON '{"spring.cloud.dataflow.applicationProperties.stream.spring.rabbitmq.addresses": "${vcap.services.rabbit.credentials.protocols.amqp.uris}"}'
对于 Spring Cloud Task 应用程序,如果您使用名为postgres
:
cf set-env SPRING_DATASOURCE_URL '${vcap.services.postgres.credentials.jdbcUrl}'
cf set-env SPRING_DATASOURCE_USERNAME '${vcap.services.postgres.credentials.username}'
cf set-env SPRING_DATASOURCE_PASSWORD '${vcap.services.postgres.credentials.password}'
cf set-env SPRING_DATASOURCE_DRIVER_CLASS_NAME 'org.mariadb.jdbc.Driver'
cf set-env SPRING_JPA_DATABASE_PLATFORM 'org.hibernate.dialect.MariaDB106Dialect'
对于非 Java 或非启动应用程序,您的 Docker 应用程序必须解析VCAP_SERVICES
变量,以便绑定到任何可用的服务。
传递应用程序属性
使用非引导应用程序时,您很可能希望使用传统的
环境变量,而不是使用 special
|
10.7. 应用程序级服务绑定
在 Cloud Foundry 中部署流时,您可以利用特定于应用程序的服务绑定,因此并非所有 服务是为 Spring Cloud Data Flow 编排的所有应用程序全局配置的。
例如,如果您想提供postgres
服务绑定仅适用于jdbc
以中的应用程序
定义,您可以将服务绑定作为部署属性传递:
dataflow:>stream create --name httptojdbc --definition "http | jdbc"
dataflow:>stream deploy --name httptojdbc --properties "deployer.jdbc.cloudfoundry.services=postgresService"
哪里postgresService
是仅专门绑定到jdbc
应用程序和http
应用程序不会通过此方法获取绑定。
如果要绑定多个服务,则可以将它们作为逗号分隔的项传递
(例如:deployer.jdbc.cloudfoundry.services=postgresService,someService
).
10.8. 配置服务绑定参数
CloudFoundry API 支持在绑定服务实例时提供配置参数。某些服务代理需要或 建议绑定配置。 例如,使用 CF CLI 绑定 Google Cloud Platform 服务如下所示:
cf bind-service my-app my-google-bigquery-example -c '{"role":"bigquery.user"}'
同样,NFS 卷服务支持绑定配置,例如:
cf bind-service my-app nfs_service_instance -c '{"uid":"1000","gid":"1000","mount":"/var/volume1","readonly":true}'
从 2.0 版开始,Cloud Foundry 的数据流允许您提供绑定配置参数,这些参数可以在应用程序级别或服务器级别提供cloudfoundry.services
deployment 属性。例如,要绑定到 nfs 服务,如上所示:
dataflow:> stream deploy --name mystream --properties "deployer.<app>.cloudfoundry.services='nfs_service_instance uid:1000,gid:1000,mount:/var/volume1,readonly:true'"
该格式旨在与数据流 DSL 解析器兼容。
通常,cloudfoundry.services
deployment 属性接受逗号分隔值。
由于逗号也用于分隔配置参数,并避免空格问题,因此包含配置参数的任何项目都必须用单引号括起来。有效值包括以下内容:
rabbitmq,'nfs_service_instance uid:1000,gid:1000,mount:/var/volume1,readonly:true',postgres,'my-google-bigquery-example role:bigquery.user'
允许在单引号内使用空格,并且可以使用空格来代替= : 以分隔键值对。 |
10.9. 用户提供的服务
除了市场服务外,Cloud Foundry 还支持用户提供的服务 (UPS)。在本参考手册中, 已经提到了常规服务,但没有什么可以排除使用用户提供的服务,无论是用作 消息传递中间件(例如,如果您想使用外部 Apache Kafka 安装)或供某些人使用 流应用程序(例如,Oracle 数据库)。
现在,我们回顾一下从 UPS 提取和提供连接凭据的示例。
以下示例显示了 Apache Kafka 的示例 UPS 设置:
cf create-user-provided-service kafkacups -p '{”brokers":"HOST:PORT","zkNodes":"HOST:PORT"}'
UPS 凭证包装在VCAP_SERVICES
,并且可以直接在流定义中提供它们,如以下示例所示。
stream create fooz --definition "time | log"
stream deploy fooz --properties "app.time.spring.cloud.stream.kafka.binder.brokers=${vcap.services.kafkacups.credentials.brokers},app.time.spring.cloud.stream.kafka.binder.zkNodes=${vcap.services.kafkacups.credentials.zkNodes},app.log.spring.cloud.stream.kafka.binder.brokers=${vcap.services.kafkacups.credentials.brokers},app.log.spring.cloud.stream.kafka.binder.zkNodes=${vcap.services.kafkacups.credentials.zkNodes}"
10.10. 数据库连接池
从 Data Flow 2.0 开始,不再使用 Spring Cloud Connector 库创建 DataSource。现在使用库 java-cfenv,它允许您设置 Spring Boot 属性来配置连接池。
10.11. 最大磁盘配额
默认情况下,Cloud Foundry 中的每个应用程序都以 1G 磁盘配额开始,并且可以将其调整为默认最大值2G。还可以使用 Pivotal Cloud Foundry (PCF) 的 Ops Manager GUI 覆盖默认最大值 10G。
此配置与 Spring Cloud Data Flow 相关,因为每个任务部署都由应用程序组成(通常是 Spring Boot uber-jar 的),并且这些应用程序是从远程 Maven 存储库解析的。解决后,应用程序工件将下载到本地 Maven 存储库以进行缓存和重用。当这种情况在后台发生时,默认磁盘配额 (1G) 可能会迅速填满,尤其是当我们尝试流时由独特的应用程序组成。为了克服此磁盘限制并根据您的扩展要求,您可能需要将默认最大值从 2G 更改为 10G。让我们回顾一下更改默认最大磁盘配额分配的步骤。
10.12. 规模应用
成功应用磁盘配额更改后,假设您有一个正在运行的应用程序,
您可以使用新的disk_limit
通过 CF CLI,如以下示例所示:
→ cf scale dataflow-server -k 10GB
Scaling app dataflow-server in org ORG / space SPACE as user...
OK
....
....
....
....
state since cpu memory disk details
#0 running 2016-10-31 03:07:23 PM 1.8% 497.9M of 1.1G 193.9M of 10G
然后,您可以列出应用程序并查看新的最大磁盘空间,如以下示例所示:
→ cf apps
Getting apps in org ORG / space SPACE as user...
OK
name requested state instances memory disk urls
dataflow-server started 1/1 1.1G 10G dataflow-server.apps.io
10.13. 管理磁盘使用
即使将数据流服务器配置为使用 10G 的空间,也有可能耗尽
本地磁盘上的可用空间。为了防止这种情况,jar
从外部源下载的工件,即注册为http
或maven
资源,无论部署请求是否成功,每当部署应用程序时都会自动删除。
此行为最适合容器运行时稳定性比部署期间产生的 I/O 延迟更重要的生产环境。
在开发环境中,部署更频繁地发生。此外,jar
工件(或打火机metadata
jar) 包含描述应用程序配置属性的元数据
它由与应用程序配置相关的各种作使用,在预生产活动期间更频繁地执行(有关详细信息,请参阅应用程序元数据)。
为了提供响应速度更快的交互式开发人员体验,但代价是预生产环境中的磁盘使用量增加,您可以设置 CloudFoundry 部署程序属性autoDeleteMavenArtifacts
自false
.
如果使用默认的port
运行状况检查类型,则必须显式监控服务器上的磁盘空间,以避免空间不足。
如果使用http
运行状况检查类型(请参阅下一个示例),如果磁盘空间不足,则会重新启动数据流服务器。
这是由于 Spring Boot 的磁盘空间健康指示器。
您可以使用具有management.health.diskspace
前缀。
对于 1.7 版,我们正在研究使用卷服务来存储数据流服务器.jar
工件,然后再将它们推送到 Cloud Foundry。
以下示例演示如何部署http
运行状况检查类型添加到名为/management/health
:
---
...
health-check-type: http
health-check-http-endpoint: /management/health
10.14. 应用程序解析替代方案
尽管我们建议将 Maven Artifactory 用于应用程序注册流应用程序, 在某些情况下,以下替代方法之一可能是有意义的。
-
借助 Spring Boot,我们可以在 Cloud Foundry 中提供静态内容。一个简单的 Spring Boot 应用程序可以捆绑所有必需的流和任务应用程序。通过拥有它 在 Cloud Foundry 上运行,静态应用程序就可以为 über-jar 提供服务。例如,从 shell 中,您可以注册 应用程序名称为
http-source.jar
通过使用--uri=http://<Route-To-StaticApp>/http-source.jar
. -
über-jar 可以托管在任何可通过 HTTP 访问的外部服务器上。它们可以从原始 GitHub URI 中解析 也。例如,在 shell 中,您可以使用名称
http-source.jar
通过使用--uri=http://<Raw_GitHub_URI>/http-source.jar
. -
Cloud Foundry 中的静态 Buildpack 支持是另一个 选择。 类似的 HTTP 解析也适用于此模型。
-
卷服务是另一个不错的选择。所需的 über-jar 可以托管在外部文件系统中。在卷服务的帮助下,您可以例如,使用
http-source.jar
通过使用--uri=file://<Path-To-FileSystem>/http-source.jar
.
10.15. 安全性
默认情况下,数据流服务器不安全,并在未加密的 HTTP 连接上运行。可以保护 REST 终结点
(以及数据流仪表板)通过启用 HTTPS 并要求客户端进行身份验证。
有关保护
REST 端点并配置为针对 OAUTH 后端(在 Cloud Foundry 上运行的 UAA 和 SSO)进行身份验证,
请参阅核心安全配置中的安全部分。您可以在dataflow-server.yml
或将它们作为环境变量传递给cf set-env
命令。
10.15.1. 身份验证
Spring Cloud Data Flow 可以与 Pivotal Single Sign-On Service 集成 (例如,在 PWS 上)或 Cloud Foundry 用户帐户和身份验证 (UAA) 服务器。
Pivotal 单点登录服务
将 Spring Cloud Data Flow 部署到 Cloud Foundry 时,可以绑定 应用程序添加到 Pivotal 单点登录服务。通过这样做,Spring Cloud 数据流利用 Java CFEnv, 它为 OAuth 2.0 提供特定于 Cloud Foundry 的自动配置支持。
为此,请将 Pivotal 单点登录服务绑定到数据流服务器应用程序,并 提供以下属性:
SPRING_CLOUD_DATAFLOW_SECURITY_CFUSEUAA: false (1)
SECURITY_OAUTH2_CLIENT_CLIENTID: "${security.oauth2.client.clientId}"
SECURITY_OAUTH2_CLIENT_CLIENTSECRET: "${security.oauth2.client.clientSecret}"
SECURITY_OAUTH2_CLIENT_ACCESSTOKENURI: "${security.oauth2.client.accessTokenUri}"
SECURITY_OAUTH2_CLIENT_USERAUTHORIZATIONURI: "${security.oauth2.client.userAuthorizationUri}"
SECURITY_OAUTH2_RESOURCE_USERINFOURI: "${security.oauth2.resource.userInfoUri}"
1 | 重要的是,该属性spring.cloud.dataflow.security.cf-use-uaa 设置为false |
非 Cloud Foundry 安全场景同样支持授权。 请参阅核心数据流安全配置中的安全部分。
由于角色的配置可能因环境而异,因此我们通过 默认将所有 Spring Cloud Data Flow 角色分配给用户。
您可以通过提供自己的行为来自定义此行为AuthoritiesExtractor
.
以下示例显示了一种可能的方法,用于设置自定义AuthoritiesExtractor
在UserInfoTokenServices
:
public class MyUserInfoTokenServicesPostProcessor
implements BeanPostProcessor {
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) {
if (bean instanceof UserInfoTokenServices) {
final UserInfoTokenServices userInfoTokenServices == (UserInfoTokenServices) bean;
userInfoTokenServices.setAuthoritiesExtractor(ctx.getBean(AuthoritiesExtractor.class));
}
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) {
return bean;
}
}
然后您可以在配置类中声明它,如下所示:
@Bean
public BeanPostProcessor myUserInfoTokenServicesPostProcessor() {
BeanPostProcessor postProcessor == new MyUserInfoTokenServicesPostProcessor();
return postProcessor;
}
云代工 UAA
Cloud Foundry 用户帐户和身份验证 (UAA) 的可用性取决于 Cloud Foundry 环境。
为了提供 UAA 集成,您必须提供必要的
OAuth2 配置属性(例如,通过将SPRING_APPLICATION_JSON
属性)。
以下 JSON 示例演示如何创建安全配置:
{
"security.oauth2.client.client-id": "scdf",
"security.oauth2.client.client-secret": "scdf-secret",
"security.oauth2.client.access-token-uri": "https://login.cf.myhost.com/oauth/token",
"security.oauth2.client.user-authorization-uri": "https://login.cf.myhost.com/oauth/authorize",
"security.oauth2.resource.user-info-uri": "https://login.cf.myhost.com/userinfo"
}
默认情况下,spring.cloud.dataflow.security.cf-use-uaa
属性设置为true
.此属性激活特殊的AuthoritiesExtractor
叫CloudFoundryDataflowAuthoritiesExtractor
.
如果您不使用 CloudFoundry UAA,您应该将spring.cloud.dataflow.security.cf-use-uaa
自false
.
在被窝里,这个AuthoritiesExtractor
调用 Cloud FoundryApps API,并确保用户实际上是 Space 开发人员。
如果经过身份验证的用户被验证为空间开发人员,则分配所有角色。
10.16. 配置参考
您必须提供几项配置。这些是 Spring Boot@ConfigurationProperties
,以便您可以将它们设置为它们作为环境变量或通过 Spring Boot 支持的任何其他方式。以下列表位于环境变量格式中,因为这是开始在 Cloud Foundry 中配置 Boot 应用程序的简单方法。请注意,将来您将能够将任务部署到多个平台,但对于 2.0.0.M1,您只能部署到单个平台,并且名称必须是default
.
# Default values appear after the equal signs.
# Example values, typical for Pivotal Web Services, are included as comments.
# URL of the CF API (used when using cf login -a for example) - for example, https://api.run.pivotal.io
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_URL=
# The name of the organization that owns the space above - for example, youruser-org
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_ORG=
# The name of the space into which modules will be deployed - for example, development
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SPACE=
# The root domain to use when mapping routes - for example, cfapps.io
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_DOMAIN=
# The user name and password of the user to use to create applications
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_USERNAME=
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_PASSWORD
# The identity provider to be used when accessing the Cloud Foundry API (optional).
# The passed string has to be a URL-Encoded JSON Object, containing the field origin with value as origin_key of an identity provider - for example, {"origin":"uaa"}
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_LOGIN_HINT=
# Whether to allow self-signed certificates during SSL validation (you should NOT do so in production)
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SKIP_SSL_VALIDATION
# A comma-separated set of service instance names to bind to every deployed task application.
# Among other things, this should include an RDBMS service that is used
# for Spring Cloud Task execution reporting, such as my_postgres
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_SERVICES
spring.cloud.deployer.cloudfoundry.task.services=
# Timeout, in seconds, to use when doing blocking API calls to Cloud Foundry
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_API_TIMEOUT=
# Timeout, in milliseconds, to use when querying the Cloud Foundry API to compute app status
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_STATUS_TIMEOUT
请注意,您可以将spring.cloud.deployer.cloudfoundry.services
,spring.cloud.deployer.cloudfoundry.buildpacks
,或 Spring Cloud Deployer-standardspring.cloud.deployer.memory
和spring.cloud.deployer.disk
作为单个部署请求的一部分,使用deployer.<app-name>
快捷方式,如以下示例所示:
stream create --name ticktock --definition "time | log"
stream deploy --name ticktock --properties "deployer.time.memory=2g"
前面示例中的命令部署具有 2048MB 内存的时间源,而日志接收器使用默认的 1024MB。
部署流时,还可以将JAVA_OPTS
作为部署属性,如以下示例所示:
stream deploy --name ticktock --properties "deployer.time.cloudfoundry.javaOpts=-Duser.timezone=America/New_York"
10.17. 调试
如果您想更好地了解部署流和任务时发生的情况,您可能需要以打开以下功能:
-
Reactor “stacktraces”,显示在错误发生之前涉及哪些运算符。此功能很有帮助,因为部署者依赖于 Project Reactor 和常规 stacktrace 可能并不总是允许在错误发生之前了解流程。请注意,这会带来性能损失,因此默认情况下它是禁用的。
spring.cloud.dataflow.server.cloudfoundry.debugReactor == true
-
Deployer 和 Cloud Foundry 客户端库请求和响应日志。此功能允许查看数据流服务器和 Cloud Foundry 云控制器之间的详细对话。
logging.level.cloudfoundry-client == DEBUG
10.18. Spring Cloud 配置服务器
您可以使用 Spring Cloud Config Server 集中 Spring Boot 应用程序的配置属性。同样,Spring Cloud Data Flow 和由 Spring Cloud Data Flow 编排的应用程序都可以与配置服务器集成,以使用相同的功能。
10.18.1. Stream、Task 和 Spring Cloud Config 服务器
与 Spring Cloud Data Flow 服务器类似,您可以配置流和任务应用程序以解析来自配置服务器的集中属性。将spring.cloud.config.uri
属性是绑定到配置服务器的常用方法。有关更多信息,请参阅 Spring Cloud Config 客户端参考指南。
由于此属性可能在所有已部署的应用程序中使用,因此数据流服务器的spring.cloud.dataflow.applicationProperties.stream
流应用程序的属性和spring.cloud.dataflow.applicationProperties.task
任务应用程序的属性可用于传递uri
配置服务器的共享到每个已部署的流或任务应用程序。有关更多信息,请参阅通用应用程序属性部分。
请注意,如果您使用现成的 Stream 应用程序,这些应用程序已经嵌入了spring-cloud-services-starter-config-client
Dependency。
如果您从头开始构建应用程序并希望添加对配置服务器的客户端支持,则可以添加对配置服务器客户端库的依赖引用。以下代码片段显示了一个 Maven 示例:
...
<dependency>
<groupId>io.pivotal.spring.cloud</groupId>
<artifactId>spring-cloud-services-starter-config-client</artifactId>
<version>CONFIG_CLIENT_VERSION</version>
</dependency>
...
哪里CONFIG_CLIENT_VERSION
可以是 Pivotal Cloud Foundry 的 Spring Cloud Config Server 客户端的最新版本。
您可能会看到一个WARN 如果使用此库的应用程序无法连接到配置,则会记录消息
服务器 当应用程序启动时以及每当/health 端点被访问。
如果您知道自己没有使用配置服务器功能,则可以通过将SPRING_CLOUD_CONFIG_ENABLED 环境变量设置为false . |
10.18.2. 示例清单模板
以下 SCDF 和 Skippermanifest.yml
模板包括 Skipper 和 Spring Cloud Data Flow 服务器所需的环境变量,以及部署的应用程序和任务,以便在 Cloud Foundry 上成功运行并自动解析来自my-config-server
运行时:
applications:
- name: data-flow-server
host: data-flow-server
memory: 2G
disk_quota: 2G
instances: 1
path: {PATH TO SERVER UBER-JAR}
env:
SPRING_APPLICATION_NAME: data-flow-server
MAVEN_REMOTEREPOSITORIES_REPO1_URL: https://my.custom.repo/prod-repo
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_URL: https://api.sys.huron.cf-app.com
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_ORG: sabby20
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SPACE: sabby20
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_DOMAIN: apps.huron.cf-app.com
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_USERNAME: admin
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_PASSWORD: ***
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SKIP_SSL_VALIDATION: true
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_SERVICES: postgres
SPRING_CLOUD_SKIPPER_CLIENT_SERVER_URI: https://<skipper-host-name>/api
services:
- postgres
- my-config-server
applications:
- name: skipper-server
host: skipper-server
memory: 1G
disk_quota: 1G
instances: 1
timeout: 180
buildpack: java_buildpack
path: <PATH TO THE DOWNLOADED SKIPPER SERVER UBER-JAR>
env:
SPRING_APPLICATION_NAME: skipper-server
SPRING_CLOUD_SKIPPER_SERVER_ENABLE_LOCAL_PLATFORM: false
SPRING_CLOUD_SKIPPER_SERVER_STRATEGIES_HEALTHCHECK_TIMEOUTINMILLIS: 300000
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_URL: https://api.local.pcfdev.io
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_ORG: pcfdev-org
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SPACE: pcfdev-space
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_DOMAIN: cfapps.io
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_USERNAME: admin
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_PASSWORD: admin
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SKIP_SSL_VALIDATION: false
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_DELETE_ROUTES: false
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_SERVICES: rabbit,my-config-server
services:
- postgres
my-config-server
哪里my-config-server
是在 Cloud Foundry 上运行的 Spring Cloud Config Service 实例的名称。
通过将服务分别绑定到 Spring Cloud Data Flow 服务器、Spring Cloud Task 和通过 Skipper 绑定到所有 Spring Cloud Stream 应用程序,我们现在可以解析由该服务支持的集中式属性。
10.18.3. 自签名 SSL 证书和 Spring Cloud Config Server
通常,在开发环境中,我们可能没有有效的证书来启用客户端和后端服务之间的 SSL 通信。 但是,Pivotal Cloud Foundry 的配置服务器使用 HTTPS 进行所有客户端到服务通信,因此我们需要在没有有效证书的环境中添加自签名 SSL 证书。
通过使用相同的manifest.yml
上一节中列出的服务器模板,我们可以通过设置TRUST_CERTS: <API_ENDPOINT>
.
但是,部署的应用程序还需要TRUST_CERTS
作为平面环境变量(而不是包装在SPRING_APPLICATION_JSON
),因此我们必须使用另一组Tokens (SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_USE_SPRING_APPLICATION_JSON: false
) 用于任务。
通过此设置,应用程序将其应用程序属性作为常规环境变量接收。
以下列表显示了更新的manifest.yml
进行所需的更改。数据流服务器和已部署的应用程序
从my-config-server
Cloud Config 服务器(部署为 Cloud Foundry 服务)。
applications:
- name: test-server
host: test-server
memory: 1G
disk_quota: 1G
instances: 1
path: spring-cloud-dataflow-server-VERSION.jar
env:
SPRING_APPLICATION_NAME: test-server
MAVEN_REMOTEREPOSITORIES_REPO1_URL: https://my.custom.repo/prod-repo
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_URL: https://api.sys.huron.cf-app.com
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_ORG: sabby20
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SPACE: sabby20
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_DOMAIN: apps.huron.cf-app.com
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_USERNAME: admin
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_PASSWORD: ***
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SKIP_SSL_VALIDATION: true
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_SERVICES: postgres, config-server
SPRING_CLOUD_SKIPPER_CLIENT_SERVER_URI: https://<skipper-host-name>/api
TRUST_CERTS: <API_ENDPOINT> #this is for the server
SPRING_CLOUD_DATAFLOW_APPLICATION_PROPERTIES_TASK_TRUST_CERTS: <API_ENDPOINT> #this propagates to all tasks
services:
- postgres
- my-config-server #this is for the server
此外,将my-config-server
服务到 Skipper 的清单环境
applications:
- name: skipper-server
host: skipper-server
memory: 1G
disk_quota: 1G
instances: 1
timeout: 180
buildpack: java_buildpack
path: <PATH TO THE DOWNLOADED SKIPPER SERVER UBER-JAR>
env:
SPRING_APPLICATION_NAME: skipper-server
SPRING_CLOUD_SKIPPER_SERVER_ENABLE_LOCAL_PLATFORM: false
SPRING_CLOUD_SKIPPER_SERVER_STRATEGIES_HEALTHCHECK_TIMEOUTINMILLIS: 300000
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_URL: <URL>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_ORG: <ORG>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SPACE: <SPACE>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_DOMAIN: <DOMAIN>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_USERNAME: <USER>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_PASSWORD: <PASSWORD>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_SERVICES: rabbit, my-config-server #this is so all stream applications bind to my-config-server
services:
- postgres
my-config-server
10.19. 配置调度
本节讨论如何配置 Spring Cloud Data Flow 以连接到 PCF-Scheduler 作为其代理来执行任务。
在遵循这些说明之前,请确保在 Cloud Foundry 空间中运行 PCF-Scheduler 服务的实例。
要在您的空间中创建 PCF-Scheduler(假设它位于您的 Market Place 中),请从 CF CLI 执行以下作: |
对于计划,您必须在环境中添加(或更新)以下环境变量:
-
通过设置
spring.cloud.dataflow.features.schedules-enabled
自true
. -
通过将 PCF-Scheduler 服务名称添加到
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_SERVICES
环境变量。 -
通过设置
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_SCHEDULER_SCHEDULER_URL
环境变量。
创建上述配置后,必须创建需要计划的所有任务定义。 |
以下示例清单显示了配置的两个环境属性(假设你有一个名为myscheduler
):
applications:
- name: data-flow-server
host: data-flow-server
memory: 2G
disk_quota: 2G
instances: 1
path: {PATH TO SERVER UBER-JAR}
env:
SPRING_APPLICATION_NAME: data-flow-server
SPRING_CLOUD_SKIPPER_SERVER_ENABLE_LOCAL_PLATFORM: false
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_URL: <URL>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_ORG: <ORG>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_SPACE: <SPACE>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_DOMAIN: <DOMAIN>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_USERNAME: <USER>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_CONNECTION_PASSWORD: <PASSWORD>
SPRING_CLOUD_SKIPPER_SERVER_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_DEPLOYMENT_SERVICES: rabbit, myscheduler
SPRING_CLOUD_DATAFLOW_FEATURES_SCHEDULES_ENABLED: true
SPRING_CLOUD_SKIPPER_CLIENT_SERVER_URI: https://<skipper-host-name>/api
SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]_SCHEDULER_SCHEDULER_URL: https://scheduler.local.pcfdev.io
services:
- postgres
其中SPRING_CLOUD_DATAFLOW_TASK_PLATFORM_CLOUDFOUNDRY_ACCOUNTS[default]SCHEDULER_SCHEDULER_URL
具有以下格式:scheduler.<Domain-Name>
(对于 例scheduler.local.pcfdev.io
). 从您的_PCF中查看实际地址环境。
有关跨多个平台启动和计划任务的详细示例,请参阅此部分 dataflow.spring.io 上任务的多平台支持。 |
11. 配置 - Kubernetes
本节介绍如何配置 Spring Cloud Data Flow 功能,例如部署器属性、任务以及要使用的关系数据库。
11.1. 功能切换
数据流服务器提供了一组特定的功能,可以在启动时启用或禁用这些功能。这些功能包括所有生命周期作、REST 终结点(服务器和客户端实现,包括 Shell 和 UI),用于:
-
流
-
任务
-
附表
您可以通过在启动数据流服务器时设置以下布尔环境变量来启用或禁用这些功能:
-
SPRING_CLOUD_DATAFLOW_FEATURES_STREAMS_ENABLED
-
SPRING_CLOUD_DATAFLOW_FEATURES_TASKS_ENABLED
-
SPRING_CLOUD_DATAFLOW_FEATURES_SCHEDULES_ENABLED
默认情况下,所有功能都处于启用状态。
这/features
REST 终结点提供有关已启用和禁用的功能的信息。
11.2. 应用程序和服务器属性
本节介绍如何自定义应用程序的部署。您可以使用许多属性来影响已部署应用程序的设置。可以按应用程序应用属性,也可以在所有已部署应用程序的相应服务器配置中应用属性。
基于每个应用程序设置的属性始终优先于设置为服务器配置的属性。通过这种安排,您可以基于每个应用程序覆盖全局服务器级别属性。 |
要应用于所有已部署任务的属性在src/kubernetes/server/server-config-[binder].yaml
文件和 for Streamssrc/kubernetes/skipper/skipper-config-[binder].yaml
.取代[binder]
使用您正在使用的消息传递中间件 — 例如,rabbit
或kafka
.
11.2.1. 内存和 CPU 设置
应用程序使用默认内存和 CPU 设置进行部署。如果需要,可以调整这些值。以下示例演示如何设置Limits
自1000m
为CPU
和1024Mi
用于记忆和Requests
自800m
用于 CPU 和640Mi
对于内存:
deployer.<application>.kubernetes.limits.cpu=1000m
deployer.<application>.kubernetes.limits.memory=1024Mi
deployer.<application>.kubernetes.requests.cpu=800m
deployer.<application>.kubernetes.requests.memory=640Mi
这些值会导致使用以下容器设置:
Limits:
cpu: 1
memory: 1Gi
Requests:
cpu: 800m
memory: 640Mi
您还可以控制将cpu
和memory
全球。
以下示例显示如何设置流的 CPU 和内存:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
limits:
memory: 640mi
cpu: 500m
以下示例展示了如何设置任务的 CPU 和内存:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
limits:
memory: 640mi
cpu: 500m
到目前为止,我们使用的设置仅影响容器的设置。它们不会影响容器中 JVM 进程的内存设置。如果要设置 JVM 内存设置,可以设置一个环境变量来执行此作。有关详细信息,请参阅下一节。
11.2.2. 环境变量
要影响给定应用程序的环境设置,您可以使用spring.cloud.deployer.kubernetes.environmentVariables
deployer 属性。
例如,生产环境中的一个常见要求是影响 JVM 内存参数。
您可以使用JAVA_TOOL_OPTIONS
环境变量,如以下示例所示:
deployer.<application>.kubernetes.environmentVariables=JAVA_TOOL_OPTIONS=-Xmx1024m
这environmentVariables 属性接受逗号分隔的字符串。如果环境变量包含值
这也是一个逗号分隔的字符串,它必须用单引号括起来——例如,spring.cloud.deployer.kubernetes.environmentVariables=spring.cloud.stream.kafka.binder.brokers='somehost:9092,
anotherhost:9093'
|
这将覆盖所需 JVM 内存设置<application>
(将<application>
替换为您的应用程序名称)。
11.2.3. 活跃度、就绪和启动探针
这liveness
和readiness
探测器使用名为/health/liveness
和/health/readiness
分别。他们使用delay
之1
对于两者和period
之60
和10
分别。使用部署程序属性部署流时,可以更改这些缺省值。活跃度和就绪性探测仅应用于流。
这startup
probe 将使用/health
路径和延迟为 30,周期为 3,失败阈值为 20 次,然后容器重新启动应用程序。
以下示例将liveness
和startup
探针(将<application>
替换为应用程序的名称),通过设置部署程序属性:
deployer.<application>.kubernetes.livenessProbePath=/health/livesness
deployer.<application>.kubernetes.livenessProbeDelay=1
deployer.<application>.kubernetes.livenessProbePeriod=60
deployer.<application>.kubernetes.livenessProbeSuccess=1
deployer.<application>.kubernetes.livenessProbeFailure=3
deployer.<application>.kubernetes.readinessProbePath=/health/readiness
deployer.<application>.kubernetes.readinessProbeDelay=1
deployer.<application>.kubernetes.readinessProbePeriod=60
deployer.<application>.kubernetes.readinessProbeSuccess=1
deployer.<application>.kubernetes.readinessProbeFailure=3
deployer.<application>.kubernetes.startupHttpProbePath=/health
deployer.<application>.kubernetes.startupProbeDelay=20
deployer.<application>.kubernetes.startupProbeSuccess=1
deployer.<application>.kubernetes.startupProbeFailure=30
deployer.<application>.kubernetes.startupProbePeriod=5
deployer.<application>.kubernetes.startupProbeTimeout=3
您可以声明相同的内容作为流的服务器全局配置的一部分,如以下示例所示:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
livenessHttpProbePath: /health/liveness
livenessProbeDelay: 1
livenessProbePeriod: 60
livenessProbeSuccess: 1
livenessProbeFailure: 3
startupHttpProbePath: /health
startupProbeDelay: 20
startupProbeSuccess: 1
startupProbeFailure: 30
startupProbePeriod: 5
startupProbeTimeout: 3
同样,您可以交换liveness
为readiness
以覆盖默认值readiness
设置。
默认情况下,端口 8080 用作探头端口。您可以更改两者的默认值liveness
和readiness
使用部署程序属性探测端口,如以下示例所示:
deployer.<application>.kubernetes.readinessProbePort=7000
deployer.<application>.kubernetes.livenessProbePort=7000
deployer.<application>.kubernetes.startupProbePort=7000
您可以声明相同的内容作为流的全局配置的一部分,如以下示例所示:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
readinessProbePort: 7000
livenessProbePort: 7000
startupProbePort: 7000
默认情况下, 这
要自动将两者
|
可以使用存储在 Kubernetes 机密中的凭据访问受保护的探测终结点。您可以使用现有密钥,前提是凭据包含在credentials
密钥的密钥名称data
块。您可以基于每个应用程序配置探测身份验证。启用后,它将应用于liveness
和readiness
使用相同的凭据和身份验证类型探测终结点。目前,只有Basic
支持身份验证。
要创建新密钥,请执行以下作:
-
使用用于访问安全探测终结点的凭据生成 base64 字符串。
基本身份验证将用户名和密码编码为 base64 字符串,格式为
username:password
.以下示例(包括输出,应在其中将
user
和pass
使用您的值)显示如何生成 base64 字符串:$ echo -n "user:pass" | base64 dXNlcjpwYXNz
-
使用编码的凭据创建一个文件(例如,
myprobesecret.yml
)包含以下内容:apiVersion: v1 kind: Secret metadata: name: myprobesecret type: Opaque data: credentials: GENERATED_BASE64_STRING
-
取代
GENERATED_BASE64_STRING
使用之前生成的 base64 编码值。 -
使用
kubectl
,如以下示例所示:$ kubectl create -f ./myprobesecret.yml secret "myprobesecret" created
-
将以下部署程序属性设置为在访问探测终结点时使用身份验证,如以下示例所示:
deployer.<application>.kubernetes.probeCredentialsSecret=myprobesecret
取代
<application>
替换为要应用身份验证的应用程序的名称。
11.2.4. 使用SPRING_APPLICATION_JSON
您可以使用SPRING_APPLICATION_JSON
环境变量,用于设置数据流服务器属性(包括Maven存储库设置的配置),这些属性在所有数据流服务器实施中都是通用的。这些设置位于容器中的服务器级别env
部署 YAML 的部分。以下示例显示了如何执行此作:
env:
- name: SPRING_APPLICATION_JSON
value: "{ \"maven\": { \"local-repository\": null, \"remote-repositories\": { \"repo1\": { \"url\": \"https://my.custom.repo/prod-repo\"} } } }"
11.2.5. 私有 Docker 注册表
您可以按应用程序从专用注册表中提取 Docker 映像。首先,您必须在集群中创建一个密钥。按照从私有注册表拉取映像指南创建密钥。
创建密钥后,您可以使用imagePullSecret
属性来设置要使用的密钥,如以下示例所示:
deployer.<application>.kubernetes.imagePullSecret=mysecret
取代<application>
替换为您的应用程序名称,以及mysecret
替换为您之前创建的密钥的名称。
您还可以在全局服务器级别配置镜像拉取密钥。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
imagePullSecret: mysecret
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
imagePullSecret: mysecret
取代mysecret
替换为您之前创建的密钥的名称。
11.2.6. 注解
您可以按应用程序向 Kubernetes 对象添加注释。支持的对象类型为 podDeployment
,Service
和Job
.注释在key:value
格式,允许用逗号分隔多个注释。有关注释的更多信息和用例,请参阅注释。
以下示例显示如何配置应用程序以使用注释:
deployer.<application>.kubernetes.podAnnotations=annotationName:annotationValue
deployer.<application>.kubernetes.serviceAnnotations=annotationName:annotationValue,annotationName2:annotationValue2
deployer.<application>.kubernetes.jobAnnotations=annotationName:annotationValue
取代<application>
替换为您的应用程序名称和注释的值。
11.2.7. 入口点样式
入口点样式会影响应用程序属性传递到要部署的容器的方式。目前,支持三种样式:
-
exec
(默认):将部署请求中的所有应用程序属性和命令行参数作为容器参数传递。应用程序属性转换为--key=value
. -
shell
:将所有应用程序属性和命令行参数作为环境变量传递。每个 applicationor 命令行参数属性都转换为大写字符串,并且.
字符替换为 ._
-
boot
:创建一个名为SPRING_APPLICATION_JSON
包含所有应用程序属性的 JSON 表示形式。部署请求中的命令行参数设置为容器参数。
在所有情况下,在服务器级配置和每个应用程序的基础上定义的环境变量都会按原样发送到容器。 |
您可以按如下方式配置应用程序:
deployer.<application>.kubernetes.entryPointStyle=<Entry Point Style>
取代<application>
替换为您的应用程序名称,以及<Entry Point Style>
使用您想要的入口点样式。
您还可以在全局服务器级别配置入口点样式。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
entryPointStyle: entryPointStyle
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
entryPointStyle: entryPointStyle
取代entryPointStyle
为所需的入口点样式。
您应该选择 入口点样式exec
或shell
,以对应于ENTRYPOINT
语法在容器的Dockerfile
.有关更多信息和用例exec
对shell
,请参阅 Docker 文档的 ENTRYPOINT 部分。
使用boot
入口点样式对应于使用exec
风格ENTRYPOINT
.部署请求中的命令行参数将传递到容器,并将应用程序属性映射到SPRING_APPLICATION_JSON
环境变量而不是命令行参数。
当您使用boot 入口点样式,则deployer.<application>.kubernetes.environmentVariables 属性不得包含SPRING_APPLICATION_JSON . |
11.2.8. 部署服务帐户
您可以通过属性为应用程序部署配置自定义服务帐户。您可以使用现有服务帐户或创建一个新服务帐户。创建服务帐户的一种方法是使用kubectl
,如以下示例所示:
$ kubectl create serviceaccount myserviceaccountname
serviceaccount "myserviceaccountname" created
然后,您可以按如下方式配置单个应用程序:
deployer.<application>.kubernetes.deploymentServiceAccountName=myserviceaccountname
取代<application>
替换为您的应用程序名称,以及myserviceaccountname
替换为您的服务帐户名称。
您还可以在全局服务器级别配置服务帐户名称。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
deploymentServiceAccountName: myserviceaccountname
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
deploymentServiceAccountName: myserviceaccountname
取代myserviceaccountname
替换为要应用于所有部署的服务帐户名称。
11.2.9. 镜像拉取策略
映像拉取策略定义何时应将 Docker 映像拉取到本地注册表。目前,支持三种策略:
-
IfNotPresent
(默认):如果镜像已经存在,则不要拉取镜像。 -
Always
:始终拉取图像,无论它是否已经存在。 -
Never
:切勿拉取图像。仅使用已存在的图像。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.imagePullPolicy=IfNotPresent
取代<application>
替换为您的应用程序名称,以及Always
使用所需的映像拉取策略。
您可以在全局服务器级别配置镜像拉取策略。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
imagePullPolicy: IfNotPresent
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
imagePullPolicy: Always
取代Always
使用所需的映像拉取策略。
11.2.10. 部署标签
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.deploymentLabels=myLabelName:myLabelValue
取代<application>
替换为您的应用程序名称,myLabelName
替换为您的标签名称,以及myLabelValue
替换为您的标签值。
此外,还可以应用多个标签,如以下示例所示:
deployer.<application>.kubernetes.deploymentLabels=myLabelName:myLabelValue,myLabelName2:myLabelValue2
11.2.11. 容忍
容忍度与污点一起使用,以确保 Pod 不会被调度到特定节点上。 容忍度设置到 Pod 配置中,而污点设置到节点上。 有关更多信息,请参阅 Kubernetes 参考的污点和容忍度部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.tolerations=[{key: 'mykey', operator: 'Equal', value: 'myvalue', effect: 'NoSchedule'}]
取代<application>
替换为您的应用程序名称和键值对,具体取决于您所需的容错配置。
您也可以在全局服务器级别配置容错。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
tolerations:
- key: mykey
operator: Equal
value: myvalue
effect: NoSchedule
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
tolerations:
- key: mykey
operator: Equal
value: myvalue
effect: NoSchedule
将tolerations
键值对。
11.2.12. 秘密引用
可以引用 Secret,并且可以解码其整个数据内容并将其作为单独的变量插入到 Pod 环境中。 有关更多信息,请参阅 Kubernetes 参考的将密钥中的所有键值对配置为容器环境变量部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.secretRefs=testsecret
您还可以指定多个密钥,如下所示:
deployer.<application>.kubernetes.secretRefs=[testsecret,anothersecret]
取代<application>
替换为您的应用程序名称和secretRefs
属性,并指定为您的应用程序环境和密钥提供适当的值。
您也可以在全局服务器级别配置机密引用。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
secretRefs:
- testsecret
- anothersecret
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
secretRefs:
- testsecret
- anothersecret
替换 的项目secretRefs
使用一个或多个机密名称。
11.2.13. 密钥引用
可以引用密钥,并将其解码值插入到 Pod 环境中。 有关更多信息,请参阅 Kubernetes 参考的使用密钥作为环境变量部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.secretKeyRefs=[{envVarName: 'MY_SECRET', secretName: 'testsecret', dataKey: 'password'}]
取代<application>
替换为您的应用程序名称和envVarName
,secretName
和dataKey
属性,并具有适合您的应用程序环境和密钥的值。
您也可以在全局服务器级别配置密钥引用。
以下示例显示了如何对流执行此作:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
secretKeyRefs:
- envVarName: MY_SECRET
secretName: testsecret
dataKey: password
以下示例显示了如何对任务执行此作:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
secretKeyRefs:
- envVarName: MY_SECRET
secretName: testsecret
dataKey: password
将envVarName
,secretName
和dataKey
属性,并为您的密钥提供适当的值。
11.2.14. ConfigMap 引用
可以引用 ConfigMap,其整个数据内容可以解码并作为单独的变量插入到 Pod 环境中。 有关更多信息,请参阅 Kubernetes 参考的将 ConfigMap 中的所有键值对配置为容器环境变量部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.configMapRefs=testcm
您还可以指定多个 ConfigMap 实例,如下所示:
deployer.<application>.kubernetes.configMapRefs=[testcm,anothercm]
取代<application>
替换为您的应用程序名称和configMapRefs
属性,并指定为适用于您的应用程序环境和 ConfigMap 的适当值。
您也可以在全局服务器级别配置 ConfigMap 引用。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml
取代(binder)
使用相应的粘合剂:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
configMapRefs:
- testcm
- anothercm
以下示例显示了如何通过编辑server-config.yaml
文件:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
configMapRefs:
- testcm
- anothercm
替换 的项目configMapRefs
使用一个或多个机密名称。
11.2.15. ConfigMap 键引用
可以引用 ConfigMap 并将其关联的键值插入到 Pod 环境中。 有关更多信息,请参阅 Kubernetes 参考的 使用 ConfigMap 数据定义容器环境变量 部分。
以下示例演示如何单独配置应用程序:
deployer.<application>.kubernetes.configMapKeyRefs=[{envVarName: 'MY_CM', configMapName: 'testcm', dataKey: 'platform'}]
取代<application>
替换为您的应用程序名称和envVarName
,configMapName
和dataKey
属性,并具有适合您的应用程序环境和 ConfigMap 的值。
您也可以在全局服务器级别配置 ConfigMap 引用。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml
取代(binder)
使用相应的粘合剂:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
configMapKeyRefs:
- envVarName: MY_CM
configMapName: testcm
dataKey: platform
以下示例显示了如何通过编辑server-config.yaml
文件:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
configMapKeyRefs:
- envVarName: MY_CM
configMapName: testcm
dataKey: platform
将envVarName
,configMapName
和dataKey
属性,并为您的 ConfigMap 提供适当的值。
11.2.16. Pod 安全上下文
Pod 安全上下文指定 Pod 及其容器的安全设置。
以下示例显示了如何为单个应用程序 Pod 配置安全上下文:
deployer.<application>.kubernetes.podSecurityContext={runAsUser: 65534, fsGroup: 65534, supplementalGroups: [65534, 65535], seccompProfile: { type: 'RuntimeDefault' }}
取代<application>
替换为应用程序的名称以及具有适合容器环境的适当值的任何属性。
您也可以在全局服务器级别配置容器安全上下文。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml
取代(binder)
使用相应的粘合剂:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
podSecurityContext:
runAsUser: 65534
fsGroup: 65534
supplementalGroups: [65534,65535]
seccompProfile:
type: Localhost
localhostProfile: my-profiles/profile-allow.json
以下示例显示了如何通过编辑server-config.yaml
文件:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
podSecurityContext:
runAsUser: 65534
fsGroup: 65534
supplementalGroups: [65534,65535]
seccompProfile:
type: Localhost
localhostProfile: my-profiles/profile-allow.json
调整podSecurityContext
属性,其值适合您的容器环境。
11.2.17. 容器安全上下文
容器安全上下文指定单个容器的安全设置。
容器安全上下文将应用于部署中的所有容器,除非它们已经显式定义了自己的安全性,包括常规 init 容器、有状态集 init 容器和其他容器。 |
以下示例显示了如何为单个应用程序 Pod 中的容器配置安全上下文:
deployer.<application>.kubernetes.containerSecurityContext={allowPrivilegeEscalation: true, runAsUser: 65534}
取代<application>
替换为应用程序的名称以及具有适合容器环境的适当值的任何属性。
您也可以在全局服务器级别配置容器安全上下文。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml
取代(binder)
使用相应的粘合剂:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
containerSecurityContext:
allowPrivilegeEscalation: true
runAsUser: 65534
以下示例显示了如何通过编辑server-config.yaml
文件:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
containerSecurityContext:
allowPrivilegeEscalation: true
runAsUser: 65534
调整containerSecurityContext
属性,其值适合您的容器环境。
11.2.18. 服务端口
部署应用程序时,将创建一个 kubernetes 服务对象,默认端口为8080
.如果server.port
属性,则它会覆盖默认端口值。您可以根据每个应用程序向服务对象添加其他端口。您可以使用逗号分隔符添加多个端口。
以下示例演示如何在应用程序的 Service 对象上配置其他端口:
deployer.<application>.kubernetes.servicePorts=5000
deployer.<application>.kubernetes.servicePorts=5000,9000
取代<application>
替换为您的应用程序名称和端口值。
11.2.19. StatefulSet 初始化容器
使用 StatefulSet 部署应用程序时,使用 Init Container 来设置 Pod 中的实例索引。
默认情况下,使用的图像是busybox
,您可以自定义。
以下示例显示了如何单独配置应用程序 Pod:
deployer.<application>.kubernetes.statefulSetInitContainerImageName=myimage:mylabel
取代<application>
替换为您的应用程序名称和statefulSetInitContainerImageName
属性,并指定为您的环境的适当值。
您也可以在全局服务器级别配置 StatefulSet 初始化容器。
以下示例演示如何对流执行此作。编辑适当的skipper-config-(binder).yaml
取代(binder)
使用相应的粘合剂:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
statefulSetInitContainerImageName: myimage:mylabel
以下示例显示了如何通过编辑server-config.yaml
文件:
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
statefulSetInitContainerImageName: myimage:mylabel
将statefulSetInitContainerImageName
属性,并指定为您的环境的适当值。
11.2.20. 初始化容器
部署应用程序时,可以按应用程序设置自定义 Init 容器。 有关更多信息,请参阅 Kubernetes 参考的 初始化容器 部分。
以下示例显示了如何为应用程序配置一个或多个初始化容器:
deployer.<application>.kubernetes.initContainer={containerName: 'test', imageName: 'busybox:latest', commands: ['sh', '-c', 'echo hello']}
# alternative for multiple init containers
deployer.<application>.kubernetes.initContainers=[{containerName:'test', imageName: 'busybox:latest', commands: ['sh', '-c', 'echo hello']}, {containerName:'test2', imageName:'busybox:latest', commands:['sh', '-c', 'echo world']}]
# multiple containers can be created inidividually
deployer.<application>.kubernetes.initContainers[0]={containerName:'test', imageName:'busybox:latest', commands:['sh', '-c', 'echo hello']}
deployer.<application>.kubernetes.initContainers[1]={containerName:'test2', imageName:'busybox:latest', commands:['sh', '-c', 'echo world']}
取代<application>
替换为应用程序的名称,并设置initContainer
属性。
11.2.21. 生命周期支持
部署应用程序时,可以附加postStart
和preStop
用于执行命令的生命周期处理程序。
Kubernetes API 支持其他类型的处理程序,除了exec
.此功能可能会在将来的版本中扩展以支持其他作。
要配置 生命周期处理程序 如上面的链接页面所示,请使用以下属性键将每个命令指定为逗号分隔的列表:
deployer.<application>.kubernetes.lifecycle.postStart.exec.command=/bin/sh,-c,'echo Hello from the postStart handler > /usr/share/message'
deployer.<application>.kubernetes.lifecycle.preStop.exec.command=/bin/sh,-c,'nginx -s quit; while killall -0 nginx; do sleep 1; done'
11.2.22. 其他容器
部署应用程序时,可能需要将一个或多个容器与主容器一起部署。 这将允许您调整一些部署模式,例如在多容器 Pod 设置的情况下的 sidecar、适配器。
以下示例演示如何为应用程序配置其他容器:
deployer.<application>.kubernetes.additionalContainers=[{name: 'c1', image: 'busybox:1', command: ['sh', '-c', 'echo hello1'], volumeMounts: [{name: 'test-volume', mountPath: '/tmp', readOnly: true}]},{name: 'c2', image: 'busybox:1.26.1', command: ['sh', '-c', 'echo hello2']}]
11.3. Deployer 属性
您可以使用 Kubernetes 部署程序的以下配置属性来自定义 Streams 和 Tasks 的部署方式。
使用数据流 shell 进行部署时,可以使用语法deployer.<appName>.kubernetes.<deployerPropertyName>
.
在数据流服务器中配置 Kubernetes 任务平台和 Skipper 中的 Kubernetes 平台以部署 Streams 时,也会使用这些属性。
部署程序属性名称 | 描述 | 默认值 |
---|---|---|
Namespace |
要使用的命名空间 |
环境变量 |
deployment.nodeSelector |
要应用于部署的节点选择器 |
<无> |
imagePullSecret (图像拉取秘密) |
访问私有注册表以拉取映像的机密。 |
<无> |
imagePullPolicy |
拉取映像时要应用的映像拉取策略。有效选项包括 |
如果不存在 |
livenessProbeDelay |
应用容器的 Kubernetes 活跃度检查应开始检查其运行状况时的延迟(以秒为单位)。 |
10 |
livenessProbe周期 |
对应用容器执行 Kubernetes 活动性检查的时间段(以秒为单位)。 |
60 |
livenessProbeTimeout |
应用容器的 Kubernetes 活动性检查的超时(以秒为单位)。如果运行状况检查返回的时间超过此值,则假定为“不可用”。 |
2 |
liveness探针路径 |
应用容器必须响应的路径才能进行活动性检查。 |
<无> |
livenessProbePort |
应用容器必须响应以进行活动性检查的端口。 |
<无> |
启动探针延迟 |
应用容器的 Kubernetes 启动检查应开始检查其运行状况时的延迟(以秒为单位)。 |
30 |
启动探针周期 |
对应用容器执行 Kubernetes 启动检查的时间段(以秒为单位)。 |
3 |
启动探针失败 |
在重新启动容器之前,启动探测允许的探测失败次数。 |
20 |
启动HttpProbePath |
应用容器必须响应才能进行启动检查的路径。 |
<无> |
启动探针端口 |
应用容器必须响应以进行启动检查的端口。 |
<无> |
准备情况ProbeDelay |
当应用容器的就绪性检查应开始检查模块是否完全启动并运行时,延迟(以秒为单位)。 |
10 |
准备情况探针周期 |
执行应用容器就绪情况检查的时间段(以秒为单位)。 |
10 |
readinessProbeTimeout |
应用容器在就绪情况检查期间必须响应其运行状况的超时(以秒为单位)。 |
2 |
准备情况探针路径 |
应用容器必须响应以进行就绪情况检查的路径。 |
<无> |
准备就绪ProbePort |
应用容器必须响应以进行就绪检查的端口。 |
<无> |
probeCredentialsSecret |
包含访问安全探测终结点时要使用的凭据的密钥名称。 |
<无> |
limits.memory |
内存限制,分配 Pod 所需的最大值,默认单位为 mebibytes,支持 'M' 和 'G' 后缀 |
<无> |
limits.cpu |
CPU 限制,分配 Pod 所需的最大值 |
<无> |
limits.临时存储 |
临时存储限制,分配 Pod 所需的最大值。 |
<无> |
limits.hugepages-2Mi |
hugepages-2Mi 限制,分配 Pod 所需的最大值。 |
<无> |
limits.hugepages-1Gi |
hugepages-1Gi 限制,分配 Pod 所需的最大值。 |
<无> |
请求.memory |
内存请求,保证分配 Pod 所需的值。 |
<无> |
请求.cpu |
CPU 请求,保证分配 Pod 所需的值。 |
<无> |
请求.临时存储 |
临时存储请求,保证分配 Pod 所需的值。 |
<无> |
请求.hugepages-2Mi |
hugepages-2Mi 请求保证了分配 Pod 所需的值。 |
<无> |
请求.hugepages-1Gi |
hugepages-1Gi 请求保证了分配 Pod 所需的值。 |
<无> |
affinity.node亲和力 |
以 YAML 格式表示的节点亲和性。例如 |
<无> |
affinity.pod亲和力 |
以 YAML 格式表示的 Pod 亲和力。例如 |
<无> |
affinity.pod反亲和力 |
以YAML格式表示的pod反亲和力。例如 |
<无> |
statefulSet.volumeClaimTemplate.storageClassName |
有状态集的存储类的名称 |
<无> |
statefulSet.volumeClaimTemplate.storage |
存储量。默认单位为兆字节,支持“M”和“G”后缀 |
<无> |
环境变量 |
要为任何已部署的应用容器设置的环境变量列表 |
<无> |
入口点样式 |
用于 Docker 映像的入口点样式。用于确定如何传入属性。可以 |
|
createLoadBalancer |
为为每个应用程序创建的服务创建一个“LoadBalancer”。这有助于将外部 IP 分配给应用程序。 |
false |
服务注释 |
为为每个应用程序创建的服务设置的服务注释。格式的字符串 |
<无> |
pod注释 |
要为为每个部署创建的 Pod 设置的 Pod 注释。格式的字符串 |
<无> |
job注释 |
要为为作业创建的容器或作业设置的作业注释。格式的字符串 |
<无> |
优先级类名 |
Pod Spec priorityClassName 的 Spec 优先级。在使用此属性之前,在 Kubernetes 中创建一个 PriorityClass。请参阅 Pod 优先级和抢占 |
<无> |
shareProcess命名空间 |
将为 Pod.spec.shareProcessNamespace 赋值。请参阅在 Pod 中的容器之间共享进程命名空间 |
<无> |
分钟等待负载均衡器 |
在尝试删除服务之前等待负载均衡器可用的时间(以分钟为单位)。 |
5 |
maxTerminatedErrorRestarts (最大终止错误重启) |
由于错误或资源使用过多而失败的应用允许重启的最大值。 |
2 |
maxCrashLoopBackOffRestarts |
CrashLoopBackOff 中的应用允许的最大重启。值是 |
|
volumeMounts |
以 YAML 格式表示的卷挂载。例如 |
<无> |
卷 |
Kubernetes 实例支持的卷以 YAML 格式指定。例如 |
<无> |
主机网络 |
部署的 hostNetwork 设置,请参阅 kubernetes.io/docs/api-reference/v1/definitions/#_v1_podspec |
false |
创建部署 |
使用“副本集”而不是“复制控制器”创建“部署”。 |
true |
创建作业 |
在启动任务时创建一个“作业”,而不仅仅是一个“Pod”。 |
false |
container命令 |
使用提供的命令和参数覆盖默认入口点命令。 |
<无> |
容器端口 |
添加要在容器上公开的其他端口。 |
<无> |
创建节点端口 |
在以下情况下使用的显式端口 |
<无> |
部署服务帐户名称 |
应用部署中使用的服务帐户名称。注意:用于应用部署的服务帐户名称派生自数据流服务器部署。 |
<无> |
部署标签 |
要添加到部署的其他标签 |
<无> |
bootMajor版本 |
要使用的 Spring Boot 主要版本。目前仅用于自动配置 Spring Boot 版本特定的探针路径。有效选项包括 |
2 |
tolerations.key |
用于容忍的关键。 |
<无> |
容忍度.效果 |
容忍效应。有关有效选项,请参阅 kubernetes.io/docs/concepts/configuration/taint-and-toleration。 |
<无> |
容忍.运算符 |
容差运算符。有关有效选项,请参阅 kubernetes.io/docs/concepts/configuration/taint-and-toleration/。 |
<无> |
tolerations.toleration秒 |
定义添加污点后 Pod 与节点绑定多长时间的秒数。 |
<无> |
容忍度.值 |
要应用的容忍值,与 |
<无> |
secretRefs |
将整个数据内容加载到各个环境变量中的密钥的名称。多个机密可以用逗号分隔。 |
<无> |
secretKeyRefs.envVarName |
用于保存机密数据的环境变量名称 |
<无> |
secretKeyRefs.secretName |
要访问的机密名称 |
<无> |
secretKeyRefs.dataKey |
要从中获取密钥数据的密钥名称 |
<无> |
配置映射引用 |
用于将整个数据内容加载到各个环境变量中的 ConfigMap 的名称。多个 ConfigMap 以逗号分隔。 |
<无> |
configMapKeyRefs.envVarName |
用于保存 ConfigMap 数据的环境变量名称 |
<无> |
configMapKeyRefs.configMapName |
要访问的 ConfigMap 名称 |
<无> |
configMapKeyRefs.dataKey |
从中获取 ConfigMap 数据的键名称 |
<无> |
最大并发任务 |
此平台实例允许的最大并发任务 |
20 |
podSecurityContext |
应用于以 YAML 格式表示的 Pod 的安全上下文。例如 |
<无> |
podSecurityContext.runAs用户 |
用于在 |
<无> |
podSecurityContext.runAsGroup |
用于运行容器进程入口点的数字组 ID |
<无> |
podSecurityContext.runAsNonRoot |
指示容器必须以非 root 用户身份运行 |
<无> |
podSecurityContext.fs组 |
Pod 卷的数字组 ID |
<无> |
podSecurityContext.fsGroupChangePolicy |
定义在 Pod 中公开之前更改卷的所有权和权限的行为(仅适用于支持基于 fsGroup 的所有权和权限的卷类型)- 可能的值为 “OnRootMismatch”、“Always” |
<无> |
podSecurityContext.补充组 |
除了容器的主组 ID 之外,还应用于容器容器进程的数字组 ID |
<无> |
podSecurityContext.seccompProfile |
用于以 YAML 格式表示的 Pod 容器的 seccomp 选项。例如 |
<无> |
podSecurityContext.seLinux选项 |
要应用于以 YAML 格式表示的 Pod 容器的 SELinux 上下文。例如 |
<无> |
podSecurityContext.sysctls |
用于以 YAML 格式表示的 Pod 的命名空间 sysctl 列表。例如 |
<无> |
podSecurityContext.windows选项 |
适用于以 YAML 格式表示的所有容器的 Windows 特定设置。例如 |
<无> |
containerSecurityContext |
应用于以 YAML 格式表示的容器的安全上下文。例如 |
<无> |
containerSecurityContext.allowPrivilegeEscalation |
进程是否可以获得比其父进程更多的权限 |
<无> |
containerSecurityContext.capabilities |
运行以 YAML 格式表示的容器时添加/删除的功能。例如 |
<无> |
containerSecurityContext.特权 |
在特权模式下运行容器。 |
<无> |
containerSecurityContext.procMount |
用于容器的触发挂载类型(仅当 spec.os.name 不是窗口时使用) |
<无> |
containerSecurityContext.readOnlyRootFile系统 |
将容器的根文件系统挂载为只读 |
<无> |
containerSecurityContext.runAsUser |
用于在 |
<无> |
containerSecurityContext.runAsGroup |
用于运行容器进程入口点的数字组 ID |
<无> |
containerSecurityContext.runAsNonRoot |
指示容器必须以非 root 用户身份运行 |
<无> |
containerSecurityContext.seccompProfile |
用于以 YAML 格式表示的 Pod 容器的 seccomp 选项。例如 |
<无> |
containerSecurityContext.seLinux选项 |
要应用于以 YAML 格式表示的 Pod 容器的 SELinux 上下文。例如 |
<无> |
containerSecurityContext.sysctls |
用于以 YAML 格式表示的 Pod 的命名空间 sysctl 列表。例如 |
<无> |
containerSecurityContext.windows选项 |
适用于以 YAML 格式表示的所有容器的 Windows 特定设置。例如 |
<无> |
statefulSetInitContainerImageName |
用于 StatefulSet 初始化容器的自定义镜像名称 |
<无> |
初始容器 |
以 YAML 格式表示的 Init 容器,以应用于 Pod。例如 |
<无> |
additional容器 |
以 YAML 格式表示的要应用于 Pod 的其他容器。例如 |
<无> |
11.4. 任务
数据流服务器负责部署任务。数据流启动的任务将其状态写入数据流服务器使用的同一数据库。对于作为 Spring 批处理作业的任务,作业和步骤执行数据也存储在此数据库中。与 Skipper 一样,任务可以启动到多个平台。当数据流在 Kubernetes 上运行时,必须定义任务平台。要配置面向 Kubernetes 的新平台帐户,请在spring.cloud.dataflow.task.platform.kubernetes
部分在您的application.yaml
文件。
在以下示例中,两个名为dev
和qa
被创建。
键,例如memory
和disk
是 Cloud Foundry Deployer 属性。
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
dev:
namespace: devNamespace
imagePullPolicy: IfNotPresent
entryPointStyle: exec
limits:
cpu: 4
qa:
namespace: qaNamespace
imagePullPolicy: IfNotPresent
entryPointStyle: boot
limits:
memory: 2048m
通过将一个平台定义为default 允许您跳过使用platformName 否则需要使用它。 |
启动任务时,使用任务启动选项传递平台帐户名称的值--platformName
如果未传递platformName
,则值default
将被使用。
将任务部署到多个平台时,任务的配置需要连接到与数据流服务器相同的数据库。 |
您可以配置 Kubernetes 上的数据流服务器,以将任务部署到 Cloud Foundry 和 Kubernetes。有关更多信息,请参阅有关 Cloud Foundry 任务平台配置的部分。
有关跨多个平台启动和计划任务的详细示例,请参阅此部分 dataflow.spring.io 上任务的多平台支持。
11.5. 常规配置
适用于 Kubernetes 的 Spring Cloud Data Flow 服务器使用spring-cloud-kubernetes
模块来处理挂载在/etc/secrets
.ConfigMap 必须挂载为application.yaml
在/config
由 Spring Boot 处理的目录。为了避免访问 Kubernetes API 服务器,SPRING_CLOUD_KUBERNETES_CONFIG_ENABLE_API
和SPRING_CLOUD_KUBERNETES_SECRETS_ENABLE_API
设置为false
.
11.5.1. 使用 ConfigMap 和密钥
以下示例显示了一种可能的配置,它启用 MariaDB 并设置内存限制:
apiVersion: v1
kind: ConfigMap
metadata:
name: scdf-server
labels:
app: scdf-server
data:
application.yaml: |-
spring:
cloud:
dataflow:
task:
platform:
kubernetes:
accounts:
default:
limits:
memory: 1024Mi
datasource:
url: jdbc:mariadb://${MARIADB_SERVICE_HOST}:${MARIADB_SERVICE_PORT}/database
username: root
password: ${database-password}
driverClassName: org.mariadb.jdbc.Driver
testOnBorrow: true
validationQuery: "SELECT 1"
前面的示例假设 MariaDB 部署时使用mariadb
作为服务名称。Kubernetes 将这些服务的主机和端口值发布为环境变量,我们可以在配置部署的应用程序时使用这些变量。
我们更愿意在 Secrets 文件中提供 MariaDB 连接密码,如以下示例所示:
apiVersion: v1
kind: Secret
metadata:
name: mariadb
labels:
app: mariadb
data:
database-password: eW91cnBhc3N3b3Jk
密码是 base64 编码的值。
11.6. 数据库
关系数据库用于存储流和任务定义以及已执行任务的状态。 Spring Cloud Data Flow 为 MariaDB、MySQL、Oracle、PostgreSQL、Db2、SQL Server 和 H2 提供模式。服务器启动时会自动创建模式。
MariaDB、MySQL(通过 MariaDB 驱动程序)、PostgreSQL、SQL Server 的 JDBC 驱动程序无需额外配置即可使用。要使用任何其他数据库,您需要将相应的 JDBC 驱动程序 jar 放在服务器的类路径上,如此处所述。 |
要配置数据库,必须设置以下属性:
-
spring.datasource.url
-
spring.datasource.username
-
spring.datasource.password
-
spring.datasource.driver-class-name
-
spring.jpa.database-platform
这username
和password
无论数据库如何,都是相同的。但是,url
和driver-class-name
每个数据库都不同,如下所示。
数据库 | spring.datasource.url | spring.datasource.driver-class-name | spring.jpa.数据库平台 | 包括Drivers |
---|---|---|---|---|
MariaDB 10.0 - 10.1 |
jdbc:mariadb://${db-hostname}:${db-port}/${db-name} |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MariaDB10方言 |
是的 |
MariaDB 10.2 |
jdbc:mariadb://${db-hostname}:${db-port}/${db-name} |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MariaDB102方言 |
是的 |
MariaDB 10.3 - 10.5 |
jdbc:mariadb://${db-hostname}:${db-port}/${db-name} |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MariaDB103方言 |
是的 |
MariaDB 10.6+ |
jdbc:mariadb://${db-hostname}:${db-port}/${db-name} |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MariaDB106方言[3] |
是的 |
MySQL 5.7 的 |
jdbc:mysql://${db-hostname}:${db-port}/${db-name}?permitMysqlScheme |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MySQL57方言 |
是的 |
MySQL 8.0+ |
jdbc:mysql://${db-hostname}:${db-port}/${db-name}?allowPublicKeyRetrieval=true&useSSL=false&autoReconnect=true&permitMysqlScheme[4] |
org.mariadb.jdbc.驱动程序 |
org.hibernate.dialect.MySQL8Dialect |
是的 |
PostgresSQL |
jdbc:postgres://${db-hostname}:${db-port}/${db-name} |
org.postgresql.驱动程序 |
移除休眠默认值 |
是的 |
SQL 服务器 |
jdbc:sqlserver://${db-hostname}:${db-port};数据库名称=${db-name}&encrypt=false |
com.microsoft.sqlserver.jdbc.SQLServer驱动程序 |
移除休眠默认值 |
是的 |
DB2 |
jdbc:db2://${db-hostname}:${db-port}/{db-name} |
com.ibm.db2.jcc.DB2驱动程序 |
移除休眠默认值 |
不 |
神谕 |
JDBC:oracle:thin:@${db-hostname}:${db-port}/{db-name} |
oracle.jdbc.Oracle驱动程序 |
移除休眠默认值 |
不 |
11.6.1. H2
当没有配置其他数据库时,Spring Cloud Data Flow 使用 H2 数据库的嵌入式实例作为默认实例。
H2 适用于开发目的,但不建议用于生产用途,也不支持作为外部模式。 |
11.6.2. 数据库配置
在 Kubernetes 中运行时,数据库属性通常在 ConfigMap 中设置。例如,如果您在 secrets 文件中除了密码之外还使用 MariaDB,则可以在 ConfigMap 中提供以下属性:
data:
application.yaml: |-
spring:
datasource:
url: jdbc:mariadb://${MARIADB_SERVICE_HOST}:${MARIADB_SERVICE_PORT}/database
username: root
password: ${database-password}
driverClassName: org.mariadb.jdbc.Driver
同样,对于 PostgreSQL,您可以使用以下配置:
data:
application.yaml: |-
spring:
datasource:
url: jdbc:postgresql://${PGSQL_SERVICE_HOST}:${PGSQL_SERVICE_PORT}/database
username: root
password: ${postgres-password}
driverClassName: org.postgresql.Driver
Deployment 中的以下 YAML 代码片段是将 ConfigMap 挂载为application.yaml
下/config
Spring Boot 将处理它以及挂载在/etc/secrets
由于环境变量,它将被 spring-cloud-kubernetes 库拾取SPRING_CLOUD_KUBERNETES_SECRETS_PATHS
设置为/etc/secrets
.
...
containers:
- name: scdf-server
image: springcloud/spring-cloud-dataflow-server:2.11.3-SNAPSHOT
imagePullPolicy: IfNotPresent
volumeMounts:
- name: config
mountPath: /config
readOnly: true
- name: database
mountPath: /etc/secrets/database
readOnly: true
ports:
...
volumes:
- name: config
configMap:
name: scdf-server
items:
- key: application.yaml
path: application.yaml
- name: database
secret:
secretName: mariadb
您可以在 spring-cloud-task 存储库中找到特定数据库类型的迁移脚本。
11.7. 监控和管理
我们建议使用kubectl
命令,用于对流和任务进行故障排除。
您可以使用以下命令列出使用的所有项目和资源:
kubectl get all,cm,secrets,pvc
您可以使用标签选择资源来列出特定应用程序或服务使用的所有资源。以下命令列出了mariadb
服务:
kubectl get all -l app=mariadb
您可以通过发出以下命令来获取特定 Pod 的日志:
kubectl logs pod <pod-name>
如果容器持续重新启动,您可以将-p
作为查看上一个日志的选项,如下所示:
kubectl logs -p <pod-name>
您还可以通过添加-f
选项,如下所示:
kubectl logs -f <pod-name>
帮助解决问题(例如容器在启动时出现致命错误)的一个有用命令是使用describe
命令,如以下示例所示:
kubectl describe pod ticktock-log-0-qnk72
11.7.1. 检查服务器日志
您可以使用以下命令访问服务器日志:
kubectl get pod -l app=scdf=server
kubectl logs <scdf-server-pod-name>
11.7.2. 流
流应用程序的部署带有流名称,后跟应用程序名称。对于处理器和接收器,还会附加实例索引。
要查看 Spring Cloud Data Flow 服务器部署的所有 Pod,您可以指定role=spring-app
标签,如下所示:
kubectl get pod -l role=spring-app
若要查看特定应用程序部署的详细信息,可以使用以下命令:
kubectl describe pod <app-pod-name>
要查看应用程序日志,您可以使用以下命令:
kubectl logs <app-pod-name>
如果要跟踪日志,可以使用以下命令:
kubectl logs -f <app-pod-name>
11.7.3. 任务
任务作为裸容器启动,没有复制控制器。任务完成后,容器仍会保留,这使您有机会查看日志。
要查看特定任务的所有容器,请使用以下命令:
kubectl get pod -l task-name=<task-name>
若要查看任务日志,请使用以下命令:
kubectl logs <task-pod-name>
您有两个选项可以删除已完成的容器。一旦不再需要它们,您可以手动删除它们,也可以使用数据流 shelltask execution cleanup
命令以删除已完成的 Pod 以执行任务。
要手动删除任务 Pod,请使用以下命令:
kubectl delete pod <task-pod-name>
要使用task execution cleanup
命令,您必须首先确定ID
用于任务执行。为此,请使用task execution list
命令,如以下示例(带输出)所示:
dataflow:>task execution list
╔═════════╤══╤════════════════════════════╤════════════════════════════╤═════════╗
║Task Name│ID│ Start Time │ End Time │Exit Code║
╠═════════╪══╪════════════════════════════╪════════════════════════════╪═════════╣
║task1 │1 │Fri May 05 18:12:05 EDT 2017│Fri May 05 18:12:05 EDT 2017│0 ║
╚═════════╧══╧════════════════════════════╧════════════════════════════╧═════════╝
获得 ID 后,您可以发出命令来清理执行工件(已完成的 Pod),如以下示例所示:
dataflow:>task execution cleanup --id 1
Request to clean up resources for task execution 1 has been submitted
任务的数据库凭证
默认情况下,Spring Cloud Data Flow 在任务启动时将数据库凭据作为属性传递给 Pod。
如果使用exec
或shell
入口点样式,如果用户执行kubectl describe
在任务的 Pod 上。
要将 Spring Cloud Data Flow 配置为使用 Kubernetes Secrets:将spring.cloud.dataflow.task.use.kubernetes.secrets.for.db.credentials
属性设置为true
.如果使用 Spring Cloud Data Flow 提供的 yaml 文件,请更新 'src/kubernetes/server/server-deployment.yaml 以添加以下环境变量:
- name: SPRING_CLOUD_DATAFLOW_TASK_USE_KUBERNETES_SECRETS_FOR_DB_CREDENTIALS
value: 'true'
如果从以前版本的 SCDF 升级,请务必验证spring.datasource.username
和spring.datasource.password
环境变量存在于secretKeyRefs
在 server-config.yaml 中。如果没有,请按以下示例所示添加它:
...
task:
platform:
kubernetes:
accounts:
default:
secretKeyRefs:
- envVarName: "spring.datasource.password"
secretName: mariadb
dataKey: database-password
- envVarName: "spring.datasource.username"
secretName: mariadb
dataKey: database-username
...
此外,请验证关联的密钥 (dataKey) 是否在密钥中也可用。SCDF 在此处为 MariaDB 提供了一个示例:src/kubernetes/mariadb/mariadb-svc.yaml
.
默认情况下,通过属性传递数据库凭据是为了保持向后兼容性。此功能将在将来的版本中删除。 |
11.8. 调度
本节介绍如何配置计划任务的自定义。默认情况下,任务调度在 Spring Cloud Data Flow Kubernetes Server 中启用。属性用于影响计划任务的设置,并且可以全局或按计划进行配置。
除非另有说明,否则按计划设置的属性始终优先于设置为服务器配置的属性。这种安排允许覆盖特定计划的全局服务器级属性。 |
11.8.1. 入口点样式
入口点样式会影响应用程序属性传递到要部署的任务容器的方式。目前,支持三种样式:
-
exec
:(默认)将所有应用程序属性作为命令行参数传递。 -
shell
:将所有应用程序属性作为环境变量传递。 -
boot
:创建一个名为SPRING_APPLICATION_JSON
包含所有应用程序属性的 JSON 表示形式。
您可以按如下方式配置入口点样式:
deployer.kubernetes.entryPointStyle=<Entry Point Style>
取代<Entry Point Style>
替换为所需的入口点样式。
您还可以在容器中的服务器级别配置入口点样式env
部分,如以下示例所示:
env:
- name: SPRING_CLOUD_DEPLOYER_KUBERNETES_ENTRY_POINT_STYLE
value: entryPointStyle
取代entryPointStyle
替换为所需的入口点样式。
您应该选择 入口点样式exec
或shell
,以对应于ENTRYPOINT
语法在容器的Dockerfile
.有关更多信息和用例exec
与shell
,请参阅 Docker 文档的 ENTRYPOINT 部分。
使用boot
入口点样式对应于使用exec
风格ENTRYPOINT
. 部署请求中的命令行参数将传递到容器,并添加映射到SPRING_APPLICATION_JSON
环境变量而不是命令行参数。
ttl秒后完成
计划应用程序时,您可以通过指定ttlSecondsAfterFinished
价值。
以下示例显示了如何配置计划的应用程序作业:
deployer.<application>.kubernetes.cron.ttlSecondsAfterFinished=86400
以下示例显示如何单独配置应用程序作业:
deployer.<application>.kubernetes.ttlSecondsAfterFinished=86400
取代<application>
替换为您的应用程序名称和ttlSecondsAfterFinished
属性为清理已完成作业的适当值。
您可以配置ttlSecondsAfterFinished
在全球服务器级别也是如此。
以下示例显示了如何对任务执行此作:
您可以在容器中的服务器级别配置镜像拉取策略env
部分,如以下示例所示:
env:
- name: SPRING_CLOUD_DEPLOYER_KUBERNETES_TTL_SECONDS_AFTER_FINISHED
value: 86400
11.8.2. 环境变量
要影响给定应用程序的环境设置,您可以利用spring.cloud.deployer.kubernetes.environmentVariables
财产。
例如,生产环境中的一个常见要求是影响 JVM 内存参数。
您可以通过使用JAVA_TOOL_OPTIONS
环境变量,如以下示例所示:
deployer.kubernetes.environmentVariables=JAVA_TOOL_OPTIONS=-Xmx1024m
在部署流应用程序或启动某些属性可能包含敏感信息的任务应用程序时,请使用shell 或boot 作为entryPointStyle .这是因为exec (默认)将所有属性转换为命令行参数,因此在某些环境中可能不安全。 |
此外,您可以在容器中的服务器级别配置环境变量env
部分,如以下示例所示:
在服务器配置中指定环境变量并按计划指定环境变量时,环境变量将被合并。这允许在服务器配置中设置通用环境变量,并在特定计划级别设置更具体的环境变量。 |
env:
- name: SPRING_CLOUD_DEPLOYER_KUBERNETES_ENVIRONMENT_VARIABLES
value: myVar=myVal
取代myVar=myVal
替换为所需的环境变量。
11.8.3. 镜像拉取策略
映像拉取策略定义何时应将 Docker 映像拉取到本地注册表。目前,支持三种策略:
-
IfNotPresent
:(默认)如果图像已存在,则不要拉取它。 -
Always
:始终拉取图像,无论它是否已经存在。 -
Never
:切勿拉取图像。仅使用已存在的图像。
以下示例演示如何单独配置容器:
deployer.kubernetes.imagePullPolicy=IfNotPresent
取代Always
使用所需的映像拉取策略。
您可以在容器中的服务器级别配置镜像拉取策略env
部分,如以下示例所示:
env:
- name: SPRING_CLOUD_DEPLOYER_KUBERNETES_IMAGE_PULL_POLICY
value: Always
取代Always
使用所需的映像拉取策略。
11.8.4. 私有 Docker 注册表
可以通过配置 Secret 来提取私有且需要身份验证的 Docker 镜像。首先,您必须在集群中创建一个密钥。按照从私有注册表拉取映像指南创建密钥。
创建密钥后,使用imagePullSecret
属性来设置要使用的密钥,如以下示例所示:
deployer.kubernetes.imagePullSecret=mysecret
取代mysecret
替换为您之前创建的密钥的名称。
您还可以在容器中的服务器级别配置镜像拉取密钥env
部分,如以下示例所示:
env:
- name: SPRING_CLOUD_DEPLOYER_KUBERNETES_IMAGE_PULL_SECRET
value: mysecret
取代mysecret
替换为您之前创建的密钥的名称。
11.8.5. 命名空间
默认情况下,用于计划任务的命名空间为default
. 可以在容器中的服务器级别配置中设置此值env
部分,如以下示例所示:
env:
- name: SPRING_CLOUD_DEPLOYER_KUBERNETES_NAMESPACE
value: mynamespace
11.8.6. 服务帐户
您可以通过属性为计划任务配置自定义服务帐户。可以使用现有服务帐户或创建新服务帐户。创建服务帐户的一种方法是使用kubectl
,如以下示例所示:
$ kubectl create serviceaccount myserviceaccountname
serviceaccount "myserviceaccountname" created
然后,您可以配置服务帐户以按计划使用,如下所示:
deployer.kubernetes.taskServiceAccountName=myserviceaccountname
取代myserviceaccountname
替换为您的服务帐户名称。
您还可以在容器中的服务器级别配置服务帐户名称env
部分,如以下示例所示:
env:
- name: SPRING_CLOUD_DEPLOYER_KUBERNETES_TASK_SERVICE_ACCOUNT_NAME
value: myserviceaccountname
取代myserviceaccountname
替换为要应用于所有部署的服务帐户名称。
有关计划任务的详细信息,请参阅计划任务。
11.9. 调试支持
通过 Java Debug Wire Protocol (JDWP) 支持调试 Spring Cloud Data Flow Kubernetes Server 和包含的组件(例如 Spring Cloud Kubernetes Deployer)。本节概述了一种手动启用调试的方法,以及另一种使用 Spring Cloud Data Flow Server Kubernetes 提供的配置文件来“修补”正在运行的部署的方法。
JDWP 本身不使用任何身份验证。本节假设调试是在本地开发环境(例如 Minikube)上完成的,因此不提供有关保护调试端口的指南。 |
11.9.1. 手动启用调试
要手动启用 JDWP,请先编辑src/kubernetes/server/server-deployment.yaml
,然后添加额外的containerPort
在spec.template.spec.containers.ports
值为5005
.此外,将JAVA_TOOL_OPTIONS
环境变量spec.template.spec.containers.env
如以下示例所示:
spec:
...
template:
...
spec:
containers:
- name: scdf-server
...
ports:
...
- containerPort: 5005
env:
- name: JAVA_TOOL_OPTIONS
value: '-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005'
前面的示例使用端口 5005,但它可以是与另一个端口不冲突的任何数字。所选的端口号也必须与添加的containerPort value 和address 参数JAVA_TOOL_OPTIONS -agentlib 标志,如前面的示例所示。 |
您现在可以启动 Spring Cloud Data Flow Kubernetes Server。服务器启动后,您可以验证scdf-server
部署,如以下示例(带输出)所示:
kubectl describe deployment/scdf-server
...
...
Pod Template:
...
Containers:
scdf-server:
...
Ports: 80/TCP, 5005/TCP
...
Environment:
JAVA_TOOL_OPTIONS: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
...
启动服务器并启用 JDWP 后,您需要配置对端口的访问。在此示例中,我们使用port-forward
子命令kubectl
.以下示例(带输出)演示如何使用port-forward
:
$ kubectl get pod -l app=scdf-server
NAME READY STATUS RESTARTS AGE
scdf-server-5b7cfd86f7-d8mj4 1/1 Running 0 10m
$ kubectl port-forward scdf-server-5b7cfd86f7-d8mj4 5005:5005
Forwarding from 127.0.0.1:5005 -> 5005
Forwarding from [::1]:5005 -> 5005
现在,可以通过将调试器指向127.0.0.1
作为主持人和5005
作为端口。这port-forward
子命令运行直到停止(通过按CTRL+c
,例如)。
可以通过将更改还原为src/kubernetes/server/server-deployment.yaml
.恢复的更改将在 Spring Cloud Data Flow Kubernetes Server 的下一次部署中选取。当每次部署服务器时都应默认启用调试时,手动向配置添加调试支持非常有用。
11.9.2. 使用补丁启用调试
而不是手动更改server-deployment.yaml
,Kubernetes 对象可以就地“修补”。为方便起见,包括提供与手动方法相同配置的补丁文件。要通过修补启用调试,请使用以下命令:
kubectl patch deployment scdf-server -p "$(cat src/kubernetes/server/server-deployment-debug.yaml)"
运行上述命令会自动添加containerPort
属性和JAVA_TOOL_OPTIONS
环境变量。 以下示例(带输出)演示了如何验证对scdf-server
部署:
$ kubectl describe deployment/scdf-server
...
...
Pod Template:
...
Containers:
scdf-server:
...
Ports: 5005/TCP, 80/TCP
...
Environment:
JAVA_TOOL_OPTIONS: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
...
要启用对调试端口的访问,而不是使用port-forward
子命令kubectl
,您可以修补scdf-server
Kubernetes 服务对象。您必须首先确保scdf-server
Kubernetes 服务对象具有正确的配置。以下示例(带输出)显示了如何执行此作:
kubectl describe service/scdf-server
Port: <unset> 80/TCP
TargetPort: 80/TCP
NodePort: <unset> 30784/TCP
如果输出包含<unset>
,您必须修补服务才能为此端口添加名称。以下示例演示了如何执行此作:
$ kubectl patch service scdf-server -p "$(cat src/kubernetes/server/server-svc.yaml)"
仅当在添加调试功能之前创建了目标集群时,才应缺少端口名称。由于将多个端口添加到scdf-server Kubernetes 服务对象,每个对象都需要有自己的名称。 |
现在,您可以添加调试端口,如以下示例所示:
kubectl patch service scdf-server -p "$(cat src/kubernetes/server/server-svc-debug.yaml)"
以下示例(带输出)演示如何验证映射:
$ kubectl describe service scdf-server
Name: scdf-server
...
...
Port: scdf-server-jdwp 5005/TCP
TargetPort: 5005/TCP
NodePort: scdf-server-jdwp 31339/TCP
...
...
Port: scdf-server 80/TCP
TargetPort: 80/TCP
NodePort: scdf-server 30883/TCP
...
...
输出显示容器端口 5005 已映射到 31339 的 NodePort。以下示例(带输出)显示了如何获取 Minikube 节点的 IP 地址:
$ minikube ip
192.168.99.100
使用此信息,可以使用主机 192.168.99.100 和端口 31339 创建调试连接。
以下示例显示了如何禁用 JDWP:
$ kubectl rollout undo deployment/scdf-server
$ kubectl patch service scdf-server --type json -p='[{"op": "remove", "path": "/spec/ports/0"}]'
Kubernetes 部署对象在修补之前回滚到其状态。然后,Kubernetes 服务对象将使用remove
从containerPorts
列表。
kubectl rollout undo 强制 Pod 重新启动。修补 Kubernetes 服务对象不会重新创建服务,并且端口映射到scdf-server 部署保持不变。 |
有关部署回滚的更多信息,请参阅回滚部署,包括管理历史记录和使用 kubectl 补丁就地更新 API 对象。
12. 使用 Carvel 进行部署
部署 carvel 包需要安装工具和特定的 Kubernetes 控制器。然后,您将把包存储库添加到集群并安装应用程序。
对于本地 minikube 或 kind 集群,您可以使用:配置 Kubernetes 以进行本地开发或测试,并按照说明进行作,直到部署 Spring Cloud Data Flow 部分
12.1. 所需工具
-
kubectl
- Kubernetes CLI(使用brew install kubectl
) -
carvel
- 打包和部署工具
Carvel CLI 可以使用以下方式安装:
wget -O- https://carvel.dev/install.sh | bash
# or with curl...
curl -L https://carvel.dev/install.sh | bash
替代方法按照主页底部的说明进行作,地址为 carvel.dev
脚本使用以下工具。
-
jq
- 轻量级 JSON 解析器 -
yq
- 轻量级 YAML 解析器 -
wget
- 调用 http 请求。 -
dirname
提供文件名的目录部分。 -
readlink
提供相对链路的绝对路径。
默认情况下,其中一些实用程序未安装在 macOS 或 *nix 中,但可以从 MacPorts 或 HomeBrew 获得。 |
12.2. 脚本
这些脚本假定您已连接到 Kubernetes 集群,并且kubectl
可用。
名称 | 参数 | 描述 |
---|---|---|
|
<broker> [scdf 类型] [命名空间] [release|snapshot] |
配置其余脚本的环境变量需求。 |
|
不适用 |
安装 cert-manager、secretgen-controller 和 kapp-controller |
|
[scdf型](OSS、专业版) |
创建 |
|
<secret-name> <namespace> [secret-namespace] [--import|--placeholder] |
使用 secretgen-controller 创建导入密钥、占位符或导入。 |
|
[scdf型](OSS、专业版) |
创建命名空间并安装相关的 Carvel 包和凭据。如果未提供可选的 scdf-type 环境变量 |
|
<host> <port> [步骤] |
为数据流、Skipper、Streams 和 Tasks 配置 Spring Boot Actuator 属性。违约 |
|
<app> <database> <url> <用户名/秘密名称> [密码/秘密用户名密钥] [秘密密码密钥] |
如果仅提供 secret-name,则 secret-username-key 默认为 url 后允许使用以下 3 种组合:
|
|
[应用名称] |
使用包和 |
|
[应用名称] |
使用修改后的值文件更新了已部署的应用程序。默认应用程序名称为 |
|
不适用 |
将打印用于访问数据流的 URL。如果您使用 |
|
<broker> [流应用程序版本] |
broker 必须是 rabbit 或 kafka 之一。stream-application-version 是可选的,将安装最新版本。最新版本是 2021.1.2 |
请注意,在专业版中注册应用程序可能需要几分钟,因为它会预先检索所有版本信息和元数据。 |
12.3. 准备
您需要准备一个名为 scdf-values.yml 的值文件 以下步骤将提供帮助。
12.3.1. 准备配置参数
执行以下脚本将配置所需的环境变量。
source ./carvel/start-deploy.sh <broker> <namespace> [scdf-type] [release|snapshot]
哪里:
-
broker
是 rabbitmq 或 kafka 之一 -
namespace
有效的 Kubernetes 命名空间,而不是default
-
scdf-type
oss 或 pro 之一。oss 是默认值。 -
release|snapshot
和scdf-type
将决定PACKAGE_VERSION
.
*确保使用所需包的类型和版本的最佳选择是修改deploy/versions.yaml
*
也可以手动配置环境变量以覆盖这些值。
名称 | 描述 | 默认值 |
---|---|---|
|
Carvel 软件包的版本。 |
发布版本 |
|
Spring Cloud Data Flow 版本 |
2.11.2 |
|
Spring Cloud Data Flow Pro 版本 |
1.6.1 |
|
Spring Cloud Skipper 版本 |
2.11.2 |
|
包注册表的 URL 和存储库。格式 |
|
|
其中之一 |
|
|
其中之一 |
|
|
Kubernetes 命名空间以外的 |
|
|
其中之一 |
|
仅当与deploy/versions.yaml
|
12.4. 准备集群并添加存储库
登录 docker 并可选择 registry.tanzu.vmware.com Spring Cloud Data Flow Pro。
# When deploying SCDF Pro.
export TANZU_DOCKER_USERNAME="<tanzu-net-username>"
export TANZU_DOCKER_PASSWORD="<tanzu-net-password>"
docker login --username $TANZU_DOCKER_USERNAME --password $TANZU_DOCKER_PASSWORD registry.packages.broadcom.com
# Always required to ensure you don't experience rate limiting with Docker HUB
export DOCKER_HUB_USERNAME="<docker-hub-username>"
export DOCKER_HUB_PASSWORD="<docker-hub-password>"
docker login --username $DOCKER_HUB_USERNAME --password $DOCKER_HUB_PASSWORD index.docker.io
安装 carvel kapp-controller、secretgen-controller 和 certmanager
./carvel/prepare-cluster.sh
加载 scdf 类型的 scdf 存储库包
./carvel/setup-scdf-repo.sh
12.5. 安装支持服务
在生产环境中,您应该使用受支持的数据库和代理服务或运算符以及共享的可观测性工具。
对于本地开发或演示,可以使用以下内容来安装数据库、代理和 prometheus。
12.6. 配置 Prometheus 代理
在部署了现有 prometheus 和 prometheus 代理的情况下,可以使用以下方法配置代理:
./carvel/configure-prometheus-proxy.sh <host> <port> [step]