[Java] Updates for Java SE Platform

原文はこちら。
https://blogs.oracle.com/java/java-se-8-9

Java SE 9.0.1はJava Platformの最新アップデートです。これは発表済みのCritical Patch Updateの一環で提供されており、重要なバグ修正が含まれています。このJRE(9.0.1)の期限は、2018年1月16日(PDT)に予定されている次回のCritical Patch Updateまでの予定です。
(訳注)セキュリティベースラインが次回のCritical Patch Updateで変更される予定ゆえに、期限切れを迎えるという意味です。
そのため、全てのJava SE 8ユーザーに対し、このリリースへのアップグレードをOracleは強く推奨いたします。
Release Notes for JDK 9 and JDK 9 Update Releases
http://www.oracle.com/technetwork/java/javase/9all-relnotes-3704433.html
Java SE Development Kit 9 Downloads
http://www.oracle.com/technetwork/java/javase/downloads/jdk9-downloads-3848520.html
Critical Patch Updates, Security Alerts and Third Party Bulletin
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
Java CPU and PSU Releases Explained
http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html
Java SE 8u151/152 (Java SE 8 update 151 および Java SE 8 update 152) もまたご利用いただけるようになりました。
Java SE Development Kit 8 Downloads
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
Java SE 8u152はPatch Set Updateで、これには8u151に含まれるもの全てに加え、追加機能が含まれています。ほとんどのJava SEユーザーに対し、重要なセキュリティに関わる修正を含むこの最新のJava 8のアップデートへのアップグレードを、Oracleは強く推奨します。このリリースに含まれている新機能やバグ修正は、Java SE 8u151のリリースノートをご覧ください。
Java Development Kit 8 Update Release Notes
http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html
Oracle Java SE Embedded Version 8 Update 151もご利用いただけるようになっています。
Oracle Java SE Embedded Downloads
http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html
JRECreateツールを使ってJREのカスタマイズが可能です。まずは利用したいプラットフォームにあったeJDKをダウンロードし、手順に従ってアプリケーションの要件にあうJREを作成してください。
Oracle® Java SE Embedded Developer's Guide Release 8
Create Your JRE with jrecreate
http://docs.oracle.com/javase/8/embedded/develop-apps-platforms/jrecreate.htm#JEMAG270
Oracle Java SE 8 EmbeddedはOracle Java SE Embedded製品の最終メジャーリリースです。JDK 9からは、Oracleは個別のJava SE Embedded製品のダウンロードを提供する予定はありません。

また、Java SE 7u161とJava SE 6u171もリリースされていますが、これらはOracle Java SEサポートの契約が必要です。詳細は以下のリリースノートをご覧ください。
Java SE 7 Advanced and Java SE 7 Support (formerly known as Java for Business 7) Release Notes
Java™ SE Development Kit 7, Update 161 (JDK 7u161)
http://www.oracle.com/technetwork/java/javaseproducts/documentation/javase7supportreleasenotes-1601161.html#R170_161
Java SE 6 Advanced and Java SE 6 Support (formerly known as Java SE for Business 6) Release Notes
Java™ SE Development Kit 6, Update 171 (JDK 6u171)
http://www.oracle.com/technetwork/java/javase/overview-156328.html#R160_171

Related Blogs

Java 9 Release Now Available!
https://blogs.oracle.com/java/java-9-release-now-available
https://orablogs-jp.blogspot.jp/2017/09/java-9-release-now-available.html
Java Magazine Issue: More Java 9
https://blogs.oracle.com/java/java-magazine-more-java-9
https://orablogs-jp.blogspot.jp/2017/09/new-java-magazine-issue-more-java-9.html
Java Magazine Issue: Inside Java 9
https://blogs.oracle.com/java/java-magazine-inside-java-9
https://orablogs-jp.blogspot.jp/2017/07/new-java-magazine-issue-inside-java-9.html

[WLS, Kubernetes, Docker] Security Best Practices for WebLogic Server Running in Docker and Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes

Overview

WebLogic Server(WLS)チームは、KubernetesおよびDockerクラウド環境でWLSを実行するための新しい統合機能に投資しています。この取り組みの一環として、WebLogic Server実行時にDockerおよびKubernetes環境を保護するためのベストプラクティスを割り出しました。
これらのベストプラクティスは、以下のドキュメントにある一般的なWebLogic Serverの推奨事項に追加されるものです。
Oracle® Fusion Middleware
Securing a Production Environment for Oracle WebLogic Server
12c (12.2.1.3.0)
https://docs.oracle.com/middleware/12213/wls/LOCKD/intro.htm

Ensuring the Security of WebLogic Server Running in Your Docker Environment

References to Docker Security Resources

以下の推奨事項は、列挙したような様々なソースのドキュメントおよびホワイトペーパーを基にしています。

Summary of Recommendations

本番環境を保護するにあたっての推奨事項は以下の通りです。
  1. CIS Dockerベンチマークを使用してDockerの設定を検証します。これは、サードパーティのツールを使用して手動または自動で行うことができます。
  2. 適切なCIS Operating Systemベンチマークを使用して、ホストOSの設定を検証します。
  3. CISベンチマークで未対応の追加のホストハードニングの推奨事項を評価します。
  4. CISベンチマークで未対応の追加のコンテナランタイムの推奨事項を評価します。
これらについては、以降のセクションで詳しく説明します。

Validate Your Docker Configuration Using the Center for Internet Security (CIS) Docker Benchmark

The Center for Internet Security (CIS) は、Docker Community Editionと複数のDocker EEバージョンのベンチマークを作成しており、最新のベンチマークはDocker EE 1.13用で、Docker EEの新バージョンがリリースされた後に新たなベンチマークが追加されています。これらのベンチマークにはDockerを安全に設定するための100個ほどの詳細な推奨事項が含まれています。この推奨事項は、ホストコンポーネントとDockerコンポーネントの両方に適用され、以下のトピックで構成されています。
  • Host configuration(ホストの構成)
  • Docker daemon configuration(Dockerデーモンの構成)
  • Docker daemon configuration files(Dockerデーモンの構成ファイル)
  • Container Images and Build File(コンテナイメージとビルドファイル)
  • Container Runtime(コンテナランタイム)
  • Docker Security Operations(Dockerセキュリティオペレーション)
  • Docker Swarm Configuration(Docker Swarmの構成)
詳細は以下のベンチマークのドキュメントをご覧ください。
CIS Docker Benchmarks
https://www.cisecurity.org/benchmark/docker/
CIS Dockerベンチマークの各推奨事項に対して、手動または自動ツールを使用して構成を検証する必要があります。Dockerの構成を検証できるCISパートナーのベンチマークツールのリストは以下のURLからご覧いただけます。
CIS Center for Internet Security
https://www.cisecurity.org/
ベンチマークツールには、次のものが含まれます(アルファベット順)。
注:CISベンチマークは、商用使用のためのライセンスが必要です。詳細については、以下のURLをご覧ください。
CIS SecureSuite Membership Terms of Use
https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/

Validate Your Host Operating System (OS) Using the CIS Benchmark

The Center for Internet Security (CIS) では、さまざまなLinuxディストリビューションやAIX、Solaris、Microsoft Windows、OSXなど、さまざまなOSのベンチマークも作成しています。
これらのベンチマークには、ホストOSを安全に設定するための一連の詳細な推奨事項が含まれています。たとえば、CIS Oracle Linux 7ベンチマークには、200を超える推奨事項と300ページ以上の指示が含まれています。この推奨事項は、Linux構成におけるすべての側面に適用されます。
詳細は、ベンチマーク文書をご覧ください。
CIS Benchmarks
https://www.cisecurity.org/cis-benchmarks/
手動または自動ツールを使用して、適切なCIS Operating Systemベンチマークに対して構成を検証する必要があります。OSの設定を検証できるCISパートナーのベンチマークツールのリストは以下のURLからご覧いただけます。
CIS Center for Internet Security
https://www.cisecurity.org/
たとえば、CIS Oracle Linux 7の場合、以下のツールがあります(アルファベット順)。

Additional Host Hardening Recommendations

CISのベンチマーク以外に、以下のような追加のホスト・ハードニングの推奨事項と考慮すべき情報があります。
  • GrsecurityとPAXの利用
  • NCCグループによるホスト・ハードニングの推奨事項

Grsecurity and PaX

grsecurityプロジェクトは、システムの全体的なセキュリティを強化するさまざまなパッチをLinuxカーネルに提供します。これには、アドレス空間の保護、拡張された監査およびプロセス制御が含まれます。
PaXは、スタックなどのデータメモリに対し、非実行可能プログラムメモリおよび書き込み不可能プログラムメモリとしてフラグを立てます。PaXはまた、アドレス空間レイアウトのランダム化を提供します。
Dockerで利用するカーネルでGrsecurityとPAXを実行することができます。このときDockerの構成を変更する必要はありません。セキュリティ機能はホスト全体に適用されるため、全てのコンテナに適用されます。grsecurityとPaXを調査して、それらを運用環境で使用できるかどうかを判断することができます。詳細は以下のURLをご覧ください。
grsecurity
http://grsecurity.net/

NCC Group Host Hardening Recommendations

NCCグループのホワイトペーパーには、Linuxコンテナをハードニングする上での追加の推奨事項が含まれています。
NCC Group Whitepaper
Understanding and Hardening
Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf
There is overlap between these recommendations and the CIS Dockerベンチマークとこの推奨事項には重複する箇所が2箇所あります。
  • 10.1 Generation Container Recommendations
  • 10.3 Docker Specific Recommendations 
追加のホストハードニング項目も含まれています。
  • Keep the kernel as up to date as possible(カーネルを最新に保つ)
  • Typical sysctl hardening should be applied. 
(通常のsysctlハードニングを適用する)
  • Isolate storage for containers and ensure appropriate security.(コンテナのストレージを分離して適切なセキュリティを確保する)
  • Control device access and limit resource usage using Control Groups (cgroups)(デバイスアクセスを管理し、Control Group (cgroup)を使ってリソース利用を制限する)
詳細を調べたい場合には、以下のURLをご覧ください。
NCC Group Whitepaper
Understanding and Hardening Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf

Additional Container Runtime Recommendations

CISのDockerに対する推奨事項以外に、検討すべき追加のコンテナランタイムの推奨事項があります。
  • 手動もしくはDocker Slimなどのツールを使用して作成したカスタムのseccompプロファイルを使用する
  • Docker Security Enhanced Linux(SELinux)プロファイルを活用する
  • Docker起動時に追加の制限付きLinuxカーネル機能を指定する
  • ホストサーバー上でDockerのみを実行することで、分離を向上させ、攻撃の危険性を減らす
  • NCCグループの推奨に基づき、追加のコンテナハードニングを実施する

Run with a Custom seccomp Profile

