Configuration for GOV.UK's content delivery network (CDN). You can read more about how GOV.UK CDN works in the developer docs.
ℹ️ This repo has some documented tech debt. It doesn't conform to GOV.UK standards.
This repo contains 3 scripts to configure our Fastly CDN account.
We are using Fastly API for all the processes (see documentation).
Script: deploy-service.sh
Invoked via the CDN: deploy service Jenkins job.
This script allows you to deploy a new VSL on a number of Fastly services (see table bellow) and replaces the old configuration.
| service name | domain | description |
|---|---|---|
| apt | apt.publishing.service.gov.uk | GOV.UK's Debian package repository |
| assets | assets.publishing.service.gov.uk | the GOV.UK domain for uploads and static assets |
| servicegovuk | service.gov.uk | redirect from https://service.gov.uk to https://www.gov.uk |
| tldredirect | gov.uk | redirect from https://gov.uk to https://www.gov.uk |
| www | www.gov.uk | the single government domain |
Script: deploy-dictionaries.sh
Invoked via the CDN: update dictionaries Jenkins job.
Fastly provide a technology called Edge Dictionaries which can be used to provide dynamic configuration to VCL. This script takes updates dictionaries defined in YAML files in configs/dictionaries. We use it for A/B testing and blocking IP addresses (the dictionary for this lives in alphagov/govuk-cdn-config-secrets - read more about IP banning in the docs).
Script: deploy-bouncer.sh
Invoked via the CDN: deploy Bouncer configs Jenkins job.
This configures the bouncer Fastly service with transitioned domains from Transition (read about Transition here). The Jenkins job is not usually run manually - it's triggered by the one of the transition Jenkins jobs. Read more about the Fastly service in the developer docs.
You will need to re-generate the spec files when making changes to www.vcl.erb.
REGENERATE_EXPECTATIONS=1 bundle exec rspecWe use edge dictionaries to define the configuration for A/B and multivariate tests. The same configuration applies to A/B and multivariate tests, differing only on the number of variants.
configs/dictionaries/active_ab_tests.yaml: This controls whether the test is active or not. You may want to configure your test to be inactive at first, so that you can activate it at a later date.configs/dictionaries/<test name lowercase>_percentages.yaml: The percentage of users who should see the variants of your test. This can be changed at a later date to expand the test to more users, but note that there will be some lag because users who have already visited the site will stay in their variant test buckets until their cookie expires. (Seeexample_percentages.yaml).configs/dictionaries/ab_test_expiries.yaml: The lifetime of the A/B test cookie. The value you choose depends on what kind of change you are making. If it is important that users always see a consistent version of the site (e.g. because you are making large changes to the navigation) then choose a lifetime which is significantly longer than the duration of your A/B test, such as 1 year. On the other hand, a shorter lifetime (such as 1 day) causes less lag when changing the B percentage, and might be more appropriate when testing something where consistency is less important from day-to-day, such as changing the order of search results.