ChangeManagement

IaaS Casual Talk #1 2016/03/29

Transcript

1. 既存と新規の環境整合性に苦労している話 @w4yh
2. 自己紹介 • @w4yh • 某SIer系iDCのインフラ技術者 • SaaSサービスZohoの古参ファン • SNMP/DNS/NTP/syslogなど裏方系など 各種デーモンさんのお守りを10年ちょっと • 元々はマネージドホスティングサービス担当 • IaaSサービスは担当を外れてしまったので 今はiDC運用基盤の内部用IaaSのみ ⇒今日のお話は内部用のIaaS運用時の出来事
3. 事業者として抱えている課題(ネタ) • バックアップをどこまで採るか 　Gmailがテープにまで採っているという 　　噂もあるというのに俺たちは… 　　 共有/分散FSの環境への保険のかけかた • DNSとNTP 共通基盤として提供していますが 最近維持管理コストがとっても増している いっそ8.8.. • バージョン管理＆標準化 　ツール化自動化の副作用？今日はこのお話
4. ホスティングサーバーのセットアップ 1.OSを最小インストール 2.NFSレポジトリから 不足RPMをインストール 3.NFSレポジトリにある 環境設定スクリプト実行 4.個別のカスタマイズは /home/provideradmin/custom 以下に使用ファイルを保管 管理ユーザー作成 各confの配布 サービス起動設定 監視用の設定 etc…. /usr/localとか /optとか /rootとか 散らかるのを防ぐ
5. ホスティングサーバーの更新適用 1.OSを最小インストール 2.NFSレポジトリから 不足RPMをインストール 3.NFSレポジトリにある 環境設定スクリプト実行 4.個別のカスタマイズは /home/provideradmin/custom 以下に使用ファイルを保管 セキュリティアップデート などのRPM更新はこの レポジトリを追加更新 ワークアラウンドなどの 設定変更は このスクリプトに実装 既存サーバーのリストアに 必要なものがあれば 作業フォルダに保管 早くここまで統一状態にしたい
6. 更新適用をどう行うかという課題 ・内部向けなのでコンパネなどで 処理を隠ぺいできていない ・セットアップ時未更新で稼働する時間は極力短くしたい しかしユーザーがセルフセットアップする場合は 　変更の適用やその後のテストが成功したことを 　リリース前に保証するステップを挟み込めない (案) 　--更新適用済のイメージへ素早く更新 --chefなどのConfig as Codeツール 　--cloud-init的な仕組み
7. 対策１:更新適用済のイメージへ素早く更新 ・人によってツールの得手不得手が生じていた 　いわゆる「自動化ツールの属人化」 ・なぜか当初はPackerのprovisionar: shellの 　更新だけが熱心に行われた ・既存サーバの更新をshellで行っていたのを バックポートしていた？ ・徐々にツラくなるpacker template 　 -せめて:shellはやめたい 　　 -それ以上にchefツラい(食わずツラい含む) 発生した問題: 適用のズレや遅延
8. 対策2: holo-cmの導入 ・「chefツラい」が根源のように感じたので、 　Config as Codeツールを変更した http://holocm.org/ ・機能的にはDeployerに近い ・機能もシンプルでTOMLの設定ファイルも明快 ・apt/dpkgやrpmでの管理もでき障壁が低い
9. (holo-cm/holo-build) $ cat example.pkg.toml [package] name = "example" version = "1.2" [[file]] path = "/etc/profile.d/example.sh" mode = "0755" content = ""“ PATH="/opt/example/bin:$PATH" LD_LIBRARY_PATH="/opt/example/lib:$LD_LIBRARY_PATH“ """ $ holo-build --debian < example.pkg.toml $ ls example_1.2-1_any.deb example.pkg.toml
10. 意外な結果: 問題点が移動しただけ ・空前のholoブーム ・既存作業からあらゆるものがholo化 整備された、とも言えるが.. ・Packer側を触る人がいなくなり、holo-cmが走る までは古い環境で稼働する状態に ・レポジトリのconfファイルをデプロイするやり方 が多く、初期は上書き事故が多発 ・広めといてなんだけどholoでいいの？
11. 現時点の落ち着き所(対策3) ワークフローの変更で対応 ・リリース前のチェックを入れておく ・イメージの更新はマイナーバージョン更新時のみ チェック方法はcloud-init(一部rc.local)で Serverspecテストを流し結果を通知 --対象テストはパッケージバージョンや 　　　ワークアラウンド（サービスの起動などはスコープ外) holocmはひとまず残す 　 --パッケージ一覧と適用済レシピをdpkg –lで見られる
12. マネージド型かつ内部向けなので対応が難しかった ・最初にワークフローや分限をやっておくべき ・「運用でカバー」を避けて「仕様で制限」に拘り過ぎた ・メンテナンスウインドウ設定を見直したり 　構成管理ツールを高頻度に稼働する方式もいいのかも 正直holoは後悔もしている ・rpm対応が限定的&Windows未対応なので 　移行は考えている ・一部でユニークツール発掘が流行ったことには 後悔しかない