Adds global.appConfig.cdnHost setting for chart deployments
What does this MR do?
Adds handling for a cdnHost
setting in global.appConfig
in order to set the gitlab.cdn_host
setting in the gitlab.yml configuration for chart deployments
Related issues
Closes #3078 (closed)
Testing
In order to have a functional CDN to test with:
- Set up a free CloudFlare Workers account
- Use a slightly modified version of the workers script listed in our External storage for static objects docs
Tested Worker Script
const CORS_HEADERS = {
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'GET, HEAD, OPTIONS',
'Access-Control-Allow-Headers': 'X-Csrf-Token, X-Requested-With',
}
const ORIGIN_HOSTNAME = 'gitlab.clusterdomain'
const CACHE_PRIVATE_OBJECTS = false
self.addEventListener('fetch', event => event.respondWith(handle(event)))
async function handle(event) {
try {
let response = await verifyAndHandle(event);
// responses returned from cache are immutable, so we recreate them
// to set CORS headers
response = new Response(response.body, response)
response.headers.set('Access-Control-Allow-Origin', '*')
return response
} catch (e) {
return new Response('An error occurred!', {status: e.statusCode || 500})
}
}
async function verifyAndHandle(event) {
if (event.request.method === 'OPTIONS') {
return handleOptions(event.request)
}
return handleRequest(event)
}
function handleOptions(request) {
// Make sure the necessary headers are present
// for this to be a valid pre-flight request
if (
request.headers.get('Origin') !== null &&
request.headers.get('Access-Control-Request-Method') !== null &&
request.headers.get('Access-Control-Request-Headers') !== null
) {
// Handle CORS pre-flight request
return new Response(null, {
headers: CORS_HEADERS,
})
} else {
// Handle standard OPTIONS request
return new Response(null, {
headers: {
Allow: 'GET, HEAD, OPTIONS',
},
})
}
}
async function handleRequest(event) {
let cache = caches.default
let url = new URL(event.request.url)
let headers = new Headers(event.request.headers)
url.host = ORIGIN_HOSTNAME
console.log(url)
let request = new Request(url, { headers: headers })
let cached_response = await cache.match(request)
let is_conditional_header_set = headers.has('If-None-Match')
if (cached_response) {
return cached_response
}
// We don't want to override If-None-Match that is set on the original request
if (cached_response && !is_conditional_header_set) {
headers.set('If-None-Match', cached_response.headers.get('ETag'))
}
let response = await fetch(request, {headers: headers })
console.log(response)
if (response.status == 304) {
if (is_conditional_header_set) {
return response
} else {
return cached_response
}
} else if (response.ok) {
response = new Response(response.body, response)
// cache.put will never cache any response with a Set-Cookie header
response.headers.delete('Set-Cookie')
if (CACHE_PRIVATE_OBJECTS) {
response.headers.delete('Cache-Control')
}
event.waitUntil(cache.put(request, response.clone()))
}
return response
}
- Deploy a Cloud Native Gitlab installation using a local helm chart - setting
global.appConfig.cdnHost
to the value of your worker url:name.account.workers.dev
helm upgrade --install gitlab . --timeout 600s \
--set global.image.pullPolicy=Always \
--set global.hosts.domain=gitlab.clusterdomain \
--set certmanager-issuer.email=email@gitlab.com \
--set global.appConfig.cdnHost=https://name.account.workers.dev \
--debug
- Observe that asset requests are made to
name.account.workers.dev
after rollout - Running
gitlab-rails console
in the Toolbox Pod should show your configuredcdn_host
inSettings.gitlab['cdn_host']
as well asRails.application.config.action_controller.asset_host
A functioning CDN is not actually required, the application UI will just be in a broken state trying to generate requests for .js
files and other assets to http[s]://name.account.workers.dev/assets/[asset]
- but it can be used to verify that the asset_host
was set appropriately from the configured global.appConfig.cdnHost
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion.
Required
-
Merge Request Title and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes -
Documentation created/updated -
Tests added -
Integration tests added to GitLab QA -
Equivalent MR/issue for omnibus-gitlab opened ( Issue / MR )