Configuration Management Mechanism Ansible , Chef and Puppet | 8.10 NETWORK AUTOMATION скачать в хорошем качестве

Configuration Management Mechanism Ansible , Chef and Puppet | 8.10 NETWORK AUTOMATION

I looked at each of these four tools in depth, explored their design and function, and determined that, while some scored higher than others, there's a place for each to fit in, depending on the goals of the deployment. Here, I summarize my findings. Puppet Enterprise Puppet arguably enjoys the biggest mind share of the four. It's the most complete in terms of available actions, modules, and user interfaces. Puppet represents the whole picture of data center orchestration, encompassing just about every operating system and offering deep tools for the main OSes. Initial setup is relatively simple, requiring the installation of a master server and client agents on each system that is to be managed. From there, the CLI (command-line interface) is straightforward, allowing module downloads and installation via the puppet command. Then, changes to the configuration files are required to tailor the module for the required task, and the clients that should receive the instructions will do so when they check in with the master or via a push that will trigger the modifications immediately. There are also modules that can provision and configure cloud server instances and virtual server instances. All modules and configurations are built with a Puppet-specific language based on Ruby, or Ruby itself, and thus will require programmatic expertise in addition to system administration skills. Puppet Enterprise has the most complete Web UI of the bunch, allowing for real-time control of managed nodes using prebuilt modules and cookbooks present on the master servers. The Web UI works well for management but does not allow for many configurations of modules. The reporting tools are well developed, providing deep details on how agents are behaving and what changes have been made. Enterprise Chef Chef is similar to Puppet in terms of the overall concept, in that there's a master server and agents installed on managed nodes, but it differs in actual deployment. In addition to a master server, a Chef installation also requires a workstation to control the master. The agents can be installed from the workstation using the knife tool that uses SSH for deployment, easing the installation burden. Thereafter, managed nodes authenticate with the master through the use of certificates. Configuration of Chef revolves around Git, so knowledge of how Git works is a prerequisite for Chef operation. Like Puppet, Chef is based on Ruby, so knowledge of Ruby is also required. As with Puppet, modules can be downloaded or written from scratch and deployed to managed nodes following the required configuration. Unlike Puppet, Chef doesn't yet have a well-formed push feature, though beta code is available. This means that agents will need to be configured to check in with the master periodically, and immediate application of changes isn't really possible. The Web UI for Enterprise Chef is functional but does not provide the ability to modify configurations. It is not as complete as the Web UI for Puppet Enterprise, lacking in reporting and other features, but allows for inventory control and node organization. Like Puppet, Chef benefits from a large collection of modules and configuration recipes, and those rely heavily on Ruby. For that reason, Chef is well-suited to development-centric infrastructures. AnsibleWorks Ansible Ansible is much more similar to Salt than to either Puppet or Chef. The focus of Ansible is to be streamlined and fast, and to require no node agent installation. Thus, Ansible performs all functions over SSH. Ansible is built on Python, in contrast to the Ruby foundation of Puppet and Chef. Installation of Ansible can be done through a Git repository clone to an Ansible master server. Following that, nodes to be managed are added to the Ansible configuration, and SSH authorized keys are appended to each node, related to the user that Ansible will run under. Once this is done, the Ansible master server can communicate with the node via SSH and perform all required tasks. In order to function with operating systems or distributions that do not allow root SSH access by default, Ansible accepts sudo credentials in order to run commands as root on those systems.