[Virtualization] Announcing the Oracle Vagrant boxes GitHub repository

原文はこちら。
https://blogs.oracle.com/developers/announcing-the-oracle-vagrant-boxes-github-repository

本日OracleソフトウェアのVagrant環境を作成するための新たなGitHubリポジトリを発表しました。
vagrant-boxes
https://github.com/oracle/vagrant-boxes
Vagrantは開発者向けの環境のセットアップを簡単かつ完全自動化できます。Oracle VirtualBoxとともに、Vagrantは仮想マシン内にサンドボックス環境を作成するための強力なツールです。この発表とともに、労力を掛けずにOracleソフトウェアを完全に構成済みの状態で仮想マシンを作成し、利用できる状態にするという、この強力な自動化を世界中のユーザーにご案内します。これは、開発者の生活をより簡単に、より生産的にするための一連のステップの1つです。

簡単かつ迅速に始めることができます。まだやったことがない場合は、以下のソフトウェアをダウンロード、インストールする必要があります。
上記2個のコンポーネントをインストールしたら、GitHubリポジトリをクローン/ダウンロードしてご自身のVagrant環境を作成できます。Oracle Linux仮想マシンを作成する場合、以下のように非常に簡単です。

1. GitHubリポジトリをクローン(もしくはダウンロード)

gvenzl-mac:vagrant gvenzl$ git clone https://github.com/oracle/vagrant-boxes
Cloning into 'vagrant-boxes'...
remote: Counting objects: 74, done.
remote: Total 74 (delta 0), reused 0 (delta 0), pack-reused 74
Unpacking objects: 100% (74/74), done.

2. OracleLinuxというサブフォルダに移動

gvenzl-mac:vagrant gvenzl$ cd vagrant-boxes/OracleLinux/

3. vagrant upと叩いて、VMのプロビジョニングを待つ

gvenzl-mac:OracleLinux gvenzl$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Box file was not detected as metadata. Adding it directly...
==> default: Adding box 'http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box' (v0) for provider: virtualbox
    default: Downloading: http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box
==> default: Successfully added box 'http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box' (v0) for 'virtualbox'!
==> default: Importing base box 'http://yum.oracle.com/boxes/oraclelinux/latest/ol7-latest.box'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: ol7-vagrant
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2220 (host) (adapter 1)
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
...
...
...
==> default: INSTALLER: Locale set
==> default: INSTALLER: Installation complete, Oracle Linux ready to use!
仮想マシンがプロビジョニングされたら、準備完了です。"vagrant ssh"と叩いて仮想マシンにSSHでログインし、やりたいタスクを実行するだけです。終了したら、SSHターミナルの場合と同様に、  "exit" と叩くだけです。
gvenzl-mac:OracleLinux gvenzl$ vagrant ssh

Welcome to Oracle Linux Server release 7.4 (GNU/Linux 4.1.12-112.14.13.el7uek.x86_64)

The Oracle Linux End-User License Agreement can be viewed here:

* /usr/share/eula/eula.en_US

For additional packages, updates, documentation and community help, see:

* http://yum.oracle.com/

[vagrant@ol7-vagrant ~]$ uname -a
Linux ol7-vagrant 4.1.12-112.14.13.el7uek.x86_64 #2 SMP Thu Jan 18 11:38:29 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
[vagrant@ol7-vagrant ~]$ exit
logout
Connection to 127.0.0.1 closed.
gvenzl-mac:OracleLinux gvenzl$
You can stop the virtual machine and reboot it any time by typing “vagrant halt” and “vagrant up”:
gvenzl-mac:OracleLinux gvenzl$ vagrant halt
==> default: Attempting graceful shutdown of VM...


gvenzl-mac:OracleLinux gvenzl$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2220 (host) (adapter 1)
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
==> default: Machine booted and ready!
[default] GuestAdditions 5.1.30 running --- OK.
==> default: Checking for guest additions in VM...
==> default: Setting hostname...
==> default: Mounting shared folders...
default: /vagrant => /Users/gvenzl/Downloads/vagrant/vagrant-boxes/OracleLinux
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.
gvenzl-mac:OracleLinux gvenzl$
Last最後に、VMをマシンから完全に削除したい場合は、"vagrant destroy"とするだけです。これでVMとその中のもの一切合切削除されますので、このコマンドを使う場合にはご注意を。
gvenzl-mac:OracleLinux gvenzl$ vagrant destroy
default: Are you sure you want to destroy the 'default' VM? [y/N] y
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives... 
今後Oracleは、より多くのVagrant構成ファイルをこのGitHubリポジトリにUpしていきます。これは、完全なオープンソースの方式で推進していきます。GitHubのIssueを使ってコメントや改善要求をお知らせください。

