Our websites

Our websites

These are the websites managed by the web team.

If you would like to propose a change to a Canonical website you can make the change in to the copy for that content (private to Canonical empolyees). This will be flagged automatically to the webteam. You can also see open issues for ubuntu.com publicly on the repo for the project.

Our websites are deployed in one of two methods:

Kubernetes deployments

We are in the process of migrating all our sites to Kubernetes. Refer to the table at the bottom of this section for a list of sites that are definitely in Kubernetes.

Kubernetes configuration

We keep all the configuration for our Kubernetes services in a public deployment-configs repository.

We apply this configuration to the Kubernetes cluster using two Jenkins jobs:

Deploying to Kubernetes sites

First of all, ensure your changes are in the master branch of the relevant GitHub repository for the site.

NB: master should always be kept in a releasable state for all our website projects, so it’s always safe to run a release.

1. master is deployed to staging automatically

When work is merged into the master branch, the {staging-domain}-staging Jenkins job should be automatically kicked off (apart from a few exceptions). This job will:

  • Build the Docker image from master and push it to the Docker registry
  • Switch the staging site in Kubernetes to the new image (release to staging)

The new version should be visible on staging within a few minutes.

You can easily see which commit is on staging by visiting http://releases.demo.haus/|releases.demo.haus. If your new work seems to be taking longer than normal to land, then go and inspect the {staging-domain}-staging job in the Webteam’s Jenkaas.

Once your work is on staging, load the staging site to check that it looks correct.

(For reference, here’s the contents of the maas.io-staging job at the time of writing.)

2. Deploy the same image to production

Visit releases.demo.haus, and after checking your work is successfully visible on staging, click the “Release” button next to the site you want to release. This will take you to the {production-domain}-production build page with the appropriate image tag filled in. Click “Build”. This job will:

  • Switch the production site in Kubernetes to the new image (release to production)
  • Copy that same image to the “latest” tag, and upload that new tag to the Docker registry (purely for reference)

The version that’s on staging should be released to production within a few seconds. The site is now live! Check the live site to see that it looks right.

(For reference, here’s the contents of the maas.io-production job at the time of writing.)

Special cases

These sites are still hosted in Kubernetes, but differ slightly from the norm described above in important ways:

usn.ubuntu.com

The usn.ubuntu.com site is released to production every time a change is pushed to the repository. This is achieved by a webhook from launchpad.net, which triggers usn.ubuntu.com-production. usn.ubuntu.com doesn’t have a staging server.

There also exists a document outlining the architecture along with debugging tips, which may be useful for anyone trying to debug deployments to the site.

docs.ubuntu.com

The site at docs.ubuntu.com is made up of a few parts. Each part is deployed to separately:

Other documentation sites, e.g. maas.io/docs

Documentation sites like maas.io/docs are generated from a discourse instance. When the content is changed on the discourse docs category the changes are reflected after a few mins on the live site. Therefore docs content does not need a release of the site to update.

Juju deployments

To access staging sites, you must be either connected to the Bluefin network or the company VPN.

External sites

Important sites hosted outside our infrastructure:

Retired sites

Sites that we’ve taken down: