diff --git a/src/content/docs.html b/src/content/docs.html index 5e6812d..bd0523d 100644 --- a/src/content/docs.html +++ b/src/content/docs.html @@ -162,7 +162,7 @@ description: "How Enroll works: harvest, manifest, modes, and configuration."
Keep in mind that a lot of software config files are also good candidates for being Jinja templates with abstracted vars for separate hosts.

-
Enroll does use my companion tool JinjaTurtle if it's installed, but JinjaTurtle only recognises certain types of files (.ini style, .json, .xml, .yaml, .toml, but not special ones like Nginx or Apache conf files which have their own special syntax). When Enroll cannot turn a config file into a template, it copies the raw file instead. JinjaTurtle templating is currently most useful for Ansible output; Puppet and Salt output stay closer to raw managed files and target-native data.
+
Enroll does use my companion tool JinjaTurtle if it's installed, but JinjaTurtle only recognises certain types of files (.ini style, .json, .xml, .yaml, .toml, but not special ones like Nginx or Apache conf files which have their own special syntax). When Enroll cannot turn a config file into a template, it copies the raw file instead. JinjaTurtle creates Jinja2 templates for both Ansible and Salt, and because it's a cheerful turtle, it generates .erb templates if you're manifesting Puppet code, too!
@@ -265,7 +265,7 @@ description: "How Enroll works: harvest, manifest, modes, and configuration."

JinjaTurtle integration

-

If JinjaTurtle (one of my other projects) is installed, Enroll can also produce Jinja2 templates for ini/json/xml/toml-style config and extract variables cleanly into Ansible, instead of just storing the 'raw' files. Puppet and Salt output currently focus on raw managed files plus target-native data.

+

If JinjaTurtle (one of my other projects) is installed, Enroll can also produce Jinja2 templates for ini/json/xml/toml-style config and extract variables cleanly into Ansible and Salt, and even erb files for Puppet (as of version 0.5.5).

diff --git a/src/content/news/0-7-0.html b/src/content/news/0-7-0.html index e21d211..6051b50 100644 --- a/src/content/news/0-7-0.html +++ b/src/content/news/0-7-0.html @@ -18,20 +18,20 @@ summary: "Enroll can now render Puppet and Salt manifests alongside Ansible, det
-

Welcome to the first of Enroll's new, erm, news section! To celebrate, Enroll 0.7.0 has been released, and makes manifest rendering target-selectable based on your preferred config management tool! Ansible remains the default, but Puppet and Salt are now possible too (with a few small exceptions, read on).

+

Welcome to the first of Enroll's new, erm, news section! To celebrate, Enroll 0.7.0 has been released, and makes manifest rendering target-selectable based on your preferred config management tool! Ansible remains the default, but Puppet and Salt are now possible too.

-

Highlights

+

Highlights in 0.7.0

    -
  • --target puppet renders Puppet module/control-repo style output., and in --fqdn mode, renders per-host Hiera data.
    • -
  • --target salt renders Salt state trees and, in --fqdn mode, Salt pillar data. Since it's Python, it also will make use of JinjaTurtle (if it finds it on your $PATH) to render templates, just like Ansible!
    • +
  • Puppet support! --target puppet renders Puppet module/control-repo style output., and in --fqdn mode, renders per-host Hiera data.
    • +
  • Salt Stack support! --target salt renders Salt state trees and, in --fqdn mode, Salt pillar data.
  • Ansible works basically as it always did, and is the default, but you can specify --target ansible too. As usual, in --fqdn mode, specific artifacts end up in host_vars inventory folders rather than polluting the 'golden' roles.
    • -
  • All three config management manifest renderers derive from the same harvest state. You can rendered repeatedly into different config management tools without re-harvesting the host!
    • -
  • Single-site output tries to combine package/service data by their package manager's Section (or equivalent metadata), to reduce role/module/state sprawl.
    • +
  • All three config management manifest renderers derive from the same harvest state as a single source of truth. Evaluating how different config managers work? You can rendered repeatedly into different config management tools without re-harvesting the host!
    • +
  • Single-site output tries to combine package/service data by their package manager's Section (or equivalent metadata), to reduce role/module/state sprawl and speed up execution.
  • Flatpak and Snap detection!
  • Docker image detection!
