Red Hat Enteprise Linux運用自動化のキモ

Red Hat Enteprise Linux運用自動化のキモ
Kazuo Moriwaka
Solution Architect, Red Hat K.K.
4 November 2015
●
●
Agenda
構築運用自動化の理想
–
自動化がうまくいくとどうなる?
–
なぜ自動化が必要?
自動化したい「キモ」と関係するOSS
–
●
自動化したいものは……?
Red Hat Satellite 6でどこまでできる?
構築運用自動化の理想
●
●
●
運用管理を改善したい
IT予算のかなりの割合は運用維持
人が手間暇をかけるところを減らしたい
→各種の作業を自動化し、社内標準を作っていく
– 人間にはパッチをあてられないけど、
スクリプトならテストして修正できる
– 同じ作業を何回も繰り返すのはコンピュータの得意分野
→ 初期構築からできる限り自動化
今までのシステムを標準にあわせるのが困難でも、
これから構築するシステムは標準化する
– 標準化して、全システムが揃うのは数年後
→数年後を見据えて技術選定・標準化作業を行う
●
●
理想的には……?
例: 「アプリケーションの負荷が高い、サーバを増やそう」
– 自動的にネットワーク設定
– 自動的に仮想マシンor実機にソフトと設定を配備
– 自動的に初期設定
– 自動的にロードバランサに登録
– 利用を開始
例「定期的な環境の更新をしよう」
– 更新したイメージや環境をテスト環境に配備
– テストしてOKでした→本番環境へ配備
– テストしてNGでした→問題解決して再度配備
●
●
そんなこと本当にできるの?
事例: IKEA
– 35ヶ国、400サイト
– 3500システムのRed Hat Enterprise Linux
– RHELの最新版への標準化を強制
– PCI DSS対応のため少なくとも1ヶ月に1回は更新
– ShellShockへの対応: 2人で2時間半
– Linux担当運用管理者: 17人
最初からこんな状態だったの？→ いいえ
– 10年近く標準化を進めてきた成果
– Red Hatもコンサルティングや専任サポートで支援
標準環境の改善サイクル
新アプリケーション配備
解決 = 標準環境の改善
問題発生
標準環境を強制
同じ問題に何回も対応するのか?
●
標準化なし: チェックリストがのびていく
●
標準化あり: 標準環境を改善する
継続的に
改善しつづけていく
●
●
スクリプト一発で仮想マシンやコンテナ、
ネットワークが用意できる世界
あるシステムが実際に使えるようになるまで
– 仮想マシン作成
– ネットワーク設定
– ソフトウェアのインストール
– OS, アプリケーション設定
OpenStackやクラウド環境、コンテナで既にある技術
– 「仮想マシンは5分で準備できた。3日かけて設定しよう」
→ あれ？？？何かおかしいぞ？？？
– スピードを活かすには構築・運用の自動化が必須
仮想マシンイメージのクローンで十分か?
●
●
●
その仮想マシンイメージ、いつのものですか?
セキュリティ上、塩漬けはありえない
– PCI DSS(クレジットカード業界のセキュリティ標準)では
脆弱性への対応を1ヶ月以内に実施する
●
そして3ヶ月毎に監査で確認
– たとえば5年後、既知の脆弱性を放置して運用していても
問題ないと思いますか?
思考実験: 一ヶ月ごとに更新すると仮定して……
– アプリケーションの数だけVMイメージを更新
– テストを行ったのち、新しいイメージを再配備
→ 自動化しないとビジネスの要求に追いつけない
これを実現するには……?
●
●
プログラミングでソースコードからバイナリを作成するよう
に、ソース(設定や指定)からシステムを作成したい
何も無いところから本番環境構築までを自動化する
– 手作業による抜け・漏れ・単純ミスの排除
●
プログラマがソースコードを手で写経したら？
→間違い頻発
– さらなる自動化へのインフラになる
●
バージョン管理システムによる変更追跡
●
設定変更時に高い頻度で自動テストを実施
自動化したい「キモ」とOSS
●
●
●
OpenSourceと自動化
構築運用の自動化は世界共通の悩み
– 実際に自動化する人もたくさんいます
自動化のソフトもOpenSourceで開発
– 各種の作業を自動化するためのOSSが非常に多くあります
対象とする課題や解決へのアプローチに違い
– 何を自動化するのか
– どうやって自動化するのか
– より良い解決方法は何か
課題(キモ)と関連OSSを見ていきましょう
理想に近づくために
標準化・自動化したい「キモ」
A: OSインストール(ベアメタル、仮想化、各種クラウド）
B: 設定（初期設定、異常検出、変更）
C: ソフトウェア配備（導入、アップデート、現状確認）
D: ライフサイクル管理（テスト環境の用意、本番環境に
テスト環境でテスト済みのものだけを配備）
E: セキュリティ監査
F: ログ管理（パフォーマンス、イベント）
G: システムのテスト
●
●
●
A: OSインストール
(ベアメタル、仮想化、各種クラウド環境）
いろいろな環境へいろいろな方法で導入
– RHELインストーラを自動化: kickstart
●
インストール前後でのスクリプト実行、自動登録
●
必要ソフトウェアの導入、各種初期化
– イメージクローンによる導入
●
各種クラウドAPIへの対応
– コンテナによる導入
システム毎に何を構成するべきか異なる
– システムとその役割の対応づけ
– 役割に応じた構成変更(パッケージ構成etc.)
OSSでの取り組み:
– Cobbler/Koan, Oz, Foreman, openQRM, vagrant
B: 設定（初期設定、異常検出、変更）
●
●
設定の自動化はここ5〜6年ほど特にホットな話題
最近の設定管理システムの特徴は？
– 定義→実際の設定や操作と、その逆をモジュールとして作成
●
各コミュニティでモジュールを作成、共有
既存設定が収集できる
– 「結果としてどうなってほしいか」の希望を定義する
●
希望と現状の差分を確認→必要な変更を洗い出し
●
再設定コスト低下、定期的な再設定実行による維持
– 初期の設定だけでなく管理外の設定変更検出や再設定も可
OSSでの取り組み:
– Puppet, Chef, Ansible, Salt
●
–
●
逆変換により設定管理システムが現状を認識できる
●
C: ソフトウェア配備
（初期導入、アップデート、現状確認）
ソフトウェア配備の特徴
– 各ベンダから継続的に更新が提供されつづける
–
–
●
「ある脆弱性の影響をうけるシステムはどれ?」
資産管理、コンプライアンス遵守のため利用数管理
設定やソフトウェアの更新作業は複雑なので避ける考え方
– 構築の自動化を推し進めて「アップデートするのではなく
環境を毎回0から構築」する Immutable Infrastructure
– Dockerのイメージ作成はこの考え方に近い
OSSでの取り組み
– Spacewalk, Pulp, Katello, Docker, rpm-ostree
●
●
更新情報の同期、集積
脆弱性やバグなどの問題との対応関係管理
●
D: ライフサイクル管理
（テスト環境でテストされたものだけを本番配備）
●
●
設定やソフトウェアについて、いきなり本番環境に配備するのでは
なく、テストしたものだけを配備したい
– 作業環境→テスト環境→本番環境
よくあるつらい現状:
– テスト環境と同じ手順を本番でも行う
●
●
更新手順を作るためのトライ&エラーの副作用は?
理想に近い:
– 仮想マシン/コンテナイメージのクローンを行う(設定も同一)
– 構築を自動化して0から作り直す
OSSでの取り組み
– 仮想マシンのクローン+設定管理
– OpenShift等の各種PaaS基盤, Katello, tleap Open ALM
●
E: セキュリティ監査
●
●
セキュリティ監査を自動化したい
– 全部の自動化は困難
「サーバが入っているラックに鍵かかってますか?」
– でも簡単に自動化できる物もあるよね……?
OSSでの取り組み:
– nmap, tripwire, snort, OpenVAS
– OpenSCAP, SCAP Security GuideによるSCAP実装
●
SCAP: セキュリティ規格のチェック項目を定義し、
自動チェック可能にするための規格
F: ログ管理（パフォーマンス、イベント）
●
●
●
●
パフォーマンスログ集積と可視化, モニタリング
– rrdtool, PCPなどで10年以上前からある話題
最近の話題: ノード数の増減や大規模クラスタに対応したい
→ DB, 検索技術をベースとした分析に注目
予防保守の観点から
– ログ分析からトレンドを確認
→ 増設計画、リソース不足の予兆検知
→ 負荷に応じたサーバ台数の自動調整
OSSでの取り組み:
– rsyslog, logstash, fluentd, ElasticSearch, Kibana, PCP,
Nagios, Zabbix, Cacti
G: システムのテスト
●
●
テストを自動化したい
– プログラムを作る時にテストを行うように
設定を作る時もテストを行う
●
その設定で、やりたかったことが実現できているか?
●
設定管理システムから独立したテストを行いたい
– システムによってやりたいことは変わるので
完全に自動的するのは困難
– でも簡単に自動化できるものもあるよね……?
OSSでの取り組み:
– RSpec, ServerSpec, セキュリティ監査ツールの転用
集中管理(=可視化)したいもの
●
●
●
●
●
●
●
●
ソフトウェア
設定
IPアドレス、ホスト名
Identity管理(ユーザ、グループ、サービス、ホスト、
証明書等)
パフォーマンスモニタリング
各種イベントログの収集・モニタリング
バックアップ
セキュリティ監査記録
Red Hat Satellite 6でどこまでできる?
Red Hat Satelliteとは?
Red Hat Enterprise Linuxの
運用管理ソフトウェア
●
パッケージ、設定、コンテナイ
メージなどのコンテンツを維持
(pulp)
●
多数のRHELを集中管理(foreman)
●
各種環境での自動構築(foreman)
●
設定の集中管理(puppet)
●
ライフサイクル管理(katello)
– テスト済みバージョンを
本番環境へ配備
●
サブスクリプション管理
(candlepin)
Satelliteに登録するだけでもそれなりに……
Red Hat Satelliteには各種の自動化機能がありますが、
単純にSatelliteへRHELを登録するだけでも色々メリットがでます
●
(ほぼ完全な)自動的にメンテナンスされるシステム台帳
– どのシステムに何が入っているか?
– この脆弱性の影響うけるシステムはどれ?
– アップデート作業の抜け漏れチェック
●
高速な導入、隔離環境でのアップデート
– LAN内で完結するので導入や更新作業が高速
– インターネットから完全に隔離したRHELの更新も簡単
●
別マシンで更新データを入手、DVDなどのメディアで
取り込めます
標準化・自動化したいもの
Red Hat Satelliteでできる範囲は……?
A: OSインストール(ベアメタル、仮想化、各種クラウド環境）
B: 設定（初期設定、異常検出、変更）
C: ソフトウェア配備（初期導入、アップデート、現状確認）
D: ライフサイクル管理（テスト環境の用意、本番環境にはテスト環境で
テストされたものだけを配備）
E: セキュリティ監査（OS、ミドルウェア、各種設定）
→OpenSCAPとの統合で部分的に対応
F: ログ管理（パフォーマンス、イベント）
→Satelliteで操作する範囲のイベント、ローカルでの操作も
パッケージと設定は検出可能。パフォーマンスログの管理は未対応
G: システムのテスト
→カバーできていません
●
●
●
●
●
●
●
●
集中管理したいもの
Red Hat Satelliteでできる範囲は……?
ソフトウェア
設定
IPアドレス、ホスト名
Identity管理(ユーザ、グループ、サービス、ホスト、証明書等)
→ Red Hat Identity Manager(RHEL同梱)と連携
パフォーマンスモニタリング
→エージェントの配布やデータ収集設定
各種イベントログの収集・モニタリング
→syslog設定, PCP設定など
バックアップ
→エージェントの配布
セキュリティ監査記録
→OpenSCAPとの統合により部分的に可
おさらい
●
●
●
システム運用・構築を自動化することがクラウドや
コンテナをはじめとした環境を活用するには必要
– 夢物語ではなく実際に活用している企業があります
– 継続的な取り組みが必要
運用管理の自動化には様々な課題があり、取り組み方も
様々です
– OSSでの取り組みが多数行われています
Red Hat SatelliteはRHELの運用改善に取り組んでいます
– コンサルティングや構築支援などご相談ください
Thank You
おまけ: Red Hat Satellite 6とは?
Red Hat Satelliteとは?
Red Hat Enterprise Linuxの
運用管理ソフトウェア
●
パッケージ、設定、コンテナイメージ
などのコンテンツを維持(pulp)
●
多数のRHELを集中管理(foreman)
●
各種環境での自動構築(foreman)
●
設定の集中管理(puppet)
●
ライフサイクル管理(katello)
– テスト済みバージョンを
本番環境へ配備
●
サブスクリプション管理(candlepin)
プロビジョニング
●
●
Foremanによるプロビジョニング
– ベアメタル、仮想化、各種クラウド環境へのインストール
●
kickstartによる自動構築
●
イメージのクローンによる自動構築
– グループ化、自動登録
– 新規ハードウェアの自動検出
インストールと初期設定の自動化により新規サーバの構築を
省力化
設定管理
●
●
Puppetによる設定管理
– 望ましい状態を宣言的に定義する
– 予想していない変化があれば検出して緩和する
– 変更の監査とレポート
Satelliteへ登録した各種factを利用して設定
コンテンツ管理
●
●
Katelloによるコンテンツ管理
ソフトウェアと設定を統合した「コンテンツ」を管理
–
–
Red Hat製品の他、Yumリポジトリ、Puppetリポジトリ、
Dockerレジストリを管理
テストされたものだけを配備するライフサイクル管理
セキュリティポリシーの遵守
●
セキュリティ問題への緊急対応にも対応
Red Hat の全インフラ製品に加えてサードパーティ製品や
ユーザ独自のコンテンツも配備可能
●
●
サブスクリプション管理
●
●
●
Candlepinによるサブスクリプション管理
– 製品・サポートレベル・期限などを集中管理
– 各システムとサブスクリプションの対応付け
– 正確な本数と使用状況を維持
– グループ毎の利用状況管理も可能
部門毎のコスト管理やサーバ毎の更新
更新漏れによるサポート不能の予防
その他いろいろな機能……
●
●
●
●
複数組織、複数拠点への対応
– 部門ごとのサブスクリプション割り当て
– 拠点間のネットワーク通信の削減
DNS, DHCP, TFTPサーバの統合(foreman-proxy)
– ベアメタルプロビジョニング
Red Hat Identity ManagerまたはActive Directoryへのホスト
自動登録
OpenSCAPによる自動セキュリティ監査
– ポリシーへの適合をチェック、レポート、記録
●
●
Satelliteによるシステムの"コンテンツ管理"
入れ物となる仮想マシンや物理マシンの上に「コンテンツ」
として以下を考える
– どのパッケージが含まれるか
– どの設定がされているか
Satelliteでは
– 新旧全てのパッケージと設定をリポジトリに集約
– リポジトリから適切な組み合わせを配備することでシステ
ムを構築する
コンテンツ管理
Yum,
Puppet
リポジトリ
リポジトリ群
●
●
●
●
製品に含まれる
リポジトリを指定
製品
フィルタ
パッケージと設定を含むリポジトリを選択して「製品」を定義
製品内の必要/不要なコンポーネントを指定してフィルタした
サブセット(CV: Contents View)を作成
複数のCVを合成してCVを作成することもできる
(CCV: Composite Contents View)
– 例:「RHEL7最小」＋「Webサーバ」
システムにはCVのスナップショットが導入される
Content viewの合成
Content view
●
Red Hat Enterprise Linux 7
●
Web server
●
Red Hat JBoss Middleware
●
EPEL etc.
Composite content view
例: SOE for web
ライフサイクル管理
●
LIB
DEV
QA
PROD
Satelliteは「CVのライフサイクル」を管理する
– 必要な製品とフィルタを指定してCVを作成
– 「publish」することである時点CVのスナップショットを作成。
ライブラリへ登録する
●
publish時点の最新パッケージと設定を利用
– 各段階でテストを実施
– 問題がなければスナップショットを
開発環境→QA環境→本番環境と出世(promote)させていく
●
●
Satelliteのゆるやかな導入
SatelliteはRHEL運用のベストプラクティスを実装
– 現状の運用とのギャップはそれなりにある→徐々に導入
導入例:
1. RHELをSatelliteに登録する
●
自動的にメンテナンスされる台帳
●
サブスクリプション管理
●
修正が必要なシステムの洗いだし
●
ローカルなので更新が速い・air gapped環境への対応
2. システムのグループ化を行い権限管理と連携する
3. OpenSCAPによる自動セキュリティチェックを行う
4. テスト環境を準備、ライフサイクル管理
Red Hat Forum 2015
Energize Your Enterprise

Download Report