[Java] 新しいJavaリリースモデルについて

2018年5月17日に開催されたJava Day Tokyo 2018で、「JDKの新しいリリースモデル」というセッションがありました。
JDKの新しいリリースモデル
http://otndnld.oracle.co.jp/ondemand/javaday2018/JSE-3
スライド7枚目に以下のようにありますね。33枚目には表形式でまとまっています。
  • Oracleの無償用バイナリ (Feature Release)
  • Oracleの有償用バイナリ (LTS Release)
    • 3年ごとのFeature Releaseの特定バージョンに対して設定
    • Java SE 11からリリース予定
で、Feature Releaseの無償用バイナリとは、スライド33枚目にもある通り、OpenJDKベースです。JDK 10の参照実装ダウンロードページにも、以下のようにOpenJDKベースのバイナリであるとの記載があります。
Java Platform, Standard Edition 10 Reference Implementations
http://jdk.java.net/java-se-ri/10
The official Reference Implementation for Java SE 10 (JSR 383) is based solely upon open-source code available from the JDK 10 Project in the OpenJDK Community.
（Java SE 10 (JSR 383)の公式参照実装は、OpenJDK CommunityのJDK 10プロジェクトから入手可能なオープンソースコードのみに基づいています）
Javaのリリースモデル変更に関連して、様々な憶測や解釈、誤解が散見されます。まずはこのセッション・スライドを熟読されることをお勧めします。
- 0 件のコメント:
カテゴリ

[Database] New in 18c: Introduction to In-Memory External Tables in 18c

原文はこちら。
https://blogs.oracle.com/in-memory/introduction-to-in-memory-external-tables-in-18c
2014年6月14日、Larry Ellisonは公式に同じデータを行方向、列方向のいずれからでも透過的にアクセスするための革命的なデュアルフォーマットストレージを導入した、新しいOracle Database In-Memoryオプションのローンチを発表しました。その年のOracle OpenWorldでは、ISV2社がIn-Memory External Tables（IMXT、インメモリ外部表）のサポートのリクエストをしてきました。IMXTのユースケースは以下のようなものです。
  • 顧客がOracleストレージにロードしたくないけれども、短時間で繰り返しスキャンする必要がある、価値の低いデータまたは一時的なデータ
  • Map/Reduceやその他のHadoopアグリゲーションツールで集約されたビッグデータ（レポート用にエンタープライズデータと結合する必要があります）
  • RDBMS側とHadoopツールの両方から問合せを行う必要があるため、Oracleストレージに再度複製する必要がないデータ
エンタープライズデータとビッグデータを単に統合するだけでは、企業にとって価値は生まれないため、両方のソースからのデータを利用して高度な分析をする必要があります。このようなクエリでは、データアナリストが収益向上のために複数の手段を検討するため、繰り返しアプローチが必要になることがよくあります。これらの分析は、あらゆるエコシステムで最も豊富なSQLツールが存在するOracle Database内で実行する必要があり、両方のデータ・ソースへの高性能なアクセスが必要です。比較的短い時間内に外部データを繰り返しクエリする必要がある場合は、HDFSや他の外部ディスク・フォーマットにアクセスすることはコスト効率が悪いため、OracleのDBIM技術の恩恵を受けることができます。

18.1より前では、外部データをOracle Databaseにロードせずに高速スキャンを実行する方法はありませんでした。以前のリリースで使用された、繰り返しの負荷や高性能スキャンを実行するために利用されたメカニズムの1つは、以下のようなものでした。
Create Materialized View <imxtmv>
Build Immediate Refresh Complete On Demand As
Select * From <external table> INMEMORY;
INMEMORY Materialized Viewを作成し、Query_Rewrite_Integrity parameterセッションをSTALE_TOLERATEDに設定します。この場合、クエリプランはその行ソースとしてMAT_VIEW ACCESS INMEMORY FULLと表示されます。

その他関連するリクエストとして、以下のようなものがありました。
  • In-Memory DBLINKs
  • In-Memory only Materialized Views
個人的には、これらの実装計画がどうなっているか承知していません。

What's in Oracle 18.1

18.1では、2個のレガシー・ドライバ（ORACLE_LOADERおよびORACLE_DATAPUMP）を使用する外部表用のINMEMORY MEMCOMPRESS句を実装しました。ビッグ・データ・ドライバ（ORACLE_HDFSおよびORACLE_HIVE）のサポートを追加しています。

INMEMORY句は、Reject Limit句と同じセクションの表定義の最後にあります。
create table s_et(
    s_suppkey            number ,
    s_name               char(25) ,
    s_address            varchar2(40) ,
    s_nationkey          number ,
    s_phone              char(15) ,
    s_acctbal            number ,
    s_comment            varchar2(101)
)
organization external (
type ORACLE_LOADER
default directory T_WORK
access parameters
(
    records delimited by newline
    nobadfile
    nologfile
    fields terminated by '|'
    missing field values are null
  )
  location (T_WORK:'supplier.tbl'))
