System administration with Puppet turns out, not too differently from the 
way you already do it. But because Puppet handles the low-level details of 
creating users, installing packages, and so on, you’re now free to think 
about your configuration at a slightly higher level.

The key differences from the traditional, manual approach are as follows: ? 
You only had to specify the steps to create a new user once, instead of 
doing them every time for each new user ? You only had to add the user in 
one place, instead of on every machine in your infrastructure ? You didn’t 
have to worry about the OS-specific details of how to add users.

The Puppet manifest—for your configuration is a set of declarations about 
what things should exist, and how they should be configured. You don’t give 
commands, such as “Do this, then do that.” Rather, you describe how things 
should be, and let Puppet take care of making it happen. These are two 
quite different kinds of programming. The first (procedural style) is the 
traditional model used by languages, such as C, Python, shell, and so on  
Puppet’s <https://mindmajix.com/puppet-training> is called declarative 
style because you declare what the end result should be, rather than 
specifying the steps to get there. This means that you can apply the same 
Puppet manifest repeatedly to a machine and the end result will be the 
same, no matter how many times you run the “program”. It’s better to think 
of Puppet manifests as a kind of executable specification rather than as a 
program in the traditional sense.

When Puppet runs on a computer, it compares the current configuration to 
the manifest. It will take whatever actions are needed to change the 
machine so that it matches the manifest. Puppet supports a wide range of 
different platforms and operating systems, and it will automatically run 
the appropriate commands to apply your manifest in each environment.

Git provides very powerful tools for doing this. If you’re working on 
Puppet code in a team, it’s critical that you use some kind of version 
control to handle it. Git tracks changes to a particular set of files. The 
changes are stored in Git’s database, known as a repository (“repo” for 
short). When you run the git init command, it tells Git to create a new 
repository in the current directory. When you create a new repo, it 
contains no files, so the git add command adds files to the list that Git 
should track. This command adds everything in this directory. The full stop 
(.) is UNIX shorthand for the current directory. Instead of storing every 
successive version of a file, Git just keeps the differences.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/969d08aa-2e47-4aa9-8612-3ea9d101a4e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to