Oracle VM VirtualBoxとVagrantを使用したDockerサンドボックスを設定する方法を紹介する、Sergio Leunissenの以下の素敵な動画もチェックしてください。

[Java] Java 10リリースを約1ヶ月後に控えて

6ヶ月ごとのリリースに移行したJavaは、来月(2018/3/20)Java 10がリリースされる予定です。
リリース予定の機能やスケジュールなどは以下をご覧ください。現在Release Candidateフェーズ(リリースにあたって障害となる不具合の修正のみ実施)に入っています。
JDK 10
http://openjdk.java.net/projects/jdk/10/
JDK 10 Early Accessのリリースノート
http://jdk.java.net/10/release-notes
Java APIのドキュメントもEarly Access版が公開されています。
Java® Platform, Standard Edition & Java Development Kit Version 10 API Specification
https://download.java.net/java/jdk10/docs/api/overview-summary.html
Java 10での新機能をまとめたエントリも出てきましたね。ぜひ、チェックしてみてください。

[WLS, Docker] Announcing the New WebLogic Server Kubernetes Operator

原文はこちら。
https://blogs.oracle.com/weblogicserver/announcing-the-new-weblogic-server-kubernetes-operator

Oracle WebLogic Server Kubernetes Operatorのテクノロジープレビュー版をオープンソースとしてリリースすることを発表できうれしく思っています。Kubernetes上でWebLogic Server 12.2.1.3ドメインを作成および管理するためのこのOperatorをGitHubにリリースするとともに、以下の内容について詳しく説明するブログを公開しています。
Oracle WebLogic Server Kubernetes Operator
https://github.com/oracle/weblogic-kubernetes-operator
Announcing the Oracle WebLogic Server Kuberentes Operator
https://blogs.oracle.com/developers/announcing-oracle-weblogic-server-kuberentes-operator
  • Operatorの実行方法
  • Kubernetesで1つ以上のWebLogicドメインの起動方法
  • WebLogic診断フレームワーク(WLDF)またはPrometheusを使用し、WebLogicクラスタの手動もしくは自動でスケールアウト・スケールインするする方法
  • OperatorによるWebLogicクラスタにデプロイされたWebアプリケーションの負荷分散の管理方法
  • ElasticSearch、logstash、およびKibanaを使用してOperatorのログを管理するための連携方法
Kubernetes Operatorは、「Kubernetes APIを拡張して複雑なアプリケーションのインスタンスを作成、構成、管理するための、アプリケーション固有のコントローラ」です。
Operatorパターンを採用し、これを使用してWebLogic ServerとKubernetesを統合するアダプタを提供しています。これにより、KubernetesをWebLogic Serverインスタンスをホストするコンテナインフラストラクチャとして機能させることができます。したがって、WebLogic Server Kubernetes Operatorは、Kubernetesを拡張してWebLogicドメインの作成、構成、管理を行うオペレータです。

Operatorは、標準のOracle WebLogic Server 12.2.1.3 Dockerイメージを使用します。このDockerイメージは、Docker StoreまたはOracle Container Registryにあります。
Docker Store
https://store.docker.com/
Oracle Container Registry
https://container-registry.oracle.com/
このイメージは不変(immutable)であるとみなされ、すべてのアプリケーションおよび製品のランタイムの状態はKubernetesの永続ボリュームに保持されます。これにより(ランタイムの状態がPod内に存在しないため)、すべてのPodを使い捨てで置き換え可能として扱うことができ、実行時にDockerコンテナに書き込まれた、ランタイムの状態を管理する必要性が完全に無くなります。
Oracle WebLogic Server Kubernetes Operatorの前提条件は以下の通りです。
  • Kubernetes 1.7.5+, 1.8.0+ (kubectl versionで確認)
  • Flannel networking v0.9.1-amd64 (docker images | grep flannelで確認)
  • Docker 17.03.1.ce (docker versionで確認)
  • Oracle WebLogic Server 12.2.1.3
My Oracle SupportのドキュメントID 2349228.1で詳しく説明されているように、Kubernetes上のWebLogic Server 12.2.1.3ドメインは動作保証されており、サポート対象です。
WebLogic Server 12.2.1.3 Certification on Kubernetes (Doc ID 2349228.1)
https://support.oracle.com/rs?type=doc&id=2349228.1
WebLogic Kubernetes Operatorはテクニカルプレビュー版であり、Oracle Supportではまだサポートされていません。WebLogic Kubernetes Operatorに関する問題が発生した場合は、以下のGitHubプロジェクトでIssueを開く必要があります。GitHubのプロジェクトメンバーは、問題に迅速に対応し、問題を解決します。
Issues - Oracle WebLogic Server Kubernetes Operator
https://github.com/oracle/weblogic-kubernetes-operator/issues
Operatorのビデオデモンストレーションは以下からご覧いただけます。
  • インストール方法とOperatorのREST APIの利用方法
  • 2個のWebLogicドメインを作成(WebLogic Server管理コンソールにアクセスし、Kubernetesで作成された様々なリソース(サービス、Ingress、Pod、ロードバランサなど)の確認を含む)
  • Webアプリケーションのデプロイ、Operatorを使ったWebLogicクラスタのスケーリング、負荷分散の検証
  • Kubernetesで実行中のドメインに対してWLSTを使用し、同様にKubernetesで動作するOracle Databaseに対するデータソースを作成
  • WLDFを使ったWebLogicクラスタのスケール
  • Prometheus integration - WebLogic ServerのメトリックをPrometheusにエクスポートし、スケール操作を呼び出すためのPrometheusアラートの作成
