企业官网建设流程全解析

• 云原生
• 微服务
• 容器编排
• 运维

导读

Flynn 是一个开源的平台即服务（PaaS），应用可以通过 Buildpacks（git push部署）或 Docker 镜像两种方式部署到集群中。本文以官方文档 docs/content/apps.md 为主体，系统讲解 Flynn 中应用（App）的完整生命周期管理：如何使用flynn env进行十二要素风格的应用配置、如何通过 Buildpack 构建与部署、零停机发布与回滚机制、进程管理与日志采集，以及 HTTP 路由、自定义域名、HTTPS、服务发现和资源限制（CPU/内存）等生产级能力。读完本文，你将掌握在 Flynn 集群上从创建应用到上线、扩容、排障、加固的全套 CLI 操作与底层原理，并能在 cli/ 与 host/resource/ 等源码中验证每个行为的具体实现。

Configuration：用环境变量配置应用

Flynn 遵循The Twelve-Factor App的实践，使用环境变量来配置应用。环境变量的读写统一通过flynn env命令完成：

flynn env set SECRET=thisismysecret

关键行为：设置环境变量会创建一次新的 release（发布），并触发应用全部进程以新配置重启。这在 cli/env.go 中有明确实现——runEnvSet解析var=val对后调用setEnv，最终依次执行client.CreateRelease与client.DeployAppRelease，CLI 会打印Created release <id>表示新 release 已生成并部署。

flynn env的完整子命令与选项如下：

从源码看，env命令区分“应用级环境变量”（存放在release.Env）与“进程类型级环境变量”（存放在release.Processes[proc].Env）两层；不带-t时读写应用级变量，带-t时读写并合并对应进程类型的变量（参见 cli/env.go）。env set/env unset最终都走setEnv：先取当前 app release，将变更合并到目标环境变量 map 中，然后创建新 release 并部署，从而触发全量重启。

External Databases：接入 Flynn 外部数据库

Flynn 应用既可以连接内置数据库（PostgreSQL、MySQL、MongoDB、Redis），也可以连接 Flynn 集群之外托管的数据库。外部数据库只需将其连接配置通过flynn env以环境变量形式传入应用即可，例如：

flynn env set DATABASE_URL=postgres://user:pass@db.example.com:5432/myapp

内置数据库则可通过flynn resource add postgres（或mongodb、mysql、redis）一键开通，Flynn 会自动向应用 release 注入DATABASE_URL、PGHOST、PGUSER等连接变量（参见 docs/content/databases/ 与 docs/content/basics.md 中的完整示例）。

Buildpacks：构建与自定义构建包

Flynn 使用 Buildpacks 来准备和构建通过git push部署的应用，并且会对大多数受支持语言自动选择标准 buildpack。

当自动检测不可行，或标准 buildpack 不适用时，可以手动指定构建包。Flynn 内置了多构建包机制（multi buildpack），既支持单个自定义 buildpack，也支持在一次部署中使用多个 buildpack。

方式一：提交.buildpacks文件。在应用仓库根目录创建并提交一个.buildpacks文件，每行一个 buildpack 的 URL：

https://github.com/kr/heroku-buildpack-inline

方式二：设置BUILDPACK_URL环境变量。如果不想向仓库添加文件，可以直接用flynn env指定：

flynn env set BUILDPACK_URL=https://github.com/ryandotsmith/null-buildpack

从构建链路看，BUILDPACK_URL会被 gitreceive 服务注入 slugbuilder 构建任务的运行环境。在 gitreceive/receiver/flynn-receive.go 中，构建任务的环境变量构建逻辑优先取当前 push 携带的环境变量，其次取上一 release 的环境变量中的BUILDPACK_URL，写入jobEnv["BUILDPACK_URL"]后由 slugbuilder 的/builder/build.sh执行构建。因此两种指定方式是等价的，且配置在环境变量中时对后续每次git push均生效。

Deployment：发布、取消发布与多分支部署

每次推送新代码或修改应用配置，Flynn 都会创建新的 release。部署采用零停机策略：先启动新 release，只有当新 release 正常起来后才会停止旧 release；如果新 release 未能正常启动或出现其他异常，部署会自动回滚，旧 release 继续运行。

这一策略意味着线上流量永远由健康版本承接，发布失败不会造成服务中断，是 Flynn 默认且无需额外配置的发布行为。

