[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 件のコメント:
カテゴリ , ,

[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.shｗアプリケーション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クラスタのスケールの決定を簡単に構成できることもご紹介いたしました。
- 0 件のコメント:
カテゴリ , ,

[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のためにこれらのテクノロジーを進化させていきたいと考えています。
- 0 件のコメント:
カテゴリ

[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/
- 0 件のコメント:
カテゴリ
登録: 投稿 (Atom)