[Cloud] Oracle Cloud Infrastructure Terraform Provider Now Supported by HashiCorp

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/oracle-cloud-infrastructure-terraform-provider-now-supported-by-hashicorp

Terraformの公式プロバイダとしてご利用頂ける、Oracle Cloud Infrastructure用のHashiCorp Terraform Providerをすぐにご利用頂けることを発表できうれしく思っています。
Oracle Cloud Infrastructure Provider
https://www.terraform.io/docs/providers/oci/index.html
HashiCorpとのパートナーシップ、そしてInfrastructure-as-Codeの旅でお客様をサポートできることにわくわくしています。

ここ数ヶ月にわたり、TerraFormへ多大な投資をした結果、全てのOracle Cloud Infrastructureリソースに対するTerraformを使ったプロビジョニングをサポートできるようになりました。Oracle Cloud Infrastructure ProviderはTerraform 0.10.1以後との互換性があります。以下はTerraformプロバイダがサポートする主要なリソースです。
  • Block Volumes
  • Compute
  • Container Engine
  • Database
  • File Storage
  • Identity and Access Management (IAM)
  • Load Balancing
  • Networking
  • Object Storage
サポート対象のリソースの詳細リストや使い方などの詳細情報は、以下のURLからどうぞ。
Oracle Cloud Infrastructure Provider
https://www.terraform.io/docs/providers/oci/index.html
TerraformやOracle Cloud Infrastructure providerのことを余りご存知ないお客様は、構成時にterraform initを実行してください。このコマンドでプロバイダを自動的にダウンロードします。

以前のバージョンを利用しており、最新バージョンにアップグレードしたいお客様は、手作業でインストール済みのプロバイダを削除するか、構成ファイルで3.0.0を指定した上で、terraform initを実行する必要があります。詳細は、アップグレードガイドをご覧ください。
Terraform OCI Provider Version 3
https://www.terraform.io/docs/providers/oci/guides/version-3-upgrade.html
Oracle Cloud InfrastructureでComputeインスタンスを作成するEnd-to-Endの例は、以下のサンプルをご覧ください。
Terraform Provider for OCI - Manage instances with multiple attached volumes
https://github.com/terraform-providers/terraform-provider-oci/tree/master/docs/examples/compute/instance
このリリースに続いて、Oracle Cloud Infrastructure用のTerraformモジュールが公式のTerraform Module Registryで公開される予定です。このモジュールを使うと、お客様がよく使われるOracle Cloud Infrastructureの構成の発見、展開が簡単になります。
Terraform Module Registry
https://registry.terraform.io/ 
このリリースに関する詳細は、以下のリソースをチェックしてください。

[.NET, Kubernetes, Docker] Running .NET Core on the Oracle Container Engine for Kubernetes

原文はこちら。
https://blogs.oracle.com/cloudnative/dotnet-core-on-kubernetes

先日、Getting Function'l with Kubernetesイベントの参加者から.NET CoreアプリケーションをKubernetesで実行する件について質問をもらいました。
It's a Wrap! Getting Function'l with Kubernetes
https://blogs.oracle.com/cloudnative/its-a-wrap-getting-functionl-with-kubernetes
「直近では、クラウドネイティブアプリを稼働させることに関して、Windowsと.NETの世界はどうなっているのだろう」と思ったのですが、そのことをKubernetesに関するLinkedIn Learningチュートリアルを撮影したときに思い出しました。「WindowsでMinikubeを使ってKubernetesを実行するのはそれほど難しいことではないが、.NETアプリケーションを実行するのはどうなのだろう?」
Learning Kubernetes
https://www.linkedin.com/learning/learning-kubernetes
時間を掛けてエコシステムを調べました。このエントリでは、Oracle Container Engineでサンプルの.NETアプリケーションを実行する方法を説明します。
Container Engine for Kubernetes
https://cloud.oracle.com/containers/kubernetes-engine
コードに直接触れたい開発者は、以下のURLでコードを確認できます。
Running a dotnet app in Kubernetes
https://github.com/karthequian/dotnet-example
これらのすべてのサンプルをMac上に構築しましたが、どのプラットフォームを選択してもすべて実行できるはずです。何らかの理由で立ち往生した場合は、(原文のコメント欄に)コメントしてください。はまっている問題を再現して調査します。

以前.NETアプリケーションを書いたのは5年以上前なので、Macに必要なものを全てインストールする必要がありました。まず、.NET Core Web APIアプリケーションを作成するために、Microsoftが公開しているシンプルな.NETチュートリアルをはじめました。
.NET Tutorial - Hello World in 10 minutes
https://www.microsoft.com/net/learn/get-started-with-dotnet-tutorial
より多くのエンドポイントやコードを追加することを考えましたが、最終的にはチュートリアルでできあがるコードと同じように、シンプルにしました。読者を.NET REST APIの魔法で混乱させたかったのではなく、Kubernetesプラットフォームでアプリケーションを実行したかったからです。補足として、dotnetコマンドは非常にすばらしいです。開発、ビルド、テストを全て非常にシームレスに実現し、一日中dockerコマンドとkubectlコマンドを実行するクラウドネイティブ開発者にとって直覚的なコマンドです。

必要なもののインストールが終了したら、シンプルなASP.NET Core Web APIアプリケーションを以下のコマンドを使って作成しました。
~$ dotnet new webapi --auth None --no-https
本格的なアプリケーションの場合、機密データを扱っている場合は認証を設定し、httpsも有効にする必要があります。 このコマンドを実行すると、簡単なREST APIを作成する新しいwebappを作成します。以下のような出力が出ます。
~$ dotnet new webapi --auth None --no-https
The template "ASP.NET Core Web API" was created successfully.
Processing post-creation actions...
Running 'dotnet restore' on /Users/karthik/dev/src/github.com/karthequian/dotnet-example/dotnet-example.csproj...
  Restoring packages for /Users/karthik/dev/src/github.com/karthequian/dotnet-example/dotnet-example.csproj...
  Generating MSBuild file /Users/karthik/dev/src/github.com/karthequian/dotnet-example/obj/dotnet-example.csproj.nuget.g.props.
  Generating MSBuild file /Users/karthik/dev/src/github.com/karthequian/dotnet-example/obj/dotnet-example.csproj.nuget.g.targets.
  Restore completed in 1.42 sec for /Users/karthik/dev/src/github.com/karthequian/dotnet-example/dotnet-example.csproj.
