3 ms·
Step #1 keep your CM files in Git. My favorite part of puppet is demonstrated well by the trifects: package { 'openssh-server': ensure => installed,
by sliken 2y ago
Step #1 keep your CM files in Git.
My favorite part of puppet is demonstrated well by the trifects:
package { 'openssh-server':
ensure => installed,
}
file { '/etc/ssh/sshd_config':
source => 'puppet:///modules/sshd/sshd_config',
owner => 'root',
group => 'root',
mode => '0640',
notify => Service['sshd'], # sshd restarts whenever you edit this file.
require => Package['openssh-server'],
}
service { 'sshd':
ensure => running,
enable => true,
}
That will keep SSH installed, a service running, and the puppet config file managed forever. If you accidentally replace the config file it will be fixed and the service restarted. If you remove the package it will be reinstalled, config file updated, and service started.
Not a fan of ansible, it's more of a "run this playbook", which translates to reinstall and "run this playbook", which in environments that don't reinstall very often can be painful. Since ansible playbooks don't know the current machines state they never know exactly what commands to run.
Generally if you spin up containers or similar short term servers I think ansible is fine. If it's a larger and more complicated environment with longer lived servers I'd use puppet.
Oh, one other think I like about puppet is if you say apply X to all nodes, you can literally not run puppet (it will fail to compile the manifests) if you try to override it. Which security auditors LOVE.