セキュアコンピューティングモード(seccomp)は、コンテナ内で利用可能なアクションを制限するために使用できるLinuxカーネル機能です。この機能は、Dockerがseccompを伴ってビルドされていて、カーネルでCONFIG_SECCOMPが有効化されている場合にのみ使用できます。Oracle Linux 7はseccompをサポートしており、デフォルトではDockerはseccompプロファイルで動作します。
デフォルトのseccompプロファイルは、seccompを使ってコンテナを実行するための適切なデフォルト設定を提供し、300以上のシステムコールのうち約44を無効にします。デフォルトのseccompプロファイルを変更することはお勧めしませんが、以下のオプションを使い、カスタムプロファイルを指定して実行することができます。
--security-opt seccomp = /path/to/seccomp/profile.json
seccompのデフォルトプロファイルの詳細については以下をご覧ください。
Seccomp security profiles for Docker
https://docs.docker.com/engine/security/seccomp/#passing-a-profile-for-a-container
Docker運用環境に対して既定のseccompプロファイルが十分ではない場合は、カスタムプロファイルを作成して実行することもできます。Docker Slimなどのツールが、静的解析と動的解析によってカスタムseccompプロファイルを生成するのに役立つことでしょう。
DockerSlim (docker-slim): Optimize and secure your Docker containers (free and open source)
https://github.com/docker-slim/docker-slim

Run with SELinux

SELinux(Security-Enhanced Linux)は、強制アクセス制御(MAC)を含むアクセス制御セキュリティポリシーをサポートするためのメカニズムを提供するLinuxカーネルセキュリティモジュールです。Dockerコンテナ起動時にSELinuxを有効化できます。
SELinuxを有効化する前に、SELinuxがインストールされていることを確認してください。
yum install selinux-policy
DockerのSELinuxモジュールを有効化します。
semodule -v -e docker
SELinuxがDocker起動時に有効化されるように指定します。
# vi /etc/sysconfig/docker
OPTIONS='--selinux-enabled --group=docker -g /scratch/docker'

Run with Restricted Capabilities

Dockerは、制限されたLinuxカーネル機能でコンテナを実行します。追加の機能を指定して、環境の要件に基づいて削除できます。 詳細については以下のURLをご覧ください。
Linux kernel capabilities
https://docs.docker.com/engine/security/security/#linux-kernel-capabilities

Run Only Docker on Server

リソースの隔離と攻撃の危険性を減らすために、サーバー上でDockerのみを実行することをお勧めします。他のサービスはDockerコンテナに移動する必要があります。

NCC Group Docker Container Hardening Recommendations

NCCグループのホワイトペーパーには、Linuxコンテナを強化するための推奨事項が追加されています。
NCC Group Whitepaper
Understanding and Hardening Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf
CISベンチマークと以前の章でリストアップした推奨事項で、以下の2箇所に重複する部分があります。
  • 10.1 Generation Container Recommendations
  • 10.3 Docker Specific Recommendations 
追加のDockerコンテナハードニング項目も含まれています。
  • Control device access and limit resource usage using Control Groups (cgroups)(Control Groups (cgroups)を使ってデバイスアクセスを管理しリソース利用を制限する)
  • Isolate containers based on trust and ownership. Have one application per container if feasible.
    (信頼と所有権に基づいてコンテナを分離する。可能であれば、1コンテナ1アプリケーションとする)
  • Use layer two and layer three firewall rules to limit container to host and guest to guest communication.
    (L2、L3ファイアウォール・ルールを使ってコンテナからホスト、ゲスト間の通信を制限する)
  • Use Docker container auditing tools such as Clair, drydock, and Project Natilus.
    (Clair、drydock、Project NatilusといったDockerコンテナの監査ツールを使う)
これらの推奨事項の詳細は、以下をご覧ください。
NCC Group Whitepaper
Understanding and Hardening Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf

Ensuring the Security of WebLogic Server Running in Your Kubernetes Production Environment

References to Kubernetes Security Resources

以下の推奨事項は、列挙したような様々なソースのドキュメントやホワイトペーパーを基にしています。

Summary of Recommendations

環境を保護するための推奨事項は
  1. Kubernetesの構成をCIS Kuberbetesベンチマークを使って検証する。これは手作業でも、3rdパーティ製ツールを使っても実施できる。
  2. CISで未対応のKubernetesランタイムに対する追加の推奨事項を評価する。
詳細は以下で説明します。

Validate Your Kubernetes Configuration Using the CIS Kubernetes Benchmark

The Center for Internet Security (CIS) は、Kubernetesのベンチマークを作成しています。このベンチマークには、約250ページにわたって、Kubernetesを安全に構成するための一連の詳細な推奨事項が含まれています。この推奨事項は、さまざまなKubernetesコンポーネントに適用されます。推奨事項は以下のトピックで構成されています。
  • API Server、Scheduler、Controller Manager、構成ファイルやetcdを含む、マスターノードのセキュリティ構成
  • Kubelet、構成ファイルなどを含む、ワーカーノードのセキュリティ構成
  • Federated Deployments(Federation API ServerやFederation Controller Managerなど)
詳細情報は以下のURLをご覧ください。
CIS Kubernetes Benchmark
https://www.cisecurity.org/benchmark/kubernetes/
CIS Kubernetesベンチマークの各推奨事項に対して、手動または自動ツールを使用して構成を検証する必要があります。以下のURLにKubernetes設定を検証できるCISパートナーのベンチマークツールのリストがあります。このリストには以下のものが含まれます(アルファベット順)。
CIS Center for Internet Security
http://www.cisecurity.org
注:CISベンチマークは、商用使用のためのライセンスが必要です。詳細については、以下のURLをご覧ください。
CIS SecureSuite Membership Terms of Use
https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/

Additional Container Runtime Recommendations

CIS Kubernetesベンチマークの推奨事項以外に、コンテナランタイムに対する検討すべき追加の推奨事項があります。

Images

イメージは脆弱性があってはならず、信頼できるレジストリまたは個人レジストリから取得する必要があります。セキュリティ上の脆弱性がないことを確認するためにイメージのスキャンを実行する必要があります。サードパーティ製のツールを使用してCVEスキャンを実行し、これらのツールをビルドプロセスに統合する必要があります。
詳細は以下のURLをご覧ください。
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

Security Context and Pod Security Policy

セキュリティ・コンテキストを使って、Podもしくはコンテナレベルでセキュリティポリシーを設定することができます。セキュリティコンテキストを使って以下のことが可能です。
  • コンテナをroot以外のユーザーで実行する
  • コンテナで利用する機能を管理する
  • ルートファイルシステムを読み取り専用にする
  • Podからrootとして実行しているユーザーでコンテナを使用しないようにする
詳細は以下のリンクをご覧ください。
Configure a Security Context for a Pod or Container
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

Secure Access to Nodes

ホストリソースへの不正アクセスというリスクを削減するため、SSHアクセスを使ったKubernetesノードへのアクセスは避けるべきです。SSHではなく、kubectl exec を使ってください。問題のデバッグが必要な場合は、SSHアクセスを許可した別のステージング環境を作成してください。

Separate Resources

Kubernetes名前空間を使用すると、作成されたリソースを論理的に名前のついたグループに分割できます。ある名前空間で作成されたリソースは、他の名前空間から隠すことができます。追加の名前空間を作成して、リソースやユーザーを追加した名前空間にアタッチできます。メモリ、CPU、およびPodがアタッチされた名前空間に対し、リソースクォータを利用できます。
詳細は、以下のURLをご覧ください。
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

Manage Secrets

secretには、パスワード、トークン、キーなどの機密データが含まれています。secretは、データボリュームとしてマウントすることも、Pod内のコンテナが使用する環境変数として公開することもできます。また、Podに直接公開せずに、システムの他の部分で使用することもできます。 以下のことを実施しておく必要があります。
  • secretへのユーザーアクセスやPodアクセスを管理する
  • secretをセキュアに保存する
  • secretにはファイルや環境変数を使わないようにする
詳細は以下のURLをご覧ください。
Secrets
https://kubernetes.io/docs/concepts/configuration/secret/

Networking Segmentation

さまざまなアプリケーションが同じKubernetesクラスタで実行されないようにネットワークを分割します。これにより、ある侵害されたアプリケーションが近隣のアプリケーションを攻撃するリスクが軽減されます。ネットワーク分割は、許可されていない限り、コンテナが他のコンテナと通信できないことを保証します。
詳細は以下のImplement Network Segmentationの項をご覧ください。
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

[Kubernetes, Docker, WLS] WebLogic on Kubernetes, Try It!

原文はこちら。
https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes%2c-try-it

WebLogicチームは、KubernetesでオーケストレーションされるWebLogicドメインの動作検証作業を実施中です。この作業の一環として、Kubernetes環境でWebLogicドメイン/クラスタをデプロイするサンプルを作成しました。これは、KubernetesとWebLogicの両方を使用してクラスタをスケールアウト・スケールインするものです。
WebLogic on Kubernetes Sample
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-K8s
WebLogic Serverには、サーバ、アプリケーション、およびリソースを監視および診断するための豊富な機能が用意されています。このサンプルでは、これらの指標をPrometheusを通して公開し、Grafanaに表示します。Prometheusが理解できる形式でWebLogicメトリックを公開するためのWebLogic Exporterを作成しました。

(訳注)
WebLogic Server on K8sは、現在動作検証中で、OpenWorld 2017では以下のような発表がありました。



WebLogic on Kubernetes Sample

このサンプル構成は、Kubernetes環境のWebLogic Server 12.2.1.3ドメインクラスタのオーケストレーションを説明するものです。このサンプルでは、Kubernetes環境のWebLogicクラスタの異なるスケールアクションを紹介します。
  1. ReplicaSetsの個数の増加・減少によりクラスタをスケールイン・スケールアウトする
  2. Open Session Count MBeanに基づいたWLDFポリシーを定義し、WebLogic Server管理サーバにスケールアクションを開始させる
StatefulSetsを使ってドメインのWebLogic Serverを定義します。これにより、管理対象サーバ名を割り当て、WebLogicクラスタ内の管理対象サーバに、well-known DNS名を使用して相互に矛盾のない可視性を与えるにあたって一貫性を持たせることができます。
WebLogicクラスタには2つのアプリケーションがデプロイされています。一つはOpen Sessionアプリケーションで、これはWLDFポリシーを呼び出して1つの管理対象サーバによりクラスタの規模を調整します。もう一つは、Memory Loadアプリケーションで、これはJVMのヒープ・メモリを割り当てます。
WLDFポリシーが呼び出されると、管理サーバと同じPodのコンテナ内で動作しているwebhookへの呼び出しが発生します。webhookはKubernetes APIを呼び出してKubernetes を起動し、Kubernetesクラスタを拡張します。これにより、WebLogicクラスタが拡張されます。
このサンプルの一環で、管理対象サーバから収集されたWLSランタイムMBeanメトリックを整形し、Prometheusが読んでGrafana UIに表示できる形式にして公開するWLS Exporterを開発しました。

Run Sample

