Enterprise Service Development Platform ご紹介...マルチクラウド仕様/メリットと注意事項 V1.2ではFJCS仕様とマルチクラウド仕様を提供しますが、マルチクラウド仕様は

FUJITSU SoftwareEnterprise ServiceDevelopment Platformご紹介

2020年7月富士通株式会社

Copyright 2020 FUJITSU LIMITED0

はじめに

◼ 富士通のSI市場でクラウド利用が加速化し、プライベートからパブリックまで選択肢が増えています。V1.2ではさまざまなクラウド環境に導入可能であり、利用者はクラウドに依存せず、同等の操作性でシステム開発・運用が可能となります。

Enterprise Service Development Platform

パブリックからプライベートまで幅広い選択

インフラ層 FUJITSU Hybrid ITService FJcloud

他社クラウドベアメタルサーバー

VMWare

アプリ層お客様

アプリケーション・・・・・・・・・

開発者運用者

クラウドに依存しないシステム開発・運用

デジタルサービスの開発から運用まで支援

実装計画監視運用

ビルドテストリリース配備

Copyright 2020 FUJITSU LIMITED

開発支援実行基盤運用支援共通基盤

1

機能一覧

分類機能名利用OSS 提供内容

共通基盤

Integration management OpenLDAP ESDP*が提供する各種OSSを同一IDで認証可能な統合認証基盤を提供。

開発支援

CI Management GitLab/SonarQube/Mattermost/Redmine

ソース管理からビルド、テスト、成果物管理といった流れを定義したCI環境を提供。・連携設定済みのCI環境を提供。・CIに必要なサンプルを提供。

実行基盤

Application Management

Container Management

Kubernetes/HELM アプリケーションの実行基盤として、Kubernetes/HELMを提供。

運用支援

Monitoring Metrics Management

Prometheus, Grafana Container Managementのコンテナリソースを監視し、稼働中のユーザアプリケーションに十分なリソースが確保されているかを監視します。

Log Management

Elasticsearch, Fluentd, Kibana

Container Managementで標準出力・標準エラー出力に出力されたログの「収集」、「蓄積」、「分析/可視化」を行います。


ESDP* ： Enterprise Service Development Platform

2

提供機能


ESDP V1.0・実行基盤Kubernetes

・開発支援CI機能

ESDP V1.1・運用支援監視/ログ

・実行基盤Kubernetes


ESDP V1.2・マルチクラウド対応軽量化マルチクラウド展開

・共通基盤統合認証基盤

・運用支援監視/ログ

・実行基盤Kubernetes


運用強化

マルチクラウド対応

2019/5月出荷 2019/10月出荷 2020/7月出荷

FUJITSU SoftwareEnterprise ServiceDevelopment Platform

デジタルサービスの開発から運用まで支援するプラットフォームを提供し続けます

社内実践

製品化

3

◼ デジタルサービスの開発から運用を一通り支援する機能を提供します。

製品構成


Application Management

CI Management

コーディング開発者

ビルド

テスト

レビュー

成果物

ステージング本番リリースシステム利用者

開発環境

ソース管理 CIパイプライン成果物管理

自動構築構築者

コミュニケーションツール

Monitoring

運用者

監視ログ収集

IntegrationManagement

統合ユーザー管理

4

マルチクラウド対応


◼ V1.1ではFUJITSU Hybrid IT Service FJcloud-O IaaS (FJCS)のみ対象としていましたが、V1.2ではマルチクラウド展開に最適な少ないリソースで素早くクラウド展開可能な構成を提供します。

◼ FJCSを対象とした従来構成を「FJCS仕様」、マルチクラウド対応の新構成を「マルチクラウド仕様」と呼びます。

◼ FJCS仕様は一般的なサービスネットワークと管理ネットワークを分離し、それぞれのネットワークに配置された仮想マシンにESDPの各ツールを分散配置していました。

◼ マルチクラウド仕様では、クラウドの利点であるスピード・低コストを想定し、ESDPの各種ツールをKubernetes上に集約し、最小で3つの仮想マシンで構築可能とします。

マルチクラウド仕様

Docker/Kubernetes

Kubernetes Masterサーバ