-

Dry-run examples

+

Dry-run examples: choose your own config management adventure!

$ enroll harvest --out ./harvest
@@ -46,20 +46,26 @@ summary: "Enroll can now render Puppet and Salt manifests alongside Ansible, det
 $ salt-call --local --file-root ./salt/states state.apply test=True
+
+

I recommend using Salt 3008.1 - on Debian 13 I encountered annoying noisy Python errors with version 3007, which are unrelated to Enroll.

+

Bonus: since Salt uses Jinja2 templates, it will take advantage of my other tool JinjaTurtle, if it's on your PATH, just like Ansible does!

+ +

And because I didn't want Puppet users to feel left out, version 0.5.5 of JinjaTurtle (despite its name) also supports erb templates as well. This means Puppet templates will be generated if you have JinjaTurtle and there are viable config files for it, too!

+

New grouping behaviour in roles/modules

Did you find the number of manifested roles overwhelming?

-

Previously, Enroll created an Ansible role (or, now, a Puppet module or Salt role) for pretty much every 'package' it found. In some cases (especially on desktops) this could result in hundreds of roles. Technically fine, but overwhelming to look at!

+

Previously, Enroll created an Ansible role (or, now, a Puppet module or Salt role) for pretty much every 'package' it found. In some cases (especially on desktops) this could result in hundreds of roles. Technically fine, but overwhelming to look at! It also made the playbooks a bit slow to run. If you have fewer roles that 'loop' over packages to install and config files to manage, Ansible gets faster.

-

As of 0.7.0, where Enroll can read that package metadata, it groups related package and service snapshots by the package manager's Section category (or comparable backend metadata), to make it less noisy. For example, network-related packages and config files might end up in a role called net. Meanwhile, vim, nano might both appear in editors, and mutt and Thunderbird may be in mail.

+

As of 0.7.0, where Enroll can read that package metadata, it groups related package and service snapshots by the package manager's Section category (or comparable backend metadata), to make it less noisy. For example, network-related packages and config files might end up in a role called net. Meanwhile, vim, nano might both appear in editors, and mutt and Thunderbird may be in mail. It's easier on the eye, and it's quicker to run the playbook end to end!

-

If you're not a fan of this new layout, you can pass --no-common-roles to enforce the previous behaviour. Also, if you use --fqdn for host-specific data-driven output, the 'common' roles are disabled automatically, because it's then safer to avoid 'bleed in' of unnecessary package installation on other hosts from a role that otherwise 'assumes too much' for all hosts.

+

Hello, opinions. If you're not a fan of this new layout, you can pass --no-common-roles to enforce the previous behaviour. Also, if you use --fqdn for host-specific data-driven output, the 'common' roles are disabled automatically, because it's then safer to avoid 'bleed in' of unnecessary package installation on other hosts from a role that otherwise 'assumes too much' for all hosts.

Flatpak and Snap detection

-

Beyond deb and rpm

-

When using Ansible, Enroll now attempts to detect Flatpak and Snaps present on the system. For Flatpaks, this includes user-specific Flatpaks as well as system-wide ones. Manifesting to Ansible will attempt to use the community.general collection to create Flatpak and Snap tasks to enforce the presence of those packages.

-

For now, unfortunately Flatpak/Snap manifesting will not occur for Puppet or Snap, just Ansible. Either way, the 'detection' still occurs at the harvest level, so you can still take advantage of that with other subcommands like enroll diff.

+

Because the state of package management in the 2020s is a circus...

+

Enroll now attempts to detect Flatpak and Snaps present on the system. For Flatpaks, this includes user-specific Flatpaks as well as system-wide ones. Manifesting in Ansible will attempt to use the community.general collection to create Flatpak and Snap tasks to enforce the presence of those packages.

+

Flatpak/Snap manifesting is also available for Puppet and Snap, but it's slightly cruder through the use of guarded cmd/exec statements - I found this keeps things simpler than having to add third party modules/extensions (and the state of extensions in Salt Stack right now, is a bit of a mess, IMO).