このサンプルの実行手順は、Minikubeを使って説明していますが、このサンプルは任意のKubernetes環境で実行できます。minikube、kubectlがインストールされていることを確認し、WebLogic Server開発者インストールイメージであるoracle/weblogic:12.2.1.3-developerをビルドしてください。以下のGitHub上に、このイメージをビルドするためのDockerfileとスクリプトがあります。
Oracle WebLogic Server on Docker
http://github.com/oracle/docker-images/tree/master/OracleWebLogic/dockerfiles/12.2.1.3
このサンプルでWebLogic 12.2.1.3ドメインイメージを作成します。
$ cd wls-12213-domain
$ docker build --build-arg  ADMIN_PASS=<Admin Password> --build-arg ADMIN_USER=<Admin  Username> -t wls-12213-domain .
2個のWebアプリケーション(Open SessionアプリケーションとMemory Loadアプリケーション)をWebLogicクラスタにデプロイします。ドメインイメージ wls-12213-domainを拡張し、 wls-12213-oow-demo-domain イメージを作成します。
$ docker build -t wls-12213-oow-demo-domain -f Dockerfile.adddemoapps .
WLDFポリシーが呼び出された際にクラスタをスケールするために使われるイメージ(oow-demo-webhook イメージ) であるwebhook イメージを作成します。
$ docker build -t oow-demo-webhook -f Dockerfile.webhook .
Save the WebアプリケーションのDockerイメージとwebhookのDockerイメージをファイルシステム(*.tar)に保存して、minikubeレジストリにロードできるようにします。
$ docker save -o wls-12213-oow-demo-domain.tar wls-12213-oow-demo-domain
$ docker save -o oow-demo-webhook.tar oow-demo-webhook
minikube を起動し、環境を設定します。
$ minikube start
$ eval $(minikube docker-env)
保存済みのWebアプリケーションのDockerイメージとwebhookのDockerイメージをminikubeにロードします。
$ minikube ssh "docker load -i $PWD/wls-12213-oow-demo-domain.tar"
$ minikube ssh "docker load -i $PWD/oow-demo-webhook.tar"
OracleWebLogic/samples/wls-k8s ディレクトリから、WebLogic管理サーバと管理対象サーバを起動します。
$ kubectl create -f k8s/wls-admin-webhook.yml
$ kubectl create -f k8s/wls-stateful.yml
インスタンスが動作していることを確認しましょう。
$ kubectl get pods
管理サーバと2個の管理対象サーバが動作していることを確認できるはずです。
NAME                          READY  STATUS     RESTARTS         AGE
ms-0                          1/1    Running           0          3m
ms-1                          1/1    Running           0          1m
wls-admin-server-0            1/1    Running           0          5m
3個の全てのサーバがRunning状態になっていることを確認してから、作業を継続しましょう。
サーバはminikubeのIPアドレスでアクセスできます。通常これは192.168.99.100です。以下の方法でIPアドレスを確認します。
$ minikube ip
192.168.99.100
WebLogic Server管理コンソールにログインするには、ブラウザでhttp://192.168.99.100:30001/consoleにアクセスします。WebLogic Serverドメインイメージ(wls-12213-domain)ビルド時に引数として渡した資格証明を使ってログインします。

Prometheusを起動し、管理対象サーバを監視します。
$ kubectl create -f prometheus/prometheus-kubernetes.yml
http://192.168.99.100:32000を確認して、Prometheusが両管理対象サーバを監視していることを確認します。メトリックのプルダウンメニューをクリックしてwls_scrape_cpu_secondsを選択し、executeをクリックすると、各管理対象サーバから収集されたメトリックを確認できるはずです。

Grafanaを起動して管理対象サーバの監視をします。
$ kubectl create -f prometheus/grafana-kubernetes.yml
Connect to Grafana at: http://192.168.99.100:31000
    Log in with admin/pass
    Click "Add Data Source" and then connect Grafana to Prometheus by entering:
    Name:    Prometheus
    Type:      Prometheus
    Url:     http://prometheus:9090
    Access:  Proxy
    Click the leftmost menu on the menu bar, and select Dashboards > Import.
Upload and Import the file prometheus/grafana-config.jsonをアップロードしてインポートし、以前の手順で追加したデータソース("Prometheus")を選択します。"WLS_Prometheus"という名前のダッシュボードが生成されるはずです。
3つのグラフ、まず「Managed Servers Up Time」、続いてWebアプリケーション「Open Session Count」、3番目に「Used Heap Current Size」がが確認できます。

Webアプリケーション“Memory Load”を実行するためには、ブラウザでhttp://192.168.99.100:30011/memoryloadappにアクセスします。"Run Memory Load"をクリックすると、メモリのスパイクの状況を"Used Heap Current Size"とラベルされたGrafanaのグラフに表示します。
kubectlを呼び出し、クラスタのレプリカの個数を増やして、Kubernetesクラスタをスケールします。
$ kubectl scale statefulset ms --replicas=3
The Kubernetesクラスタには、WebLogic Serverの管理サーバとwebhookが動作する1個のPod、そして1個の管理対象サーバがそれぞれ動作する3個のPodが表示されるはずです。“kubectl get pods” を実行して、 ms-0, ms-1, ms-2 and wls-admin-server-0 を確認しましょう。

WebLogic Server管理コンソールもまたms-0、ms-1、 ms-2が実行中で、ms-3 と ms-4 が停止している状況を示しています。Prometheusは3個の管理対象サーバすべてのメトリックを表示し、Grafanaのグラフ「サーバ稼働時間」では、管理対象サーバを表す3行が表示されます。
それでは、Kubernetesクラスタを2つのレプリカにスケールダウンしましょう。
$ kubectl scale statefulset ms --replicas=2
コマンド "kubectl get pods"もしくは管理コンソールを使ってスケールの確認ができます。
管理コンソールで、スケーリングイベントをトリガーするWLDFルールを定義しました。OpenSessionAppというApplicationRuntimeのWebAppComponentRuntimeMBeanのOpenSessionsCurrentCountを監視するように構成したWLDFスマートルールを定義しました。このルールは、毎秒サンプリングした過去10秒の間で、"DockerCluster"と呼ばれるWebLogicクラスタ内の5%以上のサーバで開かれたセッションの平均個数が0.01以上に達した場合、RESTアクションを呼び出すというものです。このRESTアクションでは、webhookを呼び出して、1個"ms"という名前のStatefulsetをスケールアップします。WLDF ルールは1分アラームで構成されているため、1分間に別のアクションを呼び出すことはありません。
WebアプリケーションOpen Sessionへは、ブラウザでhttp://192.168.99.100:30011/opensessionappにアクセスします。
1分もしくは2分以内に、新たなms-1インスタスが作成されます。このms-1インスタンスは管理コンソールやkubectlコマンド、grafanaで確認できます。
Grafanaに接続して、OpenSessionCountの収集メトリックをグラフ"Open Sessions Current Count"で確認します。

環境のクリーンアップの準備ができたら、以下のコマンドでサービスを停止します。
$ kubectl delete -f prometheus/grafana-kubernetes.yml
$ kubectl delete -f prometheus/prometheus-kubernetes.yml
$ kubectl delete -f k8s/wls-stateful.yml
$ kubectl delete -f k8s/wls-admin-webhook.yml
最後に、minikubeを停止します。
$ minikube stop

Summary

このサンプルでは、Kubernetes環境でのWebLogicドメインの実行を紹介しています。WebLogicチームは現在、Kubernetes上でのWebLogicドメイン/クラスタの動作検証に取り組んでいます。動作検証の一環として、KubernetesのWebLogicドメイン/クラスタの管理、アプリケーションのアップグレード、アプリケーションのアップグレード、パッチ適用、および安全なWebLogic環境のガイドラインを公開する予定です。以下のガイドラインのブログを参照してください。
Security Best Practices for WebLogic Server Running in Docker and Kubernetes
https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes
https://orablogs-jp.blogspot.jp/2017/10/security-best-practices-for-weblogic.html
動作検証作業の一環で、WebLogicチームはWebLogic Kubernetes Operatorをリリースする予定です。これはKubernetes APIを拡張し、ドメインやクラスタのWebLogic Serverインスタンス、アプリケーションをKubernetesユーザーの代わりに構成、管理するものです。WebLogic Kubernetes OperatorはKubernetesの設定を知っており、Kubernetesのリソースとコントローラに立脚していますが、WebLogicデプロイメントの自動化および管理のためのWebLogicドメインやアプリケーション固有の知識も含まれています。WebLogic Kubernetes Operatorのリリースについての今後の発表と、KubernetesへのWebLogic環境のデプロイ方法とビルド方法に関するガイドラインに乞うご期待!

Safe Harbor Statement
上記の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。上記の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

[Linux, Docker] Announcing Oracle Container Runtime for Docker 17.06

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

Oracle Container Runtime for Docker Release 17.06の発表ができることをうれしく思っています。Oracle Container Runtimeを使うとOracle Linuxを使ったシステムやDockerをサポートする他の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/
Oracle Container Runtime for Dockerの最新リリースはDocker 17.06ベースで、Dockerの以前のリリースからの変更が組み込まれています。Oracle Container Runtime for Docker Release 17.06はOracle Linux 7 (x86_64) でご利用いただけます。これはOracleが提供した以前のリリースからのアップグレードです。

Notable Updates

Oracle Container Runtime for Dockerの最も重要な新機能の一つが、マルチステージ・ビルドのサポートです。これを使うと、最終イメージ作成のための中間ビルド成果物を作成するDockerfileを作成することができますが、この中間ビルド成果物自体は最終イメージ自身に含める必要がありません。これは、イメージサイズを小さくするだけでなく、ロード時間やコンテナ実行時のパフォーマンス向上にも寄与します。マルチステージ・ビルドに関する詳細情報は、以下のユーザーガイドをご覧ください。
Oracle® Linux 7Oracle Container Runtime for Docker User's Guide
Multi-stage Builds
http://docs.oracle.com/cd/E52668_01/E87205/html/section_m5g_mpz_3bb.html
環境ビルドにおけるその他の改良点として、DockerfileのARG命令の形式でビルド時引数を使用できるようになりました。これにより、環境変数を各イメージに渡すことができます。FROM命令では、Dockerfile中でFROM命令の前にある、ARG命令で定義された変数をサポートします。

このリリースでは、overlay2ストレージドライバはSELinuxでもサポートされるようになっています。以前のリリースでは、SELinuxが有効で、オーバーレイファイルシステムを使っている場合、Docker Engineが始動しませんでした。このチェックは、新しいカーネルがこの組み合わせをサポートし、SELinuxサポートのパッケージが更新されたため削除されました。

このリリースには、docker-storage-configユーティリティも含まれています。このユーティリティを使用すると、新規ユーザーが新規インストール時に、Dockerストレージを正しくOracleのガイドラインに従うように設定できます。詳細については、以下のユーザーガイドをご覧ください。
Oracle® Linux 7Oracle Container Runtime for Docker User's Guide
Using the docker-storage-config Utility to Automatically Configure Docker Storage
http://docs.oracle.com/cd/E52668_01/E87205/html/docker_install_upgrade_storage.html#docker_install_storage_config_script

Deprecated Features

ご注意頂きたいのは、このリリースでは、デフォルトでv1プロトコルを実行する従来のレジストリとの通信が無効になっているという点です。
--disable-legacy-registry=false
上記のデーモンオプションを設定することで、このバージョンのプロトコルを使用した通信を許可することは可能ですが、v1レジストリのサポートは非推奨です。