Kubernetes Nodeサーバ

監視

GitLabRunner

AnsibleGitLab

API ProxyKubernetes

Master KubernetesNode

NFS

ログ監視

Ansibleサーバ

GitLabサーバ

GitLab Runnerサーバ

API Proxyサーバ×3

KubernetesMasterサーバ

Kubernetes Nodeサーバ×2

NFSサーバ

管理ネットワーク

FJCS仕様

マルチクラウド仕様

サービスネットワーク

KubernetesMaster


GitLabRunner

ビルドサーバ

Redmine

スケールアウト可能

ログ

SonarQubeGitLab

MattermostRedmine

6

マルチクラウド仕様/前提条件

◼ 導入可能な環境

◼ 動作検証済のクラウド環境

要素条件

OS 「製品情報」ー「動作環境」を参照してください。

仮想マシン管理用のmasterサーバ1台以上、業務アプリを動かすnodeサーバ１台以上。CI基盤を利用する場合には、ビルドサーバ1台以上。各仮想マシンで必要なスペックはマニュアルを参照ください。

ネットワーク masterサーバとnodeサーバ間はネットワークを共有されている必要があります。インターネットアクセスが禁止された閉域網の環境や、プロキシ経由でインターネットアクセスが必要な環境においても導入可能です。

クラウド環境備考

FUJITSU Hybrid IT Service FJcloud-O IaaS

AWS EC2、Amazon EKS

Azure IaaS、Azure Kubernetes Service (AKS)

VMWare vSphere


マルチクラウド仕様/メリットと注意事項

◼ V1.2ではFJCS仕様とマルチクラウド仕様を提供しますが、マルチクラウド仕様はKubernetesサービス上に機能を集約して以下の利点があります。このため、マルチクラウド仕様を選択してください。

◼ 少ないインフラリソースで製品を導入できます。

◼ サービス(GitLabなど)が異常終了した場合、Kubernetesが自動的に再起動して自動復旧します。

◼ Kubernetesの機能を利用して同一の操作性で各種サービスを運用できます。（サービスの起動・停止・状態確認など）

◼ 本製品の新機能は、今後マルチクラウド仕様に追加します。

◼ 注意事項

◼ Kubernetes上にお客様が登録した業務用アプリとESDPの各種ツールが同居するため、仮想マシンの容量を見積もる際にはESDPの各種ツールで必要なリソースも合算してください。

◼ FJCS仕様ではFJCS上に製品を導入するインフラ(仮想マシンやネットワークなど)の構築を支援していましたが、マルチクラウド仕様では製品の導入に必要なインフラは導入するクラウド上に製品利用者が事前に用意してください。

◼ 旧バージョンのFJCS仕様の環境を、マルチクラウド仕様にアップデートすることはできません。各ツールの資産をバックアップ・リストアして移行する必要があります。


共通基盤

1. Integration Management


監視ダッシュボードGrafana

ソースコード静的解析

SonarQubeｺﾐｭﾆｹｰｼｮﾝﾂｰﾙMattermost

プロジェクト管理Redmine

Integration Management

◼導入したOSSを利用する際に同一の認証情報でログインして利用できます。認証情報をLDAPで統合管理するため、OSSの使い易さが向上します。※Kibanaのセキュリティ機能を利用する場合、有償版のKibanaを利用する必要があるため未対応です。

◼ActiveDirectoryで管理している認証情報を利用したい場合、LDAPサーバとActiveDirectoryを連携することで既存の認証情報を利用することもできます。

openldap-client

openldap-server

Portal Portal Portal Portal

ソース管理GitLab

同一のユーザID/パスワード

統合認証管理

Portal


ActiveDirectory

既存のユーザID/パスワード

同一の認証情報で各種OSSを利用できます

10

主な特長(開発支援)

1. CI Management


汎例自動実行 OSS ツール

フェーズ

計画コーディング/

コミットビルド/

ユニットテストレビュー

リリース結合テスト

デプロイインシデント

管理

CI Management

◼事前にCI/CDパイプラインを定義しておくと、各フェーズで実施すべき作業が自動実行されます。


Redmine

GitLab

GitLab Runner

Gradle/Maven/JUnit