$ sudo ansible-playbook playbook.yml -i localhost, -c local --tags role_snap --diff
@@ -80,12 +86,45 @@ ok: [localhost] => (item={'channel': 'latest/stable', 'classic': False, 'dangero
-

Docker image detection

-

Continuing to sniff out bits from your system...

-

The harvest now detects the presence of Docker images, if it has permission. In particular, it detects the SHA256 of the Docker image. All three renderers (Ansible, Salt and Puppet) will attempt to enforce the presence of those Docker images. For Puppet, you may need the puppetlabs-docker module installed. There are details in the manifested README.md of the Puppet code. For Ansible, you may need the community.docker collection, but on Debian 13 I found that it was already present by default in the official ansible Debian packages.

- -

Please be aware that the Puppet and Salt renderers do not support the Flatpak/Snap package enforcement - only Ansible for now. You'll also need version 13+ of the community.general collection for this to work properly. A requirements.yml gets created with your manifest to help you install it if necessary.

+

Docker/Podman image detection

+

Because it works on your machine....

+

The harvest now detects the presence of container images, if the user has permission to call Docker or Podman. In particular, it detects the SHA256 of the image instead of relying on floating tags.

+

All three renderers (Ansible, Salt and Puppet) will attempt to enforce the presence of those Docker images per their precise SHA256 hash, if they were present in the harvest but not on the machine upon applying a manifest.

+

For Ansible, you may need the community.docker collection, but on Debian 13 I found that it was already present by default in the official ansible Debian packages.

+

For Ansible, if using Podman, you'll need 1.20.0 or later. Enroll creates a requirements.yml to make it easy for you: its README.md will guide you to run ansible-galaxy collection install -r requirements.yml before running the playbook.

+
+ 
$ ansible-playbook -i localhost, -c local playbook.yml --check --diff --tags role_container_images
+PLAY [Apply all roles on all hosts] *******************************************************************************************************************************************************************************
+
+TASK [Gathering Facts] ********************************************************************************************************************************************************************************************
+ok: [localhost]
+
+TASK [container_images : Pull Docker images by immutable registry digest] *****************************************************************************************************************************************
+ok: [localhost] => (item={'architecture': 'amd64', 'created': '2026-06-17T22:44:41.625799723Z', 'engine': 'docker', 'home': None, 'image_id': 'sha256:eaf6f386053efdf0ad30236a394b4460e3669006afc9eb1220ae2047f330cc9c', 'notes': [], 'os': 'linux', 'platform': 'linux/amd64', 'pull_ref': 'nginx@sha256:42f2d24ae18df9b5251d1cc45548085656d2335e9338fd150a24e415462d151f', 'repo_digests': ['nginx@sha256:42f2d24ae18df9b5251d1cc45548085656d2335e9338fd150a24e415462d151f'], 'repo_tags': ['nginx:latest'], 'scope': 'system', 'size': 161308134, 'source': 'docker image inspect', 'tag_aliases': [{'ref': 'nginx:latest', 'repository': 'nginx', 'tag': 'latest'}], 'user': None, 'variant': None})
+
+TASK [container_images : Tag Docker images with harvested tag aliases] ********************************************************************************************************************************************
+ok: [localhost] => (item=[{'architecture': 'amd64', 'created': '2026-06-17T22:44:41.625799723Z', 'engine': 'docker', 'home': None, 'image_id': 'sha256:eaf6f386053efdf0ad30236a394b4460e3669006afc9eb1220ae2047f330cc9c', 'notes': [], 'os': 'linux', 'platform': 'linux/amd64', 'pull_ref': 'nginx@sha256:42f2d24ae18df9b5251d1cc45548085656d2335e9338fd150a24e415462d151f', 'repo_digests': ['nginx@sha256:42f2d24ae18df9b5251d1cc45548085656d2335e9338fd150a24e415462d151f'], 'repo_tags': ['nginx:latest'], 'scope': 'system', 'size': 161308134, 'source': 'docker image inspect', 'user': None, 'variant': None}, {'ref': 'nginx:latest', 'repository': 'nginx', 'tag': 'latest'}])
+
+TASK [container_images : Pull system Podman images by immutable registry digest] **********************************************************************************************************************************
+ok: [localhost] => (item={'architecture': 'amd64', 'created': '2026-06-16T00:01:29.967161902Z', 'engine': 'podman', 'home': None, 'image_id': 'sha256:d529dd0c6e5597ac7e4a3e2dea65c3fcc6173f4cae713c409265c1dd9914a11b', 'notes': [], 'os': 'linux', 'platform': 'linux/amd64', 'pull_ref': 'docker.io/library/alpine@sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b', 'repo_digests': ['docker.io/library/alpine@sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b', 'docker.io/library/alpine@sha256:79ff19e9084a00eece421b2523fb93e22d730e2c0e525905de047e848e56d95f'], 'repo_tags': ['docker.io/library/alpine:latest'], 'scope': 'system', 'size': 8709729, 'source': 'podman image inspect', 'tag_aliases': [{'ref': 'docker.io/library/alpine:latest', 'repository': 'docker.io/library/alpine', 'tag': 'latest'}], 'user': None, 'variant': None})
+
+TASK [container_images : Tag system Podman images with harvested tag aliases] *************************************************************************************************************************************
+ok: [localhost] => (item=[{'architecture': 'amd64', 'created': '2026-06-16T00:01:29.967161902Z', 'engine': 'podman', 'home': None, 'image_id': 'sha256:d529dd0c6e5597ac7e4a3e2dea65c3fcc6173f4cae713c409265c1dd9914a11b', 'notes': [], 'os': 'linux', 'platform': 'linux/amd64', 'pull_ref': 'docker.io/library/alpine@sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b', 'repo_digests': ['docker.io/library/alpine@sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b', 'docker.io/library/alpine@sha256:79ff19e9084a00eece421b2523fb93e22d730e2c0e525905de047e848e56d95f'], 'repo_tags': ['docker.io/library/alpine:latest'], 'scope': 'system', 'size': 8709729, 'source': 'podman image inspect', 'user': None, 'variant': None}, {'ref': 'docker.io/library/alpine:latest', 'repository': 'docker.io/library/alpine', 'tag': 'latest'}])
+
+TASK [container_images : Pull user Podman images by immutable registry digest] ************************************************************************************************************************************
+skipping: [localhost]
+
+TASK [container_images : Tag user Podman images with harvested tag aliases] ***************************************************************************************************************************************
+skipping: [localhost]
+
+PLAY RECAP ********************************************************************************************************************************************************************************************************
+localhost                  : ok=5    changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0   
+
+
+ +

I did not use community extensions/modules for Docker in the Salt and Puppet renderers, because, well, they are god-awful (the Salt one simply doesn't work in 3008.1, and the Puppet one is non-idempotent and I would argue cruder in its approach to image management than a guarded Exec call can be (and is).

+

Other smaller changes

  • sysctl runtime parameters are now detected and would be written to /etc/sysctl.d/99-enroll.conf. Not all runtime parameters are supported.
    • @@ -95,7 +134,7 @@ ok: [localhost] => (item={'channel': 'latest/stable', 'classic': False, 'dangero

See you soon..

-

I'm off to try and write more tests - we're at 83% coverage in pytest, and we also run a stack of 'noop' executions for Ansible, Puppet and Salt too now, in CI.

+

I'm off to try and write more tests - we're at about 85% coverage in pytest, and we also run a stack of 'noop' executions for Ansible, Puppet and Salt too now, in CI.

Thanks to everyone who has reached out with suggestions, constructive criticism, and bug reports! You're helping make Enroll better for everyone.

@@ -104,7 +143,7 @@ ok: [localhost] => (item={'channel': 'latest/stable', 'classic': False, 'dangero
-
Targets
+
Target your preferred config manager
  • --target ansible (default)
  • --target puppet
    • @@ -118,6 +157,13 @@ ok: [localhost] => (item={'channel': 'latest/stable', 'classic': False, 'dangero Examples
+
+
There's more to Enroll!
+
+ Check out 'diff' mode + Explain/describe a harvest +
+