Chefの限界
サーバ構築や構成管理の自動化ツールとして用いられるChef。
Chefは便利ですが、できないことに関してイメージを持つことも重要です。
今回はChefに絞っていますが、大きな観点としてはAnsibleやPuppetのような他ツールに関しても同様です。
ざっくりした結論から言えば「コマンド/スクリプトで実行できないことはChefで扱えない」です。
本記事では、上記主張に関してリソースタイプを中心に説明してました。
Chefについて
Chefではサーバに対する設定が書かれたファイルをレシピ(Recipe)と呼び、
レシピの開発者は、管理する環境をリソース(resource)として記述していきます。
リソースとはユーザやファイルといった環境を指し、各リソースにはアクションが用意されています。
以下に、Chefでよく見るリソースを5つピックアップしました。
それぞれのリソースが持つアクションについても記載しています。
| リソース名 |
アクション |
| user |
create,lock,manage,modify,nothing,remove,unlock |
| group |
create,manage,modify,nothing,remove |
| file |
create,create_if_missing,delete,nothing,touch |
| directory |
create,delete,nothing |
| package |
install,nothing,purge,reconfig,remove,upgrade |
そして、レシピの文法ですが
リソースタイプ "リソース名" do
属性 "属性値"
action :アクションタイプ
です。
属性(attiribute)とはリソースへの設定値の項目であり、
例えばdirectoryの属性にはgroup、mode、owner、path、recursive、rightsがあります。
UNIX系に通じている方であれば以下のレシピを見れば実現したい状態は理解できると思います。
directory "/foo/bar/baz" do
owner 'root'
group 'root'
mode '0755'
action :create
end
Chefではこのような定義済みのリソースとそれに付随するアクションと属性を利用することで、
従来は各環境にシェルスクリプトで実施していた、または手作業で実施していた作業を省力化しながら実現できます。
ちなみに、公式ドキュメントに記載がある全リソースを以下に記載しました。
数が多いですが、リソース名を見ればChefでどのような範囲が自動化できるのかがイメージできると思います。
apt_package resource
apt_preference resource
apt_repository resource
apt_update resource
bash resource
batch resource
bff_package resource
breakpoint resource
build_essential resource
cab_package resource
chef_gem resource
chef_handler resource
chocolatey_config resource
chocolatey_package resource
chocolatey_source resource
cookbook_file resource
cron resource
cron_access resource
cron_d resource
csh resource
directory resource
dmg_package resource
dnf_package resource
dpkg_package resource
dsc_resource resource
dsc_script resource
execute resource
file resource
freebsd_package resource
gem_package resource
git resource
group resource
homebrew_cask resource
homebrew_package resource
homebrew_tap resource
hostname resource
http_request resource
ifconfig resource
ips_package resource
kernel_module resource
ksh resource
launchd resource
link resource
locale resource
log resource
macos_userdefaults resource
macports_package resource
mdadm resource
mount resource
msu_package resource
ohai resource
ohai_hint resource
openbsd_package resource
openssl_dhparam resource
openssl_ec_private_key resource
openssl_ec_public_key resource
openssl_rsa_private_key resource
openssl_rsa_public_key resource
openssl_x509_certificate resource
openssl_x509_crl resource
openssl_x509_request resource
osx_profile resource
package resource
pacman_package resource
paludis_package resource
perl resource
portage_package resource
powershell_package resource
powershell_package_source resource
powershell_script resource
python resource
reboot resource
registry_key resource
remote_directory resource
remote_file resource
resource
rhsm_errata resource
rhsm_errata_level resource
rhsm_register resource
rhsm_repo resource
rhsm_subscription resource
route resource
rpm_package resource
ruby resource
ruby_block resource
script resource
service resource
smartos_package resource
solaris_package resource
ssh_known_hosts_entry resource
subversion resource
sudo resource
swap_file resource
sysctl resource
systemd_unit resource
template resource
timezone resource
Use with the chef_handler resource
user resource
windows_ad_join resource
windows_auto_run resource
windows_certificate resource
windows_env resource
windows_feature resource
windows_feature_dism resource
windows_feature_powershell resource
windows_firewall_rule resource
windows_font resource
windows_package resource
windows_pagefile resource
windows_path resource
windows_printer resource
windows_printer_port resource
windows_service resource
windows_share resource
windows_shortcut resource
windows_task resource
windows_workgroup resource
yum_package resource
yum_repository resource
zypper_package resource
zypper_repository resource
本題: Chefができないこと
OSによって対応していないものもありますが、上で挙げたようなリソースに関しては用意されているアクションの範囲でChefで操作することが可能です。
では、リソースが用意されていなければ対応ができないのでしょうか。
もちろん、対応できます。
対応法としては以下の３点です。
- 非公式で作成済みのリソースを利用する
- 任意のコマンドが実行できるリソースを用いる
- リソースを自作する
例えば、社内で独自のリソースが用意されていればそれを再利用して対象リソースを操作できます。
Chefのリソースには任意のコマンドやシェルスクリプト、Rubyのスクリプトを記述できるものがあります。
よって、コマンド化やスクリプト化ができているものはChefに取り入れることができます。
そして、リソースはなければ作成することもできます。以下が公式ドキュメントです。
Custom Resources — Chef Docs
リソースの自作は再利用性を高める点では効果がありますが、そこで記述できる内容の上限もまた、任意のコマンドまたはスクリプトの発行です。
要は、コマンドで実行できない/スクリプト化できないことはできません。
GUIでの操作でバイナリファイルが変更されるもの、といったものはChefでは扱えません。
終わりに
本記事では、Chefの概要とできないことについて記載しました。
ただし、スクリプトとの大きな違いである
これらの点がChefやその他の自動化ツールの大きな強みです。
よって、事前に用意されているリソースに対する作業をChefに置き換えることには上で挙げたメリットを享受できます。
逆に、GUI操作に限定した作業であればRPAツールで自動化する、既に構築スクリプトが用意されてるものはChefに取り入れない、など自動化範囲の切り分けを適切に行うのが重要だと思います。
以上となりますが、かなりざっくりした内容なので、ケースバイケースの指摘があればぜひコメントお願いします。