SonarQube

Mattermost

開発者

ソース管理

結果通知

CI/CDパイプラインコンテナイメージ管理

タスク管理インシデント管理進捗管理

コード静的解析

CI/CDジョブ実行

生産物管理

設計


アジャイル開発による継続的インテグレーションがすぐに開始できる環境を提供

ドキュメント管理

12

主な特長(実行基盤)

1. Container Management

2. API Proxy


Node


Node


Node


Master



開発者

登録配置

コンテナ

◼新規にコンテナを登録すると、リソースが空いているNodeに自動的に配置されます。◼冗長化(ReplicaSet)されたコンテナを配置すると、複数Nodeに分散配置されて可用性が保たれます。◼Nodeやコンテナが停止した場合、自動的に別Nodeへの再配置やコンテナを再起動して自動復旧します。

KubernetesCLI(kubectl)

異常停止

再配置


開発したコンテナを業務サーバ(Node)に適切に配置

14

API Proxy

◼ 認可⚫ アプリへの振分けパスごとにAPIキーを設定し、対象のAPIキーが指定されたリクエストか検証します。

◼ トラフィック制御⚫ アプリへの同時接続数や時間内のリクエスト数の制限を設定できます。

◼ アクセス制限⚫ リクエストメソッドの制限ができます。例えば、GETメソッドのリクエストだけをアプリに振り分け、POSメ

ソッドなどはエラーを返すことが可能です。マルチクラウド仕様ではAPI Proxyは非公開のため、個別対応が必要な場合、開発元に問合わせてください。[参考]マルチクラウド仕様でKubernetesのIngressとAPI Proxyは統合し必要なリソースが削減されます。

APIProxy


Ingress ※1 Service

認可

アクセス制御

トラフィック制御 IP管理

PodPod

コンテナ

Service

PodPod

コンテナ


Ingress ※2 Service

認証

アクセス制御

トラフィック制御

IP管理 PodPod

コンテナ

Service

PodPod

コンテナ

※1）NGINX Ingress ControllerNGINXを利用したコントローラ

※2）Kubernetes Ingress Controller for KongIP管理するNGINXとAPI管理のKongが一体となったコントローラ

マルチクラウド仕様FJCS仕様


API開発に専念できるため、サービス公開までの期間を短縮

15

主な特長(運用支援)

1. Metrics Management

2. Log Management


Metrics Management

Metrics Management

PrometheusGrafana

収集蓄積可視化

コンテナ

アプリ

コンテナ

アプリ

コンテナ

アプリ

オートスケール

削除

追加

コンテナの増減に合わせて自動的に監視対象を追加・削除 E

xport

er

Export

er

Export

er

コンテナ

アプリ

コンテナ

アプリ

アラート

監視

注）Prometheusの仕様により、課金情報の収集などの用途には適していません。

◼Container Managementはコンテナを素早く追加/削除でき、コンテナ異常停止時の自動再起動や高負荷時のオートスケール機能でコンテナが動的に増減します。

◼Metrics Management機能を利用することで、このコンテナの増減に合わせて、自動的にコンテナが監視対象に追加・削除されるため、運用管理が効率化されます。

◼監視対象から情報を収集する機能をExporterと呼び、サードパーティのExporterを利用することでコンテナ以外にもデータベースやハードウェアの監視も追加可能です。


動的に増減するコンテナを監視対象に自動的に追加・削除

17

コンテナ

アプリ

コンテナ

アプリ

Log Management

Log Management

ElasticsearchKibana

収集蓄積可視化

コンテナ

アプリ

コンテナ

アプリ

コンテナ

アプリ

削除

追加

コンテナの増減に合わせて自動的にログ収集対象を追加・削除

ログ参照/解析

Flu

entd

Flu

entd

Flu

entd

ログ

ログ

ログ

オートスケール

フィル

タリン

グ

検索例)検索条件：”Bad Request” ログ情報 : ”400 Bad Request….”、“401 Unauthorized …” 、“408 Request Time-out …” 、

“500 Internal Server…”、“502 Bad Gateway…”検索結果 : ” 400 Bad Request ….”、 “408 Request Time-out …”、“502 Bad Gateway …”→”Bad” ,”Request”に合致したものが検索された。

