Recommended by 0 users
This tutorial gives you an overview and talks about the fundamentals of Puppet.
- 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 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.