Restore succeeded.
すばらしい!これで、この新規作成したアプリケーションを実行するために、 dotnet run をタイプできるようになりました。以下のようにAPIが起動するはずです。
~$ dotnet run
Using launch settings from /Users/karthik/dev/src/github.com/karthequian/dotnet-example/Properties/launchSettings.json...
: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
  User profile is available. Using '/Users/karthik/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
Hosting environment: Development
Content root path: /Users/karthik/dev/src/github.com/karthequian/dotnet-example
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
テストしたい場合には、エンドポイント /api/values/ を以下のように呼び出すことで可能でした。値リストを取得したら、アプリケーションが期待通りに動作していることがわかります。
~$ curl localhost:5000/api/values/

["value1","value2"]
Macで.NET webappが動作したので、ここからは楽しいこと、dockerizeとkubifyをやっていきましょう。

Docker対応のため、以下のDockerドキュメントにあるガイドラインに従って、.NETアプリケーションのDockerイメージを構築しました。
Create a Dockerfile for an ASP.NET Core application
https://docs.docker.com/engine/examples/dotnetcore/#create-a-dockerfile-for-an-aspnet-core-application
エントリポイントの名前がプロジェクト名だったので、 dotnet-example.dll に変更しました。最終的なDockerfileが以下にあります。
Dockerfile
https://github.com/karthequian/dotnet-example/blob/master/Dockerfile
再実行してcurlでテスト後、このアプリケーションを karthequian/dotnetexample としてDockerストアにプッシュしてありますので、テスト目的でこのサンプルアプリケーションを実行できます。
karthequian/dotnetexample
https://store.docker.com/community/images/karthequian/dotnetexample
最後に、これをKubernetesで実行するため、デプロイメントとサービスを作成しました。
Deployment.yaml
https://github.com/karthequian/dotnet-example/blob/master/Deployment.yaml
このyamlファイルは、ホスト上のポート32000上で実行中のnodePortサービスを使用して、コンテナをデプロイメントとして公開します。利便性のため、Kubernetesでデプロイメントとサービスを実行するために以下のコマンドをタイプしてください。
kubectl apply -f https://raw.githubusercontent.com/karthequian/dotnet-example/master/Deployment.yaml
今回は概念実証(Proof of Concept)としてOracle Container Engineでアプリケーションを実行することにしましたが、任意のKubernetesディストリビューションで動作するはずです。今回はKubernetes 1.9.7クラスタでテストしましたが、最新バージョンとの前方互換性もあります。

以下は実行例です。
~$ kubectl apply -f https://raw.githubusercontent.com/karthequian/dotnet-example/master/Deployment.yaml
deployment "dotnetworld" created
service "dotnetworld" created
 ~$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
dotnetworld 1 1 1 1 20s
 ~$ kubectl get services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dotnetworld 10.96.79.93 80:32080/TCP 26s
kubernetes 10.96.0.1 443/TCP 30d
最後に、テストのために、以下に示すようにノードIPとポートに対して再度curlを使ってAPIを呼び出します。
~$ kubectl get services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dotnetworld 10.96.79.93 80:32080/TCP 26s
kubernetes 10.96.0.1 443/TCP 30d
 ~/dev/src/github.com/karthequian/dotnet-example$ kubectl get nodes
NAME STATUS AGE VERSION
129.146.123.174 Ready 30d v1.9.7
129.146.133.234 Ready 30d v1.9.7
129.146.162.102 Ready 30d v1.9.7
 ~$ curl 129.146.162.102:32080/api/values
["value1","value2"]
Oracle Container Service for Kubernetesで管理されたKubernetes 1.9.7で動作する、Dockerコンテナ化され、Macでビルドされた.NET Core Webアプリケーションができあがりました。時間がかかりそうに思われるかもしれませんが、およそ1時間で全て完了しており、全く苦労はありませんでした。

問題に遭遇したり、質問があったりする場合には、(以下の原文の)コメント欄からコメントをお寄せいただくか、@iteration1 へのメンション、またはGitHubのリポジトリでIssueを立ててお知らせください。

[Kubernetes, WLS] Voyager/HAProxy as Load Balancer to Weblogic Domains in Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/voyagerhaproxy-as-load-balancer-to-weblogic-domains-in-kubernetes

Overview

負荷分散は、スケーラブルで復元力のあるアプリケーションを構築するために広く使用されているテクノロジーです。負荷分散の主な機能は、サーバーの監視と、ネットワークトラフィックの複数のサーバー(Webアプリケーション、データベースなど)への分散です。Kubernetesで動作するコンテナ化されたアプリケーションでは、負荷分散も必要です。Oracle WebLogic Server Kubernetes Operator version 1.0で、Voyager/HAProxyのサポートを追加しました。create-weblogic-domain.shスクリプトを拡張してVoyager/HAProxyをすぐに使用できるようにしています。
Oracle Weblogic Server Kubernetes Operator
https://github.com/oracle/weblogic-kubernetes-operator/tree/release/1.0
このスクリプトは、1個のWebLogicドメイン/クラスタのサーバへの負荷分散をサポートしています。このエントリでは、Kubernetesの複数のWebLogicドメインにデプロイされたアプリケーションに対して負荷分散のサポートを拡張するためのVoyager/HAProxyの設定方法を説明します。

Basics of Voyager/HAProxy

HAProxyとVoyagerに詳しくない方は、HAProxyとVoyagerの基本を時間を掛けて学ぶ価値があります。