◼Log Management機能を利用することで、コンテナのログ情報を収集して一元管理し、異常発生時の原因の追跡やアプリのアクセス情報の蓄積・解析ができます。

◼収集するログ情報から、フォーマットに合せて必要な情報のみにフィルタリングしたり、ログからあいまい検索で必要な情報を検索できるためログ解析を効率化できます。


コンテナが出力するログを収集して可視化

18

機能説明


◼ 作業管理[チケット]◼ 「誰が「「いつ」「何をするか」を管理しプロジェクト内で共有

◼ ガントチャート◼ 作業計画を視覚的に表現し、プロジェクトの状況を把握

◼ 予定管理[カレンダー]◼ プロジェクトのイベントをカレンダーでチェック

◼ 情報共有[Wiki/ニュース]◼ プロジェクト内でノウハウ(ツール利用方法など)を共有

プロジェクト管理/Redmine

誰がいつ何を状態

作業の進捗状況を視覚化


開発・運用作業を見える化し、プロジェクト運営を支援します

20

◼課題管理：機能の要望/指摘(これをIssueと呼ぶ)を登録し、担当者をアサインします。◼バージョン管理：誰がいつどんな修正をしたか管理します。過去のバージョンに戻すことも可能です。◼レビュー管理：修正時にレビューを依頼します。これをマージリクエストと呼びます。

指摘箇所にレビューコメントを付与し、開発者に通知できます。◼ブランチ管理：複数人で並行開発する場合の競合を防ぐため分岐(ブランチ)を作成できます。

開発中のソースも管理し、レビュー/テストが完了したソースを安全にマージできます。◼CI/CDパイプライン：ソースが修正されたタイミング、もしくは、任意のタイミングで、

ビルドやテストを自動実行します。◼生産物管理：ビルドして生成した生産物を世代管理します。GitLFS機能を有効化し、

大容量ファイルの取り扱いを可能にします。

ソース管理/GitLab

開発リーダ開発者

課題管理

ソース

バージョン管理

課題登録・担当アサイン

コミット

CI/CDパイプライン生産物管理

レビュア

レビュー管理ブランチ管理

マージリクエスト

マージ通知

チャットやメール


大規模な開発チームによる継続的な開発(実装-開発-ビルド-テスト)を支援します

21

コミュニケーションツール/Mattermost

Mattermost

◼ チャット：遠隔地のプロジェクトメンバともチャットにより活発な議論・情報共有を支援

◼ イベント通知：WebHookによりツール間を連携し、CI/CDパイプラインなどの作業完了や異常を通知

結果通知

チャット

配信

チャット


プロジェクトメンバ間のコミュニケーションもしくはツールからの通知

22

◼ ソースを実行せずコードを解析(静的解析)し、障害箇所だけでなく、将来的に障害リスクがある部分(Code smell/コードの臭い※)を通知して高品質なソースコード実装を支援します。

◼ Java、JavaScript、PHPなど主要な開発言語のコード解析に対応

※コードの臭い：階層が深い、ほとんど処理がないメソッドが多いなど複雑になっているコードなど現時点では問題は無いが将来的に品質悪化を招く危険性があるコードのこと。

静的解析/SonarQube

SonarQubeソースコード

静的解析

解析

分析結果の表示

Java HTML PHP

障害脆弱性コードの臭い

解説表示

フィードバック

開発

可視化

問題箇所・指摘


ソースコードを解析し、品質リスクがある部分を通知して品質の良い開発を支援

23

NodeNode

オーケストレーション/Kubernetes①


◼ サービスディスカバリ/オートスケール◼ Kubernetesは配備したコンテナを負荷に応じて多重度(レプ

リカと呼ぶ)を自動的に増やす(オートスケール)ことができ、動的に増減するコンテナの配置を把握し、クライアントからの呼び出し先への追加・削除を自動的に制御します。

Node

コンテナコンテナコンテナコンテナ

Kubernetes

コンテナコンテナ



◼ 自動コンテナ配置◼ Kubernetesはコンテナを動かすサーバ(これをNodeと呼ぶ)