Cancelling Deploys：取消进行中的部署

通过git push发起的部署，可以通过Ctrl-C终止 push 进程，或向该进程发送终止信号来取消。构建会被立即取消，代码不会被部署。

Building specific Git branches：部署指定 Git 分支

同一个代码仓库的不同分支，可以通过创建多个应用、各自配置不同 git remote 来分别部署。典型场景是构建 staging（预发布）环境：

flynn create myapp-staging --remote staging flynn -a staging env set FOO=bar git push staging staging:master

这里的关键在于：

• flynn create myapp-staging --remote staging创建名为myapp-staging的应用，并把 git remote 命名为staging而非默认的flynn。在 cli/app.go 中可以看到flynn create会为当前 git 仓库添加对应 remote，remote 名由-r/--remote指定（默认flynn，传空字符串则不配置 remote）；
• flynn -a staging env set FOO=bar通过-a指定对staging应用设置环境变量；
• git push staging staging:master把本地的staging分支推送到 Flynn 端的master分支，触发构建与发布。

创建、查看与删除应用

除了部署，flynn create、flynn apps、flynn info、flynn delete构成了应用的基础管理闭环（实现见 cli/app.go）：

# 不指定名字时随机生成，如 "turkeys-stupefy-perry" flynn create # 列出集群内所有应用 flynn apps ID NAME f1e85f5392454a329929e3f27f7a5644 gitreceive 4c6325c1f13547059e5496c91a6a97dd router # 查看应用的 Git URL 与 Web URL（自动判断 http/https） flynn info === example Git URL: https://git.dev.localflynn.com/example.git Web URL: http://example.dev.localflynn.com # 删除应用（会一并清理路由、release 与已开通的资源） flynn delete -y

flynn info会同时展示 Git 部署地址和自动注册的 Web 路由地址，并根据路由是否配置了证书自动决定展示http://还是https://（见 cli/app.go）。

Processes：进程列表与进程级操作

使用flynn ps可以获取应用下各个进程的列表，返回的进程 ID 可传给flynn kill来终止进程。Flynn 会自动重启被终止的进程，但一次性运行任务（one-off run job）除外。

# 获取进程列表 $ flynn ps ID TYPE STATE CREATED RELEASE COMMAND host0-52aedfbf-e613-40f2-941a-d832d10fc400 web up 6 seconds ago cf39a906-38d1-4393-a6b1-8ad2befe8142 /runner/init start web # 终止进程 $ flynn kill host-28a16c12-6136-4e06-93b1-2b014147de79 Job host-28a16c12-6136-4e06-93b1-2b014147de79 killed.

flynn ps还支持丰富的筛选与展示选项（参见 cli/ps.go）：

# 显示所有状态（默认只显示 running 和 pending），并附带完整命令 flynn ps --all --command # 只输出进程 ID（便于脚本化处理） flynn ps --all --quiet # 按进程类型过滤，如只看一次性 run 任务 flynn ps --all --type=run

其中run类型即通过flynn run启动的一次性任务，例如在应用容器中执行flynn run curl http://nodejs-web.discoverd:8080（详见 cli/run.go，-d可后台分离运行，--limits可指定资源限制）。

扩容与缩容

进程数量的调整使用flynn scale，默认情况下首次部署含web进程类型的应用会自动扩容到web=1：

flynn scale web=3 scaling web: 1=>3 09:33:51.730 ==> web 4ef91e4b-d0c3-4e3f-931b-6db3b551dcd9 pending 09:33:51.733 ==> web ccd3aff7-80b3-46b4-a95f-006bfceb80c6 pending 09:33:51.743 ==> web flynn-ccd3aff7-80b3-46b4-a95f-006bfceb80c6 starting 09:33:51.751 ==> web flynn-4ef91e4b-d0c3-4e3f-931b-6db3b551dcd9 starting 09:33:52.129 ==> web flynn-4ef91e4b-d0c3-4e3f-931b-6db3b551dcd9 up 09:33:52.171 ==> web flynn-ccd3aff7-80b3-46b4-a95f-006bfceb80c6 up scale completed in 464.957638ms

flynn scale还支持按主机标签调度进程，例如web=3,active=true表示把 3 个 web 进程分布到打了active=true标签的主机上；db=3,disk=ssd,mem=high要求主机同时具备disk=ssd与mem=high两个标签（参见 cli/scale.go 中的用法说明）。不带参数运行flynn scale则显示当前各进程类型的实例数。

