[Java] GlassFish 5 Promoted Build 7

原文はこちら。
https://blogs.oracle.com/theaquarium/glassfish-5-promoted-build-7

今週のGlassFish promoted build b07が以下のURLからダウンロード可能になっています。
here
今週はコンポーネントのアップデートを発表できるものはありませんが、変更のほとんどは全てのファイルの著作権の修正にあてられています。またマイナーな開発者のテスト関連の変更もありました。
Git Revision Issue Description
b211a72 21683 The value of "Group List" in "Realm User" cannot be deleted by GUI
4f148d8 - Prevent deletion of default JDBC resource
ea27715 - Update copyright plugin to 1.42 and update the copyright template for all files in the workspace
全体として、GitHubへ移行後、43のプルリクエストを受け入れ、いい感じで進んでいます。是非Issue Trackerに課題を引き続き挙げていってください。
GlassFishのIssue Tracker
https://github.com/javaee/glassfish/issues
質問の投稿は、以下のDiscussion Groupをサブスクライブしてください。
Discussion group related to GlassFish
https://javaee.groups.io/g/glassfish

[Linux] Introducing UEK4 and DTrace on Oracle Linux for SPARC

原文はこちら。
https://blogs.oracle.com/wim/introducing-uek4-and-dtrace-on-oracle-linux-for-sparc

約2ヶ月前、Oracle Linux 6およびOracle Linux 7 for SPARCの最初のバージョンをリリースしました。これはExadata SL6で使われているOracle Linuxと同一バージョンです。OL6はT4、T5、T7システムにインストールされていましたがS7チップ/システムはまだサポートしていませんでした。このバージョンには、M7チップの機能(DAX、ADI、暗号など)やSPARCにとってよりよいコードを生成をサポートするためのgcc最適化、memcpy()などのような関数の重要な最適化をサポートが含まれています。
また、管理ドメイン(ゲストドメインは以前実施しました)としてのLinuxのサポートも導入しました。それゆえ、vdiskserver、vswitch、仮想コンソールドライバを使う管理ドメインとしてLinuxを利用可能な最初のリリースでした。このリリースではUEK2 (2.6.39) のカーネルをベースにしていました。
開発チームはこれまでに数多くのことに熱心に取り組んできました。
  • 引き続きアップストリームのLinuxと連携し、gcc/glibc/binutilsの開発でのすべてのコード変更を取り込むよう提出しています。多くのSPARCの機能はすでにアップストリームのLinuxのコードにコミットされており、多くは現在保留中もしくは作業中です。
  • 作業には、UEK2/SPARC/Exadataの多くの機能をUEK4に取り込むのと同時にアップストリーム/メインラインのLinuxの開発に貢献が含まれています。
  • カーネルならびにユーザー空間の両方でのパフォーマンスの向上(特にglibc、gcc)
本日、UEK4 QU4 (4.1.12-94.3.2)を含むISOイメージのアップデートをリリースしました。ISOイメージのアップデートの主要な理由は、S7チップおよびS7ベースのサーバのサポートを追加するためです。このISOイメージにはUEK2に対する数多くの改善が含まれており、DTraceのサポートも追加しました。
最新バージョンのISOは以下のURLからダウンロードできます。
Oracle Linux for SPARC for downloads
http://www.oracle.com/technetwork/server-storage/linux/downloads/oracle-linux-sparc-3665558.html
DTraceユーティリティのダウンロードはこちら。
Oracle Linux DTrace
http://www.oracle.com/technetwork/server-storage/linux/downloads/linux-dtrace-2800968.html
より多くの機能を追加しているので、カーネルを更新し、新しいバージョンのgcc(6.xなど)を持つSPARC版Oracle Linux software collectionの新しいバージョンを公開する予定です。
gccgo、valgrind、nodeなどに対する作業も継続しています。yumリポジトリでは5000ほどのパッケージがご利用いただけます。
Oracle Linux Yum Server
http://yum.oracle.com/
是非ダウンロードしてお試しください。

[Database] ODPI-C 2.0.0-beta.4 released: More & Better-er

原文はこちら。
https://blogs.oracle.com/opal/odpi-c-200-beta4-released

ODPI-C 2.0.0-beta.4がリリースされました。GitHubからご利用いただけます。
ODPI-C version 2.0.0-beta.4
https://github.com/oracle/odpi
ODPI-CはOracle Call Interface (OCI) の抽象化レイヤーです。
Oracle Call Interface OCI
http://www.oracle.com/technetwork/database/features/oci/index-090945.html
このリリースでは、ユーザーからのフィードバックに基づき、継続的なテストの結果として段階的な改善が行われています。ベストプラクティスの数字の取り扱いや、DB接続を使わずにODPI-Cの可変構造を使用する方法について議論がありました。その結果、少々調整が必要になりました。すべての変更を知りたい方は、リリースノートを参照してください。
Release notes - Version 2.0.0-beta.4 (May 24, 2017)
https://oracle.github.io/odpi/doc/releasenotes.html#version-2-0-0-beta-4-may-24-2017
このリリースのハイライトは次のとおりです。
  • LOB、BINARY_FLOAT、BINARY_DOUBLE、NCHARおよびNVARCHAR2型の値を含むコレクション内のオブジェクトまたは要素値の属性の取得/設定がサポートされました。
  • ディスクI/Oを回避するために一時LOBキャッシングを有効にしました。
  • 列のメタデータが値が64ビット整数に収まることを示す場合、デフォルトのネイティブ・タイプをDPI_ORACLE_TYPE_INT64に変更しました。
  • 関数dpiStmt_defineValue()が追加されました。この関数は、アプリケーションが変数を作成せずにフェッチに使用するデータ型を指定することができます。
さらに、コンパイル中に新しいマクロDPI_DEBUG_LEVELを有効にして、ロギングおよびトレース情報を表示することができます。個人的には、この初期ベータ段階でDPI_DEBUG_LEVEL_FREESに対して設定して、リソース処理に間違いがないかどうかを確認しました。

ベータフェーズを速やかに終えたいと思っているので、引き続きODPI-Cについてフィードバックをお寄せください。

より大きなプロジェクトでのODPI-Cの利用を確認したい場合には、このODPI-Cの新リリースを使うようになったPython cx_Oracle 6.0b2をチェックしてください。
Python cx_Oracle 6.0b2
https://github.com/oracle/python-cx_Oracle/releases/tag/6.0b2

[Database] Python cx_Oracle 6.0b2 is available

原文はこちら。
https://blogs.oracle.com/opal/python-cx_oracle-60b2-is-available

Python cx_Oracle 6.0b2がリリースされました。GitHubおよびPyPIからご利用いただけます。
Oracle Database Programming Interface for Drivers and Applications
https://github.com/oracle/odpicx_Oracle 6.0b2 - Python interface to Oracle
https://pypi.python.org/pypi/cx_Oracle/6.0b2
Anthony Tuiningaがいくつかの改良と修正を含むPython cx_Oracle 6.0b2をリリースしました。
PyPIからインストールするには、以下をコマンドを使用します。
python -m pip install cx_Oracle --pre
"--pre" オプションを使わない場合、代わりに現在のProductionバージョン(cx_Oracle 5.3)を取得します。
以前のcx_Oracleをアップグレードする場合は以下のコマンドを実行します。
python -m pip install cx_Oracle --upgrade --pre
リリースノートにはこのリリースでの詳細が全て列挙されています。
Release notes
6.x releases
Version 6.0 beta 2 (May 2017)
http://cx-oracle.readthedocs.io/en/latest/releasenotes.html#version-6-0-beta-2-may-2017
あまり明確ではありませんが、cx_Oracleは基礎となるODPI-C抽象化レイヤーに対する改善のメリットを享受しています。具体的には、cx_Oracle 6.0b2では、一時的なLOBに対してキャッシングが有効になっていたり、LOB、BINARY_FLOAT、BINARY_DOUBLE、NCHAR、NVARCHAR2の値を持つコレクションのオブジェクトの属性や要素値のgetter/setterをサポートします。
ODPI-C's 2.0.0-beta.4 documentation
Release Notes Version 2.0.0-beta.4 (May 24, 2017)
https://oracle.github.io/odpi/doc/releasenotes.html#version-2-0-0-beta-4-may-24-2017
AnthonyはまもなくRelease Candidateフェーズに進むものと思われますので、是非引き続きフィードバックをお願いします。
Issue Tracker
https://github.com/oracle/python-cx_Oracle/issues
cx_Oracle 6では、インストール時にOracle Clientは不要(実行時のみ必要)ということをお忘れ無く。

[Coherence, Docker] Coherence Clusters on Docker Swarm

原文はこちら。
https://blogs.oracle.com/developers/coherence-clusters-on-docker-swarm

Javaのインメモリ・データグリッドは、通常数多くのJVMでクラスタを構成し、データをクラスタ間に分散させるという共通の機能を有しています。JVMが起動時のクラスタ探索にあたっては、マルチキャストを使いますが、これはDockerコンテナ内では機能しません。そのため、インメモリ・データグリッド製品は別の探索機構にフォールバックする必要があります。通常、これはクラスタメンバー・アドレスのリストを手作業で注入したり、別の探索機構を参照したりします。

Oracle CoherenceはDocker Storeからご利用いただけます。
Oracle Coherence
http://store.docker.com/images/oracle-coherence-12c
Docker SwarmでOracle Coherenceクラスタを実行する場合、以前よりもずっとクラスタの探索が簡単になっています。起動時にアドレスリストを挿入する必要がありますが、これはクラスタの開始前にクラスタメンバーのコンテナのIPアドレスのすべてまたは一部を知っている、という点に頼っています。Dockerでは、実行時にコンテナの固定IPアドレスを指定できるため実現できます。とはいえ、アドレス割り当てを気にする必要がないとより柔軟なのは明らかです。

クラスタメンバーが起動すると、クラスタメンバー内のアドレスを検索する必要がありますが、これはクラスタIPアドレスを保持する外部データソースに頼っています。これを実現するDockerサービスの検出に利用可能なアプリケーションがありますが、インフラストラクチャに追加するもう1つの可動要素です。シンプルなアプリケーション・インフラストラクチャであるほど、変なことにならなくなって、より簡単になります。

以前のOracle Coherence on Dockerのブログエントリでは、Coherenceメンバーが複数のDockerホストでクラスタを構成できるようにするために、ホスト・ネットワーキングまたはオーバーレイ・ネットワークを使用する必要がある、と記載しました。
Oracle Coherence on Docker
http://thegridman.com/coherence/oracle-coherence-on-docker/
マルチキャストが可能なホスト・ネットワーキングは最も簡単な解決策ですが、常に利用できるとは限りません。確かに現代のクラウド環境では使えないことがあります。これにより、オーバーレイネットワークを使うことになるわけですが、それに伴い、サービス発見の問題が発生します。しかし、DockerのSwarm Modeが導入されたことで、Oracle Coherenceを使用するコンテナのクラスタ構成がずっと簡単になりました。
Swarm mode overview
https://docs.docker.com/engine/swarm/

Coherence Cluster Discovery

既に触れたように、CoherenceはJVMが起動時にクラスタメンバを探索するための複数の方法を有しています。最も簡単な方法は、マルチキャストですが、これは常に利用可能というわけではなく、確かにDockerコンテナ内では利用できません。もう一つの方法は、well-know-addressingです。これは1個以上のIPアドレスのリストをJVMに渡すというもので、コンテナ内部ではこの方法を使う必要があります。

Well known addressは2方法で提供できます。Coherenceの操作構成ファイル(通常はオーバーライドファイルと呼ばれます)を使って管理します。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
          xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
 
    <cluster-config>
        <unicast-listener>
            <well-known-addresses>
              … wka configuration …
            </well-known-addresses>
        </unicast-listener>
    </cluster-config>