を複数管理し、コンテナが配備されたら、容量が空いているNodeに可用性を保つために自動的に分散配置します。

NodeNodeNode

Kubernetes

コンテナコンテナコンテナ

クライアント

コンテナの最適な配置を支援し、分散配置されたコンテナへの負荷分散を支援

24

NodeNode

オーケストレーション/Kubernetes②


◼ セルフヒーリング◼ 異常が発生したコンテナを自動検知して再配置することで、

可用性を維持することができます。

Node

Kubernetes

◼ ロールバック◼ 配備したコンテナの状態を世代管理し、アプリに異常があれば、

以前のバージョンにすぐに戻すことができます。

NodeNodeNode

Kubernetes


クライアント

コンテナ

自動検出

再配置

コンテナVer1コンテナ

Ver2

コンテナVer2

コンテナVer2

コンテナVer1

コンテナVer1

新しいアプリは問題が多いので

旧アプリに戻したい

ロールバック

コンテナの異常を認識し、自動的な復旧を支援

25

オーケストレーション/Kubernetes③


◼ ストレージオーケストレーション◼ コンテナは動的に増減するため、保存しておく必要があるデー

タは外部ストレージに格納する必要があります。コンテナ間で共有するストレージ(これを永続化ボリュームと呼びます)を管理する仕組みを提供します。

◼ 機密情報管理◼ コンテナは環境依存の情報を環境変数から参照することで各

環境で同一のコンテナを利用できます。しかし、パスワードなど機密情報を扱う場合のため、機密情報をBASE64で保存して環境変数から参照可能として機密性を維持できます。

NodeNodeNode

Kubernetes


クライアント

コンテナ

ストレージ

NodeNodeNode

Kubernetes


クライアント

コンテナ

機密情報

参照参照

パスワード

登録BASE64エンコード

コンテナの運用に必要な情報の安全な管理を支援

26


運用保守機能


◼ 本製品は各サーバがネットワークを介して連携して機能を提供するため、トラブル発生時に各サーバの情報を収集して、ネットワークやサーバの状態を確認して調査が必要な場合があり、調査に時間がかかる場合があります。このため、調査に必要な資料を簡単に収集する機能を提供し、原因調査を支援します。

正常性確認◼ サーバーへの接続性チェック

• 各サーバに正常に接続できるかを確認

◼ コンテナランタイムの動作チェック

• コンテナランタイムが正常に稼働しているか確認

◼ kubectlの動作チェック

• Kubernetesの稼動状態を確認

資料採取◼ Kubernetesの状態確認

• Kubernetes masterおよびnodeの状態を収集

◼ KubernetesのPodとして動作するコンポーネント、アプリケーションの確認

• Kubernetes上で稼動している本製品の各コンポーネントのPodの情報を収集

• Kubernetes上で稼動している利用者が配備した各Podの情報を収集

◼ dockerコンテナとして動作するコンポーネントの確認

• GitLab Runnnerなどdockerコンテナとして稼動しているコンポーネントの情報を収集

◼ インストールしているOSSのバージョンの確認

• 本製品がインストールされている環境のOSSのバージョンを収集

異常が発生時の原因調査を支援

Kubernetes Masterサーバ Kubernetes Nodeサーバ

ビルドサーバ

collectinfo

実行

ERROR!

異常発生

収集

調査採取

27

製品情報

1. 動作環境

2. 商品体系

3. 製品の更新ライフサイクル

4. バージョンアップのプロセス

5. 業務無停止で製品入替

6. 製品のバージョンアップ時の影響

7. 製品のバージョンアップ時に影響を受ける場合

8. 製品のバージョンアップによりAPL修正が必要となる場合

9. サービス


動作環境

◼ 動作OS/対応インフラ

製品名仕様動作OS 対応インフラ


FJCS仕様 RHEL 7(7.6以降)、CentOS 7(7.6以降)

FUJITSU Hybrid IT Service FJcloud-O IaaS

マルチクラウド仕様 RHEL 7(7.6以降)、CentOS 7(7.6以降)、Amzon Linux 2もしくはクラウドサービスが提供するKubernetesサービス(v1.18.0)

インフラ条件を満たすクラウドサービス


