[Java] Java Mission Control - Now serving OpenJDK binaries too!

原文はこちら。
https://blogs.oracle.com/java-platform-group/java-mission-control-now-serving-openjdk-binaries-too

OracleはオープンソースのJDK Mission Control (JMC) テクノロジーをOpenJDK、Oracle JDKユーザーの両者に提供するために、個別のダウンロードイメージとして利用可能にすることを計画しています。
CFV: New Project: Mission Control
http://mail.openjdk.java.net/pipermail/announce/2018-April/000249.html
以下に主たる理由を纏めました。

To make it available to all Java users

Java Flight Recorder (JFR) は現在オープンソースです。
JEP 328: Flight Recorder
http://openjdk.java.net/jeps/328
JFRはOpenJDK、Oracle JDKバイナリにJava SE 11から同梱される予定です。Oracle JDKならびにOpenJDK用に単一かつ個別のJMCダウンロードイメージを用意するとシンプルになるからです。

To allow for independent updates of JMC

JMCを個別のダウンロードイメージとすることで、Java SEリリースに依存せずアップデートできるからです。これにより、新たな監視機能や診断機能が複数のJava SEバージョンにわたって同時に提供できます。Java SEのリリースサイクルの途中で機能をJMCに追加することもできます。

It is now possible to efficiently bundle a stand-alone JMC

JDK 9で導入されたモジュール機能を活用し、OracleはJMC用に最適化し整えたランタイムを作成できます。これにより、JMCに不要なものを除去しながら、JavaFXコンポーネントのような当該JMCバージョンで必要となるあらゆるものを含めることができ、その結果アプリケーションランタイムのサイズを大幅に小さくできます。

Because JMC works with many JDK and OpenJDK versions

新しいJMCのバージョンは(JDK 7u40以後の)旧バージョンのJDKと対話できます。単一バージョンのJMCを使って最新リリースならびに旧リリースのJDKと対話することはよくあることですが、JMCを個別ダウンロードにすれば、複数バージョン対応がより明確になります。

To avoid duplication and confusion

一人の開発者が同一システムで複数のJDKインスタンスを必要とすることはよくあるシナリオです。これらのJDKのそれぞれにJMCのコピー重複して含まれていると、1つのバージョンでそれらをすべて処理できるならばディスク領域が無駄になりますし、異なるバージョンのJDKには異なるバージョンのJMCが含まれている可能性があるため、すべて(時には微妙な)機能の違いで混乱を招く可能性があります。

Oracleは、Maven CentralにJMCのコア部分(JFR記録の解析、処理、自動分析に使用)を公開する予定です。JDKバージョンのJFR記録を解析するプロジェクトではMavenの依存関係を、(7u40以後)の任意のJDKバージョンのJFR記録を解析したいプロジェクトで利用できます。

[Cloud, Network] Configuring a Custom DNS Resolver and the Native DNS Resolver in the Same VCN

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/configuring-a-custom-dns-resolver-and-the-native-dns-resolver-in-the-same-vcn

Oracle Cloud Infrastructure Blogの主な目的の1つは、クラウド・ソリューション・アーキテクトや製品管理者がベスト・プラクティスの提供や、新たな機能拡張の紹介、最も重要なワークロードをOracle Cloudに移行および実行するためのヒントの提供のためのフォーラムにすることです。筆者自身ソリューションアーキテクトであり、設計フェーズから実装フェーズまでお客様と関わる仕事をしています。そして、私は非常に多くのお客様のデプロイメントに関わってきたため、複数のアカウントにまたがる問題とニーズを把握できます。このお客様とベンダーのフィードバック・ループ中の喜びは、問題を解決し、ニーズに対応し、提供サービスを改善するための反復可能な方法を見つけることにあります。

このエントリでは、複数のお客様で見られた共通の問題の解決を目指します。この問題は、Oracle Cloud Infrastructureのvirtual cloud network (VCN)設定における、カスタムDNSリゾルバの構成が原因で発生しました。このエントリでその問題点と解決方法について説明します。

これらのサポートリクエストの迅速な解決のために、クラウドサポートチームとオペレーションチームの次のチームメンバーからの支援に感謝いたします。
  • Ankita Singh, Associate Solution Engineer
  • Saulo Cruz, Principal Member of Technical Staff

Issue

お客様がVCN内にサブネットを設定する場合、DHCPオプション設定時にInternet and VCN Resolver またはCustom Resolverを選択できます。

デフォルトはInternet and VCN Resolverです。 FastConnectまたはIPSec VPNでオンプレミスDNSサーバ(よくあるのがMicrosoft Active Directory)を使用する場合は、Custom Resolverを選択できます(詳細は以下のドキュメントを参照してください)。
Choices for DNS in Your VCN
https://docs.cloud.oracle.com/iaas/Content/Network/Concepts/dns.htm#Choices
 一般的に、ほとんどのエンタープライズのお客様は、共有サービスサブネット内のVCNにDNSリレーを配置します。通常、VCN内のサブネットはこの構成を反映します。この設定はアプリケーションにとって特に問題はありません。

ところが、Custom ResolverをDHCPオプションで選択、使用するサブネット上に事前ビルド済みのOracle Databaseイメージを使用してOracle Database Cloud Service(DBCS)インスタンスをプロビジョニングしようとすると、問題が発生します。よく発生するエラーメッセージは次のとおりです。
InvalidParameter - VCN RESOLVER FOR DNS AND DNS LABEL must be enabled for all subnets used to launch the specified shape
お客様がDHCPオプションのDBSをInternet and VCN Resolverに変更すると、このメッセージは出なくなりますが、この変更によって他のアプリケーションがうまく動作しなくなってしまいます。この問題はネイティブVCNリゾルバの再帰的性質が原因で発生します。

Workaround

お客様がDBCSの事前ビルド済みイメージを使っている場合における、この問題の回避策を発見しました。下図はアーキテクチャを示したものです。

この回避策を実装するためには、以下の手順を辿る必要があります。
  1. Terraformを使用してVCNと必要なサブネットを作成する。手順は以下のホワイトペーパーを参照。
  2. Oracle Cloud Infrastructure Virtual Cloud Network Overview and Deployment Guide
    https://cloud.oracle.com/iaas/whitepapers/vcn-deployment-guide.pdf
  3. データベースインスタンスの起動に必要なVCNを選択。
  4. (デフォルトの)Internet and VCN Resolver DHCPオプションを選択。
  5. データベースインスタンスを起動し、インスタンスに必要な構成を設定。
  6. データベース・インスタンスの起動後、DHCPオプションに移動し、Custom Resolverを選択した上で、お客様のDNSサーバのIPアドレスを設定。
  7. 共有リソースサブネット(上図ではshared subnet(共有サブネット)と記載)でDNSリレーサーバ(またはMicrosoft Active Directory)をインスタンス化する。DHCPオプションを(デフォルトの)Internet and VCN Resolverのままにしておく。
  8. 他のすべてのアプリケーション・サブネットでは、Custom Resolver DHCPを選択し、お客様のDNSサーバのIPアドレスを入力。
注意
Oracle Cloudからお客様のDNSサーバーへの接続が確立されていることを確認してください。また、VCNの作成時にDNS Labelに値を入力してください。未入力の場合デフォルト値を使用します。

この設定は、同じリージョン内または複数のリージョン内のVCN間でも機能します。以下のエントリをご覧ください。
Automate Oracle Cloud Infrastructure VCN Peering with Terraform
https://blogs.oracle.com/cloud-infrastructure/automate-oracle-cloud-infrastructure-vcn-peering-with-terraform
このエントリがVCNとサブネットの削除&再作成をしないですむ手助けになることを願っています。

Microsoft Active DirectoryやInfoblox、Bluecatとの統合に関する詳細情報をお求めでしたら、是非(原文のコメント欄に)コメントをお寄せください。

[Kubernetes, Cloud] Deploy Kubeflow with Oracle Cloud Infrastructure Container Engine for Kubernetes

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/deploy-kubeflow-with-oracle-cloud-infrastructure-container-engine-for-kubernetes

このエントリでは、Oracle Cloud Infrastructure Container Engine for KubernetesにKubeflowをデプロイする方法の詳細な手順を紹介します。

Container Engine for Kubernetesは、コンテナ化されたアプリケーションのクラウドへのデプロイに利用できる、フルマネージドでスケーラブル、可用性の高いサービスです。
Overview of Container Engine for Kubernetes
https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm?tocpath=Services%7CContainer%20Engine%7C_____0
このサービスを使用し、開発チームがクラウドネイティブアプリケーションを信頼性高く構築、展開、および管理できます。アプリケーションが必要とするコンピューティング・リソースを指定するだけで、Container Engine for KubernetesはOracle Cloud Infrastructure上に自動的にプロビジョニングします。

Kubeflowは、Kubernetesでの機械学習ワークフローのデプロイと管理を簡単かつ可搬性を持たせ、拡張性高くするオープンソースのプロジェクトです。
Kubeflow - The Machine Learning Toolkit for Kubernetes
https://www.kubeflow.org/
KubeflowはKubernetesへのTensorFlowのデプロイを自動化します。TensorFlowは最先端の機械学習フレームワークを提供し、Kubernetesはコンテナ化されたアプリケーションのデプロイと管理を自動化します。

Step 1: Create a Kubernetes Cluster

Container Engine for KubernetesでKubernetesクラスタを作成します。このクラスタは、Oracle Cloud Infrastructureコンソールを使用して手動で作成することも、TerraformおよびSDKを使用して自動的に作成することもできます。
Creating a Kubernetes Cluster
https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengcreatingclusterusingoke.htm?tocpath=Services%7CContainer%20Engine%7C_____3
Terraform provider for Oracle Cloud Infrastructure - container_engine sample
https://github.com/oracle/terraform-provider-oci/tree/master/docs/examples/container_engine
パフォーマンスを向上させるため、ベアメタルのシェイプを使用してノードプールにノードを作成することをお勧めします。データセットのサイズとモデルトレーニングに必要なコンピューティングキャパシティに応じて、ノードプール内の適切なシェイプとノード数を選択します。

以下のノードプールは、BM.DenseIO1.36 シェイプ(36 OCPU、512 GBのメモリ)で作成した例です。

Container Engine for Kubernetesは Kubernetesの "kubeconfig" 構成ファイルを作成します。kubectlならびにKubernetes Dashboardを使ってクラスタにアクセスするためにこのファイルを使います。

Step 2: Download the Kubernetes Configuration File

作成したばかりのクラスタのKubernetes構成ファイルをダウンロードします。
Downloading a kubeconfig File to Enable Cluster Access
https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengdownloadkubeconfigfile.htm?tocpath=Services%7CContainer%20Engine%7C_____4
この構成ファイルは、クラスタのためのkubeconfigファイルとしても知られています。

この時点で、kubectlまたはKubernetes Dashboardを使用してクラスタにアクセスできます。

[注意]
"kubectl proxy"コマンドを実行した後、次のURLを使用してKubernetesダッシュボードにアクセスする必要があります。
http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

Step 3: Deploy Kubeflow

Kubernetesクラスタ作成後、Kubeflowをデプロイできます。このエントリでは、Kubeflowをksonetを使ってデプロイします。
ksonnet
https://ksonnet.io/
ksonnetはKubernetes manifestの作成、共有、 デプロイのためのフレームワークで、Kubernetesのデプロイを簡素化するのに有用です。 ksonnetがローカルシステムにインストールされていることを確認してください。未インストールの場合は、先に進む前にksonnetをインストールしてください。

Kubeflowのドキュメントにあるように、以下のコマンドを使ってKubeflowをデプロイできます。
Getting Started - Quick Start
https://www.kubeflow.org/docs/started/getting-started/#quick-start
export KUBEFLOW_VERSION=0.2.2
curl https://raw.githubusercontent.com/kubeflow/kubeflow/v${KUBEFLOW_VERSION}/scripts/deploy.sh | bash
[注意]
このコマンドを使用すると、匿名ユーザーデータの収集が可能になり、Kubeflowの向上に役立ちます。 データを収集したくない場合は、明示的に無効にできます。手順については、Kubeflow Usage Reportingのガイドを参照してください。
Usage Reporting
https://www.kubeflow.org/docs/guides/usage-reporting/
Kubeflowのデプロイ中に、以下のエラーが発生する可能性があります。
"jupyter-role" is forbidden: attempt to grant extra privileges:
このエラーを回避するには、他のRBACロールを作成または編集するために必要なロールベースアクセス制御(RBAC)のロールを自分のユーザーに付与する必要があります。その後、以下のコマンドを実行します。
$kubectl create clusterrolebinding default-admin --clusterrole=cluster-admin --user=ocid.user.oc1..aaaaa....

