Clever Geek Handbook

日常業務のシェフ

システム管理者は毎日、些細な一連のコマンドによって何らかの形で解決しなければならないタスクに直面しています。 時にはそれはとんでもないことになる：



インフラストラクチャ管理者は、すべてのサーバーに交互にアクセスして、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上にあります。

ここでインストールパッケージを取得します 。 



# cd ~; wget https://web-dl.packagecloud.io/chef/stable/packages/ubuntu/trusty/chef-server-core_12.1.2-1_amd64.deb # dpkg -i chef-server-core_12.1.2-1_amd64.deb


パッケージをインストールしたら、「再構成」を実行して、ユーザーと組織を作成する必要があります。 



 # chef-server-ctl reconfigure # chef-server-ctl user-create grey Sergey K grey@mydomain.lan superpassword123 --filename /etc/chef/grey.pem # chef-server-ctl org-create vst "VST Consulting, Inc." --association_user grey --filename /etc/chef/vst-validator.pem


組織のメカニズムにより、非常に便利なテストサイトを整理したり、1台のサーバーですべての顧客を結合したりできます（ああ、お勧めしません）。

ここで説明した情報に加えて、Webインターフェースなどの追加コンポーネントのインストール方法に関する情報があります。



また、いくつかの設定を修正し、必要なディレクトリを作成する価値があります。 



 # cat /etc/chef/knife.rb current_dir = File.dirname(__FILE__) log_level :info log_location STDOUT node_name "grey" client_key "#{current_dir}/grey.pem" validation_client_name "vst-validator" validation_key "#{current_dir}/vst-validator.pem" chef_server_url "https://chef/organizations/vst" cookbook_path ['/root/chef-repo/cookbooks'] # ln -s /opt/opscode/embedded/bin/knife /usr/bin/knife # ln -s /etc/chef /root/.chef # git clone https://github.com/opscode/chef-repo.git # knife ssl fetch && knife ssl check


簡単な料理の本


Chefで最も人気のあるツールはクックブックです。 特定のレシピが含まれています。

レシピは、ファイルテンプレート、変数などを使用してサーバー上で特定のアクションを実行するためのテンプレートです。 特定の作業結果を実装します。 料理のように、私たちの目標は、すぐに食べられる「スープ」を手に入れることです。



例として、Javaで自己記述されたデーモンアプリケーションを準備するためのレシピを作成します。これは、構成と一緒にいくつかのサーバーに配布する必要があります。



空白を作成します。 

 # cd /root/chef-repo/cookbooks # knife cookbook create prog # cd prog; ls attributes CHANGELOG.md definitions files libraries metadata.rb providers README.md recipes resources templates


このプロジェクトでは、 属性、レシピ、テンプレートディレクトリ、および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' #    %w{ ubuntu debian centos redhat fedora oracle windows}.each do |os| supports os end #  %w{ java }.each do |cb| depends cb end




この例では、Javaレシピへの依存が、その不在の問題を回避するために示されています。 Javaを含む既製のレシピがあります。



次に、 recipesディレクトリにdefault.rbファイルがあります。 次のフォームに持ち込みます。



のような 
 # # Cookbook Name:: Prog # Recipe:: default # # Copyright 2015, vstconsulting # # All rights reserved - Do Not Redistribute # #  jdk  1.7 node.override['java']['jdk_version'] = '7' include_recipe "java" #   case node['platform_family'] when 'debian' include_recipe 'prog::deb' when 'rhel' include_recipe 'prog::rhel' when 'windows' include_recipe 'prog::windows' else Chef::Application.fatal!('Attempted to install on an unsupported platform') end package_name = node['prog']['package'] remote_file 'prog' do path "#{Chef::Config[:file_cache_path]}/#{package_name}" source "http://domain.lan/packages/#{package_name}" mode 0644 end package 'prog' do source "#{Chef::Config[:file_cache_path]}/#{package_name}" end service 'prog' do action [:enable, :start] end template "#{node['prog']['conf_dir']}/main.conf" do source 'main.conf.erb' notifies :restart, 'service[prog]', :delayed end




順番に：