Operatorのインストールと構成、およびOperatorを使ったWebLogicドメインの管理にの全体的なプロセスは、以下の手順で構成されています。提供するスクリプトでこれらの手順のほとんどを実行しますが、一部手作業による実行が必要があるものもあります。
  • Oracle Container Registryへのアクセスのための登録
  • Oracle Container Registryにアクセスするためのシークレットの設定
  • Operatorのパラメータファイルのカスタマイズ
  • KubernetesクラスタへのOperatorのデプロイ
  • 管理サーバーの資格証明に対するシークレットの設定
  • WebLogicドメインの永続ボリュームの作成
  • ドメイン・パラメータ・ファイルのカスタマイズ
  • WebLogicドメインの作成
最新の手順については、以下のURLを参照してください。
Installation - Oracle WebLogic Server Kubernetes Operator
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/installation.md
まもなくこのOperatorへの正式なサポートが提供され、時間の経過とともに新しい機能や拡張機能が追加される予定です。WebLogic Server Kubernetes Operatorの詳細はしばしお待ちください。今回の発表は、KubernetesにWebLogic Serverを導入しようとしている人にとって有益な情報であることを願っております。皆さんのご意見をお待ちしております。

[Java] EE4J: An Update

原文はこちら。
https://blogs.oracle.com/theaquarium/ee4j%3a-an-update

Eclipse FoundationのMike Milinkovichが先頃自身のブログで全体的なEE4Jプロジェクトの状況を伝えています。
EE4J: Current Status and What’s Next
https://mmilinkov.wordpress.com/2018/01/23/ee4j-current-status-and-whats-next/
  • 下記URLで示すコミュニティプロセスを使用し、新しいブランド名の定義作業を進めています。
    Brand Name Selection
    https://github.com/eclipse-ee4j/ee4j/issues/1
  • We have begun the process of moving Oracle GlassFishのソースをEE4Jプロジェクトへ移管するプロセスを開始しました。
    Eclipse Enterprise for Java
    https://projects.eclipse.org/projects/ee4j
    これまでに、Oracleは以下のプロジェクトのソースを提供しています。
    • Eclipse Grizzly
    • Eclipse OpenMQ
    • Eclipse Project for JAX-RS
    • Eclipse Project for JMS
    • Eclipse Tyrus
    • Eclipse Project for WebSocket
    • Eclipse Project for JSON Processing
  • 上記プロジェクトに加え、
    • Eclipse YassonとEclipseLinkプロジェクトがEE4Jに移管され、現在EE4Jプロジェクトの一部になっています。
    • We have created Eclipse JerseyとEclipse Mojarraプロジェクトを作成し、現在これらのソースの提供に取り組んでいます。
  • EE4Jプロジェクトのリポジトリは、EE4JというGitHubの組織で作成しており、EE4Jプロジェクトのリポジトリをご覧いただけます(そしてStarを付けることもできます)。
    Eclipse EE4J
    https://github.com/eclipse-ee4j
  • Oracleは、Mikeが彼のエントリで言及しているすべてのテクノロジー(JSON-B API、Concurrency、セキュリティ、JTA、JavaMail、JAX-B、JAX-WS、JSTL、UEL、JAF、Enterprise Management、およびCommon Annotations)に関するEclipseプロジェクトの提案に取り組んでおり、これらのプロジェクトを早急にEE4J Project Management Committee(PMC)に正式に提案する予定です。
    EE4J PMC and Project Leadership
    https://projects.eclipse.org/projects/ee4j/pmc
    直近の重要な目標の1つは、Oracleが有するGlassFishテクノロジーをすべてEE4Jに移行し、EE4JのソースからEclipse GlassFishを構築し、Java EE 8準拠を実証できるようにすることです。
  • EE4Jにメンバー指向のガバナンスモデルを提供するためのEclipse Foundationワーキンググループの設立に取り組んでいます。
まとめると、EE4Jプロジェクトは着実に進んでいます。さらなるアップデートについては、このブログと上記のリンクを参照するか、ee4j-communityメーリングリストに登録して入手してください。
ee4j-community mailing list
https://dev.eclipse.org/mhonarc/lists/ee4j-community/

