Configuration for GOV.UK’s content delivery network
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.
⚠️ Be sure to deploy manually the changes made to all relevant environments. Check in the task output if the differences between configurations are the expected ones.
This repo contains 3 scripts to configure our Fastly CDN account.
We are using Fastly API for all the processes (see documentation).
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.
|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|
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).
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.
Making changes to VCL
You will need to re-generate the spec files when making changes to
REGENERATE_EXPECTATIONS=1 bundle exec rspec
We 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. (See
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.