reject limit unlimited
INMEMORY MEMCOMPRESS FOR CAPACITY;
全てのDBIM圧縮レベルがサポートされ、ヒープ表で実施している場合と同じ意味です。
  • NO INMEMORY
  • INMEMORY
  • INMEMORY NO MEMCOMPRESS
  • INMEMORY MEMCOMPRESS FOR QUERY LOW
  • INMEMORY MEMCOMPRESS FOR QUERY HIGH
  • INMEMORY MEMCOMPRESS FOR CAPACITY LOW
  • INMEMORY MEMCOMPRESS FOR CAPACITY HIGH
'INMEMORY'を単独で使用すると、 'INMEMORY MEMCOMPRESS FOR QUERY LOW'が表示されます。

Table must be fully loaded before use

ヒープ表との主な違いの1つは、テーブル・スキャンで使用できるようになる前に、インメモリ外部表が完全にメモリにロードされている必要があります。外部表では現在、ハイブリッドIn-Memory/On-Diskスキャンはサポートされていません。v$im_segmentsを使用して母集団の状態を確認する方法については、以下のData Dictionaryの章をご覧ください。

Session must set Query_Rewrite_Integrity

In-Memory外部表は、リフレッシュ・オンデマンド・マテリアライズド・ビューのように機能します。In-Memory領域にデータが移入されると、Location句で指定された外部ファイルの変更を認識しません。ヒープ表とは異なり、外部表は一般的にDMLをサポートしていないため、問題はほとんどの場合、1個以上の異なる（より新しい）バージョンに置き換えられている可能性がある、という点です。

したがって、In-Memoryスキャンは外部スキャンとは異なる結果を返す可能性があるため、リフレッシュ・オンデマンド・マテリアライズド・ビューを使用する場合と同じように、ユーザーはこれでOKであることを明示的に知らせる必要があります。 これは次のように設定します。
SQL> alter session set query_rewrite_integrity=stale_tolerated;
最初に記載したユースケースについては、実のところリアルなメリットがあります。例えば、外部プロセスがcsv形式で出力を生成したり、またはmap-reduceジョブがHDFSファイルを作成したりしているとします。インメモリスナップショットをディスクファイルから切り離すと、実行中のクエリを中断することなく外部プロセスを完了できます。次に、外部プロセスが完了したら、dbms_inmemory.repopulateを呼び出して外部データの新しいIn-Memoryスナップショットを作成することができます。 現在、古いスナップショットに対して実行されているクエリは、IMCU（In-Memory Compression Unit、インメモリ圧縮ユニット）の読み取りラッチを保持するため、正常に完了するはずです。

Data Dictionary

外部表の In-Memory 属性を以下の6個のビューのいずれかで確認できます。
  1. USER_EXTERNAL_TABLES
  2. ALL_EXTERNAL_TABLES
  3. DBA_EXTERNAL_TABLES
  4. USER_TABLES
  5. ALL_TABLES
  6. DBA_TABLES
上で示したサンプル表の場合、以下のようにして確認できます。
SQL> column TABLE_NAME format a10
SQL> select table_name, inmemory, inmemory_compression
  2  from user_tables where EXTERNAL = 'YES'

TABLE_NAME INMEMORY INMEMORY_COMPRESS
---------- -------- -----------------
R_ET       DISABLED
N_ET       DISABLED
S_ET       ENABLED  FOR QUERY LOW
3 rows selected.
また、DBIMが外部表を含めるために利用するv$ビューの一部を拡張しています。

v$im_segments とv$im_segment_detail というビューは両者ともIS_EXTERNALという新しい列を持ち、値としてTRUE、FALSEを取ります。例えば、サンプル表をリードし、ヒープ表にサンプル表からデータをロードします。
SQL> exec dbms_inmemory.populate(USER,'S_ET');

PL/SQL procedure successfully completed.

SQL> exec dbms_inmemory.populate(USER,'SUPPLIER');

PL/SQL procedure successfully completed.

SQL> select SEGMENT_NAME,INMEMORY_SIZE,BYTES_NOT_POPULATED,POPULATE_STATUS,IS_EXTERNAL
   from v$im_segments;

SEGMENT_NAME INMEMORY_SIZE BYTES_NOT_POPULATED POPULATE_STAT IS_EX
------------ ------------- ------------------- ------------- -----
SUPPLIER           2359296                   0 COMPLETED     FALSE
S_ET               2228224                   0 COMPLETED     TRUE     
In-Memory外部表をクエリする前に、表が完全にロードされていることを確認するため、v$im_segmentsのbytes_not_populatedおよびpopulate_status列をチェックする必要があります。

