Version information
This version is compatible with:
- Puppet Enterprise 2023.8.x, 2023.7.x, 2023.6.x, 2023.5.x, 2023.4.x, 2023.3.x, 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x, 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x, 2017.2.x, 2016.4.x
- Puppet >= 4.10.0 < 9.0.0
- Archlinux, CentOS, Debian, OracleLinux, RedHat, Fedora, Ubuntu
Start using this module
Add this module to your Puppetfile:
mod 'southalc-podman', '0.7.6'
Learn more about managing modules with a PuppetfileDocumentation
podman
Table of Contents
- Description
- Setup - Getting started with podman
- Usage - Configuration options and additional functionality
- Examples - Example configurations
- Limitations - OS compatibility, etc.
- Development - Guide for contributing to the module
Description
Podman enables running standard docker containers without the usual docker daemon. This has some benefits from a security perspective, with the key point of enabling containers to run as an unprivileged user. Podman also has the concept of a 'pod', which is a shared namespace where multiple containers can be deployed and communicate with each other over the loopback address of '127.0.0.1'.
Podman version 4.4 and later include support for quadlets that enable managing containers directly with systemd unit files and services. This greatly simplies managing podman services and is now supported by this module with the new 'quadlet' defined type that manages the systemd unit files and resulting services.
The defined types 'pod', 'image', 'volume', 'secret' and 'container' are essentially wrappers around the respective podman "create"
commands (podman <type> create
). The defined types support all flags for the command, but require them to be expressed
using the long form (--env
instead of -e
). Flags that don't require values should set the value to undef (use ~
or
null
in YAML). Flags that are used more than once should be expressed as an array. The Jenkins example configuration
below demonstrates some of this in the flags
and service_flags
hashes.
Setup
The module installs packages including 'podman', 'skopeo', and optionally 'podman-docker'. The 'podman' package provides core functionality for running containers, while 'skopeo' is used to check for container image updates. The 'podman-docker' package provides a 'docker' command for those that are used to typing 'docker' instead of 'podman' (the 'podman' command is purposefully compatible with 'docker').
Simply including the module is enough to install the packages. There is no service associated with podman, so the module just installs the packages. Management of 'pods', 'images', 'volumes', 'containers' and 'quadlets' is done using defined types. The module's defined types are all implemented in the main 'podman' class, allowing resources to be declared as hiera hashes. See the reference for usage of the defined types.
Usage
Assign the module to node(s):
include podman
With the module assigned you can manage podman resources using hiera data. When podman defined types are used with the user
parameter the resources will be owned by the defined user to support rootless containers. Using rootless containers this
way also enables 'loginctl enable-linger' on the user so rootless containers can start and run automatically under the assigned
user account when the system boots.
The module implements quadlet support by allowing the systemd unit file to be represented as a hash. The only quirk with this is that systemd unit files can have sections with duplicate keys while hashes must have unique keys. To work around this you can express hash keys with an array of values to producce the desired systemd unit file. The following hiera data shows this with the 'PublishPort' key. Note that the rootless "jenkins" user must also be managed as a puppet resource with a UID and valid subuid/subgid mappings - see the last example here for those resources.
podman::quadlets:
jenkins-v0:
quadlet_type: "volume"
user: jenkins
settings:
Install:
WantedBy: jenkins.service
jenkins:
user: jenkins
settings:
Container:
Image: 'docker.io/jenkins/jenkins:lts'
PublishPort:
- '8080:8080'
- '5000:5000'
Environment: 'JENKINS_OPTS="--prefix=/jenkins"'
Volume: "systemd-jenkins-v0:/var/jenkins_home"
Service:
TimeoutStartSec: 300
Unit:
Requires: "jenkins-v0-volume.service"
General podman and systemd notes
Be aware of how to work with podman and systemd user services when running rootless containers. The systemd and podman commands rely on the 'XDG_RUNTIME_DIR' environment variable that is normally set during login by pam_systemd. When you switch users this value will likely need to be set in the shell as follows:
su - <container_user>
export XDG_RUNTIME_DIR=/run/user/$(id -u)
Systemd user services use the same 'systemctl' commands, but with the --user
flag. As the container user with the environment
set, you an run podman and 'systemctl' commands.
podman container list [-a]
systemctl --user status podman-<container_name>
containerd configuration
This module also contains minimal support for editing the containerd
configuration files that control some of the lower level
settings for how containers are created. Currently, the only supported configuration files are /etc/containers/storage.conf
and /etc/containers/containers.conf
. You
should be able to set any of the settings with those files using the $podman::storage_options
and $podman::containers_options
parameters respectively. For example (if using Hiera):
podman::storage_options:
storage:
rootless_storage_path: '"/tmp/containers-user-$UID/storage"'
podman::containers_options:
engine:
cgroup_manager: '"cgroupfs"'
Note the use of double quotes inside single quotes above. This is due to the way the puppetlabs/inifile module works currently.
Examples
The following example is a hiera-based role that leverages the types module to manage some dependent resources, then uses this module to deploy a rootless Jenkins container. Note that the environment here is using hiera lookup for class assignments. The example will perform the following configuration:
- Create the
jenkins
user, group, and home directory using the types module - Manage the
/etc/subuid
and/etc/subgid
files, creating entries for thejenkins
user - Use
loginctl
toenable-linger
on the 'jenkins' user so the user's containers can run as a systemd user service - Creates volume
jenkins
owned by userjenkins
- Creates container
jenkins
from the defined image source owned by userjenkins
- Creates secret
db_pass
with secret version and gives it to jenkins container as an environment variable. - Sets container flags to label the container, publish ports, and attach the previously created
jenkins
volume - Set service flags for the systemd service to timeout at 60 seconds
- A systemd service
podman-<container_name>
is created, enabled, and started that runs as a user service - The container will be re-deployed any time the image source digest does not match the running container image
because the default defined type parameter
podman::container::update
defaults totrue
- Creates a firewall rule on the host to allow connections to port 8080, which is published by the container. The rule
is created with the
firewalld_port
type from the firewalld module, using the types module again so it can be defined entirely in hiera.
---
# Hiera based role for Jenkins container deployment
classes:
- types
- podman
- firewalld
types::types:
- firewalld_port
types::user:
jenkins:
ensure: present
forcelocal: true
uid: 222001
gid: 222001
password: '!!'
home: /home/jenkins
types::group:
jenkins:
ensure: present
forcelocal: true
gid: 222001
types::file:
/home/jenkins:
ensure: directory
owner: 222001
group: 222001
mode: '0700'
require: 'User[jenkins]'
podman::manage_subuid: true
podman::subid:
'222001':
subuid: 12300000
count: 65535
podman::volumes:
jenkins:
user: jenkins
lookup_options:
podman::secret::secret:
convert_to: "Sensitive"
podman::secret:
db_pass:
user: jenkins
secret: very
label:
- version=20230615
podman::containers:
jenkins:
user: jenkins
image: 'docker.io/jenkins/jenkins:lts'
flags:
label:
- purpose=dev
publish:
- '8080:8080'
- '50000:50000'
volume: 'jenkins:/var/jenkins_home'
secret:
- 'db_pass,type=env,target=DB_PASS'
service_flags:
timeout: '60'
require:
- Podman::Volume[jenkins]
types::firewalld_port:
podman_jenkins:
ensure: present
zone: public
port: 8080
protocol: tcp
Several additional examples are in a separate github project, including a Traefik container configuration that enables SSL termination and proxy access to other containers running on the host, with a dynamic configuration directory enabling updates to proxy rules as new containers are added and/or removed.
Limitations
The module was written and tested with RedHat/CentOS, but should work with any distribution that uses systemd and includes the podman and skopeo packages
Development
I'd appreciate any feedback. To contribute to development, fork the source and submit a pull request.
Reference
Table of Contents
Classes
Public Classes
podman
: Manage containers, pods, volumes, and images with podman without a docker daemon
Private Classes
podman::install
: Install podman packagespodman::options
: edit container options in /etc/containerspodman::service
: Manage the podman.socket service
Defined types
podman::container
: manage podman container and register as a systemd servicepodman::image
: pull or remove container imagespodman::network
: Create a podman network with defined flagspodman::pod
: Create a podman pod with defined flagspodman::quadlet
: manage podman quadletspodman::rootless
: Enable a given user to run rootless podman containers as a systemd user service.podman::secret
: Manage a podman secret. Create and remove secrets, it cannot replace.podman::subgid
: Define an entry in the/etc/subgid
file.podman::subuid
: Manage entries in/etc/subuid
podman::volume
: Create a podman volume with defined flags
Classes
podman
Manage containers, pods, volumes, and images with podman without a docker daemon
Examples
Basic usage
include podman
A rootless Jenkins deployment using hiera
podman::subid:
jenkins:
subuid: 2000000
count: 65535
podman::volumes:
jenkins:
user: jenkins
podman::containers:
jenkins:
user: jenkins
image: 'docker.io/jenkins/jenkins:lts'
flags:
label:
- purpose=test
publish:
- '8080:8080'
- '50000:50000'
volume: 'jenkins:/var/jenkins_home'
service_flags:
timeout: '60'
require:
- Podman::Volume[jenkins]
Parameters
The following parameters are available in the podman
class:
podman_pkg
skopeo_pkg
buildah_pkg
podman_docker_pkg
compose_pkg
machinectl_pkg
podman_pkg_ensure
buildah_pkg_ensure
podman_docker_pkg_ensure
compose_pkg_ensure
machinectl_pkg_ensure
nodocker
storage_options
containers_options
rootless_users
enable_api_socket
manage_subuid
file_header
match_subuid_subgid
subid
pods
volumes
images
containers
networks
quadlets
podman_pkg
Data type: String
The name of the podman package (default 'podman')
Default value: 'podman'
skopeo_pkg
Data type: String
The name of the skopeo package (default 'skopeo')
Default value: 'skopeo'
buildah_pkg
Data type: String
The name of the buildah package (default 'buildah')
Default value: 'buildah'
podman_docker_pkg
Data type: String
The name of the podman-docker package (default 'podman-docker').
Default value: 'podman-docker'
compose_pkg
Data type: String
The name of the podman-compose package (default 'podman-compose').
Default value: 'podman-compose'
machinectl_pkg
Data type: String
The name of the machinectl package (default 'systemd-container').
Default value: 'systemd-container'
podman_pkg_ensure
Data type: Pattern[/^(\d+\.){2}\d+$/, /absent/, /installed/]
The ensure value for the podman package (default 'installed')
Default value: 'installed'
buildah_pkg_ensure
Data type: Enum['absent', 'installed']
The ensure value for the buildah package (default 'absent')
Default value: 'absent'
podman_docker_pkg_ensure
Data type: Enum['absent', 'installed']
The ensure value for the podman docker package (default 'installed')
Default value: 'installed'
compose_pkg_ensure
Data type: Pattern[/^(\d+\.){2}\d+$/, /absent/, /installed/]
The ensure value for the podman-compose package (default 'absent')
Default value: 'absent'
machinectl_pkg_ensure
Data type: Enum['absent', 'installed']
The ensure value for the machinectl package (default 'installed')
Default value: 'installed'
nodocker
Data type: Enum['absent', 'file']
Should the module create the /etc/containers/nodocker
file to quiet Docker CLI messages.
Values should be either 'file' or 'absent'. (default is 'absent')
Default value: 'absent'
storage_options
Data type: Hash
A hash containing any storage options you wish to set in /etc/containers/storage.conf
Default value: {}
containers_options
Data type: Hash
A hash containing any containers options you wish to set in /etc/containers/containers.conf
Default value: {}
rootless_users
Data type: Array
An array of users to manage using podman::rootless
Default value: []
enable_api_socket
Data type: Boolean
The enable value of the API socket (default false
)
Default value: false
manage_subuid
Data type: Boolean
Should the module manage the /etc/subuid
and /etc/subgid
files (default is false)
The implementation uses concat fragments to build
out the subuid/subgid entries. If you have a large number of entries you may want to manage them
with another method. You cannot use the subuid
and subgid
defined types unless this is true
.
Default value: false
file_header
Data type: String
Optional header when manage_subuid
is true. Ensure you include a leading #
.
Default file_header is # FILE MANAGED BY PUPPET
Default value: '# FILE MANAGED BY PUPPET'
match_subuid_subgid
Data type: Boolean
Enable the subid
parameter to manage both subuid and subgid entries with the same values.
This setting requires manage_subuid
to be true
or it will have no effect.
(default is true)
Default value: true
subid
Data type: Hash
A hash of users (or UIDs) with assigned subordinate user ID number and an count.
Implemented by using the subuid
and subgid
defined types with the same data.
Hash key subuid
is the subordinate UID, and count
is the number of subordinate UIDs
Default value: {}
pods
Data type: Hash
A hash of pods to manage using podman::pod
Default value: {}
volumes
Data type: Hash
A hash of volumes to manage using podman::volume
Default value: {}
images
Data type: Hash
A hash of images to manage using podman::image
Default value: {}
containers
Data type: Hash
A hash of containers to manage using podman::container
Default value: {}
networks
Data type: Hash
A hash of networks to manage using podman::network
Default value: {}
quadlets
Data type: Hash
A hash of quadlets to manage using podman::quadlet
Default value: {}
Defined types
podman::container
manage podman container and register as a systemd service
Examples
podman::container { 'jenkins':
image => 'docker.io/jenkins/jenkins',
user => 'jenkins',
flags => {
publish => [
'8080:8080',
'50000:50000',
],
volume => 'jenkins:/var/jenkins_home',
},
service_flags => { timeout => '60' },
}
Parameters
The following parameters are available in the podman::container
defined type:
image
Data type: Optional[String]
Container registry source of the image being deployed. Required when
ensure
is present
but optional when ensure
is set to absent
.
Default value: undef
user
Data type: Optional[String]
Optional user for running rootless containers. For rootless containers, the user must also be defined as a puppet resource that includes at least 'uid', 'gid', and 'home' attributes.
Default value: undef
flags
Data type: Hash
All flags for the 'podman container create' command are supported via the
'flags' hash parameter, using only the long form of the flag name. The
container name will be set as the resource name (namevar) unless the 'name'
flag is included in the flags hash. If the flags for a container resource
are modified the container will be destroyed and re-deployed during the
next puppet run. This is achieved by storing the complete set of flags as
a base64 encoded string in a container label named puppet_resource_flags
so it can be compared with the assigned resource state.
Flags that can be used more than once should be expressed as an array. For
flags which take no arguments, set the hash value to be undef. In the
YAML representation you can use ~
or null
as the value.
Default value: {}
service_flags
Data type: Hash
When a container is created, a systemd unit file for the container service is generated using the 'podman generate systemd' command. All flags for the command are supported using the 'service_flags' hash parameter, again using only the long form of the flag names.
Default value: {}
command
Data type: Optional[String]
Optional command to be used as the container entry point.
Default value: undef
ensure
Data type: Enum['present', 'absent']
Valid values are 'present' or 'absent'
Default value: 'present'
enable
Data type: Boolean
Status of the automatically generated systemd service for the container. Valid values are 'running' or 'stopped'.
Default value: true
update
Data type: Boolean
When true
, the container will be redeployed when a new container image is
detected in the container registry. This is done by comparing the digest
value of the running container image with the digest of the registry image.
When false
, the container will only be redeployed when the declared state
of the puppet resource is changed.
Default value: true
ruby
Data type: Optional[Stdlib::Unixpath]
The absolute path to the ruby binary to use in scripts. The default path is '/opt/puppetlabs/puppet/bin/ruby' for Puppetlabs packaged puppet, and '/usr/bin/ruby' for all others.
Default value: undef
podman::image
pull or remove container images
Examples
podman::image { 'my_container':
image => 'my_container:tag',
flags => {
creds => 'USERNAME:PASSWORD',
},
}
Parameters
The following parameters are available in the podman::image
defined type:
image
Data type: String
The name of the container image to pull, which should be present in a configured container registry.
ensure
Data type: Enum['present', 'absent']
State of the resource must be either present
or absent
.
Default value: 'present'
flags
Data type: Hash
All flags for the 'podman image pull' command are supported, using only the long form of the flag name.
Default value: {}
user
Data type: Optional[String]
Optional user for running rootless containers. When using this parameter, the user must also be defined as a Puppet resource and must include the 'uid', 'gid', and 'home'
Default value: undef
exec_env
Data type: Array
Optional array of environment variables used when the container image is pulled. Useful for defining a proxy for downloads. For example: ["HTTP_PROXY=http://${proxy_fqdn}:3128", "HTTPS_PROXY=http://${proxy_fqdn}:3128"]
Default value: []
podman::network
Create a podman network with defined flags
Examples
podman::network { 'mnetwork':
driver => 'bridge',
internal => true,
}
Parameters
The following parameters are available in the podman::network
defined type:
ensure
Data type: Enum['present', 'absent']
State of the resource must be either 'present' or 'absent'.
Default value: 'present'
disable_dns
Data type: Boolean
Disables the DNS plugin for this network which if enabled, can perform container to container name resolution.
Default value: false
driver
Data type: Enum['bridge', 'macvlan']
Driver to manage the network.
Default value: 'bridge'
opts
Data type: Array[String]
A list of driver specific options.
Default value: []
gateway
Data type: Optional[String]
Define the gateway for the network. Must also provide the subnet.
Default value: undef
internal
Data type: Boolean
Restrict external access of this network.
Default value: false
ip_range
Data type: Optional[String]
Allocate container IP from a range. The range must be a complete subnet and in CIDR notation.
Default value: undef
labels
Data type: Hash[String,String]
A hash of metadata labels to set on the network.
Default value: {}
subnet
Data type: Optional[String]
The subnet in CIDR notation
Default value: undef
ipv6
Data type: Boolean
Enable IPv6 (dual-stack) networking.
Default value: false
user
Data type: Optional[String]
Optional user for creating rootless container networks. For rootless containers, the user must also be defined as a puppet resource that includes at least 'uid', 'gid', and 'home' attributes.
Default value: undef
podman::pod
Create a podman pod with defined flags
Examples
podman::pod { 'mypod':
flags => {
label => 'use=test, app=wordpress',
}
}
Parameters
The following parameters are available in the podman::pod
defined type:
ensure
Data type: Enum['present', 'absent']
State of the resource, which must be either 'present' or 'absent'.
Default value: 'present'
flags
Data type: Hash
All flags for the 'podman pod create' command are supported, using only the long form of the flag name. The resource name (namevar) will be used as the pod name unless the 'name' flag is included in the hash of flags.
Default value: {}
user
Data type: Optional[String]
Optional user for running rootless containers. When using this parameter, the user must also be defined as a Puppet resource and must include the 'uid', 'gid', and 'home'
Default value: undef
podman::quadlet
manage podman quadlets
Examples
podman::quadlet { 'jenkins':
user => 'jenkins',
settings => {
Unit => {
Description => "Jenkins container",
},
Container => {
Image => 'docker.io/jenkins/jenkins:latest',
PublishPort => [
'5000:5000',
'8080:8080',
],
Volume => 'jenkins:/var/jenkins_home',
},
Service => {
TimeoutStartSec => '300',
},
},
}
Parameters
The following parameters are available in the podman::quadlet
defined type:
ensure
Data type: Enum['present', 'absent']
Valid values are 'present' or 'absent'
Default value: 'present'
user
Data type: String
A username for running rootless containers. The user must also be defined as a puppet resource that includes at least 'uid', 'gid', and 'home' attributes. The default value is "root" and results in root containers and resources.
Default value: 'root'
quadlet_type
Data type:
Enum['container',
'volume',
'network',
'build',
'pod',
'kube'
]
Must be one of the supported quadlet types: "container", "volume", "network", "build", "pod", or "kube". Default is "container"
Default value: 'container'
settings
Data type: Hash
A hash that represents the systemd unit file that will be managed for the podman quadlet. No sanity checking is done on this hash, so invalid values can result in a service that fails to start, but this also allows full configuration of any service or container setting now and in the future without needed to go back and update the module.
Default value: {}
defaults
Data type: Hash
A hash of values that's merged with settings to simplify module usage. This allows running a container with nothing but an image defined. See the "data/common.yaml" file for default values.
Default value: {}
podman::rootless
Enable a given user to run rootless podman containers as a systemd user service.
podman::secret
Manage a podman secret. Create and remove secrets, it cannot replace.
Examples
Set a secret with a version from puppet directly
podman::secret{'db_password':
secret => Sensitive('NeverGuess'),
flags => {
label => [
'version=20230615',
]
}
}
Set a secret from a file
podman::secret{'db_password':
path => '/etc/passwd',
}
Set a secret from a deferred function call.
podman::secret{'ora_password':
secret => Sensitive(Deferred('secret_lookup',['ora_password'])),
flags => {
labels => ['version=20230615'],
}
user => 'rootless user',
}
Parameters
The following parameters are available in the podman::secret
defined type:
ensure
Data type: Enum['present','absent']
State of the resource must be either 'present' or 'absent'.
Default value: 'present'
path
Data type: Optional[Stdlib::Unixpath]
Load secret from an existing file path The secret and path parameters are mutually exclusive.
Default value: undef
secret
Data type: Optional[Sensitive[String]]
A secret to be stored - can be set as a Deferred function. If the secret is changed the secret will NOT be modified. Best to set a secret version as a label. The secret and path parameters are mutually exclusive.
Default value: undef
flags
Data type: Hash
All flags for the 'podman secret create' command are supported as part of the 'flags' hash, using only the long form of the flag name. The value for any defined flag in the 'flags' hash must be entered as a string. If the flags for a secret are modified the secret will be recreated.
Default value: {}
user
Data type: Optional[String[1]]
Optional user for running rootless containers. When using this parameter, the user must also be defined as a Puppet resource and must include the 'uid', 'gid', and 'home'
Default value: undef
podman::subgid
Define an entry in the /etc/subgid
file.
Examples
podman::subgid { 'myuser':
subgid => 1000000
count => 65535
}
Parameters
The following parameters are available in the podman::subgid
defined type:
subgid
Data type: Integer
Numerical subordinate group ID
count
Data type: Integer
Numerical subordinate group ID count
order
Data type: Integer
Sequence number for concat fragments#
Default value: 10
podman::subuid
Manage entries in /etc/subuid
Examples
podman::subuid { 'namevar':
subuid => 1000000
count => 65535
}
Parameters
The following parameters are available in the podman::subuid
defined type:
subuid
Data type: Integer
Numerical subordinate user ID
count
Data type: Integer
Numerical subordinate user ID count
order
Data type: Integer
Sequence number for concat fragments
Default value: 10
podman::volume
Create a podman volume with defined flags
Examples
podman::volume { 'myvolume':
flags => {
label => 'use=test, app=wordpress',
}
}
Parameters
The following parameters are available in the podman::volume
defined type:
ensure
Data type: Enum['present', 'absent']
State of the resource must be either 'present' or 'absent'.
Default value: 'present'
flags
Data type: Hash
All flags for the 'podman volume create' command are supported as part of the 'flags' hash, using only the long form of the flag name. The value for any defined flag in the 'flags' hash must be entered as a string. Volume names are created based on the resoure title (namevar)
Default value: {}
user
Data type: Optional[String]
Optional user for running rootless containers. When using this parameter, the user must also be defined as a Puppet resource and must include the 'uid', 'gid', and 'home'
Default value: undef
Changelog
Release 0.7.6
- Bugfix. fixing the onlyi_prc condition #94. Contributed by utkarsh079
Release 0.7.5
- Bugfix. Resolve image name to ID before fetching digest to resolve false drift #92. Contributed by optiz0r
Release 0.7.4
- Bugfix. Replace deprecated merge() calls with stdlib::merge() - #68. Reported by ZaxLofful
Release 0.7.3
- Allow version setting on podman and podman-compose packages #77. Contributed by broadinstitute
Release 0.7.2
- Bugfix. Typos issue 87 as reported by pheeef
- Create podman networks before containers. Issues 78 and 85. Contributed by jonesbrennan
Release 0.7.1
- Include inifiles in module fixtures as required by unit tests
- Explicit lookup for defaults when calling the quadlet defined type from the main class
- Add management of /etc/containers/containers.conf #89. Contributed by fasrc
Release 0.7.0
- Added the quadlet defined type
- Use puppet-systemd to manage rootless users
Release 0.6.7
- Bugfix. Avoid deprecated has_key function #64. Contributed by traylenator
- Support for Puppet 8.x & puppetlabs/stdlib 9.x #66
Release 0.6.6
- Bugfix. Update install.pp due to false positive on selinux check #60. Contributed by magarvo
- Support ArchLinux #61. Contributed by traylenator
- Update supported OS list to drop specific versioned releases.
Release 0.6.5
- Bugfix for issue #55, Typo in network manifest. Identified by CyberLine
- Bugfix for issue #56, creates invalid systemd service file. Identified by tuxmaster5000
Release 0.6.4
- Bugfix. Fixed spelling typo "machienectl", which changed module parameters: "machienectl_pkg_ensure" is now "machinectl_pkg_ensure" "machienectl_pkg" is now "machinectl_pkg"
- Bugfix for issue #54. Unable to set the "--new" option when the systemd unit will be created. identified by tuxmaster5000
Release 0.6.3
- Add user option for networks #53. Contributed by jaevans
- Bugfix for manage_subuid documentation/implementation mismatch #51. Identified by ja391045
Release 0.6.2
- Bugfix. Fix service name #49. contributed by jcpunk
Release 0.6.1
- Bugfix. Set "systemd-logind" service title to a unique value to avoid conflict with "puppet-systemd" PR #45, contributed by jcpunk
Release 0.6.0
- Start user.slice if not running before trying to use "systemctl --user" PR #42, contributed by jcpunk
- Bugfix. Check for the container to avoid refresh errors. PR #43, contributed by jcpunk
Release 0.5.7
- Bugfix. Revert "remove rootless_users parameter and users resource collector" Contributed by silug
Release 0.5.6
- No functional changes. Bumped module dependencies to include the latest versions. Suggested by yorickps
Release 0.5.5
- Remove rootless_users parameter from the main class and do not use a resource collector for users. Identified by imp-
Release 0.5.4
- Bugfix. Creating multiple instances of podman::rootless fails, because they all have the same title for the api socket exec. Contributed by dmaes
Release 0.5.3
- Minor refactoring and general cleanup across several manifests.
- All module parameters defined in the main class and referenced by other classes.
- Default values moved from module hiera to main manifest.
- Add ability to manage the podman-compose package. Contributed by coreone
Release 0.5.2
- Minor fixes to the 'podman::network' defined type. Contributed by optizor
Release 0.5.1
- In the container defined type, skip the upstream image check when the running container image matches the declared resource and $update is false. This reduces hits against the image registry. Contributed by jaevans
- Fix operator syntax used by 'loginctl show-user' command to work with strict POSIX shells. Identified by drebs
- Add a $ruby parameter to the container defined type. This enables open source puppet agents where the ruby binary is not in the under /opt/puppetlabs. Contributed by jaevans
Release 0.5.0
- Add 'extra_env' as a parameter for the 'podman::image' class. Enables proxy support for image pull. Contributed by Kotty666
- Add 'podman::network' defined type to manage podman networks. Contributed by optiz0r
Release 0.4.0
- Add management of the API socket. - Contributed by silug
Release 0.3.0
- Add the ability to manage host system configuration of container storage in '/etc/containers/storage.conf'. Contrubuted by coreone
Release 0.2.7
- Added basic unit tests
- Fixed regression to update container when image digest differs from repo and update is true. Identified by lukashartl
Release 0.2.6
- Fix for container image removal when $update is true. Can't reference a container image after the container has been deleted...
Release 0.2.5
- Fix container removal when set to 'absent'
- Fix to re-deploy container when the defined resource image is changed. Previously, a container would not be re-deployed when the $update parameter was set to false, even when the image declared in the resource definition had changed as reported by 'lukashartl'. This change enables leaving the $update parameter set to false and 'pinning' the container image to a specific version, updating only when specified from puppet.
Release 0.2.4
- Fix "Container fails to restart when resource notified" reported by toreanderson
Release 0.2.3
- Fix for flags that don't require values - Contributed by jtopper
- Add dependency for the podman::install class to defined types
Release 0.2.2
- Only configure selinux on systems where it is enabled - Contributed by optiz0r
- Clean-up in 'podman::rootless'
Release 0.2.1
- Updated default hiera lookup to use a deep merge for all hash parameters in the main
podman
class
Release 0.2.0
- Changes to fix rootless containers. Using the defined types with the
user
parameter now requires a corresponding puppet user resource that includes the 'uid', 'gid', and 'home' attributes. - The 'homedir' parameter was removed from all defined types. Defined types now directly reference attributes of the associated user resource and requires the user and home directory to be managed by puppet.
- Changed default value of
manage_subuid
to false. Recommend managing subuid/subgid outside this module, although the functionality to manage subuid/subgid files is still present. - Stopped using resource default statements in favor of defining attributes with a hash.
- Make the 'image' parameter required for the 'container' defined type only when 'ensure' set to 'present'
- Include support for puppet 7.x
Release 0.1.4
- Added parameter to optionally create '/etc/containers/nodocker' - Contributed by coreone
Release 0.1.3
- Added dependency for puppetlabs/selinux_core to enable
SElinux boolean
container_manage_cgroup
Release 0.1.2
New features
- Added the ability to manage subuid/subgid files.
Release 0.1.0
- Initial Release
Dependencies
- puppetlabs/stdlib (>= 4.1.0 <= 10.0.0)
- puppetlabs/concat (>= 2.1.0 <= 10.0.0)
- puppetlabs/selinux_core (>= 1.0.0 <= 2.0.0)
- puppetlabs/inifile (>= 4.2.0 <= 7.0.0)
- puppet/systemd (>= 7.0.0 <= 8.0.0)
- southalc/hashfile (>= 1.4.0 <= 2.0.0)
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.