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

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED COPYRIGHT © 2014 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED COPYRIGHT © 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/

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED COPYRIGHT © 2015 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED

発表の概要


最新のマスターサーバ

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

インフラ構築コード (異なるインフラでは修正必要)


定


定コンテンツ監視・・・

インフラ構築コード (異なるインフラでは修正必要)


定


定コンテンツ監視・・・


定


定コンテンツ

監視・・・

テスト

構築

テスト

構築

案件ごとに異なってしまうコードを局所化

設計やノウハウを標準化していき品質を共有


構成(将来実装予定分も含む)

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 Gitlab MariaDB Jenkins

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

dnsmasq VM構成の一元管理

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/

Technology

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