Notes

  • 現在サポートされている外部表ドライバは、ORACLE_LOADERおよびORACLE_DATAPUMPです。
  • 外部表のインメモリコンテンツを更新するために、DBMS_INMEMORY.(re)populateを明示的に起動する必要があります。
  • 外部表のインメモリコンテンツの移入はシリアル（直列）です。
  • In-Memory外部表のシリアルスキャンのみがサポートされています。 Parallel Queryはまだサポートされていません。
    • インメモリースキャンが外部表に対するスキャンよりもはるかに高速であるため、重大なパフォーマンスの障害になることはまずありません。
  • INMEMORY句のMEMCOMPRESS副句だけがサポートされています。PRIORITY、DISTRIBUTEおよびDUPLICATEの副句はまだサポートされていません。
  • パーティション化されていない外部表のみがサポートされています。パーティションまたはパーティション化された外部表の最上位レベルでINMEMORYを指定すると、エラーが発生します。
- 0 件のコメント:
カテゴリ

[WLS, Docker, Kubernetes] WebLogic Dynamic Clusters on Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/weblogic-dynamic-clusters-on-kubernetes

Overview

WebLogic Serverクラスタは、複数の管理対象サーバ・インスタンスで構成され、スケーラビリティと信頼性を向上させるために同時に実行し、連携して動作します。WebLogic Serverは構成済みと動的クラスタの2種類のクラスタ構成をサポートします。構成済みクラスタは手作業で各管理対象サーバインスタンスを構成して作成します。動的クラスタの場合、管理対象サーバ構成を単一の共有テンプレートから生成します。テンプレートを利用することで、管理対象サーバのクラスタ構成を大幅に簡素化し、動的にサーバをマシンリソースに割り当てることができるため、最小限の構成でリソースを最大限に活用できます。動的クラスタでは、追加サーバの容量が必要な場合、新規サーバインスタンスをクラスタに追加できます。個々に管理対象サーバを手作業で構成する必要はありません。また、構成済みクラスタとは異なり、動的クラスタのスケールアップはクラスタ向けに定義済みの一連のサーバに制限されませんが、ランタイムの要求に基づいて増やすことができます。
WebLogic Serverで動的クラスタの作成、構成、利用方法は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Administering Clusters for Oracle WebLogic Server 12c (12.2.1.3.0)
Dynamic Clusters
http://docs.oracle.com/middleware/12213/wls/CLUST/dynamic_clusters.htm
Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.2.1.3.0)
動的クラスタ
https://docs.oracle.com/cd/E92951_01/wls/CLUST/dynamic_clusters.htm

Support for Dynamic Clusters by Oracle WebLogic Server Kubernetes Operator

以前は、WebLogic Server Kubernetes Operatorは構成済みクラスタのみをサポートしていました。つまりOperatorは、構成済みクラスタに対して定義された管理対象サーバのみを管理、拡張できましたが、その制限はとうとう削除されました。Operatorは、動的クラスタをサポートすることで、最初に手作業で設定するのではなく、サーバテンプレートに基づいて管理対象サーバ・インスタンスの数を容易に調整できます。

Creating a Dynamic Cluster in a WebLogic Domain in Kubernetes

WebLogic Serverチームは、KubernetesでのWebLogic Serverの統合、Kubernetes上でのWebLogic Serverの動作保証に積極的に取り組んでいます。
WebLogic Server Certification on Kubernetes
https://blogs.oracle.com/weblogicserver/weblogic-server-certification-on-kubernetes
https://orablogs-jp.blogspot.jp/2018/01/weblogic-server-certification-on.html
Oracle WebLogic Server Kubernetes Operatorは、任意の数のWebLogicドメインの作成と管理、ドメイン起動の自動化、WebLogicクラスタのスケール、WebLogicクラスタにデプロイされたWebアプリケーションの負荷分散の管理、Elasticsearch、Logstash、およびKibanaとの統合を提供します。Operatorは現在、オープンソースプロジェクトとしてご利用いただけるようになっています。
Oracle Weblogic Server Kubernetes Operator
https://oracle.github.io/weblogic-kubernetes-operator/
WebLogicドメインを作成する場合、推奨方法は提供されるスクリプト（weblogic-domain.sh）を使い、Kuberenetesクラスタ内でWebLogicドメインの作成を自動化することです。
create-weblogic-domain.sh
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/create-weblogic-domain.sh
このスクリプトはcreate-weblogic-domain-inputs.yamlという入力ファイルを取ります。このファイルはWebLogicドメインの構成プロパティを指定するものです。
create-weblogic-domain-inputs.yaml
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/create-weblogic-domain-inputs.yaml
入力ファイルの以下のパラメータを使って動的クラスタを作成します。

initialManagedServerReplicas
ParameterDefinitionDefault
clusterNameドメインで生成するWebLogicクラスタインスタンスの名前cluster-1
clusterTypeWebLogicクラスタのタイプ（CONFIGUREDもしくは DYNAMIC）CONFIGURED
configuredManagedServerCountドメインに生成する管理対象サーバインスタンスの個数2
initialManagedServerReplicasドメインで最初に起動する管理対象サーバの個数2
managedServerNameBase管理対象サーバ名を生成するために使う基礎文字列。動的クラスタのサーバテンプレートでサーバ名の接頭辞として利用。managed-server