商品体系

商品名単位備考

メディアパックープログラム+マニュアル（DVD 4枚）

サブスクリプションライセンス／サポート（50コンテナ・登録25ユーザ）

50コンテナ/月25ユーザ/月

基本：50コンテナまで基本：25ユーザまで

サブスクリプションライセンス／サポート（50コンテナ）

50コンテナ/月基本50コンテナを超過した場合

サブスクリプションライセンス／サポート（登録10ユーザ）

10ユーザ/月基本25ユーザを超過した場合

• 本製品は、メディアパックと各サブスクリプションライセンス／サポートから構成されています。• サブスクリプションライセンス／サポートは、メディアパックで提供されるプログラムを購入から

１か月間使用できる権利とサポートを含むライセンスです。• ライセンスの有効期間内に、本製品のバージョンアップが行われた場合は、

無償でバージョンアップ後のメディアパックを入手することが可能です。• 開発環境や本番環境に構築するコンテナの合計数のコンテナライセンスをご購入ください。

◼ Enterprise Service Development Platform月額商品


◼ バージョンアップサイクルが短いOSS群(最小9ヵ月)を多く活用しているため、概ね半年サイクルで更新版を提供します。年１回のサイクルで本製品を最新版へ入替えてください。また、頻繁な製品のバージョンアップや修正提供に備えて、業務アプリケーションの動作確認の自動化等の対応をお願いします。

製品の提供サイクルに合わせて以下の通りサポート期間を設定します。

① 最新版(1.1.0)出荷から半年間で旧版(1.0.0)を出荷停止となります。

② 最新版(1.2.0)出荷から１年間の間、旧版(1.1.0)をサポートします。

③ ただし、旧版(1.2.0)出荷から半年以内に最新版(1.3.0)を出荷した場合は、旧版出荷から1年半がサポート期間となります。

※本製品のバージョンアップや修正提供において、OSSのバージョンアップによる、非互換が発生する場合があります。

製品の更新ライフサイクル

1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q

V1 修正▼

修正▼

1.0.0

1.1.0

1.2.0

▼販売・出荷停止

▼サポート終了


1.3.0

②

③

①▼サポート終了


バージョンアップのプロセス

1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q

V1 1.0.0

1.1.0

1.2.0



▼出荷停止

▼出荷停止

サポート終了▼

開発環境１----------1.0.0----------------------

---------------------------1.２.0----------------

STG環境----------------1.0.0-----------------

--------1.1.0------------------------1.２.0-----------------

本番環境-----------------1.0.0-----------------

--------1.1.0------------------------1.２.0---------------

-

開発環境２---1.1.0------------------------

検証期間

検証期間

確認

確認

以下の手順を推奨します。

1) 開発環境2に1.1.0を構築します。

2) 開発環境2でお客様業務アプリの検証をします (必要に応じアプリを修正します)。

3) STG環境の本製品を1.1.0にバージョンアップします。

4) STG環境でお客様アプリの動作を確認します。

5) 本番環境の製品を1.1.0にバージョンアップします。

※1.1.0から1.2.0へバージョンアップの場合および修正適用についても上記と同じ流れとなります。

1)

2)

4)

5)

3)

右記プロセスは、本製品が想定する標準的な開発規模(サービス数25、コンテナ数50)を想定しています。

◼ 以下では典型的なバージョンアップのプロセスを説明します。◼ バージョンアップ前にアプリの検証が必要となるため、２つの開発環境を構成することを推奨します。

◼ 下図の例では、開発環境１・２、STG環境、本番環境に構築するコンテナの合計数を満たすコンテナライセンスをご購入ください。


◼ 製品のバージョンアップ時、ローリングアップデートにより、1台ずつノードを入替えることにより、業務アプリ無停止でバージョンアップが可能です。

◼ 旧バージョンのFJCS仕様の環境を、マルチクラウド仕様にアップデートすることはできません。各ツールの資産をバックアップ・リストアして移行する必要があります。

複数ノードで業務アプリが運用されていることが前提です。※開発環境、ステージング環境および本番環境などにかかわらず、すべての環境で適用が可能です。※Container Managementの管理系コンポおよびCI Managementは停止メンテナンスが必要です。

