Jump to content

Single Version MediaWiki/Documentation

From Wikitech
This page is currently a draft.
Material may not yet be complete, information may presently be omitted, and certain parts of the content may be subject to radical, rapid alteration. More information pertaining to this may be available on the talk page.

This page documents how to add HTTP routing for Single Version MediaWiki to an existing MediaWiki deployment on mw-on-k8s. Below we have a excerpt from helmfile.yaml (the rest is omitted for brevity). The definition of a release is identical to what already exists for the main and/or canary releases.

hemlfile.yaml
environments:
  eqiad:
    values:
      - releases: [main, prometheus, group0, group1, group2]
  codfw:
    values:
      - releases: [main, prometheus, group0, group1, group2]
releases:
  - name: group0
    <<: *default
  - name: group1
    <<: *default
  - name: group2
    <<: *default

The 3 helm releases, due to how the rest of helmfile.yaml is structured (not shown here) will source the files values-<release-name>, hence values-group0.yaml, values-group1.yaml, values-group2.yaml

So, add values files for the 3 different groups. Note:

  • That group0 carries right now the information about the gateway and the HTTP routing. This isn't something to do with the group0 itself, but one of the groups does need to carry it, so group0 is arbitrarily chosen.
  • That we don't have a nodePort cause we don't need it for any of the 3 groups
  • That each group has it's own resources allocated, per the amount of rps expected to reach it
  • The important part of the YAML is httproutes. That is where the entire routing logic is contained.
  • destinationrulehosts is where the destinations of the 3 groups are defined. They need to match the ones defined in httproutes[].route otherwise traffic is routed to null and the connection to the client reset. We are utilizing the Kubernetes Service names here in order to allow load balancing to be performed by kube-proxy, which is a proven component in our infrastructure

We 'll use mw-wikifunctions for this example as it is currently in production. Couple of more notes, specific to this deployment.

  • wikifunctions.org is not the canonical name. All it does is redirect to www.wikifunctions.org
  • Since only wikifunctions.org and www.wikifunctions.org domains are routed to the dedicated mw-wikifunctions deployments, there is no other wiki to route to. So we did a small trick here. wikifunctions.org is being routed to group0, and www.wikifunctions.org is being routed to group1 helm release. The latter matches reality, the former, not, but it's the best we can do right now.
values-group0.yaml
service:
  nodePort: false
resources:
  # This will only redirect to www.wikifunctions.org, no need for a lot of resources
  replicas: 2

# Ingress will only be defined in this release, the others will share
ingress:
  enabled: true
  gatewayHosts:
    extraFQDNs:
      - mw-wikifunctions-ro.discovery.wmnet
      # Our main stuff for this service
      - '*.wikifunctions.org'
      - 'wikifunctions.org'
      # And now everything we receive traffic for completeness
      - '*.wikipedia.org'
      - '*.mediawiki.org'
      - '*.wikibooks.org'
      - '*.wikidata.org'
      - '*.wikimedia.org'
      - '*.wikimediafoundation.org'
      - '*.wikinews.org'
      - '*.wikiquote.org'
      - '*.wikisource.org'
      - '*.wikiversity.org'
      - '*.wikivoyage.org'
      - '*.wiktionary.org'
      - '*.wmfusercontent.org'
      - 'mediawiki.org'
      - 'w.wiki'
      - 'wikibooks.org'
      - 'wikidata.org'
      - 'wikimedia.org'
      - 'wikimediafoundation.org'
      - 'wikinews.org'
      - 'wikiquote.org'
      - 'wikisource.org'
      - 'wikiversity.org'
      - 'wikivoyage.org'
      - 'wiktionary.org'
      - 'wmfusercontent.org'
      - 'wikipedia.org'
  httproutes:
    # We send on purpose traffic to this one. It will redirect to www.wikifunctions.org anyway
    - name: group0
      match:
        - authority:
            exact: wikifunctions.org
      route:
        - destination:
            host: mediawiki-group0-tls-service.mw-wikifunctions.svc.cluster.local
    # This is where we 'll actually send traffic to
    - name: group1
      match:
        - authority:
            exact: www.wikifunctions.org
      route:
        - destination:
            host: mediawiki-group1-tls-service.mw-wikifunctions.svc.cluster.local
    # default everything else to group2
    - name: group2
      route:
        - destination:
            host: mediawiki-group2-tls-service.mw-wikifunctions.svc.cluster.local
  destinationrulehosts:
    - mediawiki-group0-tls-service.mw-wikifunctions.svc.cluster.local
    - mediawiki-group1-tls-service.mw-wikifunctions.svc.cluster.local
    - mediawiki-group2-tls-service.mw-wikifunctions.svc.cluster.local

Below we also include the other 2 files, which are much simpler

values-group1.yaml
service:
  nodePort: false
resources:
  # Same amount of resources as the main release
  replicas: 6

And group2, which for this example (wikifunctions) serves 0 requests.

values-group2.yaml
service:
  nodePort: false
resources:
  # This is the fallback for anything else, shouldn't see any traffic, don't
  # use a lot of resources
  replicas: 1