デーモンオプション --graph もまた非推奨になっています。より説明的で混乱を避けるため、 --data-root を利用してください。このオプションはイメージやボリューム、コンテナ、ネットワーク、Swarmクラスタの状態やSwarmノードの証明書といったデータを含む親ディレクトリのパスを示します。

Oracle Linux Resources

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スペースへどうぞ。
Space : Oracle Linux
https://community.oracle.com/community/server_&_storage_systems/linux/oracle_linux
Oracle Developer Community
https://community.oracle.com/welcome

[Database] How fast is Oracle TimesTen Velocity Scale?

原文はこちら。
https://blogs.oracle.com/timesten/how-fast-is-oracle-timesten-velocity-scale

Oracle TimesTen Velocity Scaleは、TimesTen In-Memory Databaseの基盤をベースにしています。TimesTenでは、マイクロ秒の単位という非常に低レイテンシのSQL操作を実現しています。
TimesTen Latency is measured in Microseconds not milliseconds
非常に多くの変動要素があるため、データベース間でApple to Appleでの比較を行うことは困難です。DBベンダーが互いの製品をベンチマークする際、競合他社のDBが最適に調整されていないという疑いが常にあります。以下は、Apple to AppleのDBベンチマークの例です。
2016年8月、Googleは、Sysbench DBの読み取り/書き込みワークロードを使用して、2つのアベイラビリティゾーン間での高可用性構成のOLTP DBベンチマークを公開しました。
Cloud SQL Second Generation performance and feature deep dive 
https://cloudplatform.googleblog.com/2016/08/Cloud-SQL-Second-Generation-performance-and-feature-deep-dive.html
Sysbench : Scriptable database and system performance benchmark 
https://github.com/akopytov/sysbench
Google Cloudに最適化されたGoogle Cloud SQL Second GenerationとGoogleはAWS上でAmazon RDS MySQLとAuroraを実行しましたが、コンサルティング会社(2ndWatch.com)はすぐにベンチマークを再実行し、Amazon Auroraが最適に調整されていないことを示しました。(Amazonからのコンサルティングを受けた)2ndWatchは、AWS AuroraがGoogle Cloud SQL Second Generationより優れた性能を発揮したことを証明できました。
Benchmarking Amazon Aurora
http://2ndwatch.com/blog/benchmarking-amazon-aurora/
これは、OracleではなくDBベンダーが、このベンチマークに対してデータベースが最適に調整されていることを確認したことを意味していました。
このSysbench read/write DBは、2個のアベイラビリティゾーン(データセンター)間での同期レプリケーションを実施しているため、ネットワークのラウンドトリップタイムがTimesTen Velocity Scaleの支配的な要因でした。
Sysbench throughput
上記のスループットベンチマークでの変動要素は、RDBMSとパブリッククラウドです。下図は同じSysbenchベンチマークでのレイテンシ(小さいほどよい)の結果です。
Sysbench latency
見ておわかりのように、TimesTen Velocity Scaleは最低のレイテンシならびに最高のスループットを叩き出しています。Google Cloud SQL Second GenerationやAmazon RDS MySQLおよびAmazon Auroraは全てactive-standbyレプリケーション構成を使っています。もっと読み取りのスケールのために読み取り専用のレプリカを追加することができるとしても、書き込みのスループットはアクティブなデータベースが一つであるために制限をうけます。Oracle TimesTen Velocity Scaleはactive-activeレプリケーションを使っているため、 Velocity Scaleデータベースにマシンを追加することにより、書き込みのスループットもスケールすることができます。
下図のOLTPベンチマークでは、TPTBMベンチマークを使いread/writeのスケールの様子を示しています。このワークロードは80%が読み取り、20%が書き込みです。
147 Million TPS for an 80$ read and 20% write TPTBM workload
このベンチマークでは、Oracle Bare Metal Cloud(現Oracle Cloud Infrastructure)上の32個のSun X5-2 Linux x86-64マシンを使いTPTBM read/writeワークロードがリニアにスケールすることを示すものです。
Oracle Server X5-2
http://www.oracle.com/us/products/servers/x5-2-datasheet-2312923.pdf 
コミットされた書き込みトランザクションの永続化がボトルネックだったため、マシンごとにVelocity Scaleの2つのインスタンスを使用しました。そのため、32台のマシンで64のVelocity Scaleノードが実行されていました。
書き込みI/Oのボトルネックが発生した場合に、100%読取りワークロードでテストを再実行しました。その結果、64台のマシンを使用して、毎秒120億PKのSQLのSelectという結果になりました。
1.2 Billion SQL PK reads per second

この100%読取り専用ワークロードでは、Oracle Bare Metal Cloudの64台のSun X5-2 Linuxマシンでリニアにスケールすることがわかります。より高速なマシンでこれらのテストを繰り返すことができればと考えています。
詳細は、Oracle Open World 2017のセッションでご紹介します。
TimesTen and Velocity Scale at Oracle Open World 2017
https://blogs.oracle.com/timesten/timesten-and-velocity-scale-at-oracle-open-world-2017
免責事項:これは私の個人的な考えであり、いかなる形であれ、オラクルの公式見解を表すものではありません。

[Database] What is Oracle TimesTen Velocity Scale ?

原文はこちら。
https://blogs.oracle.com/timesten/what-is-oracle-timesten-velocity-scale

Oracle Open World 2017にお出でになって、Oracle TimesTen Velocity Scale.について知ってください。
Velocity Scaleは、新しいSQL、Shared-Nothing、スケールアウト、の特徴のあるTimesTenベースのIn-memory RDBMSです。
Just how fast is TimesTen In-Memory Database?
https://blogs.oracle.com/timesten/just-how-fast-is-timesten-in-memory-database
Oracle TimesTen Velocity Scale architecture
Oracle Open World 2017ではVelocity Scaleの重要な点について知って頂けることでしょう。具体的には
  • SQL書き込みのスケールアウト方法
  • SQL読み込みのスケールアウト方法
  • 高可用性(High Availability)とリカバリ
  • SQLならびにPL/SQLでサポートされる機能
  • マシン間でのデータ分散
  • Velocity ScaleでサポートするAPI
  • 以下の他社製品とVelocity Scaleとの比較 
    • Amazon Aurora
    • Google Cloud SQL
    • MySQL Cluster
    • memSQL
    • VoltDB
    • Google Spanner
    • Apache Cassandra
  • YCSBやSysbench、TPTBMといったベンチマークでのVelocity Scaleの性能
  • Velocity Scaleが稼働するオンプレミス環境
  • Velocity Scaleが稼働するパブリック/プライベートクラウド環境
  • RAC、NoSQL、ShardingやCoherenceといったOracle製品とVelocity Scaleの違い
OOW 2017でのVelocity Scaleを取り扱うセッションやハンズオンスケジュールは以下のURLにまとめてあります。
TimesTen and Velocity Scale at Oracle Open World 2017
https://blogs.oracle.com/timesten/timesten-and-velocity-scale-at-oracle-open-world-2017

[Cloud] Announcing Fn–An Open Source Serverless Functions Platform

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

新たなオープンソースの、クラウド非依存の、サーバレスプラットフォームのFnを発表できることに非常に興奮しています。

このFn Projectは、Apache 2.0ライセンスで提供される、コンテナネイティブのサーバーレス・プラットフォームで、クラウド、オンプレミス問わずどこでも実行することができます。簡単に利用でき、全てのプログラミング言語をサポートし、拡張性とパフォーマンスに優れています。
Fn Project - The Container Native Serverless Framework
http://fnproject.io/
私たちは、始めるのが本当に簡単に始められるように注力しました。数分で試してみることができ、進歩するにつれてより高度な機能を使用することができます。ぜひクイックスタートをチェックして、数分間でご自身のfunctionを起動し、デプロイしてください。
QuickStart
https://github.com/fnproject/fn#quickstart

History

Fn ProjectはIronFunctionsを作ったチームが開発しています。このチームはサーバーレス・テクノロジーのパイオニアで、サーバーレス・プラットフォームを6年間ホストしてきました。数多くのお客様の無数のコンテナを稼働後、Dockerの登場前後の時期ですが、コンテナを大規模に稼働させる、具体的には、functions-as-a serviceのスタイルで稼働させることをチームは体得しました。

現在はOracleで、このチームはこの知見と体験をFnに注ぎ込んできました。

Features

Fnには、開発と運用のための素晴らしい機能がたくさんあります。

  • コマンドラインツールを使用して簡単にfunctionを開発、テスト、およびデプロイできます。
  • 依存関係はDocker一つだけ
  • 高性能アプリケーションのためのホットfunction
  • ラムダコードとの互換性 - ラムダコードをエクスポートしてFnで実行できます
  • 多くの人気のある言語用のFDK (Function Developer Kit)
    FDK - Java API and runtime for fn.
    https://github.com/fnproject/fdk-java
  • 高度なJava FDKとJUnitテストフレームワーク
  • Kubernetes、Mesosphere、Docker Swarmなどのお気に入りのオーケストレーションツールでFnをデプロイできます
    Kubernetes
    https://kubernetes.io/
    Mesosphere
    https://mesosphere.com/
    Docker Swarm
    https://docs.docker.com/engine/swarm/
  • トラフィックをfunctionにルーティングするために特別に構築されたスマートなロードバランサ
  • カスタムアドオンやインテグレーションを可能にする拡張性とモジュール性を備えています
プロジェクトのホームページはfnproject.ioですが、すべてのコードやリソースはGitHubにあります。
Fn Project - The Container Native Serverless Framework
http://fnproject.io/
Fn Project - The container native, cloud agnostic serverless platform.
https://github.com/fnproject/fn
皆様からのフィードバックやFnを最高最適なサーバーレス・プラットフォームにするための貢献を歓迎いたします。

Related Content


[Cloud] Cloud Foundry Arrives on Oracle Cloud with a Provider Interface and Service Brokers

原文はこちら。
https://blogs.oracle.com/developers/cloud-foundry-arrives-on-oracle-cloud

Oracle Cloudの採用がすすむにつれて、さまざまなワークロードを実行する必要性が高まっています。Cloud Foundryアプリケーション開発プラットフォームの人気があるため、昨年、Oracleのお客様がOracle CloudでCloud Foundryを実行するオプションをリクエストされました。その理由は以下の通りです。
  • Cloud Foundryは非常に人気のあるアプリケーション開発プラットフォームであり、多くのCloud Foundry開発者が他の相互に関連するプロジェクトにOracle Cloudを使用している
  • Oracle Cloudは、Cloud Foundryアプリケーションを拡張するために利用可能なOracle Cloud Platformという大きなエコシステムを備えている。逆に言えば、Cloud Foundryを使用してOracleサービスを新しい方法で拡張できる。
    Oracle Cloud Platform
    https://cloud.oracle.com/en_US/paas
  • Cloud Foundryユーザーの多くは、統合する必要のある重要なOracleワークロードを持っており、ますます多くのOracleのお客様が、これらのワークロードをOracle Cloudに移動することがより簡単であることを認識されつつある。クラウド上のOracleのワークロードの近くにCloud Foundryのワークロードを配置することで、両者を容易に相互運用し統合することができる。