実際、ほぼすべてのパッケージをほぼすべてのシステムにインストールできるユニバーサルレシピについて説明しています。



次に、属性を調整する必要があります。 属性は、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'] %>




上記の後に、テンプレートの必要な属性をどのように置き換えることができるかは明確だと思います。 サイクルを使用することもできますが、これには焦点を合わせません。



言及しませんでしたが、テンプレートの追加レシピも作成する必要があります。 



 # cat recipes/deb node.override['prog']['package'] = "#{node['prog']['prog_name']}.deb" # cat recipes/rhel node.override['prog']['package'] = "#{node['prog']['prog_name']}.rpm" # cat recipes/windows node.override['prog']['package'] = "#{node['prog']['prog_name']}.msi"


はい、そのように。



レシピをサーバーにアップロードします。 



 # knife cookbook upload --all


環境


次に、パラメーターを取得する単純な環境の例を作成します。

これは必ずしも必要ではありませんが、何がどのように機能するかを理解するために非常に役立ちます。 



 # export EDITOR=nano # knife environment create someserver -d "Environment for group of servers where somejavademon will work."


指定された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がインストールされる多くのホストで使用できます。



展開する


次に、最も重要なこと、つまりサーバー間での製品の配布について説明します。



サーバーに必要なレシピをインストールするには、次を実行する必要があります。 



 # knife bootstrap --run-list "recipe[prog]" server1.domain.lan -E someserver -P rootpasswordfromnode


スクリプトを書くことを妨げるものは何もありません。 



 #!/bin/bash for i in {1..100}; do knife bootstrap --run-list "recipe[prog]" server$i.domain.lan -E someserver -P rootpasswordfromnode done


しばらくすると（5分/ 30分/時間/日）、100台すべてのサーバーが完全に作動可能になります。

いずれにせよ、Chefサーバーのインストール、レシピとenvの作成、およびデプロイは、各サーバーにパッケージを手動でインストールするよりも少ない時間または同じ時間で完了します。 しかし！ すべての準備が整っていれば、再インストールにかかる時間ははるかに短くなり、さらに労力がかかります。 最も重要なことは、手動で何かをする必要がなくなったことです。 サーバーのリストを指定し、スクリプトを実行し、Habréの新しい出版物を読むだけで十分です。



他に何ができますか？


これはかなり哲学的な質問です。

knife-windowsをインストールできます（インストールする必要があります）。 難しいことではありませんが、質問があれば、いつでもお手伝いします。

スーパーマーケットから既製のレシピの束をダウンロードして、好きなサーバーの数にあなたの心が望むものを展開できます。

すべての機会に独自のレシピを作成し、サーバーのメンテナンスを減らしてOSのインストール（PXEで非常によく自動化されます）、機器の交換、および監視を行うことができます。

ChefをOpenStack（ある場合）に接続し、新しいサーバーとサービスをバッチでデプロイできます。 ここで、それを行う方法を見つけることができます。 特にCloud-InitとChefを使用して既に理解している場合は、特に複雑なことはありません。



何かを追加するのを忘れた場合は、コメントで修正してください。



この投稿が、誰かがChefとサーバーまたはオフィス作業の雑用を理解するのに役立つことを願っています。



UPD： OpenStackのcloud-configサンプルを追加することにしました：

＃cloud-config 
 #cloud-config packages: - chef chef: install_type: "packages" force_install: false # Chef settings server_url: "https://chef-server.lan/organizations/organization_name" validation_name: "organization_name-validator" validation_key: | -----BEGIN RSA PRIVATE KEY----- .................................................. -----END RSA PRIVATE KEY----- run_list: - "recipe[somerecipe]" output: {all: '| tee -a /var/log/cloud-init-output.log'} runcmd: - service chef-client restart




起動後、VMはchef-clientをインストールし、chef-serverと通信するように構成します。

シェフがすぐにレシピを受け取り、しばらく待たないように、クライアントの再起動が必要です。 何らかの理由で、彼は再起動せずに次のスケジュールされたリクエストを待っていました。

Ubuntuの例。 CentOSでは、さらにいくつかのアクションを実行する必要があります。



More articles:


All Articles