-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add parents to varnish cache #7669
Add parents to varnish cache #7669
Conversation
Also, will create issues for all TODOs added to be tracked and also changes that need to be done for proper integration with TC |
Codecov Report
@@ Coverage Diff @@
## master #7669 +/- ##
=============================================
- Coverage 65.05% 26.89% -38.16%
Complexity 98 98
=============================================
Files 314 691 +377
Lines 12365 81057 +68692
Branches 907 90 -817
=============================================
+ Hits 8044 21803 +13759
- Misses 3968 57180 +53212
- Partials 353 2074 +1721
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 570 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
ca0b1ba
to
6a5c26a
Compare
echo "varnishd is already running." | ||
else | ||
echo "Starting varnishd..." | ||
"$VARNISHD_EXECUTABLE" -f /opt/trafficserver/etc/trafficserver/default.vcl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider moving default.vcl into a different directory, not trafficserver
related?
lib/varnishcfg/vcl.go
Outdated
|
||
// has to be before other subroutines for variables initialization | ||
txt += fmt.Sprint("sub vcl_init {\n") | ||
for _, entry := range v.subroutines["vcl_init"] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we guaranteed to always have a vcl_init
or do we need to check for presence first?
lib/varnishcfg/backends.go
Outdated
// only change request host from edge servers which typically has multiple request FQDNs or | ||
// one request FQDN that is not the origin. | ||
if len(requestFQDNs) > 1 || (len(requestFQDNs) == 1 && requestFQDNs[0] != svc.DestDomain) { | ||
lines = append(lines, fmt.Sprintf("\tset req.http.host = \"%s\";", svc.DestDomain)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might want to consider moving this to vcl_backend_fetch, and doing set bereq.http.host=...
so that the host header is only changed on the request to the backend, and the original host header is preserved in the client request processing
lib/varnishcfg/backends.go
Outdated
lines := make([]string, 0) | ||
directorType := getDirectorType(retryPolicy) | ||
sticky := "" | ||
if directorType == "fallback" && retryPolicy == atscfg.ParentAbstractionServiceRetryPolicyLatched { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding a separate sticky
return from getDirectorType so all that evaluation happens in the same place
Left a few comments, still need to test it out |
@@ -533,6 +535,9 @@ If any of the related flags are also set, they override the mode's default behav | |||
if tsHome != "" { | |||
TSHome = tsHome | |||
tsConfigDir = tsHome + "/etc/trafficserver" | |||
if cache != nil && *cache == "varnish" { | |||
tsConfigDir = tsHome + "/etc/varnish" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like for varnish cache servers, this will cause it to look for configuration files under /etc/trafficserver/etc/varnish
(by default I think tsHome
is /opt/trafficserver
so that winds up being /opt/trafficserver/etc/trafficserver/etc/varnish
) - is that really how we want to structure that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the config dir will be either home + /etc/trafficserver
, home + /etc/varnish
or if --trafficserver-home
flag is not used it will default to /opt/trafficerver/etc/trafficserver
and won't go into the if block (which is not good) other than that it will be home + /etc/varnish
for varnish case. For example specifying --trafficserver-home
flag with /opt/cache
will write the config to /opt/cache/etc/varnish
and that is what is done in varnish entrypoint.
I think ultimately default home and config dir shouldn't be related to TS. However, this change will affect CIAB, tests, workflows and some other code depending on that. So, Maybe it would be better if it is done in a separate PR?
reloadCommand := config.TSHome + config.TrafficCtl | ||
reloadArgs := []string{"config", "reload"} | ||
if cfg.CacheType == "varnish" { | ||
reloadCommand = "varnishreload" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be relying on varnishreload
being in the running user's $PATH
- with ATS cache servers we typically install everything under /opt/trafficserver
(not that I think that's a good idea, personally) but it seems like that won't work for varnish caches if everything winds up installed under e.g. /opt/varnish
. Or, at least, not without some extra work. Is that intentional, or is there some reason why it wouldn't find varnishreload
in the same directory as the varnish
binary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is done that way because Varnish currently is installed under root. So, varnishreload
is currently installed in user's $PATH
. It will be a problem indeed if Varnish is installed under different directory. Should Varnish be installed under different directory?
import ( | ||
"github.com/apache/trafficcontrol/cache-config/t3c-generate/config" | ||
"github.com/apache/trafficcontrol/cache-config/t3cutil" | ||
"github.com/apache/trafficcontrol/lib/varnishcfg" | ||
) | ||
|
||
/* | ||
* Licensed to the Apache Software Foundation (ASF) under one | ||
* or more contributor license agreements. See the NOTICE file | ||
* distributed with this work for additional information | ||
* regarding copyright ownership. The ASF licenses this file | ||
* to you under the Apache License, Version 2.0 (the | ||
* "License"); you may not use this file except in compliance | ||
* with the License. You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, | ||
* software distributed under the License is distributed on an | ||
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY | ||
* KIND, either express or implied. See the License for the | ||
* specific language governing permissions and limitations | ||
* under the License. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
license header should go above imports, below package declaration
# varnishcfg requires t3c for ToData struct and not needed for enroller | ||
RUN rm -rf /go/src/github.com/apache/trafficcontrol/lib/varnishcfg | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't worry about it; the enroller is pulling in a lot of things it doesn't strictly need. We can evaluate it if it becomes a problem, and try to clean it up a bit, but varnishcfg is small compared to the rest of the cruft so there's no point worrying about it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the comment can be improved, but it is not removed for optimization reasons. if we remove this line it won't be able to build the enroller binary because varnishcfg
requires t3c-util
package for the ConfigData
struct here. So, we will need to copy t3c
packages too. t3c
also requires some other packages not included with the enroller, so also they will need to be copied. The problem will be in keeping track of all these packages and what they require and any changes in the future. So I Just remove it instead of managing all that when it is not needed. But I believe it might be better to make varnishcfg
not depend on t3c-util
|
||
RUN curl -s https://packagecloud.io/install/repositories/varnishcache/varnish73/script.rpm.sh | bash | ||
|
||
RUN yum install varnish-7.3.0-1.el8.x86_64 -y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you really want to pin down to a specific release like that? If there's a major security bug that gets fixed with no breaking changes in v7.3.0-2 then we'd have to update this script. Also not sure it's a good idea to hard-code the CPU architecture; a lot of ATC devs use Macs, for example, and their new chipset isn't x86_64.
/usr/local/sbin/ | ||
|
||
|
||
COPY infrastructure/cdn-in-a-box/varnish/systemctl.sh /usr/bin/systemctl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it absolutely necessary to use systemd? Doing that in a Docker container is prone to problems and headaches
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since t3c-apply
only manages services using systemctl
(or service
in sysV systems) Traffic Server image and Varnish image both include a script replacing systemctl
to start, restart, show status, enable and stop the cache service. There is no actual invoking of systemd, the scripts just mimics the behavior of systemctl
regarding services
@@ -0,0 +1,73 @@ | |||
package varnishcfg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least one file in a package should have a GoDoc comment.
Verified CIAB works to pull traffic through varnish following instructions above |
* Add varnishcfg package and parent configuration * Add Varnish Dockerfile to be used in CIAB * Add license to Varnsih Dockerfile * Add systemctl.sh to handle Varnish service and integrate Varnish with t3c-apply * Move host changes to BE fetch, change varnish dir and make test more readable * Remove Varnish package release and arch, add GoDoc and move licenses * Move license text
Add the least required changes to run Varnish in a topology with parents by reusing some implementation already made in
go-atscfg
and add Dockerfile for Varnish to be testable in CIAB.Which Traffic Control components are affected by this PR?
t3c
, formerly ORT)What is the best way to verify this PR?
Using CIAB:
chkconfig
andpackage
parameters from edge or mid profile.Note: since both mid servers use the same profile Varnish can run either as the two mid caches or just edge. It can't run as all servers for now as the router does not route to servers if Traffic Monitor does not poll any cache server. So, either both mid servers or edge.
PR submission checklist