それでは、Oracleはこれを実現するためにどうしたのでしょうか。

Cloud Foundry Running on Oracle Cloud

過去数ヶ月にわたり、Pivo​​talとOracleのエンジニアリングチームは、Oracle CloudでCloud Foundryを実行するためのいくつかの統合ソリューションを構築するために協力してきました。

まずBOSH Cloud Provider Interfaceから始めました。
Cloud Provider Interface (CPI)
https://bosh.io/docs/bosh-components.html#cpi
Cloud Foundryアーキテクチャのこのレイヤーは、Cloud Foundry開発者に対し、インフラストラクチャプロバイダを抽象化します。これにより、AWS、Microsoft Azure、Google Cloud Platform、現在のOracle Cloud InfrastructureなどのさまざまなクラウドプロバイダにCloud Foundryをインストールできます。

このコードはGitHubリポジトリにプッシュされ、Oracleチームが活発に作業しています。現段階ではGAではないため、Proof of Concept(概念の証明、PoC)に使用してください。
BOSH Cloud Provider Interface for Oracle Cloud Infrastructure
https://github.com/oracle/bosh-oracle-cpi
これは、OracleとPivotalの素晴らしいコラボレーションの成果でした。今後数か月の間、このCPIは、標準のCloud Foundryビルドプロセスの一部として、またCloud Foundryで利用可能なCPIの一部として定期的にテストされることになっています。

Oracle Cloud Service Brokers for Cloud Foundry

Oracle Cloud InfrastructureでCloud Foundryを実行する以外にも、開発者から聞いた重要な技術要件の1つとして、Oracle DatabaseからWebLogic Server、MySQLに至るまでの、さまざまなOracle Cloud Servicesと統合することがありました。

Cloud Foundryには、Service Brokerと呼ばれるインターフェースを介してこれを実現するための自然なモデルがあります。
Managing Service Brokers
https://docs.cloudfoundry.org/services/managing-service-brokers.html
Cloud Foundryアプリケーションは、サービスブローカーを使ってCloud Foundry上もしくはそれ以外のサービスと簡単にやりとりすることができます。操作には、プロビジョニングとデプロビジョニング、バインディングとバインド解除、インスタンスの更新とカタログ管理が含まれます。

一つ目のサービス・ブローカ・タイプは、Oracle Cloud Platform PaaSサービス用です。このモデルでは、Oracle Cloudでホストされている1つのサービスブローカーを構成することにより、Cloud FoundryがDatabase Cloud Service、Java Cloud Service、MySQL Cloud Service、DataHub Cloud Service (Cassandra) 、Event Hub Cloud Service (Kafka) を含む、5個を超える異なるPaaSサービスとやりとりすることができます。これはクラウド・サービスの初期セットであり、オラクルは市場の需要に基づいて他のものを評価する予定です。下図は、このサービスブローカーアプローチを図示したものです。

Oracleが開発した2番目のサービス・ブローカーは、Oracle Cloud Infrastructureの機能、特にOracle Cloud Infrastructure Oracle Database Cloud ServiceとOracle Cloud Infrastructure Object Storageのためのサービス・ブローカーです。これらは、これらのOracle Cloud Infrastructureサービスに直接アクセスできるようにCloud Foundryにインストールおよび設定できるサービス・ブローカーです。下図は、このモデルを図示したものです。

Deployment Approaches

Cloud FoundryとOracle Cloudの統合は、当然ながら、このソリューションが使用される典型的な展開トポロジとは何かを問われています。最初の概要として、3つのタイプのトポロジが存在することを想定しています。
  1. 全てOracle Cloudにある場合
    all in Oracle Cloudの場合、Cloud FoundryとCloud Foundryがやりとりするサービスの両方がOracle Cloudで動作し、オンプレミスでは動作しません。下図は、これを説明するためにBOSH CPIと2つのサービスブローカーをまとめたものです。

  1. ハイブリッド構成の場合
    2つめのアプローチは、Cloud Foundry がOracle Cloud以外で動作している(オンプレミス環境もしくは他社クラウドの可能性もあります)けれども、サービス・ブローカーを使い、Oracle Cloudサービスとリモートで統合するという、ハイブリッドなアプローチです。このアプローチは、ネットワークレイテンシなどの問題によって構造的な制約を受けるのは明らかですが、クラウドサービス次第では、ユースケースによっては有用なトポロジとなる場合もあります。下図は実際の動作を図示したものです。

  1. 全てオンプレミスにある場合
    3つ目のアプローチは、OracleがOracle Cloud at Customerと呼ぶ機能を活用する、全てオンプレミスにある場合のアプローチです。
    Oracle Cloud at Customer
    https://www.oracle.com/cloud/cloud-at-customer.html
    これにより、お客様はデータセンターでOracle Cloudサービスを実行できます。このアプローチは、オンプレミスでCloud Foundryを実行してパブリッククラウドにアクセスする際の、データの配置場所に対する懸念、規制上の懸念、パフォーマンスやレイテンシに関する懸念があるお客様に特に有効です。Oracle Cloud at Customerには、Oracle Cloud Machine上で実行されるOracle PaaS Service Brokerを使って通じて全ての利用可能なサービスだけでなく、Oracle Exadata Cloud Machineも含まれ、これらは全てオンプレミスで動作します。下図は、このトポロジの実際の動作を示しています。

全体として、この領域では案件ごとにたくさんの方法があります。これらの3個の異なるアプローチは、実際には指図するものではなく、どのように実現できるかというというアイデアを提供することを意図しています。

What’s Next?

この成果は、Cloud Cloud上でCloud Foundryワークロードを実行し、Oracle Cloudとやりとりするための旅の始まりです。今後数ヶ月にわたってこの作業を進めていきますので、発表をチェックしてください。

Oracle CloudのBOSH CPIおよびOracle Cloud Infrastructure Service Brokersの詳細は、以下のエントリを参照してください。
Announcing BOSH Cloud Provider Interface for Oracle Cloud Infrastructure
https://blogs.oracle.com/developers/cloudfoundry-bosh-cpi
https://orablogs-jp.blogspot.com/2017/10/announcing-bosh-cloud-provider.html
この成果に関するPivotalの展望については、以下のエントリを参照してください。
On Choice and Oracle Joining the Cloud Foundry Party
https://content.pivotal.io/blog/on-choice-and-oracle-joining-the-cloud-foundry-party

[Cloud] Announcing BOSH Cloud Provider Interface for Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/developers/cloudfoundry-bosh-cpi

本日、Pivo​​talとの提携と共に、Cloud FoundryがOracle Cloud Infrastructureで動作するようになったことを発表でき、うれしく思っています。
Cloud Foundry Arrives on Oracle Cloud with a Provider Interface and Service Brokers
https://blogs.oracle.com/developers/cloud-foundry-arrives-on-oracle-cloud
https://orablogs-jp.blogspot.com/2017/10/cloud-foundry-arrives-on-oracle-cloud.html
On Choice and Oracle Joining the Cloud Foundry Party
https://content.pivotal.io/blog/on-choice-and-oracle-joining-the-cloud-foundry-party
過去数ヶ月にわたり、Pivo​​talおよびCloud Foundryコミュニティと緊密に協力して、OCIのBOSH Cloud Provider Interfaceを開発しました。BOSHは、幅広いインフラストラクチャにCloud Foundryを展開するために作成されたツールで、このプレビュー版がご利用いただけるようになりました。
Apache 2とUPLの両ライセンスの下、BOSH CPI for OCIをGitHubにてリリースしました。
BOSH Cloud Provider Interface for Oracle Cloud Infrastructure
https://github.com/oracle/bosh-oracle-cpi
Oracleの同僚であるDhiraj Mutrejaは、CPIの作業におけるテクニカルリードをつとめています。
Dhiraj Mutreja
https://github.com/dmutreja
これは早期プレビューリリースですが、Cloud Foundryコミュニティと共同した作業の結果すでに正式に認定されており、近いうちにこれ以上のお知らせが出来ることでしょう。つまり、問題なく実際に動作するもので、我々が日々使っています。

もう一つ、BOSHとCloud Foundry on OCIをデプロイするためのTerraformの構成をオープンソース化したことも発表でき、うれしく思っています。
Terraform configurations for bootstrapping a CloudFoundry environment on Oracle Cloud Infrastructure
https://github.com/oracle/terraform-oci-cf-install
Terraform Provider for OCIを使うと、BOSH DirectorやCloud Foundryのインストール作業が非常に簡単になります。
Terraform provider for Oracle Cloud Infrastructure
https://github.com/oracle/terraform-provider-oci
Terraformは、複雑なインフラストラクチャ構成を構築するうえでよく使われるツールです。BOSHとCloud FoundryのためのTerraformの構成では、グループポリシー、仮想ネットワーク、セキュリティリストなどを構成します。全体として、およそ50のアーチファクトを作成し、フォールトトレラントでマルチアベイラビリティのドメイン設定を作成します。このツールを実行すると、この全てにSSHに対する稜堡を加え、BOSH 2 CLIを使ってBOSH Directorをデプロイします。そのため、どのポートをセキュリティリストで空けるか心配する必要はありません。

将来、BOSHのデプロイメント・マニフェストや、BOSH on OCIを使ってCloud Foundry、ZooKeeper、Concourse、Consulといった種々のシステムに展開するためのガイドをリリースする予定です。

[Linux, Docker] Oracle Container Registry mirrors in Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/wim/oracle-container-registry-mirrors-in-oracle-cloud-infrastructure

Oracle OpenWorld 2017真っ只中です。
現在、Oracle Single Sign-Onアカウントを持つユーザーに対してContainer Registryを提供しています。
Oracle Container Registry
http://container-registry.oracle.com/
このレジストリには、Oracle Database、MySQL、Oracle Linux、Java、WeblogicといったOracle製品を簡単に使用できるようにする多数のDockerイメージが含まれています。新しいアカウントの作成や登録の必要はありません。OTN、My Oracle Support、またはOracle Software Delivery Cloudで使用するためのOracle SSOアカウントを、すでに多くのお客様がお持ちだからです。
まず、Oracle Container Registryに(SSOアカウントで)ログインし、Dockerクライアントを使ってダウンロードもしくはPullしたい製品に対するライセンス条項を受け入れる必要があります。ライセンス条項を受け入れると、ライセンスに変更がない限り、もしくはライセンスを受け入れていない製品にアクセスしたくなることがなければ、再度Container RegistryのWebページにログインする必要はありません。ここからは、以下のコマンドを使って、関心のあるイメージをPullすることができます。
$ docker pull container-registry.oracle.com/<repository>/<product>
ええ、上記の事柄は目新しいものではありませんが、現時点のContainer Registryの簡単な概要をご紹介したいと思います。

