Clever Geek Handbook

Chef Soloを使用したサーバーの準備

この記事では、Chef Soloを使用して開発者環境（開発サーバー）を準備することと、戦闘サーバーを準備することの両方についてお話したいと思います。 Habr（ VagrantとChefを使用し た開発環境と開発環境の 迅速な展開）に関するいくつかの記事が既にあり、VagrantとChef Soloを使用した開発サーバーの展開に専念しています。 小さな会社でシェフソロをどのように使用しているかを示したいと思います。



私たちのWebプロジェクトは、マルチサーバーアーキテクチャを使用しているため、かなり複雑な環境を必要とします。 したがって、このような環境の準備を自動化することが重要でした。 この問題を解決するために、VagrantとChef Soloを使用します。





Vagrantは、仮想環境を作成するためのオープンソースツールです（VirtualBox、VMware、AWSなどを使用）。 つまり、仮想マシンを簡単に管理するためのプログラムです。 他の利点の中でも、Vagrantはいくつかの構成管理システム（Chef、Puppet、Ansible）をサポートしています。 構成とは、サーバー（この場合は仮想マシン）の状態、つまり、インストール済みパッケージのセット、実行中のサービスのリスト、構成ファイルの内容、ユーザーの構成などを意味します。 つまり、Vagrantは、起動直後にマシンを必要な状態にするプロセスを開始できます。



Vagrantは、開発者環境の作成に最適でした。 開発者がVagrantプロジェクトのクローンを作成し、「vagrant up」コマンドを実行するだけで十分です。 それ以外はすべて自動的に行われます。仮想マシンのイメージのダウンロード（開発者のマシン上にない場合）、構成済みのネットワークパラメーターと共有ディレクトリでの仮想マシンの起動、構成管理システムの起動。 これにより、すべての開発者に統一された環境が提供されます。これは、大規模なチームや複雑なプロジェクトにとって非常に重要です。



Chefはサーバー構成管理システムです。 Chefにはクライアントサーバーアーキテクチャがあります。 Chefサーバーは、接続されたChefクライアントとその「準備」のための「レシピ」のセットに関する情報を保存します（つまり、それらを必要な状態にします）。 Chefサーバーの使用には料金がかかります（最大5つのクライアントを無料で接続できます）。



他の構成管理システムではなくChefが選ばれた理由（Puppetだけを真剣に見た）：



Chef Soloは、Chefサーバーなしでレシピを使用できるChefクライアントのオープンソースバージョンです（レシピは同じマシンに物理的に配置する必要があります）。 Chef Soloは無料ですが、クライアント/サーバーChefと比較していくつかの制限があります。 たとえば、条件によるレシピでサーバー検索を使用する方法はありません。



クライアントサーバーシェフではなく、シェフソロが選ばれた理由：



Chef Soloにより、新しいサーバーでのプロジェクトのインストールと構成を完全に自動化できました。 アプリケーション用の戦闘サーバーの展開には、通常、約10〜15分かかります（レシピの複雑さによって異なります）。



次のプロジェクトは 、サーバー管理を目的としています。 このプロジェクトのカタログから、Vagrantを使用して仮想マシンが起動され、実サーバーの準備も実行されます。 このプロジェクトでは、1つの仮想サーバー（デモ）が既に追加されており、その上に最新バージョンのnginxがインストールされています。



プロジェクト構造：



開発用に新しい仮想サーバーをデプロイするには、次のことを行う必要があります。

  1. 「Vagrantfile」で、サーバー名（「frontend」など）をIPアドレス（「10.2.2.100」など）に関連付けます。
  2. 「nodes」ディレクトリで、新しいサーバーの属性のJSONファイルを作成します（「10.2.2.100.json」など）。
  3. マシン名（「vagrant up frontend」など）を指定した「vagrant up」コマンドを使用して、仮想マシンを起動します。 最初の起動時にChef Soloが起動し、対応する属性のJSONファイルで指定されたすべてのレシピが実行されます。 この場合、「開発」環境が使用されます（これは「Vagrantfile」に示されています）。


新しいバトルサーバーを作成するには、以下を行う必要があります。

  1. 「nodes」ディレクトリで、新しいサーバーの属性用のJSONファイルを作成します（「23.144.12.15.json」など）。
  2. ユーザーとIPサーバー（たとえば、「./ deploy.sh root@23.144.12.15」）でスクリプト「deploy.sh」を実行します。 deploy.shスクリプトはサーバーへのSSH接続を内部的に提供するため、このスクリプトの実行時に指定されるすべての追加パラメーターはsshコマンドのパラメーターとして使用されます（これはキーで入力する場合に重要です）。 Windowsでは、このスクリプトを実行するには、cmd.exeにはない* nixコマンドが必要になるため、Git Bashで実行します。


スクリプト「deploy.sh」は、次のアクションを実行します。

  1. SSH経由でサーバーに接続します。
  2. プロジェクトディレクトリ全体をアーカイブし、アーカイブをSSH経由でサーバーに転送します。
  3. サーバー上のアーカイブをディレクトリ「〜/ chef」に解凍します。
  4. インストールスクリプト「install.sh」を実行します。


スクリプト「install.sh」は、次のアクションを実行します。

  1. Chef Soloがインストールされているかどうかを確認し、必要に応じてインストールします。 サーバーではUbuntuを使用しているため、他のシステムでは、コマンドを修正してChefをインストールする必要があります。
  2. 構成ファイル「solo.rb」とサーバー設定用のJSONファイルを使用してChef Soloを起動します。 この場合、「実稼働」環境が使用されます（これは「solo.rb」に示されています）。


サーバーの初期準備に加えて、多くの場合、サーバーの構成を更新する必要があります。 たとえば、いくつかのパッケージを更新したり、アプリケーションの新しいバージョンを投稿したり、レシピの最新の変更を適用したりする必要があります。 仮想サーバーの場合、この操作は「vagrant provision＃machine_name＃」コマンドによって実行されます。 バトルサーバーの場合、「./ deploy.sh root @＃ip_server＃」を再起動する必要があります。



「deploy.sh」および「install.sh」スクリプトは、 Chef Soloチュートリアルの記事「 Chefによる単一サーバーの管理 」に基づいています 。



deploy.shの代わりにknife-soloを見ることができますが、提案された方法と比較していくつかの欠点があります。



そのため、シンプルなデバイスを使用して、開発用の仮想サーバーを比較的簡単に展開し、作業中のプロジェクト用のサーバーに対抗できます。 私の記事が誰かに役立つことを願っています。


More articles:


All Articles