[Cloud] Announcing Oracle Cloud Infrastructure Streaming

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-cloud-infrastructure-streaming

今週シアトルで開催されているCloudNativeCon North America 2018で、Oracle Cloud Infrastructure Streaming(以下Streaming)という新しいサービスを発表できうれしく思っています。
CloudNativeCon North America 2018
https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
Streamingサービスは、リアルタイムに消費、処理できる大量のデータストリームを連続的に取り込むためのフルマネージドで拡張性のある永続ストレージを提供します。Streamingはメッセージング、アプリケーションログデータ、運用テレメトリデータ、Webクリックストリームデータやpublish-subscribeメッセージングモデルでデータが連続して順次生成され、処理されるようなユースケースなどといった大容量データに利用できます。

Use Cases

以下はOracle Cloud Infrastructure Streamingの多数考えられるユースケースのうちの一部です。
  • Messaging:
    Streamingをバックプレーンとして使用して、大規模システムのコンポーネントを疎結合にします。Streamingの主要なスコープである順序、低レイテンシ、永続性の保証により、さまざまなメッセージングパターンを実装するための信頼性の高いプリミティブを利用できます。高スループットに耐えるため、このようなシステムでのスケールが可能です。
  • Web/Mobile activity data ingestion:
    Webサイトやモバイルアプリからの利用状況データ(ページビュー、検索といったユーザーが取る得る操作)の流入パイプラインとしてStreamingを使用します。Streamingのコンシューマモデルにより、複数のリアルタイムモニタリングシステムおよび分析システム、オフライン処理およびレポート用のデータウェアハウスへの情報供給が簡単です。
  • Metric and log ingestion:
    伝統的なログやメトリックの集約アプローチの代わりにStreamingを使用し、重要な運用データをより迅速にインデックス作成、分析、および可視化に利用できるようにします。
  • Infrastructure and application event processing:
    監査、会計、および関連するアクティビティのライフサイクルイベントを報告するため、クラウドコンポーネントの統一されたエントリポイントとしてStreamingを使用します。

Managed Service

Oracle Cloud Infrastructure Streamingはサービス運用に必要な全てを管理しています。つまり、データをストリーミングするためのサービスのプロビジョニングからデプロイメント、メンテナンス、セキュリティパッチ、インフラストラクチャのストレージ、ネットワーク、ハードウェアやソフトウェアの構成の複製に至るまでです。

Security

Oracle Cloud Infrastructure Streamingはデフォルトでセキュアです。アカウントおよびデータストリームの所有者だけが作成するストリームリソースにアクセスできます。データアクセス制御のためのユーザー認証をサポートしており、Oracle Cloud Infrastructure Identity and Access Management (IAM) ポリシーを使用してユーザーおよびユーザー・グループに権限を選択的に付与できます。HTTPSプロトコルを使用して、SSLエンドポイントを介してStreamingに安全にデータを送信したり、取得したりできます。最後に、ユーザーデータは保存時、転送中ともども暗号化されます。

Getting Started

Oracle Cloud Infrastructure Streamingは2019年に一般提供される予定ですが、現在、Cloud Native Limited Availability Programを通じて、特定のお客様に限定してご利用いただけるようにしています。Streamingの詳細やStreamingへのアクセスを希望される場合には、こちらのフォームに登録してください。

[Cloud] Announcing Oracle Cloud Infrastructure Resource Manager

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-cloud-infrastructure-resource-manager-v2

今週シアトルで開催されているCloudNativeCon North America 2018で、Oracle Cloud Infrastructure Resource Manager(以下Resource Manager)という新しいサービスを発表できうれしく思っています。これはOracle Cloud Infrastructureのインフラストラクチャリソースの管理を簡単にするためのサービスです。Resource Managerを使うと、infrastructure as code (IaC)を使って、Compute、Networking、Storage、Load Balancingなどのインフラストラクチャ・リソースのプロビジョニングを自動化できます。
IaCの利用とは、つまりDevOpsプラクティスであり、これによって迅速かつ信頼性高い状態で大規模にインフラストラクチャのプロビジョニングが可能です。対象のシステムではなく、コードを変更します。そのコードはソース管理システムでメンテナンスできるので、必要に応じて協同作業や変更の追跡、文書化、逆展開も簡単です。

Terraform

インフラストラクチャを記述するため、Resource Managerは、クラウドインフラストラクチャを記述するための支配的な標準となっているオープンソースプロジェクトであるTerraformを使用します。OracleはTerraformに対して強くコミットしており、すべてのクラウドインフラストラクチャサービスをTerraformを通じて管理できるようにする予定です。今年初めにTerraform Providerをリリースし、Oracle Cloud Infrastructure用のTerraformモジュールをModule Registryに上げ始めました。
Oracle Cloud Infrastructure Terraform Provider Now Supported by HashiCorp
https://blogs.oracle.com/cloud-infrastructure/oracle-cloud-infrastructure-terraform-provider-now-supported-by-hashicorp
https://orablogs-jp.blogspot.com/2018/09/oracle-cloud-infrastructure-terraform.html
Terraform Module Registry
https://registry.terraform.io/search?q=oci&verified=false
今回、マネージドサービスを提供することで次のステップに踏み出ています。

Managed Service

プロバイダやモジュールに加えて、Oracleは、Terraformを操作するフルマネージドなサービスであるResource Managerを提供します。Resource ManagerはOracle Cloud Infrastructure Identity and Access Management (IAM)と統合されているため、Terraformの操作に対し詳細な権限設定が可能です。さらに、ステート・ロック(state locking)を提供します。これはユーザーにステートを共有する機能を提供し、チームがTerraformのデプロイメントにあたって効果的に共同作業を行うことを可能にします。何よりも、Terraformの操作をより簡単で信頼性の高いものにします。

Resource Managerを使用すると、スタックを作成してからTerraformアクションを実行できます。スタックを使用すると、Terraformの構成を分離できます。ここで、1個のスタックは一緒に作成したいOracle Cloud Infrastructureリソースの集合を表します。各スタックは、ダウンロード可能なTerraformの状態ファイルに個別にマップされます。

スタックを作成するには、コンパートメントを定義し、このスタックを作成する際にTerraform設定をアップロードします。このzipファイルには、作成したいリソースを定義しているすべての.tfファイルが含まれています。オプションでvariables.tfファイルを含めることも、コンソール上で(key,value) 形式で変数を定義することもできます。

スタック作成後、このスタックでplanapplydestroyといった様々なTerraformアクションを実行できます。これらのTerraformアクションはjobと呼ばれます。必要に応じて、新たなzipファイルをアップロードしてこのスタックを更新したり、この設定をダウンロードしたり、スタックを削除することもできます。

  • Plan: Resource Managerは構成を解析し、終了状態を説明するOracle Cloud Infrastructureリソースを並べた実行計画を返します。
  • Apply: Resource Managerは、planジョブの結果に基づいてスタックを作成します。この操作が完了すると、定義されたコンパートメントで正常に作成されたリソースを確認できます。
  • Destroy: Terraformはスタック内のすべてのリソースを削除しようとします。

IAMポリシーを使用して、スタックやジョブに対する権限を定義できます。 詳細な権限を定義し、特定のユーザーまたはグループのみがplan、apply、destroyといったアクションを実行できるように設定できます。

Availability

Resource Managerは2019年はじめに一般提供される予定ですが、現在、Cloud Native Limited Availability Programを通じて、特定のお客様に限定してご利用いただけるようにしています。現在利用可能な初期バージョンでは、Compute、Networking、Block Storage、Object Storage、IAM、Load Balancingの各サービスへのアクセスが可能です。Resource Managerの詳細やResource Managerへのアクセスを希望される場合には、こちらのフォームに登録してください。

[Cloud] Announcing Oracle Cloud Infrastructure Monitoring

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-cloud-infrastructure-monitoring

今週シアトルで開催されているCloudNativeCon North America 2018で、Oracle Cloud Infrastructure Monitoring(以下Monitoring)という新しいサービスを発表しました。
CloudNativeCon North America 2018
https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
Monitoringを使用すると、企業はスタック全体を監視するきめ細かなメトリックと通知を利用できます。Monitoringサービスを使用して、貴社はOracle Cloud Infrastructure Resourcesを含むスタックの健全性とパフォーマンスを理解し、リソース使用率を最適化し、異常にリアルタイムで対応できます。

Computeインスタンス、Virtual Cloud Network (VCN)、Virtual NIC、Block Store Volume、Load Balancer as a Service (LBaaS) などのOracle Cloud Infrastructure Resourcesには、パフォーマンスとヘルスのためのメトリックが用意されています。独自のCustom Metricを追加して、スタック全体の状況を可視化することもできます。

さらに、業界標準の統計、トリガーオペレータ、および時間間隔を使用して、これらのMetricでAlarmsも作成できます。Alarmは、Oracle Cloud Infrastructure Notificationsを使用して電子メールやPagerDutyを使ってスタック全体の重要な変更をリアルタイムで警告します。

Oracle Cloud Infrastructure ConsoleのインタラクティブなMetrics Explorerを使うと、データのフィルタリングやカスタマイズをしながら、リソース全体のMetricやCustom Metricを包括的に閲覧できます。Monitoringではクラス最高のメトリック・エンジンを搭載しているため、リアルタイムで複数のメトリック・ストリームやディメンションにわたって強力な集約様々な分析クエリを実行できます。MonitoringサービスのパブリックAPIとSDK/CLIを使えば、既存のエンタープライズインフラストラクチャとの容易な統合が可能になります。

Sample Monitoring use cases

Metrics Explorerを使うと、Oracle Cloud Infrastructure Resourcesの健全性を理解できます。メトリックは個別もしくは複数のリソースで集約して表示できます。以下の例は複数のComputeインスタンスの前日のCPU利用率です。

OCI Monitoringでは、事前遅疑した利用率の閾値を超えたCPU使用率などを通知します。リソースのCPU使用率が閾値を超えた場合、PagerDutyへの通知が呼びだされるか、チームに対してメール通知します。以下の例は、リソース使用率が24時間以上にわたって3%を下回るとアラームが呼び出されます。

Availability

Monitoringサービスは、Oracle Cloud Infrastructureがすべてのエンタープライズのワークロードやユースケースに対してクラス最高の基盤を提供することを保証するためのもう1つの中核的な柱を提供しています。Monitoringは2019年はじめに一般提供される予定ですが、現在、Cloud Native Limited Availability Programを通じて、特定のお客様に限定してご利用いただけるようにしています。Monitoringの詳細やMonitoringへのアクセスを希望される場合には、こちらのフォームに登録してください。

[Cloud] Announcing Oracle Cloud Infrastructure Notifications

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-cloud-infrastructure-notifications