What IS new:
お客様の多くがOracle Cloud Infrastructureをお使いで、新製品のDockerイメージを使うことに対し非常に関心をお持ちです。お客様や開発者の方々に最高のエクスペリエンスを享受いただきたいので、中央Container Registryのローカル・ミラーを各OCIリージョンに作成しました(もしくは今後作成する予定です)。現時点では、AshburnとPhoenixのOCIリージョンにあるミラーが稼働しており、Frankfurtはまもなく稼働予定です。これが有用な理由は、まず、パフォーマンスです。例えば、Oracle Linux 7-slimイメージをPullするのに要する時間はたった3秒強です。MySQL Community Serverの場合は8秒、Oracle Database Standard/Enterprise Editionだと(ローカルのOCIインスタンスへのフルダウンロードおよび展開で)3分です。もう一つ、全てのネットワークトラフィックがOracle Datacenter内でとどまるため、インターネット・トラフィックの帯域幅を利用しません。
このプロセスは以前と同じです。ライセンスの受け入れのためのメインのWebサイトは http://container-registry.oracle.com のままです。お使いのインスタンスでコマンドラインでDockerを使うときは、 container-registry-phx.oracle.com もしくは container-registry-ash.oracle.com をお使いください。近い将来、 container-registry-fra.oracle.com がご利用いただけるようになります。
最初、コマンドラインでログインする必要があります。
$ docker login container-registry-ash.oracle.com
Username: wim.coekaerts@oracle.com
Password:
Login Succeeded
続いて、イメージをPullできます。
$ docker pull container-registry-ash.oracle.com/os/oraclelinux:7-slim
7-slim: Pulling from os/oraclelinux
d9ca67fed2e2: Pull complete
Digest: sha256:2c4be3230da36933e1e9961909ed40c7fc3cc36107f86c2ed6c1775ea1c884fc
Status: Downloaded newer image for container-registry-ash.oracle.com/os/oraclelinux:7-slim
これらのレジストリにはOCIリージョンの外部からインターネット越しにアクセスできますので、container-registry.oracle.comのアクセスが遅い場合には、これらの新たなミラーを試してください。
ご利用いただける数多くの製品カテゴリがあり、利用方法やタグ(7.1.7.4やlatestといったイメージのバージョン)の詳細は、RegistryのWebサイトからどうぞ。






現在、 http://yum.oracle.com のOCI内部ミラーも提供の準備を進めています。Oracle Cloud InfrastructureでのOracle Linuxのgoodiesの詳細をお待ちください。

[Java] New Java Magazine Issue: More Java 9

原文はこちら。
https://blogs.oracle.com/java/java-magazine-more-java-9

Java 9の進歩は非常に広範囲であり、数号をまるまるJava 9特集にしても全てを網羅できるわけではありません。Java 9はすべての点でJavaとJDKの主要なリリースでした。前号では、Java 8からJava 9への移行方法だけでなく、主要な変更点の多くをカバーしました。今号では、Java 9の最も重要なイノベーションであるモジュールシステムを取り上げます。まず、モジュールの紹介に15ページを割きました。モジュールとは何か、どのように使うのか、について、著名なトレーナーであるPaul Deitelが執筆しています。
Java 9
http://www.javamagazine.mozaicreader.com/SeptOct2017#&pageSet=17&page=0
また、Raul-Gabriel UrmaとRichard Warburtonが引き続き言語の変更の調査をしており、今号では、Java 8で普及しこのリリースで強化された、OptionalsとCompletableFuturesという2機能の新機能を紹介しています。
Java 9 Core Library Updates: Optionals and CompletableFutures
http://www.javamagazine.mozaicreader.com/SeptOct2017#&pageSet=33&page=0
最後に、メソッド呼び出しの仕組みに関する説明を掲載しています。
The Mechanics of Java Method Invocation
http://www.javamagazine.mozaicreader.com/SeptOct2017#&pageSet=43&page=0
さらに、Clojure(LispのようなJVM言語、Closureではありません)の非常にわかりやすい入門、JavaFXの詳細説明(今号はDefine Custom Behavior in FXML with FXMLLoader)、世界で最も詳細なクイズの回答つきのいつものクイズも含んでいます。
Clojure
http://www.javamagazine.mozaicreader.com/SeptOct2017#&pageSet=63&page=0
また、特にモバイルデバイスでJava Magazineをより読みやすくするため、新しい1列形式に移行しています。

[Java] EE4J - Eclipse Enterprise for Java

原文はこちら
https://blogs.oracle.com/theaquarium/ee4j-eclipse-enterprise-for-java

Java EEの開発をEclipse Foundationに移管する予定であることを2週間前に発表してから、大きな進展がありました。本日、このイニシアチブをホストするトップレベルの新たなEclipse Projectである、EE4J(Enterprise Edition for Java)の発表ができることに興奮せざるを得ません。
Opening Up Java EE - An Update
https://blogs.oracle.com/theaquarium/opening-up-ee-update
https://orablogs-jp.blogspot.com/2017/09/opening-up-java-ee-update.html
現在作業の端緒についたところです。Oracle、IBM、Red Hat、およびEclipse Foundationは、あらゆるタスクに取り組まなければならないにもかかわらず、できるだけ早く動くよう積極的に協力しています。また、コミュニティメンバーにも支援してもらうように計画しています。そして、Mike Milinkovich(Eclipse)が彼の発表で言ったように、「it is a massive but exciting undertaking(大規模でエキサイティングな取り組み)」です!
Introducing EE4J: The first step towards Java EE at the Eclipse Foundation
https://mmilinkov.wordpress.com/2017/09/28/introducing-ee4j
現在FAQ作成に取り組んでおり、まもなく発行出来る予定です。しばらくの間、以下のEE4J草案をご覧ください。
The Eclipse Enterprise for Java Project Top Level Project Charter
https://projects.eclipse.org/projects/ee4j/charter
ee4j-communityディスカッションへの参加もお奨めします。
Mailing list: ee4j-community
https://dev.eclipse.org/mailman/listinfo/ee4j-community

[Database] cx_Oracle RPMs have landed on Oracle Linux Yum Server

原文はこちら。
https://blogs.oracle.com/linux/cx_oracle-rpms-have-landed-on-oracle-linux-yum-server

cx_Oracleを使うとOracle DatabaseにPythonからアクセスでき、Python database API仕様に準拠しています。このモジュールはOracle Database 11g、12cで利用でき、Python 2.x、3.xの両方でご利用いただけます。このたび、Oracle Linux YUMサーバにcx_Oracleの最初のRPMビルドをリリースしました。これにはcx_Oracle 6.0が含まれています。RPMビルドは以下から入手できます。
Oracle Linux 7 (x86_64) Development (ol7_developer)
http://yum.oracle.com/repo/OracleLinux/OL7/developer/x86_64/index.html
Oracle Linux 6 (x86_64) Development (ol6_developer)
http://yum.oracle.com/repo/OracleLinux/OL6/developer/x86_64/index.html
このエントリでは、Oracle Linux 7のデフォルトであるPython 2.7.5でcx_Oracle 6.0をインストールする手順を説明します。このエントリでは、Oracle Linux 7 Update 4 Vagrant boxesを使いました。
Oracle Linux Vagrant boxes
http://yum.oracle.com/boxes

1. Download and install Oracle Instant Client 12.2 RPMs

Oracle Instant Clientを使うと、Oracle Databaseアプリケーションの開発および本番環境へのデプロイが可能で、Node.jsやPHP、そしてPythonといった人気のある言語や環境で利用されています。以下のURLからOracle Linux x86-64用のInstant ClientのRPMをダウンロードします。
Oracle Instant Client
http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html 
RPMはrootユーザーでインストールしてください。以下の例では、yumを使って不足している依存性を自動的に解決しています。
$ sudo yum install ./oracle-instantclient12.2-basic-12.2.0.1.0-1.x86_64.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:oracle-instantclient12.2-basic-12################################# [100%]

2. Set Library path

Instant Clientが利用できるよう、環境変数LD_LIBRARY_PATHを適切なディレクトリに設定します。以下はその例です。
$ export LD_LIBRARY_PATH=/usr/lib/oracle/12.2/client64/lib/:$LD_LIBRARY_PATH
代替策として、他のOracleソフトウェアがマシン上になく、影響を受けない場合には、永続的にInstant Clientを実行時リンクPath(ライブラリのPath)に追加することもできます。以下はその設定例です。
$ sudo sh -c "echo /usr/lib/oracle/12.2/client64/lib > /etc/ld.so.conf.d/oracle-instantclient.conf"
$ sudo ldconfig

3. Confirm yum configuration

Make sure you have the ol7_developer リポジトリが定義済みでyumの設定で利用可能になっていることを確認します。必要に応じて、最新のOracle Linux YUMサーバのrepoファイル(http://yum.oracle.com/public-yum-ol7.repo)を入手してください。
$  grep -i developer\] -A 5 /etc/yum.repos.d/public-yum-ol7.repo 
[ol7_developer]
name=Oracle Linux $releasever Developement Packages ($basearch)
baseurl=http://yum.oracle.com/repo/OracleLinux/OL7/developer/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1

4. Install cx_Oracle RPM

>$ sudo yum install cx_Oracle-py27
...
...
Running transaction
  Installing : cx_Oracle-py27-6.0.2-1.el7.x86_64                                                            1/1 
  Verifying  : cx_Oracle-py27-6.0.2-1.el7.x86_64                                                            1/1 

Installed:
  cx_Oracle-py27.x86_64 0:6.0.2-1.el7   

5. Test connection to Oracle Database 12c

$ python
Python 2.7.5 (default, May 29 2017, 20:42:36) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>> db = cx_Oracle.connect("scott/tiger@myhost/sergio")
>>> db.version
'12.2.0.1.0'
>>> 
この新しいcx_OracleのRPMパッケージを使うと、Python-on-Oracleの開発者が迅速かつ簡単に開発を始めることができます。みなさまのご意見をこのエントリのコメント(もちろん原文に英語でお願いします)や、Python and Oracle Developer Communityにお寄せください。
Python and Oracle Developer Community
https://community.oracle.com/community/database/developer-tools/python

[Java] Java 9 Release Now Available!

原文はこちら。
https://blogs.oracle.com/java/java-9-release-now-available

Java 9には、開発者がJava SEプラットフォームを小さなデバイス向けにスケールダウンでき、パフォーマンスとセキュリティを向上させ、ライブラリや大規模アプリケーションの構築およびメンテナンスがより簡単になるモジュールシステムを含め、150を超える新機能が導入されています。

Javaプラットフォームの主要機能リリースであり、オープンなレビュー、週次ビルド、およびOpenJDKコミュニティとJCPを通じた、Oracleエンジニアと世界中のJava開発者コミュニティとの広範な連携を含む業界全体の開発努力の結果がJava 9です。
Java SE Downloads (Java 9)
http://www.oracle.com/technetwork/java/javase/overview/index.html
JDK 9のリリースとそのリリースノートは以下からどうぞ。
Java 9 expert insightsではこのリリースの主要機能を説明しています。ぜひご覧ください。
Java 9 Expert Insights
https://www.oracle.com/java/java9-screencasts.html
  • Small Language Changes in Java Development Kit 9 (Joe Darcy)
  • Modules in Java Development Kit 9 (Alex Buckley)
  • Introducing JShell (Robert Field)
  • A (Re)introduction to the G1 Garbage Collector (Paul Su) 
  • Java in a World of Containers (Paul Sandoz)
  • Collections Framework Enhancements in Java Development Kit 9 (Stuart Marks)
  • Changes to the Java Development Kit Release Model (Aurelio Garcia-Ribeyro)
