Introduction

より広い主題として、構成管理(CM)は、システムへの変更を体系的に処理して、時間の経過とともに整合性を維持するプロセスを指します。 このプロセスはIT業界で生まれたものではありませんが、この用語はサーバー構成管理を指すために広く使用されています。

自動化は、サーバー構成管理において重要な役割を果たします。 これは、サーバーを望ましい状態にするために使用されるメカニズムであり、以前はツールの特定の言語と機能を使用してスクリプトをプロビジョニングすることで定義されていました。 実際、自動化はサーバーの構成管理の中心であり、そのため、構成管理ツールを自動化ツールまたはIT自動化ツールとも呼ぶのが一般的です。

構成管理ツールによって実装される自動化機能を説明するために使用されるもう1つの一般的な用語は、サーバーオーケストレーションまたは ITオーケストレーションです。これらのツールは通常、中央コントローラーから1台から数百台のサーバーを管理できるためです。マシーン。

市場には多くの構成管理ツールがあります。 Puppet、Ansible、Chef、Saltが人気の選択肢です。 Although each tool will have its own characteristics and work in slightly different ways, they are all driven by the same purpose: to make sure the system’s state matches the state described by your provisioning scripts.

Benefits of Configuration Management for Servers

Although the use of configuration management typically requires more initial planning and effort than manual system administration, all but the simplest of server infrastructures will be improved by the benefits that it provides. To name a few:

Quick Provisioning of New Servers

Whenever a new server needs to be deployed, a configuration management tool can automate most, if not all, of the provisioning process for you. 自動化により、面倒なタスクを人間よりも迅速かつ正確に実行できるため、プロビジョニングがはるかに迅速かつ効率的になります。 Even with proper and thorough documentation, manually deploying a web server, for instance, could take hours compared to a few minutes with configuration management/automation.

Quick Recovery from Critical Events

With quick provisioning comes another benefit: quick recovery from critical events. 不明な状況が原因でサーバーがオフラインになった場合、システムを適切に監査して実際に何が起こったかを確認するのに数時間かかる場合があります。 このようなシナリオでは、影響を受けるサーバーで詳細な検査が行われている間に、通常、交換用サーバーを展開することがサービスをオンラインに戻す最も安全な方法です。 With configuration management and automation, this can be done in a quick and reliable way.

No More Snowflake Servers

At first glance, manual system administration may seem to be an easy way to deploy and quickly fix servers, but it often comes with a price. プロセスが自動化されていない場合、時間の経過とともに、サーバーに何がインストールされ、どの変更が行われたかを正確に知ることが非常に困難になる可能性があります。 手動の修正プログラム、構成の微調整、およびソフトウェアの更新により、サーバーが一意のスノーフレークに変わり、管理が難しく、複製がさらに困難になる可能性があります。 By using a configuration management tool, the procedure necessary for bringing up a new server or updating an existing one will be all documented in the provisioning scripts.

Version Control for the Server Environment

Once you have your server setup translated into a set of provisioning scripts, you will have the ability to apply to your server environment many of the tools and workflows you normally use for software source code.

Gitなどのバージョン管理ツールを使用して、プロビジョニングに加えられた変更を追跡し、スクリプトのレガシーバージョン用に個別のブランチを維持できます。 バージョン管理を使用して、プロビジョニングスクリプトのコードレビューポリシーを実装することもできます。この場合、変更はプルリクエストとして送信し、プロジェクトリーダーが承認してから承認する必要があります。 This practice will add extra consistency to your infrastructure setup.

Replicated Environments

Configuration management makes it trivial to replicate environments with the exact same software and configurations. これにより、本番サーバー、開発サーバー、およびテストサーバーを使用して、多段階のエコシステムを効果的に構築できます。 同じプロビジョニングスクリプトで構築されたローカル仮想マシンを開発に使用することもできます。 This practice will minimize problems caused by environment discrepancies that frequently occur when applications are deployed to production or shared between co-workers with different machine setups (different operating system, software versions and/or configurations).

Overview of Configuration Management Tools

Even though each CM tool has its own terms, philosophy and ecosystem, they typically share many characteristics and have similar concepts.

ほとんどの構成管理ツールは、コントローラー/マスターおよびノード/エージェントモデルを使用します。 基本的に、コントローラーは、プロビジョニングスクリプトで定義された一連の命令またはタスクに基づいて、ノードの構成を指示します。

Below you can find the most common features present in most configuration management tools for servers:

Automation Framework

Each CM tool provides a specific syntax and a set of features that you can use to write provisioning scripts. ほとんどのツールには、言語を従来のプログラミング言語と同様にする機能がありますが、その機能は単純化されています。 Variables, loops, and conditionals are common features provided to facilitate the creation of more versatile provisioning scripts.

Idempotent Behavior

Configuration management tools keep track of the state of resources in order to avoid repeating tasks that were executed before. パッケージがすでにインストールされている場合、ツールはそのパッケージを再度インストールしようとはしません。 目的は、プロビジョニングを実行するたびに、システムを複数回実行した場合でも、システムが目的の状態に到達(または維持)することです。 これが、これらのツールがべき等動作を持っていることを特徴付けるものです。 This behavior is not necessarily enforced in all cases, though.

System Facts

Configuration management tools usually provide detailed information about the system being provisioned. This data is available through global variables, known as facts. これには、ネットワークインターフェイス、IPアドレス、オペレーティングシステム、ディストリビューションなどが含まれます。 Each tool will provide a different set of facts. They can be used to make provisioning scripts and templates more adaptive for multiple systems.