</coherence>
well-known-addresses要素の内容は、アドレスの提供方法によって異なり、2種類の方法があります。
一つは、カスタムアドレスプロバイダという、com.tangosol.net.AddressProviderを実装したもので、通常は3rdパーティソースからアドレスリストを取得し、必要に応じてそれらを返すカスタムクラスを使います。例えば、私が関わっていたプロジェクトでは、コンテナ管理にMarathon/Mesosを使用しており、このプロジェクトでは、Coherenceクラスタ内のコンテナのIPアドレスを取得するためにMarathon APIに照会するカスタムアドレスプロバイダを使用しています。このアドレスプロバイダの構成例は以下の通りです。
<cluster-config>
        <unicast-listener>
            <well-known-addresses>
                <address-provider>
                    <!-- Specify AddressProvider class name -->
                    <class-name>com.oracle.coherence.clustering.MarathonAddressProvider</class-name>
                </address-provider>
            </well-known-addresses>
        </unicast-listener>
    </cluster-config>
もう一つの方法は、アドレスを直接overridesファイルに書き込むことです。
<cluster-config>
        <unicast-listener>
            <well-known-addresses>
                <!-- Specify one or more IP addresses or host names where the cluster members are running -->
                <address>foo.oracle.com</address>
                <address>bar.oracle.com</address>
            </well-known-addresses>
        </unicast-listener>
    </cluster-config>
実際、Oracle CoherenceのWKA構成では、単一のアドレスがSystemプロパティを介して渡されるように設定されています。 以下はその設定例です。
<cluster-config>
        <unicast-listener>
            <well-known-addresses>
                <address system-property="coherence.wka"></address>
            </well-known-addresses>
        </unicast-listener>
    </cluster-config>
これはつまり単一のWKAの値を実行時に設定でき、この値を使ってクラスタメンバを特定するため、最初のクラスタメンバを当該サーバで起動する必要があります。具体的には以下のような感じです。
$ java -cp ${COHERENCE_HOME}/lib/coherence.jar \
  -Dcoherence.wka=foo.oracle.com \
  com.tangosol.net.DefaultCacheServer
この場合、各Coherenceメンバはfoo.oracle.com上のメンバを探し、このメンバを使って残るクラスタメンバを探します。
これはつまり、Coherenceに設定を追加せずに、すぐにクラスタを起動でき、一つのアドレスを渡すことができ、このアドレスを持つサーバ上のCoherenceメンバは、新しいJVMクラスタメンバが他のメンバを探し始める際に連絡をうけとる、ということです。当該サーバーに問題がある場合を除いて、これでOKです。例えば、クラッシュした場合にはWKAリストが無効なIPアドレスを指しているため、新しいクラスタメンバを開始できません。これを回避するには、通常、構成ファイルに複数のWKAアドレスを指定します。

Coherence Clusters on Docker Swarm

DockerにSwarm Modeとサービスが導入されたことで、結果としてコンテナ内からDNSを使用してサービスのメンバを検索できるようになりました。Oracle CoherenceがWKA名を使用する方法の1つは、これらの名前がDNSを介して複数のアドレスに解決された場合、CoherenceはそれらのすべてのアドレスをWKAリスト用に使用します。したがって、デフォルトのCoherence構成で単一のホスト名しか指定できない上記の場合、DNSを使用してそのホスト名を複数のサーバーに解決できるのであれば、これは制限とはなり得ません。これこそが、Docker Swarm Modeを使ってサービスを構成するコンテナのためにできることです。DockerでサービスとしてCoherenceクラスタを起動すると、特別なホスト名を使用して、そのサービスを構成するコンテナのIPアドレスをすべて検索できます。Dockerのドキュメントには、Swarm Mode Networkingの仕組みの説明があります。
Attach services to an overlay network
https://docs.docker.com/engine/swarm/networking/
上記URLから、Oracle Coherenceにとって重要なことは、全てのサービスはDNS名を有しており、この名前を使ってIPアドレスの検索に利用できる、ということです。Dockerのドキュメントのサンプルをおさらいすると、どれほど簡単かがわかります。

まず、サービスが利用するオーバーレイ・ネットワークを作成します。
$ docker network create \
  --driver overlay \
  --subnet 10.0.9.0/24 \
  my-network
基本的なコンテナを持つシンプルなサービスを起動します。
$ docker service create \
  --name my-busybox \
  --network my-network \
  busybox \
  sleep 3000
サービスをリストアップすると、my-busyboxサービスが実行中であることがわかるはずです。
$ docker service ls
ID            NAME        MODE        REPLICAS  IMAGE
tpsqpgwh423c  my-busybox  replicated  1/1       busy box
サービスを3個のコンテナにスケールアップすることができます。
$ docker service scale my-busybox=3
my-busybox scaled to 3
実行中のコンテナをリストアップすると、my-busyboxサービスを構成するコンテナが確認できるはずです。
$ docker ps --format "{{.ID}}: {{.Names}}"
443d3ea90e62: my-busybox.2.mx5nq93n8w7z80ndfkqd1zmhj
81893dfcdaf8: my-busybox.3.nd4lp1z7iliys8wsplusxkq0a
19d4fdded3dd: my-busybox.1.xewffdq29h7pomx8jhw9xib14
では、nslookupをコンテナ内で使ってtasks.my-busyboxのアドレスを検索します(訳注:nslookupでよいのかどうかはさておき…)
$ docker exec my-busybox.1.xewffdq29h7pomx8jhw9xib14 nslookup tasks.my-busybox
Server:    127.0.0.11
Address 1: 127.0.0.11
 
Name:      tasks.my-busybox
Address 1: 10.0.9.4 my-busybox.2.mx5nq93n8w7z80ndfkqd1zmhj.my-network
Address 2: 10.0.9.5 my-busybox.3.nd4lp1z7iliys8wsplusxkq0a.my-network
Address 3: 10.0.9.3 19d4fdded3dd
各コンテナに1つずつ、3個のアドレスが返っていることがわかります。Docker Storeから利用可能なCoherence Dockerイメージをそのまま使用し、まったく同じコンセプトでOracle Coherenceクラスタを作成できます。ところで、このイメージはOracle LinuxとオフィシャルなOracle Server JREイメージの上に構築されています。
Put Your Containers on a Diet with Oracle Linux
https://blogs.oracle.com/developers/put-your-containers-on-a-diet-with-oracle-linux
Oracle Java 8 SE (Server JRE)
https://store.docker.com/images/oracle-serverjre-8
コンテナエントリポイントとして実行されるイメージ内のシェルスクリプトは、デフォルトでストレージが有効化されたcom.tangosol.net.DefaultCacheServerインスタンスを開始します。シェルスクリプトを使うと、環境変数を設定することで種々のパラメータを渡すこともできます。その1つが、well-known-addressの値を設定するCOH_WKAです。
$ docker pull store/oracle/coherence:12.2.1.2
$ docker service create  --name coh-cluster \
  --network my-network \  
  -e COH_WKA=tasks.coh-cluster \
  store/oracle/coherence:12.2.1.2
サービス起動時にサイズを指定していなかったので、coh-clusterサービスは1個のメンバだけで動作しています。docker psコマンドを実行すると、コンテナを1個のみ表示します。
$ docker ps --format "{{.ID}}: {{.Names}}"
c4917b7c9b9b: coh-cluster.1.tpz4kby4nwpxi0n89herpfsyp
コンテナのログを見ると、1個のメンバを持つ新たなクラスタがあることがわかります。
$ docker logs coh-cluster.1.tpz4kby4nwpxi0n89herpfsyp
ログは以下のような感じで出力されます。
WellKnownAddressList(
  10.0.9.3
  )
MasterMemberSet(
  ThisMember=Member(Id=1, Timestamp=2017-04-14 11:12:04.36, Address=10.0.9.3:36273, MachineId=1586, 
    Location=machine:c4917b7c9b9b,process:1, Role=CoherenceServer)
  OldestMember=Member(Id=1, Timestamp=2017-04-14 11:12:04.36, Address=10.0.9.3:36273, MachineId=1586, 
    Location=machine:c4917b7c9b9b,process:1, Role=CoherenceServer)
  ActualMemberSet=MemberSet(Size=1
    Member(Id=1, Timestamp=2017-04-14 11:12:04.36, Address=10.0.9.3:36273, MachineId=1586, 
      Location=machine:c4917b7c9b9b,process:1, Role=CoherenceServer)
    )
  MemberId|ServiceJoined|MemberState|Version
    1|2017-04-14 11:12:04.36|JOINED|12.2.1.1.0
  RecycleMillis=1200000
  RecycleSet=MemberSet(Size=0
    )
  )
ホスト名 task.coh-service という1個のメンバを持つWKAリストによって単一のコンテナを名前解決したことがわかります。

では、サービスをスケールし、複数のクラスタメンバを持つようにしましょう。
$ docker service scale coh-cluster=3
coh-cluster scaled to 3
この場合、3個のコンテナがあるはずです。
$ docker ps --format "{{.ID}}: {{.Names}}"
50db2c5b76ed: coh-cluster.2.r79i1q03q0umup2b8geovc6m0
8f4159035dd1: coh-cluster.3.i8wdao099zbwa5tdeslx9y2bz
c4917b7c9b9b: coh-cluster.1.tpz4kby4nwpxi0n89herpfsyp
3個目のコンテナのログを見てみると…
$ docker logs coh-cluster.3.i8wdao099zbwa5tdeslx9y2bz
3個のメンバがクラスタに存在しています。
WellKnownAddressList(
  10.0.9.3
  10.0.9.4
  10.0.9.5
  )
MasterMemberSet(
  ThisMember=Member(Id=2, Timestamp=2017-04-14 11:18:01.087, Address=10.0.9.5:42521, MachineId=686, 
    Location=machine:8f4159035dd1,process:1, Role=CoherenceServer)
  OldestMember=Member(Id=1, Timestamp=2017-04-14 11:12:04.36, Address=10.0.9.3:36273, MachineId=1586, 
    Location=machine:c4917b7c9b9b,process:1, Role=CoherenceServer)
  ActualMemberSet=MemberSet(Size=2
    Member(Id=1, Timestamp=2017-04-14 11:12:04.36, Address=10.0.9.3:36273, MachineId=1586, 
      Location=machine:c4917b7c9b9b,process:1, Role=CoherenceServer)
    Member(Id=2, Timestamp=2017-04-14 11:18:00.072, Address=10.0.9.4:39874, MachineId=231, 
      Location=machine:df36591c7ab6,process:1, Role=CoherenceServer)
    Member(Id=3, Timestamp=2017-04-14 11:18:01.087, Address=10.0.9.5:42521, MachineId=686, 
      Location=machine:8f4159035dd1,process:1, Role=CoherenceServer)
  )
  MemberId|ServiceJoined|MemberState|Version
    1|2017-04-14 11:12:04.36|JOINED|12.2.1.1.0,
    2|2017-04-14 11:18:00.072|JOINED|12.2.1.1.0,
    3|2017-04-14 11:18:01.087|JOINED|12.2.1.1.0
  RecycleMillis=1200000
  RecycleSet=MemberSet(Size=0
    )
  )
WKAリストに3つのアドレスがすべて含まれていることがわかります。そんなわけで、Swamを使ってCoherenceクラスタを拡張・縮小することができ、Swamの組み込みDNSのおかげで、CoherenceのWKAはうまく機能します。Docker Storeにあるセットアップ手順には、種々の設定やオプションを使い、Oracle CoherenceのDockerイメージを実行することに関する詳細記述があります。

