Quantcast
Channel: Oracle Blogs 日本語のまとめ
Viewing all 760 articles
Browse latest View live

[Linux, Cloud, Virtualization] Running VirtualBox inside a VM instance in Oracle Cloud Infrastructure

$
0
0
原文はこちら。
https://blogs.oracle.com/wim/running-virtualbox-inside-a-vm-instance-in-oracle-cloud-infrastructure

OK - だから、 「なぜ?」と聞かないでください。その理由は、できるから、つまり、ほとんどの場合に対して答えがあるからです。
Oracle Cloud InfrastructureはNested Virtualizationをサポートしています。VMインスタンスをOCIで作成し、Oracle Linux 7をUEKで実行すると、KVMもしくはVirtualBox VMを内部に作成できます(作り方はすぐにご紹介します)。ベアメタルインスタンスを作成すると、通常のローカルサーバー上でインストールするのと同じVirtualBoxをインストールしたり、KVMを利用したりできます。ベアメタルサーバーなので、ハードウェアおよびその機能にフルアクセスできます。
VirtualBoxには、(仮想化されている場合でも)リモート実行に便利な組み込み機能があります。 1つの例が、組み込みのvRDPサーバーで、リモートの動画や音声(ビデオチャンネルの有効化/チューニング)を利用できます。ローカルのVirtualBoxイメージを簡単に作成し、変更しないでリモートで実行できます。定常的に起動/停止する小さなVMを作成できるということで、vagrantのboxを利用できます。つまり、vagrantのVirtualBox環境全体をリモートクラウドに開放します。そんなわけで、「できるから」という言葉はさておき、これにはよい実ユースケースがあります。
どうやって構成すればいいのでしょうか。ほとんどの場合、かなり簡単です。OCIのVMにVirtualBoxをインストールする方法は、ローカルのデスクトップまたはサーバーにインストールする方法と変わりありません。VirtualBoxでゲストVMを設定するには、完全なリモートデスクトップをインストールしてvncなどを実行するのではなく、する代わりにコマンドライン(vboxmanage)を使用します。コマンドラインを使って行うほうがはるかに高速です。BridgeモードでVirtualBoxを実行して、OCIネイティブ・クラウド・ネットワーク機能(VCN/Subnet/IPアドレス、パブリックIP(NATなし)でさえも)にフルアクセスできるようにするには、 少々やるべきことがあります。
そのステップをご紹介します。私はたくさんスクリーンショットを貼り付けるタイプの人間ではないので、ほとんどが文章になってしまいますがご容赦を。

Step 1: Create an OCI VM and create/assign an extra VNIC to pass through to your VirtualBox VM.

OCIアカウントをお持ちでない場合は、サインアップして300ドルのクレジットトライアルアカウントを取得できます。始めるにはそれで十分のはずです。
Try for Free - Oracle Cloud
https://cloud.oracle.com/tryit
アカウントをセットアップし、サブネットを持つVCN(Virtual Cloud Network)を作成し、アベイラビリティ・ドメイン/リージョンの1つにVMインスタンスを作成します。テスト目的で、Oracle Linux 7のVM.Standard2.2シェイプ・インスタンスを作成しました。このインスタンスを作成すれば、ユーザーopcでログインして作業を開始できます。
VMインスタンスにログインします。OCI WebコンソールからプライマリVNICが接続されていることがわかります。これは、VMの内部ではens3になるかもしれません。 OCI Webコンソールでは、VNICには名前が付いています(通常、プライマリVNICの名前はインスタンス名と同じです)。プライベートIPを持っていて、パブリック・ネットワーク上におく場合はパブリックIPアドレスも使用します。これらすべてのものを、インスタンス作成の一環で標準で構成します。
VirtualBoxでBridgeネットワークを使用する方法をご紹介したいので、2番目のVNICが必要です。この時点で作成することもできますし、後で戻ってVirtualBox VMを起動する準備が出来てから作成することもできます。Webコンソール内(またはOCI CLIを使用)でAttached VNICsに移動し、特定のVCN/Subnet上にVNICを作成します。
create vnic
メモが必要な重要な情報は、この新しく作成されたvnicのMACアドレスとプライベートIPアドレスです。この例では、10.0.0.2と00:00:17:02:EB:EAで、後でこの情報が必要です。

Step 2: Install and configure VirtualBox

Oracle Linux 7を使う場合、非常に簡単です。yumを使用してVirtualBoxとVirtualBoxカーネルモジュールをビルドするための依存関係をインストールし、速やかにExtension Packをダウンロードしてインストールすれば完了です。
# yum install -y kernel-uek-devel-`uname -r` gcc
# yum install -y VirtualBox-5.2
# wget https://download.virtualbox.org/virtualbox/5.2.8/Oracle_VM_VirtualBox_Extension_Pack-5.2.8.vbox-extpack
# vboxmanage extpack install Oracle_VM_VirtualBox_Extension_Pack-5.2.8.vbox-extpack
これで完了です。OCI VMインスタンスのOracle Linux 7上に全ての機能を利用可能なVirtualBoxハイパーバイザがインストールされました。

Step 3: Create your first VirtualBox guest VM

以下の手順は、コマンドラインからVMを作成する方法です。コマンドラインを使用する場合のよい点は、VMを構成するために必要なことを明確に理解でき、値(メモリ、ディスクなど)を簡単に調整できる点です。

まず、インストーラのISOイメージから新しいVMを作成したい場合は、インストール・メディアをOCI VMにアップロードしてください。 ここでは、以下のURLから入手できるOracle Linux 7.5のプレビューイメージをアップロードしました。
Developer Preview for Oracle Linux 7
http://www.oracle.com/technetwork/server-storage/linux/downloads/linux-beta-4409163.html
VirtualBox VMの作成
# vboxmanage createvm --name oci-test --ostype oracle_64 --register
# vboxmanage modifyvm oci-test --memory 4096 --vram 128 --ioapic on
# vboxmanage modifyvm oci-test --boot1 dvd --boot2 disk --boot3 none --boot4 none
# vboxmanage modifyvm oci-test --vrde on
仮想ディスクとストレージコントローラの構成
当然ながら、OCIブロックストレージをVMにアタッチして、VirtualBoxの仮想ディスクをそのボリュームにおきます。以下の例では、40GBの仮想ディスクイメージを作成し、OL7.5 ISOをDVDイメージとしてアタッチしています。
# vboxmanage createhd --filename oci-test.vdi --size 40960
# vboxmanage storagectl oci-test --name "SATA Controller" --add sata --controller IntelAHCI
# vboxmanage storageattach oci-test --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium oci-test.vdi
# vboxmanage storagectl oci-test --name "IDE Controller" --add ide
# vboxmanage storageattach oci-test --storagectl "IDE Controller" --port 0 --device 0 --type dvddrive --medium /home/opc/OracleLinux-R7-U5-BETA-Server-x86_64-dvd.iso
Bridgeネットワーク・アダプタを構成して直接OCIのVNICに接続
これはやや複雑です。このセカンダリVNIC用にどのネットワークデバイスがVMホスト上に作成されているかを確認する必要があります。
# ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens3: mtu 9000 qdisc mq state UP qlen 1000
link/ether 00:00:17:02:3a:29 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.8/24 brd 192.168.1.255 scope global dynamic ens3
valid_lft 73962sec preferred_lft 73962sec
3: ens4: mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:00:17:02:eb:ea brd ff:ff:ff:ff:ff:ff
このネットワーク・アダプタをIPアドレスなしで起動し、MTUを9000(OCIにおけるVNICのデフォルトのmtu設定)に設定します。
# ip link set dev ens4 up
# ip link set ens4 mtu 9000 
あともう少しです。このタイミングでVirtualBoxでNICを作成し、以前に記録したMACアドレスをこのNICに割り当ててください。このMACアドレスを使用することが非常に重要で、そうしないとネットワーク上のトラフィックが許可されません。
注意:コマンドラインでは、macアドレスに:(コロン)を使用しないでください。
# vboxmanage modifyvm oci-test --nic1 bridged --bridgeadapter1 ens4 --macaddress1 00001702ebea
これでおしまいです。インストールメディアから起動し、OCIのホストネットワークに直接接続できる、起動可能なVirtualBox VMができました。このネットワークではDHCPは実行されていないので、VirtualBox VMを作成するときは、静的IPを割り当てなければなりません(上記の例では10.0.0.2)。
VMを起動する前に、ホスト上のリモートRDP接続用にファイアウォールを開き、OCIコンソールでも同じ操作を行います。ホストのプライマリVNICのセキュリティ・リストを変更して、ポート3389(RDP)へのインバウンドトラフィックを許可します。
# firewall-cmd --permanent --add-port=3389/tcp
# firewall-cmd --reload
Start your VM in headless mode ヘッドレスモードでVMを起動し、デスクトップやラップトップにあるお好みのRDPクライアントを使ってリモートのVirtualBoxコンソールに接続します。
# vboxmanage startvm oci-test --type headless
リモートの動画や音声(例えば、VM内でYouTubeビデオを再生したり、ムービーファイルを再生したい場合など)を試したい場合、vrdeビデオチャンネルを有効にします。 qualityパラメータを使用して、mjpegストリームの圧縮/損失率(パフォーマンスを向上させます)を変更します。
# vboxmanage modifyvm oci-test --vrdevideochannel on
# vboxmanage modifyvm oci-test --vrdevideochannelquality 70

[Cloud, Network] Security in the Oracle Cloud with Fortinet Fortigate NGFW

$
0
0
原文はこちら
https://blogs.oracle.com/cloud-infrastructure/security-in-the-oracle-cloud-with-fortinet-fortigate-ngfw

パートナー・エコシステムを引き続き拡げている流れで、さまざまなカテゴリーにわたるクラス最高のプロバイダーが、Oracle Cloud Infrastructureに追加の機能/サービスを補完したり追加したりできるようになっています。本日はOracle Cloud InfrastructureでFortinet FortiGate-VM Next Generation Firewall (NGFW)をご利用いただけるようになったことを発表できうれしく思っています。
FortiGateの次世代ファイアウォールは、Oracle Cloud InfrastructureへのInbound/outboundトラフィックを安全に保護する、洗練されたIPsec VPN機能を提供します。また、extreme threat database、脆弱性管理、フローベースの検査作業といった高度な機能とともに、IPSおよびWebフィルタリング機能を利用できるため、協調して最新の複雑なセキュリティ脅威を特定し緩和します。セキュリティが強化されたFortiOSオペレーティングシステムは、マルウェアの検査と識別のために専用に設計されています。

FortiGate Virtual Appliances 

FortiGate仮想アプライアンスを使用すると、仮想インフラストラクチャ内でクリティカルなセキュリティ制御を実装することで、盲点を軽減できます。ファイアウォールのルール数の制限なく、アプリケーション制御、Webフィルタリング、IPS、AV(Anti Virus)およびマルウェア防止などの高度なセキュリティを提供します。また、いつでもどこでもセキュリティインフラストラクチャを迅速にプロビジョニングできますし、FortiGate仮想アプライアンスには、従来のハードウェアベースのFortiGateアプライアンスに共通するすべてのセキュリティおよびネットワーキングサービスが備わっています。Fortinetの仮想アプライアンスを追加すれば、ハードウェアと仮想アプライアンスを混在させて運用できます。その際、共通の集中管理プラットフォームから両者を管理できるので、オンプレミスのデータセンターからOracle Cloud Infrastructureまで、セキュアなIPsec VPNを使用してビジネスワークロードを拡張できます。

FortiOSは、FortiGate-VM multi-threat security platformの基盤です。セキュリティ、パフォーマンス、および信頼性のために開発された専用オペレーティングシステムが仮想化の力を活用します。

OCI Virtual Cloud Network: Secure, Fast Private Network

このエントリでは、Oracle Cloud InfrastructureにFortigateを統合することに焦点を当てます。Fortigateは、複数のアベイラビリティ・ドメインにあるOracle Cloud Infrastructureの仮想クラウド・ネットワーク(VCN)を活用して、高い可用性を持つ高度なネットワーク・ファイアウォール機能を提供します。


Oracleのお客様は最もセキュリティに敏感なエンタープライズ組織の要件を満たすように設計されたクラウドベースのネットワークアーキテクチャのメリットを享受します。しかし、多くのエンタープライズのお客様は、さらに特別なセキュリティソリューションも必要としています。エンタープライズのお客様は、Intrusion Prevention Service(侵入防止システム)、Anti Virus、およびMalware防止を含むNGFWサービスの完全なスイートを備えた仮想Fortigateアプライアンスを実装することで、突っ込んだアプローチで防御を行うことができます。

Fortigateのエンタープライズ・グレードの次世代ファイアウォールをOCIに迅速にプロビジョニング、展開できます。
Deploying FortiGate for OCI
http://cookbook.fortinet.com/deploying-fortigate-oci/
OracleとFortinetのパートナーシップで、Fortigate Oracle Cloud InfrastructureへのNGFWのデプロイとお客様のワークロード保護ののシームレスな体験を提供します。

スタートするには、以下のマーケットプレイスの情報をご覧ください。
Fortinet FortiGate-VM Next Generation Firewall (NGFW)
https://cloudmarketplace.oracle.com/marketplace/en_US/listing/28079749

[Linux, Network] Congestion Control algorithms in UEK5 preview - try out BBR

$
0
0
原文はこちら
https://blogs.oracle.com/wim/done-cancel-v6

UEK5の新機能の1つに、BBR(bottleneck bandwidth and round-trip propagation time、ボトルネック帯域幅と往復伝搬時間)と呼ばれる、新しいTCP輻輳制御管理アルゴリズムがあります。以下の論文が参考になります。
BBR Congestion Control
https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr-congestion-control-02.pdf
BBR, the new kid on the TCP block
https://blog.apnic.net/2017/05/09/bbr-new-kid-tcp-block/
Linuxはbic、cubic、westwood、hybla、vegas、h-tcp、venoなど、幅広く輻輳制御アルゴリズムをサポートしています。
TCP輻輳制御について(Wikipedia)
https://en.wikipedia.org/wiki/TCP_congestion_control
BBRを含む、重要なTCP輻輳制御の概要
https://blog.apnic.net/2017/05/09/bbr-new-kid-tcp-block/
これまで長く利用されてきたデフォルトアルゴリズムはcubicです(これはUEK5でも引き続きデフォルトです)。しかし、現在はBBRもサポートしています。メインラインのLinuxカーネルバージョン4.9にBBRが追加されました。UEK5ツリーは4.14のメインラインをベースにしていたため、UEK5でBBRを選択しました。UEKはGitHubから簡単にアクセスでき、コードを読むことができます。
Oracle Linux UEK: Unbreakable Enterprise Kernel
https://github.com/oracle/linux-uek
Tarファイルにしていないので、変更履歴を付けて全て取得してください(標準的なアップストリームカーネルの場合はバックポートや修正などを伴うgit)。
大規模なファイルをWAN経由でダウンロードまたはアップロードする場合に、BBRを使用して非常に有望なパフォーマンス改善が見られました。したがって、クラウドコンピューティングの使用や、オンプレミスとクラウド間のデータの移動など、状況によってはパフォーマンスが少し向上する可能性があります。いくつかのテストで10%ほどパフォーマンス向上を測定しましたが、状況はそれぞれ異なります。パケットロスが発生した場合は、確実に役立ちます。

UEKの優位性は、ソース、ターゲットのシステムをどちらもUEK上で実行する必要はない点です。そのため、BBRをテストするには、対向でOL7を実行し、UEK5をインストールした上で、当該システムでBBRを有効にするだけです。SSHやnetperf、wgetで大きなファイルをダウンロードしてみてください。
Oracle Linux 7 UEK5 (Linux kernel 4.14) sneak preview
https://blogs.oracle.com/wim/oracle-linux-7-uek5-linux-kernel-414-sneak-preview
https://orablogs-jp.blogspot.jp/2018/02/oracle-linux-7-uek5-linux-kernel-414.html
以下を実行する必要があります。再起動は不要です。
  • 2ノードのうち1個にOracle Linux 7をインストール
  • UEK5プレビューカーネルをインストールし、起動
  • (rootユーザーで)sysctlを使い設定を変更し、BBRを有効化(オンラインで設定可)
また、(デフォルトの)pfifo_fastの代わりにキュー規律(queue discipline)をfqに設定する必要もあります。
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.core.default_qdisc=fq
デフォルトに戻すには
sysctl -w net.ipv4.tcp_congestion_control=cubic
sysctl -w net.core.default_qdisc=pfifo_fast
pfifo_fast vs fqも切り替えてみてください。

必要に応じて、Linuxの個々のソケットレベルで設定できます。あなたが特定のアプリケーション(Webサーバやデータ転送プログラムのようなもの)を持っている場合には、setsockopt()を使います。以下は設定例です。
sock = socket(AF_INET, SOCK_STREAM, 0);
sockfd = accept(sock, ...);
strcpy(optval, "bbr");
optlen = strlen(optval);
if (setsockopt(sockfd, IPPROTO_TCP, TCP_CONGESTION, optval, optlen) < 0)
error("setsockopt(TCP_CONGESTION) failed");
Python(Python 3.6以上)でも同じようにできます。
sock.setsockopt(socket.IPPROTO_IP, socket.TCP_CONGESTION,...)
是非楽しんでください。みなさんにもメリットがあるか、どんなときにメリットがあるかお知らせください。

[Integration, Cloud] Oracle Integration Cloud (OIC) - File-based Integration Best Practices

$
0
0
原文はこちら。
https://blogs.oracle.com/fmw/oracle-integration-cloud-oic-file-based-integration-best-practices

Introduction