Javaリリースのペースの変更が予定されています。Java PlatformチーフアーキテクトのMark Reinholdは以下のように説明しています。
“After Java 9 we will adopt a strict, time-based model with a new feature release every six months, update releases every quarter, and a long-term support release every three years...”
(Java 9以降、厳密な時間ベースのモデルを採用する予定です。(具体的には)新機能をリリースは6か月ごと、アップデートリリースは四半期ごと、長期サポート(long-term support)リリースは3年ごとに提供する予定です)
続きは以下のURLをどうぞ。
Moving Java Forward Faster
https://mreinhold.org/blog/forward-faster
Java 9の新機能やアプリケーションの移行方法などをより理解するために、以下のリソースをチェックしてください。
Java Magazineでは、2号にわたってJava 9を取り上げています。無料で購読できますので、ぜひ登録してください!
Get Java Magazine!
http://www.oracle.com/technetwork/java/javamagazine/index.html

[Cloud] Introducing Ravello on Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/introducing-ravello-on-oracle-cloud-infrastructure


Ravelloは常に企業がオンプレミスのVMwareアプリケーションをパブリッククラウドに移行しやすくしてきました。本日、Ravello on Oracle Cloud Infrastructureがご利用いただけるようになったことを発表できわくわくしています。これまでよりもずっと高パフォーマンスかつスケーラブルになりました。この新製品によって、パフォーマンス要件の厳しいエンタープライズアプリケーションのクラウドへ”lift-and-shift”(移行)が現実のものになります。
Ravello Service
https://cloud.oracle.com/ravello
Oracle Cloud Infrastructure
https://cloud.oracle.com/cloud-infrastructure

Accelerate Move of Data Center Production Apps to Cloud

企業は通常、仮想化されたホストと物理的なホスト間で本番環境のアプリケーションを実行しています。こうしたアプリケーションをパブリッククラウドに移行しようとした場合、以下のような非常に長い移行プロセスをたどります。
  • 物理ホストを仮想マシンに変換
  • VMware VMを再構築してイメージをクラウド化
  • クラウドベースのネットワークモデルを活用するため、アプリケーション設定を再構築
こうした作業には時間、お金がかかり、その投資にもかかわらず失敗することもあります。Ravelloは業界をリードするNested VirtualizationやSoftware Defined Networking ( Overlay Network) テクノロジーを活用し、基盤のパブリッククラウドを(自社)データセンターであるかのようにして、こうした移行を簡単にします。
High Performance Nested Virtualization
http://cloud.oracle.com/ravello/technology/virtualization
Software Defined Networking (Overlay Network)
http://cloud.oracle.com/ravello/technology/overlay-network
Ravello on Oracle Cloud Infrastructureを使えば、企業は自社のVMwareデータセンター・ベースのアプリケーションをプラットフォームの再構築やネットワークの再構成をする必要はありません。Oracle Cloud Infrastructureに「そのまま」移行し、物理コンポーネントを単にベアメタルサーバーに移動します。 VMware VMと物理ホストを同じクラウド上で実行できるこの独自の機能により、企業のクラウドへの移行(Journey)は迅速、簡単、かつ予測できるものなります。

Data Center-Like Capabilities on Public Cloud

Ravelloは、次世代のNested Hypervisor(HVX)を使用してOracle Cloud Infrastructureでデータセンターのような機能を実現します。HVXは3つのコンポーネントで構成されています。
  1. Nested virtualization engine変更を加えずに、基盤となるクラウド上でVMware VMを実行
  2. Networking overlayパブリッククラウドではサポートされていないクリーンなレイヤ2ネットワークをゲストVMに提供(ブロードキャストおよびマルチキャスト機能を含む)。
  3. Storage overlay基盤となるクラウドストレージを抽象化し、ブロックデバイスをVMware VMに公開
HVXのネストされた仮想化エンジンは、クラウド上でVMware VMを実行する際に比類のないパフォーマンスを提供する3つのモード(ハードウェア・アシスト、ベアメタル・ダイレクト、およびソフトウェア・アシスト)をサポートします。

Figure 1: HVX Nested Virtualization Modes
Hardware-assisted nested virtualization(ハードウェア・アシスト)
Oracle Cloud Infrastructureは、仮想化拡張機能をサポートする次世代の高速ハードウェア上で動作します。これらの拡張機能を使うと、複数のゲストOSが同じ基盤となるハードウェアを安全かつ効率的に共有することができます。HVXは、これらのハードウェアアシストCPU命令セットを使用して、基盤となるクラウドハードウェア上で直接nested virtualizationを実行するため、前世代のHVXに比べて大幅なパフォーマンスが改善しています。通常、クラウドプロバイダーは、ハードウェア支援の仮想化拡張をゲストVMに公開しないため、nested virtualizationモードで実行する場合顧客が認識できるパフォーマンスに制限があります。しかし、Oracle Cloud Infrastructure上でRavelloを実行すると、こうしたハードウェア・アシスト仮想化拡張機能に完全にアクセスできます。そのため、パフォーマンスが向上します。

Directly on Bare Metal(ベアメタル直結)
Oracle Cloud Infrastructureでは、HVXはベアメタルサーバー上での直接実行もサポートしています。中間のハイパーバイザー層を排除することで、HVXはネイティブのパフォーマンスに近い性能を出すことができます。

Software assisted nested virtualization(ソフトウェア・アシスト)
HVXは、ハードウェア仮想化拡張を利用できないクラウド上での利用を考慮し、binary translation with direct executionと呼ばれるソフトウェアベースのnested virtualizationテクノロジを使用して、VMware VMを実行します。このテクノロジは、幅広いワークロードで許容される優れたパフォーマンスを提供します。

Unleashed Performance & Scalability for Apps

Ravello on Oracle Cloud Infrastructureは、ハードウェア・アシストnested virtualizationのおかげで、最大14倍のパフォーマンス向上を実現します。HVXをベアメタル上で直接実行すると、さらなるパフォーマンス向上を実現します。このようなパフォーマンスの向上により、企業はRavelloを使用してOracle Cloud Infrastructureで本番用のVMwareアプリを簡単に実行できるようになりました。

また、企業での需要が高まるにつれて、アプリはその需要に対応するために拡張する必要がありますが、Ravello on Oracle Cloud Infrastructureを使用すれば、企業は1 VMあたり最大32個までvCPUを割り当てたり、また水平方向には数千個のVMを配置したりしてアプリケーションをスケールすることができます。

Try It for Yourself

Ravello on Oracle Cloud Infrastructureを試したくなりましたか?無料トライアルにサインアップしてご連絡ください。
Oracle Cloud Trial Page
https://cloud.oracle.com/ja_JP/tryit

[Java] Java EE 8 and GlassFish 5.0 Released!

原文はこちら。
https://blogs.oracle.com/theaquarium/java-ee-8-is-final-and-glassfish-50-is-released

Java EE 8のオープンソース参照実装であるGlassFish 5,0の一般提供、そしてJava EE 8仕様ならびにその傘下にある仕様(JAX-RS 2.1、Servlet 4.0、CDI 2.0、JSON-B 1.0、Bean Validation 2.0など)が最終化され承認されたことを発表できうれしく思っています。
Java EE 8にはプラットフォームに素敵な機能が追加されています。
  • HTTP/2のサポートを含むServlet 4.0 API
  • 新たなJSON binding APIを含む、JSONサポートの強化
  • 新たなREST Reactive Client API
  • 非同期CDIイベント
  • 新たな可搬性のあるSecurity API
  • Server-Sent Eventsのサポート(クライアントおよびサーバー側)
  • Java SE 8の機能のサポート(例えばDate & Time API、Streams API、アノテーションの強化)、など
本日、GlassFish 5.0でこれらの新機能を利用することができます。願わくば、今後Java EE 8アプリケーションサーバが増えることを願っています。Java EE 8を始めるにあたり有用と思われるリソースを末尾に付けておきます。
このリリースで直面した難題の一つに、旧来のJava.netインフラストラクチャから開発サイクルの途中でGitHubに移行したことがあります。これは必ずしも簡単ではありませんでしたが、今となっては明らかにこのような最新のソフトウェア共同開発プラットフォームのメリットがわかります。コード調査が今やたったの1個のリンクでよくなったからです。願わくば、GitHubの採用で開発者にってプラットフォームがよりアクセスしやすくなることを願っています。
Java EE - Java Enterprise Edition
http://github.com/javaee/
Java EE 8は実にたくさんの人々が関わったチームワークのたまものです。
  • 全てのJCPスペックリードとExpert Groupのメンバー
  • Java EEを構成する様々な参照実装の開発に関わった全ての人々
  • 様々なJava EE実装者
  • Java EEコミュニティ全体
  • そして、GlassFish自体を開発するOracleのチームや開発インフラストラクチャの管理チームのような、裏方作業をしてくれたその他の多くの人々
全ての皆さんに対し称賛を!Java EE 8は、みなさんの仕事と献身がなければ不可能でした。
ご存じのようにこれは、Eclipse Foundation、Red Hat、IBMなどのコミュニティとともにEclipse Foundationの後援の下、開発を移行することによりJava EEをさらにオープンにする取り組みの端緒にすぎません(詳細は以下のリンクをどうぞ )。
Opening Up Java EE
https://blogs.oracle.com/theaquarium/opening-up-java-ee
https://orablogs-jp.blogspot.jp/2017/08/opening-up-java-ee.html
Opening Up Java EE - An Update
https://blogs.oracle.com/theaquarium/opening-up-ee-update
https://orablogs-jp.blogspot.jp/2017/09/opening-up-java-ee-update.html
現在多くの議論が続いており、追加の詳細をJavaOneでご紹介できればと思っています。
Opening Up Java EE: Panel Discussion with Oracle, IBM, Red Hat, and the Eclipse Foundation [CON8030]
https://events.rainfocus.com/catalog/oracle/oow17/catalogjavaone17?search=CON8030&showEnrolled=false
本日、Java SE 9も一般提供されました。前述の通り、GlassFish 5.0はJava SE 8の新機能を活用しています。Eclipse Foundationへの移行に伴って我々の眼前にたくさんの作業があるにもかかわらず、現在、将来のGlassFish 5リリースでJava SE 9の動作保証をすることを目指しています。引き続きこの領域での将来の開発について投稿していく予定です。

全てのOracle Java EEチームを代表して、Davidより。

Resources


[Java] Convergence Of Oracle Java SE Embedded With Oracle JDK

原文はこちら。
https://blogs.oracle.com/java-platform-group/convergence-of-oracle-java-se-embedded-with-oracle-jdk

過去数年にわたり、OracleはOpenJDKコミュニティとJCPで、一般に言われるJava SE、特にOracle JDKをより小さなデバイスで動作するようサイズを小さくすることに取り組んできました。

