【勉強会】RedHatForum2016
2016-10-05_RedHatForum2016
これに行ってきた
JBoss on Azureでマイクロサービスアーキテクチャを
- 富杉 正広 氏 [SCSK株式会社]
環境
- Cloud
- AWS/Azure/OpenStack
- Container
- Docker/Kubernates/OpenShift
MSAのメリット
- システム改修の容易性
- システム規模の拡縮の容易性
- 技術的な柔軟性
MSAとSOAの違い
- 根底は同じ、独立した機能をサービス化する
- サービス間の結合方法の考え方が違う
- SOAは連携定義が複雑（SOAP/WSDL等）、ESBが必須
- MSAはRESTfulAPIでよいので、接続連携用のMWが不要
MSAの注意点
- サービスの切り方、なるべく現実組織・ビジネス領域に合わせる、DDDの活用
- CI/CDを正しく理解する
- 小さいシステムで正しく管理できてるならモノリスが有益
- システム全体の整合性、オーガナイズする組織なり人なりが必要
JBoss EAP7紹介
- 安齋 宗一郎 氏 [レッドハット]
https://redhatforum.jp/pdf/APP601.pdf
- JavaEE7のサポート
- ユーザビリティ
- セキュリティ
互換性
JavaEE7→WIldFly8,9,10→EAP7
- EAP6からの変更
- Web→undertow
- Messaging→AMQ Artemis
- JacORB→iiop-openjdk
CloudReadyArchitecture
オペレーショナルモード
- ドメインとスタンドアローン
- できることは同じ
管理の仕方で選べば良い
GracefulShutdown
- オフラインCLI
- Undertow
ソフトウェアロードバランサーとして利用可能
Messaging
- HornetQ→AMQArtemis
- Subsystem名はmessaging−activemq
JBoss EAP 7 マニュアル文書 – https://access.redhat.com/documentation/en/jboss-enterprise-application-platform/ • グレースフルシャットダウン: – https://docs.jboss.org/author/display/WFLY10/Suspend%2C+Resume+and+Graceful+shutdown • オフラインCLI – http://wildfly.org/news/2015/03/13/Offline-CLI/ • Discovery options – https://developer.jboss.org/people/fjuma/blog/2013/03/15/a-domain-controller-discovery-system-for-as-8
Wildfly10.1 HTTP/2採用
開発生産性
エンタープライズにおけるコンテナ活用法
- Mark Coggin 氏[米国レッドハット]
アプリケーションの積み込みをドックではなく工場で行う
コンテナとは何か？
相手によって異なる Infrastructure ● Linuxオペレーティングシステムの機能に依存 ● 中身はLinuxなので、各コンテナはLinuxソフトウェアで作られる ● 仮想マシンよりも簡素、軽量、高密度 ● 有効に使用するためにはオーケストレーションと管理が必要 Applications ● iPhoneのアプリと同様にエンタープライズアプリケーションをパッケージ化 ● すでに構築済みのアプリケーションへの追加が容易 ● コンテナ化されたコンポーネントの共有が容易 ● アプリケーションとその実行に必要なものをすべて格納する「ブラックボックス」 ● 開発者による制御が向上
最新事例から考えるRed Hat OpenStack Platform
- 井口 幸一 氏 [フリービット株式会社]
- 内藤 聡 氏 [レッドハット株式会社]
https://redhatforum.jp/pdf/CLD302.pdf
目指したもの
標準化
- 長く運用するとOS、MWのバージョンが混在する
- スキルセットがばらばら、属人化
- HWの年代、メンテナンス、維持コストがかさむ
- サーバコンフィグをExcelにまとめるのでなく、コンフィグファイル自身を管理
- ドキュメンテーションに費やすコストを排除
機敏性
- IaC
- BlueGreenDeployment
可用性
選定
- OpenStack
- CloudStack
- VMWare
導入効果
- Nova/Neutronの標準APIでインフラ開発の75%をカバー
- どこまでが手動で、どこまでがOpenStackやChefで自動化できるか
- 手動で残った作業、IPアドレス管理台帳とか、クラスタリング設定とか
- CinderのAPIでストレージを制御
- Glanceを活用したテンプレートで、属人性を排除
- 機敏性、インスタンス46台の構築、8分26秒
- 可用性、FO/FBのしくみは設計済みだった、やったのは監視設計くらい
成功の秘訣
Culture is more important than Technology. Jonathan Bryce
- 技術より文化が大事
- 全部自分たちでやろうとしない
- 専門性の高い分野はサポートに任せる
実践 DevOps
- 山田 義和 氏[レッドハット株式会社]
目的
- ITによりビジネスの領域が拡大、多様化、競争激化
- サービスはリリースの“後”じゃないと価値を生み出さない
- リリースしてユーザが使わないと、学習ができない
- リリースのサイクル数を増やすと、学習の機会が増える、変化に対応する機会が増える
「より早くサービスをリリースする、より多くフィードバックをし継続的にサービスを改善」
Agileは変更にどううまく対応するか
Leanはワークをどううまくまわすか
DevOps≒Agile/Lean
- DevOpsからAgile/Leanを引いて残るものは何か？と考えると、
- Agile/Leanの考え方をソフトウェアライフサイクル全体に広げたもの
- 本質＝強調、文化・マインド、チームドリブン
技術・ツール
- CI/CDパイプライン、変更容易性をあげて、変更スピードをあげる
- CI/CDに向けた自動化において、インフラ・非機能の領域をどうするか
- 自動化における技術的課題 • インフラ構築の自動化 • インフラ要件のコード化 • インフラに依存するテストの自動化 • インフラの構成管理の効率化
- 変更容易性に関わる要素
- 局所化
- 疎結合
- テスト容易性
- SOLID原則
- WildfFySwarm
- JavaEEが一個のJarで利用出来る
- DevOps実践課題バックログを減らすにつれて、DevOps成熟度はあがっていく
OPENSTACKによるオーケストレーションされたコンテナ化が可能にするもの
Lars Herrmann Red Hat インテグレーテッドソリューションズ事業部 GM
CIOが求めるもの 顧客満足度 アジリティ 信頼性
Agiilty
- システムの提供に時間がかかるのは組織の問題
- トヨタの、製造業のやり方を真似る
CustomerSatisfaction
- リリース頻度が３ヶ月では継続的とは言えない
Confidence to Deilver
- 可用性とセキュリティは最低限必要
- スケーリングも必要
- セルフサービスとオートメーション
- 合理化、自動化
- 弾力性、リソースの共有
- 常時オン、ポリシードリブン、人ではなくテクノロジーが判断、スピードが違う
Content
- 物理的なリソースがないとアプリケーションは動かない←OpenStack
- OSも必要←OpenShift
アプリケーションがないとビジネスにならない
Devチームは、インフラを気にしない、動けばいい
- Opsチームは、インフラを考える
- DevとOpsのニーズは異なる
必要なのは両者のコントロール、インフラは両者のニーズを満たす必要がある
これまでは、仮想化で実現してきた
- VMは常に変更をしていかなければならない、複数の人が
- マイナス点は待ち時間
- 特に変更管理、アプリケーションの
- エンタープライズになると、複雑性上がる
- Cloudでは改善されない
Any color so long as it's black. Henry Ford
- けど、ベストではない
- そこでコンテナ
アプリとインフラの間に挟まるのがオーケストレーション・コンテナ
アプリケーションをコンテナ内に入れてしまう
- セキュリティが担保される
- パフォーマンスの最適化も担保できる
- コンテナ毎に個別に制御できる
継続的な改善が可能になる
OpenStackのコンテナだからってOpenShiftじゃなくていい
いまのシェアはKubertetesがトップ
ワークフローの自動化が可能になる
デプロイの自動化
- OpenShiftはコンテナのリビルドで対応可能
OpenShiftは、セキュリティパッチも自動で、開発者が意識せずに
組織の話
- Dev/AppOps/SysOps
- コンテナによって、各チームは自分の仕事に集中できる
OpenStack 事例紹介 ーOne Command デプロイへの挑戦ー
- 黒澤 隆史氏 [NHNテコラス株式会社]
- 輿水 万友美 氏 [レッドハット株式会社]
プロビジョニングツールとは
OpenStackのプロビジョニング
- DevStack、Ubuntu Cloud Archive、packstack
- MAAS、Juju、FUEL、TripleO
- 実情
- 設定が複雑
- 過去に動いていたものが動かなくなる
- OneCommandデプロイへ至る道
- 検証と本番を意識できる
- 作って壊してを繰り返せる
- コンポーネント毎にマルチノードでデプロイできる
- HA機能付きでデプロイできる
- 冪等性がある
- Git等リビジョン管理システムを利用したワークフロー
- 挑戦した結果→4コマンド
OpenStackとは
- クラウドインフラを自分で構築するためのソフトウェア
- 仮想化管理ツールではない、パブリッククラウドと同等の機能を目指すもの
- IaaSの成熟とサービスの強化を進めている
- 「RedHatOpenStackPlatform」はRedHatのディストリビューション
- OpenStackは単体では成り立たない
- OpenStackのコアサービス、IaaS的なところは、コミュニティ版と変わらない
- コミュニティ版から２〜３ヶ月遅れでリリース
- コミュニティ版はソース、OSPはrpmで提供
Ansible Tower by Red Hat ではじめる自動化
- 平田 千浩 氏[レッドハット]
Ansible/AnsibleTower
- Ansible
- Ansible Tower
Ansibleでできること
- プロビジョニング
- パッケージインストール
- 設定変更
- ファイル転送
- オーケストレーション
- 複数の機器・製品に対して自動で順序実行
- Server / Router / Switch/ FW / Load Balancer / Storage / Database /Cloud etc… 構成管理 状態確認 バッチ処理 アップデート実行 セキュリティパッチ確認
Ansibleのコンセプト
Ansibleの課題
- 複数ユーザだと問題点が
- ファイルの更新履歴
Ansible Towerでの追加コンセプト
- ジョブコントロール
- 可視化
- 権限管理
何が違うのか
- Playbookを外だしでGit等で管理
- DBを持ってて履歴管理
- ユーザ毎に権限を分離