以下の構成例では、cluster-1という名前の動的クラスタを作成します。このクラスタには定義済みの管理対象サーバ4個（managed-server1 … managed-server4）があり、最初2個の管理対象サーバ（managed-server1と managed-server2）が立ち上がります。
# Type of WebLogic Cluster

# Legal values are "CONFIGURED" or "DYNAMIC"
clusterType: DYNAMIC

# Cluster name
clusterName: cluster-1

# Number of Managed Servers to generate for the domain
configuredManagedServerCount: 4

# Number of Managed Servers to initially start for the domain
initialManagedServerReplicas: 2

# Base string used to generate Managed Server names
managedServerNameBase: managed-server
WebLogicドメインを作成するには、入力ファイルと生成された構成ファイルを格納するための出力ディレクトリを指定して、create-weblogic-domain.shスクリプトを実行します。
create-weblogic-domain.sh
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/create-weblogic-domain.sh
#> create-weblogic-domain.sh  –i create-domain-job-inputs.yaml  -o /path/to/weblogic-domain-output-directory
ドメイン作成スクリプトを使ってWebLogicクラスタを作成する場合、いくつかの制限があります。
  • スクリプトは指定の個数の管理対象サーバインスタンスを作成し、全てを1個のクラスタに配置する
  • スクリプトは常に1個のクラスタを作成する
代替策として、以下のURLに概要を記載しているように、WebLogicドメインを手作業で作成できます。
Manually creating a WebLogic domain
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/manually-creating-domain.md

How WebLogic Kubernetes Operator Manages a Dynamic Cluster

Kubernetes Operatorは、Kubernetes APIを拡張して複雑なアプリケーションのインスタンスを作成、構成、管理するためのアプリケーション固有のコントローラです。Operatorsの詳細情報は、以下のエントリをご覧ください。
Introducing Operators: Putting Operational Knowledge into Software
https://coreos.com/blog/introducing-operators.html
Oracle WebLogic Server Kubernetes OperatorはKubernetesを拡張し、Kubernetes環境で動作する任意の個数のWebLogicドメインを作成、構成、管理します。ドメイン作成、ドメイン起動の自動化、構成済みクラスタならびに動的クラスタのいずれもスケールできる機能を有します。WebLogic Server Kubernetes Operatorの詳細は、以下のエントリをご覧ください。
Announcing the Oracle WebLogic Server Kubernetes Operator
https://blogs.oracle.com/weblogicserver/announcing-the-new-weblogic-server-kubernetes-operator
https://orablogs-jp.blogspot.jp/2018/03/announcing-oracle-weblogic-server.html
WebLogic Server Kubernetes Operatorは、Kubernetesクラスタ内の管理対象サーバのライフサイクルを管理するため、WebLogic動的クラスタを起動およびスケールアップ（アップまたはダウン）する機能を提供します。 WebLogic Server Kubernetes Operatorは、カスタムリソースドメイン（Custom Resource Domain、CRD）で定義された設定に基づいて、WebLogicドメインの起動を管理します。

動的クラスタの場合、Kubernetesクラスタで実行されているWLS Pod/管理対象サーバインスタンスの数は、次のドメインカスタムリソースYAMLファイルのClusterStartupエントリの 'replicas'という属性値で表されます。
clusterStartup:
  - desiredState: "RUNNING"
    clusterName: "cluster-1"
    replicas: 2
    env:
    - name: JAVA_OPTIONS
      value: "-Dweblogic.StdoutDebugEnabled=false"
    - name: USER_MEM_ARGS
      value: "-Xms64m -Xmx256m"
上記の例では、WebLogic Server Kubernetes OperatorはWebLogicドメイン起動中に2個のPod/管理対象サーバインスタンスをcluster-1という動的クラスタのために起動します。ドメインカスタムリソースYAMLファイルの詳細は以下のURLをご覧ください。
Starting a WebLogic domain
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/starting-domain.md

Scaling of WebLogic Dynamic Clusters on Kubernetes