[Linux] XFS - What's new and what's next!

原文はこちら。
https://blogs.oracle.com/linuxkernel/xfs-whats-new-and-whats-next

上流のXFSメンテナンス者であり、Oracle Linuxのカーネル開発者であるDarrick Wongが、XFSに関する1年間の作業の回想を書きました。この中で、最新のLinuxカーネルに登場しているいくつかの素晴らしい機能を暗示しています。(個人的には)オンラインファイルシステムのチェックに期待しています。

昨年、Linux 4.8-4.9で導入され、昨年のこのブログのエントリで取り上げた新しいリバース・マッピングとreflinkの機能を安定させるために大部分の時間を費やしました。
Upcoming XFS Work in Linux v4.8 v4.9 and v4.10+, by Darrick Wong
https://blogs.oracle.com/linuxkernel/upcoming-xfs-work-in-linux-v48-v49-and-v410%2c-by-darrick-wong
2018年中頃にreflinkからEXPERIMENTALタグを削除する準備をしています。これにより、より良い拡張性を得るために、in-core file extent map cacheを再作成する必要があります。昨年1月にVFSブロックマッピングインターフェイスをiomapに変換しました。3つのIOアクセス方式(バッファ付き、直接、DAX)はすべて、NVMeフラッシュ上でのオーバーヘッドの削減とパフォーマンスの向上のメリットがあります。

Linux 4.12では、XFSとext4の両方にGETFSMAP ioctlを導入し、ユーザ空間の管理ツールでファイルシステム空間マップ全体を照会できるようにしました。これにより、システム管理者は、メタデータのオーバーヘッドや空き領域の断片化など、ファイルシステム状態のライブ分析を実行できます。XFSでは、新しいxfs_spacemanでこの機能を提供しますが、ext4では、e2fsprogs 1.43.5のe2freefragツールが、マウントされたファイルシステムの検出時にライブクエリを実行するようになっています。 xfsprogsのリリースはカーネルの後になりました。

2017年まで、XFS用のオンラインfsckツールの準備に取り組んできました。既存のXFSコードベースには、メタデータバッファがディスクから読み込まれ、ディスクに書き出される前に、メタデータバッファのスポットチェックを実行する単純なメタデータブロックベリファイア(metadata block verifiers)があります。これらのベリファイアはIOホットパス(IO hot path)に存在するため、スコープが非常に限られています。これらは計算コストの高いチェックは実行できません。具体的には、他のメタデータ構造を相互参照することはできません。書き込みパスのエラーではファイルシステムをシャットダウンします。
こうした課題に対する解決策として、別のオンラインfsckユーティリティがあります。このツールは、ユーザ空間で計算コストの高いチェックをスケジュールし、すべてのチェックで高いコストにならないようにすることで、ベリファイアを拡張します。専用のオンラインfsckツールは、メタデータ値が正確に正しいことを確認することができます。単におおよその範囲内に収まっているかだけをチェックするわけではありません。この最も顕著な例は、逆参照マッピングを使用したブロック参照カウントのチェックです。逆のマッピングツリーを数回歩かなければなりません。他のメタデータと相互参照できる他のすべてもチェックされます。例えば、ファイルデータの範囲が与えられれば、それはinodeではなく、空き領域ではなく、btreeの一部ではなく、拡張属性データとクロスリンクされていないことを保証できます。この種のチェックでは、多くのIOが必要ですが、ユーザー空間ドライバープログラムからIOを管理し、抑制できます。スクラブ作業の一環として、XFSベリファイアを再構成して、破損が見つかった場所をより正確にレポートし、メモリ内バッファの破損を検出するようにします。

オンラインファイルシステム修復は、スクラブ後にしばらくしてから始まりますが、実行可能な修復戦略がメタデータの最初からの再構築しかないため、このタイプの修復は非常に困難です。これを行うには、ファイルシステム全体のすべてのメタデータをロックしてスキャンし、すべての新しいレコードをメモリに作成し、ディスクに書き出す必要があります。続いて、メモリ内の状態すべてを注意深くリセットする必要があります。

Linux 4.15にはスクラブの最初の部分が含まれていましたが、それ以降のリリースでは残りの部分が含まれていました。この機能は一度安定すると、ファイルシステムのダウンタイムをさらに短縮できます。

Allison Hendersonは、XFS親ポインタパッチセットの開発を最近再開しました。XFS親ポインタパッチセットを使うと、拡張属性を設定することで、親ディレクトリのディレクトリエントリへのバックリンクをファイルが記録できます。これにはまず、拡張属性の操作のアトミック性を改良する必要があります。ユーザー空間にフェイルバック可能な通常のファイル属性の操作とは異なり、親ポインタの操作は成功しなければなりません。そうでない場合はファイルシステムが破損しています。親ポインタが配置されたら、オンラインfsckツールを使用してディレクトリツリーの双方向チェックを実行し、ディレクトリを再構築できます。また、書き込みエラーを解決し、影響を受けるファイルパスとオフセットを含むより豊富なログメッセージに記述できるようになります。

