Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ChangeManagement

81ea84ebf9bc06e1a7d4bbaed39861b3?s=47 w4yh
March 29, 2016
50

 ChangeManagement

IaaS Casual Talk #1 2016/03/29

81ea84ebf9bc06e1a7d4bbaed39861b3?s=128

w4yh

March 29, 2016
Tweet

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. 対策1:更新適用済のイメージへ素早く更新 ・人によってツールの得手不得手が生じていた  いわゆる「自動化ツールの属人化」 ・なぜか当初は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未対応なので  移行は考えている ・一部でユニークツール発掘が流行ったことには 後悔しかない