More Related Content
More from anubis_369
徒手空拳で挑むサーバ管理
- 1. 徒手空拳で挑むサーバ管理
- 2. あんた誰？ ● こんにちは。中村です。 ● 特別な肩書きはない ● 俗にいう”炎上火消しエンジニア” ● インフラ系、ヘルプデスク系、社内SEが専門 ● @ITでコラム書いてます。 〜101回死んだエンジニア〜 http://el.jibun.atmarkit.co.jp/101sini/
- 4. こんな人向けな話 ● ツールに否定的なStaticおじさんと仕事をしてる人 ● 今使っているツールをもっと便利に使いたい人 ● 人と同じことをしたくない人 ● シェル芸人
- 6. 某M氏(自動化推進派)との会話 18禁 M氏: 真剣に「Ansible(というかYAMLというか設 定ファイル系プロビジョニングツール)の強みや弱 さ」を学びたくなった。 私: シェルでOK M氏: 帰れw 18禁
- 8. プロビジョニングツールの強み ● 冪等性 ● 複数のサーバを同時にデプロイできる ● コードを書くより分かりやすい記述で構成を書ける
- 9. プロビジョニングツールの弱み ● 冪等性を考えて構成を記述する必要がある ● 少数の構成にはオーバースペック ● 記述方式が独自 ● デプロイに特化していて変態技が使いにくい (当たり前)
- 12. 冪等性との付き合い方 ● あれば便利だが無くてもいい。 ● 冪等性に頼らず処理フローで解決もあり。 ● シェルで || や && で工夫する。 ● データの取得が目的なら重要度は高くない。 無理に追求しなくても いいんじゃね？
- 14. プロビジョニングツールの 記述方式について ● 覚えるのに労力がいる。 ● 汎用性は低い。(他のツールで使えない) ● 分かりやすいが知ってる人じゃないと分からない。 結局、シェル書いた時の欠点と あまり変わらないのでは？
- 15. これまでの結果を踏まえた比較 冪等性 ● 面倒なので追求しない。どうしても必要なら、 うだうだやらずにプロビジョニングツールを使おう。 複数のサーバでの同時実行について ● SSHの設定次第でシェルでも似たようなことできるんじゃないか？ 記述方式について ● 実はあんまり変わらないんじゃない？だったら、 分かりやすい書き方を考えよう。
- 16. 総括 ● 同じ機能を再現するのは難しい。 でも、同じ機能を実現する必要はない。 ● プロビジョニングツールの長所を取り込んだ使い方 は なんかできそうだ。 ● 足りないところを補い合うような使い方が いいんじゃないだろうか。
- 18. 一般的なシェルのイメージ ● 冗長 ● 整理してかけねぇ ● 分かりづらい ● 古い ● クソスクリプト ● ガソリンスタンド ● Final Fantasyの魔法 （魔法防御力が上がる）
- 19. よくあるクソスクリプト発生事案 1.histroyの出力を加工してスクリプト作成。 2.作成したスクリプトを繋げてスクリプトが肥大化。 3.変な条件分岐をねじ込んでカオス化する。 クソスクリプト発生！
- 20. シェルとの付き合い方 ● 条件分岐を多用しない。 ● プログラミング言語のノリでスクリプトを書くと、 後で泣く。 ● 自動化には向かない。 そこで、機構化という アプローチを考えてみた
- 21. 機構化とは ● 機構化 = 機能の構造化 ● 自動化への当てつけ。 (皆さん楽しそうなので対抗ネタを考えてみた) 自動化 インプットからアウトプットまでを自動で行う。 機構化 オペレーションのパターンに合わせて機能を 構造化する。オペレーションはあくまで自分で行う。
- 22. シェルで行う機構化 ● 記述したスクリプトをsouceコマンドで取り込む ● よく入力する値は変数を使用 ● ワンライナーのaliasを作る。 ● 処理をまとめるにfunctionを使用 ● 1処理1alias、1処理1function
- 23. 何が嬉しいか ● ファイル一つをsourceコマンドで取り込むだけで、 いろんなコマンドが使えるようになる。 ● 入力補完が効く。 ● コードの量が少ないのでメンテナンスが楽。 ● 他のツールの組込みや連携がやりやすい。 ● シェルスクリプトでsourceコマンドを書けば 同じように使える。 ● 再利用性が高い。
- 24. クソスクリプトと何が違うか ● 複雑な判断や条件分岐は人間がやることで、 コードの複雑さが大幅に減少。 ● 処理の目的を絞ることでコードの量を 大幅に削減。 ● コードを短く書くことで、 エラーが出た時の追跡がやり易い。
- 26. デプロイ系ツールとシェルの 動き方を比較する プロビジョニングツール 読みやすい設定ファイルを作成 → 作業PCで実行 → サーバでデプロイ → 結果を作業PCで取得 = 楽！ シェルスクリプト サーバにログイン → スクリプト及びファイルをコピー → アクセス件を設定 → 実行 → 結果のログを作業PC にscp → サーバからログオフ × 作業対象の数だけ繰り返す = クッソ面倒クセェ！
- 27. プロビジョニングツールの利便性を シェルで実現してみる ● 読んで意味が分かるような書き方 ● 作業PCでコマンドを実行して、 結果を作業PCで保存できるようにする。 ● ワンコマンドで複数サーバに対して処理。
- 28. 読んで分かる書き方 ● 普通の人はスクリプトにコメントを付ける。 ● ドキュメントを書いてスクリプトを コメントアウトする。 読んで分かり易いではヌルい。 そのまま読める方法で書いたものを実行する。 → スタイリッシュじゃない → ナウい。 1行のシェルで解決する。
- 29. 読んで分かる書き方 --実践編-- 1.普通にテキストファイルでドキュメントを書く。 2.実行するスクリプト部分の行頭に "> "を入れる。 3. eval “`grep -e '> ' <書いたドキュメント> | sed -e 's/> //g'`” ※ Sphinxというドキュメンテーションツールで 使われているコードの指定部分を抜き出す条件で シェルを組めば、Sphinxのソースコードとも 連携できる。
- 30. 作業用PCからコマンドを実行する --基本形-- ssh <user>@<host> '<コマンド>' これで十分。 コマンドはこれで十分だが、 SSHの設定をパスワード無しでセッションの 増えない方法で行う必要がある。 → この基本形、プラスSSHの使い方に工夫が必要
- 31. SSHをフレキシブルに使う --基本形-- ssh -F <設定ファイル> <設定ファイルに書いたhost> '<コマンド>' もしくは ssh -o '<沢山のオプション>' <user>@<host> '<コマンド>' これでプロジェクトごとに鍵ファイルが違っても簡単 に管理できる。 マスターモードを使うことでセッションの数を減らし たりできるが、時間がないので省く！
- 32. SSHの出力を自在に加工する --基本形-- ssh <user>@<host> '<コマンド>' | 変態的ワンライナー 変態的ワンライナーに興味がある方は、 シェル芸 でググろう！
- 33. ワンコマンドで複数サーバを処理 --スクリプト-- -comand(テキストファイル)-- function servers_exec () { for ser in `grep -e '^host ' <ssh設定ファイル> | sed -e 's/host //g' `; do ssh -t -F <設定ファイル> $ser “$1” done } --ssh設定ファイル-- host <ログイン先> hostname <ログイン先IP> user <ログインユーザ> 鍵ファイル指定 <同じフォーマットでいくつも>
- 34. ワンコマンドで複数サーバを処理 --実行-- # source ./command #実行 # servers_exec 'df -lh' → sshの設定ファイルに記載したサーバのdf -lhの結果 が出力される。 # servers_exec 'ip a' → sshの設定ファイルに記載したサーバのip aの結果 が出力される。
- 35. souceコマンドを使用する時の 注意事項 ● 何種類も実行しない。 → 変数やfunctionがカオスになる。 ● 目的の作業が済んだら一旦ターミナルを閉じる。 → 変数やfunctionをクリアするため。 ● 目的のファイルのカレントディレクトリで実行。 → 相対パスに完全対応するのが難しいから。 （解決策考案中） tmuxやscreenのような、端末を多重化できるツールと 併用すると幸せになれる。
- 36. 手元のツールにを使いこなすために ● souceコマンドでaliasやfunctionを読み込む手法は 他のツールを使用する際にも活用できる。 ● SSHの設定ファイルの書き方は、 デプロイツールでも役に立つ。 ● シェルでできることはシェルでやった方が早い。 何より、工夫を楽しむことで新しいやり方が 見えてくるのではないだろうか。
- 37. 以上、終了。