На работе у нас есть кластер Varnish. Все удаленные бэкенды используют .hostзначение (которое, как я предполагаю, является обязательным), но все конфигурации для локального бэкенда, т. е. бэкенда, работающего на сервере, на котором находится config/varnishd, используют это .pathзначение. Сегодня утром у меня возникла проблема с одним из серверов Varnish, по сути, сокет, на который ссылается , .pathне существовал, и поэтому он не запускался. Я пробовал разные способы восстановить работу сокета, но после того, как ни один из них не сработал, я переключил конфигурацию Varnish на использование этого .backendзначения. Я вижу, что это преимущество, так как теперь я могу легко поддерживать централизованную конфигурацию Varnish, не беспокоясь о компиляции каждой конфигурации на основе каждого сервера (т. е. удаляя строку .hostиз бэкенда, которая соответствует определенному серверу).
Есть ли существенные преимущества от использования сокета для подключения к локальному кластеру Varnish (использование Hitch для завершения SSL, если это имеет значение)? Если все равно, я считаю, что использование .hostзначения является лучшим вариантом, поскольку оно значительно упрощает отправку обновлений конфигурации.
решение1
Использование .pathсокетов домена Unix намного быстрее, чем использование .hostи .portдля соединений TCP/IP.
Если пропускная способность важна, используйте Unix Domain Sockets, так как вы получите более высокую пропускную способность (>100 Гбит/с по TLS).
Если высокая пропускная способность не так важна, можно использовать TCP/IP, который не требует наличия UDS.
Для UDS разрешения имеют значение, поэтому убедитесь, что и Varnish, и Hitch имеют необходимые разрешения для доступа к сокету. Varnish создаст сокет, а Hitch будет его использовать.