futriix/tests/sentinel/tests/08-hostname-conf.tcl

67 lines
1.9 KiB
Tcl
Raw Normal View History

Add hostname support in Sentinel. (#8282) This is both a bugfix and an enhancement. Internally, Sentinel relies entirely on IP addresses to identify instances. When configured with a new master, it also requires users to specify and IP and not hostname. However, replicas may use the replica-announce-ip configuration to announce a hostname. When that happens, Sentinel fails to match the announced hostname with the expected IP and considers that a different instance, triggering reconfiguration, etc. Another use case is where TLS is used and clients are expected to match the hostname to connect to with the certificate's SAN attribute. To properly implement this configuration, it is necessary for Sentinel to redirect clients to a hostname rather than an IP address. The new 'resolve-hostnames' configuration parameter determines if Sentinel is willing to accept hostnames. It is set by default to no, which maintains backwards compatibility and avoids unexpected DNS resolution delays on systems with DNS configuration issues. Internally, Sentinel continues to identify instances by their resolved IP address and will also report the IP by default. The new 'announce-hostnames' parameter determines if Sentinel should prefer to announce a hostname, when available, rather than an IP address. This applies to addresses returned to clients, as well as their representation in the configuration file, REPLICAOF configuration commands, etc. This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET which can be used to introspect or configure global Sentinel configuration that was previously was only possible by directly accessing the configuration file and possibly restarting the instance. Co-authored-by: myl1024 <myl92916@qq.com> Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
proc set_redis_announce_ip {addr} {
foreach_redis_id id {
R $id config set replica-announce-ip $addr
}
}
proc set_sentinel_config {keyword value} {
foreach_sentinel_id id {
S $id sentinel config set $keyword $value
}
}
proc set_all_instances_hostname {hostname} {
foreach_sentinel_id id {
set_instance_attrib sentinel $id host $hostname
}
foreach_redis_id id {
set_instance_attrib redis $id host $hostname
}
}
test "(pre-init) Configure instances and sentinel for hostname use" {
set ::host "localhost"
restart_killed_instances
set_all_instances_hostname $::host
set_redis_announce_ip $::host
set_sentinel_config resolve-hostnames yes
set_sentinel_config announce-hostnames yes
}
source "../tests/includes/init-tests.tcl"
proc verify_hostname_announced {hostname} {
foreach_sentinel_id id {
# Master is reported with its hostname
if {![string equal [lindex [S $id SENTINEL GET-MASTER-ADDR-BY-NAME mymaster] 0] $hostname]} {
return 0
}
Add hostname support in Sentinel. (#8282) This is both a bugfix and an enhancement. Internally, Sentinel relies entirely on IP addresses to identify instances. When configured with a new master, it also requires users to specify and IP and not hostname. However, replicas may use the replica-announce-ip configuration to announce a hostname. When that happens, Sentinel fails to match the announced hostname with the expected IP and considers that a different instance, triggering reconfiguration, etc. Another use case is where TLS is used and clients are expected to match the hostname to connect to with the certificate's SAN attribute. To properly implement this configuration, it is necessary for Sentinel to redirect clients to a hostname rather than an IP address. The new 'resolve-hostnames' configuration parameter determines if Sentinel is willing to accept hostnames. It is set by default to no, which maintains backwards compatibility and avoids unexpected DNS resolution delays on systems with DNS configuration issues. Internally, Sentinel continues to identify instances by their resolved IP address and will also report the IP by default. The new 'announce-hostnames' parameter determines if Sentinel should prefer to announce a hostname, when available, rather than an IP address. This applies to addresses returned to clients, as well as their representation in the configuration file, REPLICAOF configuration commands, etc. This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET which can be used to introspect or configure global Sentinel configuration that was previously was only possible by directly accessing the configuration file and possibly restarting the instance. Co-authored-by: myl1024 <myl92916@qq.com> Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
# Replicas are reported with their hostnames
foreach replica [S $id SENTINEL REPLICAS mymaster] {
if {![string equal [dict get $replica ip] $hostname]} {
return 0
}
Add hostname support in Sentinel. (#8282) This is both a bugfix and an enhancement. Internally, Sentinel relies entirely on IP addresses to identify instances. When configured with a new master, it also requires users to specify and IP and not hostname. However, replicas may use the replica-announce-ip configuration to announce a hostname. When that happens, Sentinel fails to match the announced hostname with the expected IP and considers that a different instance, triggering reconfiguration, etc. Another use case is where TLS is used and clients are expected to match the hostname to connect to with the certificate's SAN attribute. To properly implement this configuration, it is necessary for Sentinel to redirect clients to a hostname rather than an IP address. The new 'resolve-hostnames' configuration parameter determines if Sentinel is willing to accept hostnames. It is set by default to no, which maintains backwards compatibility and avoids unexpected DNS resolution delays on systems with DNS configuration issues. Internally, Sentinel continues to identify instances by their resolved IP address and will also report the IP by default. The new 'announce-hostnames' parameter determines if Sentinel should prefer to announce a hostname, when available, rather than an IP address. This applies to addresses returned to clients, as well as their representation in the configuration file, REPLICAOF configuration commands, etc. This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET which can be used to introspect or configure global Sentinel configuration that was previously was only possible by directly accessing the configuration file and possibly restarting the instance. Co-authored-by: myl1024 <myl92916@qq.com> Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
}
}
return 1
Add hostname support in Sentinel. (#8282) This is both a bugfix and an enhancement. Internally, Sentinel relies entirely on IP addresses to identify instances. When configured with a new master, it also requires users to specify and IP and not hostname. However, replicas may use the replica-announce-ip configuration to announce a hostname. When that happens, Sentinel fails to match the announced hostname with the expected IP and considers that a different instance, triggering reconfiguration, etc. Another use case is where TLS is used and clients are expected to match the hostname to connect to with the certificate's SAN attribute. To properly implement this configuration, it is necessary for Sentinel to redirect clients to a hostname rather than an IP address. The new 'resolve-hostnames' configuration parameter determines if Sentinel is willing to accept hostnames. It is set by default to no, which maintains backwards compatibility and avoids unexpected DNS resolution delays on systems with DNS configuration issues. Internally, Sentinel continues to identify instances by their resolved IP address and will also report the IP by default. The new 'announce-hostnames' parameter determines if Sentinel should prefer to announce a hostname, when available, rather than an IP address. This applies to addresses returned to clients, as well as their representation in the configuration file, REPLICAOF configuration commands, etc. This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET which can be used to introspect or configure global Sentinel configuration that was previously was only possible by directly accessing the configuration file and possibly restarting the instance. Co-authored-by: myl1024 <myl92916@qq.com> Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
}
test "Sentinel announces hostnames" {
# Check initial state
verify_hostname_announced $::host
# Disable announce-hostnames and confirm IPs are used
set_sentinel_config announce-hostnames no
assert {[verify_hostname_announced "127.0.0.1"] || [verify_hostname_announced "::1"]}
Add hostname support in Sentinel. (#8282) This is both a bugfix and an enhancement. Internally, Sentinel relies entirely on IP addresses to identify instances. When configured with a new master, it also requires users to specify and IP and not hostname. However, replicas may use the replica-announce-ip configuration to announce a hostname. When that happens, Sentinel fails to match the announced hostname with the expected IP and considers that a different instance, triggering reconfiguration, etc. Another use case is where TLS is used and clients are expected to match the hostname to connect to with the certificate's SAN attribute. To properly implement this configuration, it is necessary for Sentinel to redirect clients to a hostname rather than an IP address. The new 'resolve-hostnames' configuration parameter determines if Sentinel is willing to accept hostnames. It is set by default to no, which maintains backwards compatibility and avoids unexpected DNS resolution delays on systems with DNS configuration issues. Internally, Sentinel continues to identify instances by their resolved IP address and will also report the IP by default. The new 'announce-hostnames' parameter determines if Sentinel should prefer to announce a hostname, when available, rather than an IP address. This applies to addresses returned to clients, as well as their representation in the configuration file, REPLICAOF configuration commands, etc. This commit also introduces SENTINEL CONFIG GET and SENTINEL CONFIG SET which can be used to introspect or configure global Sentinel configuration that was previously was only possible by directly accessing the configuration file and possibly restarting the instance. Co-authored-by: myl1024 <myl92916@qq.com> Co-authored-by: sundb <sundbcn@gmail.com>
2021-01-28 12:09:11 +02:00
}
# We need to revert any special configuration because all tests currently
# share the same instances.
test "(post-cleanup) Configure instances and sentinel for IPs" {
set ::host "127.0.0.1"
set_all_instances_hostname $::host
set_redis_announce_ip $::host
set_sentinel_config resolve-hostnames no
set_sentinel_config announce-hostnames no
}