将来的には、これらの新しいストレージメディアへの望ましいユーザー空間インターフェイスを詳細に議論できれば、DAXと永続メモリのサポートが改善されるでしょう。この件はメーリングリスト上で多くの議論を呼び起こしましたが、使用モデルやハードウェアは遅れて現れました。mkfsに対して提案された変更があります。これはディストリビューションや管理者が、mke2fsのように、設定ファイルにデフォルトのmkfsオプションを提供できるようにするものです。古いリアルタイムボリュームを再利用して、メタデータと小さなファイルをSSDに保存しながら、SMRドライブにアーカイブデータを記録できるXFSを構築するためのパッチセットも提案されています。

2018年にテクニカルプレビューとして登場予定のすべてのXFSの機能にご期待ください。

[WLS, Docker] T3 RMI Communication for WebLogic Server Running on Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/t3-rmi-communication-for-weblogic-server-running-on-kubernetes

Overview

Oracle WebLogic ServerはJava EEをサポートしており、そしていくつかのベンダー固有の機能強化を含んでいます。それは、Java EEベースのIIOP、RMIという2個のRMI実装に加え、WebLogic ServerがT3と呼ばれる独自のRMIプロトコルです。このエントリではT3にも当てはまる汎用的なRMIの構成と、WebLogic ServerをKubernetesで動作させる上でT3固有の部分を説明します。

Background

T3 RMIは、WebLogic Server独自の高性能RMIプロトコルであり、WebLogic Server内部での主要な通信コンポーネントであり、JMS、EJB、OAMなどのサービスの外部でも使用されます。WebLogic ServerのT3 RMI構成が進化しました。これは、デフォルトのチャネルとして知られているWebLogic Server上の単一のマルチプロトコルリスンポートとリスンアドレスで始まります。ネットワークアクセスポイントレイヤーを追加することでデフォルトのチャネルが強化されました。これにより、ユーザーは複数のポートを設定できるほか、カスタムチャネルと呼ばれるポートごとに異なるプロトコルも設定できます。 WebLogic ServerがKubernetes上で動作している場合、WebLogic Serverのリスンポート番号は、Kubernetes公開ポート番号と同じでも異なっていてもかまいません。Kubernetes上で実行されているWebLogic Serverでは、カスタムチャネルを使用して、この2つのポート番号をマッピングできるからです。
下表は、このブログで使用されている重要な用語を纏めたものです。詳細を確認するためのドキュメントへのリンクも付けています。
用語
Listen port WebLogic Serverが物理的にバインドしているTCP/IPポート
Public port パブリックポート。
呼び出し側がT3 URLを定義する際に使うポート番号。ポートマッピングを使った接続でない限り、通常はリスンポートと同じ。
Port mapping とあるアドレスとポート番号の組合せからの通信リクエストを別のものにリダイレクトするネットワークアドレス変換(Network Address Translation、NAT)のアプリケーション。
Default channel すべてのWebLogic Serverドメインが自動生成する、すべてのWebLogic Serverが有するデフォルトチャネル。
Oracle® Fusion Middleware Oracle WebLogic Serverサーバー環境の管理 12c (12.2.1.3.0)
デフォルト・ネットワーク・チャネル
https://docs.oracle.com/cd/E92951_01/wls/CNFGD/network.htm#CNFGD167
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1.3.0)
The Default Network Channel
https://docs.oracle.com/middleware/12213/wls/CNFGD/network.htm#CNFGD167
Custom channel 異なる種類のネットワークトラフィックを分離するために利用
ServerTemplateMBean デフォルトチャネルとしても知られる。詳細は以下を参照。
Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12.2.1.3.0
Interface ServerTemplateMBean
https://docs.oracle.com/middleware/12213/wls/WLAPI/weblogic/management/configuration/ServerTemplateMBean.html
NetworkAccessPointMBean カスタムチャネルとしても知られる。詳細は以下を参照。
Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12.2.1.3.0
Interface NetworkAccessPointMBean
https://docs.oracle.com/middleware/12213/wls/WLAPI/weblogic/management/configuration/NetworkAccessPointMBean.html
WebLogic cluster communication クラスタに属するWebLogic Serverインスタンスはマルチキャスト、ユニキャストの2個の基本ネットワークテクノロジーのうちいずれかを使ってお互いに通信する。マルチキャストとユニキャストについては以下を参照。
Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.2.1.3.0)
クラスタでの通信
https://docs.oracle.com/cd/E92951_01/wls/CLUST/features.htm#CLUST127
Oracle® Fusion Middleware Administering Clusters for Oracle WebLogic Server 12c (12.2.1.3.0)
Communications In a Cluster
https://docs.oracle.com/middleware/12213/wls/CLUST/features.htm#CLUST127
WebLogic transaction coordinator トランザクションコーディネータとして振る舞うWebLogic Serverトランザクションマネージャ
Kubernetes service Kubernetes conceptsを参照。
Kubernetes Concepts - Services
https://kubernetes.io/docs/concepts/services-networking/service/
これはKubernetesのバックエンドとNodePortを定義する。
Kubernetes pod IP address Podがどのホスト上にあるかに関わらず、KubernetesはPodが他のPodと通信することを想定している。各PodにクラスタプライベートIPアドレスを付与するので、明示的にPod間のリンクやコンテナのポートとホストのポートとのマッピングを作成する必要はない。詳細は以下を参照。
Kubernetes Concepts - Cluster Networking
https://kubernetes.io/docs/concepts/cluster-administration/networking/
ClusterMBean ClusterBroadcastChannelを参照。
Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12.2.1.3.0
Interface ClusterMBean
https://docs.oracle.com/middleware/12213/wls/WLAPI/weblogic/management/configuration/ClusterMBean.html