Oracle Integration Cloud Service (OIC) では、幅広いユースケースやシナリオをサポートするため、ファイルの受信および処理に対し、いくつかのデザインおよびモデリング上の選択肢を用意しています。ファイルをOICでSecure Shell (SSH) File Transfer Protocol (sFTP) SSH経由で受け取ったり、REST/SOAP/HTTPインターフェースで受け取ったりできます。このエントリの目的は、ファイルサイズやコンテンツのフォーマット、Outboundへの配信方法に基づいて、重要な設計上の選択肢を紹介することにあります。また、OICでの重要なオーケストレーション手順に含まれる、Fusion Applicationのファイルベースの統合パターンもご紹介します。

ファイルベースのOracle Fusion Applicationとの統合にはいくつかのパターンがあります。以下はその例です。
  • ERP CloudはFile Based Data Integration (FBDI) インターフェースを使ったバルクデータ・インポートをサポート
  • HCM CloudはHCM Data Loader (HDL) を使ったバルクデータ・インポートをサポート
  • CRM Cloudは同様のパターンをサポート
  • ERP Cloud Bulk Extracts (BI PublisherやBI Cloud Connectorを利用) では、ファイルをUCMもしくはsFTPサーバに配信
  • 請求書、発注書やその他のサポート対象のドキュメントといった添付ファイルをERPやHCMにアップロード
詳細は、以下の各クラウドサービスのドキュメントをご覧ください。
File-Based Data Import for Oracle Financials Cloud Release 13 (update 18A)
External Data Integration Services for Oracle Cloud: Overview
https://docs.oracle.com/en/cloud/saas/financials/r13-update18a/oefbf/External-Data-Integration-Services-for-Oracle-Cloud-Overview.html
Oracle Human Capital Management Cloud Integrating with HCM Release 13 (update 18A)
HCM Data Loader: Overview
https://docs.oracle.com/en/cloud/saas/applications-common/r13-update18a/faihm/introduction-to-hcm-data-loader.html#FAIHM2243095
File-Based Data Import for Oracle Sales Cloud Release 13 (update 18A)
File-Based Data Import for Oracle Sales Cloud: Overview
https://docs.oracle.com/en/cloud/saas/applications-common/r13-update18a/oefbs/FileBased-Data-Import-for-Oracle-Sales-Cloud-Overview.html
ERPのFBDI、HCMのHDLおよびCRMの全てのファイルベースの統合では、CSV形式でそれぞれのオブジェクトテンプレートに基づきデータファイルを生成する必要があります。このファイルは、オンプレミスシステムまたは他のクラウドアプリケーションによって生成され、OICが処理できるよう、sFTPサーバーにアップロードされます。ファイルをFusion Applications Content Server(UCM)にアップロードすることもできます。
OICの統合フローは、ファイルを取得し、オプションとして、enrichmentや変換などのアクションでファイルのコンテンツを処理して、Fusion Applicationsのそれぞれのオブジェクトのデータファイルを生成します。データファイルがそれぞれのオブジェクトテンプレートに従ってオンプレミスシステムで生成された場合、OICはこのファイルをERPまたはHCM Cloudにパススルーしてインポートプロセスを開始できます。
同様に、ファイルをFusion Applicationsから抽出し、UCMサーバを介してOICに配信されます。 UCMサーバーは、Fusion Applications内にあり、このUCMサーバーには抽出されたファイルが配信され、後工程の処理のためにファイルが格納されています。
下表は、展開後のファイルサイズに基づいてファイルベースの統合フローを設計するためのハイレベルの決定モデルです。

Table 1 - インターフェースがサポートするファイルサイズ
 (展開後のファイルサイズに基づく)

オリジナルの
ファイルサイズ
Inbound
インターフェース
ランタイムの
考慮点
Outbound
インターフェース
<= 1MB任意のアダプタ制限なし任意のアダプタ(送信ファイルサイズが10MB以下)
BASE64エンコーディング、ファイル添付をサポート
1MB ~ 10MB任意のアダプタパススルーの場合は制限なし

