升级到Varnish 6.0¶
作为侦听地址的Unix域套接字¶
这个 varnishd -a
命令行参数现在具有以下形式,其中 address
可以是Unix域套接字,当它以 /
(见varnishd OPTIONS ):
-a [name=][address][:port][,PROTO][,user=<user>][,group=<group>][,mode=<mode>]
例如::
varnishd -a /path/to/listen.sock,PROXY,user=vcache,group=varnish,mode=660
这意味着必须始终为套接字文件指定绝对路径。套接字文件是在Varnish启动时创建的,并且可能存在于该路径的任何文件首先被取消链接。您可以使用可选的 user
, group
和 mode
子参数设置新套接字文件的权限;将名称用于 user
和 group
(非数字ID)和3位八进制数 mode
。这是由管理进程完成的,因此创建套接字文件和设置权限是使用管理进程所有者的权限完成的。
Udsen的使用有一些特定于平台的限制,您必须遵守这些限制。以下是我们知道的一些事情,但这个列表绝不是权威性的或详尽的;请始终参考您的平台文档(通常在 man unix
):
套接字文件的路径有允许的最大长度,比文件系统的最大长度短得多;通常略高于100个字节。
在FreeBSD和其他从BSD派生的系统上,套接字文件的权限不限制哪些进程可以连接到套接字。
在Linux上,连接到套接字的进程必须对套接字文件具有写入权限。
在任何系统上,连接到套接字的进程必须能够访问套接字文件。因此,您可以通过限制对包含套接字的目录的权限来可靠地限制访问(但这必须在Varnish配置之外完成)。
当使用UDS监听器时,Varnish加载的所有VCL程序都需要VCL>=4.1。如果您尝试使用加载VCL源 vcl 4.0;
,则加载将失败,并显示不支持该版本的消息。
如果您继续在您的 -a
参数,您将不必更改它们,并且您可以继续使用VCL 4.0。
作为后端地址的Unix域套接字¶
后端声明现在可能具有 .path
用于指定Varnish连接的Unix域套接字的字段::
backend my_uds_backend {
.path = "/path/to/backend.sock";
}
其中一块田地 .host
或 .path
必须为后端(但不能同时为两者)指定。
的价值 .path
必须是绝对路径(以 /
),并且该路径下的文件必须存在,并且在VCL加载时Varnish可以访问该文件;并且它必须是套接字。
上面提到的对Udsen的特定于平台的限制当然也适用于后端;但在这种情况下,侦听套接字文件的对等组件的部署必须满足这些条件,否则Varnish可能无法连接到后端。
套接字文件的路径也可以在 varnishd -b
命令行选项(请参见varnishd OPTIONS ):
$ varnishd -b /path/to/backend.sock
的价值 -b
必须满足与 .path
后端声明中的字段。
后端带有 .path
规范需要VCL 4.1,路径也需要 -b
争论。如果你不使用UDS后台,你可以继续使用VCL 4.0。
Varnishd参数¶
这个 cli_buffer
自Varnish 5.2起不建议使用的参数现在已停用。
max_restarts 现在运行得更正确了--它是 return(restart)
每个请求允许的呼叫。(这比允许的重启次数少了一次。)
这些参数 tcp_keepalive_intvl , tcp_keepalive_probes 和 tcp_keepalive_time 对于作为Unix域套接字的侦听地址,将以静默方式忽略。这些参数 accept_filter 和 tcp_fastopen (您的平台可能支持也可能不支持)几乎肯定不会对UDS产生影响。将这些参数中的任何一个与UDS一起使用都不是错误;您可能会在日志中收到以下错误消息 accept_filter
或 tcp_fastopen
(带有VSL标签 Error
原始分组中),但它们是无害的。
workspace_thread 现在用于客户端响应传递期间的IO缓冲区。这个空间以前是从 workspace_client 。如果您需要减少内存占用,请考虑减少 workspace_client
按中的金额 workspace_thread
。
增列 ref_param_esi_iovs 。戴利:不要碰它,除非熟悉瓦尼什内部的人建议你这样做。
对VCL的更改¶
VCL 4.0和4.1¶
VCL程序中的第一行代码现在可能是 vcl 4.0;
或 vcl 4.1;
,建立该VCL实例的语言版本。Varnish 6.0支持这两个版本。
VCL版本主要影响VCL程序中可以使用的变量,或者在某些情况下,变量是可写的还是只读的。当使用Unix域套接字时,只允许使用VCL 4.1。
有关详情,请参阅 本地、服务器、远程和客户端 ,以及本文件中的说明。
VCL变量¶
local.socket
and local.endpoint
¶
这些只读变量从VCL 4.1开始可用,并提供有关当前客户端请求接收所用的侦听器地址的信息。
local.socket
中提供的名称 -a
当前侦听器的命令行参数,默认为 a0
, a1
依此类推(参见varnishd OPTIONS )。
local.endpoint
的值是 address[:port]
或 path
提供的字段作为 -a
当前侦听器的值,与命令行上给出的完全相同。例如::
# When varnishd is invoked with these -a arguments ...
$ varnishd -a foo=12.34.56.78:4711 -a bar=/path/to/listen.sock
# ... then in VCL, for requests received over the first listener:
local.socket == "foo"
local.endpoint == "12.34.56.78:4711"
# ... and for requests received over the second listener:
local.socket == "bar"
local.endpoint == "/path/to/listen.sock"
# With this invocation ...
$ varnishd -a :80 -a 87.65.43.21
# ... then for requests received over the first listener:
local.socket == "a0"
local.endpoint == ":80"
# ... and for the second listener
local.socket == "a1"
local.endpoint == "87.65.43.21"
因此,如果您有多个监听程序,并且需要在VCL中区分它们,例如,一个监听程序用于“常规”客户端流量,另一个监听程序用于“admin”请求,您必须将其限制为内部系统,这两个变量可以帮助您做到这一点。
local.socket
和 local.endpoint
在客户端和后端均可用。但是后端的值不一定与发起后端请求的客户端请求的值相同。这是因为客户端和后端线程的分离--由客户端请求发起的后端线程可能会被重用,而不是另一个侦听器,并且 local.socket
和 local.endpoint
在该线程上保留原始侦听器的值。
因此,如果在您的后端VCL代码中,您需要确保在同一事务的客户端上使用的侦听器,则将 local.socket
和/或 local.endpoint
到客户端请求标头,并从后端请求标头中检索值::
sub vcl_miss {
set req.http.X-Listener = local.socket;
}
sub vcl_backend_fetch {
if (bereq.http.X-Listener == "a0") {
# ...
}
}
sess.xid
¶
这是Varnish分配给当前会话的唯一ID,它代表具有包含一个或多个请求/响应事务的单个客户端连接的“对话”。它与会话事务的日志中显示的XID相同(带有 -g session
分组)。 sess.xid
是只读的,从VCL 4.1起可用。
VCL 4.0和4.1中的变量更改¶
这个 *.proto
变数 (req.proto
, resp.proto
, bereq.proto
和 beresp.proto
)是只读的,但在VCL 4.0中仍然是可写的。
req.esi
在VCL 4.0中可用,但在4.1中不再可用。取而代之的是, resp.do_esi
已在VCL 4.1中引入。集 resp.do_esi
在…中作假 vcl_deliver
如果要有选择地禁用客户端响应的ESI处理(即使 beresp.do_esi
在获取过程中为真)。
beresp.backend.ip
和 beresp.storage_hint
从VCL 4.1起已停止使用,但在4.0中仍可用。请注意 beresp.storage_hint
自Varnish 5.1起已弃用;您应该使用 beresp.storage
取而代之的是。
客户端变量访问¶
req.storage
, req.hash_ignore_busy
和 req.hash_always_miss
现在可以从所有客户端子例程访问(以前仅在 vcl_recv{}
)。
Unix域套接字和VCL¶
我们已经努力在VCL中调整对Unix域套接字的支持,这样除了将版本更改为4.1之外,您可能根本不需要在VCL部署中进行任何更改。
简单地说,当VCL需要IP值时,该值为 0.0.0.0:0
对于作为UDS寻址的连接--端口为0的“任何IPv4”地址。因此,您在VCL中对IP值元素的使用将继续有效,可能不需要更改,但您应该考虑一些后果,如下所述。
正如我们将看到的,由于各种原因,如果通过UDS转发到Varnish的组件使用代理协议,则会获得最佳结果,该协议设置了 client.ip
和 server.ip
设置为代理标头中发送的地址。
如果您不使用Udsen,那么VCL在网络寻址方面不会发生任何变化。UDS支持需要4.1版,因此如果您将VCL级别保持在4.0(因此使用IP地址),则不需要考虑以下任何问题。
client.ip
, server.ip
, local.ip
and remote.ip
¶
这些变量的值为 0.0.0.0
用于寻址为UDS的连接。如果您正在使用代理协议,则 client.ip
和 server.ip
通过代理发送“真实”的IP地址值,但是 local.ip
和 remote.ip
永远都是 0.0.0.0
对于UDS监听程序。
如果您有多个UDS监听器(多个 -a
指定套接字路径的命令行参数),则可能无法使用 *.ip
变量来区分它们,特别是在 local.ip
将会是 0.0.0.0
对他们所有人来说。如果您需要在VCL中区分这些地址,您可以使用 local.socket
,这是为 -a
论辩 (a0
, a1
默认情况下等),或 local.endpoint
,在UDS的情况下是在 -a
争论。例如,您可以在上使用正则表达式匹配等字符串操作 local.endpoint
要确定路径地址的属性:
# admin requests allowed only on the listener whose path ends in
# "admin.sock"
if (req.url ~ "^/admin") {
if (local.endpoint !~ "admin.sock$") {
# wrong listener, respond with "403 Forbidden"
return( synth(403) );
}
else {
# process the admin request ...
}
}
# superadmin requests only allowed on the "superadmin.sock" listener
if (req.url ~ "^/superadmin") {
if (local.endpoint !~ "superadmin.sock$") {
return( synth(403) );
}
else {
# superadmin request ...
}
}
ACLs¶
与以前一样,ACL只能指定IP地址范围,并且只能针对IP值元素运行与ACL的匹配。
这意味着如果一个 *.ip
值为 0.0.0.0
由于UDS的使用是与ACL匹配的,因此仅当ACL包括 0.0.0.0
。如果您当前有依赖于IP地址的安全要求 not 匹配ACL,除非它们属于指定范围,否则将继续与UDS侦听器一起工作(因为您几乎肯定没有包括 0.0.0.0
在该范围内)。
再回想一下, client.ip
和 server.ip
由代理协议设置。因此,如果您将UDS侦听器配置为使用代理,并且使用ACL来匹配这两个变量中的一个,则匹配将继续针对通过代理发送的“真实”IP。
当然,您可以定义一个与UDS情况相匹配的ACL,方法是包括 0.0.0.0
**
# matches local.ip and remote.ip when the listener is UDS
acl uds {
"0.0.0.0";
}
但是,如果您有多个UDS侦听器,则这样的ACL无法区分不同的UDS侦听器。为此,您可以通过检查 local.socket
和/或 local.endpoint
,如上所述。
client.identity
和散列和碎片控制器¶
和以前一样, client.identity
默认为 client.ip
;也就是说,如果它的值没有在VCL中显式设置,则它返回与 client.ip
当它被阅读的时候。
的常见用法 client.identity
是配置散列和碎片控制器(请参见 VMOD导向器-Varnish导向器模块 )。这是实现请求到后端的“客户端粘性”分布的一种方法--来自相同客户端的请求总是被发送到相同的后端。
在以下情况下,这样的配置几乎肯定不会执行您想要的操作:
监听程序设置为UDS地址。
代理未用于设置
client.ip
。client.identity
在用于配置指挥交换机之前,未设置为不同的值。
自.以来 client.identity
默认为 client.ip
,这一直是 0.0.0.0
在这些情况下,结果是指挥交换机只将所有请求发送到一个后端,而不向任何其他后端发送请求。
要避免出现这种结果,请更改上面列出的条件之一--使用代理为 client.ip
,或设置 client.identity
在使用它之前设置为不同的值。
server.ip
和缓存的默认散列¶
用于计算缓存的哈希值的默认算法(实现 vcl_hash
在……里面 builtin.vcl
)混合 req.url
和主机标头 (req.http.Host
)转换为散列数据。如果没有主机标头,则 server.ip
而不是使用。考虑主机标头或 server.ip
是实现一种“虚拟主机”的一种方式--如果您的站点接收具有不同主机头或不同服务器地址的请求,则对相同URL的请求不会命中相同的缓存响应,如果这些请求在其他方面不同的话。
如果您有UDS侦听器,并且没有使用代理来设置 server.ip
,则没有主机标头的请求将具有相同的值 server.ip == 0.0.0.0
混合在哈希里。在这种情况下,具有相同URL的请求将产生相同的散列值,并命中相同的缓存响应。
当然,如果您不需要“虚拟主机”效果,这并不重要--您只有一个监听程序,您永远不会收到不同的主机头,或者您永远不会收到应该导致不同响应的相同URL。
但是,如果您需要避免这种结果,则可以进行以下一项或多项更改:
使用代理协议设置DISTINCT
server.ip
价值观。编写您自己的实现
vcl_hash
,例如,混合local.socket
或local.endpoint
放入散列中。集
req.http.Host
设置为一个不同的值(如果以前没有vcl_hash
已输入。
X-前转-用于¶
Varnish会自动将 client.ip
发送到 X-Forwarded-For
传递到后端的请求头,或者,如果该值尚未出现在客户端请求中,则创建具有该值的头。
如果客户端请求是通过UDS侦听器接收的,并且未使用代理协议,则 0.0.0.0
将添加到 X-Forwarded-For
。如果您愿意,可以在VCL::中更改
sub vcl_backend_fetch {
# Assuming that server.identity has been set to an IP
# address with the -i command-line argument.
set bereq.http.X-Forwarded-For
= regsub(bereq.http-X-Forwarded-For, "0.0.0.0$", server.identity);
# ...
}
同样,如果出现以下情况,这可能不是一个问题 client.ip
是通过代理协议设置的。
UDS后端和主机标头¶
默认情况下,Varnish将主机标头从客户端请求转发到后端。如果客户端请求中没有主机标头,并且 .host_header
字段在后端声明中设置,则该值用于后端主机标头。方法声明的后端 .host
字段(带有域名或IP地址),则如果既没有客户端主机标头,也没有 .host_header
声明的值, .host
被设置为后端请求的主机头。
如果后端是用 .path
对于套接字路径,则将后端主机标头设置为 0.0.0.0
在这种情况下。
重申一下:
如果后端是用
.path
要连接到Unix域套接字,...和
.host_header
未在后端声明中设置,...并且客户端请求中没有主机标头,...
则将后端请求中的主机标头设置为
0.0.0.0
。
如果希望避免这种情况,请设置一个 .host_header
后端的值,或在VCL中设置主机标头的值。
VMOD标准¶
内部端口(IP IP) 在应用于 *.ip
值设置为的变量 0.0.0.0
因为监听器是UDS。 无效set_ip_tos(Int Tos) 当侦听器为UDS时,将以静默方式忽略。
这个 shard
导演¶
这个 alg
碎片主管的论点 .reconfigure()
和 .key()
方法已被移除。散列算法的选择是实验性的,我们最终选择SHA256作为提供最佳分散的算法。
如果您一直在使用其他选项 alg
为 .reconfigure()
,然后在升级和删除后 alg
,对后端的请求分片将更改一次且仅更改一次。
如果您一直在使用 alg
为 .key()
并需要保留以前的行为,请参阅 change log 寻求如何做到这一点的建议。
与 resolve=LAZY
的论据 .backend()
方法后,碎片控制器现在将把后端的选择推迟到实际建立后端连接的时候,这也是所有其他捆绑的控制器的工作方式。
在……里面 vcl_init
, resolve=LAZY
是默认的,并且允许将碎片控制器分层在其他控制器之下--您现在可以使用如下内容 mydirector.add_backend(myshard.backend())
将碎片控制器设置为另一个控制器的后端。
使用 resolve=LAZY
仅限于使用默认或关联的参数。
碎片控制器现在提供了一个 shard_param
对象,该对象用作控制器的参数集的存储区 .backend()
方法。这样就可以重复使用一组参数值,而不必在每个 .backend()
打电话。这个 .backend()
方法有一个参数 param
其值(如果使用)必须从 shard_param.use()
方法。
由于这些更改,因此支持碎片控制器的位置参数 .backend()
方法必须被移除。换句话说,碎片控制器的所有参数 .backend()
方法现在需要命名。
看见 VMOD导向器-Varnish导向器模块 了解更多细节。
重新启动¶
重新启动现在使客户端请求的所有属性保持不变(所有 req.*
变量,包括标头),但 req.restarts
和 req.xid
,它会因设计而改变。
如果需要将客户端请求标头重置为其原始状态(在VCL更改之前),请调用 无效回滚(HTTP H) 。
return(restart)
现在可以从 vcl_recv{}
。
新的VMOD¶
VMOD Unix¶
VMOD Unix-Unix域套接字实用程序 提供用于确定通过Unix域套接字的侦听器连接到Varnish的对等进程(进程所有者的用户和组)的凭据的函数。例如,您可以使用它来对谁可以访问某些资源施加更严格的限制:
import unix;
sub vcl_recv {
# Return "403 Forbidden" if the connected peer is
# not running as the user "trusteduser".
if (unix.user() != "trusteduser") {
return( synth(403) );
}
这并不是在所有平台上都可用。像往常一样,在生产中尝试这样的操作之前,请检查文档并测试代码。
VMOD代理¶
VMOD Proxy-从PROXYv2中提取TLV属性的Varnish模块 提供提取TLV属性的函数,这些属性可以选择性地通过PROXYv2连接发送到Varnish侦听器。其中大多数是对等组件的TLS连接的属性::
import proxy;
# Get the authority attribute -- corresponds to the SNI of a TLS
# connection.
set req.http.Authority = proxy.authority();
并不是所有的实现都发送TLV属性,并且那些发送TLV属性的实现不一定支持所有的TLV属性;测试您的代码以查看哪些属性在您的配置中有效。
请参阅 PROXY v2 specification 有关TLV属性的更多信息。
包装变化¶
支持的平台¶
官方的Varnish包在这个版本中经历了重大的变化,目标是Debian 9、Ubuntu 16.04 LTS和(Red Hat)Enterprise Linux 7。Ubuntu 14.04 LTS可能会在Varnish 6之前达到其生命周期的尽头,而受人尊敬的Enterprise Linux 6变得太旧且太耗时,因此出于这些原因,我们放弃了对这些平台的社区支持。
服务¶
结果,我们最终得到了仅用于官方包的system d平台。旧服务仍然可用,因为我们将它们存档在 pkg-varnish-cache
源树。这是消除Red Hat和Debian衍生品之间差异的机会,因为没有更多的理由使它们不同:我们最初从下游包维护者那里继承了打包支持,他们应该为此而受到很多感谢。
在所有官方包中统一我们的system d设置的最大变化是 varnish.params
有关红帽衍生品的可用文件不见了。我们注意到,使用环境文件来隐藏以下事实 varnishd
是通过命令行参数配置的,这误导了一些人,使他们认为文件中建议的内容是您唯一的一组配置选项。例如,您可以使用多个指定监听地址 -a
选项,但您只获得一个地址的变量和一个通用变量 DAEMON_OPTS
任何不适合模板的内容。此外,使用环境文件会污染进程的环境。
RedHat和Debian衍生品之间的另一个重大区别是我们通过服务管理器处理VCL重新加载的方式。我们引入了一种新的 varnishreload
在上运行的脚本 varnishadm
一次执行一个VCL配置或标签的热重新加载。您所需要的只是足够的权限来联系 varnishd
的命令行界面,这对于包管理器来说应该不是问题。
一旦 varnish
程序包已安装,您可以了解更多信息::
varnishreload -h
再次感谢下游维护人员和一些早期采用者在测试新脚本方面的帮助。
为了停留在命令行界面的主题上,包不再为CLI创建秘密文件,并且服务省略 -S
和 -T
上的选项 varnishd
指挥部。这意味着开箱即用,您只能以足够的权限连接到本地CLI以读取随机生成的密码。这意味着我们的包中噪音更小,您需要更改服务配置以启用对CLI的远程访问。对于以前的包,您还需要更改您的配置,因为CLI无论如何都只会侦听环回接口。
改变方式的步骤 varnishd
已启动,请参阅系统文档。
虚拟提供¶
最后但并非最不重要的是,在包装领域,我们迈出了第一步,以改善官方 varnish
包和VMOD建立在它们的上面。RPM和Deb包现在提供来自 varnishd
其目标是最终防止安装或升级包,从而阻止加载VMOD。
对于Deb包:
Provides:
varnishd-abi-SHA1,
varnishd-vrt (= x.y)
对于RPM::
Provides: varnishd(abi)(x86-64) = SHA1
Provides: varnishd(vrt)(x86-64) = x.y
对于VMOD作者或下游发行商,这意味着取决于 $ABI
节,他们可以手动将他们的后端绑定到构建Varnish的GIT散列,或者绑定到当时使用的VRT版本。
例如,基于Varnish 6.0.0构建的VMOD RPM可能具有:
Requires: varnishd(vrt)%{?_isa} >= 7.0
Requires: varnishd(vrt)%{?_isa} < 8
未来的计划包括为树外VMOD自动执行此操作,并删除手动步骤。为了更多地了解这一变化背后的历史,通过Varnish改进过程正式确定了这一变化:
https://github.com/varnishcache/varnish-cache/wiki/VIP20%3A-Varnish-ABI-and-packaging
从6.0.0开始,RPM包才能使用的另一项功能是为VMOD提供虚拟服务。
不显示甚至不在动态链接器的默认路径中的共享对象::
Provides: libvmod_std.so(64bit)
Provides: libvmod_directors.so(64bit)
[...]
您可以获得虚拟VMOD提供的版本::
Provides: vmod(std)(x86-64) = 6.0.0-1
Provides: vmod(directors)(x86-64) = 6.0.0-1
[...]
使用相同的机制,可以直接请求VMOD并让它带来它的依赖项,例如 varnish
。由于树外VMOD目前还不能自动执行此操作,因此可以将其视为VIP 20完成后您将能够执行的操作的预览。
其他变化¶
varnishd(1)
:这个
umem
从Varnish 5.1起删除的存储分配器已恢复,现在是以下系统的默认设置libumem
是可用的(SunOS及其后代)。
varnishlog(1)
:将第三个字段添加到
ReqStart
包含通过其接收请求的监听器地址的名称的日志记录,请参见 VSL 。0.0.0.0
和端口0
当有问题的连接被寻址为Unix域套接字时,出现在日志中的地方会出现IP和端口。这会影响ReqStart
,SessOpen
,BackendStart
和BackendOpen
。如果您有多个UDS监听程序,则可以使用“监听程序名称”字段来区分它们--这两个字段都是第三个字段
ReqStart
和SessOpen
。如果您有多个UDS后端,则可以使用后端名称字段来区分它们--中的第二个字段
BackendOpen
。记录的字节计数器
ReqAcct
现在报告从操作系统返回的数字,这些数字告诉我们在请求和响应中实际发送了多少字节,而不是Varnish认为它将发送的内容。这在出现错误时提供了更准确的描述,例如,当客户端在没有收到完整响应的情况下提前挂断时。这些数字还包括请求或响应正文中的任何开销,例如,由于分块编码。默认情况下,代理协议的调试日志处于关闭状态。可以使用
protocol
流氓的旗帜 调试 参数 (-p debug=+protocol
)。
varnishstat(1)
柜台又加了一句
cache_hit_grace
--缓存中的对象在其TTL过期但仍在正常状态时被命中的频率。
varnishncsa(1)
这个
%h
格式化程序(远程主机)从ReqStart
对于客户端请求和BackendStart
用于后端请求。该值将为0.0.0.0
监听器为UDS时的客户端请求,以及后端为UDS时的后端请求。这个
%r
格式化程序(请求的第一行)部分是从主机请求头重建的。对于UDS后端,主机可能是0.0.0.0
出于上述原因(没有客户端主机标头和没有.host_header
后端的设置),这样它可能会出现在%r
。您可以通过上面讨论的措施来避免这种情况。如果您有多个UDS侦听器和/或多个UDS后端,并且希望在
varnishncsa
输出(而不仅仅是查看0.0.0.0
),请使用%{VSL}x
用于捕获监听程序名称和后端名称的格式化程序。对于监听器名称,请使用
%{VSL:ReqStart[3]}x
对于客户端日志(的第三个字段ReqStart
日志)。对于后端名称,使用
%{VSL:BackendOpen[2]}x
用于后端日志。Varnishncsa不接受输出格式字符串(来自
-F
命令行参数或配置文件),如果它们为其有效负载可能包含控制字符或二进制字符的日志条目指定标记。
varnishtest(1)
和vtc(7)
:这个
client -connect
和server -listen
VTC脚本中的命令现在允许Unix域套接字作为地址,当参数以/
。客户端立即尝试连接,因此当客户端启动时套接字文件必须存在于给定路径,并且客户端必须能够访问它。
这个
server -listen
命令必须能够在执行时创建套接字文件bind(2)
。为了使其他进程更容易连接到套接字,服务器的umask值在尝试侦听之前被临时设置为0,以最大限度地减少权限问题。不会进一步尝试设置套接字的权限。要测试侦听UDS的Varnish实例,只需使用
varnish -arg
命令的相应设置。-a
命令行参数,请参见 华而不实 。这个
varnish -vcl+backend
命令现在可以包含正在侦听UDS的服务器对象的后端定义。对于这样的服务器,后端声明是隐式包含的,具有适当的.path
布景。测试中使用套接字文件的一个方便位置是由创建的临时目录
varnishtest
对于每个测试,其路径保存在宏中${tmpdir}
。因此,这是涉及Udsen的测试的常见习语::server s1 -listen "${tmpdir}/s1.sock" { ... } -start varnish v1 -arg "-a ${tmpdir}/v1.sock" -vcl+backend { ... } -start client c1 -connect "${tmpdir}/v1.sock" { ... } -run
当Varnish实例在VTC测试中侦听UDS时,其
vN_*
宏的设置如下:v1_addr
:/path/to/socket
v1_port
:-
(连字符)v1_sock
:/path/to/socket -
当服务器
s1
正在监听UDS:s1_addr
:0.0.0.0
s1_port
:0
s1_sock
:/path/to/socket
职训局的变数
remote.ip
和remote.port
,它可用于expect
服务器和客户端脚本的表达式都设置为0.0.0.0
和0
分别当对等地址是UDS时。我们已经添加了变量
remote.path
作为另外两个的对立面。当对等地址为UDS时,其值为路径,否则为空(匹配<undef>
在后一种情况下)。
针对开发人员的更改:
VRT API版本已经升级到7.0,并包含了各种新的添加和更改。看见
vrt.h
以及 change log 了解更多细节。There are new rules about including API headers -- some may only be included once, others must included in a specific order. Only
cache.h
orvrt.h
may be included (cache.h
includesvrt.h
). See the#error
directives in the headers.VMOD作者可以使用
VRT_VSC_*()
一系列功能和新功能vsctool
为将由varnishstat显示的VMOD创建统计信息。Varnish使用相同的技术来创建其计数器,因此您可以查看核心代码以了解它是如何完成的。这个
VCL_INT
和VCL_BYTES
类型现在定义为严格的64位(而不是将其留给您的平台定义为long
)。但是,您可能无法获得完全的精度,原因在 change log 。作为VRT版本7.0的一部分,
path
已将字段添加到struct vrt_backend
,VMOD可以将其与VRT_new_backend()
要使用UDS地址创建动态后端(请参见vrt.h
)。如果
path
为非空,则IPv4和IPv6地址都必须为空。如果path
为空,则(如前所述)其中一个或两个IP地址必须为非空。这个dyn_uds
VMOD调试中的对象(可在源代码树中找到)说明了如何做到这一点。VMOD VCC信号源现在可能包含指令
$Prefix
,它的值是在生成的C接口中C对象和函数名称前面的字符串(在vcc_if.h
)。所以你可以选择另外一个前缀vmod_
,如果需要的话。VCC来源还可能包括一条指令
$Synopsis
其价值可能是auto
或manual
,默认auto
。什么时候
$Synopsis
是auto
,vmodTool会生成更全面的SYNOPSIS
部分--VMOD中的对象、方法和函数及其类型签名的概述。什么时候
$Synopsis
是manual
vt.的.SYNOPSIS
完全被排除在生成的文档之外;因此您可以编写SYNOPSIS
如果你愿意,可以切开你自己的身体。添加了对VCC文件中可选参数的新声明的支持:
[ argname ]
可以用来标记 argname 作为可选选项。If this declaration is used for any argument, _all_ user arguments and
PRIV_*
pointers (no object pointers) to the respective function/method will be passed in astruct
funcname_arg
specific to this function which contains the arguments by their name (or the namearg
n for unnamed arguments, n being the argument position starting with 1) plusvalid_
argname members for optional arguments which are being set to non-zero iff the respective argname was provided.参数的存在是在VCC时确定的,因此不可能从另一个函数调用传递未设置的参数。
eof