WebLogic Server Listen Address

WebLogic Serverは、マルチキャストとユニキャストの2つのクラスタメッセージングプロトコルをサポートしています。WebLogic Server on Kubernetesの動作保証の検証は、Flannelネットワークファブリックを使用して行われました。 現在、ユニキャスト通信のみを動作保証しています。
デフォルトでは、WebLogic Serverはユニキャスト通信にデフォルトチャネルを使用します。ユーザーは、関連付けられたWebLogic Server ClusterMBeanにカスタムチャネルを設定することでオーバーライドできます。
WebLogicクラスタのユニキャスト構成の一環として、WebLogicクラスタメンバーがお互いを発見できるよう、クラスタメンバーごとに指定されたリスンアドレスとポートが必要です。 既定では、既定のチャネルまたはカスタムチャネルはnullリスンアドレスを持ち、実行時に0.0.0.0として割り当てられます。マルチノードKubernetesクラスタ環境では、0.0.0.0とlocalhostのどちらを使っても、異なるノードの他のクラスタメンバが互いに発見できませんが、その代わりに、WebLogic Serverインスタンスが実行されているKubernetes Pod IPアドレスを使用できます。

TCP Load Balancing

一般に、WebLogic T3はTCP/IPベースであるため、複数のバックエンドを持つKubernetesサービスなど、サービスが同種の場合にTCP負荷分散をサポートできます。WebLogic Serverでは、JMSやEJBなどのいくつかのサブシステムが同種のものです。例えば、JMSフロントエンドサブシステムは、リモートJMSクライアントが任意のクラスタメンバーに接続できるWebLogicクラスタで構成できますが、対照的に、JTAサブシステムでは、単一のKubernetesクラスタを超えて広がる複数のWebLogicドメインにまたがるトランザクションでTCPロードバランシングを安全に使用できません。JTAトランザクションコーディネータは、トランザクションがコミットまたはロールバックされたときに、トランザクションのサブコーディネータとして選択されたサーバインスタンスへの直接RMI接続を確立する必要があるからです。
下図は、T3プロトコルを使用してサブコーディネータに接続するWebLogicトランザクションコーディネータを示しています。WebLogicトランザクションコーディネータは、TCPロードバランシングが原因で、選択したサブコーディネータに接続できません。
Figure 1: Kubernetes Cluster with Load Balancing Service
Kubernetes環境全体のWebLogicトランザクションコーディネータとトランザクションサブコーディネータ間のクラスタ通信をサポートするには、各デフォルトチャネルとカスタムチャネルに対して個別のNodePortサービスを定義することをお勧めします。
Figure 2: Kubernetes Cluster with One-on-One Service
アプリケーションの要件と使用するWebLogicサブシステムに応じて、TCPロードバランシングが適している場合と適切でない場合があります。

Port Mapping and Address Mapping

