CD(継続的デリバリー)手法を用いたサーバシステム構築の自動化 - OpenStack最新情報セミナー(2016年12月)

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVEDCOPYRIGHT © 2014 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVEDCOPYRIGHT © 2015 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED
(※)
IaC: Infrastructure as Code (インフラのコード化)
CD: Continuous Delivery (継続的デリバリー）

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED
自己紹介
発表者
• 吉川晃平
(よしかわこうへい)
• 住処：神奈川県藤沢市
• 趣味：スキー
• 好きな食べ物：
ラーメンパスタから肉チーズに改宗
経歴
• インフラ系システムエンジニア
• 海底ケーブルの監視GUI
• ISPのホームページ公開システム
• オンプレミスのWebポータル共通基
盤
• 興味：OpenStack,AWS,
Azure,Juju/MAAS,IoT,LXD・・・

発表内容
1. 弊社(三菱電機インフォメーションシステムズ:MDIS)のご紹介
2. 概要
3. 目的・モチベーション
4. しくみ
• デモ１：マスターサーバの構築
• デモ２：クローンVMの構築
5. デモンストレーション (ビデオ)
6. 考察とまとめ

MDIS 会社概要
三菱電機(株)
の情報システム
事業が分社化
し発足

拠点
鎌倉市(大船
駅)を技術拠点
に本社・支社を
全国配置

主な事業
高い技術力と豊かな発想で、社会に密着した多彩なソリューションを提供

MDISのOSS活用ソリューション
通信キャリア・サービスプロバイダー様向け、OSSを活用したシステムの導入支援。
http://www.mdis.co.jp/solution/oss/

発表の概要

最新のマス
ターサーバ
VM
VM
VM
マスターサーバを常に最新化最新マスターから複数のVMを生成
生成結果の
レポート
システム環境生成指示
ジョブ実行
概要(詳細はのちほど)
システム構築を自動化する仕組みを検討しプロトタイプを作りました
ユースケース(活用シーン)
– 数十台のサーバを迅速正確に構築したい
– 脆弱性対応などのため多数のサーバのOS,ミドルウェアを最新化・動作確認したい
– インフラ構築における属人性やオペミスをなくしたい
自動化の仕組み

モチベーション

モチベーション
「あらゆる基盤上で迅速に
システム構築・デリバリを継続できる機構」
を活用したい。

車輪の再発明ではないか？
PaaS使えば
CloudFormation
Heat vRO
Vagrant
Packer
Teraform
CloudFoundry
OpenShift
Docker使えば
コンテナオーケストレータ Juju
MAAS
いまさら
CI/CDなんて

そんなカッコいいもんじゃないです
あたえられた環境
きめられた運用
契約上の制約
他システムへの
影響
いろいろな
基盤
小さな権限
パブリッククラウド
オンプレ
商用は
いじりたくない
きめられた
リソース
動的な運用
はNG
OSIレイヤの低い
システム
お客様の基盤運用でシステムをつくらせていただく制約
・・・の中でなんとかしたい。

SI業からみたインフラ自動化・標準化
SIとしてシステム構築にかかわる場合、案件・顧客が利用するインフラ基盤上にシステムを構築す
る場合が多い。そのため自動化を画一的に適用することが難しい。
■自社サービスを
ターゲットとする場合
• サービス構築を最短・
最小負荷にするための
基盤整備
• 基盤の標準化やサー
ビス粒度の画一化を
検討できる
基盤標準化
サービス構築
■SI事業者
• 顧客が利用する
インフラ基盤にシ
ステムを構築
• 標準化するのが
難しい
• 1システムのため
にPaaSやオーケ
ストレータを導入
するのが難しい
Aシステム構築
Bシステム構築
Cシステム構築

「本当にほしいもの」
「お客様のあらゆる基盤上で迅速にシステム構築・デリバリを継続できる機構」
– システム構築の急速なクラウドファースト化に対応するために。
– レガシーシステムのモダン化。オンプレミス基盤(vSphere等)で
稼働するシステムの構築・運用にも迅速さを与えるために。
– オンプレミス・プライベートクラウド・パブリッククラウドにとらわれない
システム構築の生産性と品質を求めるために。

基本設計

ターゲットインフラ
プロトタイプの設計を今後OpenStack等ほかのインフラへ展開できるよう考慮しています。
VMWare 環境構築 TDDコーディング運用評価商用へ引き継ぎ
OpenStack
プロトタイプ on
OpenStackへリ
ファクタリング
運用評価
他のインフラリファクタリング

1
•失敗するテストを書く
•期待したエラーが出ることを確認
[Red]
2
•テストに通る最小限のコードを書く
•テストコードが通っていることを確認
[Green]
3.
•コードの重複除去等[Refactor]
•1.に戻る
参考: テスト駆動インフラの流れ
テスト駆動インフラでは、確認項目とテストコードを先に用意し、それに従いインフラコードを書きます。
1
•インフラ確認項目をテストコードで書く
•期待したエラーが出ることを確認
[Red]
2
•インフラ構築のためのコードを書く
•テストコードが通っていることを確認
[Green]
3
•必要なリファクタリング[Refactor]
•1.に戻る
[参考] テスト駆動開発テスト駆動インフラ

インフラ構築環境の設計標準：自動実行・継続実行の仕組み
テスト駆動インフラの活用
インフラ構築後のあるべき状態をテストするコードを作成しテストコードが合格するように
インフラ構築のためのコーディングを行う手法。異なるインフラへの移設やリファクタリング時に有効
インフラテストコード
(インフラに依存せず構築結果をテスト)
インフラ構築方式・管理方式
(インフラに依存せず設計を監理)
VM作成
OS&アプリ設
定
ネットワーク設
定
コンテンツ
監視・・・
VMware Public Cloud
App
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
OS
インフラ構築コード
(異なるインフラでは修正必要)
VM作成
OS&アプリ設
定
定
コンテンツ監視・・・
インフラ構築コード
(異なるインフラでは修正必要)
VM作成
OS&アプリ設
定
定
コンテンツ監視・・・
VM作成
OS&アプリ設
定
定
コンテンツ
監視・・・
テ
ス
ト
構
築
テ
ス
ト
構
築
案件ごとに
異なって
しまうコード
を局所化
設計やノウハウ
を標準化
していき
品質を共有

構成(将来実装予定分も含む)
Redmine
Jenkins
Gitlab
Target
Service
Ansible
サービスへの
自動設定
any IaaS(プロトタイプはvSphere)
vCenter API
Floating IP Floating IP
Blue Green
Product
Owner
Developer
Team
Service
Online
Environment
for Dev.
Master
(Team調整)
プロダクト
リリース
[BGD]
コラボレーション迅速化・高密度化
[目標]
サービス開発迅速化・
要件変化への対応迅速化
環境構築・試験の自動化
Ansible
Serverspec
可用性とスケーラビリティをもつ
Webポータル
(対応ミドルウェアは順次拡充
していく)

商用サービスの自動化段階
実際の商用サービスへ自動化を適用する際に考慮するべき方式と運用のユースケースです
特に運用に関係する箇所は、環境・案件ごとの運用に合わせた最適化が必要になります
１
• 構築手順をコード化する
２
• コードと構築後環境を構成管理する
３
• 構築結果をテストする
４
• 変更内容とテスト結果を可視化する
５
• 構築物をレビューする
６
• 構築物を現地へ適用する
７
• 新旧環境を切り替える
今回プロトタイプで
検証した領域
プロトタイプに「しくみ」は
いれたが、実運用に適用
させるべき領域
(人間系の運用)
適用先商用環境の
実装や運用に大きく
依存する領域

自動化機構の
実装方式

環境要件（基盤に許可いただく必要があるもの）
インターネットへの疎通
環境内でのDHCP,PXE利用
管理サーバ用仮想マシン1台
IaaS のAPI利用権限(オプション)
大がかりにしたくない、基盤に手をいれたくない
⇒お客様の環境に影響の少ない範囲で実施したい
最低限これだけ
あればよいです

管理サーバの構成
Slack
Clone
も入れ
たい・・・
Linux (Ubuntu 16.04)
dnsmasq
tfpd
Docker daemon
dhcpd
Container Container Container Container
Serverspec
Redmine GitlabMariaDBJenkins
Ansible
httpd
CentOS
Repo
Original
Repo
CentOS
Img
Kickstart
MAC-IP
Config
Test
Code
Playbook Project
Task
Ticket
Code
Review
etc...
Infrastructure (ex: vSphere,OpenStack,Baremetal ...)
Sub-network (Layer2 Switch)
コラボレーションツール群IaC/CDツール群リポジトリ/DHCP/PXE
Ubuntuだと
preseedかな
このＶＭ1台を用意すれば、継続的な
デプロイを運用できるよう設計しています

実現方式概要
自動化の仕組み
– 定期的に自動で最新のリポジトリからマスターサーバを作りテストを行います
– 必要に応じ最新のマスターサーバから複数のVMを自動で生成・テストしシ
ステム環境を作ります
①空の
VMを作
成
②マス
ターサー
バ
③最新
のマス
ターサー
バ
（１a）
OSリポジトリ
(CentOS等)
OS/MWの最新
パッケージを取得
自動でOSを
インストール
モジュール最新化
と共通設定後
自動テスト
④ ⑤
マスターを複製し
複数のVMを生成
設定に基づき
各VMをカスタマイズ
（２）
ローカル
リポジト
リ
マスターサーバを常に最新化
最新マスターから複数のVMを生成
ローカルリポジトリ
（１b）
独自にビルド
したアプリ
生成結果の
レポート
システム環境生成指示
ジョブ実行

ジョブの状態遷移
（１b）
独自にビルド
したアプリ
（１a）
OSリポジトリ
(CentOS等)
[ジョブ1]
空VMを作成
MBR削除
+再起動
Kickstart
によるOS
インストール
とssh設定
[ジョブ2]
マスターサーバ
を設定
Ansible +
Servespec
★定期更新
★ PXEブート
★ OS生成完了後
Jenkins ジョブ2起動
[ジョブ3]
マスターから
クローンVM
作成し
定義に従い
各マシンを
カスタマイズ
★オペレータによる
Jenkinsジョブ3起動
[ジョブ0]
の最新化
マスターサーバの自動最新化
[ジョブ0～2]
オンデマンドでクローンVM群を構築
[ジョブ３]
Kickstart.cfg
OSイメージ
OSリポジトリ
Appリポジトリ
★差分検知で
Jenkinsジョブ1起動
各VMの
設定情報
(1行=1VM)
構成管理表 (Excel⇒TSV)

構成管理表
構成管理表はExcelなどの一般的な表ファイルとして管理(RDBなどでも可)
TSV(タブ区切りテキスト)に出力して管理サーバへアップロードする
TSV
出力

サーバ種別
VMのスペック
host名、NIC毎のIP
有効化するサービス
etc
構成管理表
管理性を考慮し、構築するクローンVM群の設定はExcelで管理します。
• 実態はTSV形式なので、管理自体はExcelでなくても、RDB等でもなんでもよい
• 一元管理された情報に基づいて構築とテストを行う
TSV
dhcp
.cnf
YAML
(A)
YAML
(B)
Jenkins
Ansible
Serverspec
dnsmasqVM構成の一元管理
Export
変換
変換
変換
配布
配布
配布
各サーバを構築
各サーバをテスト
DHCPでMACに基づき
サーバへIPを付与
Upload

実装上のポイント
•たいていの環境で動く保守的な構成
•対象がベアメタルでも動く
PXE+DHCPによるOS生成
•今回はvmware_guestモジュールを利用
•モジュール差し替えで他の環境への置換が容易
•可読性が高い
Ansible2.xモジュールによるインフラ操作
•運用者はコードで管理したくない。DBも使いたくない・・・
•Excel⇒TSV⇒YAMLに変換してAnsible, Serverspec, dnsmasqが参照
•一度環境を作ったら日々の運用はExcel台帳管理だけで済むように。
ExcelによるクローンVMの設定一元管理
•運用上・実装上の理由でAPIをたたけないときに
•VMクローンを手作業で一括実施したあとに後処理を自動実行
•人が張り付かなくてもすむように
手作業も考慮

デモンストレーション
映像による構築デモ
（ノーカット。ただし編集にて早送りによる時間短縮版）
1. デモ１：マスターサーバの構築
2. デモ２：クローンVMの構築

やってみての気づき(TDD)
「テスト駆動インフラ開発(TDD)」をかかげてみた
• 実際はそんな綺麗にはすすまなかった
⇒すべてが検証しながら、なのでテストドリブンとは限らなかった
• Ansible担当とServerspec担当に分かれて並列作業
⇒ TDDというよりペアプログラミングに近い・・・
⇒ お互いスプリントごとに決めたコードを書いて、レビュー時にジョブにいれて結合テスト
• 案外いい結果に！
⇒ 結合するとジョブが動かない！（いい意味で！）
⇒ 動かない理由をコードベースで議論すると考慮もれや設計の穴が見つかる
⇒ AnsibleとServerspecで違う観点で実装することで品質向上をうんでいた気がする
• このスタイルはありだなと。 (TDDか？という疑問はさておき)
⇒①属人性を薄め、②品質をうみ、③チーム間でノウハウを共有しやすい

vSphere API
• エンタープライズ
• 企業内共通基盤
AWS/Azure
API
• パブリッククラウド
• ハイブリッドクラウド
OpenStack
API
• プライベートクラウド
• ハイブリッドクラウド
ベアメタル
• ビッグデータ
• ネットワーク機器
今後の機能強化について
全体の設計は共有しつつ、シンプルな設計を活かして
①CIとの連携、②コンテナイメージ展開、③対応IaaS APIの拡充、
と適用範囲を拡大していきたいと考えています。
継続的イン
テグレーショ
ン
コードリポジトリ
アプリケーション開発
マイクロサービス開発
プラット
フォーム最
新化
OSリポジトリ
ミドルウェアリ
固有製品
継続的イン
テグレーショ
ン
プラット
フォーム最
新化
マスターVM
RPMパッケージ
コンテナイメージ
環境
設定
ドキュメント
基本となる設定・運用は変えないまま拡充していく

まとめ

発表のまとめ
1. システム構築を自動化する仕組みを検討しプロトタイプを作りました
– お客様の所有・利用する共通基盤上で活用する想定
– 基盤への影響や依存を少なくしています
– ターゲットはオンプレ基盤としてデファクトのvSphere環境。
– テスト駆動なアプローチでお客様環境への順応性と品質確保を狙っています。
2. ユースケース(活用シーン)
– 数十台のサーバを迅速正確に構築したい
– 脆弱性対応のため定期的に多数のサーバのOS,ミドルウェアを最新化・動作確認したい
– インフラ構築における属人性やオペミスをなくしたい
3. デモンストレーション
1. リポジトリ変更に応じてマスターサーバを自動構築
2. 構成管理表を元に複数サーバを自動構築
4. 今後順次拡充予定

案件募集・PoC募集
ご興味ある方お声掛けください
最新技術をキャッ
チする
PoC(Proof of
Concept)で
顧客業務要件へ
フィッティング
得意な領域を繰
り返し深く専門化
する
現場から湧き出る
PoCネタ募集！
ぜひお声掛けください

ご清聴ありがとうございました
Thank you !
http://www.mdis.co.jp/solution/oss/

CD(継続的デリバリー)手法を用いたサーバシステム構築の自動化 - OpenStack最新情報セミナー(2016年12月)

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to CD(継続的デリバリー)手法を用いたサーバシステム構築の自動化 - OpenStack最新情報セミナー(2016年12月) (20)

More from VirtualTech Japan Inc. (20)

CD(継続的デリバリー)手法を用いたサーバシステム構築の自動化 - OpenStack最新情報セミナー(2016年12月)