ファイル処理する場合の制限事項
XMLもしくはCSV形式のみサポート
StageFile - ファイルのセグメント読み取りを利用(ファイル全体の読み込みは非サポート)
    任意のアダプタ
    BASE64エンコーディング、ファイル添付をサポート
    10MB ~ 500MBFTP、REST、SOAPアダプタパススルーの場合は制限なし

    ファイル処理する場合の制限事項
    XMLもしくはCSV形式のみサポート
    StageFile - ファイルのセグメント読み取りを利用(ファイル全体の読み込みは非サポート)
      添付のみ
      ファイル添付をサポートする任意のアダプタ(FTP、REST、SOAP)
      500MB以上

      (注意)
      ファイルサイズの最大値は並列度、利用可能なリソース、I/Oタイムアウトの考慮事項に依存
      (デフォルトは300秒)
      FTP、REST、SOAPアダプタパススルーの場合は制限なし

      ファイル処理する場合の制限事項
      XMLもしくはCSV形式のみサポート
      StageFile - ファイルのセグメント読み取りを利用(ファイル全体の読み込みは非サポート)
        添付のみ
        ファイル添付をサポートする任意のアダプタ(FTP、REST、SOAP)

        全てのファイル送受信で、アップロード/ダウンロードは自動的に300秒を超えるとタイムアウトします。

        OIC Design/Modeling Consideration

        ファイルサイズ、コンテンツ形式、および処理要件によって、OICで統合フローをモデル化する方法が決まります。下表は、ファイルサイズ、コンテンツ、パススルーもしくはOIC内での処理が必要かどうか(Fusion Applicationsがそれぞれのオブジェクトまたはインターフェイスでサポートするファイルを生成するためのEnrichmentや変換アクションが必要かどうか)に基づいて、統合フローを設計する方法を示しています。

        Table 2 - 決定モデル(ファイルサイズは展開後のファイルに基づく)
        InboundファイルインターフェースInbound 展開後のファイルサイズ主要なオーケストレーションの手順Outboundファイルサイズファイル配信形態Outboundインターフェース
        1FTP
        (File ReadもしくはStageFile -Readでファイル全体を読み取り)

        展開後のファイルのみ
        コンテンツ形式はXMLもしくはCSV
          (注意)
          ファイルサイズにかかわらず、バイナリファイルに対しては使わないこと(バイナリファイルの場合、FTPでファイルダウンロードを推奨)
          <= 1MB1. FTP - Read FileもしくはStageFile - Readでファイル全体を読み取り
          2. Enrichmentや変換を実行
          3. StageFile - Writeでターゲットファイルを生成(注意:並列"for each"内で利用するWrite操作はCSV形式のみサポート)
          4. StageFile - Zipで圧縮
          5. FTP/SOAP/REST - 配信(encodeReferenceToBase64関数もしくは添付を利用)
            <= 10MBBASE64、もしくは添付
              任意
              2FTP

              展開後のファイル、もしくは圧縮ファイル
              コンテンツ形式はXMLもしくはCSV

              (注意)
              バイナリファイルはStageFile操作で読み取り不可
              <=10MB1. FTP - ファイルのリスト取得
              2. FTP - ファイルダウンロード
              3. StageFile - ファイルのセグメント読み取り
              4. Enrichmentや変換を実行
              5. StageFile - ターゲットファイルを生成(注意:並列"for each"内で利用するWrite操作はCSV形式のみサポート)
              6. StageFile - Zipで圧縮
              7. FTP/SOAP/REST - 配信(encodeReferenceToBase64関数もしくは添付を利用)
                <= 10MBBASE64、もしくは添付
                  任意
                  3FTP
                  (2と同じだが、ファイルサイズが10MBを超える場合)

                  (注意)
                  バイナリファイルはStageFile操作で読み取り不可
                  >10MB1. FTP - ファイルのリスト取得
                  2. FTP - ファイルダウンロード
                  3. StageFile - ファイルのセグメント読み取り
                  4. Enrichmentや変換を実行
                  5. StageFile - ターゲットファイルを生成(注意:並列"for each"内で利用するWrite操作はCSV形式のみサポート)
                  6. StageFile - Zipで圧縮
                  7. FTP/SOAP/REST - 配信(添付のみ利用可)
                    > 10MB添付のみFTP
                    SOAP
                    REST
                    4
                    4) REST
                    統合フローのOICインターフェース、Base64を利用

                    展開後のファイル、もしくは圧縮ファイル
                    コンテンツ形式はXMLもしくはCSV

                      (注意)
                      バイナリファイルはStageFile操作で読み取り不可
                      <= 10MB1. Mapperでファイル参照(decodeReferenceFromBase64 もしくはAttachmentを利用)
                      2. StageFile - Zipファイルを展開
                      3. StageFile - ファイルのセグメント読み取り
                      4. Enrichmentや変換を実行
                      5. StageFile - ターゲットファイルを生成(注意:並列"for each"内で利用するWrite操作はCSV形式のみサポート)
                      6. StageFile - Zipで圧縮
                      7. FTP/SOAP/REST - 配信(encodeReferenceToBase64関数もしくは添付を利用)
                      <= 10MBBASE64、もしくは添付
                        任意
                        5
                        REST
                        統合フローのOICインターフェース、添付を利用

                        展開後のファイル、もしくは圧縮ファイル
                        コンテンツ形式はXMLもしくはCSV

                        (注意)
                        バイナリファイルはStageFile操作で読み取り不可
                        > 10MB1. Mapperでファイル参照
                        2. StageFile - Zipファイルを展開
                        3. StageFile - ファイルのセグメント読み取り
                        4. Enrichmentや変換を実行
                        5. StageFile - ターゲットファイルを生成(注意:並列"for each"内で利用するWrite操作はCSV形式のみサポート)
                        6. StageFile - Zipで圧縮
                        7. FTP/SOAP/REST - 配信(添付のみ利用可)
                          > 10MB添付のみFTP
                          SOAP
                          REST
                          6中間SOAP/RESTレスポンス・ペイロードのファイル

                          展開後のファイル、もしくは圧縮ファイル
                          コンテンツ形式はXMLもしくはCSV

                          (注意)
                          バイナリファイルはStageFile操作で読み取り不可
                          <= 10MB1. Mapperでファイル参照(decodeReferenceFromBase64 もしくはAttachmentを利用)
                          2. StageFile - Zipファイルを展開
                          3. StageFile - ファイルのセグメント読み取り
                          4. Enrichmentや変換を実行
                          5. StageFile - ターゲットファイルを生成(注意:並列"for each"内で利用するWrite操作はCSV形式のみサポート)
                          6. StageFile - Zipで圧縮
                          7. FTP/SOAP/REST - 配信(encodeReferenceToBase64関数もしくは添付を利用)
                            <= 10MBBASE64、もしくは添付
                              任意
                              76と同上だが、ファイルサイズが10MBを超える場合

                              (注意)
                              バイナリファイルはStageFile操作で読み取り不可
                              > 10MB1. Mapperでファイル参照
                              2. StageFile - Zipファイルを展開
                              3. StageFile - ファイルのセグメント読み取り
                              4. Enrichmentや変換を実行
                              5. StageFile - ターゲットファイルを生成(注意:並列"for each"内で利用するWrite操作はCSV形式のみサポート)
                              6. StageFile - Zipで圧縮
                              7. FTP/SOAP/REST - 配信(添付のみ利用可)
                              > 10MB添付のみFTP
                              SOAP
                              REST

                              Fusion Applications - SaaS Common Use Cases with file-based integrations


                              Table 3 - Fusion Applicationでのユースケース
                              ユースケースOICの主要なオーケストレーション手順
                              1sFTPサーバからデータファイルを取得し、圧縮データファイルをERP/HCM/UCM SOAP統合インタフェースにパススルーで送信する場合

                              (注意)
                              圧縮後のファイルサイズ:10MB以下
                              コンテンツ形式:XMLもしくはCSV
                              (バイナリファイルはパススルーのみ)

                                - FBDIまたはHDLバルクインポートを利用。それぞれのテンプレートに従ってデータファイルを生成する。ERPまたはHCM Cloudへのデータファイル・インポートプロセスを開始する前に、変更や処理は不要。
                                - データファイルはパススルーするので、Enrichmentや変換をせずに表2のモデル2もしくは3の利用を検討する
                                  1. FTP - ファイルリスト取得
                                  2. FTP - ファイルダウンロード
                                  3. Mapper - encodeReferenceToBase64関数の利用もしくは添付
                                  4. Outbound - Base64もしくは添付
                                    21と同様だが、ファイルサイズが10MBを超える場合


                                    - FBDIまたはHDLバルクインポートを利用。それぞれのテンプレートに従ってデータファイルを生成する。ERPまたはHCM Cloudへのデータファイル・インポートプロセスを開始する前に、変更や処理は不要。
                                    - データファイルはパススルーするので、Enrichmentや変換をせずに表2のモデル3の利用を検討する

                                    1. FTP - ファイルリスト取得
                                    2. FTP - ファイルダウンロード
                                    3. Mapper - 添付のみ利用可
                                    4. Outbound - 添付のみ利用可
                                    3sFTPサーバからデータファイルを取得し、データファイルを処理(Enrichment、変換など)した上で、ERP/HCM/UCM SOAP統合インタフェースに送信する場合

                                    (注意)
                                    展開後のファイルサイズは10MBA以下
                                    コンテンツ形式はXMLもしくはCSV


                                    - FBDIまたはHDLバルクインポートを利用。ソースファイルを基にして、FBDIやHDLファイルを生成し、ターゲットファイル用にEnrichmentや変換をする必要がある。
                                    - 表2のモデル2もしくは3の利用を検討する

                                      1. FTP - ファイルリスト取得
                                      2. FTP - ファイルダウンロード
                                      3. Mapper - encodeReferenceToBase64関数の利用もしくは添付
                                      4. StageFile - ファイルのセグメント読み取り
                                      5. Enrichmentや変換を実行
                                      6. StageFile - ターゲットファイルを生成(注意:並列"for each"内で利用するWrite操作はCSV形式のみサポート)
                                      7. StageFile - Zipで圧縮
                                      8.  Outbound  - FTP/SOAP/REST
                                      MapperではencodeReferenceToBase64関数もしくは添付を利用
                                      43と同様だが、展開後のファイルサイズは10MBを超える場合


                                      - FBDIまたはHDLバルクインポートを利用。ソースファイルを基にして、FBDIやHDLファイルを生成し、ターゲットファイル用にEnrichmentや変換をする必要がある。
                                      - 表2のモデル3の利用を検討する

                                        1. FTP - ファイルリスト取得
                                        2. FTP - ファイルダウンロード
                                        3. Mapper - encodeReferenceToBase64関数の利用もしくは添付
                                        4. StageFile - ファイルのセグメント読み取り
                                        5. Enrichmentや変換を実行
                                        6. StageFile - ターゲットファイルを生成(注意:並列"for each"内で利用するWrite操作はCSV形式のみサポート)
                                        7. StageFile - Zipで圧縮
                                        8.  Outbound  - FTP/SOAP/REST
                                        Mapperでは添付のみ利用可

                                        5Fusion Application UCM サーバーからファイルを取得する場合

                                        (注意)
                                        展開後のファイルサイズは10MB以下
                                        コンテンツ形式はXMLもしくはCSV

                                        - ERP/BIP (BI Publisher) もしくはHCM Extractsが生成したファイル、もしくはsFTPサーバではなくUCMにアップロードされたソースファイルを、Fusion ApplicationのUCMからダウンロード
                                        - 表2のモデル6もしくは7の利用を検討する
                                          1. UCMのSOAPサービスの呼び出し
                                          2. SOAPアダプタの添付オプションを選択
                                          3. Mapper - encodeReferenceToBase64関数もしくは添付を利用
                                          4. StageFile - Zipファイルを展開
                                          5. StageFile - ファイルのセグメント読み取り
                                            6
                                            5と同様だが、ファイルサイズが10MBを超える場合

                                            - ERP/BIP (BI Publisher) もしくはHCM Extractsが生成したファイル、もしくはsFTPサーバではなくUCMにアップロードされたソースファイルを、Fusion ApplicationのUCMからダウンロード
                                            - 表2のモデル7の利用を検討する

                                              1. UCMのSOAPサービスの呼び出し
                                              2. SOAPアダプタの添付オプションを選択
                                              3. Mapper - 添付のみ利用可
                                              4. StageFile - Zipファイルを展開
                                              5. StageFile - ファイルのセグメント読み取り
                                                7
                                                SOAP/REST/HTTPインターフェースのレスポンス(メディアタイプはapplication/octet-stream)からファイルを取得する場合


                                                - SOAP/REST/HTTPレスポンスに添付されたファイルをダウンロード
                                                - 表2のモデル7の利用を検討する

                                                  1. SOAP/RESTインターフェース管理を呼び出し、レスポンス・ペイロードのファイルを取得
                                                  2. 添付オプションを選択(SOAP/RESTアダプタとも。APIは添付をサポートしている必要がある)
                                                  3. Mapper - 添付のみ利用可
                                                  4. StageFile - ファイルのセグメント読み取り
                                                    8
                                                    OIC/ICSのRESTインターフェースを使う場合(マルチパート)
                                                    OIC統合フローをRESTインターフェースで呼び出す際にファイルを受信する

                                                    (注意)
                                                    ファイルサイズは10MBを超える
                                                    コンテンツ形式はXMLもしくはCSV


                                                    - オンプレミスもしくは他のクラウドシステムからOICの統合フローを呼び出す

                                                    1. OICでファイルを受信(オンプレミスもしくはOIC以外のシステムから呼び出す)
                                                    2. Mapper - 添付のみ利用可
                                                    3. StageFile - ファイルのセグメント読み取り

                                                      Conclusion

                                                      このブログは、上記のベストプラクティスとFusion Applicationsまたは他のアプリケーションでの一般的なファイルベースの統合ユースケースに基づいて、OICの統合フローのモデリングを支援するために用意しました。ファイルサイズ、コンテンツ形式、および配信形態に基づいて、OIC内のファイル処理方法に関する詳細情報を提供しました。

                                                      [Cloud, Docker] Oracle Developer Cloud Service Adds Docker, Pipelines, and More

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/cloud-platform/oracle-developer-cloud-service-adds-docker%2c-pipelines%2c-and-more

                                                      Oracle Developer Cloud Serviceが4月のリリースで新機能が追加されました。このエントリではそのいくつかを簡単にご紹介します。

                                                      New Build & Continuous Integration Architecture

                                                      ビルドジョブのための専用ビルドサーバーを利用できるようになりました。ビルドサーバーはOracle Cloud Infrastructure Compute ClassicとOracle Cloud Infrastructure Object Storage Classicインスタンスを使います。専用サーバーを構成し、Oracle Developer Cloud Service内から直接種々のソフトウェアパッケージを含めることができます。
                                                      Configure Your Build Server
                                                      Image 1 : Customize your build server software stack
                                                      Oracle Storage Cloud Service Classicと統合すれば、ビルド間で永続的なMavenリポジトリを持つことができるだけでなく、ビルド成果物を格納する場所を提供できます。
                                                      この新しい専用の永続的なビルド・アーキテクチャで、ビルドの高速化が実現されることでしょう。

                                                      Build Pipelines

                                                      ビルドオーケストレーションを視覚的に定義できるようになりました。ビルドジョブをつなぎ、実行順序を視覚的にパイプラインを使って定義します。また、最新のステータスに基づいて色分けされたビルドパイプラインの進捗状況も表示します。
                                                      Build Pipelines
                                                      Image 2 : visualize your build pipeline

                                                      Docker Support

                                                      Continuous Integrationプロセスの一環としてDockerコンテナをビルド・パブリッシュできるようになりました。ビルド構成の新しいオプションでは、さまざまなDockerコマンドを呼び出す手順を定義できます。 さらに、Dockerレジストリへの接続を定義し、Dockerコンテナをパブリッシュできます。
                                                      docker build steps
                                                      image 3: Configuring a docker step as part of your build job

                                                      SonarQube Integration

                                                      SonarQubeとの統合が可能になりました。この結果、ビルドプロセスの一環としてコードを分析し、その結果を公開することができるようになりました。
                                                      Continuous Code Quality | SonarQube
                                                      https://www.sonarqube.org/
                                                      Sonarサーバーへの接続を定義して、ビルドのテスト結果を監視します。
                                                      Sonar Configuration
                                                      image 4: configure connection to SonarQube server
                                                      新機能の詳細は、以下のドキュメントをご覧ください。
                                                      What’s New in Oracle Developer Cloud Service - April 2018
                                                      https://docs.oracle.com/en/cloud/paas/developer-cloud/csdwn/index.html#CSDWN-GUID-88FCFA5A-9EA1-4E43-BF2B-7D5B647B5A07

                                                      [Cloud] Which PaaS are available on OCI?

                                                      $
                                                      0
                                                      0
                                                      OCI (Oracle Cloud Infrastructure) で利用可能なPaaSはDatabaseのみ、と思われている方が多いようですが、実は以下のドキュメントにある通り、Database以外にもいくつかのサービスがサポートされています。
                                                      Prerequisites for Oracle Platform Services on Oracle Cloud Infrastructure
                                                      Information About Supported Platform Services
                                                      https://docs.us-phoenix-1.oraclecloud.com/Content/General/Reference/PaaSprereqs.htm#supported
                                                      サービスドキュメント
                                                      Database Cloud ServiceAbout Database Deployments in Oracle Cloud Infrastructure
                                                      https://docs.oracle.com/en/cloud/paas/database-dbaas-cloud/csdbi/db-deployments-oci.html
                                                      Java Cloud ServiceAbout Java Cloud Service Instances in Oracle Cloud Infrastructure
                                                      https://docs.oracle.com/en/cloud/paas/java-cloud/jscug/instances-oracle-cloud-infrastructure.html
                                                      MySQL Cloud ServiceAbout MySQL Cloud Service Deployments
                                                      https://docs.oracle.com/cloud/latest/mysql-cloud/UOMCS/GUID-7F197ECD-1EA0-4423-B9C2-75B39C57E984.htm
                                                      Event Hub Cloud ServiceAbout Oracle Event Hub Cloud Service - Dedicated instances inOracle Cloud Infrastructure
                                                      https://docs.oracle.com/en/cloud/paas/event-hub-cloud/admin-guide/instancesonoci-eventhubdedicated.html
                                                      Data Hub Cloud ServiceAbout Oracle Data Hub Cloud Service Clusters in Oracle Cloud Infrastructure
                                                      https://docs.oracle.com/en/cloud/paas/data-hub-cloud/user/data-hub-cs-clusters-oci.html
                                                      Big Data CloudAbout Big Data Cloud Clusters in Oracle Cloud Infrastructure
                                                      https://docs.oracle.com/en/cloud/paas/big-data-compute-cloud/csspc/big-data-cloud-clusters-oracle-cloud-infrastructure.html
                                                      Oracle SOA Cloud ServiceAbout SOA Cloud Service Instances in Oracle Cloud Infrastructure Classic and Oracle Cloud Infrastructure
                                                      https://docs.oracle.com/en/cloud/paas/soa-cloud/csbcs/instances-oracle-cloud-infrastructure-classic-and-oracle-cloud-infrastructure.html

                                                      通常のOracle Cloud Infrastructure Classic上で構成する場合とは前提条件が違いますので、ドキュメントをよく読んでお試しください。
                                                      Prerequisites for Oracle Platform Services on Oracle Cloud Infrastructure
                                                      https://docs.us-phoenix-1.oraclecloud.com/Content/General/Reference/PaaSprereqs.htm

                                                      [Java] Announcing GraalVM: Run Programs Faster Anywhere

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

                                                      現在の仮想マシン(VM)は、特定の言語または非常に少数の言語に対してのみ、プログラムの高性能な実行を提供します。コンパイル、メモリ管理、ツールは、‘don’t repeat yourself’ (DRY) (重複を防ぐ)の原則に違反して、言語ごとに別々に管理されています。これは、VM実装者にとって大きな負担になるだけでなく、パフォーマンス特性、ツール、および設定が一貫しないために開発者にとっても大きな負担になります。さらに、異なる言語で書かれたプログラム間の通信には、高コストなシリアライズ、デシリアライズのロジックが必要です。最後に、高性能VMは、高いメモリフットプリントの重量プロセスで、埋め込みは困難です。
                                                      数年前、これらの欠点に対処するために、Oracle Labsは仮想マシンの新しいアーキテクチャを探索するための新しい研究プロジェクトを始めました。
                                                      Oracle Labs
                                                      https://labs.oracle.com
                                                      我々のビジョンは、すべてのプログラミング言語で高性能を提供する単一のVMを作成し、プログラム間の通信を容易にすることでした。このアーキテクチャは、メンテナンス性を向上させるために統一された、言語非依存のツールをサポートし、その組み込み可能性(embeddability)の結果、VMがスタック全体で利用できるようにすることを目指しています。
                                                      この目的に適うよう、このようなVMのビルドにあたって新しいアプローチを考案しました。長年にわたる研究開発の結果、我々は今、最初の本番環境で利用可能なリリースを発表する準備が整いました。
                                                      Practical partial evaluation for high-performance dynamic language runtimes
                                                      https://dl.acm.org/citation.cfm?id=3062381

                                                      Introducing GraalVM

                                                      本日、polyglot(多言語)な世界向けに設計された汎用仮想マシンGraalVM 1.0のリリースを発表しました。
                                                      GraalVM
                                                      http://www.graalvm.org/
                                                      GraalVMは、個々の言語に対し高いパフォーマンスを提供し、さらに多言語アプリケーションでパフォーマンスのオーバーヘッドをゼロにする相互運用性を提供します。GraalVMの場合、言語境界でデータ構造を変換するのではなく、オブジェクトと配列を別のプログラミング言語で直接使用できます。

                                                      シナリオとして、例えばNode.jsコードからJavaライブラリの機能にアクセスしたり、JavaからPython統計ルーチンを呼び出したり、Rを使用して別の言語で管理されるデータから複雑なSVGプロットを作成したりすることが考えられます。GraalVMを使用すると、開発者は現在のタスクを解決するのに最も生産的な言語を自由に使用できます。

                                                      GraalVM 1.0では以下の言語を実行できます。
                                                      • JVMベースの言語(Java、Scala、Groovy、Kotlinなど)
                                                      • JavaScript (Node.jsを含む)
                                                      • (CやC++、Rustで記述されたプログラムから生成された)LLVM バイトコード
                                                      • Ruby、R、Pythonの実験的バージョン
                                                      GraalVMは、スタンドアロンでも、OpenJDKやNode.jsのようなプラットフォームの一部としても、あるいはMySQLやOracle RDBMSなどのデータベースに埋め込まれていても実行できます。
                                                      Oracle Database Multilingual Engine (MLE)
                                                      https://oracle.github.io/oracle-db-mle/
                                                      アプリケーションは、標準化されたGraalVM実行環境を介してスタック全体に柔軟にデプロイできます。データ処理エンジンの場合、GraalVMは、実行中のプログラムにカスタム形式で保存されたデータを直接公開します。その際の変換オーバーヘッドはありません。
                                                      JVMベースの言語の場合、GraalVMは速やかに立ち上がり、メモリフットプリントの低い、プリコンパイルされたネイティブイメージを作成するメカニズムを提供します。イメージ生成プロセスは、メインのJavaメソッドから到達可能なコードを見つけるための静的解析を実行し、完全なAOT(Ahead-of-time)コンパイルを実行します。生成されたネイティブバイナリには、即時実行のためのマシンコード形式のプログラム全体が含まれています。 このネイティブバイナリを他のネイティブプログラムとリンクしたり、GraalVMコンパイラを包含して、GraalVMベースの言語をハイパフォーマンスで実行できるよう、JIT(Just-In-Time)コンパイルをサポートすることもできます。

                                                      GraalVMエコシステムの主な利点は、すべてのGraalVMデプロイメントに適用される言語に依存しないツールです。GraalVMのコア・インストールでは、言語に依存しないデバッガ、プロファイラ、およびヒープビューアを提供します。
                                                      GraalVM Debugging and Monitoring Tools
                                                      http://graalvm.org/docs/reference-manual/tools/
                                                      3rdパーティツールの開発者や言語開発者に対し、計測ツールAPIや言語実装APIを使用してGraalVMエコシステムを充実してもらうよう呼びかけています。GraalVMは言語レベルの仮想化レイヤーとして、すべての言語でツールと埋め込みを利用できるようにすることを目指しています。

                                                      GraalVM in Production

                                                      Twitterは、Scalaベースのマイクロサービスを実行するためGraalVMを本番環境に導入している企業の1つです。GraalVMコンパイラの積極的な最適化により、オブジェクトの割り当てが削減され、全体の実行速度が向上しています。この結果、ガベージコレクションに伴う休止が少なくなり、プラットフォームの実行に必要な計算能力が少なくて済みます。以下のプレゼンテーションでは、TwitterのJVMエンジニアが自身の詳細な体験とGraalVMコンパイラを使ってどのようにコストを低減しているかを説明しています。


                                                      現在のリリース1.0では、本番利用の場合、JVMベースの言語と(Node.jsを含む)JavaScriptを推奨しています。R、Ruby、Python、LLVMベースの言語はまだ実験的な段階です。

                                                      Getting Started

                                                      GitHub上のGraalVMオープンソースリポジトリから構築したGraalVM v1.0(リリース候補)Community Edition(CE)のバイナリは以下のURLからご利用いただけます。
                                                      GraalVM Community Edition 1.0 RC1
                                                      https://github.com/oracle/graal/releases
                                                      このリリース候補版に対し、コミュニティからのフィードバックを求めています。GitHubのIssueやGitHubのプルリクエストの形でフィードバックを承っています。
                                                      Issues
                                                      https://github.com/oracle/graal/issues
                                                      Pull Requests
                                                      https://github.com/oracle/graal/pulls
                                                      GraalVM CEに加え、本番環境でのセキュリティ、スケーラビリティ、パフォーマンス向上を目的として、GraalVM v1.0(リリース候補)Enterprise Edition(EE)を提供します。GraalVM EEはOracle Cloud Infrastructureで利用可能で、評価のためにOracle Technology Networkからダウンロードできます。 GraalVM EEの本番利用に関しては、graalvm-enterprise_grp_ww@oracle.comまでご連絡ください。

                                                      Stay Connected

                                                      最新のインストーラとドキュメントは以下のURLにあります。
                                                      GraalVM
                                                      http://www.graalvm.org/
                                                      GitHubリポジトリで、開発状況、リクエスト・エンハンスメント、または問題の報告をチェックしてください。
                                                      GraalVM: Run Programs Faster Anywhere
                                                      www.github.com/oracle/graal
                                                      以下のGraalVMメーリングリストに登録することをお勧めします。
                                                      • graalvm-announce@oss.oracle.com
                                                      • graalvm-users@oss.oracle.com
                                                      • graalvm-dev@oss.oracle.com
                                                      Twitterのアカウント @graalvm でTweetします。ハッシュタグ #GraalVM でツイートやスタックオーバーフローに関する質問をチェックしています。

                                                      Future

                                                      この最初のリリースは始まりにすぎず、GraalVMのあらゆる側面の改善、特にPython、R、Rubyのサポートのために取り組んでいます。

                                                      GraalVMはオープンなエコシステムであり、独自の言語やツールを作成することをお勧めします。GraalVMは、標準化された言語実行と言語に依存しない豊富なツールを可能にする共同プロジェクトにしたいと考えています。詳細はwww.graalvm.orgを参照してください。
                                                      みなさまと一緒にPolyglotな世界のためのこの次世代テクノロジーを作っていくことを楽しみにしています。

                                                      [Linux] Announcing the release of Oracle Linux 7 Update 5

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/linux/announcing-the-release-of-oracle-linux-7-update-5

                                                      Oracleはx86_64アーキテクチャ向けのOracle Linux 7 Update 5の一般提供を発表します。個々のRPMパッケージはUnbreakable Linux Network (ULN) とOracle Linux Yumサーバで確認できます。
                                                      Unbreakable Linux Network (ULN)
                                                      https://linux.oracle.com/
                                                      Oracle Linux yum server
                                                      https://yum.oracle.com/
                                                      ISOインストールイメージはまもなくOracle Software Delivery Cloudからダウンロードできるようになる予定です。
                                                      Oracle Software Delivery Cloud
                                                      http://edelivery.oracle.com/new
                                                      Oracle Container Registry
                                                      https://container-registry.oracle.com/
                                                      Docker Hub
                                                      https://hub.docker.com/_/oraclelinux/
                                                      Oracle Linux 7 Update 5には、以下のカーネルパッケージが同梱されています。
                                                      • x86-64アーキテクチャ用Unbreakable Enterprise Kernel (UEK) Release 4 (kernel-uek-4.1.12-112.16.4.el7uek)
                                                      • x86-64アーキテクチャ用Red Hat Compatible Kernel (kernel-3.10.0-862.el7)

                                                      Application Compatibility

                                                      Oracle Linuxは、Red Hat Enterprise Linux(RHEL)とのユーザー空間の互換性を維持しています。これはオペレーティング・システムの基礎となるカーネル・バージョンとは独立しています。ユーザー空間内の既存のアプリケーションは、Oracle Linux 7 Update 5+UEK Release 4の組み合わせ上で、修正無しでそのまま実行できます。Red Hat Enterprise Linux 7またはOracle Linux 7ですでに動作保証済みのアプリケーションでは再度認証する必要はありません。

                                                      Notable security-related features in this release:

                                                      • 最近のIntelプロセッサーのメモリー保護キーのサポート
                                                        このアップデートには、最新のIntelプロセッサー上のメモリー保護キーハードウェア機能のサポートが含まれています。CPUは、各キーに対して2つの別個のビット(アクセス禁止と書き込み禁止)を含む新しいユーザーアクセス可能なレジスタ(PKRU)を通してこのサポートを提供します。
                                                      • 起動プロセス中にネットワークに接続された暗号化されたデバイスのロックを解除する機能以前は、ネットワークに接続されたブロックデバイスは、ネットワークサービスを開始する前にこれらのデバイスを接続および復号化できなかったため、ブートプロセス中にロックを解除できませんでした。
                                                      • mod_sslでのSSLv3の無効化
                                                        SSL/TLS接続のセキュリティ改善のため、httpd mod_sslモジュールのデフォルト構成でSSLv3のサポートを無効にしています。この変更が特定の暗号化サイファースィートの利用が制限されます。
                                                      • KASLR for KVMゲスト向けKASLRの追加 guests added.
                                                        KVMゲスト用のカーネルアドレス空間レイアウトのランダム化(KASLR)機能が追加されました。
                                                      Oracle Linux 7.5では、Btrfsが引き続き完全にサポートされています。Btrfsのサポートは、Red Hat Compatible Kernelでは廃止予定になっています。
                                                      これらの機能やその他の新機能、変更点の詳細は、Oracle Linux Documentation LibraryのOracle Linux 7 Update 5リリースノートを参照してください。
                                                      Oracle Linux 7 Update 5 Release Notes
                                                      https://docs.oracle.com/cd/E52668_01/E93593/html/index.html
                                                      Operating Systems Documentation - Oracle Linux
                                                      https://docs.oracle.com/en/operating-systems/linux.html
                                                      Oracle Linuxは無料でダウンロード、利用、配布でき、すべてのアップデートと正誤表に無料で入手でき、お客様がサポート契約の必要なシステムを決定します。
                                                      Oracle Linux Support
                                                      https://www.oracle.com/linux/index.html#support
                                                      そのため、Oracle Linuxは開発、テスト、および運用システムに最適です。 お客様は、すべてのシステムを最新かつ安全に保ちつつ、個々のシステムに対してどのサポートカバレッジが最善かを判断します。
                                                      Oracle Linux Premierサポートをご利用のお客様は、Ceph Storage、Oracle Linuxソフトウェア・コレクション、Oracle OpenStack、Oracle Kspliceを使用したゼロ・ダウンタイム・カーネル・アップデートといった、追加のLinuxプログラムもサポートされます。
                                                      Oracle Linuxの詳細については、以下のURLをご覧ください。
                                                      Oracle Linux
                                                      https://www.oracle.com/linux/index.html
                                                      https://www.oracle.com/jp/linux/index.html

                                                      [misc.] JavaOne Event Expands with More Tracks, Languages and Communities – and New Name

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/developers/javaone-event-expands-with-more-tracks-languages-and-communities-and-new-name

                                                      JavaOneが拡大し、より多くの言語、テクノロジー、開発者コミュニティを含む、新たなより大きいイベントに生まれ変わります。開発者が期待しているJavaのテクニカルコンテンツだけでなく、Go、Rust、Python、JavaScript、Rについてのセッションにも期待してください。この新しいイベントOracle Code Oneは、10/22から10/25まで、San FranciscoのMoscone Westで開催します。

                                                      Oracle Code OneではJavaチームのアーキテクトによる、最新のJavaプラットフォームに関する情報をご紹介するテクニカルキーノートを開催予定です。この中で、Java 11に関する最新の詳細情報、OpenJDKの最新情報、およびその他のコアなJava開発についても説明します。現在、Jakarta EE(現在はEclipse Foundationの一部)、Spring、Javaマイクロサービスやコンテナの最新情報など、サーバーサイドのJava EEテクノロジーの専用トラックを計画しています。その他、クライアント開発、JVM言語、IDE、テストフレームワークなどの豊富なコミュニティによるコンテンツも計画しています。

                                                      拡張に伴い、chatbot、マイクロサービス、AI、ブロックチェーンなどの最先端のトピックにもご期待ください。また、弊社のOracle JET、Project Fn、OpenJFXなど、最新のオープンソース開発者テクノロジーに関するセッションも予定しています。

                                                      最後に、このカンファレンスを引き続き盛り上げる要素の1つに、若手開発者のためのOracle Code4Kidsワークショップ、地元のJUGリーダーによるIGNITEライトニングトーク、Developer Loungeでのテクノロジーデモやコミュニティプロジェクトの展示といった、幅広いコミュニティによる活動があります。Developer Community Keynoteでのグランドフィナーレでこの週のテクノロジー、コミュニティイベントを締める予定です。

                                                      本日、Oracle Code OneのCall for Paperの受付を開始しました。Java開発者、データベース開発者、フル・スタック開発者、DevOps実践者、およびコミュニティ・メンバーのための11トラックのコンテンツに応募できます。

                                                      JavaOneのこの拡張について、筆者と同じくわくわく感を感じていただき、Oracle Code One最初の年にご参加いただけることを願っています。

                                                      Call for Paperは以下から応募ください。
                                                      Oracle Code One 2018
                                                      https://www.oracle.com/code-one/index.html

                                                      [Linux] An Update on Retpoline-enabled Kernels for Oracle Linux

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/linuxkernel/an-update-on-retpoline-enabled-kernels-for-oracle-linux

                                                      1月に、研究者らは、MeltdownとSpectreと呼ばれる投機的実行の欠陥を明らかにしました。Oracleは以下のサポート・ノートで公式ガイダンスを公開しました。
                                                      Meltdown and Spectre
                                                      https://meltdownattack.com/
                                                      Responding to the Spectre and Meltdown vulnerabilities (CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754) in Oracle Linux and Oracle VM on Oracle X86 Servers (Doc ID 2370398.1)
                                                      https://support.oracle.com/rs?type=doc&id=2370398.1
                                                      当時、特別なIntelのマイクロコードに依存したこれらのセキュリティ問題の軽減策をリリースしましたが、最新のカーネルリリースkernel-uek-4.1.12-112.16.4には、Spectre Variant 2(CVE-2017-5715)のより高速な、retpolineベースの軽減が含まれています。
                                                      [El-errata] ELBA-2018-4050 Oracle Linux 6 Unbreakable Enterprise kernel bug fix update
                                                      https://oss.oracle.com/pipermail/el-errata/2018-March/007581.html
                                                      このカーネルは、Oracle Linux 7とOracle Linux 6の両方で使用できます。UEK Release 2、UEK Release 3、そしてOracle Linux 6および7のRed Hat Compatible Kernel向けの既存のパッチとあわせ、Oracle LinuxのSpectre and Meltdownの脆弱性に対する最新のソフトウェア軽減策を提供します。
                                                      [El-errata] ELBA-2018-4050 Oracle Linux 6 Unbreakable Enterprise kernel bug fix update
                                                      https://oss.oracle.com/pipermail/el-errata/2018-March/007581.html
                                                      [El-errata] ELBA-2018-4050 Oracle Linux 7 Unbreakable Enterprise kernel bug fix update
                                                      https://oss.oracle.com/pipermail/el-errata/2018-March/007580.html
                                                      全てのソースコードはGitHubで公開済みです。
                                                      oracle/linux-uek - v4.1.12-112.16.4
                                                      https://github.com/oracle/linux-uek/releases/tag/v4.1.12-112.16.4
                                                      Development Versions of Oracle Linux UEK now available on GitHub
                                                      https://blogs.oracle.com/linuxkernel/development-versions-of-oracle-linux-uek-now-available-on-github
                                                      https://orablogs-jp.blogspot.com/2018/04/development-versions-of-oracle-linux.html
                                                      Oracleはまた、1月にIBRS/IBPB軽減策を使用してSpectre Variantの緩和策をXenに移植しました。Oracle VM 3.4でXenのretpoline軽減策をリリースしようとしています。これにより、サポートされているすべてのハイパーバイザー(Oracle VM 3.2、Oracle VM 3.3、Oracle VM 3.4、およびkvm)へのMeltdown/Specterタイプの攻撃から完全に保護されます。

                                                      Retpolinesの利点については、以下のIntelのホワイトペーパーとgoogle.comのサポート記事を参照してください。
                                                      Retpoline: A Branch Target Injection Mitigation
                                                      https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
                                                      Retpoline: a software construct for preventing branch-target-injection
                                                      https://support.google.com/faqs/answer/7625886
                                                      Retpolinesは、間接的な分岐を投機的な実行から隔離するコンパイラによって実行されるソフトウェアによる軽減策です。"return trampoline"から派生したretpolineを使う軽減策は、マイクロコードベースの軽減策よりも大幅にパフォーマンスのオーバーヘッドが少なく、とあるワークロードでは、パッチ適用前のレベルに近いパフォーマンスが得られる可能性があります。

                                                      Retpolinesは、Oracle Linux 7(およびOracle Linux 6)で使用可能なretpoline対応のgccコンパイラを使用して、カーネル(およびカーネルモジュール)を再コンパイルすることで有効になります。
                                                      [El-errata] ELBA-2018-0408 Oracle Linux 7 gcc bug fix update
                                                      https://oss.oracle.com/pipermail/el-errata/2018-March/007569.html
                                                      [El-errata] ELBA-2018-0513 Oracle Linux 6 gcc bug fix update
                                                      https://oss.oracle.com/pipermail/el-errata/2018-March/007583.html
                                                      Oracleのコンパイラエキスパートは、このサポートをgcc-4.8およびgcc-4.4コンパイラに移植しました。このコンパイラはyum.oracle.comで公開されています。これがOracle Linuxでretpoline対応のカーネルを使用できるようにするための前提条件でした。この結果、Oracle Linuxはコンパイラ機能を使用して、Spectre Variant 2攻撃に対してカーネルを自己保護することができます。アプリケーションの再コンパイルは必要ありません。

                                                      retpolineを使用する代わりに、IBRS(Indirect Branch Restricted Speculation)を使うこともできます。これはIntelの最新のマイクロコードのアップデートで定義された特別なSPEC_CTRL MSR(モデル固有のレジスタ)を呼び出します。IBRSはマイクロコードを使用してセキュリティ上の脆弱性を軽減します。 IBRSは、とあるワークロードではパフォーマンスが大幅に低下します。retpolineが利用可能である場合でも、もう一つの軽減策であるMSR、IBPB(Indirect Branch Predictor Barrier)も特定のユースケースでは以前として利用されています。

                                                      retpolinesを軽減策として利用する上での注意点がいくつかあります。まず、ハードウェアがretpolineをサポートしなければなりません。最新のハードウェアによっては、retpolineの軽減策を無視して命令を推測する場合があります。第2に、ロード可能なカーネルモジュールもretpoline対応のコンパイラでコンパイルする必要があります。そうしないと、カーネルは依然として脆弱なままです。

                                                      最新のkernel-uekは、これらの各条件を自動的に検出し、マイクロコードベースのIBRS軽減策を有効にします。フォールバックであるIBRS軽減策の場合、システムにアップデート済みのマイクロコードが存在している必要があります。したがって、ハードウェアベンダーから提供される利用可能な最新のシステムマイクロコードに更新することを常にお勧めします。アップデートされたIntelのマイクロコードには、SPEC_CTRL MSRが導入されていますが、それを呼び出すことはしません。カーネルはMSRを起動する必要があるからです。このカーネルの挙動はユーザーが有効または無効にできます。そのため、IBRSを無効にする予定のシステムに更新されたマイクロコードをロードしてもパフォーマンスに影響はありません。

                                                      ゲスト(仮想マシン)システムではマイクロコードを更新する必要はありません。ホストシステムに正しいマイクロコードを有しており、アップデートされたソフトウェア(Xenまたはqemu)があれば、ハイパーバイザーはゲストを保護するために必要なMSRをパススルーします。

                                                      サードパーティのカーネルモジュール
                                                      サードパーティ製のカーネルモジュールは、retpoline対応のコンパイラで再コンパイルする必要があります。UEKでは、以前にコンパイルされたモジュールがロードされることをkABI(Kernel Application Binary Interface)が保証していますが、これらのモジュールがretpolineに対応していない場合、カーネル全体がIBRS保護を再び有効にし、retpolinesのパフォーマンス上の利点は失われます。

                                                      Repolinesは必須ではない
                                                      Retpolineが有効になっているカーネルはパフォーマンスが向上しますが、retpolinesがなくてもセキュリティパッチが適用されたカーネル場合、すぐにこれらのパッチを適用することは重要ではありません。

                                                      マイクロコードのアップデートは必要
                                                      システムがIBRS(マイクロコードベース)の軽減策にフォールバックする必要のある、シナリオが多く存在します。この場合、システムのマイクロコードをアップデートしていない場合は失敗します。retpolinesを利用できる場合でも、マイクロコードをフォールバックとして利用できるようにすることは不可欠です。多数のエッジケース(kvm、強化GPG、Xen、ハードウェア制限など)では、retpolineの緩和策が十分でない場合があります。マイクロコードが期限切れの場合、 'dmesg'出力に表示されるこのメッセージは見たくないでしょう(retpolinesが利用できず、IBRSを利用可能なマイクロコードが利用できない場合のブート時のログです)。
                                                      [  358.742211] kmod1: loading module not compiled with retpoline compiler.
                                                      [  358.742214] Spectre V2 : Disabling Spectre v2 mitigation retpoline.
                                                      [  358.749417] Spectre V2 : Could not enable IBRS.
                                                      [  358.754569] Spectre V2 : No Spectre v2 mitigation to fall back to.
                                                      [  358.761587] Spectre V2 : system may be vulnerable to spectre
                                                      アプリケーションの再コンパイルは不要
                                                      カーネルでretpolineを使えるようにアプリケーションを再コンパイルする必要はありません。ロード可能なカーネルモジュールだけを再コンパイルする必要があります。

                                                      In summary:

                                                      • UEK 2/3/4、Red Hat Compatible Kernelを使うOracle Linux 6および7はSpectre variant 1/2/3に対応している
                                                      • 最新のUnbreakable Enterprise Kernel release 4には、Spectre variant 2に対応するretpolineベースの軽減策が含まれている
                                                      • retpolineが有効化されたUEK4では、マイクロコードベースのSpectre軽減策を有する以前のリリースに比べてパフォーマンスが大幅に向上している
                                                      • retpolineの軽減策を使うUEK4は特定のハードウェアでのみ動作し、全てのカーネルモジュールをretpoline対応のコンパイラで再コンパイルする必要がある。
                                                      • retpolineの軽減策を使うUEK4は、retpolineのサポートに必要な状況でない場合にはマイクロコードベースの保護策に自動的にフォールバックする。
                                                      • ここに記載した内容全てと詳細は、以下のMy Oracle Supportにドキュメントがある。
                                                        Responding to the Spectre and Meltdown vulnerabilities (CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754) in Oracle Linux and Oracle VM on Oracle X86 Servers (Doc ID 2370398.1)
                                                        https://support.oracle.com/rs?type=doc&id=2370398.1

                                                      [Java] Oracle Dev Tour Japan 2018

                                                      $
                                                      0
                                                      0
                                                      風薫る5月といえば、そうJavaの月ですね。そして、彼らが今年もやってきます。
                                                      そう、SteveとSebastianです。

                                                      今年も全国のJUGをお訪ねする、Oracle Dev Tour Japan 2018を開催します。
                                                      2018/04/24現在参加登録サイトがオープンしている会場を下表にまとめました。ご興味あればぜひお近くの会場にお越しください。

                                                      場所開催日時開催場所リンク
                                                      熊本5/8 (火) 18:50-20:50
                                                      開場:18:20
                                                      熊本県民交流館パレア
                                                      10階会議室6
                                                      https://kumamotojava.doorkeeper.jp/events/73213
                                                      福岡5/10 (木) 19:00-21:00
                                                      開場:18:30
                                                      日本オラクル株式会社 西日本支社
                                                      九州オフィス セミナールーム
                                                      https://javaq.connpass.com/event/85022/
                                                      岡山5/11 (金) 19:00-21:00
                                                      開場:18:30
                                                      岡山県立図書館
                                                      サークル活動室2 
                                                      https://okajug.doorkeeper.jp/events/73098
                                                      大阪5/14 (月) 19:00-21:00
                                                      開場:18:30
                                                      日本オラクル株式会社 西日本支社
                                                      大阪オフィス セミナールーム
                                                      https://kanjava.connpass.com/event/84996/
                                                      名古屋5/15 (火) 19:00-21:00
                                                      開場:18:30
                                                      日本オラクル株式会社 中日本支社
                                                      東海オフィス セミナールーム
                                                      https://ngo-java.connpass.com/event/85297/
                                                      仙台5/21 (月) 19:00-21:00
                                                      開場:18:30
                                                      日本オラクル株式会社 東北支社
                                                      セミナールーム 
                                                      https://connpass.com/event/86131/

                                                      そして、5月17日は、Java Day Tokyo 2018もお忘れなく。

                                                      [Java] The road to Jakarta EE

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/theaquarium/the-road-to-jakarta-ee

                                                      Jakarta EE logo

                                                      本日、Eclipse Foundationは、https://jakarta.eeとJakarta EEのロゴの公開、開発者アンケートの結果などを含む、Jakarta EEに関連する複数の発表を行っています。
                                                      Eclipse Foundation Unveils New Cloud Native Java Future with Jakarta EE
                                                      https://jakarta.ee/news/2018/04/24/eclipse-foundation-unveils-new-cloud-native-java-future-with-jakarta-ee/
                                                      Jakarta EE Community Survey of 1,800+ Java Developers Reveals “Cloud Native” Top Requirement in Platform’s Evolution
                                                      https://jakarta.ee/news/2018/04/24/jakarta-ee-community-survey/
                                                      Jakarta EE Software
                                                      https://jakarta.ee/
                                                      ここまでの道のりを紹介するいいタイミングかもしれません。
                                                      2016年終わりごろから2017年初頭、Java EEについて説明していたときに以下のようなスライドを冗談で使っていました。

                                                      その当時、誰も将来を予測していなかったと思います。その期間中、Java EEプラットフォームの将来について疑問が提起されましたが、Java EEにとって状況は簡単では簡単ではなかったことを思い出す必要があります。当時、OracleはJCP expertsと共にJava EE 8およびAPIの最終化に注力していました。

                                                      そのプロセスの比較的早い段階で、私たちはJava EEプラットフォームの将来についても考え始めました。つまり、Java EE 8以後の時代を「Java EE Next」と非公式に呼んでいました。JavaOne 2016で共有されていたJava EE 9の計画は、特に歓迎されなかったため、白紙に戻してやり直しました。Java EEエコシステムが再びわくわくするものかつ多数の方が関与するものたり得るには、根本的に異なる何かをしなければならないことは明らかでした。

                                                      長年にわたって提起されたJava EEに対するすべての懸念を取り除くために、我々はその時点から、よりオープンな方法で、より速いペースでプラットフォームを進化させるべきだと考えました。プラットフォームは、十分に確立されたガバナンスを含め、オープンソースモデルを採用しなければならないことは明らかでした。その初期の反省から、Oracleはエコシステムの主要プレーヤー、つまりRed HatとIBMと一緒に、Eclipse Foundationこそがこのラディカルな進化をホストするのにふさわしいと決定しました。多くの理由の1つは、EclipseがすでにMicroProfile.ioプロジェクトをホストしているという点です。MicroProfileでは、Java EEプラットフォームにマイクロサービス・アーキテクチャ向けの機能を追加しています。その後まもなく、Tomitribe、Payara、FujitsuなどのJava EEプレイヤーがイニシアティブに参加しました。こうしてEE4JJakarta EEが誕生しました。

                                                      プラットフォーム開発のEclipse Foundationへの移行は大仕事です。私は発言に責任を持てないのでここでは取り扱いませんが、複雑な法的問題を含め、多くの技術的側面と非技術的側面があります。さらに、私たちは小さなプロジェクトについて話しているわけではありません。例を挙げると、GlassFish、Jersey、Grizzly、Mojarra、Open MQを含む多数の確立されたプロジェクトについて話しています。しかもそれで終わりではありません。また、さまざまなTCKのオープン化に関連するあらゆる活動もあります。ただただ巨大な作業であり、おそらくEclipse Foundationがこれまでに進めてきたプロジェクトで最大のものでしょう(背景は以下をご覧ください)。
                                                      Background on Oracle’s contribution to Jakarta EE
                                                      https://blogs.oracle.com/theaquarium/background-on-oracle%E2%80%99s-contribution-to-jakarta-ee
                                                      https://orablogs-jp.blogspot.jp/2018/04/background-on-oracles-contribution-to.html
                                                      これこそが、Jakarta EEがベースラインとしてJava EE 8を使用し、旧バージョンのプラットフォームがJakarta EEに含めないことを早期に決定した理由の一つで、このアプローチは端的に合理的かつ実用的でした。こうしている間にも、これらすべての成果が生まれています。Jakarta EEの重要な目標、つまりプラットフォームを進化させることに効果的に注力できるようにするために、そうした取り組みを背後におきながら、すべてが出そろうのを待つ必要があります。それに関連し、著名なコミュニティメンバーから以下のようなメールを最近受け取りました。

                                                      私たちはJakarta EEとは無関係の問題について話し合いました。その人からの謝意にを心からありがたく思いつつ、本当にJakarta EE全体の取り組みについて強調する必要があると考えています。コミュニティー内でVisibilityがある人もいます(PMCにおけるOracleの代表であるDmitry Kornilov(@m0mus)、エバンジェリストとしてのDavid Delabassee)が、Oracle側の立場で言えば、まさにチームの成果なのです。Java EEをEclipse Foundationに移管するために背後(Oracle)では多数の人々が関わっています。関わりの濃淡にかかわらず、この作業に非常に多くの同僚が関わっているため、全員を紹介できませんし、リストにしても誰かを忘れてしまう可能性があるのでそういうことはしたくないのですが、特に言及すべきと考えている、Ed Bratt、Will Lyons、そしてBill Shanonの業績を公言させてください。彼らはJakarta EEを確実に誕生させるための作業の初期段階から休むことなく作業してくれました。皆さん、ありがとう!

                                                      また、通常プロジェクトがオープンソース化される場合、すべての法的側面を含む関連するすべての活動が上流で行われること、そしてすべてが議論され、合意された場合のみ、プロジェクトが公開されることを認識しておく必要があります。しかし、早い段階で、できるだけ透明性の高いものにすることを決めていました。そのため、昨年の夏の最初の意図を発表したのです。当時、まだ多くのことが決定されていませんでしたが、それゆえに、Jakarta EEの初期段階で、新しいけれどもすでに活発な活動をしているオープンソースコミュニティの創設をも含めて、現在の状況に至りました。Jakarta EEの究極の目標、すなわち、プラットフォームを来る10年に必要なオープンソースおよびJavaベースのクラウドネイティブの基盤への進化に適切に取り組むためには、まだまだ多くの作業が必要です。Jakarta EEコミュニティはそのゴールに向けて活発に活動しており、本日の発表が重要な初期マイルストンを表しています。
                                                      Eclipse Foundation Unveils New Cloud Native Java Future with Jakarta EE
                                                      https://jakarta.ee/news/2018/04/24/eclipse-foundation-unveils-new-cloud-native-java-future-with-jakarta-ee/

                                                      [Java] Background on Oracle’s contribution to Jakarta EE

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/theaquarium/background-on-oracle%E2%80%99s-contribution-to-jakarta-ee

                                                      このエントリはWill Lyons(Senior Director, Java EE and WebLogic Server Product Management)によるものです。
                                                      Jakarta EE logo
                                                      本日Eclipse Foundationは、Jakarta EEというブランドの下、Java EE 8テクノロジーがクラウドネイティブJavaの要件を満たすために進化するという、数々のコミュニティアップデートを行っています。新しいJakarta EEウェブサイトとJakarta EEコミュニティ調査の結果をご覧ください。
                                                      Jakarta EE Community Survey of 1,800+ Java Developers Reveals “Cloud Native” Top Requirement in Platform’s Evolution
                                                      https://jakarta.ee/news/2018/04/24/jakarta-ee-community-survey/
                                                      Jakarta EE Software
                                                      https://jakarta.ee/
                                                      本日アップデートが発表されたので、これまでのこのプロジェクトへのOracleの貢献に関するアップデートを提供してもよいだろう、と考えました。以前のエントリで説明したように、OracleはJava EE 8テクノロジーをこのプロジェクトに寄贈しています。具体的には以下のようなものです。
                                                      • Java EE 8のリファレンス実装(RI)であるOracle GlassFish 5.0のソースコード
                                                      • Java EE 8互換性のテストに使用されるOracle Technology Compatibility Kit(TCK)のソース
                                                      • 製品マニュアル
                                                      これまでのOracleの取り組みでは、Eclipse FoundationのEE4JプロジェクトへのOracle GlassFish 5.0およびTCKソースの貢献に注力していました。これは最終的に "Eclipse GlassFish"の構築とテストに使用されます。 Oracleは継続的にGitHubのOracle GlassFishソース・リポジトリの提供準備ができているかどうかをレビューしており、これらのレビューが完了すると、OracleはOracle GlassFish 5.0コンポーネントに対応するEE4Jのサブプロジェクトを提案します。これらのサブプロジェクトとリポジトリは、プロジェクト管理委員会(PMC)とコミュニティレビューの後に作成されます。Oracleは、新しいライセンスでEclipse Foundationにソースを提出し、そこでレビューされ、最終的にGitHubのEE4Jサブプロジェクト・リポジトリに公開されます。

                                                      このプロジェクトは、オープンなEclipseコミュニティ・プロセスによって管理および実行されています。この作業の進行状況は、EE4J Project Bootstrappingステータスページで追跡できます。このページでは、計画済みEE4Jサブプロジェクト、サブプロジェクトの作成、そしてソースコードの提出のステータスをレポートします。このステータスには、Ivar GrimstadとChristian KaltepothがSpec Leadである、MVC 1.0の参照実装のOzarkのステータスと、Oracleの貢献状況が含まれます。

                                                      纏めると、現時点ではこのプロセスの一環として…
                                                      • 34個のEE4Jサブプロジェクトがレビュー待ち。これらのサブプロジェクトは、GlassFishプロジェクト自体、主要なGlassFishコンポーネントのほとんど、TCK寄贈のためのプロジェクトを含む、GlassFish参照実装(Reference Implementation、RI)の大部分を表す。
                                                      • 20個のEE4Jサブプロジェクトが作られ、Oracleからの寄贈を受け取る準備は完了している。
                                                      • Eclipse Foundationに対してこうしたEE4Jサブプロジェクトに対する15個のソースの提供があった。この中には、Jersey (JAX-RS)、Mojarra (JSF)、Tyrus (WebSocket)、Open MQ (JMS)、EclipseLink (JPA)、JSON-P、JTAといった、主要なOracle Java EE 8テクノロジーが含まれる。
                                                      • 13個のサブプロジェクトのソース・リポジトリにソースコードが投入された
                                                      Oracleのソースを提供するこのプロセスは継続します。変更の可能性はありますが、目標は、7月までにすべてのOracle GlassFish 5.0ソースを提供し、Oracle GlassFish 5.0と互換性のあるEclipse GlassFish実装をEE4Jソースから構築し、Java EE 8 TCKバイナリを使ってJava EE 8互換性を検証できるようにします。さらに、Eclipse Foundationに提供したJava EE 8 TCKのソースをJakarta EE TCKプロジェクトに提供することで、これらのテストを進化させて、Jakarta EEコミュニティが決定したようにJakarta EE互換性テストが提供できることを願っています。

                                                      要するに、我々が昨年9月に提案した貢献を現実にするまさにそのさなかです。Eclipse Foundation、Jakarta EE Working Group、EE4J PMC、およびJakarta EEコミュニティの皆様に感謝し、Jakarta EEブランドの下でクラウドネイティブJavaのためにこれらのテクノロジーを進化させていきたいと考えています。

                                                      [Docker, WLS, Kubernetes] Using Prometheus to Automatically Scale WebLogic Clusters on Kubernetes

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/weblogicserver/using-prometheus-to-automatically-scale-weblogic-clusters-on-kubernetes-v5

                                                      WebLogic Serverクラスタの弾力性(スケールアップまたはスケールダウン)は、需要に基づいてリソースを管理できる利点をもたらし、リソースコストを管理しながらお客様のアプリケーションの信頼性を向上させます。Kubernetes環境でWebLogic Serverクラスタの自動スケーリングをトリガする方法にはいくつかありますが、WebLogic Server Elasticityコンポーネントのアーキテクチャと、WebLogic診断フレームワーク(WLDF)ポリシーを使用してWebLogicクラスタをスケールアップする方法の詳細は、「Automatic Scaling of WebLogic Clusters on Kubernetes」のブログエントリをご覧ください。
                                                      Automatic Scaling of WebLogic Clusters on Kubernetes
                                                      https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
                                                      https://orablogs-jp.blogspot.com/2018/01/automatic-scaling-of-weblogic-clusters.html
                                                      このデモでは、Kubernetes上のWebLogicクラスタを自動的に拡張する別の方法、つまりPrometheusを使用する方法をご紹介します。Prometheusは利用可能なすべてのWebLogicメトリクスデータにアクセスできるため、ユーザはメトリックを使ってスケーラビリティのためのルールを指定できます。収集されたメトリックデータと設定されたアラートルールの条件に基づいて、PrometheusのAlertmanagerは、アラートを送信して、WebLogic Serverクラスタ内で実行中の管理対象サーバの数を変更します。
                                                      Prometheus
                                                      https://prometheus.io/
                                                      Prometheus Alertmanager
                                                      https://prometheus.io/docs/alerting/alertmanager/
                                                      WebLogic Monitoring Exporterを使用して、特定のWebLogic Serverインスタンスの実行時メトリックを取得しPrometheusに流します。
                                                      WebLogic Monitoring Exporter
                                                      https://github.com/oracle/weblogic-monitoring-exporter
                                                      また、スケーリングアラートイベントが発生したときに呼び出されるユーザー定義のRESTサービスであるwebhookレシーバーを使用して、カスタム通知の統合を実装します。
                                                      webhook_config
                                                      https://prometheus.io/docs/alerting/configuration/#webhook_config
                                                      アラートルールが指定された条件に一致すると、Prometheus Alert Managerは、スケーリングアクションを要求するwebhookとして指定されたURLにHTTPリクエストを送信します。このサンプルデモで使用しているwebhookの詳細については、以下のリンクを参照ください。
                                                      adnanh/webhook
                                                      https://github.com/adnanh/webhook/
                                                      このブログでは、Kubernetesクラスタで動作するWebLogic Serverインスタンスの自動スケーリングを実行するために、Prometheus、Prometheus Alertmanager、Webhookを構成する方法を学習します。

                                                      Kubernetes環境のPodで実行されているすべてのコンポーネントを下図で示しています。
                                                      PictureForK8s.gif
                                                      Kubernetesクラスタで動作するWebLogicドメインは以下を構成要素としています。
                                                      1. 管理サーバ(AS)インスタンスはDockerコンテナで動作し、独自のPod(POD1)を持つ。
                                                      2. WebLogic Serverクラスタは管理対象サーバインスタンスで構成されており、各インスタンスはDockerコンテナで動作し、それぞれ独自のPod(POD2~POD5)を持つ。
                                                      3. WebLogic Monitoring Exporter WebアプリケーションはWebLogic Serverクラスタにデプロイされている。
                                                      Dockerコンテナで動作し独自のPodを持つ追加コンポーネントは以下の通りです。
                                                      1. Prometheus
                                                      2. Prometheus Alert Manager
                                                      3. WebLogic Kubernetes Operator
                                                      4. Webhookサーバ

                                                      Installation and Deployment of the Components in the Kubernetes Cluster

                                                      インストール手順に従い、WebLogic Kubernetes Operatorおよびドメインを作成します。このエントリでは、以下のパラメータを使ってWebLogic Kubernetes OperatorとWebLogicドメインを作成します。
                                                      Installation - WebLogic Kubernetes Operator
                                                      https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/installation.md
                                                      1. WebLogic Kubernetes Operatorのデプロイ( create-weblogic-operator.sh )
                                                      create-operator-inputs.yaml
                                                      serviceAccount: weblogic-operator  
                                                      targetNamespaces: domain1
                                                      namespace: weblogic-operator
                                                      weblogicOperatorImage: container-registry.oracle.com/middleware/weblogic-kubernetes-operator:latest
                                                      weblogicOperatorImagePullPolicy: IfNotPresent
                                                      externalRestOption: SELF_SIGNED_CERT
                                                      externalRestHttpsPort: 31001
                                                      externalSans: DNS:slc13kef
                                                      externalOperatorCert:
                                                      externalOperatorKey:
                                                      remoteDebugNodePortEnabled: false
                                                      internalDebugHttpPort: 30999
                                                      externalDebugHttpPort: 30999
                                                      javaLoggingLevel: INFO
                                                      2. ドメインの作成ならびに開始 ( create-domain-job.sh )
                                                      create-domain-job-inputs.yaml
                                                      domainUid: domain1   
                                                      managedServerCount: 4
                                                      managedServerStartCount: 2
                                                      namespace: weblogic-domain
                                                      adminPort: 7001
                                                      adminServerName: adminserver
                                                      startupControl: AUTO
                                                      managedServerNameBase: managed-server
                                                      managedServerPort: 8001
                                                      weblogicDomainStorageType: HOST_PATH
                                                      weblogicDomainStoragePath: /scratch/external-domain-home/pv001
                                                      weblogicDomainStorageReclaimPolicy: Retain
                                                      weblogicDomainStorageSize: 10Gi
                                                      productionModeEnabled: true
                                                      weblogicCredentialsSecretName: domain1-weblogic-credentials
                                                      exposeAdminT3Channel: true
                                                      adminNodePort: 30701
                                                      exposeAdminNodePort: true
                                                      namespace: weblogic-domain
                                                      loadBalancer: TRAEFIK
                                                      loadBalancerWebPort: 30305
                                                      loadBalancerDashboardPort: 30315
                                                      3. 以下のコマンドを実行してコンソールにアクセスするための管理NodePortを識別する
                                                      kubectl -n weblogic-domain  describe service domain1-adminserver  
                                                      下図にあるweblogic-domainは、WebLogicドメインPodがデプロイされている名前空間です。
                                                      Scaling13.png
                                                      以前のブログエントリでは、クラスタで実行されている管理対象サーバにWebLogic Monitoring Exporterをデプロイして、Kubernetes環境のWebLogic Serverインスタンスの起動、実行方法をご紹介しました。
                                                      Using Prometheus and Grafana to Monitor WebLogic Server on Kubernetes
                                                      https://blogs.oracle.com/weblogicserver/use-prometheus-and-grafana-to-monitor-weblogic-server-on-kubernetes
                                                      https://orablogs-jp.blogspot.com/2017/12/using-prometheus-and-grafana-to-monitor.html
                                                      以下のURLでWebLogic Server管理コンソールにアクセスします(資格証明はweblogic/welcome1)。
                                                      http://[hostname]:30701/console
                                                      この例では、testwebapp.warというwebアプリケーションが開いたセッションの個数を基にしてアラートルールを設定します。
                                                      bhabermaas/kubernetes-projects/testwebapp.war
                                                      https://github.com/bhabermaas/kubernetes-projects/blob/master/apps/testwebapp.war
                                                      Deploy the testwebapp.warアプリケーションと、WebLogic Monitoring Exporter(wls-exporter.war)をDockerClusterにデプロイします。
                                                      bhabermaas/kubernetes-projects/wls-exporter.war
                                                      https://github.com/bhabermaas/kubernetes-projects/blob/master/apps/wls-exporter.war
                                                      DeploymentScale1.png
                                                      DockerClusterの外部アクセス用NodePortを確認します。
                                                      kubectl -n weblogic-domain  describe service domain1-dockercluster-traefik 
                                                      Scaling2.png
                                                      To make sure that the WebLogic Monitoring Exporterがデプロイされ、実行中であることを確認するため、以下のURLを使ってアプリケーションにアクセスします。
                                                      http://[ hostname ]:30305/wls-exporter/metrics
                                                      メトリックデータにアクセスするために必要なWebLogicユーザーの資格証明を求められるので、weblogic/welcome1を入力します。メトリックページはWebLogic Monitoring Exporter用に構成されたメトリックを表示します。
                                                      Scaling3.png
                                                      Promethus Alertmanagerで設定したいアラートルールがWebLogic Exporterで構成済みのメトリックと一致することを確認しましょう。以下は今回使用したアラートルールの例です。
                                                      if sum(webapp_config_open_sessions_current_count{webapp=”testwebapp”) > 15 ;
                                                      ここで利用したメトリック ‘webapp_config_open_sessions_current_count’ は、メトリックのWebページに表示されている必要があります。

                                                      Setting Up the Webhook for Alert Manager

                                                      この例では、webhookアプリケーションを使いました。
                                                      bhabermaas/kubernetes-projects
                                                      https://github.com/bhabermaas/kubernetes-projects/tree/master/apps
                                                      Dockerイメージ構築のため、以下のディレクトリ構造を作成します。
                                                      • apps
                                                      • scripts
                                                      • webhooks
                                                      1. webhookアプリケーションの実行ファイルをappsディレクトリにコピーし、scalingAction.shスクリプトをscriptsディレクトリにコピーします。
                                                      scalingAction.sh
                                                      https://github.com/oracle/weblogic-kubernetes-operator/blob/master/src/scripts/scaling/scalingAction.sh
                                                      scriptsディレクトリでscaleUpAction.shファイルを作成し、以下のコードをペーストします。
                                                      #!/bin/bash   
                                                      echo scale up action >> scaleup.log
                                                      MASTER=https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT
                                                      echo Kubernetes master is $MASTER
                                                      source /var/scripts/scalingAction.sh --action=scaleUp --domain_uid=domain1 --cluster_name=DockerCluster --kubernetes_master=$MASTER --wls_domain_namespace=domain1
                                                      2. Create a Docker file for the webhook用のDockerファイル(Docker.webhook)を以下のように作成します。
                                                      FROM store/oracle/serverjre:8  
                                                      COPY apps/webhook /bin/webhook
                                                      COPY webhooks/hooks.json /etc/webhook/
                                                      COPY scripts/scaleUpAction.sh /var/scripts/
                                                      COPY scripts/scalingAction.sh /var/scripts/
                                                      CMD ["-verbose", "-hooks=/etc/webhook/hooks.json", "-hotreload"]
                                                      ENTRYPOINT ["/bin/webhook"]
                                                      3. hooks.json ファイルをwebhooksディレクトリを作成します。以下はその例です。
                                                      [  
                                                      {
                                                      "id": "scaleup",
                                                      "execute-command": "/var/scripts/scaleUpAction.sh",
                                                      "command-working-directory": "/var/scripts",
                                                      "response-message": "scale-up call ok\n"
                                                      }
                                                      ]
                                                      4. ‘webhook’ Dockerイメージを作成します。
                                                      docker rmi webhook:latest  
                                                      docker build -t webhook:latest -f Dockerfile.webhook .

                                                      Deploying Prometheus, Alert Manager, and Webhook

                                                      Prometheus、Alertmanagerとwebhook Podをmonitoringという名前空間で実行します。以下のコマンドを実行して、monitoringという名前空間を作成します。
                                                      kubectl create namespace monitoring 
                                                      PrometheusインスタンスをKubernetesにデプロイするために、 prometheus-kubernetes.yml というPrometheusの構成ファイルを作成します。サンプルファイルは以下のURLから入手できます。
                                                      prometheus-deployment.yaml
                                                      https://github.com/bhabermaas/kubernetes-projects/blob/master/kubernetes/prometheus-deployment.yaml
                                                      Prometheus構成ファイルのサンプルでは、以下の情報を設定しています。
                                                      • ユーザー資格証明(weblogic/welcome1)
                                                      • WebLogic Serverのメトリックアップデート間隔(5秒)
                                                      • Prometheusダッシュボードアクセスのための外部ポート(32000)
                                                      • スケーリング・ルール
                                                      • ALERT scaleup   if sum(webapp_config_open_sessions_current_count{webapp=”testwebapp”}) > 15   ANNOTATIONS {   summary = "Scale up when current sessions is greater than 15",   description = "Firing when total sessions active greater than 15" }
                                                      • Alertmanagerは9093/tcpをリスニングするよう構成
                                                      必要であれば、これらの値を変更してご自身の環境固有の情報を反映することもできます。アラートルールを変更し、Elasticity要件にあわせてPrometheusで定義済みのクエリを構成することもできます。
                                                      QUERYING PROMETHEUS
                                                      https://prometheus.io/docs/querying/basics/
                                                      アラートを生成するには、Prometheus AlertmanagerをDockerコンテナで動作する別のPodとしてデプロイする必要があります。サンプルとして提供しているPrometheus Alertmanagerの構成ファイルでは、webhookを利用しています。
                                                      alertmanager-deployment.yaml
                                                      https://github.com/bhabermaas/kubernetes-projects/blob/master/kubernetes/alertmanager-deployment.yaml
                                                      Scaling5.png
                                                      WebLogic Kubernetes Operatorのデプロイで利用する weblogic-operator.yaml に含まれるプロパティinternalOperatorCertの値で webhook-deployment.yaml ファイルのプロパティINTERNAL_OPERATOR_CERTを更新します。
                                                      webhook-deployment.yaml
                                                      https://github.com/bhabermaas/kubernetes-projects/blob/master/kubernetes/webhook-deployment.yaml
                                                      以下はその例です。
                                                      Scaling6.png
                                                      webhook、Prometheus、Alertmanagerを起動し、管理対象サーバインスタンスを監視します。
                                                      kubectl apply -f  alertmanager-deployment.yaml
                                                      kubectl apply –f prometheus-deployment.yaml
                                                      kubectl apply –f webhook-deployment.yaml
                                                      全てのPodが起動したことを確認しましょう。
                                                      Scaling14.png
                                                      http://[ hostname ]:32000にアクセスし、Prometheusが全管理対象サーバを監視していることを確認しましょう。
                                                      Insert metric at cursor プルダウンメニューを確認しましょう。WebLogic Monitoring Exporter webアプリケーションの現在の構成に基づいたメトリック名が並んでいるはずです。
                                                       
                                                      http://[hostname]:32000/alertsにアクセスしてPrometheus Alert Settingを確認できます。
                                                      Scaling8.png
                                                      prometheus-deployment.yaml 構成ファイルに並べた構成済みのルールが表示されているはずです。

                                                      Auto Scaling of WebLogic Clusters in K8s

                                                      このデモでは、2個の実行中の管理対象サーバをもつよう各WebLogic Serverクラスタを構成し、管理対象サーバの個数がちょうど4になるようにしました。configuredManagedServerCount と initialManagedServerReplicas という、create-domain-job-inputs.yamlファイルに含まれるこれらのパラメータを変更し、クラスタ内で実行する管理対象サーバの所望の個数と、許容するレプリカの最大個数を反映することができます。
                                                      今回のサンプルファイルの構成の場合、初期時点では2個の管理対象サーバPodのみを起動しました。現在実行中の全Podをチェックしましょう。
                                                      Scaling9.png
                                                      今回のAlert Ruleの構成では、クラスタでtestwebappというアプリケーションに対するセッションの個数が15を超える場合スケールアップが発生します。curl.shwアプリケーションURLを17回呼び出してみましょう。Let’s invoke the application URL 17 times using curl.sh :
                                                      #!/bin/bash  

                                                      COUNTER=0
                                                      MAXCURL=17
                                                      while [ $COUNTER -lt $MAXCURL ]; do
                                                      OUTPUT="$(curl http:/$1:30305/testwebapp/)"
                                                      if [ "$OUTPUT" != "404 page not found" ]; then
                                                      echo $OUTPUT
                                                      let COUNTER=COUNTER+1
                                                      sleep 1
                                                      fi
                                                      done
                                                      コマンドを発行します。
                                                      . ./curl.sh [hostname] 
                                                      testwebappアプリケーションに対するセッションの合計が15を超えると、PrometheusはAlertmanagerを通じてアラートを発生します。現在のアラートの状態をhttp://[hostname]:32000/alertにアクセスして確認できます。
                                                      Scaling10.png
                                                      AlertmanagerがHTTP POSTでwebhookに送信したことを確認するには、以下のwebhook Podのログを確認します。
                                                      Scaling11.png
                                                      webhookのエンドポイントが呼び出されると、execute-commandプロパティで指定されたコマンドが呼び出されます。今回の場合、該当するコマンドは/var/scripts/scaleUpAction.shです。scaleUpAction.shスクリプトはWebLogic Kubernetes Operatorが提供するscalingAction.shスクリプトへのパラメータを渡します。scalingAction.shスクリプトはOperator Server REST URLに対しスケールのリクエストを発行します。
                                                      スケールアップ(訳注:本来スケールアウトですが、原文に従っています)操作を確認するには、実行中の管理対象サーバのPodの個数を確認します。3個の実行中Podに増えているはずです。
                                                      Scaling12.png

                                                      Summary

                                                      このエントリでは、Kubernetes環境でWebLogic Serverクラスタの自動スケーリングを呼び出すために、WebLogic ServerとPrometheusを連携して利用する方法を紹介しました。Prometheusが監視・分析する包括的なWebLogicドメイン固有の(カスタム)メトリックのセットに基づいて、Podの数を増加(または減少)して自動的にWebLogic Serverクラスタを拡大/縮小できます。すばらしい監視ツールに加えて、Prometheusは簡単にWebLogic Serverクラスタのスケールの決定を簡単に構成できることもご紹介いたしました。

                                                      [Kubernetes, Fucntions] Oracle Adds New Support for Open Serverless Standards to Fn Project and Key Kubernetes Features to Oracle Container Engine

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/developers/kubecon-europe-2018-oracle-open-serverless-standards-fn-project-and-kubernetes

                                                      オープンなserverlessプロジェクトであるFnは、CNCF CloudEvents、Serverless Frameworkのサポート、トレースとメトリックのためのOpenCensusといった、広範なサーバレス標準化のサポートを追加しています。
                                                      Oracle Container Engine for KubernetesはK8sユーザーが今日直面している最も困難な現実世界のガバナンス、スケール、管理といった課題に取り組んでいます。

                                                      本日Kubecon + CloudNativeCon Europe 2018で、Oracleは以下の内容を発表しました。
                                                      • Fn Projectにおいていくつかのオープンなserverless標準の新たなサポート
                                                      • 重要な新しいOracle Container Engine for Kubernetes機能が、鍵となる現実世界でのKubernetesの課題(ガバナンス、セキュリティ、ネットワーク、ストレージ、スケール、管理性など)に対処
                                                      Kubecon + CloudNativeCon Europe 2018
                                                      https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/
                                                      Fn Project
                                                      http://fnproject.io/
                                                      serverlessコミュニティもKubernetesコミュニティも、進化における重要な岐路にさしかかっています。オープンなserverless標準へのコミットメントをさらに高めるために、OracleはFn Projectが標準ベースのプロジェクトCloudEventsおよびServerless Frameworkをサポートすると発表しました。どちらのプロジェクトも、今日のプロプライエタリなserverlessの選択肢に対し、相互運用性とコミュニティ主導型の別の選択肢を作成することを目的としています。
                                                      CloudEvents
                                                      https://github.com/cloudevents/spec
                                                      Serverless Framework
                                                      https://github.com/serverless/serverless

                                                      Solving Real World Kubernetes Challenges

                                                      Cloud Native Computing Foundation (CNCF) とパートナーシップを結ぶThe New Stackは先頃、Kubernetesユーザーが今日直面している上位の課題を分析したレポートを発表しました。
                                                      The Top Challenges Kubernetes Users Face with Deployment - The New Stack
                                                      https://thenewstack.io/top-challenges-kubernetes-users-face-deployment/
                                                      このレポートによると、インフラ関連の問題、具体的にはセキュリティ、ストレージ、ネットワーク、が上位にランクインしており、大企業に最も影響を与えているとのことです。
                                                       
                                                       
                                                      出典: The New Stack

                                                      さらに、コンテナオーケストレーションの評価時に、拡張性、管理性、アジリティ、セキュリティなど、従来にない非機能要件が関わってくるようになりました。こうしたタイプの問題の解決には、Kubernetesプロジェクトがガートナー・ハイプ・サイクルのTrough of Disillusionment(幻滅期)を抜けSlope of Enlightenment(啓蒙活動期)を過ぎて、Plateau of Productivity(生産性の安定期)という約束された土地に移動するのが役立ちます。
                                                      Hype Cycle Research Methodology
                                                      https://www.gartner.com/technology/research/methodologies/hype-cycle.jsp

                                                      出典: The New Stack

                                                      Addressing Real-World Kubernetes Challenges

                                                      今日のKubernetesユーザーが直面しているこれらの課題に対処するため、Oracle Container Engine for KubernetesはOracle Cloud Infrastructure(OCI)の最高のガバナンス、セキュリティ、ネットワーキング、およびスケール機能と緊密に統合されています。以下にまとめます。
                                                      Oracle Container Engine for Kubernetes
                                                      https://cloud.oracle.com/en_US/containers
                                                      • Governance, compliance, & auditing
                                                        Kubernetesのアイデンティティおよびアクセス管理(Identity and Access Management、IAM)は、DevOpsチームがKubernetesリソースへのアクセス権を持つユーザーを管理するだけでなく、アクセス権の種類とどの特定のリソースへのアクセスかを記述するポリシーも設定します。これは複雑な組織やユーザーやリソースの論理的なグループに適用されるルールを管理するうえで重要な要素です。ポリシーの定義と管理は非常に簡単です。
                                                        • Governance
                                                          DevOpsチームは、どのユーザーがKubernetesクラスタのどのリソース、コンパートメント、テナント、ユーザー、およびグループにアクセスできるかを設定できます。異なるチームは、開発、テスト、ステージング、プロダクションなど、開発サイクルのさまざまな段階で異なるリソースを管理することがふつうのため、役割ベースのアクセス制御(RBAC)が重要です。 2つのレベルのRBACが提供されています。
                                                          1. OCI IaaSインフラストラクチャー・リソース・レベルで、クラスタの開始、スケール、利用を定義
                                                          2. Kubernetesアプリケーション・レベルで、リソース管理を提供

                                                        • Compliance
                                                          Container Engine for Kubernetesは、カード保持者のデータの保管、処理、送信といった幅広い機密情報を扱うワークロードに対してお客様が利用される、世界的に適用されるセキュリティ基準であるPCI DSS(Payment Card Industry Data Security Standard)をサポートします。DevOpsチームは、オラクルのPCI対応クラウドインフラストラクチャサービスでKubernetesアプリケーションを実行できます。
                                                        • Auditing (logging, monitoring)
                                                          クラスタ管理監査イベントは、OCI Audit Service(OCI監査サービス)にも統合されており、一貫かつ統一されたイベント収集と可視性を実現します。
                                                          Cloud Audit and Security Services
                                                          https://cloud.oracle.com/governance/audit/features
                                                      • Scale
                                                        Oracle Container Engineは、高可用性のマネージドKubernetesサービスです。 Kubernetesのマスターは、高い可用性を担保して(クロスアベイラビリティドメイン)管理、保護されています。ワーカークラスタは自己回復型であり、アベイラビリティドメインをまたがることができ、VMからベアメタル、GPUまでのcomputeシェイプで構成されるノードプールでワーカークラスタを構成できます。
                                                        • GPUs, Bare Metal, VMs
                                                          Oracle Container Engineは、小さな仮想化環境から、非常に大きな専用の構成までの幅広いKubernetesコンピュートノード・ファミリを業界で初めて提供します。ユーザーは、ネットワーク、ブロックストレージやローカルNVMeストレージオプションを使用して、基本的なWebアプリケーションから、高性能コンピューティングモデルまでスケールアップできます。
                                                        • Predictable, High IOPS
                                                          Kubernetesノードプールでは、予測可能なIOPSブロックストレージと高密度I/O VMを備えた、VMもしくはベアメタル・コンピュートを利用できます。ローカルNVMeストレージは、幅広いコンピュートの種類と高いIOPSを備える容量を提供します。
                                                        • Kubernetes on NVIDIA Tesla GPUs
                                                          ベアメタルGPUでKubernetesクラスタを実行することで、コンテナアプリケーションは最高のパフォーマンスを実現します。ハイパーバイザーのオーバーヘッドがないので、DevOpsチームは、2つのNVIDIA Tesla P100 GPUを備えるOracle Cloud Infrastructureのベアメタル・コンピュート・インスタンスにアクセスし、インスタンスあたり21 TFLOPSを超える単精度性能を実現するCUDAベースのワークロードを実行することができます。
                                                          Oracle and NVIDIA Collaborate to Provide Accelerated Compute Offerings in the Cloud
                                                          https://blogs.oracle.com/cloud-infrastructure/oracle-nvidia-collaborate-cloud-compute-offerings
                                                      • Networking
                                                        Oracle Container Engineは、オーバーサブスクライブしない、最先端の非ブロッキングClosネットワーク上に構築されており、予測可能で広帯域、低遅延なネットワークを提供します。
                                                        • Load balancing
                                                          負荷分散は、構成管理で最も難しい機能の1つです。OracleはOCIの負荷分散機能とシームレスに統合されており、コンテナ・レベルの負荷分散が可能です。Kubernetesの負荷分散はロードバランサのIPアドレスで着信トラフィックをチェックし、負荷分散ポリシーとヘルスチェックポリシーに基づいて着信トラフィックを一連のバックエンドサーバーに配信します。DevOpsチームは、ロードバランサに対して、着信トラフィックをバックエンドサーバーに配信する方法を指示する負荷分散ポリシー(Load Balancing Policy)を定義できます。
                                                        • Virtual Cloud Network
                                                          Kubernetesのユーザー(ワーカー)ノードは顧客独自のVCN(仮想クラウドネットワーク)内にデプロイされています。VCNを使用してIPアドレス、サブネット、ルートテーブル、およびゲートウェイを安全に管理できます。
                                                      • Storage
                                                        Kubernetesストレージを管理する簡単な方法としてのコード・クラックは、DevOpsチームにとって大きな懸念事項でありつづけます。Oracle Cloud Infrastructure用に設計された2つの新たなIaaS Kubernetesストレージの統合により、OCIの業界最高レベル(標準的任意のクラウド・プロバイダーの1 GB当たりIOPSよりも高い)のブロック・ストレージ性能、コスト、予測可能性を実現します。
                                                      • Simplified, Unified Management
                                                        • Bundled in Management
                                                          一般的に使用されているKubernetesユーティリティをバンドルすることで、Oracle Container Engine for Kubernetesは、使い慣れたシームレスな開発者エクスペリエンスを実現します。これには、HelmとTiller(標準のKubernetesパッケージ管理を提供)、Kubernetesダッシュボード、およびkube-dnsの組み込みサポートが含まれます。
                                                          Helm - The Kubernetes Package Manager
                                                          https://helm.sh/
                                                        • Running Existing Applications with Kubernetes
                                                          Kubernetesは新たな、最終的にはグリーンフィールドのアプリケーションとは言えない、ワークロードをサポートしており、そのワークロードはますます増加しています。Kubernetes Operatorは、「Kubernetes APIを拡張して、Kubernetesユーザーに代わって複雑なステートフル・アプリケーションのインスタンスを作成、構成、および管理するアプリケーション固有のコントローラ」です。
                                                          Kubernetes Operators
                                                          https://coreos.com/operators/
                                                          Oracleはこれをオープンソース化し、近い将来Oracle WebLogic Server Kubernetes Operatorを一般リリースします。
                                                          Oracle Weblogic Server Kubernetes Operator
                                                          https://github.com/oracle/weblogic-kubernetes-operator
                                                          これを使うと、WebLogicユーザーは、アプリケーションの書き換え、再テスト、および追加のプロセスとコストをかけずに、Kubernetes環境でWebLogicドメインを管理できます。また、WebLogic 12.2.1.3はKubernetesでの動作保証済みであり、WebLogic Monitoring Exporterという、Prometheusのような監視ツールが読み取り・収集でき、Graetanaに表示できるWebLogic Serverのメトリックを公開するツールをリリース、オープンソース化しています。
                                                          WebLogic Server Certification on Kubernetes
                                                          https://blogs.oracle.com/weblogicserver/weblogic-server-certification-on-kubernetes
                                                          https://orablogs-jp.blogspot.jp/2018/01/weblogic-server-certification-on.html
                                                          Announcing the New WebLogic Monitoring Exporter
                                                          https://blogs.oracle.com/weblogicserver/announcing-the-new-weblogic-monitoring-exporter-v2
                                                          https://orablogs-jp.blogspot.jp/2017/12/announcing-new-weblogic-monitoring.html

                                                      Fn Project

                                                      オープンなserverlessの取り組みがCNCF内で進められており、Fn Projectは積極的に従事しこれらの新たな標準を支援しています。
                                                      • CloudEvents
                                                        Fn Projectは、Cloud Event標準の取り組みをサポートすると発表しました。CloudEventsは、イベントデータを標準化し、さまざまなアプリケーション、プラットフォーム、プロバイダ間のイベント宣言と配信を簡略化することを目指しています。
                                                        CloudEvents Specification
                                                        https://github.com/cloudevents/spec
                                                        これまで、開発者にとって、serverlessイベントを記述する共通の方法が欠けていました。これは、serverlessアプリケーションの移植性に重大な影響を与えるだけでなく、開発者の生産性を大幅に低下させます。
                                                      • Serverless Framework
                                                        オープンソースのFunctions as a Serviceおよびワークフロー・フレームワークであるFn Projectは、FaaS ProviderをServerless Frameworkに提供し、マルチクラウドおよびオンプレミスのserverlessコンピューティングのミッションをさらに推進しています。
                                                        Serverless Framework
                                                        https://github.com/serverless/serverless
                                                        この新しいProviderを使用すると、慣れ親しんだ統一された開発者体験を得ながら、Serverless Frameworkのユーザは、コンテナネイティブなfunctionを簡単に構築して任意のFn Clusterに展開できます。Fnの成長するコミュニティのために、この統合は、マルチクラウドおよびマルチプロバイダの世界で機能を管理するためのさらなる選択肢をもたらします。
                                                        "With a rapidly growing community around Fn, offering a first-class integration with the Serverless Framework will help bring our two great communities closer together, providing a “no lock-in” model of serverless computing to companies of all sizes from startups to the largest enterprises,” says Chad Arimura, VP Software Development, Oracle.

                                                        「Fn周辺のコミュニティが急速に成長している中で、Serverless Frameworkとの統合により、2つの巨大なコミュニティをより緊密に結びつけることができ、結果としてスタートアップから大企業までのあらゆる規模の企業にserverlessコンピューティングの「ロックインされない」モデルを提供します。 」(Chad Arimura, VP Software Development, Oracle)
                                                      • OpenCensus
                                                        Fnは現在、すべてのFnコードでOpenCensusの統計、トレース、ビューAPIを使用しています。
                                                        Tracing all the Fn things with OpenCensus
                                                        https://medium.com/fnproject/tracing-all-the-fn-things-with-opencensus-e579b268aeca
                                                        OpenCensus
                                                        https://opencensus.io/
                                                        OpenCensusは、アプリケーションから自動的にトレースとメトリックを収集し、ローカルに表示し、分析ツールに送信するライブラリのディストリビューションです。OpenCensusは、開発者が任意のバックエンドを使用できるように独自のデータ形式を定義する上で優れた決定を下しました(データ収集をシンプルにするために、明示的に独自のデータ構造を作成する必要はありません)。 これにより、コードを大幅に変更することなく、Fnをopsの世界で簡単に最新の状態に追随できます。
                                                      詳細情報を知りたい方は、5月4日(金)のChad ArimuraとMatt StephansonのKubeConでのセッション「Operating a Global-Scale FaaS on Top of Kubernetes」にご参加ください。
                                                      Operating a Global Scale FaaS on top of Kubernetes
                                                      http://sched.co/Dqvy

                                                      [Java] Update and FAQ on the Java SE Release Cadence

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence

                                                      Java SE 9の作業が2017年の早い段階で終了したため、OpenJDKコミュニティのコントリビュータから、Java SEプラットフォームとJDKをより早い段階で進化させて機能をよりタイムリーに配信できる方法があるだろうかという疑問が投げかけられました。Java Community Processがそのような変化に対応する方法を検討するため、JCPワーキンググループが設立されました。
                                                      17 February 2017 OpenJDK Working Group Meeting Minutes
                                                      https://community.oracle.com/docs/DOC-1015451
                                                      主要なコントリビュータの間でのさらなる議論の後、計画が提案され、並行して、Oracleは商用Java SE製品の計画を発表しました[1]。
                                                      Moving Java Forward Faster
                                                      https://mreinhold.org/blog/forward-faster
                                                      Faster and Easier Use and Redistribution of Java SE
                                                      https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se
                                                      https://orablogs-jp.blogspot.jp/2017/09/faster-and-easier-use-and.html
                                                      その後数ヶ月の短期間で、OpenJDKコミュニティは、Oracleのリーダーシップの下、Java SE 9、Java SE 10、Java SE 11の早期アクセスビルドだけでなく、調整されたスケジュールでセキュリティアップデートを複数提供してきました。
                                                      JDK 9
                                                      http://openjdk.java.net/projects/jdk9/
                                                      JDK 10
                                                      http://openjdk.java.net/projects/jdk/10/
                                                      JDK 11
                                                      http://openjdk.java.net/projects/jdk/11/
                                                      OpenJDK Vulnerability Groupが結成されました。
                                                      OpenJDK Vulnerability Group
                                                      http://openjdk.java.net/groups/vulnerability/
                                                      Java SE 10では、小さな新しい言語機能が追加されました。
                                                      JEP 286: Local-Variable Type Inference
                                                      http://openjdk.java.net/jeps/286
                                                      これは、新しいケイデンスが、実装だけでなくJCPの仕様作業でも機能していることを示しています。

                                                      ということで、新しいケイデンスは、私たちが長年にわたって慣れ親しんできた用語やプロセスに新しいイディオムや意味を導入します。明らかに、容易に新機能を取り込めるという、予測可能なリリーススケジュールの利点は、エコシステムの最大のプロジェクトに対する成果に値します。この傾向は、Java SEエコシステムの他の部分でも発生しています。たとえば、Eclipseでは長年にわたって年1回のrelease trainがありますし、Wildflyは四半期ごとのリリースモデルに移行しています。
                                                      Simultaneous Release
                                                      https://wiki.eclipse.org/Simultaneous_Release
                                                      [wildfly-dev] WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases
                                                      http://lists.jboss.org/pipermail/wildfly-dev/2017-December/006250.html
                                                      このブログエントリでは、この数ヶ月間に尋ねられたよくある質問にお答えします。

                                                      Q: Surely you can’t expect everyone to adopt major releases every six months?! (誰も6ヶ月ごとにメジャーリリースを採用するとは思いませんが?)

                                                      正確な意味では、もう「メジャーリリース」はありません。その用語は古いものです。その代わりに、feature releaseという安定した流れがあります。これは、バージョン管理の新しい取り組みを除いて、過去のリリース回数に一致しています。例えば、Java 8は2014年3月にリリースされました。feature releaseである8u20は、8月のほぼ半年後にリリースされました。次のfeature releaseである8u40は、その後6ヶ月後にリリースされました。
                                                      8u20 Update Release Notes
                                                      http://www.oracle.com/technetwork/java/javase/8u20-relnotes-2257729.html
                                                      8u40 Update Release Notes
                                                      http://www.oracle.com/technetwork/java/javase/8u40-relnotes-2389089.html
                                                      したがって、以前と同様に、6か月ごとにfeature releaseの取り込みを期待しています。

                                                      Java 9→10→11は、7→8→9よりも8→8u20→8u40の方が近いものです。3年ごとにメジャーリリースに慣れていて、そうした大きな変化の巨大な影響のメンタルモデルを持っているときは、当初は怖いと感じるでしょう。6ヶ月のリズムはそうではありません。FAQの後半で、これについてより具体的な証拠をご紹介します。

                                                      Q: If the new releases are basically the long standing six-month cadence, why rev the major release number each time?  Why not just call it 9u20, 9u40, etc.? (新しいリリースが基本的に長年の6ヶ月サイクルである場合、毎回メジャーリリース番号を上げるのはなぜですか?なぜ9u20、9u40などと呼ばないのですか?)

                                                      JCPプロセスを合理化することで、major releaseのために何年も待つ必要はなくなり、新しいクラスライブラリ、JVM機能やローカル変数型推論などの言語機能をわずか6ヶ月で導入することが可能になりました。
                                                      JEP 286: Local-Variable Type Inference
                                                      http://openjdk.java.net/jeps/286
                                                      2年ごとに数多くの仕様変更をリリースするのではなく、導入の準備が整い次第、より実用的に安定した流れに導入できます。

                                                      Q: Spec changes sound dangerous and they’ll inhibit tools ecosystem from updating, right? (仕様変更は危険に感じます。ツールのエコシステムがアップデートされなくなるのではないでしょうか?)

                                                      いくつかのツールは8→9への移行に苦労していますが、その移行が済んでいればほぼ一晩で9→10に移行できました。

                                                      Java 10がリリースされたとき、主要なIDEはすべて、数日で新しいローカル変数型推論機能を含むJava 10をサポートしました。
                                                      Webinar: IntelliJ IDEA and Java 10
                                                      https://blog.jetbrains.com/idea/2018/04/webinar-intellij-idea-and-java-10/
                                                      The Eclipse Project Downloads
                                                      http://download.eclipse.org/eclipse/downloads/#Latest_Release
                                                      JDK 10 (March 2018) - Apache NetBeans 9.0 New and Noteworthy
                                                      https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75971001
                                                      GradleやLuceneのような人気のあるプロジェクトは、すぐに正式なサポートを追加しました。
                                                      Gradle Release Notes
                                                      https://docs.gradle.org/4.7/release-notes.html
                                                      Apache Lucene
                                                      https://lucene.apache.org/
                                                      UbuntuやSUSE Linux Enterprise Serverなどの人気のあるLinuxディストリビューションでは、最新のOpenJDKをプラットフォーム上のデフォルトのJRE/JDKにするために積極的に調整していました。
                                                      OpenJDK SRU exception
                                                      https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004275.html
                                                      SUSE Linux Enterprise Server 15 GA Release Notes
                                                      Supported Java Versions
                                                      https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15/#TechInfo.Java
                                                      Elasticsearchは、新機能の恩恵を受けるために、できるだけ早くLTSリリースと非LTSリリースの両方と互換性を持たせることを計画しています。
                                                      Elasticsearch: Java 9 and Beyond!
                                                      https://www.elastic.co/blog/elasticsearch-java-9-and-beyond
                                                      これらは、他のプロジェクトや製品が6ヶ月のリズムに追随している例のほんの一部です。

                                                      この新しいリリースサイクルは、ツールベンダーにとってより管理しやすく、予測可能にします。今では小規模なアップデートの安定した流れがあります。さらに、将来を見越した開発者は、OpenJDK Project Valhallaのminimal value typeや、OpenJDK Project ZGCのZ Garbage Collector(ZGC)などの新しい機能を、使い慣れたオープンソースライセンスで利用可能な早期アクセスビルドを使って調べることができます。
                                                      Project Valhalla "Minimal Value Types" Early-Access Builds
                                                      http://jdk.java.net/valhalla/
                                                      Project ZGC "The Z Garbage Collector" Early-Access Builds
                                                      http://jdk.java.net/zgc/

                                                      Q: Why would anyone update to version X when a new release X+1 is only six-months away? (新しいリリースX+1がわずか6ヶ月先にリリースされるのに、バージョンXにアップデートするのはなぜですか?

                                                      最新のOracle JDKビルドとOracleのOpenJDKビルドを、開発者は毎月何百万回もダウンロードしています。
                                                      Java SE Downloads
                                                      http://www.oracle.com/technetwork/java/javase/downloads/index.html
                                                      Java Development Kit builds, from Oracle
                                                      http://jdk.java.net/
                                                      JDK 9、10を含め、各feature releaseでJDKダウンロード件数は着実に増加しています。Java 10の最新リリースはJava 7やJava 8よりもはるかに速いペースでダウンロードされています。例えば、このエントリ記述の時点でのJDK 10のダウンロード数は、JDK 8アップデートのダウンロード件数を5倍上回ります。

                                                      新しいリリースサイクルの速い普及は印象的です。人気のあるIDEや他のツールベンダーがJava 10を迅速に採用してJava 10のサポートを利用できるようになるのを見て、非常に力づけられています。

                                                      Q: I’m still not convinced.  Java 9 was a challenge to adopt, so that means 10 and 11 will be, too. (私はまだ納得していません。Java 9は採用が難しかったのです。10と11も同じだと考えています。)

                                                      多くのJava SE開発者とユーザーは、これまで新しいmajor versionを採用する前にアップデートを待っていました。これは、major releaseに数多くの主要な仕様変更の機能がある場合に想定されるものでしたが、6ヶ月のリリースではそういうことにはなりません。つまり、Java SE 9以降ではあてはまりません。

                                                      例えば、Java SE 9のリリースでは、Java SE 8の上に約19,000のソースコードの変更が組み込まれていましたが、Java 9とJava 10の間では2,700の変更しかありませんでした。これは、Java 8とJava 8u40の変更とほぼ同じです。したがって、Java SE 9はJava SE 8に対するメジャーアップグレードですが、Java SE 9はJava SE 9のシンプルな機能アップデートです。

                                                      Q: How can I be confident that the X+1 release transition will be smooth?  How much time is there to transition? (X+1リリースの移行がスムーズになることは、どうすればわかりますか?移行にどのくらいの時間が必要ですか?)

                                                      早期アクセスビルドは、Oracle独自のOpenJDKビルドを含めて、以前よりダウンロードや試用が簡単です。
                                                      JDK 11 Early-Access Builds
                                                      http://jdk.java.net/11/
                                                      OracleのOpenJDK早期アクセスビルドをビルドテストシステムで使用することを開発者に推奨します。そうすれば、問題が早期に発見される可能性があります。

                                                      feature releaseの最終更新から3ヶ月で、次の機能リリースのセキュリティ更新プログラムがあります。この間に移行することを強くお勧めします。新機能リリースと次回の予定されているセキュリティ更新から約1ヶ月あります。例えば、Java 9.0.4は2018年1月に、Java 10.0.0は2018年3月に、10.0.1は2018年4月にリリースされました。Java 10.0.1リリース以降、Java 9.0.4やJava 10.0.0の使用はお勧めしません。ですが、1ヶ月、もしくはテスト開始まで3ヶ月待つ必要はありません。10.0.1のアップデートリリースが出る6ヶ月以上前から、JDK 10の早期アクセスビルドは2017年11月から定期的に公開されているからです。
                                                      Java Development Kit builds, from Oracle
                                                      http://jdk.java.net/
                                                      これは、feature releaseとそれに続くセキュリティアップデートの間に4〜6週間あるという、これまでのfeature releaseと一致しています。例えば、2015年3月初旬に8u40がリリースされ、後に続くセキュリティアップデートの8u45は2015年4月14日にリリースされました。

                                                      Q: Ok, but I don’t want new features.  I have a system in production and just want stability, performance and security updates only.  What do I do? (わかりましたが、本番環境のシステムがあるので、新しい機能ではなく、安定性、パフォーマンス、およびセキュリティの更新のみを望んでいます。どうすればいいですか?)

                                                      Oracleでは、2018年9月のJava SE 11から、「長期サポート」(LTS)リリースとして、3年ごとにリリースを指定する予定です。Java SE 9のリリースはJava 10のリリースでEnd of Lifeを迎え、Java 10もJava 11のリリースで同様にEnd of Lifeを迎えますが、Java 11は少なくとも8年間はOracleの商用サポートを提供する予定です。
                                                      Oracle Java SE Support Roadmap
                                                      http://www.oracle.com/technetwork/java/eol-135779.html
                                                      Java 6とJava 7でほぼ10年間に起こったように(そして2019年にはJava 8でも同様のことが起こるでしょう)、顧客のニーズに集中できるようOracleがOpenJDKの特定のリリースシリーズにソースコードの変更を提供しなくなった後は、OpenJDKコミュニティの他の資格のあるコントリビュータは、リリースシリーズの継続的なメンテナンスを進める可能性があります。彼らは選択する限り、OpenJDKコミュニティ標準に従って、Oracleやその他の人々がまだメンテナンスしている以後のリリースから関連する変更をバックポートします。例えばJDK 6の場合、Sunは2008年にプロジェクトを確立し、Oracleは2013年までそれを維持し続けました。その後、他のメンテナーは、その後以後のリリースからの更新をバックポートすることでプロジェクトの作業を続けました。

                                                      Oracleは、JDK Updates Project内で確立されたプロセスを提供するとともに、新しい役割、そして大事なことを言い忘れていましたがVulnerability Groupの役割に慣れるために新しいメンテナーへの支援を提供することで、OpenJDK Communityでこうした移行をサポートしています。
                                                      [9u Communication] End of maintenance timeframe & invitation for prospective new maintainers
                                                      http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-February/000087.html

                                                      Q: What’s happening with Java SE 8? (Java SE 8はどうなるの?)

                                                      Java SE 8は、従来のバージョン管理とリリースサイクルモデルの最終で、Java 9は新たなスタートでした。

                                                      Oracle JDKの場合、Java 8はJava 7やJava 6と全く同じ移行プロセスを辿りますが、いくつかの例外があります。まず、新しいリリース・モデルに慣れるための猶予時間を増やすために、Oracleは商用本番利用用途向けに2019年1月、個々のデスクトップ向けに少なくとも2020年末までにOracle JDKのパブリック・アップデートを拡張しました。2つ目は、Java 6→7およびJava 7→8の場合と同様に、次のリリースに移行したい人向けに、Oracle JDKをOracleのOpenJDKビルドと互換性を持たせるための取り組みを発表しました。あなたがまだ移行されていないならば、10に移行し、新しいリリーストレインに乗ることをご提案します。

                                                      OpenJDKの領域では、Oracleは2019年1月までJDK 8 Updatesプロジェクトを継続してリードし、貢献する予定です。その前に、(これまで10年にわたって実施されていたように)新しいメンテナの要請が行われます(詳細は前の質問をご覧ください) 。
                                                      [8u-communication] Oracle's plans to contribute to JDK 8 Updates Project in OpenJDK after Java SE 8 End of Public Updates
                                                      http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html

                                                      Q: I’m an Oracle Customer, how am I affected? (Oracleの顧客にはどのような影響があるのか?)

                                                      Java SEを依存関係に持つOracle製品内で、Java SEを利用する場合には影響を受けます。詳細はMy Oracle Supportの記述をご覧ください。
                                                      Support Entitlement for Java SE When Used As Part of Another Oracle Product (Doc ID 1557737.1)
                                                      https://support.oracle.com/rs?type=doc&id=1557737.1

                                                      [脚注]

                                                      [1] Oracleがバイナリとビルドのために発表した計画は以下の通り。
                                                      1. Oracle JDKの以前の全てのクローズドソースをOpenJDKに移動する
                                                      2. GPLv2 + CPEの下でOpenJDKバイナリを公開する
                                                      3. Oracle JDKとOpenJDKのバイナリは互換性を持たせてスムーズな移行を保証する

                                                      [WLS, Docker, Kubernetes] Announcing General Availability version of the WebLogic Server Kubernetes Operator

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/weblogicserver/announcing-general-availability-version-of-the-weblogic-server-kubernetes-operator

                                                      WebLogic Server Kubernetes Operator(以下Operator)の一般提供(GA)リリースの発表ができうれしく思っています。OperatorはTechnology Previewとして2月にリリースしたもので、Kubernetes環境でWebLogic Server 12.2.1.3ドメインの作成、管理を簡単にするものです。このGA版では、Technology Previewの機能に加え、その他のWebLogic Serverの機能もサポートしており、開発、本番用途でご利用いただけるように動作保証ならびにサポートいたします。

                                                      この動作保証にはOracle Cloud Infrastructure(OCI)ならびにTerraform Installer for Kubernetes on Oracle Cloud Infrastructureを使って作成したKubernetes Clusterで動作するOperatorとWebLogic Serverの構成のサポート、そしてOracle Cloud Infrastructure Registry(OCIR)を使ったOperatorとWebLogic Serverドメインイメージの保存に対するサポートが含まれます。
                                                      Oracle Cloud Infrastructure
                                                      https://cloud.oracle.com/ja_JP/cloud-infrastructure
                                                      Terraform Installer for Kubernetes on Oracle Cloud Infrastructure
                                                      https://github.com/oracle/terraform-kubernetes-installer/

                                                      Kubernetes上でのWebLogic Serverの動作保証ならびにOperatorに関する追加情報は、以下のサポートドキュメントと発表のブログエントリをご覧ください。
                                                      WebLogic Server 12.2.1.3 Certification on Kubernetes (ドキュメントID 2349228.1)
                                                      https://support.oracle.com/rs?type=doc&id=2349228.1
                                                      WebLogic Server Certification on Kubernetes
                                                      https://blogs.oracle.com/weblogicserver/weblogic-server-certification-on-kubernetes
                                                      https://orablogs-jp.blogspot.jp/2018/01/weblogic-server-certification-on.html
                                                      KubernetesがWebLogic Serverインスタンスをホストするコンテナインフラストラクチャとして機能するよう、WebLogic ServerとKubernetesを統合するためにOperatorを開発してきました。OperatorはWebLogicドメインの作成、構成、管理をするためにKuberenetesを拡張します。以前の発表のエントリをご一読いただいた上で、WebLogic Server Kubernetes OperatorのGitHubプロジェクトをご覧ください。
                                                      Announcing the New WebLogic Server Kubernetes Operator
                                                      https://blogs.oracle.com/weblogicserver/announcing-the-new-weblogic-server-kubernetes-operatorhttps://orablogs-jp.blogspot.jp/2018/02/announcing-new-weblogic-server.html
                                                      Oracle Weblogic Server Kubernetes Operator
                                                      https://github.com/oracle/weblogic-kubernetes-operator
                                                      Kubernetes上でWebLogic Serverを実行すると、以下のことが可能になります。
                                                      • Kubernetes環境でWebLogic Serverのアプリケーションを活用できる
                                                      • WebLogic Serverアプリケーションを他のクラウドアプリケーションと統合できる
                                                      • WebLogic Serverの使用を発展させ、Kubernetesの使用を拡大することができる
                                                      Operatorを使うと、以下のことが可能になります。
                                                      • Kubernetes内のWebLogic Serverの管理を簡素化
                                                      • KubernetesのリソースのWebLogicドメインへの割り当てを確保
                                                      • ロードバランサ、Ingress controller、ネットワークファブリック、セキュリティなどの環境全体をKubernetesのAPIを使って管理
                                                      • パッチ適用やスケールといった操作の簡素化ならびに自動化
                                                      • WebLogicのベストプラクティスに則ることの保証
                                                      • WebLogicドメインを問題なく、安全に実行
                                                      OperatorのこのバージョンとWebLogic Server Kubernetesの動作保証では、以下の機能およびサポートを追加しています。
                                                      今後の計画には、以下のものが含まれます。
                                                      • OCI Container Engine for Kubernetesで動作するKubernetes上のWebLogic Serverの動作保証
                                                      • WebLogic Deploy Toolingを使った、既存KubernetesのWebLogic Serverドメインへの簡単な再プロビジョニングならびに再デプロイ方法の提供
                                                      • Oracle Container Pipelines(werckerとしても知られています)を使ったKubernetes上のWebLogicデプロイメントのCI/CDの追加
                                                      • その他時間と共に追加される新機能や機能強化
                                                      詳細はしばしお待ちください。この発表がKubernetesにWebLogic Serverをデプロイする方法を求めていた方に役立つことを願っています。是非フィードバックをお寄せください。

                                                      [Database, Cloud] Announcing Oracle SQL Developer Web!

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://www.thatjeffsmith.com/archive/2018/05/announcing-oracle-sql-developer-web/

                                                      Oracle CloudでOracle SQL Developer Webがご利用いただけるようになりました!
                                                      「でも、それって何?」というあなたに。
                                                      これはブラウザベースのOracle SQL Developerで、Oracle REST Data Servicesを使っています。
                                                      Oracle Database Cloudをお使いのお客様であれば、順次ロールアウトしているところです。

                                                      もっと知りたい方や簡単なデモを見たい方のために以下の動画を用意しました。

                                                      [Cloud] A New Oracle Autonomous Visual Builder Cloud Service - Visual and Coding Combined

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/vbcs/a-new-oracle-autonomous-visual-builder-cloud-service-visual-and-coding-combined

                                                      Oracle Autonomous Visual Builder Cloud Service (VBCS) の一般提供を発表できうれしく思います。これは組み込み済みの自律的な機能群を持っており、JavaScriptベースのアプリケーションのための、ビジュアル開発&Low-code(コードをほとんどもしくは全く書かない)開発のためのプラットフォームです。
                                                      これまでの数年にわたり、VBCSのビジュアル開発のアプローチは、カスタムアプリケーションを構築するためのプラットフォームの、コードを書く必要のない性質を活用した市民開発者に対する非常に魅力的なソリューションでした。
                                                      ところが、多くのプロフェッショナルな開発者も、彼らが見たビジュアル開発体験に興味関心を表していましたが、追加機能を求めていました。

                                                      具体的には、プロフェッショナルな開発者はビジュアルツールが生成するコードに直接アクセスして変更したり、よりリッチな挙動をするようにカスタムコードで機能追加したりしたい、という要求がありました。

                                                      このVBCSの新バージョンでは、VBCSのLow-codeの特性は維持しつつ、直接コードにアクセスして操作するという要求に対応しています。

                                                      Visual and Code Based Development Combined

                                                      以前のバージョンと同様、ビジュアルWYSIWYGレイアウトエディタでUIを開発できます。既存のVBCSユーザーは、コンポーネントパレットの一連のUIコンポーネントがずっと増えたことに気付くことでしょう。実はOracle JET(OracleのオープンソースJavaScript Extension Toolkit)が提供する全てのコンポーネントにアクセスできるようになりました。
                                                      Oracle JET
                                                      http://oraclejet.org/
                                                      さらに、Web-components標準ベースのOracle JETコンポジットコンポーネントアーキテクチャ(CCA)を使い、パレットにより多くのコンポーネントを追加できます。


                                                      Visual Editorに関して知っておくべきことは、新たに”Code"ボタンが右上部に追加された、ということです。これをクリックすると、プロフェッショナル開発者はページレイアウトを構成するHTMLコードに直接アクセスできるようになります。このコードがピュアなHTML/JavaScript/CSSベースであることがわかって喜んでもらえると思います。これを使ってこれまでの専門知識を生かしてカスタマイズできます。code insight、シンタックスハイライト、ドキュメントへのアクセス、直接ブラウザでコードの再フォーマットなどといったスマートコードエディタの機能を活用して、開発者は直接コードを操作できます。



                                                      ビジュアル開発アプローチはページレイアウトに限定されません。ビジネスロジックの定義もできるよう拡張しています。新しいアクションフローエディタでロジック・フローを定義できます。操作のコレクションを使って宣言的な方法で定義できますし、独自の機能のための特定のJavaScriptコードを呼び出すこともできます。



                                                      開発者がコードに直接アクセスできるようになったので、Gitとの統合も追加しました。Oracle Developer Cloud Service (DevCS) で提供するプライベートGitリポジトリを使います。
                                                      Oracle Developer Cloud Service
                                                      https://cloud.oracle.com/ja_JP/developer-service
                                                      VBCSアプリケーション開発にあたり、チーム開発でIssue追跡、バージョン管理、アジャイル計画やコードレビュープロセスといったDevCSのアジャイルメソドロジーの機能を活用できます。

                                                      Mobile and Web Development Unified

                                                      この新しくなったVBCSを使って、Webブラウザベースのアプリケーション、デバイス上で稼働するモバイルアプリケーション両者間の開発者体験をさらに統合します。

                                                      同じプロジェクトで両方のタイプのアプリケーションを作成できます。同じ開発方法、アプリケーション・アーキテクチャ、UIコンポーネント、カスタムビジネスオブジェクトや外部RESTサービスへのアクセスを活用できます。

                                                      モバイルアプリケーションの開発が終了したら、モバイルデバイスにインストール、テスト、実行するモバイルアプリケーションとしてパッケージングします。Oracle JETが種々のモバイルプラットフォーム用に提供するネイティブLook & Feelを活用できます。


                                                      Standard-Based Data Openness

                                                      この新しいVBCSを使うと、数回ボタンをクリックすれば、任意のRESTデータソースにVBCSを接続でき、宣言的な方法で外部RESTソースを利用できます。VBCSは標準のSwagger (OpenAPI Spec 2.0)ベースの記述を読み取ることができるので、簡単にRESTデータソースを利用できます。サービスの構造表現の詳細がない場合でも、VBCSの宣言的なダイアログでセキュリティ設定、ヘッダーパラメータやURLパラメータといった任意のサービスへのアクセスを簡単に定義できます。VBCSはサービスからのレスポンス構造の解析やUIでデータアクセスを可能にする変数の作成も簡単です。



                                                      VBCSを使えば、再利用可能なカスタムのビジネスサービスを定義できることを忘れないでください。VBCSはデータベース・オブジェクトを作成してこれらのオブジェクトに情報を格納し、強力かつセキュアなRESTサービスを提供します。このサービスを使えば、こうしたオブジェクトをVBCSだけでなく外部アプリケーションからもアクセスできます。

                                                      Visual Builder Cloud Service Goes Autonomous

                                                      今日リリースされたVisual Builder Cloud Serviceには、反復的なタスクを自動化ならびに排除するための自律機能が組み込まれているため、アプリのケーションの設計と開発に専念できます。

                                                      サービスの設定とプロビジョニングは、たった1個のボタンをクリックするだけで簡単です。必要なのは、サーバーに付ける名前だけです。それが終われば、ボタンをクリックするだけで、すべてを構成します。基盤となるプラットフォームをインストールして設定する必要はありません。サービスは自動的にデータベース、アプリケーションをホストするサーバー、および完全な開発プラットフォームをプロビジョニングします。

                                                      One click install

                                                      この新しいautonomous VBCSは開発・デプロイ環境の管理のための手作業を減らします。サービスをプロビジョニングしたら、パッチの適用、アップデート、バックアップは我々Oracleが実施します。

                                                      さらに、autonomous VBCSでは自動的にモバイルアプリケーションの公開基盤をメンテナンスします。ボタンをクリックするだけで、モバイルアプリケーションをiOSやAndroidパッケージにパブリッシュし、データやアプリケーションをホストするスケーラブルなバックエンドサービスにWebアプリケーションをホストします。

                                                      But Wait There is More

                                                      その他にもこの新しいOracle Visual Builder Cloud Serviceにはたくさんの新機能があります。より速くデリバリしたいと思っている経験豊富なJavaScriptの専門家、JavaScript開発という野生の世界での最初の一歩を踏み出そうとしている開発者、ビジネスアプリケーションを構築しようとするサンデープログラマーのいずれの方々にとっても有用なものが、Visual Builderにはあります。

                                                      ぜひお試しください。この体験を楽しんでもらえると思っています。

                                                      詳細情報やフリートライアルなどについては、以下のURLをどうぞ。
                                                      Autonomous Visual Builder Cloud
                                                      http://cloud.oracle.com/visual-builder

                                                      [Cloud] Learning App Development with Visual Builder Cloud Service - Demos & Tutorials

                                                      $
                                                      0
                                                      0
                                                      原文はこちら。
                                                      https://blogs.oracle.com/vbcs/learning-app-development-with-visual-builder-cloud-service-demos-tutorials

                                                      新しくなったOracle Visual Builder Cloud Serviceを使ってアプリケーションを開発するにはどうすればいいか知りたくありませんか?

                                                      ご用意しました!以下のOracle Visual Builder YouTube Channelに開発者体験を説明する動画がUpされています。
                                                      Oracle Visual Builder Cloud Service
                                                      https://www.youtube.com/channel/UCFMTiIZAE6f3Ib91sY6Ms3g/featured
                                                      一部の動画をご紹介しましょう。

                                                      Developing a Web Application in 10 Minutes


                                                      Developing an On-Device Mobile Application in 10 Minutes


                                                      試したくなったでしょ?
                                                      Getting Started with Oracle Visual Builder Cloud Serviceというプレイリストを作成しました。最初からアプリケーション公開までを以下の4個の動画で説明しています。
                                                      Getting Started with Oracle Visual Builder Cloud Service
                                                      https://www.youtube.com/playlist?list=PLSKf-atSzZejAz7ZIIWTWXEnX5M_Co7AV


                                                      手順に従うよりは自分でがしがしやりたい、ということであれば、とっかかりはドキュメントをご覧頂くことが一番でしょう。
                                                      具体的にはStep-by-stepチュートリアルをご覧ください。
                                                      Oracle Visual Builder Cloud Service Tutorials
                                                      https://docs.oracle.com/en/cloud/paas/app-builder-cloud/tutorials.html
                                                      Viewing all 760 articles
                                                      Browse latest View live


                                                      <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>