Logs：日志查看、实时跟踪与外部日志

Flynn 会自动记录应用进程写入标准输出（stdout）和标准错误（stderr）的所有内容。日志可通过flynn log获取，使用-f可以实时跟踪新产生的日志：

flynn log # 查看最近日志 flynn log -f # 实时跟踪日志流

flynn log的完整选项（参见 cli/log.go）：

默认输出格式带有时间戳、来源、进程类型与 job ID 前缀，形如2026-09-26T01:39:43.000000Z web[web.host0-xxx]: <消息内容>；使用-r则可得到不带前缀的原始内容。日志由 logaggregator 组件汇聚与缓存，CLI 通过 logaggregator 客户端按流类型（stdout/stderr/init）拉取（见 logaggregator/）。

External Logs：输出到外部 syslog

应用也可以通过系统或客户端库把日志流式发送到远程 syslog 服务。大多数编程语言都有远程日志的内置支持，例如 Python 的SysLogHandler。这类日志流与 Flynn 自身的flynn log相互独立，适用于日志归档与集中监控场景。

Routes：HTTP 路由、自定义域名与 HTTPS

Flynn 会自动为每个应用配置一条https://$APPNAME.$CLUSTERDOMAIN路由，指向web进程类型的实例。应用必须监听并接受PORT环境变量所指定端口上的 HTTP 请求，才能收到流量（PORT由 Flynn 在启动进程时注入）。

默认路由与flynn route查看

创建应用后可以确认自动生成的路由：

$ flynn route ROUTE SERVICE ID STICKY LEADER PATH http:example.demo.localflynn.com example-web http/2e37467e-08fc-47e5-853b-4f0574cb6871 false false /

Custom Domains：添加自定义域名

为应用添加额外的 HTTP 路由：

flynn route add http www.example.com

同时需要为域名配置 DNS，例如将www.example.com设置为$APPNAME.$CLUSTERDOMAIN的 CNAME 记录。

Additional Process Types：多进程类型对外提供服务

Flynn 支持多个进程类型同时对外提供 Web 流量。这些额外进程类型必须在Procfile中定义，且进程类型名必须以-web结尾。例如如下 Procfile：

web: ./server admin-web: ./admin-server

为额外进程类型配置路由时，通过--service标志指定目标服务（服务名默认为APPNAME-PROCTYPE，即myapp-admin-web）：

flynn route add http --service myapp-admin-web admin.example.com

flynn route命令还支持 TCP 路由与丰富的路由属性（参见 cli/route.go 的 usage）：

flynn route add tcp [-s <service>] [-p <port>] [--leader] [--no-drain-backends] flynn route update <id> [-s <service>] [-c <tls-cert> -k <tls-key>] [--sticky] [--no-sticky] [--leader] [--no-leader] [--disable-keep-alives] [--enable-keep-alives] flynn route remove <id>

常用路由选项说明：

从实现看，HTTP 路由通过url.Parse("http://"+domain)解析域名与路径（example.com/path/形式的路径同样受支持），并将 service 默认填为APPNAME-web（见 cli/route.go）；TCP 路由不解析域名，只绑定端口并转发到指定 service。

HTTPS：自动终结 TLS 并启用 HTTP/2

路由器可以自动终结 HTTPS 流量。创建或更新路由时，通过--tls-cert与--tls-key标志指定证书链与私钥；为路由启用 HTTPS 后，HTTP/2 也会自动开启。

flynn route update http/2b3b2004-38f1-4e68-b856-7d8af3e4c6e1 --tls-cert cert.pem --tls-key cert.key

证书文件应包含 PEM 编码的目标证书块，以及为链接到受信任根所需的中间证书。此外，--tls-cert与--tls-key必须同时指定（源码parseTLSCert会校验这一点），支持从 stdin 传入 PEM 内容（参见 cli/route.go）。

Service Discovery：集群内服务发现

Flynn 会自动把每个web进程类型注册到服务发现中，供不走路由器的集群内部请求使用。服务发现条目可通过 DNS 访问，DNS 名称模式为$APPNAME-$PROCTYPE.discoverd，例如myapp-web.discoverd与myapp-admin-web.discoverd。该特性可用于应用与应用、进程与进程之间的内部通信，例如从应用内直接访问数据库主节点leader.postgres.discoverd:5432，或使用flynn run curl http://nodejs-web.discoverd:8080访问同集群内的另一个应用服务。