HAProxyは、TCPおよびHTTPベースのアプリケーション用の可用性の高いロードバランサとプロキシサーバを提供する、無料のオープンソース・ソフトウェアです。(プロセッサ速度とメモリ使用量の面で)高速で効率的であることはよく知られています。HAProxyの初心者ガイドは以下からどうぞ。
HAProxy Starter Guide version 1.9-dev1
http://cbonte.github.io/haproxy-dconv/1.9/intro.html
VoyagerはHAProxyを使うIngressコントローラです(IngressについてはKubernetesのドキュメントを参照してください)。
Ingress
https://kubernetes.io/docs/concepts/services-networking/ingress/
Kubernetesクラスタにインストールすると、VoyagerオペレータはKubernetes IngressリソースとVoyager自身のIngress CRDを監視し、状況に応じてHAProxyインスタンスを自動作成、更新、削除します。 Voyagerオペレータの仕組みを理解するには、voyagerの概要をご覧ください。
Voyager Overview
https://appscode.com/products/voyager/7.1.1/concepts/overview/

Running WebLogic Domains in Kubernetes

wls-operator-quickstartプロジェクトをGitHubからあなたのローカル環境にチェックアウトしてください。このプロジェクトを使うと、最小限の作業でWebLogic Operatorとドメインを設定できます。READMEのPre-Requirementsの章に記載の手順を実行して、ローカル環境を構成してください。
Quick Start of WLS Operator
https://github.com/lilyhe123/wls-operator-quickstart
wls-operator-quickstartプロジェクトとWebLogic Operatorを使用して、Kubernetes上で実行される2つのWebLogicドメインを、それぞれ独自の名前空間に設定します。
  • 'domain1'という名前のドメインは名前空間 'default'で実行され、2個の管理対象サーバ 'domain1-managed-server1'と 'domain1-managed-server2'を含む 'cluster-1'という1個のクラスタを有します。
  • 'domain2'という名前のドメインは名前空間 'test1'で実行され、2個の管理対象サーバ 'domain2-managed-server1'と 'domain2-managed-server2'を含む 'cluster-1'という1個のクラスタを有します。
  • Webアプリケーション 'testwebapp.war' は、domain1とdomain2の両方のクラスタに別々にデプロイされます。このWebアプリケーションには、どちらの管理対象サーバがHTTPリクエストを処理しているかを表示するデフォルトページがあります。
次の手順を実行して、HAProxyの背後にあるWebLogicドメインを準備します。
# change directory to root folder of wls-operator-quickstart
$ cd xxx/wls-operator-quickstart

# Build and deploy weblogic operator
$ ./operator.sh create

# Create domain1. Change value of `loadBalancer` to `NONE` in domain1-inputs.yaml before run.
$ ./domain.sh create

# Create domain2. Change value of `loadBalancer` to `NONE` in domain2-inputs.yaml before run.
$ ./domain.sh create -d domain2 -n test1

# Install Voyager
$ kubectl create namespace voyager
$ curl -fsSL https://raw.githubusercontent.com/appscode/voyager/6.0.0/hack/deploy/voyager.sh \
    | bash -s -- --provider=baremetal --namespace=voyager
以下のようにWebLogicドメインの状態を確認します。
# Check status of domain1
$ kubectl get all
NAME                          READY     STATUS    RESTARTS   AGE
pod/domain1-admin-server      1/1       Running   0          5h
pod/domain1-managed-server1   1/1       Running   0          5h
pod/domain1-managed-server2   1/1       Running   0          5h

NAME                                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
service/domain1-admin-server                        NodePort    10.105.135.58    <none>        7001:30705/TCP    5h
service/domain1-admin-server-extchannel-t3channel   NodePort    10.111.9.15      <none>        30015:30015/TCP   5h
service/domain1-cluster-cluster-1                   ClusterIP   10.108.34.66     <none>        8001/TCP          5h
service/domain1-managed-server1                     ClusterIP   10.107.185.196   <none>        8001/TCP          5h
service/domain1-managed-server2                     ClusterIP   10.96.86.209     <none>        8001/TCP          5h
service/kubernetes                                  ClusterIP   10.96.0.1        <none>        443/TCP           5h

# Verify web app in domain1 via running curl on admin server pod to access the cluster service
$ kubectl -n default exec -it domain1-admin-server -- curl http://domain1-cluster-cluster-1:8001/testwebapp/

# Check status of domain2
$ kubectl -n test1 get all
NAME                          READY     STATUS    RESTARTS   AGE
pod/domain2-admin-server      1/1       Running   0          5h
pod/domain2-managed-server1   1/1       Running   0          5h
pod/domain2-managed-server2   1/1       Running   0          5h

NAME                                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
service/domain2-admin-server                        NodePort    10.97.77.35      <none>        7001:30701/TCP    5h
service/domain2-admin-server-extchannel-t3channel   NodePort    10.98.239.28     <none>        30012:30012/TCP   5h
service/domain2-cluster-cluster-1                   ClusterIP   10.102.228.204   <none>        8001/TCP          5h
service/domain2-managed-server1                     ClusterIP   10.96.59.190     <none>        8001/TCP          5h
service/domain2-managed-server2                     ClusterIP   10.101.102.102   <none>        8001/TCP          5h

# Verify the web app in domain2 via running curl in admin server pod to access the cluster service
$ kubectl -n test1 exec -it domain2-admin-server -- curl http://domain2-cluster-cluster-1:8001/testwebapp/
Kubernetesで両WebLogicドメインが稼働してから、異なるHAProxy機能を使って、2個のWebLogicドメインに帯する単一エントリポイントとしてVoyagerを構成します。

Using Host Name-Based Routing

Ingressリソースファイル 'voyager-host-routing.yaml' を作成します。このファイルにはホスト名ベース・ルーティングを使ったIngressリソースが含まれています。
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
  name: hostname-routing 
  namespace: default
  annotations:
    ingress.appscode.com/type: 'NodePort'
    ingress.appscode.com/stats: 'true'
    ingress.appscode.com/affinity: 'cookie'