今週シアトルで開催されているCloudNativeCon North America 2018で、Oracle Cloud Infrastructure Notifications(以下Notifications)という新しいサービスを発表しました。
CloudNativeCon North America 2018
https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
Notificationsはフルマネージドで、永続性のある、セキュアなPub-Subメッセージングサービスで、メッセージを多数の分散アプリケーションに大規模に配信します。サブスクライバのエンドポイントにメッセージをプッシュすることで、ポーリングのオーバーヘッドを削減します。NotificationsはOracle Cloud Infrastructureおよび外部にホストされているアプリケーションに向け、セキュア、高い信頼性と低レイテンシ、永続化されたメッセージを配信します。通知を送信し、分散システムとマイクロサービスを統合できるようになります。

Notifications Use Cases

以下はたくさん考えられるNotificationsのユースケースのうちの一部です。
  • Operational alerts
    Notificationsを使って、アプリケーションのアラート起因の通知を受け取ることができます。たとえば、Oracle Cloud Infrastructure Alarmsを構成して、通知をNotificationsのtopicに送信できます。そして、電子メールまたはPagerDutyのいずれかを使用してtopicをサブスクライブできます。
  • Application integration
    このfan-outシナリオでは、アプリケーションイベントをNotificationsのトピックに送信できます。その後、Notificationsはすべてのサブスクライバにメッセージをプッシュします。たとえば貨物管理アプリケーションでは、貨物ステータスの任意の変更をNotificationsを使って複数のアプリケーションに配信し、プロセスを開始したり、お客様に通知したりすることができます。

Getting Started

Oracle Cloud Infrastructure Notificationsは2019年はじめに一般提供される予定ですが、現在、Cloud Native Limited Availability Programを通じて、特定のお客様に限定してご利用いただけるようにしています。Notificationsの詳細やNotificationsへのアクセスを希望される場合には、こちらのフォームに登録してください。

[Cloud] Announcing Oracle Cloud Native Framework at KubeCon North America 2018

原文はこちら(いずれも内容は同一です)。
https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-cloud-native-framework-at-kubecon-north-america-2018-iaas
https://blogs.oracle.com/cloudnative/announcing-oracle-cloud-native-framework-at-kubecon-north-america-2018

Oracleは、KubeCon + CloudNativeCon North America 2018で、パブリック・クラウド、オンプレミス、およびハイブリッド・クラウドのデプロイメント・モデルを含む、包括的で持続可能でオープンなCloud Native開発ソリューションであるOracle Cloud Native Frameworkを発表しました。
KubeCon + CloudNativeCon North America 2018
https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
Oracle Arms Developers with the Most Comprehensive Cloud Native Framework
https://www.oracle.com/corporate/pressrelease/oracle-cloud-native-framework-121118.html
Oracle Cloud Native Frameworkは、最近発表されたOracle Linux Cloud Native Environmentと、オープンソースのFnプロジェクトをベースにした、マネージド・クラウドサービスとして利用できる、業界初のオープン・サーバーレス・ソリューションであるOracle Functionsを含む、Oracle Cloud Infrastructureクラウドネイティブサービスで構成されています。
Announcing Oracle Linux Cloud Native Environment
https://blogs.oracle.com/linux/announcing-oracle-linux-cloud-native-environment
Oracle Cloud Native Services
https://www.oracle.com/cloud/cloud-native/
Announcing Oracle Functions
https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-functions
https://blogs.oracle.com/developers/announcing-oracle-functions-v2
https://orablogs-jp.blogspot.com/2018/12/announcing-oracle-functions.html
Fn Project
https://fnproject.io/
今回の発表で、Oracleはパブリック・クラウド(Oracle Cloud Infrastructure)、ハイブリッド・クラウドおよびオンプレミス・ユーザー向けに、マネージド・クラウド・サービスおよびオンプレミス・ソフトウェアの間で統一されたクラウド・ネイティブ・ソリューションを提供およびサポートする唯一の主要クラウド・プロバイダーであること、そしてフレームワーク上に構築されたクラウド・ネイティブ・アプリケーションを任意の場所に双方向にシームレスに移植できるようにサポートします。フレームワークはオープンでCNCFが認定した準拠標準をベースにしているため、Oracle Cloud Native Framework上に構築されたアプリケーションは、任意のクラウドやインフラストラクチャ上のあらゆるKubernetes準拠の環境に移植可能です。

Oracle Cloud Native Framework – What is It?

Oracle Cloud Native Frameworkは、オープンなコミュニティ指向のCNCFプロジェクトをベースにした、Oracle Cloud Infrastructureクラウド・サービスとOracle Linuxオンプレミス・ソフトウェアのサポート対象のソリューションを提供します。これらは、昨年リリースされ、認定された最初のk8s製品の中で、オープンなKubernetes基盤上に構築されています。6つの新しいOracle Cloud Cloud Infrastructureクラウドネイティブサービスが、このソリューションの一部として発表され、既存のOracle Container Engine for Kubernetes (OKE)、Oracle Cloud Infrastructure Registry、Oracle Container Pipelinesサービス(a.k.a Wercker)上に構築されています。
Container Engine for Kubernetes
https://cloud.oracle.com/containers/kubernetes-engine

Cloud Native at a Crossroads – Amazing Progress

立ち止まってクラウドネイティブエコシステムがどこまで来たのかを考えるべきです。今週の完売したKubeConカンファレンスやKubernetesがもたらした成功と強力な基盤に関するスケール、興奮、そしてざわめきからもわかるかと思います。私たちは、開発者の黄金時代、大きな可能性を生み出す、以下の3つの力が集まって形成するクラウドネイティブ・デプロイメントとテクノロジーの文字通り「第一の波(First Wave)」に生きています。
  • Culture: DevOpsのカルチャーは、ソフトウェア開発とデプロイの方法を根本的に変え、アプリケーション開発チームの連携方法を根本的に変えました。方法論やカルチャーの変化サポートする作業やメトリックに約10年を費やして、SRE、DevSecOps、AIOps、GitOps、NoOpsなど、多くの関連する派生するものが生まれました(リストは間違いなく進化し続けるでしょう)。
  • Code: Netflix、Google、Uber、Facebook、TwitterなどのWebスケールの組織で徹底的にテストされとスピンアウトされたオープンソースとそのプロジェクトは、CNCF(Cloud Native Computing Foundation)のような組織の下で民主化されました。これは、最大の組織のエンタープライズ開発者と同じように、家庭で遊んだり学んだりするcitizen developers にも同じアクセスと機会が与えられます。
  • Cloud: 今日のクラウドでは、まったく新しいコンピューティング、ネットワーク、ストレージが利用可能であり、その力はベアメタルからGPUに至るまで、絶えず爆発的な規模で発展を続けています。これにより、HPCアプリ、Big Data、AI、ブロックチェーンなどの分野の開発者向けに新しいアプリケーションの開発の制約がなくなります。

Cloud Native at a Crossroads – Critical Challenges Ahead

あらゆる進歩にもかかわらず、この第1の波の成功の先に到達するための新たな課題に直面しています。多くの開発者やチームがカルチャーの変化に置き去りにされています。オープンソースは何千もの新しい選択肢やオプションを提供していますが、これにより、見かけ上は開発者用にすべて事前決定済みかつクローズドでプロプライエタリな場合よりも複雑になります。単一クラウドモデル(single source cloud model)への急激な動きは、クラウドロックインの問題を多く残し、その結果、選択肢が減少し、コストが上昇します。これは、オープンソースとクラウドが提供しようとしていたものとは正反対です。

以下の課題は上記の肯定的な勢力を反映しており、2018年8月のCNCF調査にも現れています。
CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%
https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/
  • Cultural Change for Developers: オンプレミスの伝統的な開発チームが置き去りにされています。カルチャーの変化が遅く、変化が進みません。
  • Complexity: あまりにも多くの選択肢があり、メンテナンスや管理を自身でするのは難しい状態です。
  • Cloud Lock-in: プロプライエタリな単一クラウドの場合、クローズドなAPIやサービス、可搬性のないソリューションでロックインされる可能性があります。

The Cloud Native Second Wave – Inclusive, Sustainable, Open