WebLogic Serverは、2つのスタイルのT3 RMIの構成をサポートしています。1つはデフォルトチャネル(ServerTemplateMBeanを参照)によって定義され、もう1つはカスタムチャネル(NetworkAccessPointMBeanを参照)によって定義されるものです。
Oracle Fusion Middleware MBean Reference for Oracle WebLogic Server 12.2.1.3.0 MBean Reference
ServerTemplateMBean
https://docs.oracle.com/middleware/12213/wls/WLMBR/mbeans/ServerTemplateMBean.htmlNetworkAccessPointMBean
https://docs.oracle.com/middleware/12213/wls/WLMBR/core/index.html
KubernetesでWebLogic Serverを実行する場合は、ポートマッピングに特に注意する必要があります。
NodePortを使用してKubernetesクラスタ外でWebLogic T3 RMIサービスを公開する場合は、NodePortをWebLogic Serverのリスンポートにマップする必要があります。NodePortがWebLogic Serverのリスンポートと同じであれば、WebLogic Serverのデフォルトチャネルを使用できます。それ以外の場合は、NodePortのnodePort値と一致する「パブリックポート」と、NodePortのポート値と一致する「リスンポート」を定義するカスタムチャネルを設定する必要があります。
下図は動作しないNodePort/デフォルトチャネルの構成と、動作するNodePort/カスタムチャネルの構成を示したものです。
Figure 3: T3 External Clients in K8S
下表はデフォルトチャネルのプロパティと、それに対応するカスタムチャネルのプロパティを対比したものです。
Default Channel (ServerTemplateMBean) Custom Channel (NetworkAccessPointMBean)
複数のプロトコルをサポート(T3、HTTP、SNMP、LDAPなど) Yes No
RMI over HTTP tunneling Yes
(デフォルトでは無効)
Yes
(デフォルトでは無効)
Port mapping No Yes
Address Yes Yes

Examples of WebLogic T3 RMI configurations

WebLogic Serverは複数のT3 RMIの構成方法をサポートしています。以下はよく使われる方法の例です。

Using the WebLogic Server Administration Console

以下のコンソールページは、リスンポートとして9001、リスンアドレスは無指定、SSLポートの設定をしていない、管理サーバーのWebLogic Serverインスタンスの例です。このサーバーインスタンスをデフォルトチャネルを使って構成しているため、ポート9001はT3、http、iiop、snmp、そしてldapをサポートします。
Figure 4: T3 RMI via ServerTemplateMBean on WebLogic console
以下のコンソールページは、リスニングポートとして7010、リスニングアドレスは無指定、パブリックポート30010へのマッピングがなされているカスタムチャネルの例です。デフォルトでは、カスタムチャネルはT3プロトコルをサポートします。
Figure 5: T3 RMI via NetworkAccessPointMBean on WebLogic Console

Using WebLogic RESTful management services

以下のシェルスクリプトはリスンポートとして${CHANNEL_PORT}、ペアとなるパブリックポートとして${CHANNEL_PUBLIC_PORT}を持つカスタムチャネルを作成します。
#!/bin/sh

HOST=$1
PORT=$2
USER=$3
PASSWORD=$4
CHANNEL=$5
CHANNEL_PORT=$6
CHANNEL_PUBLIC_PORT=$7

echo "Rest EndPoint URL http://${HOST}:${PORT}/management/weblogic/latest/edit"
if [ $# -eq 0 ]; then
echo "Please specify HOST, PORT, USER, PASSWORD CHANNEL CHANNEL_PORT CHANNEL_PUBLIC_PORT"
exit 1
fi

# Start edit
curl -j --noproxy '*' --silent \
--user $USER:$PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d "{}" \
-X POST http://$HOST:$PORT/management/weblogic/latest/edit/changeManager/startEdit

# Create
curl -j --noproxy '*' --silent \
--user $USER:$PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d "{
name: '${CHANNEL}'
}" \
-X POST http://$HOST:$PORT/management/weblogic/latest/edit/Servers/myServer/networkAccessPoints

curl -j --noproxy '*' --silent \
--user $USER:$PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d "{
listenPort: ${CHANNEL_PORT},
publicPort: ${CHANNEL_PUBLIC_PORT}
}" \
-X POST http://$HOST:$PORT/management/weblogic/latest/edit/Servers/myServer/networkAccessPoints/${CHANNEL}

curl -j --noproxy '*' --silent \
--user $USER:$PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d "{}" \
-X POST http://$HOST:$PORT/management/weblogic/latest/edit/changeManager/activate

Using a WLST script

以下のWLSTスクリプトではt3Channelという名前のカスタムT3チャネルを作成します。これはリスンポートとしてlisten_port、パブリックポートとしてpublic_portを持ちます。
host = sys.argv[1]
port = sys.argv[2]
user_name = sys.argv[3]
password = sys.argv[4]
listen_port = sys.argv[5]
public_port = sys.argv[6]

print('custom host : [%s]' % host);
print('custom port : [%s]' % port);
print('custom user_name : [%s]' % user_name);
print('custom password : ********');
print('public address : [%s]' % public_address);
print('channel listen port : [%s]' % listen_port);
print('channel public listen port : [%s]' % public_port);

connect(user_name, password, 't3://' + host + ':' + port)

edit()
startEdit()
ls()
cd('/')
cd('Servers')
cd('myServer')
create('t3Channel','NetworkAccessPoint')
cd('NetworkAccessPoints/t3Channel')
set('Protocol','t3')

set('ListenPort',int(listen_port))
set('PublicPort',int(public_port))