WebLogic Server Kubernetes Operatorを使ってスケールを開始するにはいくつかの方法があります。具体的には以下のようなものです。
  1. オンデマンドでCustom Resource Domain仕様を直接更新する（kubectlの利用）
  2. cURLなどを使い、WebLogic Server Kubernetes OperatorのREST APIを呼び出す
  3. WLDFポリシールールとスクリプトアクションを使って、WebLogic Kubernetes OperatorのREST API呼び出す
  4. Prometheusアラートアクションを使ってWebLogic Server Kubernetes OperatorのREST APIを呼び出す

    1) On-Demand, Updating the Custom Resource Domain Directly

    動的クラスタのスケールはCustom Resource Domainファイルを直接編集することで実現できます。具体的にはkubectl editコマンドを使って属性replicasの値を変更することで対応します。
    #> kubectl edit domain domain1 -n [namespace]
    このコマンドで定義済みのCustom Resource Domain仕様の編集が可能なエディタを開きます。コミットしたら、WebLogic Server Kubernetes Operatorは変更を検知して、実行中のPod/管理対象サーバインスタンスの数をreplicasの値と照合し、即座に対応する動的クラスタをスケールしようと試みます。

    Calling the Operator's REST Scale API

    WebLogic Server Kubernetes Operatorは、次のURL形式のRESTエンドポイントを公開しており、承認されたアクタがWebLogicクラスタのスケーリングを要求できます。
    http(s)://${OPERATOR_ENDPOINT}/operator/<version>/domains/<domainUID>/clusters/<clusterName>/scale
    • <version> : RESTリソースのバージョン
    • <domainUID> : 特定のドメインを示すために利用するユニークなID。Kubernetesクラスタ内の全ドメインにわたり一意である必要がある。
    • <clusterName> : スケールしたいWebLogicクラスタインスタンスの名前
    例えば以下のようなURLです。
    http(s)://${OPERATOR_ENDPOINT}/operator/v1/domains/domain1/clusters/cluster-1/scale
    /scaleというRESTエンドポイントでは、
    • HTTP POSTリクエストを受け付ける
    • リクエスト本体ではJSON（application/json）メディアタイプをサポートする
    • リクエスト本体はmanagedServerCountというシンプルな名前と値を持つ
    {
      ”managedServerCount": 3
}
    managedServerCountで、スケール後のWebLogic Serverインスタンスの個数を指示します。

    Note: cURLコマンドを使ったREST APIの利用例は、以下のシェルスクリプトにあります。
    scalingAction.sh
    https://github.com/oracle/weblogic-kubernetes-operator/blob/master/src/scripts/scaling/scalingAction.sh

    Using a WLDF Policy Rule and Script Action to Call the Operator's REST Scale API

    WebLogic診断フレームワーク（WLDF）が提供するリソースメトリックに基づいて、Podの数を増やしたり減らしたりして、WebLogic Serverの動的クラスタを自動的に拡大/縮小できます。WLDFは、サーバーとアプリケーションのパフォーマンスを可視化するメトリックを収集し表出する一連のサービスとAPIです。WLDFでは、動的クラスタの自動スケーリングをサポートするPoliciesとActionsというコンポーネントを提供します。WLDFでは2種類のスケーリングをサポートしています。
    • カレンダーベースのスケール：特定の日時に実行される動的クラスターに対するスケール操作。
    • ポリシーベースのスケール：需要の変化に応じて実行される動的クラスタのスケール操作。
    このエントリでは、ルールを満たす際に構成済みアクションを自動的に実行するためのポリシー式を記述できるポリシーベースのスケーリングに焦点を当てます。これらのポリシーは、メモリ、アイドルなスレッド、CPU負荷など、1つ以上のWebLogic Serverメトリックを監視します。ポリシー内に設定したしきい値を超えると、ポリシーが呼び出され、対応するスケールアクションを実行します。

    Example Policy Expression Rule
    以下は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.jp/2018/01/automatic-scaling-of-weblogic-clusters.html
    wls:ClusterGenericMetricRule("cluster-1","com.bea:Type=WebAppComponentRuntime,ApplicationRuntime=OpenSessionApp,*","OpenSessionsCurrentCount","&gt;=",0.01,5,"1 seconds","10 seconds")
    この ‘ClusterGenericMetricRule’ というスマートルールは、Server Runtime MBean Serverから公開されているJMXメトリックのトレンドを監察するために利用され、以下のように読むことができます。

    ‘cluster-1’というクラスタについては、WLDFがアプリケーション（OpenSessionApp）のMBean（WebAppComponentRuntime）の属性（OpenSessionsCurrentCount）を監視します。OpenSessionsCurrentCountがクラスタ内のサーバの5％で0.01以上である場合、ポリシーをTrueとして評価します。1秒のサンプリングレートでメトリックを収集し、指定された10秒間の保持タイムウィンドウでサンプルデータを平均化します。

    以下のツールのいずれかを使って、診断システムモジュール用のポリシーを構成できます。
    • WebLogic Server管理コンソール
    • WLST
    • REST
    • JMXアプリケーション
    以下はポリシー構成例です。myScaleUpPolicyというポリシーをWebLogic Server管理コンソールで表示しています。
    Example Action
    アクションはポリシー式がTrueと評価された場合に実行されるオペレーションです。WLDFは以下の種類の診断アクションをサポートしています。
    • Java Management Extensions (JMX)
    • Java Message Service (JMS)
    • Simple Network Management Protocol (SNMP)
    • Simple Mail Transfer Protocol (SMTP)
    • 診断イメージのキャプチャ
    • Elasticityフレームワーク
    • REST
    • WebLogicロギングシステム
    • スクリプト
    WebLogic Serverチームでは、scalingAction.shというサンプルのシェルスクリプトをScript Action用に用意しています。これでOperatorのRESTエンドポイントにリクエストを発行するしくみを説明しています。
    scalingAction.sh
    https://github.com/oracle/weblogic-kubernetes-operator/blob/master/src/scripts/scaling/scalingAction.sh
    以下はWebLogic Server管理コンソールのScript Action構成ページのスクリーンショットです。


    Script Actionの構成プロパティで重要な点を纏めておきます。
    • ScriptへのPathと作業ディレクトリの構成エントリは、WebLogicドメインホームへアクセスするためのボリュームマウントパス（/shared）を指定します。
    • scalingAction.shスクリプトはOperatorエンドポイントのSSL証明書にアクセスできる必要があり、これは環境変数INTERNAL_OPERATOR_CERTで情報が提供されます。OperatorのSSL証明書は、OperatorのConfigMap weblogic-operator-cmのinternalOperatorCertというエントリにあります。以下はその例です。
    #> kubectl describe configmap weblogic-operator-cm -n weblogic-operator