Container Cloud Serviceを使って、Oracle Cloud PlatformでDockerやCoherenceを試すことができます。
Oracle Container Cloud Service
https://cloud.oracle.com/ja_JP/container
以下のURLにアクセスしてアカウントを取得し、300ドルの無料クレジットを取得してください(訳注:日本はこのエントリ執筆時点では無料クレジットの対象外です)。
トライアルページ
https://cloud.oracle.com/ja_JP/tryit

[Java] Java SE support for Docker CPU and memory limits

原文はこちら。
https://blogs.oracle.com/java-platform-group/java-se-support-for-docker-cpu-and-memory-limits

複数のOpenJDKプロジェクトにコントリビュートしてくれているCharlie Huntがこのようなすばらしいエントリを書いてくれました。とても感謝しています。
Charlie Hunt
http://openjdk.java.net/census#huntch 
Alpine LinuxにJDKのポートを提供するプロジェクトであるOpenJDK Project Portolaを発表したブログのフォローアップとして、Java SEの機能強化がなされました。
Official Docker Image for Oracle Java and the OpenJDK Roadmap for Containers
https://blogs.oracle.com/developers/official-docker-image-for-oracle-java-and-the-openjdk-roadmap-for-containers
[Docker, Java] Official Docker Image for Oracle Java and the OpenJDK Roadmap for Containers
https://orablogs-jp.blogspot.jp/2017/05/official-docker-image-for-oracle-java.html
Portola Project
http://openjdk.java.net/projects/portola/
OpenJDK
http://openjdk.java.net/
Alpine Linux
https://alpinelinux.org/
これはDockerとAlpine Linuxのスローガン「Small、Simple、Secure」にも合致します。今回言及するのは以下の2個です。
  • Docker CPUとメモリ制限のサポート
  • Project Jigsawのjlink。このツールを使って、アプリケーションが利用もしくは必要とするモジュールベースの最小限のJREを作成することができます(jlinkについては今後このエントリで紹介予定です)。
    Project Jigsaw
    http://openjdk.java.net/projects/jigsaw/
    JEP 282: jlink: The Java Linker
    http://openjdk.java.net/jeps/282
Oracle Server JREのDockerイメージはDocker Storeから利用いただけます。
Oracle Java 8 SE (Server JRE)
https://store.docker.com/images/oracle-serverjre-8

Java SE support for Docker CPU and memory limits

JavaアプリケーションでDockerのCPUとメモリの制限を使用してきた人にとって、いくつかの課題がありました。特にCPUの制限は、JVMがGCスレッド数とJITコンパイラスレッド数を内部で透過的に設定するため、課題となっていましたが、これらの値をコマンドラインオプションの-XX:ParallelGCThreads-XX:CICompilerCountで明示的に設定することができます。メモリ制限については、JVMコマンド行オプション-Xmxを使用して、最大Javaヒープ・サイズを明示的に設定することもできます。しかしながら、前述のJVMコマンドラインオプションを指定せず、Java SE 8u121以前のバージョンを使うJavaアプリケーションがDockerコンテナ上で動作する場合、GCスレッド数やJITコンパイラスレッド数、使用する最大Javaヒープサイズを透過的に決定する際に、JVMはDockerが動作するホストのCPUやメモリの構成を使います。

Java SE 8u131およびJDK 9以降、DockerのCPU制限に関してJVMは透過的にDockerを認識しています。つまり、-XX:ParalllelGCThreadsまたは-XX:CICompilerCountがコマンドラインオプションとして指定されていない場合、JVMはDocker CPU制限を、JVMがシステム上で認識するCPUの数として適用します。そしてJVMは、DockerのCPU制限として設定されてる個数のCPUが載っているベアメタルシステム上で動作しているかのように、GCスレッド数とJITコンパイラスレッド数を調整します。-XX:ParallelGCThreadsまたは-XX:CICompilerCountがJVMコマンドラインオプションで指定されていて、DockerのCPU制限が指定されている場合、JVMは-XX:ParallelGCThreadsおよび-XX:CICompilerCountの値を使用します。

Dockerのメモリ制限について、最大Javaヒープの透過的な設定に対する作業がもうすこし必要です。-Xmxを使って最大Javaヒープサイズを設定していない場合に、JVMに対しDockerのメモリ制限を認知するよう指示するには、次の2個のコマンドラインオプションが必要です。
-XX:+UnlockExperimentalVMOptions
-XX:+UseCGroupMemoryLimitForHeap
将来のリリースでDockerメモリ制限の透過的な認知を目標としているため、-XX:+UnlockExperimentalVMOptions が必要です。これら2個のJVMコマンドラインオプションを使い、 -Xmx を指定しない場合には、JVMはLinux cgroupの設定(Dockerコンテナがメモリ制限の設定のために利用)を見て、透過的に最大Javaヒープサイズを設定します。参考までに、DockerコンテナもまたCPU制限のためにcgroupsの設定を使います。

Java SE 8u131およびJDK 9でのこれらの2個の変更で、DockerでのJavaの実行体験の改善が期待されます。
8u131 Update Release Notes
http://www.oracle.com/technetwork/java/javase/8u131-relnotes-3565278.html
JDK 9
http://openjdk.java.net/projects/jdk9/

これらの機能強化の作業は両方ともOpenJDKでトラッキングされています。

[Java, Cloud] JOnsen, Java Day Tokyo, Oracle Code, and JJUG CCC

皆様いかがお過ごしでしょうか。先週はJava Weekでしたね。
先週(厳密には12日から20日まで)はタイトルに記載した4イベントに参加(そのうち3イベントに登壇)することができ、非常に刺激を受けました。セッションならびにイベントに参加いただいた皆様には厚く御礼申し上げます。

JOnsen (12-14, May, 2017)

伊豆半島の下田で開催された、第1回JOnsen。
他の方がいろいろコメントされていると思うので、詳細は割愛しますが、面白い取り組みだと思います。日本と海外の違いがわかったり、日本と海外で同じ悩みを持っていたり、といろいろな気付きがあり、興味深いものでした。来年の開催も期待しましょう(もし来年開催するとなれば、なんとなく裏方の仕事をやることになるのでは、という気がしています)。JOnsenについては以下のURLからどうぞ。
Java Unconference at a Japanese Onsen
http://jonsen.jp/

Java Day Tokyo 2017 (17, May, 2017)

トピックはCDI 2.0。既にほぼ仕様は決まっていて、2年前に上妻さんがまとめてらっしゃる内容からの変更はあまりない、という状況でしたが、直前に全EGによって承認されたのでよかったですね(あのJSR 376とは違います)。セッションでは、Java SEサポートとCDIコンテナ起動のAPIを使ったデモをご紹介しましたが、CDIってデモ映えしないので、ちょっとわかりづらかったかもしれません。。。
スライドはイベントのページから公開されますが、こちらにも貼り付けておきます。


Oracle Code Tokyo 2017 (18, May, 2017)

基調講演の1コマになぜか登壇することになりました。ここでちょびっと喋ったことで、社内にも中の人が誰か認知されたという。。。

# 実を言うと、このコマで紹介したAPI Platform Cloud Serviceを含む、iPaaS (Integration PaaS) と呼ばれる類いのサービスが当方の主担当なのです。

API Managementは様々なお歴々が語ってらっしゃるので、当方があの短い10分程度でさらに何かすごい話ができるわけもないのですが、お伝えしたかったのは、
"MicroservicesのAPIの公開"という狭い観点ではなく、"APIの公開"という観点で考えると、すなわち情報公開なので、当該情報の管理だけでなく、情報へのアクセス管理も必要であり、その管理のしくみはプロセス化しておく必要がある
ということでした。なので、基調講演に参加された皆様に上記の内容が伝われば成功かなー、と考えています。特に社外公開する場合には、SaaSプロバイダとして情報を提供することに他ならないわけですから、より一層の管理が必要ですよねぇ。
なお、このコマでお話した内容は、昨年のOpen WorldでのAPI Platformのセッションや、今年の2月のAPI Platform & Identity Managementのイベントでお話した内容と同一です。スライドが公開されるかどうかはわからないのですが、もし公開されるようなら、イベントページからダウンロードできるはずです。

JJUG CCC 2017 Spring (20, May, 2017)

元々20分枠で申し込んだのですが、なぜか45分枠に格上げ(?)されました。しかもGraalという、ニッチかつマニアックな内容だったので、数名の方に聞いてもらえたらいいかなー、と思っていたのですが、大幅に上回る人数の方々に聞いていただきありがとうございました(最前列に鎮座なさっていたきつねさんやじゅくちょーさんからの目が一番厳しかったのは言うまでもありません)。
Graalの話はどこまで詳細に踏み込むべきか思案していたため、今回はあえて難しくならないレベルに抑えました。スライドはこちらからどうぞ。


このセッションの部屋を担当されていたまめぴかさんの落胆のTweetが涙を誘うものでしたので、ここにUpしておきます。



休憩時間中に久保田さんに、懇親会でかずひらさんやうらがみさん、キクタローさんにご挨拶できたのはよかったです。みなさまありがとうございました。当面イベント登壇はないので、しばらく地道にステルス性能を向上させる所存でございます。今後ともどうぞご贔屓に。

[Java] GlassFish 5 Promoted Build 6

原文はこちら。
https://blogs.oracle.com/theaquarium/glassfish-5-promoted-build-6

Java.netの移行が原因で数週間GlassFishのpromotionプロセスを一時停止しなければなりませんでしたが、Nightly Buildsは移行後すぐに利用できるようになっています。
GlassFish 5 nightly builds
http://download.oracle.com/glassfish/5.0/nightly/index.html
(Java.net移行に伴い)以下の新しいホームに変わったことにご注意ください。
GlassFish - The Open Source Java EE Reference Implementation
https://javaee.github.io/glassfish/
GlassFishのソースコードは以下にあります。
GlassFish Server
https://github.com/javaee/glassfish
最新のGlassFish 5.0-b06 promoted buildは以下からご利用頂けます。
GlassFish 5 promoted builds
http://download.oracle.com/glassfish/5.0/promoted/index.html
このビルドの詳細は以下の通りです。

Component Update:

  • Grizzly 2.4.0-beta2

Bug Fixes:

Issue ID
 Summary
20684
 Visual issue in the Batch Admin UI
21693
 Rename install directory to 'glassfish5'
21702
 Update Java EE version in master pom.xml to EE8
21714
 Warning related core.jar bundle not started in time of startup

ちょっとしたことですが重要な変更として、インストールディレクトリがglassfish4からglassfish5に変わっています。ご自身のスクリプトをアップデートしてこの変更を反映するようにしてください。

是非お試しいただいて、何か問題があればGitHubのissue trackerにレポートしてください。
glassfish issue tracker
https://github.com/javaee/glassfish/issues

[Java, Cloud] Introducing Application Cache Client Java SDK for Oracle Cloud

原文はこちら。
https://blogs.oracle.com/developers/introducing-application-cache-client-java-sdk-for-oracle-cloud

Oracle Application Container Cloud (ACCS) のApplication Cacheは(名前が示す通り)アプリケーションのキャッシュ機能を提供します。
Application Container Cloud Service
https://cloud.oracle.com/ja_JP/acc
Mike LehmannによるCaching with Oracle Application Container Cloudと題したエントリで説明した通り、Cacheに使いたいメモリのサイズと基本的な開発・検証環境用非HAキャッシュもしくは本番環境用の信頼性の高いキャッシュを指定するだけで、適切なインフラストラクチャを自動的にプロビジョニングします。
Caching with Oracle Application Container Cloud
https://blogs.oracle.com/developers/caching-with-oracle-application-container-cloud

Under the Hood