spec:
  rules:
  - host: domain1.org
    http:
      nodePort: '30305'
      paths:
      - backend:
          serviceName: domain1-cluster-cluster-1
          servicePort: '8001'
  - host: domain2.org
    http:
      nodePort: '30305'
      paths:
      - backend:
          serviceName: domain2-cluster-cluster-1.test1
          servicePort: '8001'
YAMLファイルを以下のコマンドを使ってデプロイします。
kubectl create -f voyager-host-routing.yaml

Testing Load Balancing with Host Name-Based Routing

ホスト名ベース・ルーティングを行うには、通常はDNSの変更を伴う仮想ホスティングを設定する必要があります。デモ目的のため、curlコマンドを使用して、ホスト名ベース・ルーティングによるロードバランシングをシミュレートします。
# Verify load balancing on domain1
$ curl --silent -H 'host: domain1.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain1-managed-server1
$ curl --silent -H 'host: domain1.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain1-managed-server2

# Verify load balancing on domain2
$ curl --silent -H 'host: domain2.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain2-managed-server1
$ curl --silent -H 'host: domain2.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain2-managed-server2
結果は以下の通りです。
  • ホスト名 'domain1.org' を指定すると、リクエストはdomain1の管理対象サーバで処理される。
  • ホスト名 'domain2.org' を指定すると、リクエストはdomain2の管理対象サーバで処理される。

Using Path-Based Routing and URL Rewriting

この章では、URL書き換えによるパスベース・ルーティングを使用して、ホスト名ベース・ルーティングと同じ動作を実現します。

Ingressリソースファイル 'voyager-path-routing.yaml'を作成します。
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
  name: path-routing
  namespace: default
  annotations:
    ingress.appscode.com/type: 'NodePort'
    ingress.appscode.com/stats: 'true'
    ingress.appscode.com/rewrite-target: "/testwebapp"
spec:
  rules:
  - host: '*'
    http:
      nodePort: '30307'
      paths:
      - path: /domain1
        backend:
          serviceName: domain1-cluster-cluster-1
          servicePort: '8001'
      - path: /domain2
        backend:
          serviceName: domain2-cluster-cluster-1.test1
          servicePort: '8001' 
YAMLファイルを以下のコマンドを使ってデプロイします。
kubectl create -f voyager-path-routing.yaml

Verify Load Balancing with Path-Based Routing

負荷分散の結果を検証するため、curlコマンドを使います。別の方法として、Webブラウザから直接URLにアクセスすることもできます。
# Verify load balancing on domain1
$ curl --silent http://${HOSTNAME}:30307/domain1/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain1-managed-server1
$ curl --silent http://${HOSTNAME}:30307/domain1/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain1-managed-server2

# Verify load balancing on domain2
$ curl --silent http://${HOSTNAME}:30307/domain2/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain2-managed-server1
$ curl --silent http://${HOSTNAME}:30307/domain2/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain2-managed-server2
異なるURLを指定してパスベース・ルーティングによりトラフィックが異なるWebLogicドメインに振り分けられることを確認できます。URL書き換え機能を使えば、最終的に各ドメインの同じコンテキスト・パスを持つWebアプリケーションにアクセスできます。

Cleanup

このエントリの手順を使った演習終了後は、Kubernetesで作成した全てのリソースをクリーンアップしたいと思うことでしょう。
# Cleanup voyager ingress resources
$ kubectl delete -f voyager-host-routing.yaml
$ kubectl delete -f voyager-path-routing.yaml
 
# Uninstall Voyager
$ curl -fsSL https://raw.githubusercontent.com/appscode/voyager/6.0.0/hack/deploy/voyager.sh \
      | bash -s -- --provider=baremetal --namespace=voyager --uninstall --purge

# Delete wls domains and wls operator
$ cd <QUICKSTART_ROOT>
$ ./domain.sh delete --clean-all
$ ./domain.sh delete -d domain2 -n test1 --clean-all
$ ./operator.sh delete

Summary

このエントリでは、Voyagerロードバランサを構成し、WebLogic ServerドメインにデプロイしたTCPベースおよびHTTPベースのアプリケーションのための、可用性の高いリクエストの負荷分散とプロキシサーバ機能を提供する方法を説明しました。このエントリで提供したサンプルでは、Voyagerを複数のWebLogicドメインの前の単一ポイントとして使用する方法を説明しました。ホスト名ベースルーティング、パスベースルーティング、URL書き換えなどのVoyager機能の使用方法を示す例を示しました。このブログが皆様のお役に立つことを願いつつ、是非Kubernetes上のWebLogic環境でVoyagerを使用してみてください。

[Java] End of Public Updates is a Process, not an Event

原文はこちら。
https://blogs.oracle.com/java-platform-group/end-of-public-updates-is-a-process%2c-not-an-event

And so, from hour to hour, we ripe and ripe.
And then, from hour to hour, we rot and rot;
And thereby hangs a tale.


Shakespeare
成功しているソフトウェアプラットフォームとその周辺のエコシステムには、ポジティブなフィードバックサイクルとネガティブなフィードバックサイクルの両方と共生する関係にあります。開発者はプラットフォームを使用して以前では簡単に解決できなかった問題を解決するための製品を構築し、プラットフォームは時間と共に進化し、新しいユースケースに対してもよりフィットするような新機能を提供します。同時に、成功したプラットフォームは、自身のまわりの技術環境の変化に適応するため、あまり使用されていないレガシー機能を廃止したり削除したりしています。

このプロセスは常に動いています。プラットフォームの新バージョンがリリースされると、旧バージョン(の利用)が徐々に減少していくため、プラットフォームプロバイダーは過去ではなく将来に向けて労力を集中できます。

Javaというエコシステムは、10回の主要なプラットフォームの改訂を通じ、このプロセスを何十年にもわたって成功させてきました。長期にわたる強力な下位互換性により、エコシステムに対する投資が保護されます。それと同時に、時間の経過と共にある程度の適応(の作業)は避けられません。そのため、プラットフォームの継続的な成功のためには、既存の投資を保護しながら、大量のエコシステムを最新のリリースに移行する必要があります。

