You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Portal:Cloud VPS/Admin/Hiera

From Wikitech-static
Jump to navigation Jump to search

This page contains information on how hiera data is managed in Cloud VPS, which is a bit different from the main production hiera/puppet workflow.

Precedence of hiera keys

Hiera keys may come from different backends, not only puppet hieradata files.

You can set hiera data by using Horizon or through diverse yaml-files in the operations/puppet and labs/private git repos. You can see the exact, always up-to-date resolution order at [2].

By default the hierarchy is searched using the following list top to bottom with a first match win policy. Also note the following considerations when reading this list

  • cloudlib::httpyaml: is a custom backbend to pull data from to Horizon(either at the instance level, prefixes, or project level).
  • /etc/puppet/hieradata/: this is a checkout of the operations/puppet git repo
  • /etc/puppet/private/hieradata: this is a checkout of the labs/private git repo
  • /etc/puppet/secret/hieradata: this is a directory on the stand-alone puppet master which doesn't exist by default
  • %{::wmcs_deployment}: This refers to the openstack deployment currently eqiad1 or codfw1dev
  • %{::labsproject}: This refers to the openstack project e.g. deployment-prep
  • %{::hostname} This refers to the instance name e.g. tools-mail.

The following is a dump as of 2021-03-24.

hierarchy:
- cloudlib::httpyaml
- "/etc/puppet/hieradata/cloud/%{::wmcs_deployment}/%{::labsproject}/host/%{::hostname}.yaml"
- "/etc/puppet/hieradata/cloud/%{::wmcs_deployment}/%{::labsproject}/common.yaml"
- "/etc/puppet/hieradata/cloud/%{::wmcs_deployment}.yaml"
- "/etc/puppet/secret/hieradata/labs/%{::labsproject}/common.yaml"
- "/etc/puppet/secret/hieradata/%{::labsproject}.yaml"
- "/etc/puppet/secret/hieradata/labs.yaml"
- "/etc/puppet/private/hieradata/labs/%{::labsproject}/common.yaml"
- "/etc/puppet/private/hieradata/%{::labsproject}.yaml"
- "/etc/puppet/private/hieradata/labs.yaml"
- "/etc/puppet/hieradata/common.yaml"
- "/etc/puppet/secret/hieradata/common.yaml"
- "/etc/puppet/private/hieradata/common.yaml"

Note that providing Hiera settings per role is not possible on Cloud Services.

Only users with the projectadmin role can edit hiera data in Horizon and on Wikitech. Everyone can propose a patch in gerrit to change the hiera data in git, which can then be merged by all of SRE/Ops.

Puppet enc system

The enc mechanism is a custom made API that serves up hiera config (it's what horizon talks to). See the image below for a quick overview.

File:Cloud puppet enc.png
Overview of the ENC system

ENC API

The ENC API is powered by a Flask microservice running on small VMs in the cloudinfra project. It makes two types of endpoints accessible to different instances, one with read-write permissions and one with only read ones. It uses a database on cloudinfra-db*.cloudinfra.eqiad1.wikimedia.cloud to store the hiera and roles information.

The code for the service is here.

The read only endpoint endpoint is exposed via Nginx on port 8100. It rejects all requests with a status code not equal to GET. This endpoint is used by various puppetmasters to query node information.

The writable endpoint is exposed directly from uwsgi on port 8101. It is secured by Ferm firewalls and app-layer code for IP-based access control, although migration to Keystone authentication tokens is planned. This endpoint is used by Horizon, wmfsink hosted on the cloudcontrol nodes and manual operations from cloudcontrol nodes.

Horizon UI

The primary way of interacting with the ENC backend is via the custom Horizon panel.

Note that the dashboard mirrors all writes to the cloud/instance-puppet.git Gerrit repository. That repository is not read by the infrastructure itself but is useful if you're trying to grep for a particular setting.

cli

There's a small cli that will allow interacting with the enc api installed on all the control nodes (cloudcontrol*):


root@cloudcontrol1003:~# wmcs-enc-cli --help
 usage: wmcs-enc-cli [-h] [--enc-url ENC_URL]
                     [--openstack-project OPENSTACK_PROJECT]
                     {get_node_consolidated_info,get_node_info,get_prefix_hiera,get_project_hiera,set_prefix_hiera}
                     [params [params ...]]
 positional arguments:
   {get_node_consolidated_info,get_node_info,get_prefix_hiera,get_project_hiera,set_prefix_hiera}
   params                Any parameters needed for the action chosen.
 optional arguments:
   -h, --help            show this help message and exit
   --enc-url ENC_URL     Full url to the enc, for example
                         http://puppet-enc.cloudinfra.wmcloud.org:8101/v1
   --openstack-project OPENSTACK_PROJECT

The code for it is hosted here. Note that it does not sync changes to the cloud/instance-puppet.git Gerrit repository.

puppet-enc

This is a cli that puppet runs to retrieve the actual node ENC data [1]. It's a wrapper on top of the read-only enc api endpoint that just transforms the output format to something puppet understands.

The code for it is hosted here. Note that it uses the configuration file /etc/puppet-enc.yaml to retrieve the host for the ENC api endpoint (instead of using Keystone service discovery).

Wikitech integration

In the past you could configure hieradata in Wikitech, but that is no longer possible. The person writing this text does not know any further details, if you have them, feel free to fill them here!

See also

References

  1. [1]Puppet external node classifier docs