ACCS Application Cacheは高パフォーマンスかつスケーラブルなOracle Coherenceインメモリデータグリッド上に構築されています。Oracle Coherenceはトレーディングやその他メモリやレイテンシの要求に厳しいアプリケーションを長年支えているコンポーネントです。
Oracle Coherence
http://www.oracle.com/technetwork/jp/middleware/coherence/overview/index.html
ACCS Application CacheではCoherence実装は公開されていませんが、インメモリ・データグリッドクラウドサービスを必要とする場合には、心配する必要はありません。Oracleがまさにそれをやっています。この間、Coherenceチームは継続して革新を続けています。例えば、以下の動画はOracle CodeでのBrian Oliverによる分散ストリームに関するセッションです。


この動画では背後にあるすばらしいエンジンについて説明していますが、メイントピックに戻ることにしましょう。

Java Caching

Application Cacheは、最初は言語に依存しないREST APIでリリースされましたが、Javaアプリケーションが容易にキャッシュを利用できるよう、新たにネイティブJavaクライアントライブラリが作成されました。Javaからのキャッシュ使用を簡素化するのに加え、キャッシュとクライアント間の効率的なデータ転送を実現するためのgRPCのオプションもライブラリに追加されています。
gRPC
http://www.grpc.io/
クライアントライブラリはオープンソースフレームワークで、GitHubでホストされており、バイナリは、Maven Centralから直接ダウンロードすることも利用することもできます。
Application Container Cloud Service Application Cache Java API
https://github.com/oracle/accs-caching-java-sdk
Javaクライアントライブラリを紹介するため、簡単な例で使用方法の基礎を説明し、そのサンプルコードをApplication Container Cloudにデプロイする方法を紹介します。

Background

読者の皆さんが、Application Cacheの機能をご存知であることを前提として、今回はJavaクライアントライブラリに焦点を当てています。ACCS Application Cacheをご存知ない場合は、以下のリソースで詳細を説明しています。

Cache API Basics

数ステップの簡単な手順でJavaクライアントライブラリを使ってキャッシュにアクセスすることができます。
  1. 名前(MyCacheなど)と目的のトランスポートプロトコルをサポートするポート(gRPCの場合は1444、RESTの場合は8080)をURLとして指定し、以前に作成したApplication Cache用のSessionProviderを作成します。RESTを使用する場合、キャッシュのホスト名の後に "/ ccs" が続きます。
    SessionProvider sessionProvider = new RemoteSessionProvider("http://MyCache:1444");
  2. 指定したポートで利用可能なトランスポートを指定し、SessionProviderからSessionを取得します。
    Session cacheSession = sessionProvider.createSession(Transport.grpc());
  3. SessionからCacheオブジェクトを取得します。キャッシュがない場合には作成されます。
    Cache<Users> users = cacheSession.getCache("users");

Using A Cache

キャッシュは(Key-Valueペアの)アイテムのget、put、replace、removeをサポートします。 各操作はJava Sparkフレームワークを使う非常にシンプルなUser管理RESTサービスを提供するサンプルに含まれています。
Spark Framework: A tiny Java web framework
http://sparkjava.com/
サンプルのバックエンドでは、 UserService がUserの create/update/delete 操作を提供しており、この操作はApplication Cache Javaクライアントライブラリを使って実装されています。例えば、UserオブジェクトをそのIDを使ってusersキャッシュに入れるコードは以下のようです。
users.put(user.getId(),user);
キャッシュからの削除は users.remove(id) だけで、とても簡単ですが、キャッシュはローカルにないので、remove APIはパフォーマンス最適化オプションを提供しています。JDKの java.util.Map インターフェースは(もしあれば)削除されたオブジェクトとしてremove()メソッドの戻り値を定義していますが、キャッシュを扱う場合、単にオブジェクトを削除したいだけで、キャッシュから削除されたオブジェクトをクライアントに返すコストをかけたくないかもしれません。そんなわけで、Javaクライアントライブラリの Cache.remove() メソッドでは、削除されたオブジェクトを返すかどうかを指定します。デフォルトでは、削除されたオブジェクトを返さず、メソッドはNullを返します。以下は削除されたオブジェクトを必要とするためにReturn.OLD_VALUEオプションを指定しています。
User user = users.remove(id, Return.OLD_VALUE);
Cache.replace() でユーザーを更新する場合のように、remove()メソッドはネットワーク越しに通信するデータ量を制御する機能を提供しています。今回の場合、置換対照のオブジェクトの詳細に興味がないので、デフォルトの挙動のまま、指定したキーに対する以前のオブジェクトを転送しないようにしているので、nullが返ります。
users.replace(id, user);

この図はApplication Container Cloudにデプロイした際のサンプルの構造を図示したものです。クライアントはUserアプリケーションにRESTでアクセスすると、ACCSロードバランサーによってルーティングされます。この図で、アプリケーションを2インスタンスにスケールアウトしています。'MyCache' Application Cache もまた3インスタンスにスケールアウトして、高可用性構成を提供し、全データがメモリ上で安全であることを保証します。任意の1個のキャッシュインスタンスがなくなった場合でも、データの消失はありません。Userアプリケーションはステートレスであり、Javaクライアントライブラリを使って、ACCS内部オーバーレイ・ネットワーク上のキャッシュと対話します。様々なワークロードを処理するためにUserアプリケーションインスタンスの個数がスケールアップしたりスケールダウンしたりしても、データは引き続き安全にキャッシュに格納されます。

Deploying the Example

ではこれらを踏まえて、サンプルをデプロイし、試すことにしましょう。
  1. 1GBのストレージを持つ、MyCacheというApplication CacheをBasicタイプで作成します。この構成では、キャッシュデータのメモリの安全性を保証しませんが、サンプルのためにはこれでOKです。以下のチュートリアルの "Creating a Cache" の手順に従って作成します。
    Oracle® Cloud Using Caches in Oracle Application Container Cloud Service
    Creating a Cache Service
    http://docs.oracle.com/en/cloud/paas/app-container-cloud/cache/creating-cache-service.html
  2. このサンプルのGitリポジトリをローカルに複製します。
  3. サンプルをビルドして、デプロイ可能なアプリケーション・アーカイブを生成します。複製したGitリポジトリのcache-client-examples/appcache-example フォルダ内で、mvn clean packageを実行します。このコマンドを実行すると、”fat”なJarファイルが生成されます。このファイルにはアプリケーションコードと、Javaクライアントライブラリを含む、アプリケーションが依存している全てのライブラリが含まれています。Mavenビルドによって、ACCSアプリケーションアーカイブファイルも生成されます。このファイルにはfat Jarファイルがmanifest.jsonファイルと共にパッケージされています。
  4. ACCSサービスコンソールに移動し、”Create Application”をクリックして、Java SEをランタイムとして選択します。
  5. アプリケーション名を付けて、”Upload”を選択し、Mavenが生成したtargetフォルダから appcache-example-1.0-dist.zip アプリケーションアーカイブを選択します。
  6. MyCache を関連付けられたApplication Cacheとして選択します。Application Cacheが未作成もしくは現在プロビジョニング中である場合には、キャッシュの選択ドロップダウンリストが現れないことにご注意ください。deployement.jsonファイルでサービスバインディングを使うことでApplication Cacheとアプリケーションの関連付けをすることもできます。
    Oracle® Cloud Using Caches in Oracle Application Container Cloud Service
    Creating Metadata Files
    http://docs.oracle.com/en/cloud/paas/app-container-cloud/dvcjv/creating-meta-data-files.html
  7. 'Create' をクリックして、アプリケーションアーカイブをアップロードし、サンプルのインスタンスをデプロイします。これでおしまいです。
Webコンソールではなく、コマンドラインで操作したい場合には、ACCS REST APIをcURLで使って、アプリケーションのライフサイクルを完全に管理することもできます。
REST API for Managing Applications
http://docs.oracle.com/en/cloud/paas/app-container-cloud/apcsr/index.html 

Using the Example

アプリケーションを実行したら、そのURLをApplicationsリストならびにアプリケーションの詳細ページで把握できます。デプロイされたアプリケーションを試すために、このURLが必要です。

Creating a User

単純化するため、cURLを使ってデプロイ済みのサンプルと対話することにします。Userを作成するためには、POSTを実行する必要があります。UserControllerクラスのPOSTエンドポイントは以下のようです。
post("/users", (req, res) -> userService.createUser(
        req.queryParams("name"),
        req.queryParams("email")
), json());
これから、nameemailという2個のクエリパラメータを渡す必要があることがわかります。ターミナルから、ご自身のアプリケーションのURLを使って、以下のように実行してください。
$ curl -i -X POST https://CacheDemo-paas104.apaas.us2.oraclecloud.com/users?name=mark\&email=twain@riverboat.org
実行すると、作成され、キャッシュに配置されたUserオブジェクトがJSONデータを伴い200で返ってきます。
HTTP/1.1 200 OK
Server: Jetty(9.3.z-SNAPSHOT)
Date: Mon, 01 May 2017 20:18:15 GMT
Content-type: application/json Via: 1.1 net-apaasotd
Proxy-agent: Oracle-Traffic-Director/11.1.1.9
Transfer-encoding: chunked
{
  "id":"92e7d5f0-6919-4f72-9f85-e8b01dedc770",
  "name":"mark",
  "email":"twain@riverboat.org"
}
作成の成功を確認するため、POSTの結果返ってきたidを使ってユーザーに対するGETを実行することができます。
$ curl -i -X GET https://CacheDemo-paas104.apaas.us2.oraclecloud.com/users/92e7d5f0-6919-4f72-9f85-e8b01dedc770

HTTP/1.1 200 OK
Server: Jetty(9.3.z-SNAPSHOT)
Date: Mon, 01 May 2017 20:18:50 GMT
Content-type: application/json
Via: 1.1 net-apaasotd
Proxy-agent: Oracle-Traffic-Director/11.1.1.9
Transfer-encoding: chunked
{
  "id":"92e7d5f0-6919-4f72-9f85-e8b01dedc770",
  "name":"mark",
  "email":"twain@riverboat.org"
}
いい感じですね。ユーザーがキャッシュにあります。

Updating a User

作成したユーザーの名前と電子メールを更新するには、以下のように(作成したユーザーのIDに置き換えて)実行してください(これは簡単な例ですので、あまり洗練されていません)。
$ curl -i -X PUT https://CacheDemo-paas104.apaas.us2.oraclecloud.com/users/92e7d5f0-6919-4f72-9f85-e8b01dedc770?name=luke\&email=luke@rebellion.org
200が返ってきて、更新されたユーザーが表示されます。
HTTP/1.1 200 OK
Server: Jetty(9.3.z-SNAPSHOT)
Date: Mon, 01 May 2017 20:21:04 GMT
Content-type: application/json
Via: 1.1 net-apaasotd
Proxy-agent: Oracle-Traffic-Director/11.1.1.9
Transfer-encoding: chunked

{
  "id":"92e7d5f0-6919-4f72-9f85-e8b01dedc770",
  "name":"luke",
  "email":"luke@rebellion.org"
}

Deleting a User

キャッシュからユーザーをDELETE しましょう(削除されたUserオブジェクトが返ります)。
$ curl -i -X DELETE https://CacheDemo-paas104.apaas.us2.oraclecloud.com/users/92e7d5f0-6919-4f72-9f85-e8b01dedc770

HTTP/1.1 200 OK
Server: Jetty(9.3.z-SNAPSHOT)
Date: Mon, 01 May 2017 20:23:07 GMT
Content-type: application/json
Via: 1.1 net-apaasotd
Proxy-agent: Oracle-Traffic-Director/11.1.1.9
Transfer-encoding: chunked