Limits：内存、CPU 与其他资源限制

资源限制（内存及其他）可以通过flynn limit命令查看与设置：

flynn limit set web memory=2GB

flynn limit支持的类型在 host/resource/resource.go 中定义，包括：

查看当前限制的示例输出：

$ flynn limit web: cpu=1000 temp_disk=100MB max_fd=10000 memory=1GB worker: cpu=1000 temp_disk=100MB max_fd=10000 memory=1GB

一次设置多个限制：

flynn limit set web memory=512MB max_fd=12000 cpu=500 temp_disk=200MB

从源码看，flynn limit set会解析var=val对并合并到对应进程类型的资源规格中，随后同样走“创建 release + 部署”链路（cli/limit.go），因此调整限制同样会触发应用进程重启。资源规格由Request（调度时要求宿主具备的预留量）与Limit（可消耗上限）两部分组成（见 host/resource/resource.go）。

CPU Shares：CPU 份额的相对优先级

CPU 份额是相对的：份额越多，进程优先级越高。当宿主机负载高时，拥有 2000 milliCPU 的任务获得的 CPU 时间是默认值 1000 的任务的两倍。

flynn limit set web cpu=1500

Slugbuilder Limits：调整构建进程内存

部分构建过程需要大量内存。如果在git push部署时遇到构建缓慢或随机失败，可以尝试提高slugbuilder进程的内存限制：

flynn limit set slugbuilder memory=4GB

也可以在集群范围内设置全局默认的slugbuilder内存限制，即为负责处理git push部署的应用（gitreceive与taffy）设置SLUGBUILDER_DEFAULT_MEMORY_LIMIT环境变量：

limit=SLUGBUILDER_DEFAULT_MEMORY_LIMIT=2GB flynn -a gitreceive env set $limit flynn -a taffy env set $limit

该默认值的生效逻辑位于 gitreceive/receiver/flynn-receive.go：构建 slugbuilder 任务时，先检查上一 release 中是否定义了slugbuilder进程类型——有则直接采用其资源限制；否则读取SLUGBUILDER_DEFAULT_MEMORY_LIMIT，若解析成功则把该值同时作为 memory 的Limit与Request应用。也就是说，逐应用设置（flynn limit set slugbuilder ...）优先于全局默认值，而全局默认值通过环境变量对后续所有git push构建生效。

部署方式补充：Docker 镜像部署

除 Buildpack 外，Flynn 还内置了tarreceive应用，用于把 Docker 镜像导入集群并部署。一次完整的 Docker 部署流程如下（详见 docs/content/docker.md）：

# 1. 构建镜像 docker build -t nodejs-flynn-example . # 2. 创建应用（--remote "" 表示不配置 git remote，因为本次走 docker push） flynn create --remote "" nodejs # 3. 推送并部署镜像 flynn -a nodejs docker push nodejs-flynn-example # 4. 首次部署后扩容 app 进程 flynn -a nodejs scale app=1

以 Docker 镜像部署的 release 会生成一个app进程类型，其ENTRYPOINT、CMD与ENV均取自镜像配置，并自动注册APPNAME-web服务名，供集群内部通过nodejs-web.discoverd:8080访问；外部则通过自动注册的http://nodejs.1.localflynn.com路由访问。这与 Buildpack 部署在路由、服务发现、资源限制与日志方面共用同一套应用管理模型。

小结

Flynn 应用管理的核心模型可以概括为：配置即环境变量、发布即 release、流量即路由、容量即进程数与资源限制。flynn env的任何变更都会产生新 release 并触发零停机滚动发布；flynn scale、flynn limit同样通过 release 机制生效；flynn route负责把域名/端口映射到以-web结尾的进程类型服务，并支持 TLS 终结、HTTP/2、粘性会话与领导者模式；flynn ps/flynn kill/flynn log覆盖了运行态进程与日志的日常运维。结合本文给出的源码路径（cli/、host/resource/resource.go、gitreceive/receiver/flynn-receive.go），你可以进一步深入验证每个命令背后的实现细节，并将其迁移到自己的 PaaS 运维实践中。

• 云原生
• 微服务
• 容器编排
• 运维