Step 4: Access Notebook

これでJupiter Notebookにアクセスできる準備が整いました。ML/AIモデルをデータセットを使って構築できます。
Jupyter Notebooks
https://www.kubeflow.org/docs/guides/components/jupyter/
notebookにローカル接続するために、以下のコマンドを実行できます。
$kubectl get pods --selector="app=tf-hub" --output=template --template="{{with index .items 0}}{{.metadata.name}}{{end}}"
$kubectl port-forward tf-hub-0 8000:8000

Summary

OCI Container Engine for KubernetesとKubeflowを使って、プロジェクト用の柔軟かつスケーラブルな機械学習およびAIプラットフォームを簡単にセットアップできます。基盤となるインフラストラクチャの管理ではなく、モデルの構築とトレーニングに注力できます。

[Cloud, Security] PCI Compliance on Oracle Cloud Infrastructure is EASY!

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/pci-compliance-on-oracle-cloud-infrastructure-is-easy

Oracle Cloud InfrastructureサービスにはPCI DSS Attestation of Compliance(準拠証明)があります。対象範囲はBlock Volumes、Object Storage、Archive Storage、File Storage、Data Transfer Service、Database、Exadata、Container Engine for Kubernetes、Container Registry、FastConnect、そしてGovernanceです。このエントリでは、Oracle Cloud Infrastructureの顧客がOracle IaaS上で実行するワークロードに対してPCIコンプライアンスを達成するのに役立つガイドラインを説明します。

Background

PCIコンプライアンスを達成するためのガイドラインは、クラウドセキュリティの連続体の共有責任スペクトラムに基づいています。下図は、クラウドセキュリティとクラウドのセキュリティの責任の分離を示しています。

お客様は、Oracle Cloud Infrastructureでのワークロードの保護に対する責任があります。場合によっては、Oracleが提供するサービスを構成する必要があります。この責任は共有対象、つまりOracleはサービス基盤を維持し、お客様はそのサービスを使用し、セキュリティおよびコンプライアンスの要件に従って管理・制御を設定します。Information System Security Certification Consortium [ (ISC)2] による以下の図では、IaaS、PaaS、およびSaaSに関する責任分野を明確にしています。

当社は、お客様のセキュリティおよびコンプライアンスの要件を満たすソリューションを開発するために、Oracleの7 Pillars of Trusted Secure Enterprise Platformに従っています。
Oracle IaaS and PaaS Security and Compliance
https://cloud.oracle.com/en_US/iaas-paas-compliance
これについては、Security Solutions Architectureの次回のエントリで詳説しますが、今回はOracle Cloud Infrastructure上のPCIに焦点を当てます。

Recommended High-Level Solutions for PCI Compliance on Oracle Cloud Infrastructure

PCI Security Standards Council (R) の最新のRequirements and Security Assessment Procedures version 3.2.1 (May 2018)に従います。
Requirements and Security Assessment Procedures
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf?agreement=true&time=1533259034559
文書ごとに、6つのセクションにわたって12の詳細な要件があります。
  1. Build and Maintain a Secure Network and System
  2. Protect Cardholder Data
  3. Maintain a Vulnerability Management Program
  4. Implement Strong Access Control Measures
  5. Regularly Monitor and Test Networks
  6. Maintain an Information Security Policy
Oracleのような共有ホスティングプロバイダには追加の要件がありますが、我々はすでに準拠証明を通して要件を満たしています。

それでは詳細に入っていきましょう。

Section 1: Build and Maintain a Secure Network and System

Requirement 1
Install and maintain a firewall configuration to protect cardholder data.(カード会員データを保護するためのファイアウォールをインストール、構成して設定を維持する)

Solution:
Oracle Cloud Infrastructureのセキュリティ・リスト(Oracle Cloud Infrastructureの管理下のサブネット固有のファイアウォール・ルール)を使用する。
Security Lists
https://docs.cloud.oracle.com/iaas/Content/Network/Concepts/securitylists.htm?tocpath=Services|Networking|Access%20and%20Security|_____3
さらに、MarketplaceからFortinetまたはCheckpointのファイアウォール・イメージをダウンロードし、Oracle Cloud Infrastructureでファイアウォール・アプライアンスをプロビジョニングする。
Fortinet FortiGate-VM Next-Generation Firewall (NGFW) v5.6/v6.0 for OCI
https://cloudmarketplace.oracle.com/marketplace/en_US/listing/42416321
Check Point CloudGuard IaaS Security Gateway
https://cloudmarketplace.oracle.com/marketplace/en_US/listing/37604515
Requirement 2
Do not use vendor-supplied defaults for system passwords and other security parameters.(ベンダー提供のデフォルトをシステムパスワードやその他のセキュリティパラメータとして利用しない)

Solution
PCIドキュメントのガイダンスを確認する。Oracle Cloud Infrastructureでのユーザー資格証明の管理方法に関する詳細なドキュメントも用意している。
User Credentials
https://docs.cloud.oracle.com/iaas/Content/Identity/Concepts/usercredentials.htm

Section 2: Protect Cardholder Data

Requirement 3
Protect stored cardholder data.(格納しているカード会員データの保護)

Solution
これは保存データの保護を対象としている。デフォルトでは、Oracle Cloud InfrastructureのBlock StorageおよびObject Storageは暗号化されている。さらに、将来登場する予定のKMS、または任意のサポート対象のHSM、Oracle Wallet、Oracle Key Vault、およびサードパーティのVault製品では、キーと秘密の管理で無類の柔軟性を提供する。データセキュリティについては、Transparent Data Encryption (TDE、透過データ暗号化)と列レベルの暗号化を提供している。


Requirement 4
Encrypt transmission of cardholder data across open, public networks.(オープンかつパブリックなネットワーク間でカード会員データの送信を暗号化)

Solution
すべての制御および管理プレーンの通信は、PCI DSS準拠証明に必要なTLSで保護されている。また、(SSLではなく)TLSを使用し、必要に応じてロードバランサでアプリケーションの前さばきをすることを推奨する。
Overview of Load Balancing
https://docs.cloud.oracle.com/iaas/Content/Balance/Concepts/balanceoverview.htm?tocpath=Services%7CLoad%20Balancing%7C_____0
FastConnectと共にSSHとIPSec VPNの使用を強く推奨する。

Section 3: Maintain a Vulnerability Management Program

Requirement 5
Protect all systems against malware and regularly update antivirus software or programs.(マルウェアから全てのシステムを保護し、定期的にウイルス対策ソフトウェアやプログラムを更新)

Solution
Dyn Malware Protectionサービスを使用して、Oracle Cloud Infrastructure上で動作するWebアプリケーションに感染する前に、論理ネットワークのEdgeでマルウェアをブロックする。
Malware Protection to Block Malicious Malware
https://dyn.com/malware-protection/
また、ウイルス対策ソフトウェアがOSレベルでデプロイされていることを確認する。


Requirement 6
Develop and maintain secure systems and applications.(セキュアなシステムやアプリケーションの開発・維持)

Solution
我々はセキュアなシステムを開発し、維持するための多くの推奨事項を有している。パッチ管理ポリシーを策定し、この目的のためにマネージドクラウドサービスプロバイダを使用する。マネージドクラウドサービスプロバイダをお探しの場合、多くのOracle Cloud Infrastructure MSPパートナーとならんで、Oracle Managed Cloud Servicesもその選択肢の一つである。
Oracle Advanced Customer Services
https://www.oracle.com/support/advanced-customer-services/index.html

Section 4: Implement Strong Access Control Measures

Requirement 7
Restrict access to cardholder data by business need-to-know.(ビジネスニーズによるカード会員データへのアクセス制限)

Requirement 8
Identify and authenticate access to system components.(システムコンポーネントへのアクセスを識別、認証する)

Solution
IAMアクセス制御(コンパートメントとポリシー)に関するドキュメントを確認する。
Overview of IAM
https://docs.cloud.oracle.com/iaas/Content/Identity/Concepts/overview.htm?tocpath=Services%7CIAM%7C_____0
さらに、Oracle CASBおよびOracle IDCSを使用して、アクセス・ポリシーに関するさらなるセキュリティ制御を行うことを推奨する。
Oracle CASB: Cloud Access Security Broker
https://cloud.oracle.com/ja_JP/casb
Identity Cloud Service
https://www.oracle.com/cloud/paas/identity-cloud-service.html
Oracle Container Engine for Kubernetesの場合、IAMに加えてKubernetes Role Based Access Controlを使用する。
Container Engine for Kubernetes
https://cloud.oracle.com/containers/kubernetes-engine
About Access Control and Container Engine for Kubernetes
https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengaboutaccesscontrol.htm
Oracle Cloud InfrastructureでのKubernetesセキュリティに関して将来エントリを記載する予定です。

Requirement 9
Restrict physical access to cardholder data.(カード会員データへの物理的なアクセス制限)

Solution
これは、アベイラビリティ・ドメインやリージョン・レベルでのデータセンターの物理的なセキュリティ管理の対象です。物理的なセキュリティ要件に対応するよう、ISO 27001、SOC 1、SOC 2、およびSOC 3の認証を取得済みである。これらの認定は、PCI DSS準拠証明の基礎となるものである。

Section 5: Regularly Monitor and Test Networks

Requirement 10
Track and monitor all access to network resources and cardholder data(ネットワークリソースおよびカード会員データへのすべてのアクセスの追跡および監視)

Requirement 11
Regularly test security systems and processes.(セキュリティシステムとプロセスの定期的なテスト実施)

Solution
監視にはOracle CASBおよびOracle Cloud Infrastructure Audit Servicesを使用する。
Overview of Audit
https://docs.cloud.oracle.com/iaas/Content/Audit/Concepts/auditoverview.htm?tocpath=Services%7CAudit%7C_____0
CASBと監査ログを既存のSIEMソリューションと統合し、以下のリンクを参考に、Oracle Cloud Infrastructureベースの環境の定期的な侵入テストを計画・実行する。
Oracle® Cloud Managing and Monitoring Oracle Cloud
Oracle Cloud Security Testing Policy
https://docs.oracle.com/en/cloud/get-started/subscriptions-cloud/mmocs/oracle-cloud-security-testing-policy.html
Penetration and Vulnerability Testing
https://docs.oracle.com/en/cloud/get-started/subscriptions-cloud/mmocs/oracle-cloud-security-testing-policy.html#GUID-7238434F-6541-4FF7-9E79-E90A48631413
多くの遠隔測定および監視機能が登場しており、現在自動化されたOpenVASソリューションを開発中です。

Section 6: Maintain an Information Security Policy

Requirement 12
Maintain a policy that addresses information security for all personnel.(すべての人員の情報セキュリティに対処するポリシーの維持)

Solution
お客様はセキュリティポリシーに対する責任がありますが、Oracleは可能な限りお手伝いします。ほとんどのお客様はすでにセキュリティポリシーをお持ちなので、弊社チームはクラウド(IaaS、PaaS、SaaS)固有の視点でご支援できます。以下のURLはSANS Instituteの業界別のセキュリティポリシーテンプレートの一覧です。
Information Security Policy Templates
https://www.sans.org/security-resources/policies
結論として、これらの手順により、Oracle Cloud Infrastructure上の環境のPCIコンプライアンスが簡単に達成できることを願っています。Oracle Cloudへの移行を容易にするための、クラウドでのセキュリティ、コンプライアンスのためのブログ、ホワイトペーパー、Infrastructure Security as Code(ISaC)などを今後ご用意していきます。.

[Docker, Linux] Announcing Oracle Container Runtime for Docker Release 18.03

原文はこちら。
https://blogs.oracle.com/linux/announcing-oracle-container-runtime-for-docker-release-1803