Name:         weblogic-operator-cm
Namespace:    weblogic-operator
Labels:       weblogic.operatorName=weblogic-operator
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","data":{"externalOperatorCert":"","internalOperatorCert":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...

Data
====
internalOperatorCert:
----
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR3akNDQXFxZ0F3SUJBZ0lFRzhYT1N6QU...
    • scalingAction.shスクリプトでは、数多くのカスタマイズ可能なパラメータを許容しています。
      • action - scaleUp もしくは scaleDown （必須）
      • domain_uid - WebLogicドメインの一意の識別子（必須）
      • cluster_name - WebLogicクラスタ名（必須）
      • kubernetes_master - KubernetesマスタのURL。デフォルトはhttps://kubernetes
      • access_token - RESTリソースへアクセスするための認証認可のService Account Bearerトークン
      • wls_domain_namespace - WebLogicドメインを定義したKubernetes名前空間。デフォルトはdefault
      • operator_service_name - RESTエンドポイントのWebLogic Operator Service名。デフォルトはinternal-weblogic-operator-service
      • operator_service_account - WebLogic OperatorのKubernetes Service Account名。デフォルトはweblogic-operator
      • operator_namespace – WebLogic Operatorをデプロイした名前空間。デフォルトはweblogic-operator
      • scaling_size – スケールアップ、ダウンによって増分するWebLogic Serverインスタンスの個数、デフォルトは1
    WLDFおよび診断ポリシーおよびアクションに関する詳細は、以下のドキュメントをご覧ください。
    Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用 12c (12.2.1.3.0)
    ポリシーとアクションの構成
    https://docs.oracle.com/cd/E92951_01/wls/WLDFC/config_watch_notif.htm
    Oracle® Fusion Middleware
    Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
    Configuring Policies and Actions
    http://docs.oracle.com/middleware/1221/wls/WLDFC/config_watch_notif.htm#WLDFC188
    Note: WLDFを使った自動スケールの詳細は以下のエントリで説明しています。
    WebLogic on Kubernetes, Try It!
    https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes,-try-it
    https://orablogs-jp.blogspot.jp/2017/10/weblogic-on-kubernetes-try-it.html
    Automatic Scaling of WebLogic Clusters on Kubernetes
    https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
    https://orablogs-jp.blogspot.jp/2018/01/automatic-scaling-of-weblogic-clusters.html
    WebLogicクラスタの自動スケールについて、このエントリで紹介している方法と、以下の以前のエントリで紹介した方法にはいくつか重要な違いがあります。
    Automatic Scaling of WebLogic Clusters on Kubernetes
    https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
    https://orablogs-jp.blogspot.jp/2018/01/automatic-scaling-of-weblogic-clusters.html
    • 以前のエントリでは、早期リリースだったので、構成済みクラスタのスケールのみをサポートしていました。
    • このエントリでは以下の違いがあります。
      • 動的クラスタをスケールするには、Webhookを使用する代わりにWebLogic Server Kubernetes Operatorを使用します。
      • 動的クラスタをスケールするには、RESTアクションではなくScript Actionを使用します。
      • Podをスケールするには、スケーリング・アクションが、Kubernetes APIサーバではなくOperatorのRESTエンドポイントに対するリクエストを呼び出します。

    Using a Prometheus Alert Action to Call the Operator's REST Scale API

    In addition to using the WebLogic Diagnostic Frameworkを利用するのに加えて、動的クラスタの自動スケールのために、Prometheusのような3rdパーティの監視アプリケーションを使うことができます。詳細は以下のエントリをご一読ください。
    Using Prometheus to Automatically Scale WebLogic Clusters on Kubernetes
    https://blogs.oracle.com/weblogicserver/using-prometheus-to-automatically-scale-weblogic-clusters-on-kubernetes-v5
    https://orablogs-jp.blogspot.jp/2018/04/using-prometheus-to-automatically-scale.html

    What Does the Operator Do in Response to a REST Scaling Request?

    WebLogic Server Kubernetes OperatorがスケールのリクエストをスケールRESTエンドポイントを通じて受け取ると、以下のアクションを実行します。
    • 指定されたユーザーが指定されたリソースに対して指定された操作を実行することを許可されていることを確認するために、認証および許可チェックを実行します。
    • domainUIDで識別される指定されたドメインが存在することを検証します。domainUIDは、この特定のドメインを識別するために使用される一意のIDです。このIDは、Kubernetesクラスタ内のすべてのドメインで一意でなければなりません。
    • clusterNameによって識別されるWebLogicクラスタが存在することを検証します。clusterNameは、スケーリング対象のWebLogicクラスタインスタンスの名前です。
    • スケール・リクエストの 'managedServerCount'値が、指定されたWebLogicクラスタの構成された最大クラスタサイズを超えないことを確認します。 動的クラスタの場合、'MaxDynamicClusterSize'は、スケールアップ操作で許可されている実行中の管理対象サーバ・インスタンスの最大数を指定するWebLogic属性です。 動的クラスタの構成に使用される属性の詳細は、以下のドキュメントをご覧ください。
      Oracle® Fusion Middleware Oracle WebLogic Server動的クラスタの拡張度の構成 12c (12.2.1.3.0)
      動的クラスタの構成
      https://docs.oracle.com/cd/E92951_01/wls/ELAST/requirements.htm#GUID-58D37E45-38A1-4EBF-BBD9-1BFE88F9C35E
      Oracle® Fusion Middleware
      Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1)
      Configuring Dynamic Clusters
      https://docs.oracle.com/middleware/1221/wls/ELAST/requirements.htm#ELAST530
    • 対応するDomain Custom Resource内のReplicasプロパティを設定してスケールを開始します。これは以下のいずれかの方法で実行できます。
      • 特定のWebLogicクラスタに対してclusterStartupエントリを定義している場合
        • （例）
        Spec:
  …
  Cluster Startup:
    Cluster Name:   cluster-1
    Desired State:  RUNNING
    Env:
      Name:     JAVA_OPTIONS
      Value:    -Dweblogic.StdoutDebugEnabled=false
      Name:     USER_MEM_ARGS
      Value:    -Xms64m -Xmx256m
    Replicas:   2
   …
    • ドメインレベルで、clusterStartupエントリを特定のWebLogicクラスタ向けに設定していない場合や、startupControlプロパティをAUTOに設定している場合
      （例）
      • Spec:
  Domain Name:  base_domain
  Domain UID:   domain1
  Export T 3 Channels:
  Image:              store/oracle/weblogic:12.2.1.3
  Image Pull Policy:  IfNotPresent
  Replicas:           2
  Server Startup:
    Desired State:  RUNNING
    Env:
      Name:         JAVA_OPTIONS
      Value:        -Dweblogic.StdoutDebugEnabled=false
      Name:         USER_MEM_ARGS
      Value:        -Xms64m -Xmx256m
    Server Name:    admin-server
  Startup Control:  AUTO
    Note: 以下のコマンドを使って、WebLogic Kubernetesドメインリソースの完全な情報を閲覧できます。
    #> kubectl describe domain <domain resource name>
    • Custom Resource DomainのReplicaプロパティへの変更に対応し、OperatorはPod（管理対象サーバ）の個数を増減して所望のレプリカ個数に一致するよう調整します。

    Wrap Up

    WebLogic Serverチームは、Kubernetes環境でWebLogic Serverを統合するため、Kubernetes Operatorパターンに基づいて、Oracle WebLogic Server Kubernetes Operatorを開発しました。このOracle WebLogic Server Kubernetes Operatorを使って、WebLogicドメインのライフサイクル管理、具体的には、動的クラスタを拡張します。WebLogic Diagnostic Framework（WLDF、WebLogic診断フレームワーク）またはPrometheusなどのサードパーティの監視アプリケーションを使用して、オンデマンドまたは自動でWebLogicの動的クラスタのスケールが可能です。まとめると、Kubernetesクラスタ上で構成済みクラスタに比べてWebLogic動的クラスタを使用する利点は次のとおりです。
    • 単一のサーバテンプレートを使って管理対象サーバを構成できる
    • サーバ容量の追加が必要な場合、個々に手作業で構成せずに新たなサーバインスタンスをクラスタに追加できる
    • 構成済みクラスタとは異なり、動的クラスタのスケールアップはクラスタで定義済みのサーバ・セットに限定されず、ランタイムの要求に基づいて増加することが可能
    Oracle WebLogic Server Kubernetes Operatorをダウンロードして、動的クラスタの自動スケーリング機能をお試しになることをお勧めします。Oracle WebLogic Server Kubernetes Operatorを拡張するために追加される予定機能に関するエントリはしばらくお待ちください。
    Oracle Weblogic Server Kubernetes Operator
    https://github.com/oracle/weblogic-kubernetes-operator
    - 0 件のコメント:
    カテゴリ , ,

    [misc.] Oracle製品ドキュメントページにSolutionsというカテゴリが追加されています

    Oracle製品ドキュメントのトップページが少々変更されていることをご存知でしょうか。
    下図の通り、Solutionsというグループが出来ています。

    これをクリックすると、Design、Develop、Integrate、Operateというカテゴリに細分化され、各製品を使った構成例を確認できます。

    Designをクリックしてみたところ、SaaSアプリケーションとの連携や、オンプレミスのERP（E-Business Suite）との連携をどのように実現するか、といった内容が紹介されています。


    まだ数少ないですが、今後いろいろな内容が追加されていきますので、ご興味ある方は時間のあるときにチェックしてみてください。


    - 0 件のコメント:
    カテゴリ

    [Cloud] Visual Builder Architecture - A Crash Course in Building Blocks

    原文はこちら。
    https://blogs.oracle.com/vbcs/visual-builder-architecture-a-crash-course-in-building-blocks
    VBCSのビジュアル開発体験によって、アプリケーション作成が簡単になりますが、ビジュアル開発の基礎部分が堅牢なアーキテクチャであることを理解するのは重要です。

    このアーキテクチャとVBCSが利用するビルディングブロックの基本的な理解は、VBCSでアプリケーションを開発しようとしている人にとっては良い基礎になります。

    アーキテクチャやビルディングブロックの詳細はドキュメントの以下の章でご覧いただけます。
    Oracle® Cloud Developing Applications with Oracle Visual Builder Cloud Service
    Understanding the Building Blocks of Visual Applications
    https://docs.oracle.com/en/cloud/paas/app-builder-cloud/visual-builder-developer/understanding-building-blocks-visual-applications1.html
    Building Blocks of VBCS

    YouTubeチャンネルにUpした30分の動画で、ビルディングブロックの説明と利用方法の例をご紹介します。



    この動画をご覧になれば、クイックスタートでは即座に答えが得られない、より高度なシナリオに対処することが容易になるはずです。しかし、アーキテクチャとビルディングブロックの別の側面について詳細を知っていただくために、ドキュメントを一読されることをお勧めします。

    この手の動画がお役にたつかどうかお知らせください。
    - 0 件のコメント:
    カテゴリ

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

    原文はこちら。
    https://blogs.oracle.com/vbcs/learning-app-development-with-visual-builder-cloud-service-demos-tutorials
    新しくなったOracle Visual Builder Cloud Serviceを使ってアプリケーションを開発するにはどうすればいいか知りたくありませんか？

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

    Developing a Web Application in 10 Minutes


    Developing an On-Device Mobile Application in 10 Minutes


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


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

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

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

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

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

    Visual and Code Based Development Combined

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


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



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



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

    Mobile and Web Development Unified

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

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

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


    Standard-Based Data Openness

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



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

    Visual Builder Cloud Service Goes Autonomous

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

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

    One click install

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

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

    But Wait There is More

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

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

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

    [Database, Cloud] Announcing Oracle SQL Developer Web!

    原文はこちら。
    https://www.thatjeffsmith.com/archive/2018/05/announcing-oracle-sql-developer-web/
    Oracle CloudでOracle SQL Developer Webがご利用いただけるようになりました！
    「でも、それって何？」というあなたに。
    これはブラウザベースのOracle SQL Developerで、Oracle REST Data Servicesを使っています。
    Oracle Database Cloudをお使いのお客様であれば、順次ロールアウトしているところです。

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

    - 0 件のコメント:
    カテゴリ ,

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

    原文はこちら。
    https://blogs.oracle.com/weblogicserver/announcing-general-availability-version-of-the-weblogic-server-kubernetes-operator
    WebLogic Server Kubernetes Operator（以下Operator）の一般提供（GA）リリースの発表ができうれしく思っています。OperatorはTechnology Previewとして2月にリリースしたもので、Kubernetes環境でWebLogic Server 12.2.1.3ドメインの作成、管理を簡単にするものです。このGA版では、Technology Previewの機能に加え、その他のWebLogic Serverの機能もサポートしており、開発、本番用途でご利用いただけるように動作保証ならびにサポートいたします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Q: What’s happening with Java SE 8? （Java SE 8はどうなるの？）

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

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

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

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

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

    ［脚注］

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

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

    原文はこちら。
    https://blogs.oracle.com/developers/kubecon-europe-2018-oracle-open-serverless-standards-fn-project-and-kubernetes
    オープンなserverlessプロジェクトであるFnは、CNCF CloudEvents、Serverless Frameworkのサポート、トレースとメトリックのためのOpenCensusといった、広範なサーバレス標準化のサポートを追加しています。
    Oracle Container Engine for KubernetesはK8sユーザーが今日直面している最も困難な現実世界のガバナンス、スケール、管理といった課題に取り組んでいます。

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

    Solving Real World Kubernetes Challenges

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

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

    出典: The New Stack

    Addressing Real-World Kubernetes Challenges

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

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

    Fn Project

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

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