... | ... | @@ -1753,9 +1753,10 @@ configuration. |
|
|
|
|
|
TL;DR:
|
|
|
|
|
|
0. publish our repository (tpo/tpa/team#29387)
|
|
|
1. Use a control repository
|
|
|
2. Get rid of 3rdparty
|
|
|
3. Deploy with g10k
|
|
|
2. Get rid of `3rdparty`
|
|
|
3. Deploy with `g10k`
|
|
|
4. Authenticate with checksums
|
|
|
5. Deploy to branch-specific environments
|
|
|
6. Rename the default branch "production"
|
... | ... | @@ -1772,6 +1773,35 @@ and could be implemented once the new infrastructure stabilizes. |
|
|
|
|
|
What follows is an explanation and justification of each step.
|
|
|
|
|
|
### Publish our repository
|
|
|
|
|
|
Right now our Puppet repository is private, because there's
|
|
|
sensitive information in there. The goal of this step is to make sure
|
|
|
we can safely publish our repository without risking disclosing
|
|
|
secrets.
|
|
|
|
|
|
Secret data is currently stored in Trocla, and we should keep using it
|
|
|
for that purpose. That would avoid having to mess around splitting the
|
|
|
repository in multiple components in the short term.
|
|
|
|
|
|
This is the data that needs to be moved into Trocla at the time of writing:
|
|
|
|
|
|
* `modules/postfix/files/virtual` - email addresses
|
|
|
* `modules/postfix/files/access-1-sender-reject` and related - email addresses
|
|
|
* sudoers configurations?
|
|
|
* secrets in /etc/puppet (hopefully not in git, but just in case)
|
|
|
|
|
|
A full audit should be redone before this is completed.
|
|
|
|
|
|
The actual issues that need to be resolved to close this ticket are
|
|
|
really just 1 and 2, however: it just means we would need to push to
|
|
|
two repositories to get our code public. So as a temporary measure, we
|
|
|
would push the public repositories twice: once to the public git
|
|
|
repository (ie. here) and once to the private one. Eventually, we
|
|
|
would push directly with Puppet which, with access keys, would push
|
|
|
public repositories here. But that's not essential to close this
|
|
|
ticket, which is just about publishing our darn source code.
|
|
|
|
|
|
### Use a control repository
|
|
|
|
|
|
The base of the infrastructure is a [control-repo](https://puppet.com/docs/pe/latest/control_repo.html) ([example](https://github.com/puppetlabs/control-repo),
|
... | ... | @@ -1804,6 +1834,48 @@ modules". This has been suggested before in [issue 29387: publish our |
|
|
puppet repository](https://gitlab.torproject.org/tpo/tpa/team/-/issues/29387)) and is important for the `Puppetfile` to do its
|
|
|
job.
|
|
|
|
|
|
In other words, this is the checklist:
|
|
|
|
|
|
* [x] convert everything to hiera (#30020) - this requires creating `roles` for each machine (more or less) -- effectively done as far as this issue is concerned
|
|
|
* [ ] move current `modules/` into `site-modules/` and audit for private data
|
|
|
* [ ] move any private data into `hiera/`, currently known private data:
|
|
|
* `modules/postfix/files/virtual` - email addresses
|
|
|
* `modules/postfix/files/access-1-sender-reject` and related - email addresses
|
|
|
* sudoers configurations?
|
|
|
* secrets in /etc/puppet (hopefully not in git, but just in case)
|
|
|
* [ ] move `3rdparty` modules into `modules/`
|
|
|
* [ ] publish everything but `hiera/` as a new (secret) repository
|
|
|
|
|
|
Once this is done, the final picture will look like this in `/etc/puppet`:
|
|
|
|
|
|
* `hiera/` - private data. `machine -> role` assignements, secret
|
|
|
stuff like the alias file, machine location, price and other
|
|
|
similar metadata and details (see also legacy/trac#29816)
|
|
|
|
|
|
* `modules/` - equivalent of the current `3rdparty/` directory: fully
|
|
|
public, reusable code that's aimed at collaboration. mostly code
|
|
|
from the Puppet forge or our own repository if no equivalent there
|
|
|
|
|
|
* `site-modules/profiles/` - magic sauce on top of 3rd party
|
|
|
`modules/`, already created a few `modules/profiles/` for grafana
|
|
|
and prometheus, the profiles configure official 3rd party classes
|
|
|
with our site-specific criteria
|
|
|
|
|
|
* `site-modules/roles/` - abstract classes that regroup a few
|
|
|
profiles. for example `roles::monitoring` could currently include
|
|
|
`profiles::nagiosmaster`, `profiles::prometheus::server` and
|
|
|
`profiles::grafana` as an implementation
|
|
|
|
|
|
* `site-modules/MODULE/` - remaining custom modules that still need
|
|
|
to be published (by moving in their own repository and `modules/`
|
|
|
or by replacing with an existing module in `modules/`
|
|
|
|
|
|
This could all be done in the current repository, without creating a
|
|
|
new clean history one, but it would prepare us for that final
|
|
|
step. And that step would simply be to move `modules/`, `profiles/`,
|
|
|
and `roles/` into a public repository, while keeping `hiera/` private
|
|
|
in its own repository.
|
|
|
|
|
|
### Deploy with g10k
|
|
|
|
|
|
It seems clear that everyone is converging over the use of a
|
... | ... | |