必要なのは、異なるアプローチです。
  • Inclusive(包括的):クラウドもオンプレミスも、モダンな方法も伝統的な方法も、dev(開発)もops(運用も、スタートアップも大企業も
  • Sustainable(持続可能):マネージドサービス vs DIY、オープンではあるがキュレーションされており、サポート対象のエンタープライズグレードのインフラストラクチャ
  • Open(オープン):真にオープン、コミュニティ主導、プロプライエタリのテクノロジーや利己的なOSS拡張には基づかない

Introducing the Oracle Cloud Native Framework – What’s New?

Oracle Cloud Native Frameworkは、パブリック・クラウド、オンプレミス、そしてハイブリッド・クラウドのデプロイメント・モデルにまたがるもので、選択肢を提供しつつ、開発者の幅広いデプロイメントニーズを唯一満足するものです。これには、Oracle Cloud Infrastructure Cloud Native ServicesとOracle Linux Cloud Native Environmentが含まれています。既存のOracle Container Engine for Kubernetes (OKE)、Oracle Cloud Infrastructure Registry、Oracle Container Pipelines (Wercker) といったサービス上で、プロビジョニング、アプリケーション定義および開発、 可観測性と分析にわたるサービスを有する一連の新しいOracle Cloud Infrastructureのクラウドネイティブサービスが発表されました。
The Journey to Enterprise Managed Kubernetes
https://blogs.oracle.com/cloud-infrastructure/the-journey-to-enterprise-managed-kubernetes

Use Cases for the Oracle Cloud Native Framework: Inclusive, Sustainable, Open

Inclusive:
Oracle Cloud Native Frameworkには含まれます、クラウドとオン・プレミスの両方が含まれており、モダンなアプリケーションならびに従来のアプリケーションならびにdevとopsをサポートします。さらに、新興企業でも大企業でもご利用いただけます。業界として、クラウドネイティブの高速道路へのより多くの流入路を作成する必要があると考えています。特に、チームやテクノロジーに触れ、人々が日々知り取り組んでいるものにクラウドネイティブを結合することによって、より多くの流入路を作成する必要があると考えています。WebLogic Server Operator for Kubernetesは、まさにその素晴らしい例です。 これにより、既存のWebLogicアプリケーションを、Kubernetesクラスタ管理に簡単に統合して活用できます。
Announcing WebLogic Server Certification on Oracle Cloud Infrastructure Container Engine for Kubernetes
https://blogs.oracle.com/weblogicserver/announcing-weblogic-server-certification-on-oracle-cloud-infrastructure-container-engine-for-kubernetes
https://orablogs-jp.blogspot.com/2018/06/announcing-weblogic-server.html
Oracle Weblogic Server Kubernetes Operator
https://github.com/oracle/weblogic-kubernetes-operator

別の例として、Project Helidonでは、より迅速にクラウドネイティブの世界に移行するため、マイクロサービス・アーキテクチャとJavaアプリケーションのためのフレームワークを作成しています。
Project Helidon
https://helidon.io/

多くのOracle Databaseのお客様は、新しいWebフロントエンドやAI/ビッグ・データ処理のバックエンドのために、Kubernetesベースのクラウドネイティブ・アプリケーションに接続されており、Oracle Autonomous DatabaseとOKEの組み合わせにより、自動運転、セキュリティ確保、 クラウドネイティブアプリケーションの修復のための新しいモデルが作成されます。たとえば、Kubernetesサービス・ブローカとサービス・カタログ・テクノロジを使用することで、開発者はAutonomous Transaction ProcessingアプリケーションをOracle Cloud Infrastructure上のOracle Cloud Infrastructure上のOKEサービスと簡単に接続できます。
Oracle Autonomous Database
https://www.oracle.com/database/autonomous-database.html

Sustainable:
Oracle Cloud Native Frameworkは、マネージド・クラウド・サービスのセットとサポートされているオンプレミス・ソリューションを提供します。これはオープンでキュレーションされており、エンタープライズ・グレードのインフラストラクチャ上に構築されています。新しいオープンソースプロジェクトが毎日現れており、Kubernetesのような既存のプロジェクトの変更の割合は驚異的です。ランドスケープが成長している間、企業やチームは非常に迅速に学び、変更し、採用することしかできないため、業界とベンダーは複雑さの結果としての挑戦に直面しなければなりません。

統一されたフレームワークにより、キュレーションとサポートを通じてこの複雑さが軽減されます。マネージド・クラウドサービスは、企業がやらざるを得なかった管理、トレーニング、学習の問題を軽減する秘密の武器です。これまでDIYのアプローチしか選択できませんでしたが、OKEのようなマネージド・クラウドサービスは、開発者がクラウドネイティブに飛び乗るチャンスを与えます。長くて厄介な学習曲線は必要ありません。

オープンなエンタープライズ・グレードのインフラストラクチャ上に構築された持続可能なモデルは、企業に対し、次の5つの主要なハイブリッドクラウドユースケースを含むリアルなハイブリッド・クラウド・デプロイメントを構築するためのセキュアで高性能なプラットフォームを提供します。
  1. Development and DevOps: クラウドで開発・テストをして、本番はオンプレミス
    1. Application Portability and Migration: 双方向のクラウド・ネイティブ・アプリケーションの移植性(オンプレミスからクラウド、クラウドからオンプレミス)と lift and shift の移行を可能にします。Oracle MySQL Operator for Kubernetesは、移植性とMySQLアプリケーションのクラウドネイティブなツールへの統合を簡素化する極めて人気のあるソリューションです。
      Introducing the Oracle MySQL Operator for Kubernetes
      https://blogs.oracle.com/developers/introducing-the-oracle-mysql-operator-for-kubernetes
      これにより、データベースバックアップや既存のバックアップからの復元といった運用作業を含め、シンプルな宣言的な構成形式に基づいて、本番運用可能なMySQLクラスタの作成と管理が可能になります。MySQL Operatorを使うと、Kubernetes上でのMySQLの実行、ならびにアプリケーションの移植性と移行性の向上を簡単に実現できます。
      MySQL Operator - Create, operate and scale self-healing MySQL clusters in Kubernetes
      https://github.com/oracle/mysql-operator
    2. HA/DR: クラウド、本番系のオンプレミスにおけるディザスタリカバリや高可用性サイト
    3. Workload-Specific Distribution: 例えばレイテンシ、法令、新しいもの、レガシーなものなどといったワークロードの種類に基づいて、ワークロードの実行先をクラウド、オンプレミスで選択してください。
    4. Intelligent Orchestration: もっと先進的なハイブリッドのユースケースでは、洗練された分散アプリケーション・インテリジェンスとフェデレーションが必要です。これらにはクラウドバーストやKubernetesのフェデレーションが含まれます。
    Open: ここ数年の間にわたって、開発チームは単一クラウドモデル、換言すると、素早く簡単なソリューションを採用して、迅速に移動し、複雑さの軽減を選択することが通常でしたが、その結果、プロプライエタリなサービス、クローズドなAPI、可搬性のなソリューションに起因するクラウドロックインに対してお金を支払っているのが現状です。これは、オープンソース、CNCFベースのコミュニティ主導型の技術のおかげにもかかわらず、業界として産業として我々が進むべきところとは正反対です。

    オープンなエコシステムにより、ハイブリッド・クラウドの世界だけでなく、本当のマルチ・クラウドの世界を実現します。そしてそれこそがOracle Cloud Native Frameworkを推進するビジョンなのです。

    [Functions, Cloud] Announcing Oracle Functions

    原文はこちら(内容はほぼ同じです。今回はv2を対象にしています)。
    https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-functions
    https://blogs.oracle.com/developers/announcing-oracle-functions-v2

    Seattleで開催中のKubeCon 2018で、OracleはOracle Functionsという、企業がサーバーレスアプリケーションをクラウドで開発、実行できる新たなクラウドサービスを発表しました。

    Oracle Functionsはサーバーレス・プラットフォームで、これを使うと簡単に開発者がコードを記述、デプロイできます。コンピューティング基盤やネットワーク基盤のプロビジョニングおよび管理を心配する必要はありません。Oracle Functionsは全ての基盤となるインフラストラクチャを自動的に管理し、サービスへの着信リクエストにあわせてエラスティックにスケールします。Oracle Functionsを使うと、開発者はビジネスバリューを提供するコードを記述することに集中できます。

    Pay-per-Use

    Serverless functionsはクラウドコンピューティングの経済モデルを変えています。お客様に対してはfunction実行時に使うリソースに対してのみ課金し、アイドル時間に課金されることはありません。このアプローチは、ユーザーがプロビジョニングし、管理する仮想マシンやコンテナにコードをデプロイするこれまでのアプローチとは異なるものです。これまでのアプローチでは、24x7実行する場合、アイドル時間であっても支払う必要がありますが、Pay-per-use(使った分だけお支払い)のため、断続的なワークロードやスパイクする使用パターンのワークロードにとって、Oracle Functionsは理想的なプラットフォームです。

    Open Source

    オープンソースにより、Oracleを含む企業のソフトウェアビルド方法が変わりました。独自のクラウドfunctionプラットフォームを構築するのではなく、OracleはApache 2.0ライセンスのオープンソースFn Projectに投資し、FnでOracle Functionsを構築することを選択しました。この方法を使えば、Oracle Functions用に作成されたコードは任意のFnサーバー上で実行されます。functionは、Oracle Functionsまたはオンプレミス、または別のクラウド・プラットフォーム上でお客様が管理されるFnクラスタにデプロイできます。

    つまり、Oracle Functionsの利点は、サーバーレスサービスゆえに、お客様は顧客がFnクラスタや基盤となるコンピューティング・インフラストラクチャを手動で管理する必要がなくなります。とはいえ、オープンソースのFnのおかげで、お客様は常に最善の価格やパフォーマンスを定休するプラットフォームにご自身のfunctionをデプロイする選択肢を有します。我々はお客様が選択されるそのプラットフォームがOracle Functionsであるものと自信を持っています。

    Container Native

    他のほとんどのfunctionsプラットフォームとは異なり、Oracle FunctionsはContainer Nativeであり、functionはDockerコンテナ・イメージとしてパッケージ化されます。このアプローチは、新規ユーザのための生産性の高い開発者エクスペリエンスをサポートしつつ、パワーユーザは、必要なネイティブライブラリをインストールするなど、functionランタイム環境を完全にカスタマイズすることができます。幅広いDockerエコシステムとその柔軟性により、開発者はビジネス上の問題の解決に集中できます。独自のクラウドfunctionプラットフォームで頻繁に発生する制限を克服する方法を理解することに注力する必要はありません。

    functionはDockerコンテナとしてデプロイされます。そのため、Oracle Functionsはfunctionコンテナ・イメージの格納に使用されるDocker Registry v2準拠のOracle Cloud Infrastructure Registryとシームレスに統合されています。Oracle Functionsと同様に、Oracle Cloud Infrastructure Registryもサーバレスであり、pay-per-useでもあります。単にfunctionをビルドし、コンテナイメージをレジストリにプッシュすれば、使用されたリソースだけに対して課金されます。

    Secure

    セキュリティはOracle Cloudにとって最重要項目で、Oracle Functionsも例外ではありません。Oracle Functionsにデプロイされたfunctionへの全てのアクセスはOracle Identity and Access Management (IAM)で管理されています。IAMを使ってfunction管理とfunction実行権限を特定のユーザーやユーザーグループに割り当てることができます。デプロイの後、function自信は明示的にアクセスを許可されたコンパートメントのVCNのリソースにしかアクセスできません。セキュアなアクセスもまた、Registryに格納されたfunctionコンテナ・イメージのデフォルトです。認可されたユーザーのみがfunctionコンテナにアクセス、デプロイできることを保証するため、Oracle FunctionsはRegistryというプライベート・レジストリと連携します。いずれの場合も、お客様にはお客様自身のfunctionアセットに対して完全なアクセスを提供しつつ、Oracle Functionsは"secure by default"のアプローチを取ります。

    Getting Started

    Oracle Functionsは2019年に一般提供の予定ですが、現在Cloud Native Limited Availability Programを通じて一部のお客様に限定して提供しています。Oracle Functionsの詳細を知りたい方は、アクセスリクエストをしたい方は、是非こちらのフォームに登録してください。Oracle Functionsの基盤のオープンソーステクノロジーについて知りたい方は、以下のFn Projectのページをご覧ください。
    Fn Project - Open Source. Container-native. Serverless platform
    http://fnproject.io/

    [Java] Java Local Variable Type Inference: Frequently Asked Questions

    原文はこちら。
    https://openjdk.java.net/projects/amber/LVTIFAQ.html

    Why have var in Java?(なぜJavaにvar?)

    ローカル変数はJavaの主役です。ローカル変数を使うと、メソッドが中間値を安いコストで格納することにより、重要な結果を計算できます。フィールドとは異なり、ローカル変数は宣言されたブロック内でのみ利用するため、コンパイラは常にローカル変数が利用前に初期化されていると保証できます。コードを理解する上で、ローカル変数の名前や初期値は、ローカル変数の方よりも重要であることがよくあります。型は重要ではありますが、次の行で使う名前のほうが重要なことがあります。varを使うことで、ローカル変数宣言の重要な部分を目立たせることができます。

    型ではなくvarを使う場合、Javaコンパイラは初期値から変数の型を推論します。これは特に型が長い名前であったり、複雑なパラメータ化された型、もしくは型が初期値と重複している場合に価値があります。varを使うことで、コードの読みやすさを犠牲にせずに簡潔にできますし、土岐には冗長性を取り除いて可読性を向上させることもできます。

    Does this make Java dynamically typed? Is this like var in JavaScript?(これはJavaが動的な型になるということですか?JavaのvarはJavaScriptのvarのようなものですか?)

    どちらの質問に対する答えも、Noです。Javaは変わらず静的型言語で、varが加わったからといって変わることはありません。型ではなく、varをローカル変数の宣言で利用可能、というだけです。varを使う場合、Javaコンパイラはコンパイル時に変数のイニシャライザから取得する型情報を使って変数の型を推論します。その後、変数の静的型として推論された型を使います。通常、推論した型は明示的に書いた場合と同じ型のため、varを使って宣言した変数は、型を明示的に記述した場合とまったく同じように正しく振る舞います。

    Javaコンパイラは長年にわたって型推論をしてきました。例えばJava 8では、ラムダ式のパラメータには明示的な型を必要としていませんが、これはコンパイラがラムダ式での使われ方から、パラメータの型を推論しているからです。
    List<Person> list = ...
    list.stream().filter(p -> p.getAge() > 18) ...
    上記のコード・スニペットでは、ラムダ式のパラメータ p は静的な型Personを持つと推論しています。getAgeメソッドを持たないようにPersonクラスを変更した場合、もしくはPerson以外の型のリストに変更した場合、型推論はコンパイル時のエラーで失敗します。

    Is a var variable final?(varで宣言した変数はfinalですか?)

    いいえ。varで宣言したローカル変数はデフォルトでfinalではありません。ただし、final修飾子はvar宣言に追加できます。
    final var person = new Person();
    Javaではfinal varの短縮はありません。Scalaのような言語ではvalを使ってイミュータブル(final)変数を宣言します。Scalaの場合、全変数(ローカル変数でもフィールドでも)が以下の形式の構文を使って宣言されるため、うまくいきます。
    val name : type
    もしくは
    var name : type
    型推論させたいか否かによって、宣言の": type"部分を含めることも、省略することもできます。Scalaの場合、可変性(mutability)と不変性(immutability)の選択が型推論と直交します。

    Javaの場合、varは型推論が必要な場合にのみ利用できます。つまり、明示的に型宣言されている箇所では利用できません。valを追加した場合、この場合も型推論を用いる箇所でのみ利用できます。型が明示的に宣言されている場合、Javaでvarもしくはvalの利用によって不変性を制御することはできません。

    さらに、Javaではvarをローカル変数に対してのみ利用できます(フィールドは対象外です)。不変性はフィールドではずっと重要ではありますが、イミュータブルなローカル変数は(イミュータブルなフィールド変数に比べると)あまり使われません。

    var/val キーワードを使って不変性を制御することはScalaからJavaへきれいに引き継ぐべきであるような機能ですが、JavaにおいてはScalaにおける場合ほど有用ではないと思われます。

    Won't bad developers misuse this feature to write terrible code?(ひどい開発者がこの機能を誤用してとんでもないコードを書くのではないでしょうか?)

    はい、ひどい開発者はどんなふうにしてもひどいコードを書くことでしょう。機能を保留しても、ひどいコードを禁止できないでしょうしかし、適切に利用すれば、開発者は型推論を使ってよりよいコードを書くことができます。

    varの利用によって、新しい変数の宣言のオーバーヘッドが減るため、開発者はよりよいコードを書くことができます。変数の宣言のオーバーヘッドが高いと、開発者はそのオーバーヘッドを避けようとします。そのため、より多くの変数宣言をせずにすむよう、可読性を損なう複雑なネスト、もしくはチェーンになった式を作成するでしょう。varを使うと名前付き変数に部分式(subexpression)を引き渡すオーバーヘッドが少なくなるため、開発者はvarを使うようになるでしょう。その結果、コードがきれいになるでしょう。

    機能が導入されると、まず最初はプログラマーがその機能を使用したり、過度に使用したり、悪用したりすることさえあるでしょう。が、それはよくあることです。合理的な利用方法に関するガイドラインにコミュニティが落ち着くまでには時間がかかります。大部分のローカル変数宣言ではなく、かなり頻繁にvarを使用することはおそらく合理的です。

    ローカル変数の型推論[Local Variable Type Inference (LVTI)]から、機能提供開始時期にあわせてこのFAQやLVTI Style Guidelinesのような、推奨する利用方法に関する資料を公開しています。
    Style Guidelines for Local Variable Type Inference in Java
    https://openjdk.java.net/projects/amber/LVTIstyle.html
    https://orablogs-jp.blogspot.com/2018/03/style-guidelines-for-local-variable.html
    こうした取り組みがコミュニティによる合理的なvarの利用方法の収束を加速し、ほとんどのvarの乱用を避ける手助けになることを願っています。

    Where can var be used?(varを利用可能な箇所は?)

    var はローカル変数やfor-loopのインデックス変数、try-with-resourcesにおけるリソース変数の宣言目的で利用できます。

    ただし、var はフィールドやメソッドパラメータ、メソッドの戻り値で利用することはできません。それは、これらの場所の型は明示的にクラスファイルやjavadoc仕様書に現れているからです。型推論を使えば、イニシャライザへの変更によって変数の推論された型を変更するのはきわめて簡単です。ローカル変数の場合、これは問題ありません。というのも、ローカル変数はスコープが限定されており、ローカル変数の型はクラスファイルに直接記録されていないからです。しかしながら、フィールドやメソッドのパラメータ、メソッドの戻り値の型を推論する場合、型推論では簡単に問題が発生する可能性があります。

    例えば、メソッドの戻り値がメソッドのreturn文から推論されたとしましょう。メソッドの実装に対する変更により、return文の式の型が変更される可能性があります。この結果、メソッドの戻り値の型が変わるため、ソースやバイナリの非互換性が発生する可能性があります。このような互換性のない変更は、実装の無害な変更から生じるべきではありません。

    推論によりフィールドの型が決まる場合、フィールドのイニシャライザへの変更の結果フィールドの型が変わる可能性があり、結果としてreflective codeを予期せずに破壊する可能性があります。

    型推論は実装内ではOKですが、APIではNGです。APIのコントラクトは明示的に宣言すべきです。

    APIの一部ではないプライベート・フィールドやメソッドではどうでしょうか?理論的には、従属コンパイルと動的リンクにより互換性を損なう心配がないため、privateフィールドとprivateメソッドの戻り値の型に対してvarをサポートすることも可能でしたが、簡単のためにこのように型推論のスコープを制限することにしました。いくつかのフィールドといくつかのメソッドの戻り値を含むように境界をプッシュしようとすると、そのフィーチャはかなり複雑で難しくなるものの、有用性はそれほど向上しません。

    Why is an initializer required on the right-hand side of var?(イニシャライザがvarの右辺に必要な理由は?)

    変数の型は、イニシャライザの型から推測されます。これはもちろん、varはイニシャライザがある場合にのみ使用できるということです。変数への代入から型を推測することも可能でしたが、その場合、この機能がかなり複雑になってしまい、誤解を招くか、診断しづらいエラーにつながる可能性があります。物事を単純にするために、ローカル情報だけを使って型推論するようvarを定義しました。

    宣言とは別の複数の場所での代入を基にして型推論できたとしましょう。例えば以下のような例です。
    var x;
    ...
    x = "foo";
    ...
    x = 17;
    (例えば)最初の代入に基づいて型を選択した場合、エラーの原因から遠く離れた別の文でエラーが発生します(これは「遠隔操作」問題とも呼ばれることがあります)。

    あるいは、すべての割り当てと互換性のあるタイプを選択することもできますが、この場合、推論される型がObjectであると予想される方がいらっしゃるかもしれません。というのも、ObjectStringIntegerの共通のスーパークラスであるためです。しかし残念ながら、この状況はもっと複雑です。StringIntegerの両方がSerializableにしてComparableであるため、共通のスーパータイプは以下のような奇妙な交差型になるでしょう。
    Serializable & Comparable<? extends Serializable & Comparable<...>>
    (この型の変数を明示的に宣言できないことに注意してください。)また、17をxに代入すると、予期せず、望ましくないボクシング変換(boxing conversion)が発生します。

    これらの問題を避けるため、明示的なイニシャライザを使った型推論を要求したほうがよいと思われます。

    Why can't you use var with null?(nullと一緒にvarを使ってはいけない理由は?)

    以下のような宣言を考えてみましょう(これは誤りです)
    var x = null; // ERROR
    nullリテラルは、Javaのすべての参照型のサブタイプである特殊なnull型(JLS 4.1)の値を示します。
    The Java® Language Specification - Java SE 11 Edition
    The Kinds of Types and Values
    https://docs.oracle.com/javase/specs/jls/se11/html/jls-4.html#jls-4.1
    null型の唯一の値はnullそのものなので、null型の変数に代入できる唯一の値はnullです。これはあまり役に立ちません。

    nullに初期化されたvar宣言がObject型を持つと推測されるように特別な規則を作ることもできました。確かに可能なのですが、プログラマの意図に対する疑問が出てきます。変数は後で他の値に割り当てることができるように、nullに初期化されている場合、変数の型をObjectとして推論するのは正しい選択であるとは考えづらいのです。

    このケースを処理するための特別なルールを作らず、禁止することにしました。Object型の変数が必要な場合、明示的に宣言する必要があります。

    Can you use var with a diamond on the right-hand side?(右辺でダイアモンド演算子と一緒にvarを利用できる?)

    はい、可能です。しかし、おそらくは期待されているようなものではないでしょう。例えば以下の例を考えます。
    var list = new ArrayList<>();
    この場合、リストの型がArrayList<Object>であると推論されます。一般的には、右側でダイヤモンドを使う場合は左側で明示的な型を、左側でvarを使う場合には右側には明示的な型を、それぞれ使用するのが望ましいでしょう。詳細については、LVTIスタイルガイドラインのガイドラインG6を参照してください。
    Style Guidelines for Local Variable Type Inference in Java
    G6. Take care when using var with diamond or generic methods.
    https://openjdk.java.net/projects/amber/LVTIstyle.html#g6.-take-care-when-using-var-with-diamond-or-generic-methods.
    https://orablogs-jp.blogspot.com/2018/03/style-guidelines-for-local-variable.html#G6

    [Cloud] Customer Managed VM Maintenance with Reboot Migration

    原文はこちら。
    https://blogs.oracle.com/cloud-infrastructure/customer-managed-vm-maintenance-with-reboot-migration

    クラウドプロバイダーに基盤となるインフラストラクチャの管理を任せることが出来る点が、クラウドへワークロードを移行する主要なメリットの一つです。これのおかげで、特定のビジネスソリューションに対してより多くのリソースを注力できます。しかしながら、時としてメンテナンスが発生してクラウドリソースの利用ができなくなることがあります。そのため、スケジュール済みダウンタイムを把握しておくだけでなく、ビジネスニーズに従ってクラウド利用不可の状態に備えることが重要です。
    Oracle Cloud InfrastructureのComputeサービスの場合、Customer Managed VM Maintenanceを使って、こうしたまれなハードウェアメンテナンスイベントに関連付けられたダウンタイムをコントロールできます。お使いのVMをサポートする基盤システムに対するメンテナンスイベントが計画されると、スケジュール済みメンテナンスイベントの前の任意のタイミングでインスタンスを再起動すれば、別のインフラストラクチャにお使いのVMを移行できます。

    How It Works

    実際のメンテナンスイベントがスケジュールされるおよそ2週間前に、Oracle Cloud Infrastructureからメール通知を受け取ることになるでしょう。このメールには、日付と停止時間、このイベントによって影響を受けるインスタンスのリスト、そしてメンテナンス日時までの任意のタイミングで異なるインフラストラクチャにインスタンスを移行する方法が明示されています。この通知メールが正しい受信箱に届くように、Oracle Cloud Infrastructureのアカウントをメールアドレスにしておくとよいでしょう。

    同じ情報はOracle Cloud Infrastructureのコンソールからもご覧いただけます。スケジュール済みのメンテナンスの影響を受けるすべてのVMインスタンスにはMaintenance Rebootフラグのマークが付きます。


    この情報を無視すれば、インスタンスは再起動を含む予定されたメンテナンスプロセスを踏みます。しかし、スケジュール済みメンテナンスの前に、より都合のよい時間にインスタンスを再起動してサービスの可用性を向上できます。コンソール、API、CLIから再起動を実行できます。インスタンス再起動時にクラウドの別のインフラストラクチャでインスタンスを実行すると、メンテナンスフラグが消えます。

    Checking for Scheduled Maintenance

    運用ポリシーの一環として、定期的にメンテナンス再起動が必要な全てのインスタンスを確認したい、と思うかもしれません。コンソールでは、Advanced Searchの以下の事前定義済みクエリを使うことができます。
    "Query for all instances which have an upcoming scheduled maintenance reboot"

    コンソールには一度に1個のリージョンのリソースが表示されますので、各リージョンで個別にクエリを実行する必要があります。

    APIもしくはCLIの場合、timeMaintenanceRebootDueプロパティを使ってフラグ付きインスタンスをフィルタリングできます。以下のスクリプトを使って、テナントの有効な全リージョンにわたり、全ての対象インスタンスをリストアップできます。
    Instances flagged for reboot migration
    https://github.com/radudobrinescu/oci-miscellaneous/blob/master/list_maintenance_instances.py
    このスクリプトを日次実行すれば、緊急時であっても、フラグの付いたインスタンスへの対応に十分な時間を確保できるようになります。

    Considerations

    この機能は現在、OracleのイメージもしくはカスタムイメージのLinux OSを実行するStandardVMシェイプに限定されています。non-iSCSIブロックボリュームをアタッチしていたりセカンダリVNICを持っていたりするインスタンスの場合、ブロックボリュームやセカンダリVNICをインスタンス再起動の前にデタッチしておく必要があります。再起動後、これらを再度アタッチして通常の運用を再開できます。

    将来は、この機能が全てのVMシェイプ、non-iSCSIブロックボリュームやセカンダリVNICがアタッチされているインスタンスをサポートすることになるでしょう。

    Conclusion

    カスタママネージドVMメンテナンス(Customer Managed VM Maintenance)機能を使うと、メンテナンスを必要とするインフラストラクチャ上で動作するVMインスタンスのダウンタイムをコントロールできます。これらのインスタンスを(メール通知もしくはスクリプトを実行して)識別すれば、アプリケーションにとって都合のよい時間に再起動することで新たなインフラストラクチャに移行できます。

    [Cloud, Kubernetes, Docker] Deploy containers on Oracle Container Engine for Kubernetes using Developer Cloud

    原文はこちら。
    https://blogs.oracle.com/developers/deploy-containers-on-oracle-container-engine-for-kubernetes-using-developer-cloud

    前回のエントリでは、Oracle Developer Cloudを使ってビルドし、Node.jsマイクロサービスのDockerイメージをDockerHubにプッシュする方法をご紹介しました。
    Build and Deploy Node.js Microservice on Docker using Oracle Developer Cloud
    https://blogs.oracle.com/developers/build-deploy-nodejs-microservice-on-docker-using-oracle-developer-cloud
    DockerHub
    https://hub.docker.com/
    このエントリでは、Oracle Developer Cloudを使ってDockerHubにプッシュしたDockerイメージをContainer Engine for Kubernetes(OKE)にデプロイする方法をご紹介します。

    Container Engine for Kubernetes

    Container Engine for Kubernetes(OKE)はOracle Cloud Infrastructure(OCI)のもつ管理、セキュリティ、予測可能なパフォーマンスを備えた、高可用性クラスタを実行するためのdeveloper-friendlyでcontainer-nativeかつenterprise-readyなマネージドKubernetesサービスです。以下のリンクでOKEの紹介をしています。
    Container Engine
    https://cloud.oracle.com/containers/kubernetes-engine

    Prerequisites for Kubernetes Deployment

    1. Oracle Cloud Infrastructure (OCI) アカウントにアクセス
    2. OCIにKubernetesクラスタを構成
      以下のチュートリアルでOCI上にKubernetesクラスタを構成する手順を説明しています。
      Creating a Cluster with Oracle Cloud Infrastructure Container Engine for Kubernetes and Deploying a Sample App
      https://www.oracle.com/webfolder/technetwork/tutorials/obe/oci/oke-full/index.html

    Set Up the Environment:

    Create and Configure Build VM Templates and Build VMs

    ビルドジョブ実行のために必要なソフトウェアを含むBuild VMテンプレートおよびBuild VMを作成する必要があります。

    ユーザーのアバターをクリックして、メニューからOrganizationを選択します。



    Click VM Templates をクリックすると New Template 作成ダイアログが出ますので、テンプレート名(例えばKubernetes Template)を入力し、プラットフォームに”Oracle Linux 7"を選択して、Createボタンをクリックしましょう。


    テンプレート生成完了後、Configure Softwareをクリックします。


    構成時に利用可能なソフトウェアバンドルから、kubectlOCIcliを選択(Python3 3.6も追加するように尋ねられることでしょう)し、をクリックしてこれらのソフトウェアバンドルをテンプレートに追加します。



    Done をクリックして、Build VMテンプレートのためのソフトウェア構成を完了します。

    Virtual Machinesのページで+New VM をクリックし、現れるダイアログにて作成したいVMの個数と先ほど作成したVMテンプレート(Kubernetes Template)を選択します。


    Add をクリックしてVMを追加します。


    Kubernetes deployment scripts

    Projectページで + New Repository をクリックして新たなリポジトリを追加します。


    リポジトリ作成後、Developer CloudはCodeページに移動し、NodejsKubernetesリポジトリが表示されます。 +Fileボタンをクリックすると、リポジトリに新しいファイルが作成されます(リポジトリ内のREADMEファイルは、プロジェクトの作成時に作成されたものです)。


    以下のスクリプトをテキストエディタにコピーし、nodejs_micro.yamlという名前でファイルに保存します。
    apiVersion: apps/v1beta1
    kind: Deployment
    metadata:
      name: nodejsmicro-k8s-deployment
    spec:
      selector:
        matchLabels:
          app: nodejsmicro
      replicas: 1 # deployment runs 1 pods matching the template
      template: # create pods using pod definition in this template
        metadata:
          labels:
            app: nodejsmicro
        spec:
          containers:
          - name: nodejsmicro
            image: abhinavshroff/nodejsmicro4kube:latest
            ports:
            - containerPort: 80 #Endpoint is at port 80 in the container
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: nodejsmicro-k8s-service
    spec:
      type: NodePort #Exposes the service as a node port
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        app: nodejsmicro
    
    Commit ボタンをクリックしてファイルを作成し、コード変更をコミットします。


    Commit changesダイアログ内のCommit ボタンをクリックします。


    以下のスクリーンショットのように、 nodejs_micro.yaml ファイルがNodejsKubernetes.git リポジトリのファイルリストに現れるはずです。


    Configuring the Build Job

    ナビゲーションバーの Build をクリックしてBuildページを表示します。+New Job ボタンをクリックして、新規ビルドジョブを作成します。このダイアログでは、ジョブ名として NodejsKubernetesDeploymentBuild を、Software TemplateのドロップダウンリストからSoftware Templateとして Kubernetes Template を選択します。その上で、Create Jobボタンをクリックしてビルドジョブを作成します。


    ビルドジョブ作成後、構成画面に遷移します。タブをクリックしてリポジトリのドロップダウンリストからNodejsKubernetes.git を選択します。これはnodejs_micro.yaml ファイルを作成したのと同じリポジトリです。
    Branchのドロップダウンリストからmasterを選択します。


    In the Builders タブでAdd Builderドロップダウンをクリックし、ドロップダウンリストからOCIcli Builder を選択します。


    OCIcli Builderフォームの各入力フィールドへの入力必要事項を確認し、これらの値の取得箇所を調べるには、以下のエントリもしくは以下のドキュメントの章をご覧ください。
    Oracle Cloud Infrastructure CLI on Developer Cloud
    https://blogs.oracle.com/developers/oracle-cloud-infrastructure-cli-on-developer-cloud
    Oracle® Cloud - Using Oracle Developer Cloud Service
    Access Oracle Cloud Infrastructure Services Using OCIcli
    https://docs.oracle.com/en/cloud/paas/developer-cloud/csdcs/manage-project-jobs-and-builds.html#GUID-DD932D11-2A66-4C45-9E0C-598E07984C9F
    Note: 下記スクリーンショット中の値はセキュリティ上の理由で難読化しています。


    Add Builder ドロップダウンリストを再度クリックしてUnix Shell Builderを選択します。


    Unix Shell Builderのテキスト領域に、Kubernetes構成ファイルをダウンロードし、以前のエントリに記載した手順に従って作成したOKE上のコンテナにデプロイするするためのスクリプトを追加します。
    Build and Deploy Node.js Microservice on Docker using Oracle Developer Cloud
    https://blogs.oracle.com/developers/build-deploy-nodejs-microservice-on-docker-using-oracle-developer-cloud
    Saveボタンをクリックしてビルドジョブを保存します。


    mkdir -p $HOME/.kube
    oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.iad.aaaaaaaaafrgkzrwhtimldhaytgnjqhazdgmbuhc2gemrvmq2w --file $HOME/.kube/config --region us-ashburn-1
    export KUBECONFIG=$HOME/.kube/config
    kubectl config view
    kubectl get nodes
    kubectl create -f nodejs_micro.yaml
    sleep 120
    kubectl get services nodejsmicro-k8s-service
    kubectl get pods
    kubectl describe pods
    
    This このスクリプトはkubeディレクトリを作成し、OCIcliコマンドのoci ce clusterを使ってKubernetesクラスタ構成ファイルをダウンロードした上で、KUBECONFIG環境変数を設定します。

    kubectl configコマンドとkubectl get nodesコマンドは、クラスタ構成の表示とクラスタのノードの詳細を表示するものです。kubectl createコマンドは、実際にKubernetesクラスタにDockerコンテナをデプロイします。getサービスを実行し、get podsコマンドを実行して、デプロイ済みコンテナのIPアドレスとポート番号を取得します。 nodejsmicro-k8s-serviceという名称は、nodejs_micro.yamlファイルで事前に構成されていたことに注意してください。

    Note: クラスタのOCIDは、上のスクリプトに記載してあるため、各々の環境に合わせて変更する必要があります。

    Build NowボタンをクリックしてKubernetesのデプロイメント・ビルドを開始します。Build Logアイコンをクリックしてビルド実行ログを閲覧できます。


    ビルドジョブ実行の成功後、ビルドログを確認してKubernetesクラスタにデプロイされたサービスのIPアドレスとポート番号を取得できます。IPアドレスとポート番号はYAMLファイルで構成したデプロイメント名よりも下で探す必要があります。


    取得したIPアドレスとポート番号を以下の形式で使い、ブラウザで出力を確認してください。
    http://<IP Address>:port/message
    Note: メッセージ出力は、コンテナ化されたNode.js RESTアプリケーションで作成したものに基づくため、ここで示したものと異なる結果を出力する場合があります。



    Oracle Developer CloudがOKEでDockerコンテナの自動ビルドや自動デプロイの管理プロセスの合理化、簡素化する方法をご紹介しました。

    Happy Coding!

    **このエントリで記載している内容は原著者の意見であり、必ずしもOracleの意見を反映するものではありません。

    [Java, Security] Oracle's Plan for Distrusting Symantec TLS Certificates in the JDK

    原文はこちら。
    https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates

    Oracle JDKは、Google、Mozilla、Apple、Microsoftが最近発表したものと同様の計画に沿って、Symantecが発行したTLS証明書の信頼を停止します。影響を受ける証明書のリストには、Symantecが管理するGeoTrust、Thawte、およびVeriSignというブランド名の証明書が含まれます。
    Chrome’s Plan to Distrust Symantec Certificates
    https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html
    CA:Symantec Issues
    https://wiki.mozilla.org/CA:Symantec_Issues
    Information for website operators about distrusting Symantec certificate authorities
    https://support.apple.com/en-us/HT208860
    Microsoft partners with DigiCert to begin deprecating Symantec TLS certificates
    https://cloudblogs.microsoft.com/microsoftsecure/2018/10/04/microsoft-partners-with-digicert-to-begin-deprecating-symantec-tls-certificates/
    2019年4月16日リリース予定のCritical Patch Release以後、全てのサポート対象のJDKバージョン(12、11、8、7)では、影響を受けるトラストアンカー(ルート)を通じて発行された新しいTLSサーバー証明書を信頼しなくなります。
    Critical Patch Updates, Security Alerts and Bulletins
    https://www.oracle.com/technetwork/topics/security/alerts-086861.html
    2019年4月16日より前に発行されたTLSサーバー証明書は有効期限まで引き続き信頼しますが、この日以後に発行された証明書は拒否します。Symantecの証明書をDigiCertの証明書に置き換える情報は、以下のURLをご覧ください(DigiCertは2017年12月1日にSymantec Website Security SSL/TLS証明書の検証および発行を引き継ぎました)。
    Replace Your Symantec SSL/TLS Certificates
    https://www.digicert.com/replace-your-symantec-ssl-tls-certificates/
    この新たな制限は、Java Secure Socket Extension(JSSE)APIのJDK実装(SunJSSE Provider)で実施されます。サーバーの証明書チェーンが下表の認証局(Certificate Authorities、CA)のいずれかに固定されている場合、TLSセッションをネゴシエートしません。

    アプリケーションはトラストアンカーが信頼されていないというメッセージを含む例外を受け取ります。
        Untrusted trust anchor: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
    影響を受けるリリースのリリースノートにて、Oracleは影響を受けるルートアンカーへの信頼を一時的に有効化するための手順を紹介する予定にしています。

    JDKに含まれる以下のSymantecルート証明書に対して制約が課されます。

    2019年4月16日以後に信頼されなくなるルート証明書
    Distinguished NameSHA-256 Fingerprint
    CN=GeoTrust Global CA, O=GeoTrust Inc., C=USFF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A
    CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US37:D5:10:06:C5:12:EA:AB:62:64:21:F1:EC:8C:92:01:3F:C5:F8:2A:E9:8E:E5:33:EB:46:19:B8:DE:B4:D0:6C
    CN=GeoTrust Primary Certification Authority - G2, OU=(c) 2007 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US5E:DB:7A:C4:3B:82:A0:6A:87:61:E8:D7:BE:49:79:EB:F2:61:1F:7D:D7:9B:F9:1C:1C:6B:56:6A:21:9E:D7:66
    CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=USB4:78:B8:12:25:0D:F8:78:63:5C:2A:A7:EC:7D:15:5E:AA:62:5E:E8:29:16:E2:CD:29:43:61:88:6C:D1:FB:D4
    CN=GeoTrust Universal CA, O=GeoTrust Inc., C=USA0:45:9B:9F:63:B2:25:59:F5:FA:5D:4C:6D:B3:F9:F7:2F:F1:93:42:03:35:78:F0:73:BF:1D:1B:46:CB:B9:12
    CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US8D:72:2F:81:A9:C1:13:C0:79:1D:F1:36:A2:96:6D:B2:6C:95:0A:97:1D:B4:6B:41:99:F4:EA:54:B7:8B:FB:9F
    CN=thawte Primary Root CA - G2, OU="(c) 2007 thawte, Inc. - For authorized use only", O="thawte, Inc.", C=USA4:31:0D:50:AF:18:A6:44:71:90:37:2A:86:AF:AF:8B:95:1F:FB:43:1D:83:7F:1E:56:88:B4:59:71:ED:15:57
    CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US4B:03:F4:58:07:AD:70:F2:1B:FC:2C:AE:71:C9:FD:E4:60:4C:06:4C:F5:FF:B6:86:BA:E5:DB:AA:D7:FD:D3:4C
    EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA3F:9F:27:D5:83:20:4B:9E:09:C8:A3:D2:06:6C:4B:57:D3:A2:47:9C:36:93:65:08:80:50:56:98:10:5D:BC:E9
    OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US3A:43:E2:20:FE:7F:3E:A9:65:3D:1E:21:74:2E:AC:2B:75:C2:0F:D8:98:03:05:BC:50:2C:AF:8C:2D:9B:41:A1
    OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=USA4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09:CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05
    OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US83:CE:3C:12:29:68:8A:59:3D:48:5F:81:97:3C:0F:91:95:43:1E:DA:37:CC:5E:36:43:0E:79:C7:A8:88:63:8B
    CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=USEB:04:CF:5E:B1:F3:9A:FA:76:2F:2B:B1:20:F2:96:CB:A5:20:C1:B9:7D:B1:58:95:65:B8:1C:B9:A1:7B:72:44
    CN=VeriSign Class 3 Public Primary Certification Authority - G4, OU="(c) 2007 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US69:DD:D7:EA:90:BB:57:C9:3E:13:5D:C8:5E:A6:FC:D5:48:0B:60:32:39:BD:C4:54:FC:75:8B:2A:26:CF:7F:79
    CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US9A:CF:AB:7E:43:C8:D8:80:D0:6B:26:2A:94:DE:EE:E4:B4:65:99:89:C3:D0:CA:F1:9B:AF:64:05:E4:1A:B7:DF
    CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US23:99:56:11:27:A5:71:25:DE:8C:EF:EA:61:0D:DF:2F:A0:78:B5:C8:06:7F:4E:82:82:90:BF:B8:60:E8:4B:3C

    上表に記載のいずれかのCAが発行したTLSサーバー証明書をお持ちの場合、DigiCertから無料での証明書置き換えに関する情報を伴うメッセージを受けているはずです。

    以下のように、JDKのkeytoolユーティリティを使い、証明書チェーンの詳細を表示することもできます。
    keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>
    チェーンの証明書のいずれかが上表に記載のルートCAのどれかが発行したものである場合、証明書を更新してください。自分が管理しているわけではない場合は、サーバーを管理する組織に連絡してください。

    [Cloud] Introducing Cloud Native Ecosystem Solutions

    原文はこちら。
    https://blogs.oracle.com/cloudnative/introducing-cloud-native-ecosystem-solutions

    Cloud Native Labs(より広範なOracle Cloud Infrastructure)では、オープンスタンダードを遵守し、お客様がIT環境で活用するソリューションやプロジェクトを自由に選択できることを約束します。
    Oracle Cloud Infrastructure
    https://cloud.oracle.com/ja_JP/cloud-infrastructure
    このテーマを継続する中、我々のエコシステムに焦点を当てたソリューションガイドを発表できることをうれしく思っています。
    エコシステム・パートナーに学習コンテンツを作成してもらうその目的は、顧客の選択肢を広げることです。多くの企業は、オープンソースソフトウェアを最も純粋な形で活用したいと考えていますが、パートナーが提供できるエンタープライズレベルの機能、管理、運用、サポートが必要な場合があります。最初のパートナーを紹介する前に、注力しようとしている最初にOSSプロジェクトについてお話しましょう。

    Spinnaker

    Spinnakerが初耳の方は、Spinnaker.ioのドキュメントをご覧になることをお勧めします。
    Spinnaker: Continuous Delivery for Enterprise
    https://www.spinnaker.io/
    Spinnakerとは、ソフトウェアの変更を高速かつ自信を持ってリリースするための、オープンソースかつマルチクラウドの継続的デリバリプラットフォームです。
    Netflixが作成し、NetflixからスピンアウトしたSpinnakerは強力かつ拡張性があり、クラウドプロバイダを問わずに利用できます。Cloud Native Labsでは、下位のほとんど全てのビルドシステム(Jenkins、Werckerなど)を活用でき、Webスケール、マルチクラウド・オペレーションを可能にする生来の傾向の両面で、Spinnakerに対して親和性があります。Spinnakerはクラウドネイティブのデプロイメント戦略を第1級市民として取り扱っており、Immutableイメージ、カナリア・デプロイメント、パイプライン、自動リリース、自動ロールバックなどのベストプラクティスを実現します。
    Pipelines
    https://www.spinnaker.io/concepts/pipelines/
    その上、Spinnakerにはコンテナワークロードを実行するオーケストレーション・プラットフォームのデファクトであるKubernetesサポートが組み込まれています。
    Spinnakerは、急速にオープンソース、マルチクラウドのコンテナワークロードの継続的デリバリならびに開発者の(開発)スピードを増加するための業界標準プラットフォームになりつつあります。
    by Micha (Mies) Hernandez Van Leuffen, VP Solution development, Ex-CEO of Wercker
    本番環境のワークロードを継続的にOracle Cloud Infrastructureの強力なベアメタルComputeインスタンスにデプロイするのは非常に簡単です。
    Cloud Compute Services - Oracle Cloud Infrastructure
    https://cloud.oracle.com/compute

    Armory

    Spinnakerのエコシステムを中心に、Armoryとのエキサイティングな新しいクラウドネイティブソリューションの統合を紹介したいと考えています。 ArmoryがOracle Cloud Infrastructureへのデプロイと検証がなされたことを発表できうれしく思っています。
    Armory is Spinnaker at Enterprise Scale
    https://www.armory.io/
    Armory Spinnaker on Oracle Container Engine for Kubernetes
    https://cloudnative.oracle.com/template.html#application-development/ci-cd/spinnaker/spinnaker.md
    ArmoryはSpinnakerの商用バージョンを提供しており、エンタープライズ向けにソフトウェアデリバリを自動化します。Armoryのディストリビューションには、ハイブリッド環境におけるスケーラビリティとセキュリティを実現する重要な機能が含まれています。具体的には以下のようなものです。
    • Armory Installer – 本番環境で利用可能なSpinnakerクラスタをすぐに立ち上げ可能
    • Armory Pipelines as Code – Gitリポジトリにパイプラインテンプレート定義を作成、その定義を再利用可能
    • Terraform Stage – Terraformスクリプトをパイプライン中で実行可能
    • Enterprise Release Management – OSSで見つかったバグはリリース前に修正
    • Edge Releases – Spinnakerで内部開発を促進するためのOSSからの最新リリースを完全にテスト済み
    • Professional Services – Spinnakerのトレーニング、実装、コンサルテーション、カスタム開発
    • Enterprise Support – メール、Slack、サポートポータルを使った24/7サポート

    What’s next?

    OCIにSpinnakerをインストールしようとしていますか?ソリューションガイドをチェックして、無料トライアルアカウントで試してみてください。
    Armory Spinnaker on Oracle Container Engine for Kubernetes
    https://cloudnative.oracle.com/template.html#application-development/ci-cd/spinnaker/spinnaker.md
    Try it!
    https://cloud.oracle.com/trial
    質問があれば、原文のコメント欄に記載するか、もしくは2018年12月10日から13日までのKubeConでお尋ねください。
    KubeCon + CloudNativeCon North America 2018 - Linux Foundation Events
    https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
    我々がチェックすべきと思われる会社やテクノロジーについてアイデアがあれば、logan.smith at oracle.comまでお寄せください。

    [Cloud] Using Availability Domains and Fault Domains to Improve Application Resiliency

    原文はこちら。
    https://blogs.oracle.com/cloud-infrastructure/using-availibility-domains-and-fault-domains-to-improve-application-resiliency


    テクノロジーの不幸な真実として、ハードウェアにはメンテナンスが必要であり、ハードウェアの障害は発生しうる、というものがあります。クラウドリソースは、従来のオンプレミスリソースと同じハードウェア関連の保守の影響を受けます。2018年8月、Oracle Cloud Infrastructureは、仮想マシンおよびベア・メタルのComputeインスタンスにフォルト・ドメイン(fault domain)を導入しました。 Oracle Cloud Infrastructureのフォルト・ドメインは、アプリケーションがアベイラビリティ(可用性)・ドメイン内でのハードウェア障害やハードウェア計画保守を回避できるようにします。

    Oracle Cloud Infrastructureのアベイラビリティ・ドメインとは以下のようなものです。
    あるリージョン内にある1個以上のデータセンター。アベイラビリティ・ドメインは互いに分離されており、フォールト・トレラントであり、同時に障害が発生する可能性はほとんどありません。アベイラビリティ・ドメインは、電源や冷却などのインフラストラクチャやアベイラビリティ・ドメインの内部ネットワークを共有しないため、あるアベイラビリティ・ドメインでの障害が他のアベイラビリティ・ドメインの可用性に影響を及ぼす可能性はほとんどありません。リージョン内のすべてのアベイラビリティ・ドメインは、低遅延、高帯域幅のネットワークによって相互接続されています。
    Oracle Cloud Infrastructure Documentation
    Regions and Availability Domains
    https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm
    Oracle Cloud Infrastructureのフォルト・ドメインとは以下のようなものです。
    アベイラビリティ・ドメイン内のハードウェアとインフラストラクチャをグループ化したもの。各アベイラビリティ・ドメインには3個のフォルト・ドメインが含まれています。フォルト・ドメインを使うと、1個のアベイラビリティ・ドメイン内の同一物理ハードウェア上に存在しないよう、インスタンスを分散配置できます。あるフォルトドメインに影響があるハードウェア障害やコンピューティングハードウェア保守は、他のフォルト・ドメインのインスタンスに影響しません。
    Fault Domains
    https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm#fault
    Oracle Cloud Infrastructureのフォルト・ドメインの背後にある理論とコンピュートインスタンスの配置方法に関するすばらしい概要をSanjay Pillaiが投稿しています。
    Introducing Fault Domains for Virtual Machine and Bare Metal Instances
    https://blogs.oracle.com/cloud-infrastructure/introducing-fault-domains-for-virtual-machine-and-bare-metal-instances
    https://orablogs-jp.blogspot.com/2018/08/introducing-fault-domains-for-virtual.html
    アプリケーションをOCIにデプロイしている場合、アプリケーションのユニークなアーキテクチャやアフィニティ、アンチ・アフィニティの要件によって、インスタンスがフォルト・ドメイン間にわたってどのように分散するかが決まります。OCIドキュメントの「Best Practices for Your Compute Instance」で複数のアプリケーションシナリオを使ってフォルト・ドメインを説明しています。
    Best Practices for Your Compute Instances
    https://docs.cloud.oracle.com/iaas/Content/Compute/References/bestpracticescompute.htm
    高可用性を確保するために、クラウドサービスを複数のアベイラビリティ・ドメインにデプロイすることをお勧めします。 アプリケーションアーキテクチャでコンポーネントが同じアベイラビリティ・ドメインに存在する必要がある場合は、アプリケーションコンポーネントのために適切なフォルト・ドメインを選択することで、リソース障害の保護が可能です。以下のセクションでは、JD Edwards EnterpriseOne(JDE)およびOracle E-Business Suite(EBS)の公開アーキテクチャとアベイラビリティ・ドメインおよびフォルト・ドメインによるアプリケーションのサポートを分析します。このブログエントリの終わりに、EBS、JDE、およびSiebel CRMのOracleソリューションドキュメントのリンクがあります。

    Multiple Availability Domains

    アプリケーションスタックに複数のアベイラビリティ・ドメインを使用する場合、単一のフォルト・ドメインに複数のインスタンスを配置すると、各々のインスタンスに対して適切なアフィニティが与えられます。以下のJD Edwards EnterpriseOneの例では、地理的に離れたアベイラビリティ・ドメインによって、アプリケーションの一次冗長性が提供されています。フォルト・ドメインは前述のOracle E-Business Suiteの例とは異なる方法で割り当てられています。

    JD Edwards EnterpriseOneへの着信接続は、Oracle Cloud Infrastructureの外部にあるDNS経由で、両方のアベイラビリティ・ドメインのロード・バランサにルーティングされます。ロードバランサは、設定された配信ポリシーに基づいてトラフィックをアプリケーションインスタンスにルーティングします。以下の例では、別々のアベイラビリティ・ドメインにより、アプリケーションの一次冗長性がもたらされています。プレゼンテーション層および中間層のすべてのホストはFAULT-DOMAIN-1に属します。フォルト・ドメインはアベイラビリティ・ドメインに固有のものなので、アベイラビリティ・ドメイン1のFAULT-DOMAIN-1は、同じ名前ではありますが、アベイラビリティ・ドメイン2のFAULT-DOMAIN-1とは異なるハードウェアセットです。各アベイラビリティ・ドメイン内のホストはすべて同じフォルト・ドメインに属しているため、地理リージョンでのハードウェア障害または計画メンテナンスは、各アベイラビリティ・ドメインに最小限の影響しか与えません。アベイラビリティ・ドメイン2のホストに影響を与えるハードウェアイベントは、アベイラビリティ・ドメイン1のホストには影響しません。すべてのホストを同じフォルト・ドメインに配置すると、同様に必要とされるインフラストラクチャのメンテナンスアクティビティによる、アプリケーションスタックへの影響を最小限にすることができます。

    Diagram from "Learn about Deploying JD Edwards EnterpriseOne on Oracle Cloud Infrastructure"

    Learn about deploying JD Edwards EnterpriseOne on Oracle Cloud Infrastructure
    https://docs.oracle.com/en/solutions/learn-architecture-deploy-jd-edwards/index.html

    One Availability Domain

    1個のアベイラビリティ・ドメインにアプリケーションスタックをデプロイする場合、複数のフォルト・ドメイン間にインスタンスを配置することで、各インスタンスに対して適切なアンチ・アフィニティをもたらします。以下のOracle E-Business Suiteの例では、フォルト・ドメインを使うことでエンドユーザーはハードウェア障害もしくはインフラストラクチャの計画メンテナンス時にもアクセスが可能です。

    Oracle E-Business Suiteへの着信接続はロードバランサを経由してサーバープールのサーバにルーティングされます。アプリケーション層では、Host 1がFAULT-DOMAIN-1に、Host 2がFAULT-DOMAIN-2にあります。ハードウェア障害がHost 1に影響を及ぼした場合、Oracle E-Business SuiteはHost 2を使ってアクセスできます。Host 1とHost 2が同一フォルト・ドメインに存在する場合、Oracle E-Business Suiteはエンドユーザーからアクセスできなくなるでしょう。Oracle Cloud Infrastructureのハードウェア・メンテナンスの場合、フォルト・ドメインのメンテナンス・ウィンドウはオーバーラップしません。

    Diagram from "Learn About Deploying Oracle E-Business Suite on Oracle Cloud Infrastructure"

    Learn about deploying Oracle E-Business Suite on Oracle Cloud Infrastructure
    https://docs.oracle.com/en/solutions/deploy-ebusiness-suite-oci/index.html#GUID-8BF5EDC7-2686-48D2-A11C-0595A933AE13
    アプリケーションにてフォルト・ドメインを使う上で詳細を知りたい場合には、以下のソリューション・ドキュメントにその他のシナリオや詳細があります。Oracle Cloud Infrastructureのコンピュートインスタンスのために適切にフォルト・ドメインを注意深く選択することで、ハードウェア障害や計画されたメンテナンスアクティビティによってエンドユーザーが予期せぬ影響を受けることがなくなります。別の視点が必要であれば、同僚のLuke Feldmanが書いた、フォルト・ドメインがOracle Cloud Infrastructureにおいて非常に重要な理由を説明している記事をWebで検索してください。

    最後に、まだOracle Cloud Infrastructureの無料トライアルにサインアップされていない場合は、今すぐサインアップできます。 未来を築くことができるようにクラウドを提供いたします。
    無料で試して見る/Try for Free
    https://cloud.oracle.com/tryit

    Solutions Design Resources

    [Network, Linux, Security] Encrypting NFS data on the Wire

    原文はこちら。
    https://blogs.oracle.com/linux/encrypting-nfs-data-on-the-wire

    Oracle Linuxの開発者であるChuck Leverは、NFS(実際にはすべてのRPCベースのプロトコル)に対する透過的なエンドツーエンドの暗号化を実現するためのインターネットドラフト標準(draft-cel-nfsv4-rpc-tls-01)の協同作業に参画しています。
    Remote Procedure Call Encryption By Default (draft-cel-nfsv4-rpc-tls-01)
    https://tools.ietf.org/html/draft-cel-nfsv4-rpc-tls-01
    より多くのLinuxワークロードが共有ネットワークインフラストラクチャを横断するにつれて、ネットワークトラフィックの暗号化に対するリクエストが増加してきました。ポイントツーポイントのトラフィック暗号化を行う方法は数多くありますが、Linux NFSコミュニティのリード・メンバーは、NFSトラフィックのover-the-wire(ネットワーク越し)暗号化を実現するための、(これまでとは)異なる、より単純な戦略を提案しています。

    Linux NFSのメンテナであるTrond MyklebustとOracle Linuxの開発者であるChuck Leverは、NFSなどのRPCベースのプロトコルのための、透過的で構成が簡単なエンドツーエンドの暗号化標準であるNFS-over-TLSを提案しています。このソリューションでは、自己署名証明書を使用して、NFSのネットワーク・トラフィックの標準暗号化を設定します。この方法ではKerberosやActive Directoryの重いオーバーヘッドはかかりません。

    IPsecやKerberosのように、ネットワーク上でNFSトラフィックを暗号化する方法はたくさんありますが、現時点では、大きな欠点があるためにほとんどのユーザーがそれらを使用していません。RPC-over-TLSを有効にするこの提案は、HTTPSと同様に、自己署名証明書を選択して、暗号化を「簡単な」オプションにします。

    この標準は最もシンプルで使い勝手の良いソリューションとして押し出されているものではありますが、代替暗号化ソリューションが適切なソリューションになり得ない場合にも、ユニークなメリットを提供します。具体的には、接続毎の暗号化(例えばIPSec)に対するフロー毎の暗号化であったり、(クラウド環境ではよくあることですが)顧客のユーザー認証ドメインがホストのID管理とは別の場合であったりする場合にメリットを提供します。

    クライアントとサーバーがすでに信頼関係がある場合ようなデプロイメントのケースは多々あります。そのような場合、必要なのは信頼されていないネットワーク上を流れるNFSトラフィックの保護だけです。ほとんどのNFSはすでにこのように動作しており、テナントはDNSサービスが提供するIPアドレスを信頼しますが、トラフィックを見張らない他のテナントは信頼しません。

    このソリューションは、Webトラフィックの暗号化のためのhttpsソリューションからヒントを得ています。具体的には、認可/認証とは別に暗号化に焦点を当てます。このソリューションはユーザー認証ソリューションほどの機能はありませんが、これは管理者が必要とする最小限の構成で使用できるソリューションです。この標準は以下の前提でロールアウトされるでしょう。

    • use-if-availableモデル(使用可能な場合には使用)にデフォルトで設定されている
    • つまり、接続の両端でこの標準をサポートし、証明書の信頼性が十分にある場合には、NFSトラフィックは暗号化される

    この機能がNFSクライアントやNFSサーバーにロールアウトされる際には、全てのNFSトラフィックが透過的に暗号化されることになるでしょう。

    これはまだ標準のドラフトですので、すぐにOracle Linuxサーバーで利用できるようになるわけではありません。しかし、業界メディアではすでに話題になっています。
    Oi! Not encrypting RPC traffic? IETF bods would like to change that
    RPC over TLS: You know it makes sense
    https://www.theregister.co.uk/2018/11/14/internet_draft_rpc_over_tls/

    [misc.] Twitterアカウントの変更

    唐突ではありますが、Twitterアカウントを変更しました。
    (旧)OraBlogs_jp
    (新)Logico_jp
    変更理由は、主に以下の3つです。

    • Oracle Blogsだけを翻訳したり紹介したりしているわけではなくなった
    • 英語読みでは結構言いづらい
    • 日本のロジ子、とわかりやすくしておけばいいんじゃないか

    今後ともごひいきに。

    [Integration] How to migrate from ICS to OIC?

    原文はこちら。
    https://blogs.oracle.com/integration/how-to-migrate-from-ics-to-oic

    このエントリでは、ICS (Integration Cloud Service)インスタンスからOIC(Oracle Integration Cloud)インスタンスへのメタデータの移行についてご紹介します。移行対象のメタデータには以下のものが含まれます。
    • 統合(Integration)、接続(Connection)、ルックアップ(Lookup)、ライブラリ(Library)、パッケージ(Package)、エージェントグループ(Agent Group)、カスタムアダプタ(Custom Adapter)など
      • 任意の状態(開発中、アクティブ化済み、など)の統合が移行対象です
      • 統合が参照しないルックアップ、接続といったリソースも移行対象です
    • (接続で構成される)エンドポイント設定
    • 証明書
    • CSFストアに格納されている資格証明(Credential)
    • データベースや通知(Notification)のような設定
    移行ツールは以下のタスクの一部を自動化しますが、手作業でのエクスポート、インポートを使うバイア、手作業での移行が必要です。
    • 接続、ルックアップなどといった依存関係と共に全ての統合を移行パッケージにバルクエクスポート
    • エンドポイント構成や資格証明の移行
    • "Integration calling Integration"における移行元ICSインスタンスから移行先OICインスタンスへのホスト、ポートの自動置換
    • 自動「テスト接続(Test Connection)」
    • アクティブ化済み統合の自動アクティブ化

    Enabling Migration in OIC

    移行の一環でOICにコンテンツをインポートするために、OICで機能フラグを有効化する必要があります。機能フラグを有効化するには、Oracle Supportに対しSRを発行する必要があります。
    (訳注)
    この機能は18.4.1で全てのユーザーが利用できるようになっています。そのため、SRの発行は不要です。
    また、ここで説明している内容は、ドキュメントにも記載があります。
    Oracle® Cloud
    Administering Oracle Integration Cloud
    Export Oracle Integration Cloud Service Data Objects into Oracle Integration Cloud
    https://docs.oracle.com/en/cloud/paas/integration-cloud/integration-cloud-auton/export-oracle-integration-cloud-service-data-objects-oracle-autonomous-integration-cloud.html

    Migration Lifecycle




    移行手順の概要は以下の通りです。
    1. (移行先がOIC Autonomousの場合)Oracle Cloud Infrastructure環境にオブジェクトストレージバケットを作成する。これはICSとOIC間で移行パッケージを転送するために必要である。
      • ストレージバケットの作成方法の詳細はこちらをクリックしてください。
    2. 1の手順が完了したら、ストレージURLとストレージの資格証明を使い、ICS環境のエクスポートREST APIを呼び出す。この操作でICSからデータをストレージサービスにコピーする。
    3. 必要であれば、エクスポート操作の状態を取得するREST APIを呼び出す。
    4. エクスポートされたオブジェクト、移行時のエラーや警告の情報は、移行レポートから取得できる。
    5. ストレージURLとストレージの資格証明を渡して、OIC環境でインポート操作を実行する。この操作により、ストレージからコンテンツをOICにインポートする。
    6. 必要であれば、エクスポートの状態を取得するREST APIを呼び出す。
    7. インポートされたオブジェクトや移行時のエラー、警告に関する情報は、移行レポートから取得できる。

    Exporting the data from ICS

    ICS環境から以下の手順を使ってデータをエクスポートします(OICからのエクスポートについては、Exporting the data from OICを参照してください)。

    管理者権限でアクセスして、エクスポートREST APIを実行します。以下はPostman RESTクライアントを使った例です。

    Export Request:

    ストレージサービス内で完了した構成に従い、以下の形式に基づいてストレージのURLを作成します。ストレージの資格証明も渡してください。
    https://swiftobjectstorage.region.oraclecloud.com/v1/tenancy/bucket
    ストレージバケット作成に関する詳細はこちらを確認してください。


    Response:



    Checking status:



    Checking the migration archive:



    Importing the data into OIC

    OIC環境にデータをインポートする手順は以下の通りです。

    移行ユーティリティはインポートに当たって複数の方法をサポートします。
    NoimportActivateMode valueDescription
    1ImportOnlyこのモードでは、オブジェクトをインポートするだけで、統合のアクティブ化はしない。アダプターのエージェントをインストールする必要がある場合など、手作業の操作が必要な場合に利用する。
    2ImportActivateこのモードでは、以前アクティブ化されている統合を全てインポートし、アクティブ化する。
    3ActivateOnlyこのモードは以前アクティブ化されている統合のアクティブ化のみ実行する。

    管理者権限でアクセスして、インポートREST APIを実行します。以下はPostman RESTクライアントを使った例です。

    ImportOnly Request:

    ストレージサービス内で完了した構成に従い、ストレージURLを以下のフォーマットに基づいて作成します。ストレージの資格証明も渡す必要があります。
    https://swiftobjectstorage.region.oraclecloud.com/v1/tenancy/bucket


    ImportActivate Request:



    ActivateOnly Request:



    Response:



    Checking the import status:

    インポートルクエストのペイロードとして帰ってくるjobidを、リソースに指定して渡します。以下の例では、jobidとして405を渡しています。


    Checking the migration report

    以下の手順で移行インポートプロセスの結果を確認できます。

    Migration report location:



    Sample report:



    Exporting the data from OIC

    OIC環境からデータをエクスポートする手順は以下の通りです。
    管理者権限でアクセスして、エクスポートREST APIを実行します。以下はPostman RESTクライアントを使った例です。

    Export Request:



    Export Response:



    Checking status: