TL;DR
All Varnish Cache VCL changes submitted will be validated, and if compilation fails, the changes will be rejected. All running Varnish Cache instances will maintain the last known good configuration. This applies to both in-browser editing and using git push from a local workspace.
In the beginning
The core tenets at Section are to provide a platform that is open, easy and gives control to the user. All three of these are present in the Varnish Cache Configuration Language editor in our Section Console.
We expose the raw VCL, in the browser, for the user to customise, save, and deploy just as the user could if they managed their own Varnish Cache instance. This approach is also key to honouring another Section mantra - “It’s just Varnish Cache”.
Unfortunately, our original implementation differed from normal Varnish Cache usage in an important way: deploying broken VCL to any typical Varnish Cache instance would be rejected and Varnish Cache would continue to operate with the last known good configuration. However Section’s Varnish Cache instances would instead lose the last known good configuration and begin serving an error response for all requests.
How did this happen?
This difference in handling broken configurations was a by-product of ensuring that the committed files at tip of the repository branch (eg Production) should represent the active configuration of the reverse-proxies handling live traffic. The intent was to reduce the conceptual complexity that would arise from having the most recent commit show one state whilst needing another branch (or tag) to track the state that was last successfully deployed.
This behaviour, while not helping the chance of breaking your site through web-based VCL editing, has always been mitigated by Section’s recommended local development experience. In local development, VCL changes can be tested, not only to ensure correct syntax, but also to confirm that the actual impact on your site’s behaviour is what you had intended, and tested against the same Varnish Cache version as used in production.
We have wanted to improve upon this situation for a while, to make Section even easier and safer to use with confidence. Now we have.
A better experience
The platform now performs Varnish Cache VCL validation when saving changes made in the Section Console web-based editor and when pushing commits from your local development git workspace. This means that you cannot save broken configuration to your application repository that might have previously resulted in serving error pages to your visitors.
For those with a technical interest, this validation is implemented by passing your desired configuration changes to a duplicate Docker container of the same Varnish Cache proxy image that is used to handle your live traffic. This provides high confidence that the configuration is valid in the context of your specific Varnish Cache version and its settings and available modules.
While we still strongly encourage implementing and testing changes in a development environment before promoting them through to Production, you can now also make quick changes in the browser without fear of accidentally forgetting a semicolon.