{
  "id":"92e7d5f0-6919-4f72-9f85-e8b01dedc770",
  "name":"luke",
  "email":"luke@rebellion.org"
}
削除を確認するため、UserをGETしましょう。
$ curl -i -X GET https://CacheDemo-paas104.apaas.us2.oraclecloud.com/users/92e7d5f0-6919-4f72-9f85-e8b01dedc770
404が返ってくるので、キャッシュにはもう存在しないことがわかります。
HTTP/1.1 404 Not Found
Server: Jetty(9.3.z-SNAPSHOT)
Date: Mon, 01 May 2017 20:23:12 GMT
Content-type: application/json
Via: 1.1 net-apaasotd
Proxy-agent: Oracle-Traffic-Director/11.1.1.9
Transfer-encoding: chunked

{
  "message":"No user with id \u002792e7d5f0-6919-4f72-9f85-e8b01dedc770\u0027 found"
}

Developing Locally

Application Cacheを使うアプリケーションの開発、テスト、デバッグを容易にするため、JavaキャッシュクライアントライブラリはLocalSessionをサポートしています。ACCSにデプロイする際に利用するRemoteSessionと全く同じAPIを提供していますが、インプロセスで実行します。LocalSessionを使うLocalUserServiceクラスの例をご覧ください。LocalMainクラスを実行すると、リモートの共有キャッシュではなく、ローカルのインプロセスキャッシュでサンプルアプリケーションを開始できます。お手軽ですね。

Obtaining the Application Cache Java Client Library

Javaキャッシュクライアントライブラリを入手する方法は複数ありますので、お好きな方法でどうぞ。
  1. 一つ目は、Maven Centralを使う方法です。依存性を解決するため、pom.xmlに以下を追加します。
    <dependency>
        <groupId>com.oracle.cloud.caching</groupId>
        <artifactId>cache-client-api</artifactId>
        <version>1.0.0</version>
    </dependency>
  2. 2番目は、Oracle Technology NetworkのCloud Downloadページから入手する方法です。
    Oracle Cloud Downloads
    http://www.oracle.com/technetwork/topics/cloud/downloads/index.html
    Jarファイル、javadoc、ソースが入ったZipファイルをダウンロードできます。
    Application Container Cloud Service Downloads
    http://www.oracle.com/technetwork/topics/cloud/downloads/app-cloud-service-3707850.html
  3. 最後に、クライアントライブラリのソースが格納されているGitHubからソースを入手することができます。
    Application Container Cloud Service Application Cache Java API
    https://github.com/oracle/accs-caching-java-sdk

Acknowledgements

今回のサンプルは、Michael ScharhagがJava Sparkフレームワークを紹介したブログ記事のコードに基づいています。元のコードはApache 2.0ライセンスに基づいており、今回かなりの変更を加えています。
mscharhag/blog-examples is licensed under the Apache License 2.0
https://github.com/mscharhag/blog-examples/blob/master/LICENSE
特に、元のインメモリUser HashMapをACCS Application Cacheに置き換えました。Michaelのブログエントリにオリジナルのエントリとそれに関連するコードが掲載されています。
Building a simple RESTful API with Spark
http://www.mscharhag.com/java/building-rest-api-with-spark

[Cloud] Announcing Built-in Terraform Provider for Oracle Compute Cloud

原文はこちら。
https://blogs.oracle.com/developers/announcing-built-in-terraform-provider-for-oracle-compute-cloud

Terraform release 0.9.4以後、Oracle Public Cloud ServiceのビルトインTerraformプロバイダにより、Oracle Compute Cloudはフルサポートされています。

What is Terraform?

HashiCorp Terraform とは、クラウド基盤や関連するリソースのプロビジョニングのためのオープンソースのオーケストレーションツールです。
Terraform by HashiCorp
https://terraform.io/
所望のインフラストラクチャ状態を表す構成ファイルをTerraformが処理すると、必要な変更をターゲット環境に適用し、構成されたリソースを作成および更新します。 "infrastructure-as-code" ということで、Terraformを使うと、DevOpsのプラクティスとCI/CDの自動化に容易に組み込み可能で繰り返し可能なプロビジョニングが可能になります。
Terraformは幅広いTerraformプロバイダを通じて、複数のインフラストラクチャやサービスのプロビジョニングをサポートします。Prior to Terraform 0.9.4より前は、外部プロバイダ・プラグインとしてOracle Compute Cloudをサポートしていました。が、Terraform release 0.9.4で、ビルトイン・プロバイダとしてOracle Compute Cloudは完全にサポートされ、主要なTerraformディストリビューションに含まれています。

Getting Started

Terraformは直感的で使いやすいツールです。以下の手順は開始プロセスについて説明しています。まず、以下のURLから最新のTerraformをダウンロードしてください。
Download Terraform
https://www.terraform.io/downloads.html
バージョンが0.9.4以降であることを確認しましょう(訳注:2017/05/22現在、0.9.5です)。
$ terraform version
Terraform v0.9.4
Terraformの初心者ということであれば、一般的なintroductionを一読して主要なコンセプトを理解することをお勧めします。
Introduction to Terraform
https://www.terraform.io/intro/index.html
必要なリソース構成を宣言するためにTerraform .tf ファイルを作成することから始めていきます。構成は複数の .tfモジュールファイルにまたがることも可能ですが、今回の例では1個のmain.tfファイルだけを作成することにします。
main.tfの最初のアイテムは、必要な認証属性を持つプロバイダの宣言です。Oracle Compute CloudリソースはOPC(Oracle Public Cloud)プロバイダに含まれています。Oracle CloudのCloud APIやCLIを使っている場合、これらの認証属性はよくご存知でしょう。
provider "opc" {
  identity_domain = "mydomain"
  endpoint        = "https://api-z27.compute.us6.oraclecloud.com/"
  user            = "user.name@example.com"
  password        = "Pa$$w0rd"
}
RESTエンドポイントURLはOracle Compute Cloudコンソールにあります。ご自身のアイデンティティ・ドメインで複数のサイトが利用可能である場合、所望のサイトのための正しいエンドポイントURLを使う必要があります。それではリソースを追加しましょう。opc_compute_instanceリソースは指定されたイメージおよびシェイプでコンピュート・インスタンスを立ち上げます。
resource "opc_compute_instance" "instance1" {
  name = "example-instance1"
  shape = "oc3"
  image_list = "/oracle/public/OL_7.2_UEKR3_x86_64"
}
この時点でterraform設定を適用してインスタンスを作成することもできますが、その前にいくつかの追加設定を追加して、インスタンスにパブリックIPアドレス付きでプロビジョニングし、SSH経由でインスタンスにログインできるようにしましょう。opc_compute_ssh_keyリソースでは新しいSSH公開鍵を作成し、opc_compute_ip_reservationではパブリックIPアドレス予約を作成します。networking_info設定ブロックでは、インスタンスのネットワーキングインターフェイス属性を設定します。
以下は今回作成したmain.tfです。
provider "opc" {
  identity_domain = "mydomain"
  endpoint        = "https://api-z27.compute.us6.oraclecloud.com/"
  user            = "user.name@example.com"
  password        = "Pa$$w0rd"
}

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

resource "opc_compute_instance" "instance1" {
  name = "example-instance1"
  shape = "oc3"
  image_list = "/oracle/public/OL_7.2_UEKR3_x86_64"
  ssh_keys = [ "${opc_compute_ssh_key.sshkey1.name}" ]
  networking_info {
    index = 0
    shared_network = true
    nat = ["${opc_compute_ip_reservation.ipreservation1.name}"]
  }
}

resource "opc_compute_ip_reservation" "ipreservation1" {
  name = "example-ipreservation1"
  parent_pool = "/oracle/public/ippool"
  permanent = true
}

output "public_ip" {
  value = "${opc_compute_ip_reservation.ipreservation1.ip}"
} 
構成ファイル内のリソース定義の順序は関係ありません。Terraformは自動的に作成するリソースの順序を依存関係に基づいて決定します。他にもこの構成で興味深い点があります。
  • $ {}形式の属性値は、他のリソースの属性を参照するためにTerraformの補間構文(interpolation syntax)を使用しています。
    interpolation syntax
    https://www.terraform.io/docs/configuration/interpolation.html
  • SSH鍵属性では、 ${file()} という補間関数(interporation function)を使い、SSH公開鍵コンテンツをファイルから読みこんでいます。
    Built-in Functions
    https://www.terraform.io/docs/configuration/interpolation.html#built-in-functions
    必要に応じて、ローカルのssh鍵ファイルを指すようにパスを更新するか、属性文字列全体をssh公開鍵の内容で置き換えます。
  • ssh_keys属性は、opc_compute_ssh_keyリソース定義からSSH鍵名を参照しています。手作業で作成され、terraformの構成で定義されていない既存のリソースを参照することもできます。たとえば、既に作成されているsshキーを参照する場合は、ssh_keys = ["my_sshkey"] を宣言します。また、SSH鍵を別のユーザーが作成した場合には、ssh_keys = ["/Compute-mydomain/john@example.com/johns_sshkey"]と宣言します。
  • networking_info ブロックでは、interface 0 (つまりeth0) が共有ネットワーク(Shared Network)上にあることを宣言し、パブリックIPプールからIPアドレス予約を割り当てるopc_compute_ip_reservationリソースを参照します。
  • output 定義は、プロビジョニング終了時に、割り当てられたパブリックIPアドレスを表示するためのものです。
ようやくリソースのプロビジョニングの準備が整いました。全て正しく定義されたことを確認し、実行してterraformがプロビジョニングする様子を確認しましょう。
$ terraform plan
+ opc_compute_instance.instance1
...
+ opc_compute_ip_reservation.ipreservation1
...
+ opc_compute_ssh_key.sshkey1
... 
Terraformは、作成済(+)、更新済(~)、または破棄済( - )リソースの詳細を出力します。今回の場合、3つのリソースが作成されています。すべてがうまくいっているようなので、リソースをプロビジョニングしてみましょう。
$ terraform apply
opc_compute_ip_reservation.ipreservation1: Creating...
...
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:
public_ip = 129.144.xx.126 

インスタンスがプロビジョニングされ、完全にブートされると、以下のようにssh経由でアクセスできます。
ssh opc@129.144.xx.126 -i ~/.ssh /id_rsa
ただし、明示的なセキュリティ・リストの関連付けを宣言していないため、Oracle Compute Cloudは、sshアクセスを可能にするデフォルトのセキュリティ・リストにインスタンスを自動的に関連付けます。
設定ファイルが変更されると、terraform plan/applyを再度実行すれば、配備されたリソースの作成や更新に必要な変更だけが計算され、ターゲットとする設定に一致させます。
最後に、この基本的なチュートリアルを完了するために、作成したすべてのリソースを削除してクリーンアップします。すべてのTerraformプロビジョニングされたリソースは、以下のコマンドを実行すれば削除できます。
$ terraform destroy
...
Destroy complete! Resources: 3 destroyed.

What Next?

ここまでの説明で基本的な例をご紹介しました。ストレージ、セキュリティ、およびネットワークの追加リソースを追加し、他のプロバイダやプロビジョナーと組み合わせて、複数のサービスにわたって完全なインフラストラクチャとアプリケーションのデプロイをオーケストレーションすることができます。
サポート対象リソースの完全なセットは、Oracle Public Cloud Providerのドキュメントを参照してください。
Oracle Public Cloud Provider
https://www.terraform.io/docs/providers/opc/index.html
より詳細なOracle Compute Cloud Terraform構成例については、以下のURLを参照してください。
Terraform examples for the built-in Oracle OPC Provider
https://github.com/oracle/terraform-provider-compute/tree/master/examples/opc
Oracle Bare Metal Cloud ServiceのTerraformのサポートは、現時点では外部プラグインとして利用できます。外部プラグインは以下から入手できます。
Terraform provider for Oracle Bare Metal Cloud Services
github.com/oracle/terraform-provider-baremetal