Oracle Container Runtime for Docker version 18.03のリリースを発表できうれしく思っています。Oracle Container Runtimeを使うと、DockerをサポートするOracle Linuxやその他のOS間で、アプリケーションを作成し配布できます。Oracle Container Runtime for Dockerは、アプリケーションをパッケージ化して実行するDocker Engineで構成されており、Docker Hub、Docker StoreおよびOracle Container Registryと統合して、Software-as-a-Service(SaaS)クラウドでアプリケーションを共有します。
Oracle Container Registry
https://container-registry.oracle.com/

Notable Updates

  • Oracleはマルチ・レジストリ・サポートを実装しています。これにより、Pull操作時に問い合わせる追加のレジストリ・リストを含めるために、--add-registryフラグを指定してデーモンを実行できます。この機能は現在テクノロジー・プレビューとして利用でき、Oracle Container Runtime for DockerはデフォルトのレジストリとしてOracle Container Registryを使用してコンテナ・イメージを検索した後、ローカル・ミラーやDocker Hub、Docker Storeなどの代替レジストリにフォールバックできます。この機能で利用可能な別の機能に、特定のDockerレジストリへのアクセスを防ぐために使用できる--block-registryflagがあります。レジストリ・リストでは、すべてのイメージがソースレジストリに自動的にプレフィックスされるため、Dockerイメージのリストにはイメージが取得されたソースレジストリが常に表示されます。
  • Docker 18.03では、Docker Swarmの代わりにKubernetesオーケストレーションとの統合を強化する拡張機能が導入されており、この中には、さまざまなコンテナ化プロジェクトで使用される名前空間規則に準拠するための変更も含まれています。
  • Dockerfileはbuild-contextの外にも存在できるので、Dockerfilesを一緒に格納し、標準入力上のdocker buildコマンドでそのパスを参照できます。
  • ロギングとDockerのログへのアクセスに対する改良が追加されました。これには、指定されたタイムスタンプの前に発生したログを制限する--untilフラグが含まれます。
  • 実験的なDockerの信頼管理コマンドが追加され、Dockerイメージの信頼管理をより適切に処理できます。詳細は、docker trustコマンドのヘルプを参照してください。
    docker trust
    https://docs.docker.com/engine/reference/commandline/trust/

Upgrading

Oracle Container Runtime for Dockerの以前サポート対象だったバージョンからのアップグレード方法は、ドキュメントの以下の章をご覧ください。
Upgrading Oracle Container Runtime for Docker
https://docs.oracle.com/cd/E52668_01/E87205/html/docker_install_upgrade_upgrade.html 
開発者プレビューリリースからのアップグレードはOracleはサポートしないので、ご注意ください。

Support

Oracle Container Runtime for DockerのサポートはOracle Linux Premierサポートをご契約であればご利用いただけます。Oracle Linuxのサポートレベルについては、以下のドキュメントをご覧ください。
Oracle® Linux Licensing Information User Manual for Release 7
https://docs.oracle.com/cd/E52668_01/E63013/html/index.html

Resources – Oracle Linux

Documentation

Software Download

Blogs

Community Pages

Social Media

Data Sheets, White Papers, Videos, Training, Support & more

Product Training and Education

コミュニティベースのサポートについては、Oracle Technology Network CommunityのOracle Linuxスペースへどうぞ。
Oracle Linux
https://community.oracle.com/community/server_&_storage_systems/linux/oracle_linux
Oracle Technology Network Community
https://community.oracle.com/welcome

[Linux, Kubernetes] Announcing the developer preview of Oracle Container Services 1.1.10 for use with Kubernetes

原文はこちら。
https://blogs.oracle.com/linux/announcing-the-developer-preview-of-oracle-container-services-1110-for-use-with-kubernetes

Oracle Container Services 1.1.10 for use with Kubernetes®の開発者プレビューリリースを発表できることをOracleはうれしく思います。このリリースでは、アップストリームプロジェクトへの準拠というOracleのコミットメントを維持しており、搭載されたKubernetesはCloud Native Computing Foundation (CNCF) によって認定されたものです。
Conformance results for v1.10/ocsk
https://github.com/cncf/k8s-conformance/pull/309

Release Information

Oracle Container Services 1.1.10 for use with Kubernetesは、アップストリームでリリースされたKubernetesバージョン1.10ベースで、これはOracle Linux 7で使用可能で、Oracle Container Runtime for Dockerと統合するように設計されています。Oracle Container Services for use with Kubernetesは一連のDockerコンテナで実行され、これらのイメージはOracle Container Registryの”Container Services (Developer)”という新しいセクションから入手できます。
Oracle Container Registry
https://container-registry.oracle.com/
Oracleはkubeadmクラスタ構成ユーティリティを利用するセットアップおよび構成スクリプトを作成、テスト済みです。このセットアップスクリプトにより、Oracle Linuxでの構成とセットアップが容易になり、バックアップとリカバリのサポートが強化されています。

Installation

Oracle Container Services 1.1.10 for use with Kubernetesは、Oracle Linux yumサーバー上のOracle Linux 7 Developer Channelから無料でダウンロードできます。
Oracle Linux Yum Server
https://yum.oracle.com/
標準のyum updateコマンドを使用してアップグレードできますが、以下のいずれかの条件を満たすシステムのKubernetesはサポート対象外です。
  • ol7_preview、ol7_developer、ol7_developer_EPEL yumリポジトリまたはULNチャネルが有効な場合
  • または、前項のリポジトリまたはチャネルのソフトウェアがKubernetesが動作するシステム上にインストールされている場合
Kubernetes®は、The Linux Foundationの米国およびその他の国における登録商標であり、The Linux Foundationのライセンスに基づいて使用されています。

Resources – Oracle Linux

Documentation

Software Download

Blogs

Community Pages

Social Media

Data Sheets, White Papers, Videos, Training, Support & more

Product Training and Education

コミュニティベースのサポートについては、Oracle Technology Network CommunityのOracle Linuxスペースへどうぞ。
Oracle Linux
https://community.oracle.com/community/server_&_storage_systems/linux/oracle_linux
Oracle Technology Network Community
https://community.oracle.com/welcome

[Blockchain] Oracle Blockchain update: Hyperledger Fabric v1.1 support and much more

原文はこちら。
https://blogs.oracle.com/cloud-platform/oracle-blockchain-update-hyperledger-v11

Oracleは、急速に拡大するユーザー層をサポートするため、新しく拡張された機能を継続的にリリースすることにより、ブロックチェーン・プラットフォームの改善に注力しています。7月は以下のような機能強化を行いました。
  1. 以下の機能を持つHyperledger Fabric 1.1をサポート
    Hyperledger Fabric v1.1 Released!
    https://www.hyperledger.org/blog/2018/03/20/hyperledger-fabric-v1-1-released
    • Node.jsのチェーンコードをサポート
      Hyperledger Fabric 1.1のサポートに伴い、Node.jsでチェーンコードを作成できるようになり、Node.jsを使い慣れた幅広い開発者に訴えるだけでなく、幅広いツールで開発できるようになりました。
    • 全てのSDK(Node.js、Java、Go)とFabric CAがアップデートされ、Hyperledger Fabric 1.1をサポートするようになりました
    • 接続プロファイルのサポートと、OABCSコンソールでConnectionプロファイルを生成できるようになりました
    • 開発者パッケージやサンプルは接続プロファイルを利用するようアップデートされました。コンソールのDeveloper ToolsタブのApp Devエリアからご利用いただけます。
    • 属性ベースのアクセス管理をサポートするようになりました。
  2. SQLベースのクエリ
    • ブロックチェーンが理解できるビジネスクエリの作成がはるかに簡単になりました。OABCSチェーンコードでは、SQLを使用して、state-of-the-world(世界の様子)のためのリッチなクエリを作成できます。
    • OABCSのチェーンコードのリッチなクエリでは、互換性のためにCouchDBのクエリ構文を使用できます。
  3. 新たなPeerエイリアスフィールド
    • このフィールドを使って、Peerの名前にエイリアスを追加し、Peerおよびその利用用途を識別しやすくできます。
  4. Transient map(一時マップ)とRESTプロキシ
    • RESTプロキシからチェーンコードを呼び出したりクエリする場合、一時マップを使ってデータを渡すことができるようになりました。
  5. チェーンコードコンテナの最適化
    • 新バージョンのチェーンコードがチャネルでインスタンス化されると、旧バージョンのチェーンコードは停止します。これにより、利用していないチェーンコードコンテナが消費するシステムリソースを解放できます。
纏めると、パフォーマンスを向上させ、開発者のニーズに対応し、ブロックチェーン・ネットワークの構築、デプロイ、および管理を容易にするために、Oracleはブロックチェーン・プラットフォームを継続的にアップデートすることにコミットします。急速に拡大しているユーザーベースからのフィードバックを受け取り、そのフィードバックがサービス全体の改善に役立つ機能に結びつきます。無料試用は以下のURLにアクセスしてサインアップしてください。
Autonomous Blockchain Cloud Service
https://cloud.oracle.com/ja_JP/blockchain

[Machine Learning] Introducing GraphPipe

原文はこちら。
https://blogs.oracle.com/developers/introducing-graphpipe

Dead Simple Machine Learning Model Serving

ここ数年で機械学習は急速に進歩し、今日ではどれか一つのフレームワークを使って、オンラインチュートリアルに従い、動作する機械学習モデルを数時間で作成できるようになりました。しかし残念なことに、そのモデルを本番環境に展開する準備ができたとしても、まだ固有の課題に直面します。

第一に、モデルを提供するAPIに標準がないため、フレームワークで提供されるもので悩まされる可能性があります。これは、Protocol Buffersかもしれませんし、カスタムのJSONかもしれません。あなたのビジネスアプリケーションは、デプロイされたモデルと話すためだけに、特注のクライアントを必要とすることが一般的です。複数のフレームワークを使用している場合はさらに事態が悪化します。複数のフレームワークからモデルのアンサンブルを作成したい場合は、組み合わせるためのカスタムコードを記述する必要があります。

第二に、モデルサーバーの構築は非常に複雑です。デプロイはトレーニングほど注意を払う必要がないため、すぐに使えるソリューションはほとんどありません。例えば、TensorFlow ServingのGPUバージョンを構築してみてください。頭を数日間打ちつける準備をしておくべきでしょう。

最後に、既存のソリューションの多くはパフォーマンスに重点を置いていないため、特定のユースケースではパフォーマンスが不足します。Python-JSON APIを使えば複雑なモデルからtensorデータの束を取得できますが、パフォーマンスが重要なアプリケーションのためにそのデータの束をカットしてはくれません。

この3つの課題を解決するためにGraphPipeを作成しました。ネットワーク経由でtensorデータを送信するための標準的な高性能プロトコルと、あらゆるフレームワークの機械学習モデルを簡単にデプロイおよび照会するクライアントおよびサーバーの簡単な実装を提供します。GraphPipeの効率的なサーバーは、TensorFlow、PyTorch、MXNet、Microsoft Cognitive Toolkit (CNTK)、またはCaffe2で構築されたモデルに対応できます。
TensorFlow
https://www.tensorflow.org/
PyTorch
https://pytorch.org/
MXNet: A Scalable Deep Learning Framework
http://mxnet.ai/
Microsoft Cognitive Toolkit (CNTK)
https://www.microsoft.com/en-us/cognitive-toolkit/
Caffe2 - A New Lightweight, Modular, and Scalable Deep Learning Framework
https://caffe2.ai/
GraphPipeがOracleのGitHubからご利用いただけるようになったことを発表できうれしく思っています。ドキュメンテーション、サンプル、その他の関連コンテンツは、以下にあります。
GraphPipe -- Dead Simple ML Model Serving via a Standard Protocol
https://oracle.github.io/graphpipe

The Business Case

企業組織では、機械学習モデルは個別に訓練され、特注の技術を使用して導入されることがよくありますが、これは機械学習の取り組みから価値を引き出す組織の能力に影響を与えます。ファイナンスグループが作成したモデルをマーケティンググループが使用したい場合、モデルと対話するカスタムクライアントを作成する必要があります。モデルに人気が出て営業グループも利用したいと思った場合、カスタムクライアントが負荷に耐えられない可能性があります。

モデルが顧客が目にするモバイルアプリケーションやIoTアプリケーションに現れ始めると、悪化する一方です。多くのデバイスはモデルをローカルで実行できるほどの能力はないため、リモートサービスに要求する必要があります。このリモートサービスは、さまざまな機械学習フレームワークのモデルを実行しながら、効率的で安定していなければなりません。