print('Channel t3Channel added ...')
activate()
disconnect()

Summary

WebLogic ServerはT3プロトコルを使うRMI通信を使用して、WebLogic Serverインスタンス間および他のJavaプログラムとクライアント間を通信します。WebLogic ServerがKubernetesクラスタで動作する場合、RMI通信を行うために考慮すべき特別な事項と構成要件があります。このエントリでは、Kubernetesクラスタの外部からのRMI通信がKubernetesクラスタ内で実行されているWebLogic Serverインスタンスに正常に到達できるように、WebLogic ServerとKubernetesを構成する方法について説明しています。
EJB、JMS、JTA、WLSTなど、T3 RMIを使用する多くのWebLogic Server機能では、Kubernetesクラスタの内部と外部のクライアントをサポートしています。さらに、マルチノードKubernetesクラスタ内の単一、および複数のWebLogicドメインの両方をサポートします。

[Java, Security] Understanding why Java signed code needs to be re-signed periodically (even if time-stamped)

原文はこちら。
https://blogs.oracle.com/java-platform-group/signed-code-needs-to-be-re-signed

Javaランタイムには、別のコンピュータからコードを受け入れるためのメカニズムがあります。コードは実行前に安全ではないネットワークを通過する可能性があるため、これらのメカニズムは、プログラムが信頼できるエンティティによって作成され、改ざんされていないことを検証するためのデジタル署名(コード署名)に依存しています。デジタル署名コードにはコード署名証明書が必要です。デフォルトでJavaランタイムが受け入れるのは、信頼できる認証局(CA)が発行した証明書のみです。セキュリティ上の理由から、証明書の発行日から1年間から3年間の限られた期間のみ有効です。
デジタル署名が有効とみなされるためには、署名自体の有効期限が切れていなくても、コード署名証明書が有効な間に署名をしなければなりません。有効期限が切れた証明書で作成された署名は有効とみなされません。署名がいつ作成されたかを知ることが重要です。残念ながら、ファイルのファイル作成日"プロパティを信頼することはできません。その値が偽造された可能性があるからです。
コード署名証明書の有効期間中に署名されたことを確認する1つの方法として、署名チェック時に有効な証明書で署名されたコードのみを受け入れる方法がありますが、このアプローチの問題は、たとえコード自体が変更されていなくても、1年に1回、コードを再署名して再配布する必要がある点です。
証明書の有効期限内に署名が作成されたかどうかを検証する場合、タイムスタンプをつかうとよいでしょう。タイムスタンプの付与には、信頼できるサードパーティであるTSA(Time-Stamping Authority、タイムスタンプ局)が、与えられた署名が所定の日付以前に作成されたことを確認する必要があります。このタイムスタンプは、コード署名証明書が失効する前に署名が行われたという証明として、署名済みコードに追加されます。
タイムスタンプ自体は、開発者のコード署名証明書ではなく、タイムスタンプの権限証明書を使用した別の電子署名に過ぎませんが、依然として考慮しなければならない同じ規則と独自の有効期限がある点を見落としがちです。理想的には、タイムスタンプ局は、コード署名証明書よりもずっと後に期限が切れる証明書を使用します。
タイムスタンプサーバーの証明書が失効すると、証明書の有効期限内にタイムスタンプが作成されたことを信頼できなくなってしまいます。コード署名証明書が失効する前に元の署名が作成されたかどうかを確認できなくなります。
有効期限は、署名が信頼されなくなる理由の1つにすぎません。コード署名やタイムスタンプに関わる証明書は、それらが侵害された場合、もしくは証明書の有効期限が切れる前に、それらの作成に使用されたアルゴリズムがクラックされる場合、取り消される可能性があります。コード署名証明書を無効にするものは、コードの署名に影響します。タイムスタンプ証明書を無効にするものは、タイムスタンプを無効にします。
タイムスタンプサービスは、遠い将来に有効期限が切れる証明書が常に使用し、長期間有効であると考えられるアルゴリズムと鍵長でのみ署名すると信じられていますが、後方互換性のために中期的には安全でないと思われるアルゴリズムを使用してタイムスタンプを生成することが必要なこともあります。その場合タイムスタンプ局は有効期限の短いタイムスタンプ証明書の利用を選択する可能性があります。
開発者は、依存している各タイムスタンプサービスの長所や短所、コードの署名が有効でなくなったときの状況を把握し、混乱を避けるための十分な時間をもってコードを再署名して十分に再配布する手順を踏むことが重要です。
コード署名とタイムスタンプがより低いレベルでどのように機能するか、もっと詳しく知りたい場合は、以下のエントリをご一読ください。
Understanding Digital Certificates and Code Signing
http://www.oracle.com/technetwork/java/javase/documentation/digitalcerts-codesigning-4312830.html