|
|
TPA uses [Puppet](https://puppet.com/) to manage all servers it operates. It handles
|
|
|
most of the configuration management of the base operating system and
|
|
|
some services. It is *not* designed to handle ad hoc tasks, for which
|
|
|
some services. It is *not* designed to handle ad-hoc tasks, for which
|
|
|
we favor the use of [fabric](howto/fabric).
|
|
|
|
|
|
[[_TOC_]]
|
... | ... | @@ -366,7 +366,7 @@ As a bonus, this query will show the number of hosts running each release: |
|
|
## Running Puppet everywhere
|
|
|
|
|
|
There are many ways to [run a command on all hosts (see next
|
|
|
section)][], but the TL;DR: is to basicaully use [cumin](howto/cumin)
|
|
|
section)][], but the TL;DR: is to basically use [cumin](howto/cumin)
|
|
|
and run this command:
|
|
|
|
|
|
[run a command on all hosts (see next section)]: #batch-jobs-on-all-hosts
|
... | ... | @@ -671,11 +671,11 @@ the time of writing: |
|
|
|
|
|
* Exported resources
|
|
|
* PuppetDB lookups
|
|
|
* Puppet Query Languaeg (PQL)
|
|
|
* Puppet Query Language (PQL)
|
|
|
* LDAP lookups
|
|
|
* Hiera lookups
|
|
|
|
|
|
This section walks through how each method method works, outlining the
|
|
|
This section walks through how each method works, outlining the
|
|
|
advantage/disadvantage of each.
|
|
|
|
|
|
### Exported resources
|
... | ... | @@ -772,7 +772,7 @@ case, you should use LDAP or Hiera lookups. |
|
|
Note that this could also be implemented with a `concat` exported
|
|
|
resource, but much harder because you would need some special case
|
|
|
when no resource is exported (to avoid adding the `deny`) and take
|
|
|
into account that other configuratinos might also be needed in the
|
|
|
into account that other configurations might also be needed in the
|
|
|
file. It would have the same security and expiry issues anyways.
|
|
|
|
|
|
### Puppet query language
|
... | ... | @@ -797,7 +797,7 @@ of the `query_nodes` call, above: |
|
|
|
|
|
It seems like I did something wrong, because that returned an empty
|
|
|
array. I could not figure out how to debug this, and apparently I
|
|
|
neded more functions (like `map` and `filter`) to get what I wanted
|
|
|
needed more functions (like `map` and `filter`) to get what I wanted
|
|
|
(see [this gist](https://gist.github.com/bastelfreak/b9620fa1892ebcc659c442b115db34f9)). I gave up at that point: the `puppetdbquery`
|
|
|
abstraction is much cleaner and usable.
|
|
|
|
... | ... | @@ -875,7 +875,7 @@ refers to the following data structure in `hiera/common.yaml`: |
|
|
|
|
|
The key point with Hiera is that it's a "hierarchical" data structure,
|
|
|
so each host can have its own override. So in theory, the above keys
|
|
|
could be overriden per host. Similarly, the IP address information for
|
|
|
could be overridden per host. Similarly, the IP address information for
|
|
|
each host could be stored in Hiera instead of LDAP. But in practice,
|
|
|
we do not currently do this and the per-host information is limited.
|
|
|
|
... | ... | @@ -1054,7 +1054,7 @@ authority (CA). |
|
|
As mentioned in the [installation section](#installation), the Puppet server
|
|
|
assumes a few components (namely [LDAP](ldap), [Nagios](nagios), [Let's
|
|
|
Encrypt](tls) and auto-ca) feed information into it. This is also
|
|
|
detailed in the sections below. In particular, Puppet consistutes a
|
|
|
detailed in the sections below. In particular, Puppet acts as a
|
|
|
duplicate "source of truth" for some information about servers. For
|
|
|
example, LDAP has a "purpose" field describing what a server is for,
|
|
|
but Puppet also has the concept of a role, attributed through Hiera
|
... | ... | @@ -1381,8 +1381,8 @@ certificates in use internally and which are deployed directly in |
|
|
|
|
|
The Puppet server also manages an internal CA which we informally call
|
|
|
"auto-ca". Those certificates are internal in that they are used to
|
|
|
authentify nodes to each other, not to the public. They are used, for
|
|
|
example, to encrypt connexions between mail servers (in Postfix) and
|
|
|
authenticate nodes to each other, not to the public. They are used, for
|
|
|
example, to encrypt connections between mail servers (in Postfix) and
|
|
|
[backup servers](backup) (in Bacula).
|
|
|
|
|
|
The auto-ca deploys those certificates directly inside the Puppet
|
... | ... | @@ -1437,7 +1437,7 @@ maximum of 90 days or 1GB, whichever comes first (configured in |
|
|
`/etc/puppetdb/logback.xml`). The other logs are sent to `syslog`, and
|
|
|
usually end up in `daemon.log`.
|
|
|
|
|
|
Puppet should hold minimal personnally idenfiable information, like
|
|
|
Puppet should hold minimal personally identifiable information, like
|
|
|
user names, user public keys and project names.
|
|
|
|
|
|
## Other documentation
|
... | ... | @@ -1758,7 +1758,7 @@ share code outside of the repository with anyone else because there is |
|
|
private data inside, but also because it doesn't follow the standard
|
|
|
role/profile/modules separation that makes collaboration possible at
|
|
|
all. To work around that, I designed a workflow where we locally clone
|
|
|
subrepos as needed, but this is clunky as it requies to commit every
|
|
|
subrepos as needed, but this is clunky as it requires to commit every
|
|
|
change twice: one for the subrepo, one for the parent.
|
|
|
|
|
|
Our giant monorepo also mixes all changes together which can be an pro
|
... | ... | |