应用
- 1: 部署应用程序
- 2: 使用 Buildpacks
- 3: 使用 Dockerfiles
- 4: 使用容器镜像
- 5: 管理应用进程
- 6: 配置应用程序
- 7: 管理应用指标
- 8: 管理应用
- 9: 为应用挂载卷
- 10: 关于应用的网关
- 11: 管理应用的资源
- 12: 应用间通信
- 13: 资源限制
- 14: 域名和路由
- 15: 应用 SSL 证书
- 16: 使用 drycc 路径
1 - 部署应用程序
[应用程序][] 使用 git push 或 drycc 客户端部署到 Drycc。
支持的应用程序
Drycc Workflow 可以部署任何可以在容器中运行的应用程序或服务。为了能够水平扩展，应用程序必须遵循 Twelve-Factor App 方法，并将任何应用程序状态存储在外部后端服务中。
例如，如果您的应用程序将状态持久化到本地文件系统（这在内容管理系统如 WordPress 和 Drupal 中很常见），则无法使用 drycc scale 进行水平扩展。
幸运的是，大多数现代应用程序具有无状态的应用程序层，可以在 Drycc 中水平扩展。
登录到控制器
Note
如果您还没有，现在是安装客户端并注册的好时机。在部署应用程序之前，用户必须首先使用 Drycc 管理员提供的 URL 对 Drycc [控制器][] 进行身份验证。
$ drycc login http://drycc.example.com
Opening browser to http://drycc.example.com/v2/login/drycc/?key=4ccc81ee2dce4349ad5261ceffe72c71
Waiting for login... .o.Logged in as admin
Configuration file written to /root/.drycc/client.json
或者您可以使用用户名和密码登录
$ drycc login http://drycc.example.com --username=demo --password=demo
Configuration file written to /root/.drycc/client.json
选择构建过程
Drycc Workflow 支持三种不同的应用程序构建方式：
Buildpacks
Cloud Native Buildpacks 如果您想遵循 cnb’s docs 来构建应用程序会很有用。
了解如何使用 Buildpacks 部署应用程序。
Dockerfiles
Dockerfiles 是一种强大的方式，可以定义基于您选择的基础操作系统的可移植执行环境。
了解如何使用 Dockerfiles 部署应用程序。
容器镜像
将容器镜像部署到 Drycc 允许您从公共或私有注册表获取容器镜像，并逐位复制，确保您在开发环境或 CI 流水线中运行的镜像与生产环境中的镜像相同。
了解如何使用容器镜像部署应用程序。
调整应用程序设置
可以使用 config:set 在每个应用程序基础上配置一些全局可调设置。
| 设置 | 描述 |
|---|---|
| DRYCC_DISABLE_CACHE | 如果设置，将禁用 [imagebuilder 缓存][]（默认：未设置） |
| DRYCC_DEPLOY_BATCHES | 在扩展期间顺序启动和停止的 pod 数量（默认：可用节点数量） |
| DRYCC_DEPLOY_TIMEOUT | 每个部署批次的部署超时时间（秒）（默认：120） |
| IMAGE_PULL_POLICY | 应用程序镜像的 Kubernetes [镜像拉取策略][pull-policy]（默认：“IfNotPresent”）（允许值：“Always”、“IfNotPresent”） |
| KUBERNETES_DEPLOYMENTS_REVISION_HISTORY_LIMIT | Kubernetes 为给定 Deployment 保留的修订数量（默认：所有修订） |
| KUBERNETES_POD_TERMINATION_GRACE_PERIOD_SECONDS | Kubernetes 在发送 SIGKILL 之前等待 pod 完成工作的秒数（默认：30） |
部署超时
部署超时（秒）- 有两种部署方法，Deployments（见下文）和 RC（2.4 版本之前），此设置对它们的影响略有不同。
Deployments
Deployments 的行为与基于 RC 的部署策略略有不同。
Kubernetes 负责整个部署，在后台进行滚动更新。因此，只有一个整体部署超时，而不是可配置的每批次超时。
基础超时乘以 DRYCC_DEPLOY_BATCHES 来创建整体超时。这将是 240（超时）* 4（批次）= 960 秒整体超时。
RC 部署
此部署超时定义在 DRYCC_DEPLOY_BATCHES 中等待每个批次完成的时长。
基础超时的附加项
基础超时也会通过健康检查使用 liveness 和 readiness 上的 initialDelaySeconds 进行扩展，其中应用较大的那个。
此外，超时系统通过在看到镜像拉取超过 1 分钟时添加额外 10 分钟来考虑慢速镜像拉取。这允许超时值合理，而不必在基础部署超时中考虑镜像拉取的缓慢。
Deployments
Workflow 使用 Deployments 进行部署。在之前的版本中，使用 ReplicationControllers，可以通过 DRYCC_KUBERNETES_DEPLOYMENTS=1 启用 Deployments。
Deployments 的优势是滚动更新将在 Kubernetes 服务器端发生，而不是在 Drycc Workflow Controller 中进行，以及其他一些 Pod 管理相关功能。这允许即使 CLI 连接中断，部署也能继续。
在后台，您的应用程序部署将由每个进程类型的 Deployment 对象组成，每个对象有多个 ReplicaSets（每个发布一个），这些 ReplicaSets 反过来管理运行您的应用程序的 Pods。
Drycc Workflow 的行为在启用或禁用 DRYCC_KUBERNETES_DEPLOYMENTS 时相同（仅适用于 2.4 版本之前）。
变化发生在后台。您在使用 CLI 时会看到差异的地方是 drycc ps:list 将以不同的方式输出 Pod 名称。
2 - 使用 Buildpacks
Drycc 支持通过 Cloud Native Buildpacks 部署应用程序。如果您想遵循 cnb 的文档 来构建应用程序，Cloud Native Buildpacks 会很有用。
添加 SSH 密钥
对于通过 git push 的基于 Buildpack 的应用程序部署，Drycc Workflow 通过 SSH 密钥识别用户。SSH 密钥被推送到平台，并且必须对每个用户唯一。
-
请参阅 此文档 以获取生成 SSH 密钥的说明。
-
运行
drycc keys add将您的 SSH 密钥上传到 Drycc Workflow。
$ drycc keys add ~/.ssh/id_drycc.pub
Uploading id_drycc.pub to drycc... done
阅读有关添加/删除 SSH 密钥的更多信息 此处。
准备应用程序
如果您没有现有应用程序，您可以克隆演示 Heroku Buildpack 工作流的示例应用程序。
$ git clone https://github.com/drycc/example-go.git
$ cd example-go
创建应用程序
使用 drycc create 在 Controller 上创建应用程序。
$ drycc create
Creating application... done, created skiing-keypunch
Git remote drycc added
推送以部署
使用 git push drycc master 部署您的应用程序。
$ git push drycc master
Counting objects: 75, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (75/75), 18.28 KiB | 0 bytes/s, done.
Total 75 (delta 30), reused 58 (delta 22)
remote: --->
Starting build... but first, coffee!
---> Waiting podman running.
---> Process podman started.
---> Waiting caddy running.
---> Process caddy started.
---> Building pack
---> Using builder registry.drycc.cc/drycc/buildpacks:bookworm
Builder 'registry.drycc.cc/drycc/buildpacks:bookworm' is trusted
Pulling image 'registry.drycc.cc/drycc/buildpacks:bookworm'
Resolving "drycc/buildpacks" using unqualified-search registries (/etc/containers/registries.conf)
Trying to pull registry.drycc.cc/drycc/buildpacks:bookworm...
Getting image source signatures
...
---> Skip generate base layer
---> Python Buildpack
---> Downloading and extracting Python 3.10.0
---> Installing requirements with pip
Collecting Django==3.2.8
Downloading Django-3.2.8-py3-none-any.whl (7.9 MB)
Collecting gunicorn==20.1.0
Downloading gunicorn-20.1.0-py3-none-any.whl (79 kB)
Collecting sqlparse>=0.2.2
Downloading sqlparse-0.4.2-py3-none-any.whl (42 kB)
Collecting pytz
Downloading pytz-2021.3-py2.py3-none-any.whl (503 kB)
Collecting asgiref<4,>=3.3.2
Downloading asgiref-3.4.1-py3-none-any.whl (25 kB)
Requirement already satisfied: setuptools>=3.0 in /layers/drycc_python/python/lib/python3.10/site-packages (from gunicorn==20.1.0->-r requirements.txt (line 2)) (57.5.0)
Installing collected packages: sqlparse, pytz, asgiref, gunicorn, Django
Successfully installed Django-3.2.8 asgiref-3.4.1 gunicorn-20.1.0 pytz-2021.3 sqlparse-0.4.2
---> Generate Launcher
...
Build complete.
Launching App...
...
Done, skiing-keypunch:v2 deployed to Workflow
Use 'drycc open' to view this application in your browser
To learn more, use 'drycc help' or visit https://www.drycc.cc
To ssh://git@drycc.staging-2.drycc.cc:2222/skiing-keypunch.git
* [new branch] master -> master
$ curl -s http://skiing-keypunch.example.com
Powered by Drycc
Release v2 on skiing-keypunch-v2-web-02zb9
因为检测到 Buildpacks 风格的应用程序，web 进程类型在首次部署时自动扩展到 1。
使用 drycc scale web=3 将 web 进程增加到 3，例如。直接扩展进程类型会更改运行该进程的 pods 数量。
包含的 Buildpacks
为方便起见，Drycc 捆绑了许多 buildpacks：
- Go Buildpack
- Java Buildpack
- Nodejs Buildpack
- PHP Buildpack
- Python Buildpack
- Ruby Buildpack
- Rust Buildpack
Drycc 将循环遍历每个 buildpack 的 bin/detect 脚本以匹配您推送的代码。
Note
如果您正在测试 [Scala Buildpack][]，[Builder][] 至少需要 512MB 可用内存来执行 Scala Build Tool。使用自定义 Buildpack
要使用自定义 buildpack，您需要在您的根路径应用中创建 .pack_builder 文件。
$ tee > .pack-builder << EOF
> registry.drycc.cc/drycc/buildpacks:bookworm
> EOF
在您的下一次 git push 中，将使用自定义 buildpack。
使用私有仓库
要从私有仓库拉取代码，将 SSH_KEY 环境变量设置为具有访问权限的私钥。使用私钥文件的路径或原始密钥材料：
$ drycc config set SSH_KEY=/home/user/.ssh/id_rsa
$ drycc config set SSH_KEY="""-----BEGIN RSA PRIVATE KEY-----
(...)
-----END RSA PRIVATE KEY-----"""
例如，要使用托管在私有 GitHub URL 的自定义 buildpack，请确保 SSH 公钥存在于您的 [GitHub 设置][] 中。然后将 SSH_KEY 设置为相应的 SSH 私钥，并将 .pack_builder 设置为构建器镜像：
$ tee > .pack-builder << EOF
> registry.drycc.cc/drycc/buildpacks:bookworm
> EOF
$ git add .buildpack
$ git commit -m "chore(buildpack): modify the pack_builder"
$ git push drycc master
构建器选择器
构建项目的哪种方式符合以下原则：
- 如果项目中存在 Dockerfile，堆栈使用
container - 如果项目中存在 Procfile，堆栈使用
buildpack - 如果两者都存在，默认使用
container - 您也可以设置
DRYCC_STACK为container或buildpack来确定使用哪种堆栈。
3 - 使用 Dockerfiles
Drycc 支持通过 Dockerfiles 部署应用程序。Dockerfile 自动化了制作 [容器镜像][] 的步骤。 Dockerfiles 非常强大，但需要额外的工作来定义您的确切应用程序运行时环境。
添加 SSH 密钥
对于通过 git push 的基于 Dockerfile 的应用程序部署，Drycc Workflow 通过 SSH 密钥识别用户。SSH 密钥被推送到平台，并且必须对每个用户唯一。
-
请参阅 此文档 以获取生成 SSH 密钥的说明。
-
运行
drycc keys add将您的 SSH 密钥上传到 Drycc Workflow。
$ drycc keys add ~/.ssh/id_drycc.pub
Uploading id_drycc.pub to drycc... done
阅读有关添加/删除 SSH 密钥的更多信息 此处。
准备应用程序
如果您没有现有应用程序，您可以克隆演示 Dockerfile 工作流的示例应用程序。
$ git clone https://github.com/drycc/helloworld.git
$ cd helloworld
Dockerfile 要求
为了部署 Dockerfile 应用程序，它们必须符合以下要求：
- Dockerfile 必须使用
EXPOSE指令来公开恰好一个端口。 - 该端口必须监听 HTTP 连接。
- Dockerfile 必须使用
CMD指令来定义将在容器内运行的默认进程。 - 容器镜像必须包含 bash 来运行进程。
Note
请注意，如果您使用任何类型的私有注册表（gcr 或其他），应用程序环境必须包含与 EXPOSE 端口匹配的 $PORT 配置变量，例如：drycc config set PORT=5000。有关更多信息，请参阅 配置注册表。
创建应用程序
使用 drycc create 在 Controller 上创建应用程序。
$ drycc create
Creating application... done, created folksy-offshoot
Git remote drycc added
推送部署
使用 git push drycc master 部署您的应用程序。
$ git push drycc master
Counting objects: 13, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (13/13), 1.99 KiB | 0 bytes/s, done.
Total 13 (delta 2), reused 0 (delta 0)
-----> Building Docker image
Uploading context 4.096 kB
Uploading context
Step 0 : FROM drycc/base:latest
---> 60024338bc63
Step 1 : RUN wget -O /tmp/go1.2.1.linux-amd64.tar.gz -q https://go.googlecode.com/files/go1.2.1.linux-amd64.tar.gz
---> Using cache
---> cf9ef8c5caa7
Step 2 : RUN tar -C /usr/local -xzf /tmp/go1.2.1.linux-amd64.tar.gz
---> Using cache
---> 515b1faf3bd8
Step 3 : RUN mkdir -p /go
---> Using cache
---> ebf4927a00e9
Step 4 : ENV GOPATH /go
---> Using cache
---> c6a276eded37
Step 5 : ENV PATH /usr/local/go/bin:/go/bin:$PATH
---> Using cache
---> 2ba6f6c9f108
Step 6 : ADD . /go/src/github.com/drycc/helloworld
---> 94ab7f4b977b
Removing intermediate container 171b7d9fdb34
Step 7 : RUN cd /go/src/github.com/drycc/helloworld && go install -v .
---> Running in 0c8fbb2d2812
github.com/drycc/helloworld
---> 13b5af931393
Removing intermediate container 0c8fbb2d2812
Step 8 : ENV PORT 80
---> Running in 9b07da36a272
---> 2dce83167874
Removing intermediate container 9b07da36a272
Step 9 : CMD ["/go/bin/helloworld"]
---> Running in f7b215199940
---> b1e55ce5195a
Removing intermediate container f7b215199940
Step 10 : EXPOSE 80
---> Running in 7eb8ec45dcb0
---> ea1a8cc93ca3
Removing intermediate container 7eb8ec45dcb0
Successfully built ea1a8cc93ca3
-----> Pushing image to private registry
Launching... done, v2
-----> folksy-offshoot deployed to Drycc
http://folksy-offshoot.local3.dryccapp.com
To learn more, use `drycc help` or visit https://www.drycc.cc
To ssh://git@local3.dryccapp.com:2222/folksy-offshoot.git
* [new branch] master -> master
$ curl -s http://folksy-offshoot.local3.dryccapp.com
Welcome to Drycc!
See the documentation at http://docs.drycc.cc/ for more information.
因为检测到 Dockerfile 应用程序，web 进程类型在首次部署时自动扩展到 1。
使用 drycc scale web=3 将 web 进程增加到 3，例如。直接扩展进程类型会更改运行该进程的 容器 数量。
容器构建参数
从 Workflow v2.13.0 开始，用户可以使用 容器构建参数 将其应用程序配置注入到容器镜像中。要选择加入，用户必须向其应用程序添加新的环境变量：
$ drycc config set DRYCC_DOCKER_BUILD_ARGS_ENABLED=1
使用 drycc config set 设置的每个环境变量都将在用户的 Dockerfile 中可用。例如，如果用户运行 drycc config set POWERED_BY=Workflow，用户可以在其 Dockerfile 中使用该构建参数：
ARG POWERED_BY
RUN echo "Powered by $POWERED_BY" > /etc/motd
4 - 使用容器镜像
Drycc 支持通过现有的 [Docker 镜像][] 部署应用程序。 这对于将 Drycc 集成到基于 Docker 的 CI/CD 流水线中很有用。
准备应用程序
首先克隆示例应用程序：
$ git clone https://github.com/drycc/example-dockerfile-http.git
$ cd example-dockerfile-http
接下来使用您的本地 docker 客户端构建镜像并推送
到 DockerHub。
$ docker build -t <username>/example-dockerfile-http .
$ docker push <username>/example-dockerfile-http
Docker 镜像要求
为了部署 Docker 镜像，它们必须符合以下要求：
- Dockerfile 必须使用
EXPOSE指令来公开恰好一个端口。 - 该端口必须监听 HTTP 连接。
- Dockerfile 必须使用
CMD指令来定义将在容器内运行的默认进程。 - Docker 镜像必须包含 bash 来运行进程。
Note
请注意，如果您使用任何类型的私有注册表（gcr 或其他），应用程序环境必须包含与 EXPOSE 端口匹配的 $PORT 配置变量，例如：drycc config set PORT=5000。有关更多信息，请参阅配置注册表。
创建应用程序
使用 drycc create 在 controller 上创建应用程序。
$ mkdir -p /tmp/example-dockerfile-http && cd /tmp/example-dockerfile-http
$ drycc create example-dockerfile-http --no-remote
Creating application... done, created example-dockerfile-http
Note
对于除drycc create 之外的所有命令，如果您没有使用 --app 明确指定，drycc 客户端会使用当前目录的名称作为应用程序名称。
部署应用程序
使用 drycc pull 从 DockerHub 或
公共注册表部署您的应用程序。
$ drycc pull <username>/example-dockerfile-http:latest
Creating build... done, v2
$ curl -s http://example-dockerfile-http.local3.dryccapp.com
Powered by Drycc
因为您正在部署 Docker 镜像，web 进程类型在首次部署时自动扩展到 1。
使用 drycc scale web=3 将 web 进程增加到 3，例如。直接扩展进程类型会更改运行该进程的 容器 数量。
私有注册表
要从私有注册表或私有仓库部署 Docker 镜像，请使用 drycc registry
将凭据附加到您的应用程序。这些凭据与您在私有注册表运行
docker login 时使用的凭据相同。
要部署私有 Docker 镜像，请执行以下步骤：
- 收集注册表的用户名和密码，例如 Quay.io Robot Account 或 GCR.io Long Lived Token
- 运行
drycc registry set <the-user> <secret> -a <application-name> - 现在像往常一样对私有注册表中的镜像执行
drycc pull
当使用 GCR.io Long Lived Token 时，JSON blob 必须首先使用
jq 等工具压缩，然后在 drycc registry set 的密码字段中使用。对于用户名，使用
_json_key。例如：
drycc registry set _json_key "$(cat google_cloud_cred.json | jq -c .)"
当使用私有注册表时，Docker 镜像不再通过 Drycc Workflow Controller 拉取到 Drycc 内部注册表，而是由 Kubernetes 管理。这将提高安全性和整体速度，
但是应用程序 port 信息无法再被发现。相反，应用程序 port 信息可以通过
drycc config set PORT=80 在设置注册表信息之前设置。
Note
目前不支持短寿命认证令牌模式的 [GCR.io][] 和 [ECR][]。5 - 管理应用进程
Drycc Workflow 将您的应用作为一组可以根据其角色命名、扩展和配置的进程进行管理。这为您提供了灵活性，可以轻松管理应用的各个方面。例如，您可能有面向 Web 的进程处理 HTTP 流量、后台工作进程执行异步工作，以及从 Twitter API 流式传输的辅助进程。
通过使用 Procfile（已检入您的应用或通过 CLI 提供），您可以指定类型的名称和应运行的应用命令。要生成其他进程类型，请使用 drycc scale <ptype>=<n> 来相应地扩展这些类型。
默认进程类型
在没有 Procfile 的情况下，为每个应用假设单个默认进程类型。
使用 Buildpacks 通过 git push 构建的应用隐式接收 web 进程类型，该类型启动应用服务器。例如，Rails 4 具有以下进程类型：
web: bundle exec rails server -p $PORT
所有使用 Dockerfiles 的应用都有一个隐含的 web 进程类型，该类型运行 Dockerfile 的 CMD 指令而不修改：
$ cat Dockerfile
FROM centos:latest
COPY . /app
WORKDIR /app
CMD python -m SimpleHTTPServer 5000
EXPOSE 5000
对于上述基于 Dockerfile 的应用，web 进程类型将运行容器的 CMD python -m SimpleHTTPServer 5000。
使用 远程容器镜像 的应用也会隐含 web 进程类型，并运行容器镜像中指定的 CMD。
Note
web 进程类型是特殊的，因为它是默认进程类型，将从 Workflow 的路由器接收 HTTP 流量。其他进程类型可以任意命名。
声明进程类型
如果您使用 Buildpack 或 Dockerfile 构建并想要覆盖或指定其他进程类型，只需在应用源树的根目录中包含一个名为 Procfile 的文件。
Procfile 的格式是每行一个进程类型，每行包含要调用的命令：
<process type>: <command>
语法定义为：
<process type>– 小写字母数字字符串，是您的命令的名称，如 web、worker、urgentworker、clock 等。<command>– 启动进程的命令行，如rake jobs:work。
此示例 Procfile 指定了两种类型，web 和 sleeper。web 进程在端口 5000 上启动 Web 服务器，一个简单的进程休眠 900 秒然后退出。
$ cat Procfile
web: bundle exec ruby web.rb -p ${PORT:-5000}
sleeper: sleep 900
如果您使用 远程容器镜像，您可以通过在工作目录中使用 Procfile 运行 drycc pull，或通过将字符串化的 Procfile 传递给 --procfile CLI 选项来定义进程类型。
例如，内联传递进程类型：
$ drycc pull drycc/example-go:latest --procfile="web: /app/bin/boot"
读取另一个目录中的 Procfile：
$ drycc pull drycc/example-go:latest --procfile="$(cat deploy/Procfile)"
或通过位于当前工作目录中的 Procfile：
$ cat Procfile
web: /bin/boot
sleeper: echo "sleeping"; sleep 900
$ drycc pull -a steely-mainsail drycc/example-go
Creating build... done
$ drycc scale sleeper=1 -a steely-mainsail
Scaling processes... but first, coffee!
done in 0s
NAME RELEASE STATE PTYPE READY RESTARTS STARTED
steely-mainsail-sleeper-76c45b967c-4qm6w v3 up sleeper 1/1 0 2023-12-08T02:25:00UTC
steely-mainsail-web-c4f44c4b4-7p7dh v3 up web 1/1 0 2023-12-08T02:25:00UTC
Note
只有web 进程类型会自动扩展到 1。如果您有其他进程类型，请记住创建后扩展进程计数。
要删除进程类型，只需将其扩展到 0：
$ drycc scale sleeper=0 -a steely-mainsail
Scaling processes... but first, coffee!
done in 3s
NAME RELEASE STATE PTYPE READY RESTARTS STARTED
steely-mainsail-web-c4f44c4b4-7p7dh v3 up web 1/1 0 2023-12-08T02:25:00UTC
扩展进程
部署在 Drycc Workflow 上的应用通过 [进程模型][] 向外扩展。使用 drycc scale 来控制为您的应用提供动力的 容器 数量。
$ drycc scale web=5 -a iciest-waggoner
Scaling processes... but first, coffee!
done in 3s
NAME RELEASE STATE PTYPE READY RESTARTS STARTED
iciest-waggoner-web-c4f44c4b4-7p7dh v3 up web 1/1 0 2023-12-08T02:25:00UTC
iciest-waggoner-web-c4f44c4b4-8p7dh v3 up web 1/1 0 2023-12-08T02:25:00UTC
iciest-waggoner-web-c4f44c4b4-9p7dh v3 up web 1/1 0 2023-12-08T02:25:00UTC
iciest-waggoner-web-c4f44c4b4-1p7dh v3 up web 1/1 0 2023-12-08T02:25:00UTC
iciest-waggoner-web-c4f44c4b4-2p7dh v3 up web 1/1 0 2023-12-08T02:25:00UTC
如果您的应用有多个进程类型，您可以分别为每个类型扩展进程计数。例如，这允许您独立管理 Web 进程和后台工作进程。有关进程类型的更多信息，请参阅我们的 管理应用进程 文档。
在此示例中，我们将进程类型 web 扩展到 5，但将进程类型 background 保留为一个工作进程。
$ drycc scale web=5
Scaling processes... but first, coffee!
done in 4s
NAME RELEASE STATE PTYPE READY RESTARTS STARTED
scenic-icehouse-web-3291896318-7lord v3 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-web-3291896318-jn957 v3 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-web-3291896318-rsekj v3 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-web-3291896318-vwhnh v3 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-web-3291896318-vokg7 v3 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-web-3291896318-vokg7 v3 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-background-3291896318-yf8kh v3 up web 1/1 0 2023-12-08T02:25:00UTC
通过减少进程计数来扩展进程会向进程发送 TERM 信号，如果它们在 30 秒内未退出，则跟随 SIGKILL。根据您的应用，扩展可能会中断长时间运行的 HTTP 客户端连接。
例如，从 5 个进程扩展到 3：
$ drycc scale web=3
Scaling processes... but first, coffee!
done in 1s
NAME RELEASE STATE PTYPE READY RESTARTS STARTED
scenic-icehouse-web-3291896318-vwhnh v2 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-web-3291896318-vokg7 v2 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-web-3291896318-vokg9 v2 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-background-3291896318-yf8kh v2 up web 1/1 0 2023-12-08T02:25:00UTC
自动扩展
自动扩展允许在每个进程类型的基础上添加最小和最大数量的 Pod。这是通过指定所有可用 Pod 的目标 CPU 使用率来实现的。
此功能建立在 Kubernetes 中的 Horizontal Pod Autoscaling 或简称 HPA 之上。
Note
这是一个 alpha 功能。建议在使用此功能时使用最新的 Kubernetes。$ drycc autoscale set web --min=3 --max=8 --cpu-percent=75
Applying autoscale settings for process type web on scenic-icehouse... done
然后查看为 web 创建的扩展规则
$ drycc autoscale list
PTYPE PERCENT MIN MAX
web 75 3 8
删除扩展规则
$ drycc autoscale unset web
Removing autoscale for process type web on scenic-icehouse... done
为了使自动扩展工作，必须在每个应用 Pod 上指定 CPU 请求（可以通过 drycc limits --cpu 完成）。这允许自动扩展策略进行 适当计算 并决定何时向上和向下扩展。
向上扩展只能在过去 3 分钟内没有重新扩展的情况下发生。向下扩展将等待上次重新扩展后的 5 分钟。该信息和更多信息可以在 HPA 算法页面 找到。
获取应用容器的日志
列出容器：
$ drycc ps
NAME RELEASE STATE PTYPEE READY RESTARTS STARTED
python-getting-started-web-69b7d4bfdc-kl4xf v2 up web 1/1 0 2023-12-08T02:25:00UTC
=== python-getting-started Processes
--- web:
python-getting-started-web-69b7d4bfdc-kl4xf up (v2)
获取容器日志：
$ drycc ps logs -f python-getting-started-web-69b7d4bfdc-kl4xf
[2024-05-24 07:14:39 +0000] [1] [INFO] Starting gunicorn 20.1.0
[2024-05-24 07:14:39 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2024-05-24 07:14:39 +0000] [1] [INFO] Using worker: gevent
[2024-05-24 07:14:39 +0000] [8] [INFO] Booting worker with pid: 8
[2024-05-24 07:14:39 +0000] [9] [INFO] Booting worker with pid: 9
[2024-05-24 07:14:39 +0000] [10] [INFO] Booting worker with pid: 10
[2024-05-24 07:14:39 +0000] [11] [INFO] Booting worker with pid: 11
获取应用容器的信息
列出容器：
$ drycc ps describe python-getting-started-web-69b7d4bfdc-kl4xf
Container: python-getting-started-web
Image: drycc/python-getting-started:latest
Command:
Args:
- gunicorn
- -c
- gunicorn_config.py
- helloworld.wsgi:application
State: running
startedAt: "2024-05-24T07:14:39Z"
Ready: true
Restart Count: 0
删除应用容器
删除容器。 由于设置了副本数量，将启动新容器以满足数量要求。
$ drycc ps delete python-getting-started-web-69b7d4bfdc-kl4xf
Deleting python-getting-started-web-69b7d4bfdc-kl4xf from python-getting-started... done
获取运行容器的 Shell
验证容器正在运行：
$ drycc ps
NAME RELEASE STATE PTYPEE READY RESTARTS STARTED
python-getting-started-web-69b7d4bfdc-kl4xf v2 up web 1/1 0 2023-12-08T02:25:00UTC
=== python-getting-started Processes
--- web:
python-getting-started-web-69b7d4bfdc-kl4xf up (v2)
获取运行容器的 shell：
$ drycc ps exec python-getting-started-web-69b7d4bfdc-kl4xf -it -- bash
在您的 shell 中，列出根目录：
# 在容器内运行此命令
ls /
在容器中运行单个命令
$ drycc ps exec python-getting-started-web-69b7d4bfdc-kl4xf -- date
使用 “drycc ps –help” 获取全局命令行列表（适用于所有命令）。
重启应用进程
如果您需要重启应用进程，您可以使用 drycc pts restart。在幕后，Drycc Workflow 指示 Kubernetes 终止旧进程并启动新进程来替换它。
$ drycc ps
NAME RELEASE STATE PTYPE READY RESTARTS STARTED
scenic-icehouse-web-3291896318-vokg7 v2 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-web-3291896318-rsekj v2 up web 1/1 0 2023-12-08T02:50:21UTC
scenic-icehouse-web-3291896318-vokg7 v2 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-background-3291896318-yf8kh v2 up web 1/1 0 2023-12-08T02:25:00UTC
$ drycc pts restart scenic-icehouse-background
NAME RELEASE STATE PTYPE READY RESTARTS STARTED
scenic-icehouse-web-3291896318-vokg7 v2 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-web-3291896318-rsekj v2 up web 1/1 0 2023-12-08T02:50:21UTC
scenic-icehouse-web-3291896318-vokg7 v2 up web 1/1 0 2023-12-08T02:25:00UTC
scenic-icehouse-background-3291896318-yf8kh v2 starting web 1/1 0 2023-12-08T02:25:00UTC
注意进程名称已从 scenic-icehouse-background-3291896318-yf8kh 更改为 scenic-icehouse-background-3291896318-yd87g。在多节点 Kubernetes 集群中，这也可能具有将 Pod 调度到新节点的效果。
使用 “drycc pts –help” 获取 pts 命令行列表（进程类型信息）。
列出应用进程类型
$ drycc pts
NAME RELEASE READY UP-TO-DATE AVAILABLE GARBAGE STARTED
web v2 3/3 1 1 true 2023-12-08T02:25:00UTC
background v2 1/1 1 1 false 2023-12-08T02:25:00UTC
清理进程类型
清理不存在的 ptype，通常在 autodeploy 设置为 true 时自动执行。
$ drycc pts clean background
获取应用进程类型的部署信息
$ drycc pts describe web
Container: python-getting-started-web
Image: drycc/python-getting-started:latest
Command:
Args:
- gunicorn
- -c
- gunicorn_config.py
- helloworld.wsgi:application
Limits:
cpu 1
ephemeral-storage 2Gi
memory 1Gi
Liveness: http-get headers=[] path=/geo/ port=8000 delay=120s timeout=10s period=20s #success=1 #failure=3
Readiness: http-get headers=[] path=/geo/ port=8000 delay=120s timeout=10s period=20s #success=1 #failure=3
6 - 配置应用程序
配置应用程序
Drycc 应用程序[将配置存储在环境变量中][]。
设置环境变量
使用 drycc config 修改已部署应用程序的环境变量。
$ drycc help config
管理定义应用配置的环境变量
用法：
drycc config [flags]
drycc config [command]
可用命令：
info 应用配置信息
set 为应用设置环境变量
unset 取消设置应用的环境变量
pull 将环境变量拉取到路径
push 从路径推送环境变量
attach 选择要附加到应用 ptype 的环境组
detach 选择要从应用 ptype 分离的环境组
标志：
-a, --app string 应用程序的唯一可识别名称
-g, --group string 需要列出配置的组
-p, --ptype string 需要列出配置的 ptype
-v, --version int 需要列出配置的版本
全局标志：
-c, --config string 配置文件路径。（默认 "~/.drycc/client.json"）
-h, --help 显示帮助信息
使用 "drycc config [command] --help" 获取有关命令的更多信息。
当配置更改时，会自动创建并部署新版本。
您可以使用一个 drycc config set 命令设置多个环境变量，
或者使用 drycc config push 和本地 .env 文件。
$ drycc config set FOO=1 BAR=baz && drycc config pull
$ cat .env
FOO=1
BAR=baz
$ echo "TIDE=high" >> .env
$ drycc config push
Creating config... done, v4
=== yuppie-earthman
DRYCC_APP: yuppie-earthman
FOO: 1
BAR: baz
TIDE: high
它可以修改应用程序进程类型的环境变量。
$ drycc config set FOO=1 BAR=baz --ptype=web
它还可以修改环境组的环境变量。
$ drycc config set FOO1=1 BAR1=baz --group=web.env
然后将此环境变量组绑定到 web。
$ drycc config attach web web.env
当然，您也可以分离它。
$ drycc config detach web web.env
附加到后端服务
Drycc 将数据库、缓存和队列等后端服务视为[附加资源][]。 附加使用环境变量执行。
例如，使用 drycc config 设置 DATABASE_URL，将
应用程序附加到外部 PostgreSQL 数据库。
$ drycc config set DATABASE_URL=postgres://user:pass@example.com:5432/db
=== peachy-waxworks
DATABASE_URL: postgres://user:pass@example.com:5432/db
可以使用 drycc config unset 执行分离。
Buildpacks 缓存
默认情况下，使用 [Imagebuilder][] 的应用将重用最新的镜像数据。 在部署依赖于必须获取的第三方库的应用程序时， 这可以大大加快部署速度。为了利用这一点，buildpack 必须通过写入缓存目录来实现 缓存。大多数 buildpack 已经实现了这一点，但在使用 自定义 buildpack 时，可能需要更改以充分利用缓存。
禁用和重新启用缓存
在某些情况下，缓存可能不会加快您的应用程序速度。要禁用缓存，您可以使用 drycc config set DRYCC_DISABLE_CACHE=1 设置
DRYCC_DISABLE_CACHE 变量。当您禁用缓存时，Drycc 将清除它创建的用于存储缓存的文件。关闭后，运行
drycc config unset DRYCC_DISABLE_CACHE 来重新启用缓存。
清除缓存
使用以下过程清除缓存：
$ drycc config set DRYCC_DISABLE_CACHE=1
$ git commit --allow-empty -m "Clearing Drycc cache"
$ git push drycc # (如果您使用不同的远程仓库，您应该使用您的远程仓库名称)
$ drycc config unset DRYCC_DISABLE_CACHE
自定义健康检查
默认情况下，Workflow 仅检查应用程序是否在其容器中启动。可以为应用程序配置健康检查探针来添加健康检查。健康检查作为 Kubernetes 容器探针实现。可以配置 ‘startupProbe’ ’livenessProbe’ 和 ‘readinessProbe’，每个探针可以是 ‘httpGet’、’exec’ 或 ’tcpSocket’ 类型，具体取决于容器所需的探针类型。
‘startupProbe’ 指示容器内的应用程序是否已启动。 如果提供了启动探针，则所有其他探针都被禁用，直到它成功。 如果启动探针失败，容器将受到其重启策略的影响。
’livenessProbe’ 对于长时间运行的应用程序很有用，最终 会过渡到损坏状态，除非通过重启它们，否则无法恢复。
其他时候，‘readinessProbe’ 很有用，当容器只是暂时无法 服务，并且会自行恢复。在这种情况下，如果容器未能通过 ‘readinessProbe’， 容器不会被关闭，而是容器将停止接收 传入请求。
‘httpGet’ 探针正如其名称：它在容器上执行 HTTP GET 操作。 200-399 范围内的响应代码被视为通过。‘httpGet’ 探针接受一个 端口号，以便在容器上执行 HTTP GET 操作。
’exec’ 探针在容器内运行命令来确定其健康状况。退出代码为 零被视为通过，而非零状态代码被视为失败。’exec’ 探针接受要在容器内运行的参数字符串。
’tcpSocket’ 探针尝试在容器中打开套接字。只有当检查可以建立连接时，容器才被视为健康。’tcpSocket’ 探针接受一个 端口号，以便在容器上执行套接字连接。
可以使用 drycc healthchecks set 为每个应用程序的每个 proctype 配置健康检查。如果未提及类型，则健康检查将应用于默认进程类型 web（无论存在哪个）。要
配置 httpGet liveness 探针：
$ drycc healthchecks set livenessProbe httpGet 80 --ptype web
Applying livenessProbe healthcheck... done
App: peachy-waxworks
UUID: afd84067-29e9-4a5f-9f3a-60d91e938812
Owner: dev
Created: 2023-12-08T10:25:00Z
Updated: 2023-12-08T10:25:00Z
Healthchecks:
livenessProbe web http-get headers=[] path=/ port=80 delay=50s timeout=50s period=10s #success=1 #failure=3
If the application relies on certain headers being set (such as the Host header) or a specific
URL path relative to the root, you can also send specific HTTP headers:
$ drycc healthchecks set livenessProbe httpGet 80 \
--path /welcome/index.html \
--headers "X-Client-Version:v1.0,X-Foo:bar"
Applying livenessProbe healthcheck... done
App: peachy-waxworks
UUID: afd84067-29e9-4a5f-9f3a-60d91e938812
Owner: dev
Created: 2023-12-08T10:25:00Z
Updated: 2023-12-08T10:25:00Z
Healthchecks:
livenessProbe web http-get headers=[X-Client-Version=v1.0] path=/welcome/index.html port=80 delay=50s timeout=50s period=10s #success=1 #failure=3
To configure an exec readiness probe:
$ drycc healthchecks set readinessProbe exec -- /bin/echo -n hello --ptype web
Applying readinessProbe healthcheck... done
App: peachy-waxworks
UUID: afd84067-29e9-4a5f-9f3a-60d91e938812
Owner: dev
Created: 2023-12-08T10:25:00Z
Updated: 2023-12-08T10:25:00Z
Healthchecks:
readinessProbe web exec /bin/echo -n hello delay=50s timeout=50s period=10s #success=1 #failure=3
You can overwrite a probe by running drycc healthchecks set again:
$ drycc healthchecks set readinessProbe httpGet 80 --ptype web
Applying livenessProbe healthcheck... done
App: peachy-waxworks
UUID: afd84067-29e9-4a5f-9f3a-60d91e938812
Owner: dev
Created: 2023-12-08T10:25:00Z
Updated: 2023-12-08T10:25:00Z
Healthchecks:
livenessProbe web http-get headers=[] path=/ port=80 delay=50s timeout=50s period=10s #success=1 #failure=3
Configured health checks also modify the default application deploy behavior. When starting a new Pod, Workflow will wait for the health check to pass before moving onto the next Pod.
自动部署
默认情况下，更改配置、限制或健康检查等将触发部署。 如果您不想部署，可以禁用。
$ drycc autodeploy disable
要重新启用自动部署。
drycc autodeploy enable
您可以通过执行以下命令进行部署。 部署所有 ptype
drycc releases deploy
部署 web 进程类型，并支持 --force 选项强制部署。
drycc releases deploy web --force
自动回滚
默认情况下，部署失败将回滚到之前的成功版本。 如果您不想发生这种情况，可以禁用。
$ drycc autorollback disable
要重新启用自动回滚。
drycc autorollback enable
隔离应用程序
Workflow 支持使用 drycc tags 将应用程序隔离到一组节点上。
Note
为了使用标签，您必须首先使用适当的节点标签启动集群。如果您没有这样做，标签命令将失败。通过阅读[“将 Pod 分配给节点”][pods-to-nodes]了解更多。一旦您的节点配置了适当的标签选择器，使用 drycc tags set 将应用程序 ptype 限制到这些节点：
$ drycc tags set web environ=prod
Applying tags... done, v4
environ prod
7 - 管理应用指标
创建认证令牌
使用 drycc 客户端创建认证令牌。
# drycc tokens add prometheus --password admin --username admin
! WARNING: Make sure to copy your token now.
! You won't be able to see it again, please confirm whether to continue.
! To proceed, type "yes" !
> yes
UUID USERNAME TOKEN
58176cf1-37a8-4c52-9b27-4c7a47269dfb admin 1F2c7A802aF640fd9F31dD846AdDf56BcMsay
为 prometheus 添加抓取配置
有效的示例文件可以在这里找到。
全局配置指定在所有其他配置上下文中有效的参数。它们还作为其他配置部分的默认值。
global:
scrape_interval: 60s
evaluation_interval: 60s
scrape_configs:
- job_name: 'drycc'
scheme: https
metrics_path: /v2/apps/<appname>/metrics
authorization:
type: Token
credentials: 1F2c7A802aF640fd9F31dD846AdDf56BcMsay
static_configs:
- targets: ['drycc.domain.com']
8 - 管理应用
跟踪应用更改
Drycc Workflow 跟踪对您的应用的所有更改。应用更改是新应用代码推送到平台（通过 git push drycc master）或应用配置更新（通过 drycc config:set KEY=VAL）的结果。
每次对您的应用进行构建或配置更改时，都会创建一个新的 release。这些发布编号单调递增。
您可以使用 drycc releases 查看对您的应用的更改记录：
$ drycc releases
OWNER STATE VERSION CREATED SUMMARY
dev succeed v3 2023-12-04T10:17:46Z dev deleted PIP_INDEX_URL, DISABLE_COLLECTSTATIC
dev succeed v2 2023-12-01T10:20:22Z dev added IMAGE_PULL_POLICY, PIP_INDEX_URL, PORT, DISABLE_COLLEC[...]
dev succeed v1 2023-11-30T17:54:57Z dev created initial release
回滚发布
Drycc Workflow 还支持回滚到以前的发布。如果有问题的代码或错误的配置更改被推送到您的应用，您可以回滚到以前已知良好的发布。
Note
所有回滚都会创建一个新的编号发布。但将引用所需回滚点的构建/代码和配置。在此示例中，应用当前运行发布 v4。使用 drycc rollback v2 告诉 Workflow 部署用于发布 v2 的构建和配置。这创建一个名为 v5 的新发布，其内容是发布 v2 的源代码和配置：
$ drycc releases
OWNER STATE VERSION CREATED SUMMARY
dev succeed v3 2023-12-04T10:17:46Z dev deleted PIP_INDEX_URL, DISABLE_COLLECTSTATIC
dev succeed v2 2023-12-01T10:20:22Z dev added IMAGE_PULL_POLICY, PIP_INDEX_URL, PORT, DISABLE_COLLEC[...]
dev succeed v1 2023-11-30T17:54:57Z dev created initial release
$ drycc rollback v2
Rolled back to v2
$ drycc releases
OWNER STATE VERSION CREATED SUMMARY
dev succeed v4 2023-12-04T10:20:46Z dev rolled back to v2
dev succeed v3 2023-12-04T10:17:46Z dev deleted PIP_INDEX_URL, DISABLE_COLLECTSTATIC
dev succeed v2 2023-12-01T10:20:22Z dev added IMAGE_PULL_POLICY, PIP_INDEX_URL, PORT, DISABLE_COLLEC[...]
dev succeed v1 2023-11-30T17:54:57Z dev created initial release
仅回滚 web 进程类型：
$ drycc rollback v3 web
Rolled back to v3
$ drycc releases
OWNER STATE VERSION CREATED SUMMARY
dev succeed v5 2023-12-04T10:23:49Z dev rolled back to v3
dev succeed v4 2023-12-04T10:20:46Z dev rolled back to v2
dev succeed v3 2023-12-04T10:17:46Z dev deleted PIP_INDEX_URL, DISABLE_COLLECTSTATIC
dev succeed v2 2023-12-01T10:20:22Z dev added IMAGE_PULL_POLICY, PIP_INDEX_URL, PORT, DISABLE_COLLEC[...]
dev succeed v1 2023-11-30T17:54:57Z dev created initial release
运行一次性管理任务
Drycc 应用 [使用一次性进程进行管理任务][] 如数据库迁移和其他必须针对实时应用运行的命令。
使用 drycc run 在部署的应用上执行命令。
$ drycc run -- 'ls -l'
Running `ls -l`...
total 28
-rw-r--r-- 1 root root 553 Dec 2 23:59 LICENSE
-rw-r--r-- 1 root root 60 Dec 2 23:59 Procfile
-rw-r--r-- 1 root root 33 Dec 2 23:59 README.md
-rw-r--r-- 1 root root 1622 Dec 2 23:59 pom.xml
drwxr-xr-x 3 root root 4096 Dec 2 23:59 src
-rw-r--r-- 1 root root 25 Dec 2 23:59 system.properties
drwxr-xr-x 6 root root 4096 Dec 3 00:00 target
共享应用
使用 drycc perms add 允许其他 Drycc 用户与您协作应用。
$ drycc perms add otheruser view,change,delete
Adding user otheruser as a collaborator for view,change,delete peachy-waxwork... done
使用 drycc perms 查看应用当前与谁共享，使用 drycc perms remove 删除协作者。
Note
协作者可以对应用执行所有者可以执行的任何操作，除了删除应用。在使用与您共享的应用时，克隆原始存储库并在尝试 git push 任何更改到 Drycc 之前添加 Drycc 的 git 远程条目。
$ git clone https://github.com/drycc/example-java-jetty.git
Cloning into 'example-java-jetty'... done
$ cd example-java-jetty
$ git remote add -f drycc ssh://git@local3.dryccapp.com:2222/peachy-waxworks.git
Updating drycc
From drycc-controller.local:peachy-waxworks
* [new branch] master -> drycc/master
应用故障排除
部署在 Drycc Workflow 上的应用 [将日志视为事件流][]。Drycc Workflow 聚合每个 Container 的 stdout 和 stderr，使排除应用问题变得容易。
使用Drycc Grafana查看部署应用的日志输出。
Dec 3 00:30:31 ip-10-250-15-201 peachy-waxworks[web.5]: INFO:oejsh.ContextHandler:started o.e.j.s.ServletContextHandler{/,null}
Dec 3 00:30:31 ip-10-250-15-201 peachy-waxworks[web.8]: INFO:oejs.Server:jetty-7.6.0.v20120127
Dec 3 00:30:31 ip-10-250-15-201 peachy-waxworks[web.5]: INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:10005
Dec 3 00:30:31 ip-10-250-15-201 peachy-waxworks[web.6]: INFO:oejsh.ContextHandler:started o.e.j.s.ServletContextHandler{/,null}
Dec 3 00:30:31 ip-10-250-15-201 peachy-waxworks[web.7]: INFO:oejsh.ContextHandler:started o.e.j.s.ServletContextHandler{/,null}
Dec 3 00:30:31 ip-10-250-15-201 peachy-waxworks[web.6]: INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:10006
Dec 3 00:30:31 ip-10-250-15-201 peachy-waxworks[web.7]: INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:10007
Dec 3 00:30:31 ip-10-250-15-201 peachy-waxworks[web.8]: INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:10008
9 - 为应用挂载卷
我们可以使用以下命令创建卷并挂载已创建的卷。 Drycc 创建卷支持 ReadWriteMany，因此在部署 drycc 之前，您需要有一个支持 ReadWriteMany 的 StorageClass。 部署 drycc 时，将 controller.appStorageClass 设置为此 StorageClass。
使用 drycc volumes 为已部署应用的进程挂载卷。
$ drycc help volumes
Valid commands for volumes:
add create a volume for the application
expand expand a volume for the application
list list volumes in the application
info print information about a volume
remove delete a volume from the application
client the client used to manage volume files
mount mount a volume to process of the application
unmount unmount a volume from process of the application
Use 'drycc help [command]' to learn more.
为应用创建卷
您可以使用 drycc volumes add 命令创建 csi 卷。
$ drycc volumes add myvolume 200M
Creating myvolume to scenic-icehouse... done
或使用现有的 nfs 服务器
$ drycc volumes add mynfsvolume 200M -t nfs --nfs-server=nfs.drycc.com --nfs-path=/
Creating mynfsvolume to scenic-icehouse... done
或使用现有的 oss3
$ drycc volumes add myossvolume 200M -t oss --oss-server=oss.drycc.com --oss-bucket=vbucket --oss-access-key=ak --oss-secret-key=sk
Creating myossvolume to scenic-icehouse... done
列出应用中的卷
卷创建后，您可以列出此应用中的卷。
$ drycc volumes list
NAME OWNER TYPE PTYPE PATH SIZE
myvolume admin csi 200M
mynfsvolume admin nfs 200M
myossvolume admin oss 200M
挂载卷
名为 myvolume 的卷已创建，您可以使用应用的进程挂载该卷，使用 drycc volumes mount 命令。卷挂载时，将自动创建并部署新版本。
$ drycc volumes mount myvolume web=/data/web
Mounting volume... done
使用 drycc volumes list 显示挂载详情。
$ drycc volumes list
NAME OWNER TYPE PTYPE PATH SIZE
myvolume admin nfs web /data/web 200M
如果您不再需要卷，请使用 drycc volumes unmount 卸载卷，然后使用 drycc volumes remove 从应用中删除卷。
删除卷之前，必须先卸载卷。
$ drycc volumes unmount myvolume web
Unmounting volume... done
$ drycc volumes remove myvolume
Deleting myvolume from scenic-icehouse... done
使用卷客户端管理卷文件。
假设名为 myvolume 的卷已创建并挂载。
准备一个名为 testfile 的文件。
$ echo "testtext" > testfile
上传。 $ drycc volumes client cp testfile vol://myvolume/ [↑] testfile 100% [==================================================] (5/ 5 B, 355 B/s)
列出 myvolume 中的文件。
$ drycc volumes client ls vol://myvolume/
[2024-07-22T15:32:28+08:00] 5 testfile
删除 myvolume 中的 testfile。
$ drycc volumes client rm vol://myvolume/testfile
10 - 关于应用的网关
Gateway 描述了如何将流量转换为集群内的服务。也就是说，它定义了一种将流量从不知道 Kubernetes 的地方转换为知道的地方的方式。例如，由云负载均衡器、集群内代理或外部硬件负载均衡器发送到 Kubernetes 服务的流量。虽然许多用例的客户端流量源于"集群外部"，但这不是必需的。
为应用创建网关
网关是一种对外暴露服务的方式，它生成一个外部 IP 地址来连接路由和服务。 部署后，网关已创建。
列出容器：
# drycc gateways
NAME LISENTER PORT PROTOCOL ADDRESSES
python-getting-started tcp-80-0 80 HTTP 101.65.132.51
您也可以在此网关中添加端口或创建一个端口。
# drycc gateways add python-getting-started --port=443 --protocol=HTTPS
Adding gateway python-getting-started to python-getting-started... done
为应用创建服务
服务是一种对内暴露服务的方式，创建服务会生成一个内部 DNS，可以访问 ptype。
web 进程类型已创建，对于其他类型，您应该根据需要添加。
列出服务：
$ drycc services
PTYPE PORT PROTOCOL TARGET-PORT DOMAIN
web 80 TCP 8000 python-getting-started.python-getting-started.svc
为进程类型添加新服务
# drycc services add --help
# drycc services add sleep 8001:8001
为应用创建路由
网关可以附加到一个或多个路由引用，这些路由引用用于将部分流量引导到特定服务。 与上述相同，web 进程类型已经绑定了网关和服务。
# drycc routes
NAME OWNER KIND GATEWAYS SERVICES
python-getting-started demo HTTPRoute ["python-getting-started:80"] ["python-getting-started:80"]
创建新路由并附加网关。
drycc routes add sleep HTTPRoute --ptype=sleep sleep:8001,100
drycc routes attach sleep --gateway=python-getting-started --port=80
11 - 管理应用的资源
我们可以使用以下命令创建资源并绑定已创建的资源。 此命令依赖于 service-catalog。
使用 drycc resources 为已部署的应用创建和绑定资源。
$ drycc help resources
Manage resources for your applications
Usage:
drycc resources [flags]
drycc resources [command]
Available Commands:
services List all available resource services
plans List all available plans for a resource service
create Create a resource for the application
list List resources in the application
describe Get a resource's detail in the application
update Update a resource from the application
bind Bind a resource for an application
unbind unbind a resources for an application
destroy Delete a resource from the application
Flags:
-a, --app string The uniquely identifiable name for the application
-l, --limit int The maximum number of results to display
Global Flags:
-c, --config string Path to configuration file. (default "~/.drycc/client.json")
-h, --help Display help information
-v, --version Display client version
Use "drycc resources [command] --help" for more information about a command.
列出所有可用的资源服务
您可以使用 drycc resources services 命令列出可用的资源服务
$ drycc resources services
ID NAME UPDATEABLE
15032a52-33c2-4b40-97aa-ceb972f51509 airflow true
b7cb26a4-b258-445c-860b-a664239a67f8 cloudbeaver true
9ce3c3ba-33b5-4e4e-a5e9-a338a83d5070 flink true
b80c51a1-957c-4d93-b3d5-efde84cd8031 fluentbit true
fff5b6c7-ed85-429b-8265-493e40cc53c7 grafana true
412e368f-bf78-4798-92cc-43343119a57d kafka true
ea2a9b87-fbc4-4e2a-adee-161c1f91d98d minio true
383f7316-84f3-4955-8491-1d4b02b749c8 mongodb true
fbee746b-f3a7-4bef-8b55-cbecfd4c8ac3 mysql-cluster true
5975094d-45cc-4e85-8573-f93937d026c7 opensearch true
1db95161-7193-4544-8c76-e5ad5f6c03f6 pmm true
5cfb0abf-276c-445b-9060-9aa964ede87d postgresql-cluster true
b8f70264-eafc-4b2f-848e-2ec0d059032b prometheus true
e1fd0d37-9046-4152-a29b-d155c5657c8b redis true
7d2b64c6-0b59-4f08-a2f5-7b17cea6e5ee redis-cluster true
2e6877df-86e7-4bcc-a869-2a9b6847a465 seaweedfs true
4aea5c0f-9495-420d-896a-ffc61a3eced5 spark true
b50db3b5-8d5f-4be9-b8bd-467ecd6cc11d zookeeper true
列出资源服务的所有可用计划
您可以使用 drycc resources plans 命令列出资源服务的所有可用计划
$ drycc resources plans redis
ID NAME DESCRIPTION
8d659058-a3b4-4058-b039-cc03a31b9442 standard-128 Redis standard-128 plan which limit resources memory size 128Mi.
36e3dbec-fc51-4f6b-9baa-e31e316858be standard-256 Redis standard-256 plan which limit resources memory size 256Mi.
560817c2-5aa1-41c4-9ee6-a77e3ee552d5 standard-512 Redis standard-512 plan which limit resources memory size 512Mi.
d544d989-9fb8-43e9-a74e-0840ce1b8f0f standard-1024 Redis standard-1024 plan which limit resources memory size 1Gi.
ad51b7bb-9b12-4ffd-8e49-010c0141b263 standard-2048 Redis standard-2048 plan which limit resources memory size 2Gi.
5097d76e-557c-453f-bdb1-54009e0df78d standard-4096 Redis standard-4096 plan which limit resources memory size 4Gi.
be3fa2d0-36d2-47c5-9561-9deffe5ba373 standard-8192 Redis standard-8192 plan which limit resources memory size 8Gi.
4ca812a8-d7c3-439f-96cd-26523e88400e standard-16384 Redis standard-16384 plan which limit resources memory size 16Gi.
b7f2a71f-0d97-48fd-8eed-aab24a7822f3 standard-32768 Redis standard-32768 plan which limit resources memory size 32Gi.
25c6b5d5-7505-47c8-95b1-dc9bdc698063 standard-65536 Redis standard-65536 plan which limit resources memory size 64Gi.
在应用中创建资源
您可以使用 drycc resources create 命令创建资源
$ drycc resources create redis redis standard-128
Creating redis to scenic-icehouse... done
资源创建后，您可以列出此应用中的资源。
$ drycc resources list
UUID NAME OWNER PLAN UPDATED
07220e9e-d54d-4d74-a88c-f464aa374386 redis admin redis:standard-128 2024-05-08T01:01:00Z
绑定资源
名为 redis 的资源已创建，您可以将 redis 绑定到应用，使用 drycc resources bind redis 命令。
$ drycc resources bind redis
Binding resource... done
描述资源
使用 drycc resources describe 显示绑定详情。如果绑定成功，此命令将显示连接到资源的信息。
$ drycc resources describe redis
=== scenic-icehouse resource redis
plan: redis:1000
status: Ready
binding: Ready
REDISPORT: 6379
REDIS_PASSWORD: RzG87SJWG1
SENTINELHOST: 172.16.0.2
SENTINELPORT: 26379
更新资源
您可以使用 drycc resources update 命令升级到新计划。
将计划容量升级到 128MB 的示例：
$ drycc resources update redis redis standard-128
Updating redis to scenic-icehouse... done
删除资源
如果您不再需要资源，请使用 drycc resources unbind 取消绑定资源，然后使用 drycc resources destroy 从应用中删除资源。
删除资源之前，必须先取消绑定资源。
$ drycc resources unbind redis
Unbinding resource... done
$ drycc resources destroy redis
Deleting redis from scenic-icehouse... done
12 - 应用间通信
多进程应用程序的常见架构模式是让一个进程服务公共请求，同时让多个其他进程支持公共进程，例如按计划执行操作或处理队列中的工作项。要在 Drycc Workflow 中实现这种应用程序系统，请设置应用程序使用 DNS 解析进行通信，如上所示，并通过从 Drycc Workflow 路由器中删除它们来隐藏支持进程的公共视图。
DNS 服务发现
Drycc Workflow 支持部署由进程系统组成的单个应用程序。每个 Drycc Workflow 应用程序都在单个端口上通信，因此与其他 Workflow 应用程序通信意味着找到该应用程序的地址和端口。所有 Workflow 应用程序在外部都映射到端口 80，因此找到其 IP 地址是唯一的挑战。Workflow 为每个应用程序创建一个 Kubernetes Service，这有效地为应用程序分配了一个名称和一个集群内部 IP 地址。集群中运行的 DNS 服务添加和删除 DNS 记录，这些记录在添加和删除服务时从应用程序名称指向其 IP 地址。然后，Drycc Workflow 应用程序可以简单地向服务的域名发送请求，该域名是"app-name.app-namespace"。
13 - 资源限制
管理应用资源限制
Drycc Workflow 支持限制每个进程的内存和 CPU 份额。为每个进程类型设置的请求/限制将作为请求和限制提供给 Kubernetes。这意味着您为进程保证 <requests> 数量的资源，同时限制进程使用不超过 <limits> 的资源。
默认情况下，如果我们没有明确设置 <requests> 值，Kubernetes 会将 <requests> 设置为等于 <limit>。请记住 0 <= requests <= limits。
限制
如果您设置的请求/限制超出集群的范围，Kubernetes 将无法将您的应用进程调度到集群中！
$ drycc limits plans
ID SPEC CPU VCPUS MEMORY FEATURES
std1.large.c1m1 std1 Universal CPU 1 1 GiB Integrated GPU shared
std1.large.c1m2 std1 Universal CPU 1 2 GiB Integrated GPU shared
std1.large.c1m4 std1 Universal CPU 1 4 GiB Integrated GPU shared
std1.large.c1m8 std1 Universal CPU 1 8 GiB Integrated GPU shared
std1.large.c2m2 std1 Universal CPU 2 2 GiB Integrated GPU shared
std1.large.c2m4 std1 Universal CPU 2 4 GiB Integrated GPU shared
std1.large.c2m8 std1 Universal CPU 2 8 GiB Integrated GPU shared
std1.large.c2m16 std1 Universal CPU 2 16 GiB Integrated GPU shared
$ drycc limits set web=std1.large.c1m1
Applying limits... done
14 - 域名和路由
您可以使用 drycc domains 向应用程序添加或删除自定义域名：
$ drycc domains add hello.bacongobbler.com --ptype=web
Adding hello.bacongobbler.com to finest-woodshed... done
完成后，您可以进入 DNS 注册商并设置从新应用名称到旧应用名称的 CNAME：
$ dig hello.dryccapp.com
[...]
;; ANSWER SECTION:
hello.bacongobbler.com. 1759 IN CNAME finest-woodshed.dryccapp.com.
finest-woodshed.dryccapp.com. 270 IN A 172.17.8.100
Note
为根域名设置 CNAME 可能会导致问题。将 @ 记录设置为 CNAME 会导致所有流量都转到其他域名，包括邮件和 SOA（“start-of-authority”）记录。强烈建议您将子域名绑定到应用程序，但是您可以通过将 @ 记录指向负载均衡器（如果有）的地址来解决这个问题。要从路由网格中添加或删除应用程序，请使用 drycc routing：
$ drycc routing disable
Disabling routing for finest-woodshed... done
这将使应用程序无法通过 [路由器][] 访问，但应用程序仍然可以通过其 Kubernetes 服务 在内部访问。要重新启用路由：
$ drycc routing enable
Enabling routing for finest-woodshed... done
15 - 应用 SSL 证书
应用 SSL 证书
SSL 是一种加密协议，为所有 Web 请求提供端到端加密和完整性。传输敏感数据的应用应启用 SSL，以确保所有信息安全传输。
要在自定义域名（如 www.example.com）上启用 SSL，请使用 SSL 端点。
Note
drycc certs 仅适用于自定义域名。默认应用域名已启用 SSL，只需使用 https 即可访问，例如 https://foo.dryccapp.com（前提是您已在路由器或负载均衡器上[安装了通配符证书][platform-ssl]）。
概述
由于 SSL 验证的独特性质，为您的域名配置 SSL 是一个涉及多个第三方的多步骤过程。您需要：
- 从 SSL 提供商处购买 SSL 证书
- 将证书上传到 Drycc
获取 SSL 证书
购买 SSL 证书的成本和过程因供应商而异。RapidSSL 提供了一种简单的方式来购买证书，是推荐的解决方案。如果您可以使用此提供商，请参阅[使用 RapidSSL 购买 SSL 证书][]以获取说明。
DNS 和域名配置
SSL 证书配置完成后，您的证书确认后，您必须通过 Drycc 路由对域名的请求。除非您已经这样做，否则使用以下命令将生成 CSR 时指定的域名添加到您的应用中：
$ drycc domains add www.example.com --ptype==web -a foo
Adding www.example.com to foo... done
添加证书
使用 certs:add 命令将您的证书、任何中间证书和私钥添加到端点。
$ drycc certs add example-com server.crt server.key -a foo
Adding SSL endpoint... done
www.example.com
Note
证书名称只能包含 a-z（小写）、0-9 和连字符Drycc 平台将检查证书并从中提取相关信息，如通用名称、主题备用名称 (SAN)、指纹等。
这允许通配符证书和 SAN 中的多个域名，而无需上传重复项。
添加证书链
有时，您的证书（如自签名或廉价证书）需要额外的证书来建立信任链。您需要将所有证书捆绑到一个文件中并提供给 Drycc。重要的是，您的站点证书必须是第一个：
$ cat server.crt server.ca > server.bundle
之后，您可以使用 certs add 命令将其添加到 Drycc：
$ drycc certs add example-com server.bundle server.key -a foo
Adding SSL endpoint... done
www.example.com
将 SSL 证书附加到域名
证书不会自动连接到域名，而是您必须将证书附加到域名
$ drycc certs attach example-com example.com -a foo
每个证书可以连接到多个域名。不需要上传重复项。
要删除关联
$ drycc certs detach example-com example.com -a foo
端点概述
您可以使用 drycc certs 验证域名的 SSL 配置详情。
$ drycc certs
NAME COMMON-NAME EXPIRES SAN DOMAINS
example-com example.com 14 Jan 2017 blog.example.com example.com
或通过查看每个证书的详细信息
$ drycc certs info example-com -a foo
=== bar-com Certificate
Common Name(s): example.com
Expires At: 2017-01-14 23:57:57 +0000 UTC
Starts At: 2016-01-15 23:57:57 +0000 UTC
Fingerprint: 7A:CA:B8:50:FF:8D:EB:03:3D:AC:AD:13:4F:EE:03:D5:5D:EB:5E:37:51:8C:E0:98:F8:1B:36:2B:20:83:0D:C0
Subject Alt Name: blog.example.com
Issuer: /C=US/ST=CA/L=San Francisco/O=Drycc/OU=Engineering/CN=example.com/emailAddress=engineering@drycc.cc
Subject: /C=US/ST=CA/L=San Francisco/O=Drycc/OU=Engineering/CN=example.com/emailAddress=engineering@drycc.cc
Connected Domains: example.com
Owner: admin-user
Created: 2016-01-28 19:07:41 +0000 UTC
Updated: 2016-01-30 00:10:02 +0000 UTC
测试 SSL
使用命令行工具如 curl 来测试您的安全域名的配置是否正确。
Note
-k 选项标志告诉 curl 忽略不受信任的证书。注意输出。它应该打印 SSL certificate verify ok。如果它打印类似 common name: www.example.com (does not match 'www.somedomain.com') 的内容，则说明配置不正确。
在路由器上强制 SSL
要强制所有 HTTP 请求重定向到 HTTPS，可以通过运行以下命令在路由器级别强制 TLS
$ drycc tls force enable -a foo
Enabling https-only requests for foo... done
访问应用 HTTP 端点的用户现在将收到 301 重定向到 HTTPS 端点。
要禁用强制 TLS，请运行
$ drycc tls force disable -a foo
Disabling https-only requests for foo... done
自动证书管理
通过自动证书管理 (ACM)，Drycc 自动管理通用运行时上具有 Hobby 和 Professional dyno 的应用的 TLS 证书，以及启用该功能的私有空间中的应用。由 ACM 处理的证书会在到期前一个月自动续订，每当您添加或删除自定义域名时，会自动创建新证书。所有具有付费 dyno 的应用都免费包含 ACM。自动证书管理使用 Let’s Encrypt，这是免费、自动化和开放的证书颁发机构，用于管理您的应用的 TLS 证书。Let’s Encrypt 由互联网安全研究小组 (ISRG) 为公共利益运营。
使用以下命令启用 ACM： $ drycc tls auto enable -a foo
使用以下命令禁用 ACM： $ drycc tls auto disable -a foo
删除证书
您可以使用 certs:remove 命令删除证书：
$ drycc certs remove my-cert -a foo
Removing www.example.com... Done.
更换证书
在应用的生命周期中，操作员将不得不获取具有新到期日期的证书并将其应用到所有相关应用，下面是更换证书的推荐方法。
有意选择证书名称，尽可能将其命名为 example-com-2017，其中年份表示到期年份。这允许在购买新证书时使用 example-com-2018。
假设所有应用已经在使用 example-com-2017，可以运行以下命令，链接在一起或其他方式：
$ drycc certs detach example-com-2017 example.com -a foo
$ drycc certs attach example-com-2018 example.com -a foo
这将处理单个域名，允许操作员验证一切按计划进行，并慢慢将其推广到使用相同方法的任何其他应用。
故障排除
如果您的 SSL 端点未按预期工作，以下是一些可以遵循的步骤。
不受信任的证书
在某些情况下访问 SSL 端点时，它可能会将您的证书列为不受信任。
如果发生这种情况，可能是因为它不受 Mozilla 的[root CA][]列表信任。如果是这种情况，您的证书可能被许多浏览器视为不受信任。
如果您上传了由根机构签名的证书，但收到消息说它不受信任，则证书有问题。例如，它可能缺少[中间证书][]。如果是这样，从您的 SSL 提供商下载中间证书，从 Drycc 中删除证书，然后重新运行 certs add 命令。
16 - 使用 drycc 路径
Drycc 堆栈仅适用于高级用例。除非您有自定义 Docker 镜像的具体需求，否则我们建议使用 Drycc 的默认 buildpack 驱动的构建系统。它提供自动基础镜像安全更新和特定于语言的优化。它还避免了维护容器 Dockerfile 的需要。
Drycc 配置路径概述
Drycc 仓库有两种不同的形式：
-
工作树根目录下的
.drycc目录； -
根目录是一个"裸"仓库（即没有自己的工作树）。 通常用于
drycc pull。
Drycc 仓库中可能存在这些东西。
config/[a-z0-9]+(\.[a-z0-9]+)*::
配置文件名，文件名是组名。
格式是环境变量格式。
[a-z0-9]+(\-[a-z0-9]+)*.(yaml|yml)::
流水线配置文件。
配置格式
Environment variables follow
配置格式
环境变量遵循
DEBUG=true
JVM_OPTIONS=-XX:+UseG1GC
流水线格式
清单有三个顶级部分。
- build – 指定要构建的 Dockerfile。
- env – 指定容器中的环境变量。
- run – 指定要执行的发布阶段任务。
- config – 指定配置组，全局组自动引用。
- deploy – 指定部署的命令和参数。
这是一个说明使用清单构建 Docker 镜像的示例。
kind: pipeline
ptype: web
build:
docker: Dockerfile
arg:
CODENAME: bookworm
env:
VERSION: 1.2.1
run:
command:
- ./deployment-tasks.sh
image: task
timeout: 100
config:
- jvm-config
deploy:
command:
- bash
- -ec
args:
- bundle exec puma -C config/puma.rb
有关更多部署信息，请参考 drycc 示例。
Pipeline format
A manifest has three top-level sections.
- build – Specifies the to build Dockerfile.
- env – Specifies environment variables in container.
- run – Specifies the release phase tasks to execute.
- config – Specifies config group, global group automatic reference.
- deploy – Specifies the commands and args to deploy.
Here’s an example that illustrates using a manifest to build Docker images.
kind: pipeline
ptype: web
build:
docker: Dockerfile
arg:
CODENAME: bookworm
env:
VERSION: 1.2.1
run:
command:
- ./deployment-tasks.sh
image: task
timeout: 100
config:
- jvm-config
deploy:
command:
- bash
- -ec
args:
- bundle exec puma -C config/puma.rb
For more deployment information, please refer to the drycc examples.