Difference between revisions of "Configuration Management"
Timdavidson (talk | contribs) (New configuration management details) |
|||
Line 1: | Line 1: | ||
+ | =Puppet= |
||
− | ==How best to manage the configuration of the servers== |
||
+ | ==Adding a new client== |
||
− | '''Static Configuration Files''' |
||
− | These are files such as exim and apache configuration files.<br> |
||
− | In most cases, these will only be altered when the package is installed.<br> |
||
− | In most cases, the customised files will not apply to the next version of the package. |
||
+ | On the client: |
||
− | '''Dynamic data files''' |
||
+ | '''sudo aptitude install puppet''' |
||
− | These are password files and network information.<br> |
||
+ | '''sudo puppetd --test''' |
||
− | The data is stored in the MySQL database and is managed via the website.<br> |
||
− | Most of the data will not change very regularly, but when it does, the servers need to be updated soon - otherwise you have to wait 24hrs for a password change.<br> |
||
− | The files can easily be generated by scripts, but there are lots of scripts on lots of servers each one generating a single configuration file. |
||
+ | On the server (puppet): |
||
− | ==Virtualisation== |
||
+ | '''sudo puppetca --list''' |
||
− | *Virtualisation of services would mean that they can be set up once and moved around the servers as hardware is upgraded |
||
+ | The new client hostname should be displayed. Then |
||
− | *Access can be controlled on a per-service level |
||
+ | '''sudo puppetca --sign''' ''<client hostname>'' |
||
− | *Does not solve the configuration managment problem |
||
− | *Configurations can be tested on a copy of the service before rolled out for real. |
||
− | |||
− | ==Version Control System== |
||
− | */etc could be put into CVS |
||
− | *A possible structure would have different branches for each server and trunk holds common configuration |
||
− | *Update would be pushed in a similar way to the website ie. on each commit a script is run to push the updates |
||
− | |||
− | '''Advantages''' |
||
− | *Allows changeing of configuration files in-place with a commit once changes have been made |
||
− | *Easy to roll back to an earlier version or see previous changes on any file |
||
− | |||
− | '''Disadvantages''' |
||
− | *Its a lot of infrastucture for files that usually don't change after installation and won't be the same when the next version is installed. |
||
− | *People need to remember to do a commit once changes have been made |
||
− | *No per-host permissions |
||
− | *Does not deal with dynamic data files |
||
− | |||
− | ==Configuration Management Software== |
||
− | *Cfengine or puppy are the most popular candidates |
||
− | *cfengine scripts are stored in cvs on a single server |
||
− | |||
− | '''Advantages''' |
||
− | *Provides a solution for both static configuration files and dynamic data files |
||
− | |||
− | '''Disadvantages''' |
||
− | *Way too complicated |
||
− | |||
− | ==Rsync== |
||
− | *Store configuration files all on one server |
||
− | *Static configuration files can be in cvs |
||
− | *dynamic data files can be automatically generated and then copied accross to server with static files |
||
− | |||
− | '''Advantages''' |
||
− | *Simple |
||
− | *Means that data files only need to be generated on one host |
||
− | *Only modified files need to be stored |
||
− | |||
− | '''Disadvantages''' |
||
− | *Is there any point storing configuration files in cvs that will only be changed when a package is installed. |
||
− | *Difficult to alter and test files in place. |
||
− | |||
− | |||
− | ==In-place== |
||
− | *Scripts generate data files where they are needed |
||
− | *Configuration files are altered as required |
||
− | *Any changes can be documented |
||
− | *Easy to determine what files have been modified after install |
||
− | |||
− | '''Advantages''' |
||
− | *Simple |
||
− | *This is pretty much how it currently works |
||
− | |||
− | '''Disadvantages''' |
||
− | *People need to remember to document |
||
− | *Can't see what changes have been made, only that a file has been modified |
||
Revision as of 22:19, 25 November 2010
Puppet
Adding a new client
On the client:
sudo aptitude install puppet sudo puppetd --test
On the server (puppet):
sudo puppetca --list
The new client hostname should be displayed. Then
sudo puppetca --sign <client hostname>