標準があれば、研究者はお望みのツールを使って最良のモデルを構築し、特別なクライアントを使わなくてもユーザーはモデルの予測にアクセスできます。モデルを複数のサーバーにデプロイでき、共通のプロトコルを使ってより大きなアンサンブルに簡単に集約できます。GraphPipeは、ビジネスが機械学習の投資から価値を引き出すために必要なツールを提供します。

Implementation Details

GraphPipeは、リモートプロセス間の機械学習データの送信を簡素化し、標準化するために設計された効率的なネットワークプロトコルです。現在、深層学習アーキテクチャのコンポーネント間でtensorのようなデータの伝送方法に対する支配的な標準は存在しません。そのため、開発者にとっては、非常に非効率なJSONや、大規模で複雑なソフトウェアであるTensorFlowに付いてくるTensorFlow ServingのProtocol Buffersのようなプロトコルを使うことが一般的です。GraphPipeは、効率のよいバイナリのメモリマップフォーマットでありながら、シンプルかつ依存関係を少なくするように設計されています。

GraphPipeは以下のものを包含しています。
  • FlatBuffers定義のセット
  • FlatBuffers定義に従って一貫してモデルを提供するためのガイドライン
  • TensorFlow、ONNX、およびCaffe2からモデルを提供するサンプル
    ONNX
    https://onnx.ai/
  • GraphPipeを使って提供されるモデルを照会するためのクライアントライブラリ
要するに、GraphPipeリクエストはTensorFlow Servingの予測リクエストのように振る舞いますが、メッセージフォーマットとしてFlatBuffersを使用します。 FlatBuffersは、GoogleのProtocol Buffersと似ており、デシリアライズ時のメモリコピーを避けるという利点があります。FlatBuffers定義は、入力tensor、入力名、および出力名を含むリクエスト・メッセージを提供します。 GraphPipeリモートモデルはリクエスト・メッセージを受け取り、要求された出力名につき1個のtensorを返します。リモート・モデルは、サポート対象の入出力のタイプとシェイプに関するメタデータも提供する必要があります。

Performance

まず、カスタムujson APIを使うPython、TensorFlow Servingの予測リクエストを使用するProtocol Buffers、およびGraphPipeリモートリクエストでの、浮動小数点tensorデータのシリアライズ、デシリアライズの速度を比較します。リクエストは約1,900万の浮動小数点値(128個の224x224x3イメージで構成)で構成され、レスポンスは約320万の浮動小数点値(128の7x7x512畳み込み出力で構成)です。 縦軸の単位は秒です。

Flatbuffersではメモリコピーなしで基礎となるデータへアクセス可能なので、GraphPipeはデシリアライズ時の性能が特に顕著です。

次に、Python-JSON TensorFlowモデルサーバー、TensorFlow Serving、およびGraphPipe-Go TensorFlowモデルサーバーを使用して、エンドツーエンドのスループットを比較します。いずれの場合も、バックエンドモデルは同じです。に大きなリクエストを1個のスレッドを使用するサーバ、5個のスレッドを使用するサーバに投げています。縦軸の単位は、モデルによって計算された1秒あたりの行です。

このテストでは、Tensorflow Serving構築の推奨パラメータを使用していることにご注目ください。TensorFlow Servingの推奨ビルド・パラメータではあまり性能が出ませんが、最終的にはGraphPipe実装と同等のパフォーマンスを実現できるコンパイルパラメータを導き出すことができました。言い換えれば、最適化されたTensorFlow ServingはGraphPipeと同様のパフォーマンスを発揮しますが、TensorFlow Servingを最適に実行するためのビルド方法は文書化されておらず、そのビルドも容易ではありません。

Where Do I Get it?

ドキュメントやサンプルは以下の場所にたくさんあります。
GraphPipe -- Dead Simple ML Model Serving via a Standard Protocol
https://oracle.github.io/graphpipe
GraphPipeのFlatBuffersの仕様はPythonやGoの仕様を実装するサーバと共にGitHub上にあります。
GraphPipe - Dead Simple ML Model Serving via a Standard Protocol
https://github.com/oracle/graphpipe
Python、Go、Java(これはまもなくリリース予定)のクライアント、ローカルのTensorFlowグラフの中にリモートモデルを含めることができるTensorFlowプラグインも提供します。
GraphPipe for python
https://github.com/oracle/graphpipe-py
GraphPipe for Go
https://github.com/oracle/graphpipe-go
GraphPipe for Java (2018/08/16現在リンクはまだ有効ではありません)
https://github.com/oracle/graphpipe-java
GraphPipe helpers for TensorFlow
https://github.com/oracle/graphpipe-tf-py

[Database, Java] Java Scalability with Sharded Database

原文はこちら。
https://blogs.oracle.com/dev2dev/java-scalability-with-sharded-database

ユーザー数、トランザクション数、およびデータが指数関数的に増加しているため、スケーラビリティはJavaアプリケーションにとって非常に重要です。シャーディング(Sharding)は、ハードウェアやソフトウェアを共有しないデータベースのプール全体にデータを分散して複製する方法で、個々のデータベースはシャード(shard)と呼ばれます。Javaアプリケーションは、プールへのデータベース(シャード)の追加や削除により、リニアにスケールアップ・スケール・ダウンできます。

リニアなスケーラビリティを達成することに加えて、シャーディングには他にも多くの利点があります。単一障害点を排除し、故障したシャードを他の動作しているシャードから隔離することで、高いデータ可用性をもたらします。シャードのサイズが小さいほど、クラウドへの展開が容易になります。また、シャーディングは異なる国または地域に異なるデータを配置することができるため、データの主権(data sovereignty)とデータの近接性(data proximity)を可能にします。

シャーディングでは、シャードには同じ列で行のサブセットが異なる表が含まれる水平パーティショニングを使用します。このパーティショニングはシャーディングキー(sharding key)に基づきます。シャーディングでは、優れたパーティショニング戦略を選択することが非常に重要です。良いシャーディングキーは、すべてのシャード間でデータが一様に分散するため、DMLやクエリーがホットシャードを作成せずに公平な分配されます。通常の場合、ユーザーまたはアプリケーションのオブジェクトを一意に識別する表の主キーはシャーディング・キーとして適格ですが、シャーディングキーを複数持つ場合もあります。例えばCustomer_IDはシャーディングキー、REGIONはスーパーシャーディングキーといった具合です。下図は、データが3つのシャードにどのように分配されるのかを示しています。これらのシャードはあわせて1個の論理データベースです。

How to make your Java applications shard aware?

Javaアプリケーションでは、特定のシャードへの接続を確立するためシャーディングキーまたは(あれば)スーパーシャーディングキーが必要です。シャードへのセッションが確立すると、すべてのSQLクエリとDMLを指定されたシャードのスコープ内で実行します。JDK 9の標準Sharding APIは、シャード対応のJavaアプリケーションを開発するためのシャードキーとスーパーシャーディングキーを受け入れます。
ShardingKey (Java SE 9 & JDK 9)
https://docs.oracle.com/javase/9/docs/api/java/sql/ShardingKey.html
ShardingKey (Java SE 10 & JDK 10)
https://docs.oracle.com/javase/10/docs/api/java/sql/ShardingKey.html
例えば、シャードされたデータベースに接続する際にシャーディング・キーとスーパーシャーディング・キーを受け入れるよう、Oracle JDBCドライバとUniversal Connection Pool(UCP)(12.2.0.1以降)は拡張されました。

例としてOracle Shardingをみてみましょう。
Oracle Sharding
http://www.oracle.com/technetwork/jp/database/database-technologies/sharding/overview/index.html
http://www.oracle.com/technetwork/database/database-technologies/sharding/overview/index.html
Oracle Database v12.2.0.1は、Global Data Services(GDS)を使ったシャーディングをサポートしています。シャード・ディレクター(Shard Director)またはGSMリスナー(GSM listener)が、接続要求中に渡されたシャーディングキーに基づいて適切なシャードに接続をルーティングします。シャード・トポロジ(特定のシャードに格納されているシャーディングキーのレンジ・マッピング)は最新にメンテナンスされます。クライアント・サイドの接続プールでは、シャード・トポロジーを取得し、クライアント・サイドにトポロジーをキャッシュするために、シャードへの接続を確立した1個の接続だけが必要です。その後、シャーディングキーを渡して接続を要求すると、接続プールはトポロジ内でそのキーが属するシャードを調べ、正しいシャードへの接続を返します。これが直接ルーティング(Direct Routing)です。例えば、Java接続プールはUCPはシャード・トポロジをキャッシュし、シャードディレクタとして機能します。そのため、UCPを使って構築されたアプリケーションは、シャードの高速パスを取得して、シャード・ディレクターへの追加ホップを節約します。

How to aggregate the data from all shards?

アプリケーションがすべてのシャード間でデータを集約する必要がある場合、シャード・カタログ(Shard Catalog)とも呼ばれるシャード・コーディネータ(Shard Coordinator)に接続して、クロスシャード・クエリ(cross-shard query)を実行できます。シャード・コーディネータまたはシャード・カタログを使用すると、ユーザーはシャーディングキーを指定せずにSQL文を発行できます。コーディネータのSQLコンパイラは、クエリを分析して、複数のシャードによって送信され実行されるクエリ・フラグメントに書き換えます。クエリ処理後、データはコーディネータが集約します。これがプロキシルーティング(Proxy Routing)です。

JDBC APIs for Sharding:

Sharding APIでは、データベースへの接続を確立するためにシャーディングキーを渡す必要があります。シャードされたデータベースに接続するには、次の手順が必要です。
  1. Build the sharding key(シャーディングキーの作成)シャーディングキーを作成して、シャーディングキー値とシャーディングデータタイプを渡してください。SQL DeveloperまたはSQLPlusを使用してシャードされたデータベースに接続し、テスト目的でシャーディング・キーのリストを取得できます。
  2. Build the super sharding key(スーパーシャーディングキーの作成)スーパーシャーディングキーはオプションです。シャードされたデータベースがスーパーシャーディングキーを使用していない場合は、この手順を無視してください。
  3. Getting a connection to the shard(シャードへの接続の取得)シャーディングキーとスーパーシャーディングキーを作成後、シャーディングキーに関連するデータを持つシャードへの接続に成功するために、これらのキーを渡す必要があります。
シャードされたデータベースをテストするためのサンプルコードは、JDBCShardingSample.javaを参照してください。

(訳注)
○○のコードを参照してください、とありますが、原文にもそのコードへのリンクがありません。

注意

JDBC driver 12.2.0.1は JDK9の標準Sharding API をサポートしていません。計画では、将来のデータベース・リリースでサポートする予定です。その代わりに、JDK 8やJDK 9を使うアプリケーションでSharding APIをサポートするため、Oracle JDBCドライバはoracle.jdbc.OracleShardingKeyを使います。

以下のコード・スニペットは、Oracle JDBCドライバを使ってシャードされたデータベースへの接続の確立する例です。
import oracle.jdbc.OracleShardingKey;
import oracle.jdbc.OracleType;
import oracle.jdbc.pool.OracleDataSource;

OracleDataSource ods = new OracleDataSource();
ods.setURL(url);
ods.setUser(user);
ods.setPassword(pwd);

// 1. Build the Sharding Key
Date shardingKeyVal = new java.sql.Date(0L);
OracleShardingKey shardKey = 
  ods.createShardingKeyBuilder()
     .subkey(shardingKeyVal, OracleType.DATE)
     .build();