最初の一手は、Java SE 8にCompact Profileを導入することでした。この機能は、Oracle Java SE 8 Embeddedで利用できます。
An Introduction to Java 8 Compact Profiles
https://blogs.oracle.com/jtc/an-introduction-to-java-8-compact-profiles
https://orablogs-jp.blogspot.jp/2013/08/an-introduction-to-java-8-compact.html
Java SE Embedded 8 Compact Profiles Overview
http://www.oracle.com/technetwork/java/embedded/resources/tech/compact-profiles-overview-2157132.html
つづいて、Jigsawプロジェクトを通してJava SE 9にモジュールシステムを導入することでした。jlinkという新しいツールを使うと、一連のユーザーが提供するモジュールとランタイムの依存関係をアセンブルし、アプリケーション実行に必要なJDK 9モジュールのみを含む、カスタムランタイムイメージに最適化することができます。
Project Jigsaw
http://openjdk.java.net/projects/jigsaw
JEP 282: jlink: The Java Linker
http://openjdk.java.net/jeps/282

この機能は、アプリケーションのランタイムフットプリントをコンパクトプロファイルよりもきめ細かく制御します。関心のある開発者は、この機能やその他の多くのJDK 9の機能を試し、OpenJDKコミュニティを通じて開発に貢献することができます。
JDK 9
http://jdk.java.net/9
JDK 9ではまた、Javaプラットフォームに対し、実験的な静的「Ahead of Time(AOT)」(JEP 295)という新機能も導入されています。この新しいコンパイルツールは、(時間の経過とともに)コンパクトで静的にリンクされたイメージの作成を容易にします。AOTは、Javaアプリケーションで必要とするランタイム・フットプリントの大幅な削減と、スタートアップ・パフォーマンスの大幅な向上を実現します。Oracleはこの新しいAOTコンパイラをOpenJDKコミュニティに提供しました。
JEP 295: Ahead-of-Time Compilation
http://openjdk.java.net/jeps/295
昨年Oracleは、JDK 9のために、32ビットおよび64ビットARMプラットフォームのHotSpotの統合ポートをOpenJDKコミュニティに提供しました。これは、OpenJDKの64ビットAArch64ポートプロジェクトを補完する、OpenJDKの既存の32ビットAArch32ポートプロジェクトの助けを借りて行われました。
AArch32 Port Project
http://openjdk.java.net/projects/aarch32-port/
AArch64 Port Project
http://openjdk.java.net/projects/aarch64-port/
大事なことを言い忘れていましたが、Oracleは、OpenJDK Mobile Projectを立ち上げ、iOS、Android、Windowsなどの一般的なモバイル・プラットフォームにJDKを移植することに注力しています。
関連するOracle Java SE Embeddedの移植を開始したことで、オープンソースのJava SE Embeddedコミュニティは、活気に満ちたオープンソースコミュニティの一端として、JDK 9の革新とコラボレーションを継続できるようになりました。
Mobile Project
http://openjdk.java.net/projects/mobile/
How to contribute
http://openjdk.java.net/contribute/
これに伴い、JDK 9以後、Oracleは「Oracle Java SE Embedded」という別のダウンロードを提供する予定はありません。つまり、Oracle Java SE 8 Embeddedは、「Oracle Java SE Embedded」製品の最終リリースシリーズです。この理由は、JDK 9の新機能のおかげで、別の製品として用意する必要がなくなったからです。

[Cloud] Announcing Oracle Cloud Infrastructure Modules for the Terraform Modules Registry

原文はこちら。
https://blogs.oracle.com/developers/announcing-oracle-cloud-infrastructure-modules-for-the-terraform-modules-registry

新たに発表されたHashiCorp Terraform Module Registryを使用して、OracleはOracle Cloud Infrastructure Classic(OPC)Provider用の検証済みモジュールの初期セットを提供しています。このモジュールは現在HashiCorpによる認定および互換性テストを受けています。
HashiCorp Terraform Module Registry
https://www.hashicorp.com/blog/hashicorp-terraform-module-registry/
Terraform Moduleは、Terraform構成の再利用可能なパーツを内蔵パッケージとしてカプセル化しています。Terraform Moduleを使用すると、インフラストラクチャ構成全体の再利用性と保守性の両方を向上することができ、テスト済みの構成パターンを一貫して使用できます。
Module Configuration
https://www.terraform.io/docs/configuration/modules.html
Terraform Module Registryを使用すると、Oracle Cloud Infrastructureの検証済みモジュールとコミュニティ・モジュールの両方を簡単に検出して使用することができます。以下で、Oracle Cloud Infrastructure Classic(OPC)モジュールの初版を2個組み合わせた構成で使用する方法を詳しく見ていきます。

Oracle Cloud Infrastructure Classic Modules

Terraform Providerは、Compute、Networking、Storageサービスなどを構成およびプロビジョニングするために使用される個々のリソースをきめ細かく制御することができます。
Resource Configuration
https://www.terraform.io/docs/configuration/resources.html
インフラストラクチャ構成を完全に制御するにあたり、個々のリソースを宣言することは非常に強力な方法ではありますが、例えばComputeインスタンスの起動やネットワークの作成、セキュリティ・ルールの宣言といった、具体的な構成要件を満たすために、何度もリソースのグループを共通パターンで使う必要があります。

Compute Instance Module

opc_compute_instanceリソースは、デフォルトで、ローカルブートストレージを持つ一時インスタンスを作成しますが、永続インスタンスを作成するには、追加のopc_compute_storage_volumeリソースをブートボリューム用に宣言し、作成時にインスタンスにアタッチする必要があります。
compute-instanceモジュールを使うと、ストレージリソースならびにインスタンスリソースの両方の作成が1個の再利用可能なコンポーネントに結合され、複数のリソースの定義と関連付けの詳細が、単一の簡潔なインスタンス定義にカプセル化されます。
Terraform Module for creating Oracle Cloud Infrastructure OPC Compute instances
https://registry.terraform.io/modules/oracle/compute-instance/opc
では、最も簡単なcompute-instanceモジュール定義から始めましょう。
module "persistent-instance1" {
  source           = "oracle/compute-instance/opc"
  instance_name    = "instance1"
  instance_shape   = "oc3"
}
この最小限の設定で、通常明示的に定義が必要な多くの属性に対して、共通のデフォルト値や派生値を使用して、永続ブータブルストレージボリュームを持つインスタンスを作成します。
では、この最小設定と同等の、全て宣言した基本リソースセットと比べてみましょう。
resource "opc_compute_instance" "persistent-instance1" {
  name                = "instance1"
  hostname            = "instance1"
  label               = "instance1"
  shape               = "oc3"

  networking_info {
    index          = 0
    shared_network = true
  }

  storage {
    index  = 1
    volume = "${opc_compute_storage_volume.boot-volume.name}"
  }

  boot_order = [1]
}

resource "opc_compute_storage_volume" "boot-volume" {
  name             = "instance1-boot"
  description      = "$instance1 boot storage volume "
  image_list       = "/oracle/public/OL_7.2_UEKR4_x86_64"
  image_list_entry = 1
  size             = 12
  bootable         = true
}

IP Networks Modules

2個目のモジュールはip-networksモジュールです。 このヘルパーモジュールは、共有IPネットワーク交換(IP Network Exchange)を使って、相互に接続された複数のIPネットワークの作成を簡素化します。これは、異なるアプリケーションデプロイメント層に使用される複数のサブネットを宣言する場合に便利です。
Terraform Module for creating Oracle Cloud Infrastructure OPC IP Neworks
https://registry.terraform.io/modules/oracle/ip-networks/opc
このip-networksモジュールはIPネットワーク交換の名前、サブネットと対応するサブネットワーク名のリストを使ってインスタンス化します。
module "ip-networks" {
    source = "oracle/ip-networks/opc"
    ip_exchange_name = "example"
    subnet_cidrs = [ "192.168.1.0/24", "192.168.2.0/24", "192.168.3.0/24" ]
    subnet_names = [ "network1", "network2", "network3" ]
}
ここでも、同じ構成の同等の基本リソース定義を見てみましょう。
resource "opc_compute_ip_network_exchange" "exchange" {
  name = "example"
}

resource "opc_compute_ip_network" "network" {
  name                = "network1"
  ip_address_prefix   = "192.168.1.0/24"
  ip_network_exchange = "${opc_compute_ip_network_exchange.exchange.name}"
}

resource "opc_compute_ip_network" "network" {
  name                = "network2"
  ip_address_prefix   = "192.168.2.0/24"
  ip_network_exchange = "${opc_compute_ip_network_exchange.exchange.name}"
}

resource "opc_compute_ip_network" "network" {
  name                = "network3"
  ip_address_prefix   = "192.168.3.0/24"
  ip_network_exchange = "${opc_compute_ip_network_exchange.exchange.name}"
}

Using Modules as part of a complete configuration

今度は、上記の2つのモジュールを組み合わせを見てみましょう。 相互接続されたIPネットワークのサブネットワークを2個作成し、各サブネットに1つのCompute インスタンスを作成します。構成を完了するために追加のリソースが2つ作成され、実行中のインスタンスにアクセスできるようにSSHキーが作成されます。 パブリックIPアドレス予約はインスタンスの1つに関連付けられます。
module "ip-networks" {
    source = "oracle/ip-networks/opc"
    ip_exchange_name = "example"
    subnet_cidrs = [ "192.168.1.0/24", "192.168.2.0/24" ]
    subnet_names = [ "network1", "network2" ]
}

module "persistent-instance1" {
  source           = "oracle/compute-instance/opc"
  instance_name    = "instance1"
  instance_shape   = "oc3"
  ip_network       = "${module.ip-networks.ip_networks[0]}"
  ssh_key          = "${opc_compute_ssh_key.ssh-key.name}"
}

module "persistent-instance2" {
  source           = "oracle/compute-instance/opc"
  instance_name    = "instance1"
  instance_shape   = "oc3"
  ip_network       = "${module.ip-networks.ip_networks[1]}"
  ip_reservation   = "${opc_compute_ip_address_reservation.ip-reservation.name}"
  ssh_key          = "${opc_compute_ssh_key.ssh-key.name}"
}

resource "opc_compute_ssh_key" "ssh-key" {
  name    = "example-sshkey1"
  key     = "${file("~/.ssh/id_rsa.pub")}"
  enabled = true
}

resource "opc_compute_ip_address_reservation" "ip-reservation" {
  name            = "example-ip-reservation"
  ip_address_pool = "public-ippool"
}
この例では、IPネットワーク上にインスタンスを作成しているため、opc_compute_ip_address_reservationでパブリックIP予約を使っていますが、IPネットワークを使わない場合、共有ネットワークインターフェースでIP予約を作成するために、opc_compute_ip_reservationを使う必要があります。

Summary

どのようなプログラミング言語でも、再利用可能なコード要素にカプセル化し分解することで、開発と保守が大幅に省力化できますが、この原則は、宣言的および機能的な構造を使用してクラウドインフラストラクチャを定義できる、infrastructure-as-codeの領域でも等しく適用されます。Terraform ModuleとTerraform Modules Repositoryを使うと、ベンダーが提供するモジュールとコミュニティが提供するモジュールの両方を信頼性の高い方法で採用して、素早く初期設定を作成できます。

More Information

Related Content