Sun Microsystemsは、これらの2つの目標のバランスをとる戦略を確立しました。それは、一定期間無料の公開アップデートを提供すると共に、異なるニーズを持つユーザーに商業的な長期サポートを提供する、というものです。この戦略によって、あるプラットフォームのバージョンから別のプラットフォームのバージョンに自分のスケジュールで移行したいユーザー、もしくは全く移行したくないユーザーに対して、セキュリティ、パフォーマンス、その他のアップデートを商用ベースで提供しながら、エコシステムの大半がリリースサイクルに無料で追随できます。

Every new beginning comes from some other beginning’s end

Java SE 8は、2014年3月18日にリリースされ、2019年1月にOracle Java SE 8の商用利用者向けのPublic Updateが終了するまで、Oracleはおよそ5年間にわたり無料でPublic Updateを提供してきました。

Oracle Java SE Subscriptionを使うと、商用ユーザーは、拡張機能やクリティカルなパッチを含むOracle Java SE 8のサポートと定期的なアップデートをより長期間にわたって受けることができます。例えば、Java Web Startテクノロジは、少なくとも2025年3月までOracle Java SE 8において商用サポートを継続します。
A Quick Summary on the new Java SE Subscription
https://blogs.oracle.com/java-platform-group/a-quick-summary-on-the-new-java-se-subscription
https://orablogs-jp.blogspot.com/2018/06/a-quick-summary-on-new-java-se.html
Oracle Java SE Roadmap
(日本語)https://www.oracle.com/technetwork/jp/java/eol-135779-ja.html
(英語)http://www.oracle.com/technetwork/java/eol-135779.html
Oracle Java SE 8のすべてのユーザーが商用使用するわけではありません。ある人はゲームをしたり、またある人は消費者向け生産性アプリケーションを実行したりするのに使っています。Oracleは、少なくとも2020年12月まで個人ユーザー向けのOracle Java SE 8のパブリック・アップデートを無料で提供します。その間、個人ユーザーはアプリケーション・プロバイダに連絡し、アプリケーションを最新バージョンのJavaに移行するよう提言したり、代わりのアプリケーションに切り替えたりしてください。
Java Client Roadmap Update
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf

Upgrade to JDK 10

Oracle Java SE 8から最短のアップグレードパスは(現時点では)JDK 10です。アプリケーション開発者向けの説明は、「Oracle JDK 10移行ガイド」を参照ください。
Oracle JDK 移行ガイド リリース10
https://docs.oracle.com/javase/jp/10/migrate/toc.htm
Oracle JDK Migration Guide Release 10
https://docs.oracle.com/javase/10/migrate/toc.htm
Oracle JRockitからの移行ユーザー向けの説明もございます。
JRockitからHotSpotへの移行ガイド リリース10
https://docs.oracle.com/javase/jp/10/jrockit-hotspot/toc.htm
JRockit to HotSpot Migration Guide Release 10
https://docs.oracle.com/javase/10/jrockit-hotspot/toc.htm
このエントリの執筆時点における、Oracleからダウンロード可能な最新のJavaリリースはJDK 10.0.2です。 これはセキュリティベースライン、つまり、最新のOracle Critical Patch Updateで説明されているセキュリティ脆弱性に対する修正が含まれています。
Java SE Downloads
http://www.oracle.com/technetwork/java/javase/downloads/index.html
JDK 10.0.2 Release Notes
http://www.oracle.com/technetwork/java/javase/10-0-2-relnotes-4477557.html

Upgrade to JDK 11

JDK 10は2018年9月下旬にEoLを迎えます。以後のOracle Java SE 8からのアップグレードパスはJDK 11です。Oracle Java SE 11は長期サポート(LTS)リリースであり、 6カ月サイクルになってからのはじめてのリリースです。そのため、Java SE 12リリース後も、Oracle Premier Supportと定期的なアップデートリリースがOracleのお客様に対し提供されます。これにより、Oracle Java SE 11はISVや他の商用ユーザーにとって魅力的な移行ターゲットになります。

JDK 11はまだリリースされていないため、JDK 11を移行先としている開発者の方々は、Java SE 8からの移行作業として、まずJDK 10でアプリケーションを正常に動作させることから開始することを推奨します。以前より速い半年ごとのリリースサイクルゆえに、JDK 10とJDK 11の間の変更の数は、JDK 8とJDK 10の間の変更の数よりはるかに少ないからです。
Fast Forward To 11
https://blogs.oracle.com/java-platform-group/fast-forward-to-11-v2https://orablogs-jp.blogspot.com/2018/09/fast-forward-to-11.html
アプリケーションがJDK 10で問題なく動作したら、開発者はJDK 11リリース候補版ビルドでテストをし、今月待つにリリースされたときにJDK 11への移行準備が完了するようにしてください。
JDK 11 Early-Access Builds
http://jdk.java.net/11/

Upgrade to JDK 12

アプリケーションをOracle Java SE 8からJDK 12に直接移行したい開発者は、同じ移行モデルに従う必要があります。つまり、まずはセキュリティベースラインでの最新のリリース、つまり現在のJDK 10.0.2への移行作業に力を注ぎ、その後アプリケーションが正常に動作したら、最新のJDK 11リリースへの段階的移行に進みます。

アプリケーションがJDK 11で正常に動作したら、開発者はJDK 12 Early Accessビルドでテストを開始してください。
JDK 12 Early-Access Builds
http://jdk.java.net/12/
OracleはJDK 12 Early Accessビルドをクラスパス例外付きGNU General Public Licenseバージョン2の下で定期的に公開しています。
GNU General Public License, version 2, with the Classpath Exception
http://openjdk.java.net/legal/gplv2+ce.html
これらのビルドを使用すると、開発者は新しいJDK 12の機能を評価できるのと共に、既存の機能に対する変更が自社のアプリケーションに及ぼす影響をテストできます。
JDK 12
http://openjdk.java.net/projects/jdk/12/
JDK 12 Early-Access Release Notes
http://jdk.java.net/12/release-notes

