dave2wave commented on issue #19:
URL:
https://github.com/apache/tooling-trusted-releases/issues/19#issuecomment-3474984193
I have a good design to try with a little help from ChatGPT:
Excellent 👍 — centralizing the user and group setup is the cleanest and most
maintainable approach.
You’ll have **one system user** (say `atr`) that owns all ATR Docker
directories and runs all containers, while each instance (dev, staging, etc.)
has its own config and ports.
Let’s restructure your Puppet code to reflect that clean separation of
concerns.
---
## 🧱 Final design
We’ll have:
* **Class** `tooling::atr_docker_container`
→ installs prerequisites (`git`, `docker`),
→ ensures the shared user and group exist (`atr`),
→ creates the shared base directories.
* **Defined type** `tooling::atr_docker_container::instance`
→ sets up each specific container instance (dev, staging, …),
→ uses the common `atr` user/group for ownership and runtime.
---
## 🧩 `tooling/manifests/atr_docker_container.pp`
```puppet
# tooling/manifests/atr_docker_container.pp
class tooling::atr_docker_container (
String $user = 'atr',
String $group = 'atr',
) {
package { 'git':
ensure => installed,
}
# Ensure the shared user and group exist
group { $group:
ensure => present,
}
user { $user:
ensure => present,
gid => $group,
shell => '/bin/bash',
home => "/home/${user}",
}
# Common base directories
file { ['/opt', '/var/opt']:
ensure => directory,
owner => $user,
group => $group,
mode => '0755',
}
# Example instances (can also be declared elsewhere)
tooling::atr_docker_container::instance { 'dev':
image_name => 'atr-dev',
app_host => 'tooling-vm-ec2-de.apache.org',
bind_address => '127.0.0.1:4443',
ssh_port => '2223',
tag => 'main',
user => $user,
group => $group,
}
tooling::atr_docker_container::instance { 'staging':
image_name => 'atr-staging',
app_host => 'release-test.apache.org',
bind_address => '127.0.0.1:8443',
ssh_port => '2222',
tag => 'release-1.0',
user => $user,
group => $group,
}
}
```
---
## 🧩 `tooling/manifests/atr_docker_container/instance.pp`
```puppet
# tooling/manifests/atr_docker_container/instance.pp
define tooling::atr_docker_container::instance (
String $image_name,
String $app_host,
String $bind_address,
String $ssh_port,
String $tag = 'main',
String $user,
String $group,
Hash $extra_env = {},
) {
$source_dir = "/opt/${image_name}"
$state_dir = "/var/opt/${image_name}"
file { [$source_dir, $state_dir]:
ensure => directory,
owner => $user,
group => $group,
mode => '0755',
}
vcsrepo { $source_dir:
ensure => latest,
provider => git,
source => 'https://github.com/apache/tooling-trusted-release.git',
revision => $tag,
user => $user,
require => [Package['git'], File[$source_dir]],
}
exec { "build-docker-image-${title}":
command => "make build IMAGE=${image_name}",
path => '/bin:/usr/bin',
cwd => $source_dir,
user => $user,
subscribe => Vcsrepo[$source_dir],
refreshonly => true,
notify => Docker::Run[$image_name],
}
# Merge environment variables (static + Hiera/eyaml-provided)
$base_env = [
"APP_HOST=${app_host}",
"BIND=${bind_address}",
"SSH_PORT=${ssh_port}",
]
$merged_env = $base_env + $extra_env.map |$k, $v| { "${k}=${v}" }
docker::run { $image_name:
image => $image_name,
pull_on_start => false,
remove_container_on_start => true,
volumes => ["${state_dir}:/opt/atr/state"],
net => 'host',
user => $user,
require => File[$state_dir],
env => $merged_env,
}
}
```
---
## 🧩 Hiera eyaml for secrets
You can continue using eyaml exactly as before:
```yaml
# data/common.eyaml
tooling::atr_docker_container::instance::dev::extra_env:
ATR_API_TOKEN: >
ENC[PKCS7,MIIBI...==]
tooling::atr_docker_container::instance::staging::extra_env:
ATR_API_TOKEN: >
ENC[PKCS7,MIIBJ...==]
```
These get automatically merged into `$extra_env` for each instance.
---
## ✅ Result
* All containers run as the same **non-root user** `atr`
* Centralized management of that user/group
* Each instance still independent in configuration
* Clean separation of common setup (class) vs. per-instance logic (defined
type)
* Secrets continue to be injected securely via Hiera eyaml
---
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
