modules, in our case
/etc/puppet/modules
. We change to that directory and then execute the
git
binary to initialize our new Git repository.
$ cd /etc/puppet/modules
$ git init
This creates a directory called
.git
in the
/etc/puppet/modules
directory that will hold all the details and tracking data for our Git repository.
We can now add files to this repository using the
git
binary with the
add
option.
$ git add *
This adds everything currently in our path to Git. You can also use
git
and the
rm
option to remove items you don’t want to be in the repository.
$ git rm filename
This doesn’t mean, however, that our modules are already fully tracked by our Git repository. Like Subversion and other version control systems, we need to “commit” the objects we’d like to track. The commit process captures the state of the objects we’d like to track and manage, and it creates a revision to mark that state. You can also create a file called
.gitignore
in the directory. Every file or directory specified in this file will be ignored by Git and never added.
Before we commit though, we can see what Git is about by using the
git status
command:
$ git status
This tells us that when we commit that Git will add the contents to the repository and create a revision based on that state.
Now let’s commit our revision to the repository.
$ git commit –a –m "This is our initial commit"
The
–m
option specifies a commit message that allows us to document the revision we’re about to commit. It’s useful to be verbose here and explain what you have changed and why, so it’s easier to find out what’s in each revision and make it easier to find an appropriate point to return to if required. If you need more space for your commit message you can omit the
–m
option and Git will open your default editor and allow you to type a more comprehensive message.
The changes are now committed to the repository and we can use the
git log
command to see our recent commit.
$ git log
We can see some information here about our commit. First, Git uses SHA1 hashes to track revisions; Subversion, for example, uses numeric numbers – 1, 2, 3, etc. Each commit has a unique hash assigned to it. We will also see some details about who created the commit and our commit message telling us what the commit is all about.
Every time you add a new module or file you will need to add it to Git using the
git add
command and then commit it to store it in the repository. I recommend you add and commit changes regularly to ensure you have sufficiently granular revisions to allow you to easily roll back to an earlier state.
Tip If you’re interested in Git, we strongly recommend Scott Chacon’s excellent book Pro Git – also published by Apress. The book is available in both dead tree form and online at
http://progit.org/book/
. Scott is also one of the lead developers of the Git hosting site, GitHub –
http://www.github.com
, where you can find a number of Puppet related modules.
Our simple
sudo
module is a good introduction to Puppet, but it only showcased a small number of Puppet’s capabilities. It’s now time to expand our Puppet knowledge and develop some new more advanced modules, starting with one to manage SSH on our hosts. We’ll then create a module to manage Postfix on
mail.example.com
, one to manage MySQL on our Solaris host,
db.example.com
, another to manage Apache and web sites, and finally one to manage Puppet with Puppet itself.
We’ll also introduce you to some best practices for structuring, writing and managing modules and configuration.
Creating a module to Manage SSH
We know that we first need to create an appropriate module structure. We’re going to do this under the
/etc/puppet/modules
directory on our Puppet master.
$ cd /etc/puppet/modules
$ mkdir –p ssh/{manifests,templates,files}
$ touch ssh/manifests/init.pp
Next, we create some classes inside the
init.pp
file and some initial resources, as shown in
/etc/puppet/modules
. We change to that directory and then execute the
git
binary to initialize our new Git repository.
$ cd /etc/puppet/modules
$ git init
This creates a directory called
.git
in the
/etc/puppet/modules
directory that will hold all the details and tracking data for our Git repository.
We can now add files to this repository using the
git
binary with the
add
option.
$ git add *
This adds everything currently in our path to Git. You can also use
git
and the
rm
option to remove items you don’t want to be in the repository.
$ git rm filename
This doesn’t mean, however, that our modules are already fully tracked by our Git repository. Like Subversion and other version control systems, we need to “commit” the objects we’d like to track. The commit process captures the state of the objects we’d like to track and manage, and it creates a revision to mark that state. You can also create a file called
.gitignore
in the directory. Every file or directory specified in this file will be ignored by Git and never added.
Before we commit though, we can see what Git is about by using the
git status
command:
$ git status
This tells us that when we commit that Git will add the contents to the repository and create a revision based on that state.
Now let’s commit our revision to the repository.
$ git commit –a –m "This is our initial commit"
The
–m
option specifies a commit message that allows us to document the revision we’re about to commit. It’s useful to be verbose here and explain what you have changed and why, so it’s easier to find out what’s in each revision and make it easier to find an appropriate point to return to if required. If you need more space for your commit message you can omit the
–m
option and Git will open your default editor and allow you to type a more comprehensive message.
The changes are now committed to the repository and we can use the
git log
command to see our recent commit.
$ git log
We can see some information here about our commit. First, Git uses SHA1 hashes to track revisions; Subversion, for example, uses numeric numbers – 1, 2, 3, etc. Each commit has a unique hash assigned to it. We will also see some details about who created the commit and our commit message telling us what the commit is all about.
Every time you add a new module or file you will need to add it to Git using the
git add
command and then commit it to store it in the repository. I recommend you add and commit changes regularly to ensure you have sufficiently granular revisions to allow you to easily roll back to an earlier state.
Tip If you’re interested in Git, we strongly recommend Scott Chacon’s excellent book Pro Git – also published by Apress. The book is available in both dead tree form and online at
http://progit.org/book/
. Scott is also one of the lead developers of the Git hosting site, GitHub –
http://www.github.com
, where you can find a number of Puppet related modules.
Our simple
sudo
module is a good introduction to Puppet, but it only showcased a small number of Puppet’s capabilities. It’s now time to expand our Puppet knowledge and develop some new more advanced modules, starting with one to manage SSH on our hosts. We’ll then create a module to manage Postfix on
mail.example.com
, one to manage MySQL on our Solaris host,
db.example.com
, another to manage Apache and web sites, and finally one to manage Puppet with Puppet itself.
We’ll also introduce you to some best practices for structuring, writing and managing modules and configuration.
Creating a module to Manage SSH
We know that we first need to create an appropriate module structure. We’re going to do this under the
/etc/puppet/modules
directory on our Puppet master.
$ cd /etc/puppet/modules
$ mkdir –p ssh/{manifests,templates,files}
$ touch ssh/manifests/init.pp
Next, we create some classes inside the
init.pp
file and some initial resources, as shown in
Similar Books
