システム管理者は毎日、些細な一連のコマンドによって何らかの形で解決しなければならないタスクに直面しています。 時にはそれはとんでもないことになる：
- 100台のサーバーにファイルを配布します
- 100台のサーバーにパッケージを配布します
- ファイル内の行を変更
- 更新システム
- ユーザーを追加
- サービスを再開する
インフラストラクチャ管理者は、すべてのサーバーに交互にアクセスして、1〜10個のコマンドセットを実行します。 このように動作し続けると、すぐに大規模システムのシステム管理者は「サーバーenikeyschika」に変わります。
この問題を解決するには、2つの方法があります。1つは下級従業員を雇い、すべての汚い仕事を「アンロード」するか、単純なタスクをあまり自動化しません。
現時点では、これを可能にする多くのシステムがありますが、最も一般的なのは
Chef 、
Puppet、および
Ansibleです。
このパブリケーションでは、Chefと、複数のサーバーでの日常的なタスクを自動化する方法に焦点を当てます。
一般的に、なぜシェフなのか？
最初に、顧客は私達とそれを使用します。 それで、Deployersから動物園を作らないように、シェフは去りました。 Habréのどこかで、ChefとPuppetの違いについての良い説明を見ました：
- シェフ-何を手に入れたいですか？
- 人形-あなたは何をしたいですか？
しかし、MirantisのMikhail Shcherbakovが「展開におけるPuppetの非標準的な使用」について語ったビデオセミナー「The Road to the Clouds」を見た後、このイデオロギーを明確に理解するために、少し気分が悪くなりました。 また、プロジェクトを顧客に展開するために作成したシェフレシピをテストすることで、Chefを好きなように使用できることが示唆されました。
第二に、シェフの言語は私に近いです。 少し前まで、私はルビーに出会いました。シェフのマニフェスト構文はそれを使用しています。
第三に、シェフレシピは、「
knife bootstrap --run-list」レシピ[somerecipe]「somehost、domain.lan 」を呼び出すだけで、サーバーから集中的に配布できます。 本当に便利です。
4番目に、chefには通常のWindowsクライアントがあります。 そして、これなしでは、時にはどこにもありません。
設置
例として引き続きUbuntuを使用します。 サーバーのみがUbuntu上にあり、クライアントはUbuntu、CentOS、およびWindows上にあります。
ここでインストールパッケージを取得し
ます 。
パッケージをインストールしたら、「再構成」を実行して、ユーザーと組織を作成する必要があります。
組織のメカニズムにより、非常に便利なテストサイトを整理したり、1台のサーバーですべての顧客を結合したりできます（ああ、お勧めしません）。
ここで説明した情報に加えて、Webインターフェースなどの追加コンポーネントのインストール方法に関する情報があります。
また、いくつかの設定を修正し、必要なディレクトリを作成する価値があります。
簡単な料理の本
Chefで最も人気のあるツールはクックブックです。 特定のレシピが含まれています。
レシピは、ファイルテンプレート、変数などを使用してサーバー上で特定のアクションを実行するためのテンプレートです。 特定の作業結果を実装します。 料理のように、私たちの目標は、すぐに食べられる「スープ」を手に入れることです。
例として、Javaで自己記述されたデーモンアプリケーションを準備するためのレシピを作成します。これは、構成と一緒にいくつかのサーバーに配布する必要があります。
空白を作成します。
このプロジェクトでは、
属性、レシピ、テンプレートディレクトリ、および
metadata.rbファイルのみを使用します。
最後から始めましょう。
metadata.rbファイルには、レシピ、その開発者、そのライセンスとバージョン、および依存関係とサポートされているOSのリストに関する基本情報が含まれています。
例 name 'prog' maintainer 'vstconsulting' maintainer_email 'admin@vst.lan' license 'All rights reserved' description 'Installs/Configures Prog' long_description IO.read(File.join(File.dirname(__FILE__), 'README.md')) version '1.2.3'
この例では、Javaレシピへの依存が、その不在の問題を回避するために示されています。 Javaを含む既製のレシピ
があります。
次に、
recipesディレクトリに
default.rbファイルがあります。 次のフォームに持ち込みます。
順番に：
- node.override ['java'] ['jdk_version'] = '7'は、クックブックjavaのjdk_version属性のデフォルト値を '7'に変更することを意味します。 属性については後で説明します。
- include_recipe "java"は、最初にjavaクックブックからdefault.rbレシピを開始する必要があることを示しています。 それ以降のレシピは、Javaレシピが成功した後にのみ行われます。
- ケースコンストラクトと標準のplatform_family属性を使用して、現在のクックブックから適切なレシピをインストールして呼び出すプラットフォームを定義します。 概して、これらのレシピでは、インストールと起動ですべての操作を行うことができますが、 ほとんどのアクションは同じです。特定のプラットフォームに必要なフォームにいくつかのパラメーターを追加します。
- package_name = node ['prog'] ['package']は、将来使用する変数を宣言していることを意味します。 この変数には、「package」属性の値が含まれます
- remote_file構造により、オープンソースからファイルをダウンロードし、キャッシュディレクトリに保存できます。
- サービス設計とは、サービスが起動時に起動されることを意味します。
- template構成により、構成テンプレートが必要なディレクトリに保存され、サービスが再起動されます。
実際、ほぼすべてのパッケージをほぼすべてのシステムにインストールできるユニバーサルレシピについて説明しています。
次に、属性を調整する必要があります。 属性は、Cookieの便利なメカニズムであり、外部から好きなだけパラメーターを設定できます。 この例では、
package、conf_dir、prog_name、clusterの 4つの属性が使用され
ます 。
attributes / default.rbを次の形式にしましょう：
default['prog']['prog_name'] = 'somejavademon' default['prog']['package'] = "#{node['prog']['prog_name']}.deb" case node['platform_family'] when 'debian' default['prog']['conf_dir'] = "/etc/#{node['prog']['prog_name']}/conf" when 'rhel' default['prog']['conf_dir'] = "/etc/#{node['prog']['prog_name']}/conf" when 'windows' default['prog']['conf_dir'] = "C:/#{node['prog']['prog_name']}/conf" else Chef::Application.fatal!('Attempted to install on an unsupported platform') end
したがって、属性の基本値を設定しますが、異なるシステムでは構成ファイルの配置が異なる場所にあることを考慮しました。
次に、構成ファイルテンプレートを作成する必要があります。
テンプレート/デフォルト/ main.conf.erb cluster.name: <%= node["prog"]["cluster"] %> node.name: <%= node['hostname'] %>
上記の後に、テンプレートの必要な属性をどのように置き換えることができるかは明確だと思います。 サイクルを使用することもできますが、これには焦点を合わせません。
言及しませんでしたが、テンプレートの追加レシピも作成する必要があります。
はい、そのように。
レシピをサーバーにアップロードします。
環境
次に、パラメーターを取得する単純な環境の例を作成します。
これは必ずしも必要ではありませんが、何がどのように機能するかを理解するために非常に役立ちます。
指定されたEDITORのウィンドウが開き、次の情報を入力します。
{ "name": "someserver", "description": "Environment for group of servers where somejavademon will work.", "cookbook_versions": { }, "json_class": "Chef::Environment", "chef_type": "environment", "default_attributes": { }, "override_attributes": { "prog": { "prog_name": "somejavaserver", } } }
これで、この環境は
somejavaserverがインストールされる多くのホストで使用できます。
展開する
次に、最も重要なこと、つまりサーバー間での製品の配布について説明します。
- 何を、どのように、どこにインストールするかを示すレシピがあります。
- 特にインストールする必要があるものを指定するEnvがあります。
- これがすべて動作するChefサーバーがあり、必要なすべてのサーバーにアクセスできます。
- Ubuntu、CentOSに動作するドメイン名を持つ100台のサーバーがあり、これらすべてをインストールする必要があります。
- 必要なすべてのサーバーへのsshを介したroot / adminアクセスがあります。
サーバーに必要なレシピをインストールするには、次を実行する必要があります。
スクリプトを書くことを妨げるものは何もありません。
しばらくすると（5分/ 30分/時間/日）、100台すべてのサーバーが完全に作動可能になります。
いずれにせよ、Chefサーバーのインストール、レシピとenvの作成、およびデプロイは、各サーバーにパッケージを手動でインストールするよりも少ない時間または同じ時間で完了します。 しかし！ すべての準備が整っていれば、再インストールにかかる時間ははるかに短くなり、さらに労力がかかります。 最も重要なことは、手動で何かをする必要がなくなったことです。 サーバーのリストを指定し、スクリプトを実行し、Habréの新しい出版物を読むだけで十分です。
他に何ができますか？
これはかなり哲学的な質問です。
knife-windowsをインストールできます（インストールする必要があります）。 難しいことではありませんが、質問があれば、いつでもお手伝いします。
スーパーマーケットから既製のレシピの束をダウンロードして、好きなサーバーの数にあなたの心が望むものを展開できます。
すべての機会に独自のレシピを作成し、サーバーのメンテナンスを減らしてOSのインストール（PXEで非常によく自動化されます）、機器の交換、および監視を行うことができます。
ChefをOpenStack（ある場合）に接続し、新しいサーバーとサービスをバッチでデプロイできます。
ここで、それを行う方法を見つけることができます。 特にCloud-InitとChefを使用して既に理解している場合は、特に複雑なことはありません。
何かを追加するのを忘れた場合は、コメントで修正してください。
この投稿が、誰かがChefとサーバーまたはオフィス作業の雑用を理解するのに役立つことを願っています。
UPD： OpenStackの
cloud-configサンプルを追加することにしました：
＃cloud-config
起動後、VMはchef-clientをインストールし、chef-serverと通信するように構成します。
シェフがすぐにレシピを受け取り、しばらく待たないように、クライアントの再起動が必要です。 何らかの理由で、彼は再起動せずに次のスケジュールされたリクエストを待っていました。
Ubuntuの例。 CentOSでは、さらにいくつかのアクションを実行する必要があります。