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

原文はこちら。
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クラスタのスケールの決定を簡単に構成できることもご紹介いたしました。

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

原文はこちら。
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のためにこれらのテクノロジーを進化させていきたいと考えています。

[Java] The road to Jakarta EE

原文はこちら。
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] Oracle Dev Tour Japan 2018

風薫る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:45
岡山県立図書館
サークル活動室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/23 (水) 19:00-21:00
開場:18:30
日本オラクル株式会社 北日本支社
北海道オフィス セミナールーム
https://javado.connpass.com/event/86481/

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

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

原文はこちら。
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

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

原文はこちら。
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] Announcing the release of Oracle Linux 7 Update 5

原文はこちら。
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

[Java] Announcing GraalVM: Run Programs Faster Anywhere

原文はこちら。
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 bitcode
  • 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な世界のためのこの次世代テクノロジーを作っていくことを楽しみにしています。

[Cloud] Which PaaS are available on OCI?

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

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

原文はこちら。
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

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

原文はこちら。
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 ~ 500MB FTP、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関数もしくは添付を利用)
            〜10MB BASE64、もしくは添付
              任意
              2FTP

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

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

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

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


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

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

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

                            (注意)
                            バイナリファイルはStageFile操作で読み取り不可
                            10MB〜 1. 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統合インタフェースに送信する場合

                                  (注意)
                                  展開後のファイルサイズが10MB以下
                                  コンテンツ形式は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 - ファイルのセグメント読み取り
                                          65と同様だが、ファイルサイズが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 - ファイルのセグメント読み取り
                                              7SOAP/REST/HTTPインターフェースのレスポンス(メディアタイプはapplication/octet-stream)からファイルを取得する場合


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

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


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

                                                    Conclusion

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

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

                                                    原文はこちら
                                                    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,...)
                                                    
                                                    是非楽しんでください。みなさんにもメリットがあるか、どんなときにメリットがあるかお知らせください。

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

                                                    原文はこちら
                                                    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, Cloud, Virtualization] Running VirtualBox inside a VM instance in Oracle Cloud Infrastructure

                                                    原文はこちら。
                                                    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, Integration] Introducing Oracle Self-Service Integration Cloud Service

                                                    原文はこちら。
                                                    https://blogs.oracle.com/integration/introducing-oracle-self-service-integration-cloud-service

                                                    過去10年間でIntegration分野での最もエキサイティングなイノベーションの1つが、統合の必要な生産性アプリの急増に対応するのにちょうど間に合うようにEnterpriseに到来しました。一般に、約2,300のSaaSビジネスアプリケーションが統合の必要があります。マーケティングキャンペーンマネージャーやセールスマネージャーなどの現場の人たちは、IT部門に依頼せずに、これらのアプリケーション自体を迅速かつ簡単に自分たちで統合することを検討しています。
                                                    Oracle Self-Service Integration Cloud Service(SSI)は、SlackやEventbriteなどの生産性アプリをビジネスに結びつけるツールです。例えば、キャンペーンのための新しいデジタルアセットができあがる都度、マーケティングキャンペーンマネージャーはアラートを受け取ることができます。または、あなたがカスタマーサポート担当者なら、インシデントが終了したときにアンケートのリンク配信を自動化しようとするでしょう。セールスマネージャーであれば、イベント出席者にフィードを送り、回答者をCRMに登録したいかもしれません。SSIには、これらすべてのニーズに対応する機能があります。

                                                    Oracle Self-Service Integrationはこうしたビジネスの課題に対し、以下の方法で解決します。
                                                    1. Connecting productivity with enterprise apps
                                                      エンタープライズアプリケーションとの統合が必要なソーシャルアプリケーションや生産性アプリケーションの急速な拡大に対応
                                                    2. Enabling Self-Service Integration
                                                      現場の非IT部門ユーザー自身で、コーディングせずにアプリケーションに接続し、反復的なタスクの自動化が可能
                                                    3. Recipe-based Integration
                                                      クラウドアプリケーション・コネクタのインターフェースやライブラリ、すぐに使えるレシピを使い、最新のクラウドアプリケーションを使って自身の仕事の生産性を簡単に向上
                                                    SSIは、従来のエンタープライズ・アプリケーションとSlackなどのコラボレーション・アプリケーションを統合して生産性を向上させ、初期設定と必要な高度な統合のためのIT部門による作業負荷を軽減し、基本的な統合のアップデートを現場のユーザーに任せることができるため、結果としてより早く統合とそのアップデートを実現します。SSIの利用にあたってトレーニングは不要です。すぐに使えるレシピと、顧客が追加したイベントを単にアクティブ化するだけで、自動的に統合の流れを呼び出します。

                                                    詳しく知りたい方は、2018年4月18日の午前10時(PT)/午後1時(ET)にVikas Anand (Oracle Vice President of Product Management)が説明するWebcastにご参加ください。
                                                    (訳注)
                                                    日本時間では、2018年4月19日(木)午前2時からです。
                                                    • セルフサービスやブロックチェーン、AIといったIntegrationのトレンド
                                                    • Oracle Self-Service Integration Cloud Serviceで実現可能なソリューション
                                                    • friction-lessなエンタープライズへの旅路(Journey)
                                                    登録はこちら

                                                    Oracle Self-Service Integration Cloud Serviceの概要はSSI ebookをご覧ください。
                                                    Make Your Cloud Work for You
                                                    https://cloud.oracle.com/opc/paas/ebooks/Self_Service_Integration_Cloud_Service_eBook.pdf

                                                    [Cloud, Linux] How to use Terraform with Oracle Linux and Oracle OpenStack 4.0

                                                    原文はこちら。
                                                    https://blogs.oracle.com/linux/how-to-use-terraform-with-oracle-linux-and-oracle-openstack-40

                                                    先日、Oracle Linux Developer CommunityにHow to use Terraform with Oracle Linux and Oracle Cloud Infrastructure (OCI)という記事を投稿しました。
                                                    How to use Terraform with Oracle Linux and Oracle Cloud Infrastructure (OCI)
                                                    https://community.oracle.com/docs/DOC-1019936
                                                    本日、Oracle Linux Developer CommunityにHow to use Terraform with Oracle Linux and Oracle OpenStack 4.0という記事を投稿しました。
                                                    How to use Terraform with Oracle Linux and Oracle OpenStack 4.0
                                                    https://community.oracle.com/docs/DOC-1022601
                                                    Infrastructure as a codeは関心のあるトピックであり、ol7_developer yumチャネルを使用してTerraformバイナリを簡単にインストールするなど、Oracle Linuxと協調します。Infrastructure as a codeは、データセンターのコンピューティングリソースを機械が読める定義ファイルを使ってプロビジョニングするというプロセスで、手作業によるシステム管理、対話型UI、コマンドラインといった、これまでのツールやテクニックを置き換えることができます。Terraformは、サポートされているパブリッククラウド内で利用されるハイレベルな構成言語で、APIを使いながら複雑なデータセンターのインフラストラクチャを定義することができるオープンソース・ソフトウェアです。

                                                    Oracle OpenStack 4.0の詳細情報は以下をご覧ください。
                                                    Oracle OpenStack 4.0
                                                    https://docs.oracle.com/cd/E90981_01/
                                                    TerraFormの詳細情報は以下をご覧ください。
                                                    Terraform
                                                    https://www.terraform.io/

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

                                                    UEKのソースは、全てのgit履歴があるgitリポジトリとして、いつでもoss.oracle.comで入手できますが、UEKのソースをgithubに掲載するようになりました。これにより、私たちは作業の可視性を高め、人々がUEKのソースにアクセスしてもらいやすくすることを意図しています。
                                                    oss.oracle.com - linux-uek.git / tags
                                                    https://oss.oracle.com/git/gitweb.cgi?p=linux-uek.git;a=tags
                                                    Oracle Linux UEK: Unbreakable Enterprise Kernel
                                                    https://github.com/oracle/linux-uek/
                                                    また、パートナー企業やLinuxコミュニティの開発者との作業でもこのリポジトリを使用します。リポジトリには、メインラインのLinuxカーネルソースツリーでまだ受け入れられていない少数のOracleの追加コードを含む、Unbreakable Enterprise Kernelのソースが含まれています。

                                                    Unbreakable Enterprise Kernel(UEK)は、Oracleが構築し、Oracle Linuxサポートを通じてサポートされるLinuxカーネルです。メインラインのソースコードを可能な限り厳密に追随して、パフォーマンス、安定性、最小限のバックポートを重視しています。OracleのEngineered System、Oracle Cloud Infrastructure、およびOracleの顧客向けの大企業向けのデプロイメントのためにUEKは十分にテストされ、使用されています。

                                                    毎週の開発ビルドのソースをGitHubに掲載しています。このリポジトリからビルドするには、GitHub READMEファイルに示されている追加の依存関係が必要です。
                                                    Oracle Linux UEK: Unbreakable Enterprise Kernel
                                                    https://github.com/oracle/linux-uek
                                                    プロダクションビルドのソースはgitから引き続き入手可能です。
                                                    oss.oracle.com - linux-uek.git / tags
                                                    https://oss.oracle.com/git/gitweb.cgi?p=linux-uek.git;a=tags
                                                    KERNEL.ORG
                                                    のバージョン
                                                    リリース
                                                    ステータス
                                                    サポートする
                                                    Oracle Linux
                                                    バージョン
                                                    UEK Release 5: github uek5/master
                                                    https://github.com/oracle/linux-uek/tree/uek5/master
                                                    v4.14DevelopmentOracle Linux 7
                                                    UEK Release 4: github uek4/master
                                                    https://github.com/oracle/linux-uek/tree/uek4/master
                                                    v4.1ProductionOracle Linux 6
                                                    Oracle Linux 7
                                                    UEK Release 3: github uek3/master
                                                    https://github.com/oracle/linux-uek/tree/uek3/master
                                                    v3.8ProductionOracle Linux 5
                                                    Oracle Linux 6
                                                    Oracle Linux 7
                                                    UEK Release 2: github uek2/master
                                                    https://github.com/oracle/linux-uek/tree/uek2/master 
                                                    v3.0ProductionOracle Linux 5
                                                    Oracle Linux 6

                                                    Oracleは長年にわたりLinuxに貢献してきました。カーネルの変更をアップストリーム化してオープンソースにしておくことに常に重点を置いてきました。変更をオープンソースにしておくことで、アップストリームのLinuxカーネルとの迅速な統合が可能になり、自分たちが貢献した成果に加えて、最先端のドライバやファイルシステム、ハードウェアサポート、コミュニティからのセキュリティ修正が得られます。

                                                    2007年以来、オラクルは40万行以上のコードをLinuxに提供しており、Linuxのトップ15の常勤者に7,500以上のチェンジセットを提供する、Linuxにおけるトップ15に入るコントリビュータ―です。たとえば、Btrfs、OCFS2やRDSはもともとOracleで作成され、提出されました。また、XFS(メンテナーがOracleで働いています)とNFSにも大きな貢献をしています。

                                                    OracleのLinuxチームは、各アップストリーム・カーネル・リリースにおけるトップ10のコントリビュータです。 私たちの使命は、Linuxを改善すること、すなわち、より高い性能、より良いセキュリティ、より高度な診断能力を面での改善を意味します。また、OSの基本に焦点を当て、スケジューラとコアメモリの割り当てルーチンを改善しています。

                                                    Oracle Developer CommunityのOracle LinuxおよびUEKプレビュー・スペースで、質問をしたり、問題を報告したり、提案したりしてください。
                                                    Oracle Linux and UEK Preview
                                                    https://community.oracle.com/community/server_&_storage_systems/linux/oracle_linux_and_uek_preview
                                                    GitHub経由でプルリクエストを受け付けませんが、アップストリームコミットへのポインタは歓迎します。UEKソースはgithubに公開していますがサポートはありません。コンパイル済みバイナリおよびサポート対象のエンタープライズ・ディストリビューションの場合、Oracle Linuxは無料でダウンロード、配布、使用でき、以下から入手できます。
                                                    Oracle Linux Downloads
                                                    http://www.oracle.com/technetwork/server-storage/linux/downloads/index.html
                                                    個別のパッケージと更新は、Oracle Linux yumサーバからダウンロードできます。
                                                    Oracle Linux Yum Server
                                                    https://yum.oracle.com/