Get Involved

Oracle Public Cloud Terraform ProviderはOracleとHashiCorpで完全サポートされています。Oracle Public Cloud opcプロバイダの使用に関する質問や問題がありましたら、TerraformのGithubリポジトリに直接記録できます
hashicorp/terraform
https://github.com/hashicorp/terraform/issues
オープンソースプロジェクトとして、Terraform Oracle Public Cloudプロバイダへのコミュニティによるコントリビュートを歓迎しています。詳細については、Terraform寄稿ガイドラインを参照してください。
Contributing to Terraform
https://github.com/hashicorp/terraform/blob/master/.github/CONTRIBUTING.md

[Java] Comments at Public Review Ballot for JSR 376

Jigsawとして知られるJSR #376 JavaTM Platform Module Systemの、Public Preview Ballotでの各Executive Comitteeメンバーによる投票時のコメントをさらっと日本語化してみました(no commentのものは自明なので、日本語にしていません)。

原文はこちら。
https://jcp.org/en/jsr/results?id=5959

[Oracle]
On 2017-04-25 Oracle voted Yes with no comment.

[IBM]
On 2017-04-28 IBM voted No with the following comment:
IBMの投票は、現時点ではPublic Reviewステージを通過して、Proposed Final Draftステージに進むまでには至っていないという我々の立場を反映しています。JSR 376 Expert GroupおよびExpert Group以外の面々は、現在の仕様のPublic Review Draftについて、数多くの合理的な問題と懸案事項をいくつか提起しており、さらなる議論と解決が必要と考えています。我々は、メーリングリストに記載された問題に対処するため、Expert Groupの全メンバー間で継続して作業することを提唱します。IBMは、この仕様が次のステップに進む前に、Expert Group全体のコンセンサスをより深めたいと考えています。

[Intel]
On 2017-04-26 Intel Corp. voted Yes with no comment.

[NXP Semiconductors]
On 2017-04-26 NXP Semiconductors voted Yes with no comment.

[Keil, Werner]
On 2017-05-08 Keil, Werner voted No with the following comment:
IBMやその他のExpert GroupメンバーがNoを投票したその理由について理解しており、(例えばOSGiコミュニティや多数の人が使っているMavenやGradle、Antといったビルドシステムのコントリビュータから)多くの類似した懸念を聞いてきました。彼らが考えている懸念のほとんどに対し、未だにExpert GroupやSpec Leadから回答がないため、現時点ではこのJSRは時期尚早であると考えます。

[Hazelcast]
On 2017-05-03 Hazelcast voted No with the following comment:
我々は、Expert Group内部のコンセンサスが欠如していることは危険な兆候であり、すべての問題に対し、道筋が明確に示されたわけでもなければ、単一の観点から解決済みとなったわけでもないと考えています。 全体として、コミュニティと共に数多くの課題に対処したことで、状況はここ数ヶ月ですばらしい進歩を遂げたと認識していますが、Public Review Ballotに至るにはまだ早いと思われます。
さらに、人気のあるビルドツールの問題は、まだ解決していないように思います。 Executive Comittee(の役割)は、Javaエコシステムが害を受けないようにすることであり、現状では、JSR376はそのような準備ができているとは思えません。

[Red Hat]
On 2017-05-03 Red Hat voted No with the following comment:
Red HatはこのJSRに対してNOを投じています。Red Hatのミドルウェアチームやその他のExecutive CommitteeメンバーやJavaコミュニティのメンバーがパブリックかつ詳細に懸念点を言及しています。
Concerns Regarding Jigsaw(JSR-376, Java Platform Module System)
https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns
Jigsaw, EC Member Concerns - An analysis of the Jigsaw technology and its relationship to JPMS (JSR-376)
https://developer.jboss.org/servlet/JiveServlet/download/38-155022/JSR376.pdf
我々はまた、いくつかの懸念事項に対して良い反論を行った自社のOpenJDKチームと話し合った結果、最終的にはNOを投じることが正しい行動であると考えています。以前のExpert Groupの(メーリング)リストでの投票とコメントで、ミドルウェア/SE開発者の視点から、JigsawはJava EEのようなものが使用可能なモジュールシステムという本来の目標を達成していない、との見解を示しました。当初から、Expert Groupの最初の目標が変更され、JVMを完全にモジュール化するために利用されるモジュールシステムに焦点を当てようとしましたが、その結果、アーキテクチャや実装のアプローチが、Java SE開発者やJava EE開発者が使用するためのモジュールシステムたらしめることが困難になったと理解しています。残念なことに、Expert Groupの存続期間中、目標はJava開発者のためのモジュールシステムたらしめるようにスイッチバックしたようですが、以前の実装に関する決定は再検討されなかったか、もしくは変更できなかったようで、その結果、実装はJigsawへの期待に足るものではありませんでした。したがって、現在の実装が広範なJavaコミュニティに対する影響、特に既存のプロジェクトや製品だけでなく、さらにJava EEも含めた影響を懸念しています。私たちは、Expert Groupの(メーリング)リストでいくつかの問題を提起し、これらの事柄のいくつかを影響を最小限にとどめると考えられる方法で是正しようとしましたが、拒否されました。さらに、JVMにとって非常に劇的な一連の変更は、Expert Groupのコンセンサスが不十分であり、Javaコミュニティからの意見を受け取り、議論するオープン性にも欠けていると考えます。もっとあらゆる意見を評価し、同意を得ることに時間をかけすぎるべきではありませんが、(もう少し時間をかけることで)Javaエコシステム全体でがより受け入れられるものになると考えます。

[Goldman Sachs & Co.]
On 2017-05-05 Goldman Sachs & Co. voted Yes with no comment.