Staying with OpenJDK 8 after January 2019

現時点で、OracleのエンジニアはOpenJDKコミュニティのOpenJDK 8アップデートのメンテナンス作業の大半を4年半以上引っ張ってきました。
JDK 8 Update Releases
http://openjdk.java.net/projects/jdk8u/
少なくとも2019年1月まで継続していきますが、その後は、これまでのOpenJDK 6やOpenJDK 7 Updatesの場合と同様、OracleからのコントリビュータはOpenJDKコミュニティにおける彼らの労力をOpenJDK 8 Updatesから現在のJDKリリースに集中させる可能性があります。
[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
これまでのように、適切なパーティーが2019年1月以降OpenJDK 8 Updatesのメンテナンスを継続する場合には、OpenJDKコミュニティにおいて最善の移行方法について議論する予定です。

そのため、Oracleエンジニアの移動後にOpenJDK 8を使用し続けたいユーザーは、2019年1月までにプロジェクトのメーリングリスト(jdk8u-dev)に登録した上で、引き続きメンテナンスしてくれるコントリビュータと、ご自身の期待や計画について議論をして、その時点でのOpenJDK 8で利用可能なサポートの範囲をよりよく理解してください。
jdk8u-dev -- Technical discussion related to the JDK 8 Updates Project
http://mail.openjdk.java.net/mailman/listinfo/jdk8u-dev

[Integration, Cloud] Enabling the Future Today - Feature Flags in Oracle Integration Cloud

原文はこちら。
https://blogs.oracle.com/integration/enabling-the-future-today-feature-flags-in-oracle-integration-cloud

Enabling the Future Today

Integration Cloud内で、全てのお客様に全面開放せずに新機能のトライアルを実現するモデルに移行しつつあります。(クラウドなので)全てのお客様が同じコードベースを実行しているわけですが、機能フラグによって特定のインスタンスで利用可能なものを管理・制御しています。そのようなことをやっている理由はいくつかあります。
  • ユーザーベース全体にロールアウトする前に新機能のフィードバックを得たい
  • 管理された方法で「野放し」にして新機能をテストしたい
  • 予期せぬ問題が発生する可能性のある新機能をロールバックできるようにしたい

How It Works

各新機能に対し、その利用可否を制御するために使うフラグがあります。例えば、小さなフットプリントのOICエージェントのフラグはoic.adapters.connectivity-agent.light-weight-agentでした。このフラグが特定のOICインスタンスで有効になっている場合、軽量の接続エージェントをダウンロードできます。同じコードを実行しているけれどもフラグがOffの他のOICインスタンスでは、新しいエージェントは提供されません。

中央のシステムからフラグを制御しています。Oracleの開発チームやオペレーションチームがリアルタイムで更新できます。つまり、機能フラグは非常に迅速にOnにでき、問題が発生した場合は無効にすることもできます。

Feature Flag Lifecycle

機能フラグには下図のようなライフサイクルがあります。


各ステージについて以下で説明します。

Internal Only

現在利用できないインスタンスでプロダクションマネージャーが機能のデモをするのをご覧になったことがあるかと思います。もしProduction環境のPodを使っている場合、これらのPodは社内ユーザーのみが利用可能なものである可能性があります。これは、お客様向けに利用可能にする前に内部的に試している状態です。内部的にこの機能の評価に問題がなければ、選ばれたお客様とこの機能を共有し、この機能をFeature Controlledフェーズに移行できる状態に到達します。この段階での変更はコードの変更は不要で、内部の承認プロセスで機能を有効にするだけです。

Feature Controlled

機能がFeature Controlledフェーズに到達すると、お客様はお使いのOICインスタンスでフラグを有効にするようにリクエストできます。承認された場合、リクエストされたインスタンスのフラグが有効に設定され、数分以内に機能が使用可能になります。この場合も、お客様のインスタンスにおけるコードの変更はなく、中央の機能フラグサーバでフラグステータスを無効から有効に変更するだけです。

Feature Controlled General Availability

機能の安定性に問題がないと確認できれば、すべてのインスタンスに対して機能を有効化します。 この場合もコードの変更は不要です。特定のお客様で問題が発生した場合、その機能を無効にするか、ロールバックすることができるように、フラグをそのまま残しています。これは、機能の内部ユーザーやアーリーアダプタが遭遇しなかった問題が発生した場合の安全策です。

General Availability

最終的に、機能制御フラグが削除されます。これはエンドユーザーに影響はありません。コードパスをきれいに保ち、新しい機能で廃止された未使用のコードを削除できます。エンドユーザーはこの前後で差異を見つけることはできないでしょう。そのため、コードベースをきれいに保つ方法を説明するためだけと言及しておきます。

What Flags are Available?

以下の機能フラグが現在Feature Controlledフェーズで利用できるものです。これらの機能についてブログエントリで取り上げていく予定にしており、今後、機能の詳細を説明するブログエントリで詳細な説明をしていきます。新機能を追加すると、このエントリを更新していきます(以下は2018/09/13現在の内容です)。
Feature Flag NameDescriptionDetailed Explanation
oic.ics.console.diagnostics.oracle-litmus-support自動テストにおけるLitmusのサポートHow to use Litmus to create OIC Integration unit tests automatically and run them to catch regressions
https://blogs.oracle.com/integration/how-to-use-litmus-to-create-oic-integration-unit-tests-automatically-and-run-them-to-catch-regressions
https://orablogs-jp.blogspot.com/2018/09/how-to-use-litmus-to-create-oic.html
oic.adapter.connectivity-agent.ha接続エージェントのHAサポート
oic.ics.console.integration.throw-action統合にエラーをスローできる機能
oic.ics.console.integration.nested-try-scopes入れ子のスコープを作成できる機能
oic.cloudadapter.adapters.oraclehcmtbeTaleo Business Edition (TBE) Adapter
oic.cloudadapter.adapter.rightnow.mtom.uploadRightnowでMTOMとしてファイルをアップロードできる機能
oic.ics.mapper.jetmap-enablement新しいJet UI ベースのマッパー
oic.cloudadapter.adapters.epmOracle Enterprise Performance Management Adapter (EPM Adapter)
oic.insight.consoles.instanceprogressInsightインスタンスの詳細ページの異なる表示をサポート
oic.cloudadapter.adapter.utilities.wsdluploadUtilities adapterのインバウンド用にWSDLをアップロードできる機能
oic.ics.console.integration.layout擬似コードスタイル・レイアウトとして統合を表示
oic.ics.console.schedule.parameter-override-supportスケジュールパラメータのオーバーライドOverriding Schedule Parameters
https://blogs.oracle.com/integration/overriding-schedule-parameters
https://orablogs-jp.blogspot.com/2018/09/overriding-schedule-parameters.html

How to Request a Feature Flag

お客様のいずれかの環境で機能フラグを有効にするには、My Oracle Supportからサービスリクエスト(SR)を発行してリクエストする必要があります。
My Oracle Support
https://support.oracle.com
SRに以下の情報を記入してください。
  • 有効化したい機能フラグの名前
  • OICインスタンスのURL
  • OICインスタンスのバージョン情報ダイアログに記載の以下の情報

    • バージョン (例) 18.3.3.0.0 (180823.1018.14180)
    • データベース・スキーマのバージョン (例) 18.08.16
    • サービス・インスタンス (例) myinstance
    • アイデンティティ・ドメイン (例) idcs-xxxxxxxxxxxxxxx
    • サービスタイプ (例) Autonomous - 2
  • 有効化が必要な理由
    • 理由とユースケースを説明する(自由形式)
リクエストは承認のためにプロダクトマネージャーに提出されます。承認されると、リクエストが転送されて、要求された環境で機能が有効になります。

Caveats

機能にはいくつかの欠陥が残っている可能性があるため、Controlled Availabilityの状態です。一般提供に先んじて機能フラグで制御された機能を利用することにより、新機能のアーリーアダプターであることを意味していること、スムーズにご利用いただけるよう最善を尽くしていますが、問題にぶち当たる可能性があることにご注意ください。一般提供の前に、機能フラグで有効化している機能を変更しなければならない場合があります。ただ、これだけは知っておいて欲しいのですが、機能フラグを使用することで、当該機能を一般提供する前に、その機能を利用してメリットがあるユーザーに新機能をリリースすることができます。 この方法が、お客様とOracleの両者にとって良い、Win-Winな状態であると考えています。

Previous Flags Now Generally Available

以下は、制御対象の機能がOracle Integration Cloudのすべてのインスタンスで使用可能になったために使用されなくなったフラグです。User ManagedのOracle Integration Cloudを使用している場合、これらの機能を使用するためには、最新のリリースにアップグレードする必要があることに注意してください。
Feature Flag NameDescriptionDetailed Explanation
oic.cloudadapter.adapter.hcm.dataExtractHCM AdapterでのData ExtractConfiguring the Extract Bulk Data Option in an Integration
https://docs.oracle.com/en/cloud/paas/integration-cloud/hcm-adapter/sample-integration-flow-demonstrate-extract-bulk-data-option.html
oic.adapters.hcm-cloud.atom-feed-supportHCM AdapterでのAtom FeedのサポートSubscribing to Atom Feeds in a Scheduled Integration
https://docs.oracle.com/en/cloud/paas/integration-cloud/hcm-adapter/subscribing-atom-feeds-scheduled-integration.html
oic.adapters.connectivity-agent.light-weight-agent軽量な接続性エージェントManaging the Agent Group and the On-Premises Connectivity Agent
https://docs.oracle.com/en/cloud/paas/integration-cloud/integrations-user/managing-agent-groups-and-connectivity-agent.html
oic.cloudadapter.adapter.rightnow.queryCSV.ValidationRightnow adapterでの QueryCSVの検証Specifying QueryCSV Statements when Configuring the Oracle RightNow Cloud Adapter as an Invoke
https://docs.oracle.com/en/cloud/paas/integration-cloud/rightnow-adapter/using-query-csv-invoke-oracle-rightnow-cloud-adapter.html
oic.cloudadapter.adapter.database.batchSelectOracle Database
Adapterを使った、表に対する操作(Select、 Mergeの機能強化)
oic.cloudadapter.adapter.database.batchInsertUpdateOracle Database
Adapterを使った、表に対する操作(Insert、 Updateの機能強化)
oic.cloudadapter.adapters.dbaasdatabaseOracle DBaaS Adapterを使った、表に対する操作(Insert、 Update、Merge、Selectの機能強化)
oic.cloudadapter.adapter.rightnow.noSchema
oic.cloudadapter.adapter.rest.oauth10aPolicyREST AdapterでのOAuthのサポート(OAuth2ではない)
oic.cloudadapter.adapter.rightnow.fileDownloadRightnow (Service Cloud) Adapterでのファイルダウンロード
oic.ics.console.integration.inline-menuドラッグ&ドロップではなく、キャンバスからアクション/トリガー/呼び出しをインラインで追加できるようにする
oic.cloudadapter.adapters.rest_opaOracle Policy Automation Adapter
oic.ics.mapper.encode-decode-on-filesファイルのBase64 Encode/Decode
oic.cloudadapter.adapter.soap.enableMtomSOAP AdapterでのMTOMのサポート
oic.ics.console.connection.soap.uploadzipSOAP AdapterでのZipファイルのアップロード

[Integration, Cloud] Overriding Schedule Parameters

原文はこちら。
https://blogs.oracle.com/integration/overriding-schedule-parameters

A quick recap on schedule parameters

Schedule Parameter(スケジュール・パラメータ)機能は、Scheduled Orchestration Integrations(スケジュールされたオーケストレーション統合)のスカラー変数の追加をサポートします。これらのパラメータ値は、特定の統合のスケジュール実行にわたって使用でき、Assign(割り当て)などのダウンストリームアクションを使って上書きできます。1個の統合に対し、最大5個のスケジュールパラメータを定義できます。

スケジュール・パラメータを使用すると、スケジュール・パラメータで以下のような要件に対応できます。
  1. データの重複処理を避けるため、スケジュールされた統合の最終実行時間(位置)を維持したい
  2. 特定のディレクトリやエリア、リージョン向けの情報を処理したい
上記の通り、スケジュール・パラメータはAssignを使ってオーケストレーション内で更新できます。

この機能の詳細は以下のドキュメントをご覧ください。
Oracle® Cloud
Using Oracle Integration Cloud Service
Creating Parameters in Scheduled Integrations
https://docs.oracle.com/en/cloud/paas/integration-cloud-service/icsug/creating-scheduled-integrations.html#GUID-219DF3E8-2753-435F-9A46-518989A290A8

How to override schedule parameters

現時点では、異なるパラメータ値を持つ(スケジュールパラメータを含む)スケジュールされた統合をユーザが呼び出そうとする場合、統合を非アクティブ化して新しいデフォルト値を設定し、再度アクティブ化する必要があります。

スケジュールパラメータのオーバーライド機能を有効にすると、ユーザーは、非アクティブ化せずに統合を呼び出しながらパラメータ値を指定できます。この機能は、以下の機能フラグで制御されています。
oic.ics.console.schedule.parameter-override-support
この機能を有効化すると、スケジュールパラメータが定義された統合でユーザーが[Submit Now](今すぐ送信)または[Start Schedule](スケジュールを開始)をクリックすると、ポップアップが表示され、ユーザーはパラメータのDefault Value(デフォルト値)とCurrent Value(現在値)を表示し、必要に応じてNew Value(新しい値)を入力してCurrent ValueやDefault Valueを上書きできます。

New Valueはオプションです。新規設定する値を指定しない場合、次回の実行時にはCurrent Valueを使います。Current Valueも設定がない場合、Default Valueを使います。

統合がAssignを使ってこれらのスケジュールパラメータの値を更新すると、更新された値が保存され、次回実行時のCurrent Valueとして利用されます。

当該統合において、Submit NowとStart Scheduleユースケース用のスケジュールパラメータ値は共有されません。

したがって、ユーザがSubmit Now操作の一環で新しいスケジュールパラメータ値を定義した場合、その値はその後のすべてのSubmit Now操作のCurrent Valueとして保存され、表示されます。Start Scheduleのパラメータ値の保存内容に影響を与えることはありません。

[Cloud] General Availability of Virtual Machines with NVIDIA GPUs on Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/general-availability-of-virtual-machines-with-nvidia-gpus-on-oracle-cloud-infrastructure

数週間前、ドイツのISC High Performance 2018というコンファレンスで、NVIDIA Tesla Volta GPU付き仮想マシンインスタンスのプレビュー提供を発表しました。
Oracle’s Continued HPC Investments at ISC High Performance 2018
https://blogs.oracle.com/cloud-infrastructure/oracle-continued-hpc-investments-at-isc-high-performance-2018
お客様は、エンジニアリング・シミュレーションや医学研究から、TensorFlowなどのフレームワークを使用した機械学習トレーニングなどの最新のワークロードまでのさまざまな用途にOracle Cloud InfrastructureのGPUを活用されています。
Oracle Cloud Infrastructure - High Performance Computing
https://cloud.oracle.com/iaas/hpc
今週東京で開催されるNVIDIAのGPU Technology Conferenceに参加しますが、そのまさにこの週、London(UK)およびAshburn(US)リージョンでNVIDIA Tesla Volta V100 GPU搭載の仮想マシンの一般提供いたしました。この発表ができることに興奮しています。ログインすると、通常のOracle Cloud Infrastructureのインスタンスを立ち上げるのと全く同じ方法でこれらのインスタンスを起動できます。

これらの仮想マシンは、今年早々に導入されたベアメタルComputeインスタンスに参加しており、DNNトレーニングなどの非常に計算集約型で高速化されたワークロードや、GROMACSやNAMDなどの従来の高性能コンピューティング(HPC)アプリケーションを実行するサーバー全体を提供します。

最後に、新しいコスト効果の高いGPUオプションとして、Pascal世代のGPUインスタンスがAshburn(US)とFrankfurt(ドイツ)リージョンの仮想マシンで利用できるようになりました。誰にとってもうれしいものがここにあります。

Instance ShapeGPU TypeGPU(s)Core(s)Memory (GB)InterconnectPrice (GPU/Hr)
BM.GPU3.8Tesla V100 (SXM2)852768P2P over NVLINK$2.25
VM.GPU3.4Tesla V100 (SXM2)424356P2P over NVLINK$2.25
VM.GPU3.2Tesla V100 (SXM2)212178P2P over NVLINK$2.25
VM.GPU3.1Tesla V100 (SXM2)1686N/A$2.25
BM.GPU2.2Tesla P100228192N/A$1.275
VM.GPU2.1Tesla P100112104N/A$1.275

また、NVIDIA GPU Cloudを使うと、事前設定済みのイメージをNGCの資格情報とともにデプロイするだけで、HPCアプリケーションやAIアプリケーションのコンテナを起動できます。詳しい手順については以下のURLもしくはGPU製品のページをご覧ください。
Using NVIDIA GPU Cloud with Oracle Cloud Infrastructure
https://docs.cloud.oracle.com/iaas/Content/Compute/References/ngcimage.htm
NVIDIA & Oracle Cloud Infrastructure GPU Cloud Platform
https://cloud.oracle.com/iaas/gpu
最後に、今週のNVIDIAのGTC Conferenceの展示ホールにお越しになってOracle Cloud Infrastructureについてエンジニアリングチームと会話いただけます。また、9月13日午後12時10分開始のブレイクアウトセッションで詳細を知っていただくこともできます。是非お越しください。
GTC Japan 2018
https://www.nvidia.com/ja-jp/gtc/
Advantages of a Bare-Metal Cloud for GPU Workloads
https://www.nvidia.com/ja-jp/gtc/sessions/?sid=2018-1105