// 2. Build the Super Sharding Key (Optional)
OracleShardingKey superShardKey =
  ods.createShardingKeyBuilder()       
     .subkey("Customer_Location_US”,oracle.jdbc.OracleType.VARCHAR2) 
     .build();

// 3. Get a connection from the specific shard
Connection conn = ods.createConnectionBuilder()
                     .shardingKey(shardKey)
                     .suerShardingKey(superShardKey)
                     .build();

UCP APIs for Sharding:

UCP Sharding APIはシャードされたデータベースへの接続を確立するためにシャーディング・キーを渡す必要があります。シャードされたデータベースをテストするためのサンプルコードは、UCPShardingSample.java を参照してください。

以下のコード・スニペットは、Oracle Universal Connection Pool (UCP)を使ってシャードされたデータベースへの接続を確立する例です。
import oracle.jdbc.OracleShardingKey;
import oracle.jdbc.OracleType;
import oracle.ucp.jdbc.PoolDataSourceFactory;
import oracle.ucp.jdbc.PoolDataSource;

PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");
pds.setURL(DB_URL);
pds.setUser(DB_USER);
pds.setPassword(DB_PASSWORD);
pds.setConnectionPoolName("UCP_POOL");
pds.setInitialPoolSize(5); //Initial connections when the pool is created
pds.setMinPoolSize(5); // Minimum number of connections
pds.setMaxPoolSize(20); // Set the maximum number of connections

// 1. Build the Sharding Key
String email= "test@test.com";
OracleShardingKey shardKey =  
  pds.createShardingKeyBuilder()                
     .subkey(email, OracleType.VARCHAR2)                 
     .build();

// 2. Build the Super Sharding Key (Optional)
OracleShardingKey superShardKey = 
  pds.createShardingKeyBuilder()      
     .subkey("Location_US”,oracle.jdbc.OracleType.VARCHAR2) 
     .build();

// 3. Get a connection to the specific shard
Connection conn = pds.createConnectionBuilder()
                     .shardingKey(shardKey)
                     .suerShardingKey(superShardKey)
                     .build();

Appendix:

シャーディングの解説、シャーディング・キーとしてサポートされるデータ型、新しいシャーディングAPIの詳細は、以下のドキュメントを参照してください。
Oracle® Database JDBC開発者ガイド 12c リリース2 (12.2)
データベース・シャーディングのJDBCによるサポート
https://docs.oracle.com/cd/E82638_01/jjdbc/database-sharding.html
Oracle® Database JDBC Developer's Guide 12c Release 2 (12.2)
JDBC Support for Database Sharding
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/jjdbc/database-sharding.html
Oracle® ユニバーサル接続プール開発者ガイド 12c リリース2 (12.2)
データベース・シャーディングのUCP共有プールの概要
https://docs.oracle.com/cd/E82638_01/jjucp/ucp-database-sharding-overview.html
Oracle® Universal Connection Pool Developer's Guide 12c Release 2 (12.2)
Overview of UCP Shared Pool for Database Sharding
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/jjucp/ucp-database-sharding-overview.html

[Cloud] Did you know you can access reports, logs, screenshots, etc., from your build?

原文はこちら。
https://blogs.oracle.com/wercker/did-you-know-you-can-access-reports%2C-logs%2C-screenshots%2C-etc%2C-from-your-build

ビルド中に作成したさまざまなデータに、ビルド完了後にアクセスしたいことがよくあります。例えばログ、テスト結果、もしかするとスクリーンショットも含まれるかもしれません。こうした情報は、ビルド失敗時に特に重要になります。
Werckerには、Web UIからこうしたデータを簡単に利用できるようにするための機能があります。ビルド中に発生したデータを特定のディレクトリ
$WERCKER_REPORT_ARTIFACTS_DIR
に配置すると、Werckerはそのデータを保存します。そのデータは、データを作成したステップの下にある"Download artifact"ボタンをクリックすると、(Tar形式で)ダウンロードできます(下図参照)。

以前は、この機能はステップが成功した場合に利用できましたが、失敗した場合にはデータ収集しませんでした。ユーザーからのリクエストに応え、この機能をアップデートし、ステップが失敗した場合にもデータ収集するようにしました。これで、ステップ中にデータをレポートディレクトリに書き込むことができるようになり、ステップが失敗した場合、簡単にそのデータにアクセスできるようになりました。これはステップで発生した問題のトラブルシューティングに非常に有用です。

この機能を利用するには、wercker.ymlでデータをそのディレクトリに配置するように設定するだけです。以下はその例です。
build:
  steps:
    # Run the test and save the output
    - script: 
      name: Run my test
      code: |
        run_test.sh > $WERCKER_REPORT_ARTIFACTS_DIR/some-output.txt
    # Take a screenshot of the application's home page
    - screenshot:
      url: https://www.myapp.com
      filename: myapp.png
ステップが完了すると、Web UIからアーティファクトをダウンロードできます。tar形式で当該ディレクトリに書き出された任意のデータを取得できます。上記の例では、some-output.txtとmyapp.pngというスクリーンショットが含まれているはずです。

[Docker, Cloud] Announcing new built-in steps for building, testing and pushing docker images in your Wercker pipelines

原文はこちら。
https://blogs.oracle.com/wercker/announcing-new-built-in-steps-for-building%2C-testing-and-pushing-docker-images-in-your-wercker-pipelines

Werckerに3つの新しい組み込みステップが追加されました。これにより、Dockerイメージの作成、テスト、イメージ・レジストリへのPushが簡単になり、全てWerckerパイプラインで可能になりました。

Dockerfileを作成してソースコードリポジトリに追加するだけでイメージをビルドできます。DockerfileはDockerイメージを作成する標準的な方法です。そのため、既存のプロジェクトをWerckerに移動する場合は、すでにDockerfileを作成済みのことでしょう。

この internal/docker-build ステップを使って、DockerfileをWerckerで直接実行できます。 単に以下の記述をwercker.ymlに追加するだけです。
- internal/docker-build:
    dockerfile: Dockerfile 
    image-name: my-new-image
Dockerイメージを作成したら、イメージを始動してテストを実行したいと思うことでしょう。そんなときは、この新しい internal/docker-build  というステップを使って新しいイメージを始動できます。
- internal/docker-run:
    image: my-new-image
image-name は後のステップでイメージを参照するために使用する一時的な名前です。

このコマンドで先ほど作成したイメージを使って新しいコンテナを起動します。パイプラインはコンテナに接続し、やりたいテストを実行できます。

作成したイメージが”Hello World”を返すWebサーバを実行すると仮定しましょう。以下はコンテナに接続し、 curl コマンドを使って期待するレスポンスが戻ることを検証するシンプルなスクリプトのステップです。
Using Wercker to build an image from a Dockerfile
https://github.com/wercker/docker-build-golang
- script: 
    name: Test the container
    code: |
        if curlOutput=`curl -s myTestContainer:5000`; then 
            if [ "$curlOutput" == "Hello World!!" ]; then
                echo "Test passed: expected response"
            else
                echo "Test failed: unexpected response" 
                exit 1
            fi   
        else 
            echo "Test failed: container did not respond"
            exit 1
        fi        
テストが成功すると、他者がそのイメージを利用できるよう、Docker HubのようなレジストリへのイメージのPushをパイプラインにさせたいと思うことでしょう。

既存の internal/docker-push ステップを拡張し、その前の internal/docker-build ステップで作成したイメージを任意のレジストリにPushできるようにしました。:
- internal/docker-push: 
    image-name: my-new-image
    username: $USERNAME # You can configure user and password     
    password: $PASSWORD # securely in wercker.com  
        repository: docker.io/$USERNAME/docker-build-golang
        tag: latest
すごく簡単ですね。
ドキュメントをご覧いただき、GitHubのサンプルをお試しください。
Building an Image
https://devcenter.wercker.com/administration/containers/building-an-image/
Using Wercker to build an image from a Dockerfile
https://github.com/wercker/docker-build-golang

[Cloud] Foundational Oracle Cloud Infrastructure IAM Policies for Managed Service Providers

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/foundational-oracle-cloud-infrastructure-iam-policies-for-managed-service-providers

このエントリでは、Oracle Cloud Infrastructureのパートナおよびマネージド・サービス・プロバイダ(MSP)が、エンド・ユーザーに代わってOracle Cloud Infrastructureサービスを管理するための基盤として利用可能なアイデンティティ・アクセス管理(IAM)ポリシーについて説明します。
Identity and Access Management
https://cloud.oracle.com/en_US/governance/identity/features
特にこのエントリでは、MSPがエンド・ユーザーのテナント全体を管理し、それぞれのコンパートメントの管理のセルフサービス化のためにさまざまなエンド・ユーザー管理者グループの資格をプロビジョニングするために活用できる、初期IAMポリシーのユースケースに焦点を当てています。

Oracle Cloud InfrastructureのIAMのベスト・プラクティスについては、以下のブログエントリと、筆者のChangbin Gongが作成したホワイト・ペーパーをご覧ください。
Best Practices for Identity and Access Management Service on Oracle Cloud Infrastructure
https://blogs.oracle.com/cloud-infrastructure/best-practices-for-identity-and-access-management-service-on-oracle-cloud-infrastructure
Best Practices for Identity and Access Management (IAM) in Oracle Cloud Infrastructure
https://cloud.oracle.com/opc/iaas/whitepapers/best-practices-for-iam-on-oci.pdf

Use Case Overview

このエントリでは以下のようなIAMのユースケースを紹介します。
  1. テナント管理者として、MSPはテナント(customer enterprise)の全てのOracle Cloud Infrastructureのアセットを管理して、MSPは(顧客の要求に沿って)コンパートメントを作成し、顧客の管理者グループから上がってくる問題のトラブルシューティングできるようにしたい。
  2. テナント管理者として、MSPは非ルート・コンパートメントの管理を対応する顧客の管理者に委譲し、顧客の管理者がそれぞれのコンパートメントのリソースに対する資格を持つようにしたい。
  3. テナント管理者として、MSPはテナント用にロール固有の資格を作成し、MSP管理者グループの責務分担を明確にしたい。具体的には、特定のロール、例えばサーバ管理者にコンピューティングに関するサービスの資格を持たせたり、ネットワーク管理者に顧客のテナントのコンパートメント間のネットワークリソースに関する資格を持たせる。
  4. 運用管理者(Operations Admin)として、OPSチームが顧客やユーザーグループの作成や管理を望んでいるが、無制限のアクセスのためにTenant Adminグループへのアクセスは避けたい。

Requirements

  • MSPは、顧客の要求に応じてテナントとコンパートメントを作成する。この例では以下の通り。
    • MSP
      • ACME_Cloud_provider(略してACP)
    • テナント
      • ACP_Tenant
    • コンパートメント
      • Root
      • ACP_Client_Prod
      • ACP_Client_Dev
  • MSP管理者グループ
    • ACP_OPS_Admin
    • ACP_Server_Admin
    • ACP_Network_Admin
  • 顧客管理者グループ
    • ACP_Prod_Admin
    • ACP_Dev_Admin
    • (必要であれば)ACP_Customer_Admin:ユーザープロビジョニングのための顧客管理者グループ
  • ポリシー
    • ACP_Tenant_Policy
    • ACP_Prod_Policy
    • ACP_Dev_Policy
    • ACP_Customer_Policy.

Steps

各ユースケースについて、必要なグループを作成し、ユーザをグループに追加し、以下の手順でOracle Cloud Infrastructureコンソールでポリシーを作成します。詳細手順のリンクは以下の通りです。
  1. グループの作成
    1. To create a group
      https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managinggroups.htm#three
  2. グループへのユーザ追加
  3. ポリシーの追加

Use Case 1

テナント管理者として、MSPはテナント(customer enterprise)の全てのOracle Cloud Infrastructureのアセットを管理して、MSPは(顧客の要求に沿って)コンパートメントを作成し、顧客の管理者グループから上がってくる問題のトラブルシューティングできるようにしたいと思っています。

Key Policy:

  • ALLOW GROUP ACP_OPS_Admin to manage all-resources IN TENANCY

注意 
このポリシーはMSP Operationsチーム用です。管理者グループと同じアクセスが必要になることがあります。

Use Case 2

テナント管理者として、MSPは非ルートコンパートメントの管理を対応する顧客の管理者に委譲して、顧客の管理者がそれぞれのコンパートメントのリソースに関する資格を有するようにしたいと思っています。このユースケース例では、MSPは顧客の本番、開発コンパートメント用のポリシーを作成します。

Key Policy(本番コンパートメント用)
  • Allow group ACP_Client_Prod to manage all-resources in compartment ACP_Client_Prod


Key Policy(開発コンパートメント用)
  • Allow group ACP_Client_Dev to manage all-resources in compartment ACP_Client_Dev


Use Case 3

テナント管理者として、MSPはテナントのロール固有の資格を作成することを望んでいます。そのため、例えばコンピューティング関連サービスの資格を持つサーバー管理者、顧客のテナント内のコンパートメント間のネットワークリソースに関する資格を持つネットワーク管理者、というように、MSP管理者グループは明確に責務を分離します。

Key Policies(ネットワーク管理者用)

  • Allow group ACP_Network_Admin to manage virtual-network-family in tenancy
  • Allow group ACP_Network_Admin to manage load-balancers in tenancy
  • Allow group ACP_Network_Admin to read instances in tenancy
  • Allow group ACP_Network_Admin to read audit-events in tenancy

Key Policies(サーバ管理者用)

  • Allow group ACP_Server_Admin to manage instance-family in tenancy
  • Allow group ACP_Server_Admin to manage volume-family in tenancy
  • Allow group ACP_Server_Admin to use virtual-network-family in tenancy
  • Allow group ACP_Server_Admin to read instances in tenancy
  • Allow group ACP_Server_Admin to read audit-events in tenancy

Key Policies(セキュリティ管理者用)

  • Allow group ACP_Security_Admin to read instances in tenancy
  • Allow group ACP_Security_Admin to read audit-events in tenancy

Key Policies(データベース管理者用)

  • Allow group ACP_DB_Admin to manage database-family in compartment Prod
  • Allow group ACP_DB_Admin to manage database-family in compartment Dev
  • Allow group ACP_DB_Admin to read instances in tenancy

Use Case 4

運用管理者(Operations Admin)として、OPSチームが顧客やユーザーグループの作成や管理を望んでいますが、無制限のアクセスのためにTenant Adminグループへのアクセスは避けたいと考えています。

Key Policies

  • Allow group ACP_OPS_Admin to use users in tenancy where target.group.name != 'Administrators'
  • Allow group ACP_OPS_Admin to use groups in tenancy where target.group.name != 'Administrators'
注意
IAM動詞は、次のようにより詳細なものからより粗いもの、またはより限定的なものからより限定的でないもの、といった順序に並びます。

今後も、マネージド・サービス・プロバイダ向けのOracle Cloud Infrastructure IAMポリシーを取り上げるブログとホワイト・ペーパーを追加していく予定です。

IAMの詳細情報はドキュメントをご覧ください。
Overview of IAM
https://docs.cloud.oracle.com/iaas/Content/Identity/Concepts/overview.htm?TocPath=Services|IAM|_____0

[WLS, Docker] Make WebLogic Domain Provisioning and Deployment Easy!

原文はこちら。
https://blogs.oracle.com/weblogicserver/make-weblogic-domain-provisioning-and-deployment-easy

Oracle WebLogic Deploy Tooling(WDT)を使うと、WebLogic Serverドメインのプロビジョニングとアプリケーションのデプロイ自動化が容易になります。WDTでは、メンテナンスが必要なWLSTスクリプトを作成するのではなく、ドメインやアプリケーション、そしてアプリケーションが使用するリソースを記述する宣言的なメタデータモデルを作成します。このメタデータモデルを使って、プロビジョニング、デプロイメント、およびドメインライフサイクル操作の実行を繰り返し実行することができ、アプリケーションのContinuous Deliveryに最適です。
Oracle WebLogic Server Deploy Tooling
https://github.com/oracle/weblogic-deploy-tooling
WDTは10.3.6から12.2.1.3までの幅広いWebLogic ServerのバージョンならびにWindowsとUNIXの両方のOSをサポートするという柔軟性を有しており、次の利点があります。
  • WebLogicドメインを観察してメタデータモデル(JSONまたはYAML)に抽出する
  • 新規WebLogic Serverドメインをメタデータモデルを使って作成、ドメイン構成のバージョン管理が可能
  • 既存のWebLogic Serverドメインの構成を更新し、アプリケーションやリソースをドメインに展開
  • ランタイムへの変更を実施する前に、メタデータモデル(モデルとも呼ばれる)へのランタイム変更が可能
  • 別のプロパティファイルで値を提供できるようプレースホルダを設定でき、同じモデルを複数の環境に適用可能
  • モデルやプロパティファイルで直接パスワードを暗号化可能
  • スパースモデル(疎性モデル)をサポート、他のアーティファクトを記述しなくてもモデルは特定の操作に必要なものを記述するだけでよい
  • モデルの内容を簡単に検証し、関連する成果物がフォーマット上問題ないことを検証
  • 自動化とデプロイのContinuous Deliveryが可能
  • DockerイメージやKubernetesのような環境へのドメインのLift & Shiftを容易に


現在、このプロジェクトでは5個の専用ツールを提供しており、全てシェルスクリプトとして公開しています。
  • Create Domain Tool(ドメイン作成ツール、createDomain)ドメインの作成方法と、モデルに指定されているすべてのリソースとアプリケーションをドメインに移入する
  • Update Domain Tool(ドメイン更新ツール、updateDomain)
    既存のドメインを更新し、モデルに指定されているすべてのリソースとアプリケーションをオフラインモードまたはオンラインモードでドメインに移入する
  • Deploy Applications Tool(アプリケーション展開ツール、deployApps)オフラインまたはオンラインモードのいずれかで、既存ドメインにリソースとアプリケーションを追加する
  • Discover Domain Tool(ドメイン探索ツール、discoverDomain)既存のドメインを観察し、ドメインとそのドメインにデプロイされたバイナリのアーカイブファイルを記述したモデルファイルを作成する
  • Encrypt Model Tool(モデル暗号化ツール、encryptModel)ユーザーが入力したパスフレーズを使用して、モデル(またはその変数ファイル)のパスワードを暗号化する
  • Validate Model Tool(モデル検証ツール、validateModel)モデル作成や編集に役立つよう、モデルのスタンドアロン検証とモデル使用情報を提供
WebLogic on Docker and Kubernetesプロジェクトでは、WDTを利用してWebLogicドメインをプロビジョニングし、DockerイメージまたはKubernetes永続ボリューム(PV)内にアプリケーションをデプロイします。Discover Domain ToolとCreate Domain Toolのおかげで、Docker/Kubernetes以外の環境で動作するドメインを、これらの環境にLift & Shiftできます。 Docker/Kubernetes環境では特定のWebLogic構成(ネットワークなど)が必要ですが、Validate Model Toolは、WebLogicの構成を検証し、これらの環境で実行できるようにするためのしくみを提供します。

Dockerイメージ内にWebLogic Server 12.2.1.3のドメインをプロビジョニングする方法を説明するために、GitHub WebLogic Dockerプロジェクトでサンプルを作成しました。
Example Image with a WLS Domain
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/12213-domain-wdt
WebLogicドメインは、WebLogic動的クラスタ、1個のシンプルなアプリケーションがデプロイ済みで、コンテナ内で実行されるOracle Databaseに接続するデータソースで構成されます。このサンプルには、基本的なWDTモデルのsimple-topology.yamlが含まれており、このモデルにはDockerイメージ内のドメイン構成が記述されています。GitHubのWDTプロジェクトのREADMEファイルに記載の形式と規則に従って、WDTモデルをテキストエディタで作成および変更できます。また、WDTのDiscover Domain Toolを使用して既存のWebLogicドメインからモデルを作成することもできます。
Oracle WebLogic Server Deploy Tooling README
https://github.com/oracle/weblogic-deploy-tooling/blob/master/README.md
ドメイン作成には、アプリケーションとライブラリのデプロイメントが必要になることがありますが、これは、特定の構造を持つZIPアーカイブを作成し、モデル内でそれらのアイテムを参照することによって実現できます。このサンプルでは、小さなアプリケーションWARを含むシンプルなZIPアーカイブを作成してデプロイします。アーカイブは、Dockerイメージを作成する前にサンプルディレクトリに作成されています。


How to Build and Run

イメージはdocker-imagesリポジトリのWebLogic Server 12.2.1.3イメージをベースにしています。以下のREADMEに従って、ローカルリポジトリにWebLogic Serverインストールイメージをビルドします。
Oracle WebLogic Server on Docker
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/dockerfiles/12.2.1.3
(訳注)
Dockerfile(https://github.com/oracle/docker-images/tree/master/OracleWebLogic/dockerfiles/<WLSのバージョン>のDockerfile.developerもしくはDockerfile.generic)の30行目でPullしているServer JREイメージを変更しないとうまく動作しない場合があります。
Docker Storeの場合
oracle/serverjre:8  --> store/oracle/serverjre:8
Oracle Container Registryの場合
oracle/serverjre:8  --> container-registry.oracle.com/java/serverjre:8
WDTインストーラを使って、このサンプルのWebLogicドメインイメージをビルドします。

このサンプルでは、Zipアーカイブ(archive.zip)に含まれているシンプルな1ページのWebアプリケーションをデプロイします。このアーカイブを、ドメインのDockerイメージを構築する前に作成する必要があります。
$ ./build-archive.sh
ドメインイメージを作成する前に、WDTモデル(simple-topology.yaml)も必要です。 このWebLogicドメインサンプルをカスタマイズする場合は、エディタでモデル(simple-topology.yaml)を変更するか、WDT Discover Domain Toolを使用して既存のWebLogicドメインから構成を取得できます。

以下のイメージは、サンプルのWDTモデル(simple-topology.yaml)のスニペットです。ここで、データベースパスワードが暗号化され、WebLogicドメインコンテナ実行前に,提供されるプロパティファイルの値で置換されます。



このサンプルをビルドするには以下のコマンドを実行します。
$ docker build \
    --build-arg WDT_MODEL=simple-topology.yaml \
    --build-arg WDT_ARCHIVE=archive.zip \
    --force-rm=true \
    -t 12213-domain-wdt .
ローカルリポジトリにWebLogicドメインができあがっているはずです。


How to Run

このサンプルでは、WebLogicドメインの各管理対象サーバにデータソースがデプロイされています。コンテナ内で実行されているOracle Databaseにデータソースを接続する必要があるため、Oracle DatabaseイメージをDocker StoreもしくはOracle Container RegistryからローカルリポジトリにPullします。
$ docker pull container-registry.oracle.com/database/enterprise:12.2.0.1
WebLogic ServerとOracle Databaseのコンテナが動作するよう、Dockerネットワークを作成します。
$ docker network create -d bridge SampleNET

Run the Database Container

データベースコンテナを作成するには、以下の環境ファイルを使用して、データベース名、ドメイン、および機能バンドルを設定します。以下は環境ファイル(properties/env.txt)の例です。
DB_SID=InfraDB
DB_PDB=InfraPDB1
DB_DOMAIN=us.oracle.com
DB_BUNDLE=basic
以下のDockerコマンドを実行してデータベースコンテナを実行します。
$ docker run -d --name InfraDB --network=SampleNET  \
    -p 1521:1521 -p 5500:5500  \
    --env-file /Users/mriccell/Docker/docker-images/OracleWebLogic/samples/12213-domain-wdt/properties/env.txt  \
    -it --shm-size="8g"  \
    container-registry.oracle.com/database/enterprise:12.2.0.1
データベースが問題なく動作していることを確認します。docker psコマンドの出力にあるSTATUSフィールドに(healthy)と表示されていればOKです。



データベースはデフォルトのパスワード(Oradoc_db1)で作成していますが、パスワードを変更するには、SQL*Plusを使う必要があります。SQL*Plusを実行するには、Oracle Instance ClientをOracle Container RegistryもしくはDocker StoreからPullし、以下のコマンドを使ってsqlplusコンテナを実行します。
$ docker run -ti --network=SampleNET --rm \
    store/oracle/database-instantclient:12.2.0.1 \
    sqlplus sys/Oradoc_db1@InfraDB:1521/InfraDB.us.oracle.com AS SYSDBA

SQL> alter user system identified by dbpasswd container=all;
新たなデータベースパスワード(dbpasswd)をプロパティファイル(properties/domain.properties)のDB_PASSWORDに追加して、データベースに接続できることを確認してください。
$ docker exec -ti InfraDB  \
    /u01/app/oracle/product/12.2.0/dbhome_1/bin/sqlplus \
    system/dbpasswd@InfraDB:1521/InfraPDB1.us.oracle.com

SQL> select * from Dual;

Run the WebLogic Domain

domain.properties (properties/domain.properties)ファイルを編集し、データベースのパスワードを含む、WebLogicドメイン実行に必要な全てのパラメータを設定する必要があります。



コンテナ化された管理サーバを開始するには、以下のコマンドを実行します。
$ docker run -d --name wlsadmin --hostname wlsadmin \
    --network=SampleNET -p 7001:7001 \
    -v /Users/mriccell/Docker/docker-images/OracleWebLogic/samples/12213-domain-wdt/properties:/u01/oracle/properties  \
    12213-domain-wdt
コンテナ化された管理対象サーバ(ms-1)を起動して上記の管理サーバに自動登録する場合、以下のコマンドを実行します。
$ docker run -d --name ms-1 --link wlsadmin:wlsadmin \
    --network=SampleNET -p 9001:9001 \
    -v /Users/mriccell/Docker/docker-images/OracleWebLogic/samples/12213-domain-wdt/properties:/u01/oracle/properties  \
    -e MS_NAME=ms-1 12213-domain-wdt startManagedServer.sh
追加の管理対象サーバ(この例ではms-2)を起動する場合、以下のコマンドを実行します。
$ docker run -d --name ms-2 --link wlsadmin:wlsadmin  \
    --network=SampleNET -p 9002:9001 \
    -v /Users/mriccell/Docker/docker-images/OracleWebLogic/samples/12213-domain-wdt/properties:/u01/oracle/properties  \
    -e MS_NAME=ms-2 12213-domain-wdt startManagedServer.sh
上記のシナリオでは、単一のホスト環境に動的クラスタを設定したWebLogicドメインを作成します。サーバーが実行中で、データソースがコンテナ内で実行されているOracle Databaseに接続していることを確認しましょう。ブラウザでhttp://localhost:7001/console にアクセスしてWebLogic Server管理コンソールを起動します。このとき、domain.propertiesファイルで指定した資格情報を使用してログインします。



WebLogic Deploy Toolingを使うと、WebLogicドメインのプロビジョニング、アプリケーションやアプリケーションに必要なリソースのデプロイが簡単になります。WebLogic on Docker/Kubernetesプロジェクトでは、これらのツールを利用して、イメージ内のドメインのプロビジョニングを簡素化したり、Kubernetes永続ボリュームに永続化したりしています。 我々は、KubernetesでのWebLogicドメインの管理を簡素化するWebLogic Kubernetes Operatorの一般提供しましたが、WebLogicドメインの管理機能を強化したWebLogic Kubernetes Operator ver 2.0をまもなくリリースする予定です。幅広い場所でこれらのドメインが動作可能になるよう、WebLogicドメインのプロビジョニング、デプロイ、および管理を容易にするためのツールを引き続き提供していきます。このサンプルが、WebLogic Deploy Toolingを使ってWebLogic Serverドメインのプロビジョニングとデプロイメントを行いたい全ての方々にお役に立つことを願っています。皆さんのご意見をお待ちしております。

[Cloud] 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

アベイラビリティ・ドメイン内のOracle Cloud Infrastructure仮想マシンおよびベアメタルコンピューティング・インスタンスの可用性の管理と向上のための新しい方法である障害ドメイン(fault domains)が導入されました。

現在、アベイラビリティ・ドメインを使用して、仮想マシン(VM)やベアメタル・インスタンスを単一のリージョン内の複数のアベイラビリティ・ドメインドメインに分散することにより、アプリケーションの高可用性を保証しています。アベイラビリティ・ドメインは物理的に分離されており、リソース(電力、冷却装置、ネットワーク)を共有していないため、リージョン内の複数のアベイラビリティ・ドメインが障害を起こすことはほとんどありません。複数のアベイラビリティ・ドメインを使用することで高可用性が保証されるのは、いずれかのアベイラビリティ・ドメインの障害が他のアベイラビリティ・ドメインで実行されているリソースに影響を与えないためです。

単一のアベイラビリティ・ドメイン内でアプリケーションの可用性をより細かく制御したい場合に、障害ドメインを使用して可用性を達成できるようになりました。障害ドメインを使用すると、単一のアベイラビリティ・ドメイン内の異なる物理ハードウェア上にコンピューティング・インスタンスを分散できます。これにより、別のフォールトトレランス(耐障害)レイヤーが導入されます。障害ドメインは、予期しないハードウェアの障害やベースのコンピュータ・ハードウェアのメンテナンスによるアプリケーションの停止を防ぐことができます。さらに、障害ドメイン内ですべてのシェイプのインスタンスを起動できます。

Oracle Cloud Infrastructureは、通常、リージョンごとに3個のアベイラビリティ・ドメインが設計されており、各アベイラビリティ・ドメインには3個の障害ドメインがあります。ベースのコンピュータ・ハードウェアのメンテナンスを実行する場合、Oracle Cloud Infrastructureでは、残りの障害ドメインでのインスタンスの可用性を保証するため、あるタイミングで影響を受けるのは1個の障害ドメインのみです。

簡単に使い始めることができます。API、CLI、またはコンソールで新しいコンピューティングインスタンスを作成すると、インスタンスを配置する障害ドメインを指定できます。障害ドメインを指定しない場合、インスタンスはそのアベイラビリティ・ドメイン内の3個の障害ドメインのどれか1個に自動的に配置されます。インスタンス作成後に障害ドメインを変更するには、そのインスタンスを終了して再作成する必要があります。すべての既存のVMインスタンスとベアメタルインスタンスは、アベイラビリティ・ドメイン内の3つの障害ドメイン間に自動的に分散されています。

インスタンスの詳細ページを見ると、障害ドメインの情報がインスタンスの別のメタデータと共に表示されていることがわかります。

Oracle Cloud Infrastructureで障害ドメインを開始するには、以下のページへどうぞ。
Oracle Cloud
https://cloud.oracle.com/ja_JP/home
障害ドメインは、すべてのパブリック・リージョンで利用でき、追加費用は不要です。詳細は以下のリソースをご覧ください。
Oracle Cloud Infrastructure Getting Start Guide
https://docs.us-phoenix-1.oraclecloud.com/Content/GSG/Concepts/baremetalintro.htm
Cloud Computing Service - Oracle Cloud Infrastructure
https://cloud.oracle.com/ja_JP/compute
Cloud Computing FAQs - Oracle Cloud Infrastructure
https://cloud.oracle.com/compute/faq
Fault Domains
https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm#fault

[Cloud] What's New in Oracle Developer Cloud Service - August 2018

原文はこちら。
https://blogs.oracle.com/developers/whats-new-in-oracle-developer-cloud-service-august-2018



先週末にかけて、DevOpsとAgile開発のためのプラットフォームであるOracle Developer Cloud Service(DevCS)が新リリース(18.3.3)にアップデートされ、Oracle Cloudでのソフトウェア開発やリリース方法が改善される新機能が追加されました。今月のリリースで追加された主要な新機能をまとめました。

Environments

Developer Cloud Serviceの新しいトップレベルのセクションでEnvironments(環境)、つまり一つの名前の下にまとめたクラウドサービスのコレクションを定義できるようになりました。環境を定義すると、プロジェクトのホームページで環境のステータスを確認できるようになります。例えば、development(開発)、test(テスト)、production(本番)環境を定義でき、それぞれの状況を人目で確認できます。


これは、ソフトウェアアーティファクトを環境をまたがってより簡単に管理できるという、将来のDevCSの機能の最初のステップです。

Project Templates

DevCSで新規プロジェクトを作成する際、テンプレートに基づいて作成できるようになります。以前は、Oracleが作成したテンプレートに限定していましたが、今リリースからは、貴社独自のテンプレートを定義できます。

テンプレートには、wikiページ、デフォルトのgitリポジトリ、ビルドやデプロイメントステップといったデフォルトのアーティファクトを含めることができます。

これは、開発チーム間で開発を標準化することを目指している企業や、開発の繰り返しパターンを持つチームにとって非常に役立ちます。

Wiki Enhancements

DevCSのwikiはチームでの情報共有のための非常に重要な機能ですが、チーム・コラボレーションをより一層強化するために機能強化されました。

誰かによるWikiページの更新を通知させることができ、その更新された特定のWikiページやセクションを見ることができます。

また、Wikiページへのコメントのサポートも追加しました。これにより、コンテンツについて議論できるようになりました。


More

上記はDeveloper Cloud Serviceの新機能の一部に過ぎません。これらの機能はすべて、Developer Cloud ServiceがOracle Cloudのお客様に無料で提供する機能の一部です。是非ご利用いただき、コメントをお寄せください。

追加された新機能の詳細については、以下のドキュメントをご覧ください。
What's New for Oracle Developer Cloud Service - August 2018
https://docs.oracle.com/en/cloud/paas/developer-cloud/csdwn/index.html#CSDWN-GUID-88FCFA5A-9EA1-4E43-BF2B-7D5B647B5A07
技術的な質問がありましたら、弊社のcloud customer connect communityのページにお尋ねください。
Oracle Cloud Customer Connect - Developer Cloud Service
https://cloudcustomerconnect.oracle.com/resources/9553a4c68d/summary

[Cloud, Network, Security] Creating a Secure SSL VPN Connection Between Oracle Cloud Infrastructure and a Remote User

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/creating-a-secure-ssl-vpn-connection-between-oracle-cloud-infrastructure-and-a-remote-user

企業はますますモバイルを活用しようとしています。そのため、従業員に対し便利で安全なネットワークアクセスを提供できる必要があります。VPNを使用すると、ユーザーはモビリティをサポートする便利な方法であるパブリック・インターネット経由で社内ネットワークに安全に接続できます。

IPSec VPNを使用して、リモートロケーションへの専用接続を提供できます。IPSecはネットワークアクセス制御(Network Access Control)と共に使用して、承認されたユーザーだけが企業ネットワークに接続できるようにします。

もう1つのタイプのVPNとして、Secure Socket Layerプロトコルを使用するSSL VPNがあります。これはIPSecよりもきめ細かなアクセス制御が可能なので、企業はユーザーがVPN経由でアクセスできるリソースの種類を管理できます。

このブログエントリでは、OpenVPNを使用してOracle Cloud Infrastructureとリモート・ユーザー間で安全なSSL VPN接続を作成する方法について説明します。

Oracle Cloud InfrastructureとOpenVPNクライアント間でSSLトンネリングを作成するために必要な手順は概ね以下の通りです。
  1. OpenVPNのためにOracle Cloud Infrastructureを構成する
  2. OpenVPNサーバをインストール、構成する
  3. OpenVPNクライアントをインストールする

Configuration Diagram

下図は今回の構成のアーキテクチャ概要です。

図では2個のサブネットを持つVCNがあります。
  • Public (10.0.1.0/24) - パブリック・サブネット。インターネット・ゲートウェイを経由してインターネットにアクセスする。
  • Private (10.0.2.0/24) - プライベート・サブネット。インターネットへのアクセスは出来ない。

1. Configure Oracle Cloud Infrastructure for OpenVPN

以下の手順はOracle Cloud InfrastructureのVCNをOpenVPNのために作成および準備する方法の概要を示しています。

Create a VCN

アベイラビリティ・ドメインに2個のサブネットを持つVCNを作成し、OpenVPNサーバーとLinuxホストを収容します。VCNの作成方法と関連するベストプラクティスの詳細については、VCN概要と展開ガイドを参照ください。
Oracle Cloud Infrastructure
Virtual Cloud Network Overview and Deployment Guide
https://cloud.oracle.com/opc/iaas/whitepapers/OCI_WhitePaper_VCN_v1.0_LL.pdf


Public Subnet Configuration

パブリック・サブネットのルーティング・テーブル(Default route table for datacenter)にはルーティング・ルールがあり、インターネット・ゲートウェイをすべてのトラフィック(0.0.0.0/0)のルーティング先として構成しています。

サブネットのセキュリティリスト(Default Security List)に対して、すべての宛先へのトラフィックを許可するegressルールを作成します。以下のアクセスを許可するingressルールを作成します。
  • TCP Port 22 (SSH)
  • TCP Port 443 (OpenVPN TCP接続)
  • TCP Port 943 (OpenVPN Web UI)
  • UDP Port 1194 (OpenVPN UDPポート)
サブネット作成方法の詳細は、以下のドキュメントをご覧ください。
VCNs and Subnets
https://docs.cloud.oracle.com/iaas/Content/Network/Tasks/managingVCNs.htm


Launch an Instance

新しく作成したパブリック・サブネットでインスタンスを起動します。今回は、CentOS 7を実行しているVMStandard2.1シェイプを使用しています。このインスタンスを使用してOpenVPNサーバをインストールします。

詳細は、以下のドキュメントをご覧ください。
Launching an Instance
https://docs.cloud.oracle.com/iaas/Content/GSG/Tasks/launchinginstance.htm?tocpath=Getting%20Started%7CTutorial%20-%20Launching%20Your%20First%20Linux%20Instance%7C_____4


Private Subnet Configuration

プライベート・サブネットのルーティング・テーブル(Private RT)にはルーティング・ルールがあり、OpenVPN(10.0.1.9)をすべてのトラフィック(0.0.0.0/0)のルーティング先として構成しています。

セキュリティリストには、すべての宛先へのトラフィックを許可するegressルールがあります。ingressルールで、特定のアドレス範囲(オンプレミス・ネットワークやVCNの他のプライベート・サブネットなど)のみを許可します。


2. Install and Configure the OpenVPN Server

新しいインスタンスが起動したら、SSH経由でインスタンスに接続し、OpenVPNパッケージをインストールします。OSプラットフォーム用のソフトウェアパッケージは、OpenVPNのWebサイトからダウンロードできます。
Software Packages
https://openvpn.net/index.php/access-server/download-openvpn-as-sw.html

RPMコマンドを使ってパッケージをインストールします。

注意:
passwd openvpnコマンドを使ってパスワードを変更することをお忘れなく。

OpenVPNユーザーのパスワードを使い、Admin UI(https://public-ip:943/admin)に接続します。

ログインしたら、 Network Settings をクリックし、Hostname or IP addressをOpenVPNサーバインスタンスのパブリックIPに置き換えます。

続いて、VPN settingsをクリックし、ルーティングのセクションにてプライベート・サブネット・アドレスの範囲を追加します。

ルーティングのセクションで、Should client Internet traffic be routed through the VPN?(クライアントのインターネットトラフィックをVPN経由でルーティングする必要があるか?)の設定がYesになっていることを確認します。

Have clients use these DNS servers(クライアントはこれらのDNSサーバーを使用する)で、VPNクライアントマシンが使用するDNSリゾルバを手動設定します。


Inter-Client Communication

Advanced VPNのセクションで、Should clients be able to communicate with each other on the VPN IP Network?(VPN IPネットワーク上でクライアントが相互に通信できるようにする必要がありますか?)の設定がYesに設定されていることを確認します。

変更を適用したら、Save Settingsを押します。新しい構成をOpenVPNサーバにプッシュするために、Update Running Server(実行中のサーバの更新)を求めるプロンプトが表示されます。

3. Install OpenVPN Client

OpenVPN Access Server Client UI(https://Public-IP-OpenVPN-VM:943)に接続し、お使いのプラットフォーム用のOpenVPNクライアントをダウンロードします。

インストールが完了すると、OpenVPNアイコンがOSのタスクバーに現れます。これを右クリックしてコンテキストメニューを開くと、OpenVPN接続を開始できます。

Connectをクリックすると、OpenVPNのユーザ名とパスワードを要求するウィンドウが現れるので、 OpenVPNユーザーの資格情報を入力し、ConnectをクリックしてVPNトンネルを確立します。


Verification

プライベート・サブネット内の任意のOSを使ってホストインスタンスを起動します。ラップトップPCでターミナルを開き、プライベートIPを使用してホストに接続します。

Conclusion

このエントリでは、Oracle Cloud Infrastructureとリモートユーザー間で安全かつ暗号化されたSSL VPNトンネルを作成し、ユーザーがOracle Cloud Infrastructureのプライベート・サブネット内のリソースにアクセスできるようにする方法について説明しました。

[Cloud] Deploy HA Availability Domain Spanning Cloudera Enterprise Data Hub Clusters on Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/deploy-ha-availability-domain-spanning-cloudera-enterprise-data-hub-clusters-on-oracle-cloud-infrastructure

このエントリはZachary Smith (Senior Member of Technical Staff, Solutions Architect on Big Data for Oracle Cloud Infrastructure) によるものです。

Terraformを使った、Oracle Cloud Infrastructureへのアベイラビリティ・ドメインにまたがるCloudera Enterprise Data Hubのデプロイ自動化が可能になったことを発表でき、誇りに思います。このデプロイメント・アーキテクチャは、パフォーマンスを維持しながら、セキュリティと耐障害性が強化されています。
https://github.com/smithzc/terraform-provider-oci/tree/master/docs/solutions/Hadoop/EL7/Cloudera/AD-Spanning

Cloudera Enterprise Data Hub: Availability Domain Spanning

アベイラビリティ・ドメイン・スパニングは、クラウド構成を活用して耐障害性と高可用性を向上させながら、Oracle Cloud InfrastructureでCloudera Enterprise Data Hubのパフォーマンスを維持したいお客様にとって理想的です。Cloudera Enterprise Data Hubのクラスタホストは、リージョン内の3つのアベイラビリティ・ドメイン全体にデプロイされ、Zookeeper、NameNode、およびHDFSサービスは各アベイラビリティ・ドメイン内のノードに分散配置されています。

Cloudera Cluster Hosts on a Private Subnet

エンタープライズのお客様がクラウドにセキュアな環境を展開できるように引き続き我々は注力しています。このアーキテクチャでは、インターネットから直接アクセスできないプライベートサブネット上にMasterおよびWorkerクラスタホストをデプロイしています。これを実現するために、デプロイメント中の要塞ホストはNATゲートウェイとして設定され、プライベートサブネット上のホストはインターネットへのトラフィックをインターネットゲートウェイにルーティングします。このアーキテクチャは、クラスタのパフォーマンスを犠牲にせずにセキュリティを強化します。

Performance Testing

Oracle Cloud InfrastructureでのCloudera Enterprise Data Hubのパフォーマンスをテストするために、Terasortをベンチマークとして選択しました。compute、メモリ、ストレージ、ネットワークというHadoopデプロイメントに関わるすべての要素のI/Oをテストするため、このベンチマークはHadoopの標準です。

以下のグラフは、各デプロイメント・アーキテクチャで2個のクラスタタイプ間で10 TBのTerasortを実行した場合の比較です。最初のクラスタタイプは、HDFS用に6個の1.5 TBブロックボリュームを使用する仮想マシン、もう一方のクラスタタイプは、HDFS用にローカルNVMeを使用したベアメタルです。クラスタトポロジは両アーキテクチャで同一です。

  • Workerノード:5個
  • Cloudera Managerノード:1個
  • クラスタサービスのMasterノード:2個
  • 要塞ホスト:1個



結果を見ると、Workerノード5個での10 TBのソートが非常に高速であるだけでなく、単一のアベイラビリティ・ドメインの場合とアベイラビリティ・ドメイン・スパニング・アーキテクチャーを比較しても、ソート時間にほとんど違いがありません。これらのテストは連続して複数回実行しており、ジョブ実行時刻に関係なく、結果はほぼ同じでした。Oracleの業界最高レベルのクラウドのSLAの素晴らしい例といえるでしょう。

この領域でさらに改善をしており、Oracle Cloud InfrastructureでのCloudera Enterprise Data Hubのリファレンス・アーキテクチャと、これらのTerraformテンプレートの使用方法について詳説するホワイトペーパーがあります。
Cloudera Enterprise Data Hub Reference Architecture for Oracle Cloud Infrastructure Deployments
https://cloud.oracle.com/iaas/whitepapers/cloudera_reference_arch_oci.pdf
ご質問があれば、8月2日9時から13時(PDT)に開催されるCloudera NowのVirtual Event Boothにご参加ください(要登録)。
(訳注)
オンデマンド視聴も登録が必要のようです。
Cloudera Now
https://www.cloudera.com/more/events/cloudera-now.html?src=Oracle
登録
https://www.cloudera.com/more/events/cloudera-now.html?src=Oracle#reg
ClouderaとOracleソリューションをお見逃しなく。是非フィードバックをお寄せください。
Cloudera Enterprise Data Hub on Oracle Cloud Infrastructure
http://cloud.oracle.com/iaas/cloudera

[Applications, Cloud] Announcing SAP NetWeaver® Support for VM Shapes on Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/announcing-sap-netweaver-support-for-vm-shapes-on-oracle-cloud-infrastructure

業界で最も幅広く、かつ最も統合されたパブリック・クラウドであるOracle Cloud Infrastructureは、パブリック・クラウドから独自のデータ・センターでクラウド・サービスを使用する機能までのさまざまな導入オプションを備え、IaaS(Infrastructure as a Service)としてクラス最高のサービスを提供します。ITの複雑さを軽減することで、企業のアジリティ向上、イノベーション推進、ビジネス変革をOracle Cloudはご支援します。
Oracle Cloud
https://cloud.oracle.com/home
IaaS - Enterprise Cloud - Oracle Cloud Infrastructure
https://cloud.oracle.com/ja_JP/iaas
2018年6月から、SAP NetWeaverベースのアプリケーションでもOracle Cloud InfrastructureのVMシェイプがサポートされています。
SAP NetWeaver
https://www.sap.com/products/netweaver-platform.html
これらの新しいシェイプをサポートした結果、SAP NetWeaverですでにサポート済みのベアメタルインスタンス以外のインスタンスも利用できるようになりました。これにより、SAPをお使いのお客様にさらに柔軟性と幅広いポートフォリオを提供します。
SAP Note 2474949
https://launchpad.support.sap.com/#/notes/2474949
SAP NetWeaver® Application Server ABAP/Java on Oracle Cloud Infrastructure
http://www.oracle.com/us/solutions/sap/sap-netweaver-on-oracle-cloud-wp-3931430.pdf

Extreme Performance, Availability, and Security for SAP Business Suite Applications

企業がOracleベースのSAPアプリケーションをクラウドに簡単に移行できるようにするため、OracleはSAPと連携して、Oracle Cloud Infrastructure上でのSAP NetWeaverアプリケーションを動作保証ならびにサポートします。Oracle Cloudを使えば、同じOracle DatabaseおよびSAPアプリケーションを実行できるため、お客様が既存の投資を維持しつつ、コストを削減し、アジリティを向上できます。

第1世代のクラウドプロバイダの製品とは異なり、Oracle Cloud Infrastructureはエンタープライズ・ワークロードをサポートするためにユニークな設計がなされています。また、Oracle Database用に最適化された唯一のクラウドです。Oracle Cloud Infrastructureは、SAPやその他のエンタープライズ・ワークロードに必要なパフォーマンスの予測可能性、分離性、セキュリティ、ガバナンス、透過性を提供するように設計されています。

今回の発表では、貴社のデータセンターと同じ管理性と機能を備えながら、クラウド上でOracleベースのSAPアプリケーションを実行できます。あなたのチームを再トレーニングする必要はありません。最高のパフォーマンスを必要とするアプリケーション(数百万という安定したIOPsとミリ秒のレイテンシを必要とするアプリケーション)を従量制という柔軟性を備えたelasticなリソースに展開できるようになりながらも、オンプレミスと同等またはそれ以上のパフォーマンスと可用性を発揮します。これはつまり、クラウドにてより低コストでより高速にOracleベースのSAPアプリケーションを実行できる、ということです。さらに、ユニバーサルクレジットによるシンプルで予測可能で柔軟な価格設定のメリットを得ることができます。ガバナンスに関しては、シンプルなポリシー言語を使用して共有クラウドリソースを区画化し、複雑な組織であっても集中管理と可視性を維持しながらセルフサービスアクセスを提供できます。

Multiple Options Available

Oracleは、Oracle Cloud Infrastructure上でさまざまなシェイプとグレード(ベアメタルと仮想マシンの両方)を提供しています。こうした品揃えにより、より多くのお客様がオンプレミス・システムと同等以上のパフォーマンス、セキュリティ、および可用性を備えたクラウドにOracle Databaseアプリケーションのデプロイやアクセスが可能です。容易にパフォーマンスが拡張することがわかることでしょう。

OracleとSAPは、SAP NetWeaverおよびSAP NetWeaver Business WarehouseベースのアプリケーションのOracle Cloud InfrastructureおよびExadata Cloud Service上での動作保証をしました。4.2 SPレベル5以上のSAP Business Objectsもサポート対象です。SAP Hybris Help Portalの要件が満たされている場合、SAP HybrisはOracle Cloudでサポートされます。

詳細はOracle Cloud for SAPのパブリックポータルをご覧ください。
Oracle Cloud for SAP
http://www.oracle.com/us/solutions/sap/cloud/overview/index.html