In the principle of DRY, hop on over to the Apache as a Proxy introduction because the details are the same.
Likewise, setting up our repository for Squid was pretty much the same as setting up Apache. We only use one install script, just a script to reload Squid but still have a set of Jinja templates for automating the configuration of our application at build time. In particular, the consul-template template which is used when we discover what Apache servers are in our environment. It obviously isn't normal to be discovering clients but we wanted to demonstrate how we can use active discovery to configure our Squid ACLs. When used with secure keys, this could be used to configure Squid as a basic identity aware proxy.
So much is covered in the Apache repo that there isn't a great deal to write about here (well, consistent and repeatable builds is what a lot of this is about). However, there are still a few interesting points:
- Discovering our clients is done by having a list of downstream services to tell Containerpilot to watch, then reload Squid on change.
- To get Squid to log to stdout, we had to run syslogd as a coprocess in the container. So we took the opportunity to demonstrate template precedence. By renaming the example template and creating our own custom Containerpilot.json5 template in our local orchestration templates directory, we were able to overwrite the playbook's default one and add in a job to run syslog.
- We found a strange Squid behaviour where if the CIDR (/32) range was missed off an IP address used for an ACL, Squid would not log requests to access_log even though debugging and testing found the requests to succeed.
- Our downstream server addresses are updated in their own file
- Just like Apache, we also added some configuration for reverse proxying
###------------------------------------------------------------------------------------------------------------------------- Template by Mesoform Limited