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

Kazuo MoriwakaSolution Architect, Red Hat K.K.

4 November 2015

● 構築運用自動化の理想– 自動化がうまくいくとどうなる?– なぜ自動化が必要?

● 自動化したい「キモ」と関係するOSS– 自動化したいものは……?

● Red Hat Satellite 6でどこまでできる?

Agenda

構築運用自動化の理想

運用管理を改善したい● 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

ライフサイクル管理

DEV QA● Satelliteは「CVのライフサイクル」を管理する

– 必要な製品とフィルタを指定してCVを作成– 「publish」することである時点CVのスナップショットを作成。ライブラリへ登録する

● publish時点の最新パッケージと設定を利用– 各段階でテストを実施– 問題がなければスナップショットを 開発環境→QA環境→本番環境 と出世(promote)させていく

LIB PROD

Satelliteのゆるやかな導入● SatelliteはRHEL運用のベストプラクティスを実装

– 現状の運用とのギャップはそれなりにある→徐々に導入● 導入例:1. RHELをSatelliteに登録する

● 自動的にメンテナンスされる台帳● サブスクリプション管理● 修正が必要なシステムの洗いだし● ローカルなので更新が速い・air gapped環境への対応2. システムのグループ化を行い権限管理と連携する3. OpenSCAPによる自動セキュリティチェックを行う4. テスト環境を準備、ライフサイクル管理

Red Hat Forum 2015Energize Your Enterprise