業務無停止で製品のバージョンアップが可能

旧ノード1

アプリ

Enterprise ServiceDevelopment Platform

V1.0.0→V1.1.0

Enterprise ServiceDevelopment

PlatformV1.1.0

アプリ

旧ノード2

アプリアプリ

新ノード1

アプリ


PlatformV1.2.0

アプリ

新ノード2

アプリアプリ

旧ノード1

アプリアプリ

アプリアプリ

新ノード2


PlatformV1.1.0→V1.2.0

旧ノード2

②アップデートアプリアプリ

①退避ノード数分繰り返し

アップデート

アップデート中も業務処理継続


製品のバージョンアップ時の影響 (APLコンテナ)

Infrastructure(FUJITSU Hybrid IT Service FJcloud-O IaaS)

Operating System(Red Hat / CentOS)

Container Engine

(Docker)Bin/Lib

(e.g. CentOS)

Middleware(e.g. tomcat)

APL

Bin/Lib(e.g. Debian)

Middleware(e.g. Rails)

APL

Bin/Lib(e.g. Ubuntu)

Middleware(e.g. Spring)

APL

Container Container Container

製品のバージョンアップ時の入替対象。

コンテナイメージはお客様が用意

APL-Middleware間のI/F非互換は発生しない。

management

◼ 製品をバージョンアップしても、APL-Middleware間のI/Fに影響は無いので、通常、APL修正は不要となります (OSバージョンアップと同様に動作検証は必要となります)。


製品のバージョンアップ時に影響を受ける場合

KubernetesAPI Server

アプリ

利用者

kubectl

運用操作で使用しているOSSのCLIは、OSS非互換の影響を受ける場合があるため、十分な動作検証をお願いします。また、運用操作以外でのCLIの使用は推奨しません。

KubernetesAPI呼び出し

アプリからKubernetesなどのAPIを呼び出している場合は、OSS非互換の影響を受ける場合があるため十分な検証が必要です。そのため、APLからのKubernetesなどのAPI呼び出しは推奨しません。

◼ 以下の場合は、バージョンアップ時にOSS非互換の影響を受ける可能性があります。このため、以下のように業務アプリから製品I/Fを直接使用しないことを推奨します。


サービス

◼ 本製品を購入し、利用する際には、以下のサービスを購入してください。

Enterprise Service Development Platform サービス商品

サービス名サービス内容アウトプット

Enterprise Service Development Platform 環境設計支援サービス

お客様ヒヤリングシートの要件に合わせて、Enterprise Service Development Platformの環境の設計を支援いたします。

・環境構成設計書（ネットワーク構成、サーバ(コンテナ)構成、各OSSの定義情報）

Enterprise Service Development Platform 環境構築サービス

環境構成設計書を元に、Enterprise Service Development Platformの環境を構築いたします。

・本製品を構築した環境・構築した環境の運用手順書（必要に応じて作成）


登録商標● VMwareは、VMware, Inc.の米国およびその他の国における登録商標です。● Linux は米国及びその他の国におけるLinus Torvaldsの登録商標です。● Windows Azure PlatformはWindows Azureと記載することがあります。● Microsoft, Windows, Windows Azureは、米国Microsoft Corporationの米国およびその他の国

における登録商標または商標です。● Red Hat、Red Hat Enterprise Linux、Shadowmanロゴ、JBossは米国およびその他の国において登

録されたRed Hat, Inc.の商標です。● OracleとJavaは、Oracle Corporation およびその子会社、関連会社の米国およびその他の国における

登録商標です。● 「Amazon Web Services」「AWS」「VPC」は、米国その他の諸国における、Amazon.com, Inc.または

その関連会社の商標です。●その他、本書に記載されている会社名および製品名は、それぞれ各社の商標または登録商標です。

なお、本書に記載されている会社名、システム名、製品名等には必ずしも商標表示 (TM・(R)) を付記しておりません。



Documents

Enterprise Service Development Platform ご紹介...マルチクラウド仕様/メリットと注意事項 V1.2ではFJCS仕様とマルチクラウド仕様を提供しますが、マルチクラウド仕様は