Templating System

Most CM tools will provide a built-in templating system that can be used to facilitate setting up configuration files and services. テンプレートは通常、汎用性を最大化するために使用できる変数、ループ、および条件をサポートします。 たとえば、テンプレートを使用して、Apache内に新しい仮想ホストを簡単にセットアップし、同じテンプレートを複数のサーバーのインストールに再利用できます。 テンプレートには、ハードコードされた静的な値だけを含めるのではなく、ホストごとに変更できる値のプレースホルダーを含める必要があります。 NameServerDocumentRoot.

Extensibility

Even though provisioning scripts can be very specialized for the needs and demands of a particular server, there are many cases when you have similar server setups or parts of a setup that could be shared between multiple servers. ほとんどのプロビジョニングツールは、プロビジョニング設定の小さなチャンクをモジュールまたはプラグインとして簡単に再利用および共有できる方法を提供します。

サードパーティのモジュールとプラグインは、インターネット上で簡単に見つけることができます。特に、PHPWebサーバーのインストールなどの一般的なサーバー設定の場合はそうです。 CMツールには強力なコミュニティが構築されている傾向があり、ユーザーはカスタム拡張機能を共有することをお勧めします。 Using extensions provided by other users can save you a lot of time, while also serving as an excellent way of learning how other users solved common problems using your tool of choice.

Choosing a Configuration Management Tool

There are many CM tools available in the market, each one with a different set of features and different complexity levels. 人気のある選択肢には、Chef、Ansible、Puppetなどがあります。 最初の課題は、ニーズに最適なツールを選択することです。

There are a few things you should take into consideration before making a choice:

Infrastructure Complexity

Most configuration management tools require a minimum hierarchy consisting of a controller machine and a node that will be managed by it. たとえば、Puppetでは、各ノードに agent アプリケーションをインストールし、コントローラーマシンにmasterアプリケーションをインストールする必要があります。 一方、Ansibleは分散型の構造であり、ノードに追加のソフトウェアをインストールする必要はありませんが、プロビジョニングタスクを実行するためにSSHに依存しています。 小規模なプロジェクトの場合、単純化されたインフラストラクチャの方が適しているように見えるかもしれませんが、ツールでは適用されない可能性のあるスケーラビリティやセキュリティなどの側面を考慮することが重要です。

Some tools can have more components and moving parts, which might increase the complexity of your infrastructure, impacting on the learning curve and possibly increasing the overall cost of implementation.

Learning Curve

As mentioned earlier in this article, CM tools provide a custom syntax, sometimes using a Domain Specific Language (DSL), and a set of features that comprise their framework for automation. 従来のプログラミング言語と同様に、一部のツールでは、習得するためにより高い学習曲線が必要になります。 The infrastructure requirements might also influence the complexity of the tool and how quickly you will be able to see a return of investment.

Cost

Most CM tools offer free or open source versions, with paid subscriptions for advanced features and services. 一部のツールには他のツールよりも多くの制限があるため、特定のニーズとインフラストラクチャの成長方法によっては、これらのサービスの料金を支払う必要が生じる場合があります。 You should also consider training as a potential extra cost, not only in monetary terms, but also regarding the time that will be necessary to get your team up to speed with the tool you end up choosing.

Advanced Tooling

As mentioned before, most tools offer paid services that can include support, extensions, and advanced tooling. 特定のニーズ、インフラストラクチャのサイズ、およびこれらのサービスを使用する必要があるかどうかを分析することが重要です。 たとえば、管理パネルはこれらのツールによって提供される一般的なサービスであり、中央のポイントからすべてのサーバーを管理および監視するプロセスを大幅に容易にすることができます。 Even if you don’t need such services just yet, consider the options for a possible future necessity.

Community and Support

A strong and welcoming community can be extremely resourceful for support and for documentation, since users are typically happy to share their knowledge and their extensions (modules, plugins, and provisioning scripts) with other users. This can be helpful to speed up your learning curve and avoid extra costs with paid support or training.

The table below should give you a quick overview of the main differences between three of the most popular configuration management tools available in the market today: Ansible, Puppet, and Chef.

Ansible 傀儡 シェフ
スクリプト言語 YAML Rubyに基づくカスタムDSL ルビー
インフラストラクチャー コントローラマシンはSSH経由でノードに設定を適用します PuppetマスターはPuppetノードの構成を同期します Chefワークステーションは構成をChefサーバーにプッシュし、そこからChefノードが更新されます
ノード専用のソフトウェアが必要 いいえ はい はい
一元化された制御ポイントを提供します いいえ。 どのコンピューターもコントローラーになることができます はい、パペットマスター経由 はい、ChefServer経由
スクリプト用語 プレイブック/役割 マニフェスト/モジュール レシピ/クックブック
タスク実行順序 一連の 非シーケンシャル 一連の

Next Steps

So far, we’ve seen how configuration management works for servers, and what to consider when choosing a tool for building your configuration management infrastructure. このシリーズの後続のガイドでは、Ansible、Puppet、Chefの3つの一般的な構成管理ツールを実際に体験します。

これらのツールを自分で比較する機会を与えるために、各ツールによって完全に自動化されるべきサーバー設定の簡単な例を使用します。 This setup consists of an Ubuntu 18.04 server running Apache to host a simple web page.

Conclusion

Configuration management can drastically improve the integrity of servers over time by providing a framework for automating processes and keeping track of changes made to the system environment. このシリーズの次のガイドでは、 Ansible をツールとして使用して、構成管理戦略を実際に実装する方法を説明します。