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
© Copyright 2025 ExpyDoc