[Software AG]
On 2017-05-07 Software AG voted No with the following comment:
Software AGは、Expert Groupメンバー間での健全なコンセンサスの欠如を懸念しています。完全に意見が一致したり、未解決の問題をなくしたりすることは実現できないと理解してはいますが、より健全なコンセンサスは可能であると考えています。また、このようなコンセンサスにより、結果としてよりすぐれたJavaエコシステムになり、よりスムーズに業界がモジュール化されたJavaの世界に移行すると考えています。
Noを投票してはいますが、Spec LeadがExpert Group内でより健全なコンセンサスを形成するため、JCPプロセスの下で与えられた30日間を利用することを望みます。既存のソフトウェアのモジュール化された世界への移行パスと、既存の確立されたJavaプラクティスおよびビルドシステムとの共存について、特に注意を払っていただきたいと考えています(#ModuleNameInManifest、#CyclicDependences、#AutomaticModuleNames、#AvoidConcealedPackageConflicts、#MultiModuleJARs )。

将来の投票で、Expert Groupからの支持がより強いDraftに対して「Yes」を投票できることを楽しみにしています。

[Azul Systems, Inc.]
On 2017-05-07 Azul Systems, Inc. voted Yes with no comment.

[MicroDoc]
On 2017-05-08 MicroDoc voted Yes with no comment.

[Gemalto M2M GmbH]
On 2017-05-08 Gemalto M2M GmbH voted Yes with no comment.

[Credit Suisse]
On 2017-05-08 Credit Suisse voted No with the following comment:
Credit SuisseはExecutive CommitteeでJavaテクノロジーの顧客を代表しています。JSR 376については、大きな懸念点が2個(automatic modulesとreflection)あり、これらはこのJSRを簡単に採用することと、潜在的に矛盾するものです。Expert Groupに解決策が提示され、これらの重要なトピックについて合意を得るのにExpert Groupへ時間の猶予を与えることは有益である、と理解しています。

[SAP SE]
On 2017-05-08 SAP SE voted No with the following comment:
Groupのメンバーだけでなく、(そして特に)Spec Lead自身によってこれまで遂行された偉大な成果と作業を十分に認識しています。JPMSはJavaプラットフォームそのものをモジュール化する上でかなり良い具合ではありますが、仕様の最終承認前に対処し合意しなければならないJavaプラットフォーム外のライブラリやフレームワークに関し、すりあわせが必要な部分がまだ存在するように思います。
私たちは、OpenJDK内の "Project Jigsaw"という文脈の中で、JPMSのオープンな開発を認識していますが、それと同時に、OpenJDK JEPプロセスとJCP JSRプロセスの緊張が高まることを懸念しています。開発時およびこれまでのところ、JPMS/Jigsawの開発でどれが実装の詳細で、どれが標準仕様なのかが明確ではありませんでした。モジュールやランタイムイメージのバイナリ形式のような機能、jlinkツール、ハッシュやバージョンなどの新しいクラス属性は、標準化されていない実装の詳細の例です。
しかし、私たちが特に心配しているのは、Expert Group内での直接のコミュニケーションが不足していることです。このJSRが承認に必要な3分の2の過半数で承認されない場合には、Expert GroupおよびSpec Leadが定期的なミーティングのためにこの増えた30日を使い、残存する問題を整理し、新しい、より多くの持続可能で将来を見据えた提案を作成することを期待します。すべての懸念を救済することは不可能であると認識していますが、この数日でよい妥協(例えば、automatic modulesの問題など)がまだ可能であることが明確に示されたと思っています。そして、猶予期間を使って、再考投票に向けてよりよい仕様を提出することができると自信を持っています。

最後に、全てのメンバーおよびSpec Leadがテーブルに戻り、ブログとオープンレターでお互いを責めるのではなく、直接お互いにコミュニケーションを取ることを切に願います。

[London Java Community]
On 2017-05-08 London Java Community voted No with the following comment:
SAPからのコメントの通り、私たちは、Expert Groupメンバーだけでなく、(特に)Spec Lead自身によってこれまで成されてきたすばらしい成果を十分に認識しています。

LJCは、投票期間の開始時に提出された仕様に対し、Noと投票しています。14日間の投票期間中、#AutomaticModuleNamesのような非常に困難な問題についてはSpec LeadとExpert Groupによって合意に達し、大きく前進しました。しかし、いくつかの問題はまだ話し合いが行われており、エコシステムが、十分な深さ、十分な時間を費やして最新の仕様に基づいて実装したりテストする上で、新しいデザインの議論に十分な時間を費やしているとは言えません。具体的には、Eclipse ejcコンパイラやMavenにおける最新のAutomatic Module Namingのデザインなどです。

必要に応じて、Expert Group(およびエコシステム)がこれらの難しい仕様項目の議論や実装、テストを行うために少々時間を使ったバージョンで、30日以内にYesと投票できることを非常に楽しみにしています。確かに最後の14日間は、真逆の視点から始まったにも関わらず合意に達することができましたが、最後の障害を解決するためにもうちょっと時間が必要と考えています。必要であれば、30日以内にYesを投票できることを楽しみにしています。

[V2COM]
On 2017-05-08 V2COM voted Yes with the following comment:
V2COMは他のExecutive Committeeの懸念を共有していますが、全ての主要な懸念はこの投票と次回の投票の間に対処できると信じています。

[Grimstad, Ivar]
On 2017-05-08 Grimstad, Ivar voted No with the following comment:
投票期間の開始時に提出された仕様に対しNoと投票しています。14日間の投票期間中の議論はすばらしいものであり、この期間にSpec LeadとExpert Groupが成した進捗、特に、直近のAutomatic Module Namingに関する提案はすばらしいと思っています。

継続的な議論とこれらの変更が仕様に組み込まれ、再検討投票でYesと投票できることを楽しみにしています。

[Twitter, Inc.]
On 2017-05-08 Twitter, Inc. voted No with the following comment:
Java 9におけるJava Platform Module System(JPMS)の導入を、Javaプラットフォームへの望ましくて価値のある追加と認識しており、誕生後20年たってから、Javaのような成熟して広く使われている言語をモジュール化するという、非常に困難な作業に対しありがたく思っています。JSR Lead、Expert Group 、そして尽力された全ての人、そして実現するためのあらゆる努力に感謝しています。

私たちの主な関心事は、このJSRはJava開発者にとって破壊的であると判明し、その上究極的にはそのようなシステムに期待される利点を提供しない可能性が高い、という点です。このためにこの重要な技術が広範な採用されるまでに時間がかかる可能性を心配しています。JPMSが本来の目的をより包括的に達成するならば(特に、エクスポート対象外のPackage名の衝突は "non-interference(非干渉)"と "strong encapsulation(強力なカプセル化)"という目標とは相容れません)、Java開発者が今日抱える現実の課題(例えば、エクスポート対象外パッケージとして隠すことによって同じパッケージの複数のコピーを扱う)に対処できるでしょう。これにより、より多くの開発者がモジュール開発を迅速に採用できるようになります。

最後に、JSR LeadとExpert Groupメンバーの幅広いコンセンサスがこういった重要なJSRにとっては必要であると考えています。

[SouJava]
On 2017-05-08 SouJava voted Yes with the following comment:
SouJavaはJava Platform Module System仕様に対しYESを投票します。

他のメンバーのコメントの通り、チームによるこの作業に大きな成果があったことには同意します。しかし、Public Reviewに出てきた仕様はExpert Groupが同意しておらず、そのことへの不安によって、SouJava内の議論はNOを投票する方向になりました。
(しかしながら)ここ数週間のSpec Leadの動きの結果、全体的な意見が変わりました。問題解決への努力に感謝しています。

私たちは、Public Reviewに提出された仕様には不足がある、という、London Java Communityやその他の意見に同意します。 Spec Leadが、後に改良される初期リリースに重点を置くべきであることを理解しており、ツールの問題に関するいくつかの妥協を歓迎しています。

しかし、この仕様が独立した実装をサポートしていない場合にはより大きな問題です。独立した実装はJCPの第1の目的であり、状況が変わらない場合には、Yesを投票し続けるつもりはありません。

[Fujitsu Limited]
On 2017-05-08 Fujitsu Limited voted Yes with the following comment:
数多くの懸念はありますが、Expert Groupメンバーが次回の投票までに懸念事項を解決することを願っています。

[Eclipse Foundation, Inc]
On 2017-05-08 Eclipse Foundation, Inc voted No with the following comment:
Eclipse Foundationは、LJC(London Java Community)と同様、「投票開始時に提出された」仕様に「いいえ」と投票しています。Eclipse Foundationは、独立した非依存の実装が動作するように改訂された仕様を期待しています。最近の会話内容は非常に肯定的なものであり、Expoert Groupが正しい方向に向かっていると我々は感じています。しかし、投票を依頼されたDraftには、様々なメーリングリストにおける最近の会話で記載されているように、数多くの重大な欠陥が含まれています。これらの会話を完了して改訂案に含めることができれば、仕様が大幅に改善されると感じています。

[Hewlett Packard Enterprise]
On 2017-05-08 Hewlett Packard Enterprise voted No with the following comment:
Expert GroupやSpec Leadによる進捗は認識しています。ですが、Hewlett Packard Enterpriseは、Expert Groupがフィードバックに対処し、未解決の問題を解決し、アップデートされたDraftを提出できるようにすることを期待します。

[Tomitribe]
On 2017-05-08 Tomitribe voted No with the following comment:
TomitribeがNoを投票したのは、この仕様では実際にJCPプロセスを成功裏に通することが難しいのではないか、との懸念したからです。このJSRを次のステージに移行してFinal Approval Ballotで拒否された場合、Spec LeadとExpert Groupは30日以内にすべての問題を解決するか、仕様をJCPルールに従って永久に葬るかのいずれかを取る必要があります。

過去14日間の進捗状況を賞賛する他の有権者の心情を代弁します。Noを投票することで得た30日間の期間で、完璧な合意を得ることはできないとはいえ、大きな助けになると信じています。事態収拾のための時間です。過去2週間の変更により、最終投票に提示されるものがあまり明確ではないからです。

私たちは、この勢いのために重要な圧力を維持する点で、Exective ComitteeへのフィードバックとExective Comitteeからのフィードバックのための30日の猶予期間を選択したことにポジティブな見方をしています。JSR-299(CDI 1.0)は、Public Review BallotとFinal Approval Ballotの間に9ヶ月もかかった結果、Java EE 5は大幅にリリースが遅れました。ここでも同じことが起こるのは嫌です。 30日の期間はSpec Leadと本質的にExpert Groupに適用され、その後すぐに投票します。

Noの投票は拒絶反応のように見えるかもしれませんが、突き詰めていくと、時間のプレッシャーは引き続きあるものの、JSRから必要と思われるより大きなレベルの合意を得るための、最も支持的な投票であると信じています。

[Docker] Oracle Container Registry is available in Japan

4ヵ月ほど前に、以下のエントリを公開しました。
[Docker] MONDAY SPOTLIGHT:Announcing the Oracle Container Registry
https://orablogs-jp.blogspot.jp/2017/01/monday-spotlightannouncing-oracle.html
この当時は、一部の国からのアクセスのみ許可していましたが、ようやくその制限がなくなりました。以下のページにアクセスすると、下図のような画面がブラウザに表示されるはずです。
Oracle Container Registry
https://container-registry.oracle.com

で、サインインし、Oracle Standard Terms and Restrictionsに同意すると、以下の画面が現れます(日本語にも対応しています)。赤で隠した部分は、利用条件に同意した日時(UTC)です。この同意は8時間でタイムアウトしますので、ご注意ください。
2017/06/28追記
8時間の制限はなくなりました。Pullする前に一度利用条件を承諾すれば、以後尋ねられることはありません。

あとは必要なDockerイメージ(例えばデータベースやJava (Server JRE)など)をPullしてください。

Docker StoreからPullできるので何を今更、という言葉が聞こえてきそうですが、Oracle Container RegistryからPullしたイメージは、Pullしたイメージに含まれている製品を購入され、Premier Supportを契約されている場合はサポート対象です。対して、Docker StoreからPullしたイメージは、OTNライセンスによる利用許諾であって、当該製品を購入され、Premier Supportを契約されていたとしてもサポート対象ではありませんので、ご注意ください。

[Java] Java EE 8 - April recap

原文はこちら。
https://blogs.oracle.com/theaquarium/entry/java_ee_8_april_recap

少々遅れましたが、Java EE 8に関する四月のニュースをまとめておきます。

まずJava.netに関する重要なアップデートですが、Java.netはまもなく停止する予定です。全てのGlassFishの開発やJavaの開発に関するほとんどのコンテンツは、Java EE organizationが管理するGitHubに移行されています。
Java EE organization
https://github.com/javaee
今後、GitHubを使ってプロジェクトを進めていきます。うまくいけば、より多くのプロジェクトの参加が可能になるでしょう。Jerseyのようなプロジェクトや、JAX-RSのような仕様はすでにJava.netからGitHubにミラーリングされており、これらのリポジトリは当面変更されることはありません。
Jersey(GitHub)
https://github.com/jersey/jersey
JAX-RS API
https://github.com/jax-rs
Java.netのリポジトリとIssueのほとんどはGitHubに移行されていますが、プロジェクトのWebサイトの大半を更新するなど、やるべきことはまだあります。私たちは新しいメーリングリストへの最後の変更をしており、うまくいけば、すぐに詳細を共有できるはずです。最後に大事なことを言い忘れていましたが、このブログプラットフォームは新しい最新のプラットフォームに移行されます。

全体として、Java.netからGitHubへの移行に伴う作業は先月のGlassFish 5の作業にわずかに影響を与えましたが、これは長期的な利益のための短期間の苦労でした。4月中旬版のGlassFish 5のプロモートビルドをダウンロードできます。
GlassFish 5 Promoted Build
http://download.oracle.com/glassfish/5.0/promoted/index.html
種々のExpert Groupの進捗がこの移行によってそれほど影響を受けていないことは喜ばしいニュースです。

JavaServer Faces 2.3(JSR 372)は、JSON-P 1.1が最終承認投票を通過した際に、仕様の最終リリースを投稿しました。両方のEGのみなさん、おめでとうございます。
JSR-000372 JavaServerTM Faces 2.3 Specification (Final Release)
https://jcp.org/aboutJava/communityprocess/final/jsr372/index.html
JSR #374 JavaTM API for JSON Processing 1.1 Final Approval Ballot
https://jcp.org/en/jsr/results?id=5982
JSON-B 1.0(JSR 367)は現在Proposed Final Draftのフェーズですが、もう一つの仕様は最終承認投票に非常に近い状態にあります。
JSR-000367 Java API for JSON Binding (Proposed Final Draft)
https://jcp.org/aboutJava/communityprocess/pfd/jsr367/index.html
Servlet 4.0 (JSR 369) Expert Groupは現在Public Reviewのフェーズです。
JSR-000369 JavaTM Servlet 4.0 Specification (Close of Public Review: 20 May 2017)
https://jcp.org/aboutJava/communityprocess/pr/jsr369/index.html
Regarding Servlet 4およびより具体的にはJDK 8におけるTLSでのHTTP/2サポートについて、JDK 8でのALPNのサポートに関する説明があります。
[servlet-spec users] [jsr369-experts] Re: ALPN status: Java SE 9 and JDK 8
https://java.net/projects/servlet-spec/lists/users/archive/2017-04/message/43
JAX-RS 2.1 (JSR 370) Expert Groupの進捗は順調で、Public Reviewを投稿しました。
JSR-000370 JavaTM API for RESTful Web Services 2.1 (Close of Public Review: 20 May 2017)
https://jcp.org/aboutJava/communityprocess/pr/jsr370/index.html
是非ドラフト仕様をチェックして、フィードバックしてください。Santiago Pericas-Geertsen (JAX-RS 2.1 Co-Spec Lead) がDevoxx USでJAX-RS 2.1に関するセッションを実施しました。動画は以下からご覧いただけます。


この3月初旬のプレゼンテーション以後、プロバイダにおけるNon-blocking I/Oのサポートを仕様から外す決断をしたことをお伝えしておかねばなりません。
[jax-rs-spec users] Proposal to drop non-blocking I/O from JAX-RS 2.1
https://java.net/projects/jax-rs-spec/lists/users/archive/2017-04/message/0
いずれにせよ、SantiagoのセッションはJAX-RS 2.1の新しいAPI(SSE API、Reactive Client API)だけでなく、JAX-RSプロバイダにおけるNon-blocking I/Oのサポートの背後にある同期(およびその困難な課題)を理解する上でも興味深いものです。

Devoxx USでは、Java EE Security(JSR 375)のSpec LeadであるWill HopkinsがJava EE Securityの概要を説明しています。動画は以下からご覧いただけます。


Java EE Platform(JSR 366)Expert Groupから、このJSR (JSR 375)をWeb Profileにも含めることについて質問があがりました。
[javaee-spec users] [jsr366-experts] Java EE Security API
https://java.net/projects/javaee-spec/lists/users/archive/2017-04/message/0
非常に強い肯定的な意見が得られたので、(Full Profileだけでなく)Web Profileにも加えることが決定されました。これがJava EE 8仕様の2回目のEarly Draftに含まれるアップデートの一つで、Public Reviewとしてご覧いただけるようになっています。
JSR-000366 JavaTM Platform, Enterprise Edition 8 (Close of Public Review: 25 May 2017)
https://jcp.org/aboutJava/communityprocess/pr/jsr366/index.html
また、Linda De Michiel(JSR 366 Spec Lead)によるDevoxx USでのJava EE 8概要のプレゼンテーションもご覧ください。


CDI 2.0はFinal Approval Ballotのフェーズに到達し、結果を待っているところです。
JSR 365: Contexts and Dependency Injection for JavaTM 2.0
https://jcp.org/en/jsr/detail?id=365
もう一つ、John Ament(JSR 365 Expert Groupメンバー)による”CDI 2.0 New and Noteworthy”という、すばらしいDevoxx USでのセッションをご覧頂くことができます。


Red HatがリードするこのJSRについて説明している、Bean Validation 2.0(JSR 380)は現在Public Reviewのフェーズにあります。Devoxx USでのEmmanuel Bernard(BV 1.x Spec Lead)によるセッション”Bean Validation 2 overview”の動画が公開されています。


Java EE 8に向けてInterceptorsとJPAの2個のメンテナンスリリースが進んでいます。
[javaee-spec users] [jsr366-experts] Interceptors MR spec
https://java.net/projects/javaee-spec/lists/users/archive/2017-04/message/90
[jpa-spec users] JPA_SPEC-115: Add @Repeatable(containerClass.class)
https://java.net/projects/jpa-spec/lists/users/archive/2017-04/message/1

そして大事なことですが、Java EEから独立したMVC(JSR 371)が、2名のSpec Lead(Ivar GrimstadとChristian Katlepoth)によって動き出しました。JSRは安泰です。
JSR 371: Model-View-Controller (MVC 1.0) Specification
https://jcp.org/en/jsr/detail?id=371
[mvc-spec users] [jsr371-experts] Reinforcements on the spec lead side
https://java.net/projects/mvc-spec/lists/users/archive/2017-05/message/0
まとめると、Aprilは非常に忙しい月でしたが、今夏のJava EE 8の完成に向けてさらに一歩進んでいます!

[Docker, Cloud] Running Docker Store images on Container Cloud Service

原文はこちら。
https://blogs.oracle.com/developers/running-docker-store-images-on-container-cloud-service

Docker Storeで商用製品のDockerイメージをご利用いただけるとの発表をして以来、Oracle Container Cloud Serviceを使用してDocker StoreのイメージをPullしてDeployする方法に関する質問を何件か頂きました。これは非常に簡単で、たった5ステップでできます。試してみたい場合には、Oracle Cloudアカウントを今すぐ入手してください。
Containers, Containers Everywhere But Not a Drop to Drink!
https://blogs.oracle.com/developers/containers-everywhere
Docker Store
https://store.docker.com/
トライアルページ
https://cloud.oracle.com/ja_JP/tryit

Step 1

まず、Docker Storeにログインし、Oracle Container Cloud Service上にデプロイしたいイメージのページに移動します。
Container Service
https://cloud.oracle.com/ja_JP/container
利用規約に同意してから、”Get Content”ボタンをクリックします。

その後、”Set up”ボタンをクリックします。

Step 2

docker pullコマンドで指定するDockerイメージの場所をコピーします。場所のフォーマットは以下のようになっています。store/oracle/product:version

Step 3

続いて、Container Cloud Serviceで、Docker Storeへの新しいRegistryを定義します。URLとしてindex.docker.io/store を指定し、Dockerアカウント情報としてメールアドレス、ユーザー名、パスワードを追加します。”Validate”ボタンをクリックして接続をテストすることができます。確認後、Registry定義は”Save”をクリックして保存しましょう。
[注意]
このRegistry設定はDocker Storeの任意のイメージに対し1回だけ実行する必要があります。

Step 4

Dockerイメージのために新たにOracle Container Cloud Serviceを作成し、所望のイメージの場所を貼り付け、イメージタグを追加し、任意の適切な実行パラメータを設定して、この新しいサービスの設定を保存します。

Step 5

クリックしてサービスをデプロイしましょう。


これで終わりです。5ステップでDocker Storeで利用可能なOracle製品のDockerイメージを、Oracle Container Cloud Serviceを使って直接Oracle Cloud Platformアカウントにデプロイできました。まだアカウントをお持ちでない場合には、トライアルページからアカウントを取得して試してください。
トライアルページ
https://cloud.oracle.com/ja_JP/tryit

[Docker, Java] Official Docker Image for Oracle Java and the OpenJDK Roadmap for Containers

原文はこちら
https://blogs.oracle.com/developers/official-docker-image-for-oracle-java-and-the-openjdk-roadmap-for-containers

世の中クラウドがもてはやされていますね。
Containers, Containers Everywhere But Not a Drop to Drink!
https://blogs.oracle.com/developers/containers-everywhere
数千、数百万ものインスタンスにスケールする、一貫した、再作成可能な環境をセットアップすることがクラウドでの重要な課題の一つです。インスタンス/アプリケーション/サービス実行環境のばらつきは、メンテナンスコストに反映され、環境が同一であることを信頼できないためにトラブルシューティングはより複雑です。

Oracle Server JREのDockerイメージがDocker Storeからご利用いただけるようになりました。
Oracle Java 8 SE (Server JRE)
https://store.docker.com/images/oracle-serverjre-8
多くの競合技術はこの課題に対処するために長年にわたって開発がなされてきました。 いくつかの技術によって、OSインストールのスクリプト作成や一貫性のある環境の維持が容易になっています(この例としてPuppetがあります)し、ハードウェア仮想化により、(比較的)うまく定義され、隔離されたアプリケーション実行環境を提供するVMの設定が可能ですが、VMはいささか重量級です。

Quick recap of Docker

同じようにDockerが出てきました。実際にはDockerはいくつかの点で違うのですが、人々がDockerとつきあう重要な要素をあげてみましょう。
  • Dockerイメージフォーマットやイメージ作成ツール
  • DockerがLinux上で提供する実行環境では、Linuxカーネルの機能を活用
こうした機能を全て活用かつ組み合わせることにより、Dockerはうまく定義され、分離され、管理可能な「コンテナ」を提供しています。このコンテナは、効果的にハードウェアVMが提供するものと同様の一般的なメリットをオーバーヘッド無しで提供します。具体的には、コンテナはすべて同じLinuxカーネルインスタンス上で実行され/共有されるため、本来なら複製が必要な多くのリソースを共有できます。

Dockerイメージは、実際のDockerコンテナインスタンスを作成するためのパッケージ形式で、このイメージには実行するアプリケーション、当該アプリケーションの構成(の一部)だけでなく、アプリケーションが必要としている依存コンポーネントも含まれています。例えば、Webサービス用のDockerイメージには、実際のWebサービスコードだけでなく、依存するフレームワークやライブラリ、Java Runtime(JRE)、アプリケーションが必要とする任意のユーザー空間ライブラリが含まれています。

Towards a simple & lightweight deployment environment

ちょっと触れた数千、数百万ものインスタンスについて覚えてらっしゃるでしょうか。数百万のインスタンスにスケールする場合、ベースとなるものを合理化し簡素化することが重要になることがすぐにわかることでしょう。 依存性が少ないほど、うまくいきます。ベースイメージが小さければ小さいほど、ディスク上の静的なフットプリントとメモリの動的なフットプリントの両方が占有されるスペースが少なくなります。

本格的かつ一般的なLinuxディストリビューションは通常、あらゆる種類のアプリケーションとユースケースを対象としており、それらをサポートしますが、今実行しようとしていることが正確にわかっていれば、その柔軟性のすべては必要でしょうか。

Alpine Linuxのスローガンは以下のようなものです。
"Small. Simple. Secure. Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.”(Small, Simple, Secure - Alpine Linuxは、musl libcとbusyboxをベースとしたセキュリティ指向、軽量なLinuxディストリビューションです。)
Alpine Linux
https://www.alpinelinux.org/
Alpineが"musl"と呼ばれる小さなCライブラリを使っています。これは通常はGNU Cライブラリ(glibc)を使う傾向にある他のLinuxディストリビューションとは異なります。なぜそうしているのでしょうか。muslのWebページの内容を見てみましょう。
musl libc
http://www.musl-libc.org/ 
"musl is lightweight, fast, simple, free, and strives to be correct in the sense of standards-conformance and safety.”(muslは軽量かつ高速、シンプルで、フリー、標準ベースで案戦という点で正しくあろうと努力しています)
では、busyboxのこの記述はどうでしょうか。
BusyBox: The Swiss Army Knife of Embedded Linux
https://www.busybox.net/about.html
"BusyBox combines tiny versions of many common UNIX utilities into a single small executable.”(BusyBoxは、よく使われる多くのUNIXユーティリティを一つの小さな実行バイナリにまとめたものです)
そうですね、Alpineは基本的に小さなCライブラリを使っており、それをLinux/UNIXユーティリティと組み合わせています。便利ですね。基本的には、通常のアプリケーションを使用でき、Alpine Linuxで実行すると、そのすべての利点が得られる、ということです。

What does Alpine Linux/musl mean to Java?

JDKのコードベースは移植性が高く、いくつかの異なるオペレーティングシステム、CPUアーキテクチャ、コンパイラをサポートしています。 しかし、JDKのソースコードはまだAlpine Linuxに移植されていません。より具体的には、musl Cライブラリに移植されていません。つまり、Alpine Linuxの場合、JDKのソースコードの観点で異なり、目立っている点はCライブラリです。

OpenJDK "Project Portola"の目標は、JDKをAlpine Linuxに移植、特に "musl" Cライブラリに提供することです。 プロジェクトのCall-for-Voteは2月22日に提示され、2週間後(3月9日)に承認されました。(mercurial)コードリポジトリ、メーリングリストなどを含めて、OpenJDKプロジェクトのインフラストラクチャが新たに設定されました。必要なコード変更の統合作業がまもなく開始されます。
Portola Project
http://openjdk.java.net/projects/portola/

Frequently Asked Questions

Oracle Support TeamはDockerコンテナ上で動作するJava SEをサポートしますか?
はい。Oracle Java SEは長年にわたってあらゆるコンテナプラットフォーム上で動作してきました。Oracle SupportはDockerやその他のコンテナプラットフォームをお使いのお客様をご支援します。

Docker固有のOracle Java SEライセンスの考慮事項はありますか?
いいえ。Dockerはコンテナプラットフォームであり、他のOS、仮想化環境、パッケージング形式と比較して、利用や再配布における固有および特別なライセンス上の制約はありません。
Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX
http://java.com/license
Oracle JDKはDockerエコシステムで幅広く利用され、採用されています。

Oracle Java SEをDocker上で実行する際の推奨事項をOracleは提供していますか?
はい、GitHubに掲載しています。
Oracle Java on Docker
http://github.com/oracle/docker-images/tree/master/OracleJava

Dockerをサポートするために直近で何かJavaに対する変更がありましたか?
はい。Java 8 Update 131(2017年4月18日リリース)には、JavaとDocker間でのメモリやプロセッサのよりよい統合を実現する、数多くの変更が含まれています。JDK 8ではデフォルトでスレッドとメモリ設定はホストOS由来ですが、JDK 9ではJVMはコンテナを認識します。あらゆるケースで、スレッドとメモリの制限を明示的にコマンドラインで管理・制御できます。機能強化の詳細は以下をご覧ください。

Docker Image for Oracle Server JRE

DockerでOracle Server JREを試してみる場合には、Docker Storeで個人カタログに追加してから、以下のコマンドを実行することができます。
Oracle Java 8 SE (Server JRE) - Docker Store
https://store.docker.com/images/oracle-serverjre-8
$ docker pull store/oracle/serverjre
Happy coding!