[Linux] Announcing the general availability of the Unbreakable Enterprise Kernel Release 5

原文はこちら。
https://blogs.oracle.com/linux/announcing-the-general-availability-of-the-unbreakable-enterprise-kernel-release-5

Unbreakable Enterprise Kernel Release 5 (UEK R5)は入念にテストされた、Oracle Linux 7 Update 5およびそれ以後の64bit Intel(x86_64)ならびにARMアーキテクチャ(aarch64)に最適化されたOSカーネルです。メインラインLinuxカーネルバージョン4.14 LTSベースで、このリリースにはドライバのアップデート、バグ修正、セキュリティ修正が含まれています。

Introduction of 64-bit ARM (aarch64) architecture

Oracle LinuxをUEK R5と共に使うと、64ビットARM(aarch64)アーキテクチャをサポートします。この変更は、既存のARMハードウェアで構築、テストされ、ARM用Oracle Linuxをサポートするための最初の土台を提供します。UEK R5で使用可能なARM機能はテクニカル・プレビューとしてリリースされ、機能上の制限があります。

Oracle Linux 7 for ARMには、gccコンパイラのバージョン7.3を含むツールチェーンが含まれており、64ビットARMプラットフォーム用のコードを構築するためのしっかりした開発者ツールセットが用意されています。 ARMプラットフォーム用のUEK R5は、このツールチェーンを使用してビルドされています。

Notable Changes

  • セキュア・ブートの改善
    セキュア・ブートは、ブートプロセスの初期段階で悪質なコードがロードされて実行されるのを防ぐよう設計されています。保護されたプラットフォームは、オプションのROMドライバ、ブートローダ、OSローダなど、変更されずにプラットフォームが信頼しているソフトウェアバイナリのみをロードします。OSロード中、後続のブートで悪質なコードが注入されないよう、対策が追加されました。
  • NUMAバランシングの有効化
    NUMAバランシングの改善と修正の結果、この機能を有効化したときにI/O待機時間が長くなる可能性のある問題が解決されました。複数のNUMAノードを持つシステムでは、NUMAバランシングが自動的に有効になります。
  • RoCE (RDMA over Converged Ethernet) のサポート
    標準のInfiniBand Trade Association(IBTA)プロトコルであるRDMA over Converged Ethernet(RoCE)プロトコルは、レイヤ3ネットワークを越えるためにUDPカプセル化を使用してイーサネットネットワーク上でRDMAの効率的なデータ転送を可能にします。
  • TCP-BBRの有効化
    TCP-BBRは、インターネットトラフィックで高い帯域幅と低い待ち時間を達成するために利用可能な機能で、インターネットベースのアプリケーションのパフォーマンスが大幅に向上します。 BBR(Bottleneck Bandwidth and Round-Trip Time、ボトルネック帯域幅とラウンドトリップ時間)とは、スケジューリングアルゴリズムであり、これを使うと、TCP輻輳を低減するために帯域幅ボトルネックに対する往復時間を監視することにより、TCPプロトコルの送信レートを制御して、バッファリングを削減できます。

Notable Driver Updates

  • Hyper-Vドライバのアップデート
    Hyper-Vストレージドライバ(hv_storvsc)が更新されました。バウンスバッファが削除されたことで、特定のワークロードに対するI/O操作のパフォーマンスが向上しています。Hyper-Vネットワークドライバ(hv_netvsc)がアップデートされ、仮想機能デバイスでの透過的なSR-IOVをサポートするようになりました。これにより、構成の複雑さと、PCIデバイスのホットプラグを処理するための専用のボンディングドライバとスクリプトを利用する必要がなくなりました。
  • Intel iWARP RDMAドライバの追加
    Intel Ethernet Connection X722 iWARP RDMA Driver (i40iw)がこのカーネルリリースのドライバモジュールに追加されました。このRDMAハードウェアを直接ユーザー空間で使用するためのライブラリ(libi40iw)が追加されました。
  • Amazon Elastic Networkアダプタドライバのアップデート
    Elastic Network Adapter Driver(ena)がver 15.0kにアップデートされました。このバージョンには、多数のアップストリームのバグ修正や機能改善が含まれています。その他、追加の電源管理オペレーションやIPv6RSSの初期サポート、ドライバの堅牢性の向上などが含まれています。
これらの機能やその他の新機能、変更点の詳細(このリリースで修正されたCVEのリストを含みます)は、以下のリリースノートをご覧ください。
Oracle Linux Unbreakable Enterprise Kernel Release 5 Release Notes
https://docs.oracle.com/cd/E93554_01/index.html

Certification of Oracle products

Oracle LinuxシステムでUEK R5を使うようアップデートする前に、Oracleのアプリケーションを含む、ご利用中のアプリケーションがUEK R5をサポートしていることを確認してください。Oracle製品のOracle Linux + UEK R5上での動作保証は各Oracle製品グループが決定します。追加情報は以下のリンクからご覧ください。
My Oracle Support:動作保証のページ
https://support.oracle.com/epmos/faces/CertifyHome
Oracle Automatic Storage Management Cluster File System (Oracle ACFS) の種々のカーネルバージョンに対する動作保証は、My Oracle Supportのドキュメントに記載があります。
ACFS Support On OS Platforms (Certification Matrix). (ドキュメントID 1369107.1)
https://support.oracle.com/rs?type=doc&id=1369107.1

Compatibility

Oracle Linuxは、Red Hat Enterprise Linuxとのユーザー空間での互換性を維持しています。これは、OSの下で動作するカーネルのバージョンとは独立しています。ユーザー空間内の既存のアプリケーションは、引き続きUEK R5上で動作し、修正の必要はありません。RHEL認定アプリケーションの再認証は不要です。

リリース間の互換性の影響を最小限に抑えるために、Oracle Linuxチームは、ハードウェアおよびソフトウェアがカーネル・モジュールに依存するサード・パーティ・ベンダーと緊密に協力しています。UEK R5のカーネルABIは、最初のリリースから続くすべてのアップデートで変更はありませんが、今回のリリースでは、以前のリリースに対し、カーネルABIに変更が加えられています。そのため、サードパーティのカーネルモジュールをシステム上で再コンパイルする必要があります。UEK R5をインストールする前に、アプリケーションベンダーにサポート状況を確認してください。

Supported Upgrade Path

お客様はUnbreakable Linux NetworkもしくはOracle Linux yumサーバを使って、既存のOracle Linux 7サーバをアップグレードできます。
Unbreakable Linux Network
http://linux.oracle.com/
Oracle Linux Yum Server
http://yum.oracle.com/

Software Download

Oracle Linuxは無料でダウンロード、利用、配布でき、アップデートやエラータも無料でご利用いただけます。
Oracle Linux
https://www.oracle.com/linux
そのため、どのシステムでサポート・サブスクリプションが必要かを決定できますし、それゆえにOracle Linuxが開発、テスト、本番システム用に理想的な選択肢になる理由なのです。
Oracle Linux Support
http://www.oracle.com/us/technologies/linux/support/overview/index.html
各システムに対してどのサポート範囲が最適かを個別に決めることも、全システムを最新かつセキュアに保つことも可能です。Oracle Linux Premier Supportのお客様であれば、ダウンタイム無しでカーネルをアップデートする機能(Oracle Ksplice)も使えますし、Oracle OpenStackのサポートもご利用いただけます。
KSplice: Zero downtime updates for Oracle Linux
http://www.oracle.com/us/technologies/linux/ksplice-datasheet-487388.pdf
Oracle OpenStack
http://www.oracle.com/technetwork/server-storage/openstack/linux/documentation/datasheet-oracle-openstack-2296038.pdf

UEK R5 Availability in Oracle Cloud Infrastructure

Oracle Cloud Infrastructure (OCI) でご利用いただけるOracle Linuxイメージは、最新のソフトウェアにアクセスできるよう頻繁にアップデートされています。OCIでOracleが提供するイメージにまもなくOracle Linux 7 Update 5 + UEK Release 5が含まれる予定です。
Displaying: All Oracle Linux 7.x Images
https://docs.us-phoenix-1.oraclecloud.com/images/oel-7x/ 
Oracle Linux Premier SupportはOracle Cloud Infrastructureサブスクリプションに含まれており、追加費用は不要です。最新のパッケージやアップデートへのアクセス、24x7のサポート、豊富なLinuxナレッジベースを備えたMy Oracle Supportポータル、Oracle Ksplice zero-downtimeアップデート、Oracle Enterprise Managerを使ったOracle Linuxインスタンスの監視といった、Oracle Linux Supportが提供するあらゆる便益を活用できます。
My Oracle Support
https://support.oracle.com/ 
 Using Oracle Linux on Oracle Cloud InfrastructureでOracle Linuxを使うことで、クラウドインフラストラクチャ、OS、そしてOracleソフトウェア全体に対するサポートの一元化が可能です。

Resources – Oracle Linux

Documentation
Software Download
Blogs
Community Pages
Social Media
Data Sheets, White Papers, Videos, Training, Support & more
Product Training and Education

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

今朝、OracleはOracle Java SE Subscriptionの導入を発表しました。
Oracle Introduces New Java SE Subscription Offering for Broader Enterprise Java Support
https://www.oracle.com/corporate/pressrelease/java-se-subscription-offering-062118.html
簡単に言えば、あたかもLinuxのアップデートとサポートをディストリビュータから購入するのと同じように、Oracleからのサポートを含めて、Java SEのアップデートへのアクセスを購入できます。低価格かつシンプルな価格体系です。オンラインでサブスクライブできるよう現在作業中です。

この新たなオファリングは、開発者がOracleからJava SEを入手して利用する方法を変えるものではありません。昨年の発表通り、OracleはOpenJDKビルドをGPL+CPE(Classpath Exception)ライセンスに基づいて提供しており、2018年9月のJava SE 11のローンチ時に、Oracle JDKと機能上の互換性をもたせる予定にしています。
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.com/2017/09/faster-and-easier-use-and.html
今後、Oracle JDKとOracleによるOpenJDKビルドが同等になると、ほとんどの開発者や企業組織の方々はOpenJDKやOracle JDKのビルドをお使いくださると思っております。
OpenJDK
http://jdk.java.net/
Java SE Downloads (Oracle JDK)
http://www.oracle.com/technetwork/java/javase/downloads/index.html
(OpenJDKビルドは)BCLライセンスではなく、Linuxと同じライセンスの下、Classpath例外付きのため、ご利用にあたってより柔軟性が増しています。

Java SE Subscriptionでは、Java SEの商用ライセンスとテクニカルサポート、以前のバージョン(訳注:サポート期間内のバージョンです)のアップデートへのアクセスを提供します。そのため、将来のリリースへのアップグレードをご自身のスケジュール、タイミングで決めることができます。さらに、Oracle Java SE desktop deploymentテクノロジー(簡単に言うとAppletやWeb Start)から他のソリューションに移行するためにもう1〜2年必要と考えている組織にとっては、このサブスクリプションで時間を稼ぐことになります。高価なPerpetual(永久)ライセンスを購入する必要はなく、デスクトップユーザーサブスクリプションを必要に応じて購入されればよいのです。

詳細は以下のリンクをご覧ください。
Java SE Subscription FAQ
http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html
Java SE Subscription Data Sheet
http://www.oracle.com/technetwork/java/javaseproducts/javasesubscription-data-sheet-4891969.pdf
Java SE Subscriptionのページ
https://www.oracle.com/java/java-se-subscription.html

[Cloud, Kubernetes] Developer Cloud Service May Release Adds K8S, OCI, Code Editing and More

原文はこちら
https://blogs.oracle.com/developers/developer-cloud-service-may-release-adds-k8n%2c-oci%2c-code-editing-and-more



直近のOracle Developer Cloud Serviceでパイプライン、Docker、Terraformのサポートが追加されましたが、そのちょうど1ヵ月後に、DevOpsやCI/CDプロセスを拡張するさらなるアップデートがDeveloper Cloud Serviceに追加され、追加のユースケースをサポートできるようになったことを発表でき、うれしく思っています。
Oracle Developer Cloud Service Adds Docker, Pipelines, and More
https://blogs.oracle.com/cloud-platform/oracle-developer-cloud-service-adds-docker%2C-pipelines%2C-and-more
https://orablogs-jp.blogspot.com/2018/04/oracle-developer-cloud-service-adds.html
以下で新バージョンのハイライトをご紹介します。

Extended build server software

以下の機能を活用するビルドジョブやパイプラインを作成できるようになりました。
  • Kubernetes
    kubectl コマンドを使ってDockerコンテナを管理
    kubectl
    https://kubernetes.io/docs/tasks/tools/install-kubectl/
  • OCIコマンドライン
    Oracle Computeのプロビジョニングや構成を自動化
  • Java 9(訳注:エントリ執筆時点で2018/5なので、すでにあれなのですが)
    最新のJavaプロジェクトのデプロイ
  • Oracle Development Tools
    Oracle FormsやOracle JDeveloper 12.2.3がFormsやADFアプリケーションのデプロイメント自動化に利用可能に


SSH Connection in Build

SSH接続をビルド構成に定義し、セキュアにOracle Cloudサービスに接続し、シェルスクリプトを実行できるようになりました。


In Browser Code Editing and Versioning 

新たに追加された鉛筆アイコンを使うと、Developer Cloud ServiceがホストするプライベートGitリポジトリのコードを直接ブラウザから編集できます。コードを編集すると、コミットメッセージ付きでブランチに変更を直接コミットできます。

PagerDuty Webhook

環境をオープンに保つという原則を引き続き継続し、新たのWebhookをサポートしました。これにより、イベントを人気のあるPagerDutyソリューションに送信できるようになりました。
PagerDuty
https://www.pagerduty.com/

Increased Reusability

チームのために既に機能しているものを簡単に複製することができます。例えば、エクスポートした既存のプロジェクトに基づいた新規プロジェクトの作成や、Agileボードを新しいボードへのコピーが可能になりました。便利なissue検索を作成した場合は、チーム内の他のユーザーと共有できます。

他にも多くの機能が追加されており、みなさまの日々の仕事が改善されることでしょう。詳細は、DevCSドキュメントのWhat's Newをごらんください。
What’s New in Oracle Developer Cloud Service (2018/5)
https://docs.oracle.com/en/cloud/paas/developer-cloud/csdwn/index.html#CSDWN-GUID-88FCFA5A-9EA1-4E43-BF2B-7D5B647B5A07

[Linux] Upcoming change to Oracle Linux package channels

原文はこちら。
https://blogs.oracle.com/linux/upcoming-change-to-oracle-linux-package-channels

What is changing?

6月5日に、Oracle Linux 6とOracle Linux 7のULN(Unbreakable Linux Network)とOracle LinuxのYumサーバに対して以下のような変更をする予定です(変更されました)。
Unbreakable Linux Network (ULN)
https://linux.oracle.com/
Oracle Linux yum server
https://yum.oracle.com/
現在のOracle Linuxのアップデート・レベルより前のパッケージ、例えばOracle Linux 7 Update 5やOracle Linux 6 Update 9より前のパッケージは、新規に作成されたarchiveチャネルに移動します。特定の古いバージョンのパッケージに依存していて、Chef、Puppet、Ansible、その他のカスタムスクリプトなどの設定管理ツールを使用してデプロイしている場合には、チャネルが変更されても動作することを確認するように案内してください。同様に、Spacewalk for Oracle Linuxを使っていたり、uln-yum-mirrorスクリプトに基づいてULNのローカルミラーをメンテナンスしていたりする場合は、必要に応じてULNを経由してサブスクライブすることで、archiveチャネルが含まれていることを確認してください。

New Channels

ULN、Oracle Linuxのyumサーバに以下のチャネルが作成されます。

ULN

  • ol7_x86_64_latest_archive
  • ol6_x86_64_latest_archive

Oracle Linux yum server

  • ol7_latest_archive
  • ol6_latest_archive
将来、Oracle Linux 7 Latest Optional Packages (x86_64) - ol7_x86_64_optional_latest も含めて、他のチャネルのアーカイブを作成する可能性があります。

Why are we making this change?

定期的にlatestチャネルからarchiveチャネルにパッケージをアーカイブすることで、チャネル全体のサイズだけでなく、そのメタデータファイルのサイズを大幅に削減できます。この結果、ネットワークトラフィックが削減され、ULNやOracle Linuxのyumサーバを使う場合にパフォーマンスが大幅に改善されるでしょう。

What happens when an update to Oracle Linux is released?

Oracle Linuxの新しいアップデート・リリースが利用可能になると、インストール・メディアに同梱されているパッケージのセットでlatestのチャネルが最新になり、これらの条件に合致しないすべてのパッケージがarchiveチャネルに移動されます。したがって、各Oracle Linuxリリースのlatestチャネルには、(Oracle Software Delivery CloudまたはOracle Linuxダウンロード・ミラーの1つから入手可能な)そのリリースのインストール・メディアで配布された最新リリースと、そのリリースに続くすべての更新パッケージ(および正誤表)のみが含まれます。
Oracle Software Delivery Cloud
https://edelivery.oracle.com/
Downloading Oracle Linux
https://community.oracle.com/docs/DOC-917963

[WLS, Cloud, Docker, Kubernetes] How to run WebLogic clusters on the Oracle Cloud Infrastructure Container Engine for Kubernetes

原文はこちら
https://blogs.oracle.com/weblogicserver/how-to-run-weblogic-clusters-on-the-oracle-cloud-infrastructure-container-engine-for-kubernetes

WebLogicクラスタを実行するためにKubernetes環境をセットアップするには様々な方法があります。Oracleは、本番モードもしくは開発モードのWebLogicクラスタを、オンプレミスもしくはクラウドでKubernetes上で実行したいお客様をサポートします。このエントリでは、Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetesを使用してWebLogicクラスタを実行する手順について説明します。Kubernetesマネージドサービスは、基盤となるOracle Cloud Infrastructure(OCI)と完全に統合されているため、Kubernetesクラスタを簡単にプロビジョニングし、ロードバランサ、ボリューム、ネットワークファブリックなどの必要なサービスを簡単に提供できます。
OKEPICTURE2.png

Prerequisites:

  1. Dockerイメージ:
    • WebLogic Server (weblogic-12.2.1.3:latest).
    • WebLogic Kubernetes Operator (weblogic-operator:latest)
    • Traefik Load Balancer (traefik:1.4.5)
  2. Dockerとkubectlのインストール、構成が完了しているワークステーション
  3. Oracle Container Engine for Kubernetes on OCI。OCIでKubernetesマネージドサービスをセットアップするには、以下のドキュメントに従う。
    Overview of Container Engine for Kubernetes
    https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm
  4. OCI Container Engine for KubernetesノードにSSHでアクセスできること
  5. WebLogic Server、Operator、Load BalancerイメージをプッシュするためのOracle Cloud Infrastructure Registry
    Overview of Registry
    https://docs.us-phoenix-1.oraclecloud.com/Content/Registry/Concepts/registryoverview.htm

Prepare the WebLogic Kubernetes Operator environment

環境準備のために以下を実施する必要があります。
  • OCI Container Engine for the Kubernetesクラスタへのアクセス確認ならびにRBACポリシーの設定
  • NFSサーバの構成
  • OCI Registry (OCIR) へのDockerイメージのアップロード
  • OCIRにあるDockerイメージの名前を反映するため、構成YAMLファイルを編集

Test accessibility and set up the RBAC policy for the OKE cluster

OCI Container Engine for Kubernetesノードへのアクセス確認のため、以下のコマンドを実行します。
kubectl get nodes
以下のような出力でノードが表示されるはずです。
NAME              STATUS    ROLES     AGE       VERSION
129.146.109.106   Ready     node      5h        v1.9.4
129.146.22.123    Ready     node      5h        v1.9.4
129.146.66.11     Ready     node      5h        v1.9.4
Kubernetesクラスタへのアクセス権限を有するには、OCI Container Engine for Kubernetesクラスタのcluster-adminとしてご利用のOCIアカウントを認可する必要があります。これにはOCID(OCIコンソールページのユーザー設定の下にあります)が必要です。例えば、OCIDがocid1.user.oc1..aaaaaaaac26kw7qvuij7i6fadabklqfb7svyuhpitedmguspv6ht67i5l32qの場合、コマンドは以下のようになります。
kubectl create clusterrolebinding my-cluster-admin-binding --clusterrole=cluster-admin --user=ocid1.user.oc1..aaaaaaaac26kw7qvuij7i6fadabklqfb7svyuhpitedmguspv6ht67i5l32q

Set up the NFS server

現在ご利用いただけるOCI Container Engine for Kubernetesのバージョンでは、ノード間で共有可能なアクセス権RWOnce(一人のみが書き込め、その他は読み取りのみ)のネットワークブロックストレージをサポートします。このとき、WebLogic Server Kubernetes Operatorで作成されたKubernetes上のWebLogicドメインでは、WebLogicドメインの構成を保存するために共有ファイルシステムが必要です。この共有ファイルシステムはノード全体の全てのPodからアクセスできる必要があります。回避策として、NFSサーバを一つのノードにインストールし、全ノード間でファイルシステムを共有する必要があります。

Note: WebLogic Server on OCI Container Engine for Kubernetes上でWebLogic Serverを実行する場合、NFS 3.0を使うことを現状推奨しています。動作確認の間、NFS 4.0を使うとWebLogicドメインのサーバが断続的に障害状態に陥ることがわかりました。服すのスレッドがNFS(デフォルトストア、診断ストア、Node Manager、ロギング、ドメインホーム)を使うため、ファイルストアにアクセスする際に問題があります。これらの問題はNFSのバージョンを3.0にすることで解消されます。

このデモでは、Kubernetesクラスタは以下のIPアドレスを持つノードを利用します。
Node1: 129.146.109.106  

Node2: 129.146.22.123  

Node3: 129.146.66.11
上記の場合、NFSサーバをNode 1(129.146.109.106)にインストールし、Node 2(129.146.22.123)、Node 3(129.146.22.123)をクライアントとして利用します。各ノードに対応するプライベートIPアドレスを調べるために、各ノードに以下のコマンドを使ってログインします。
ssh -i ~/.ssh/id_rsa opc@[Public IP of Node]

ip addr | grep ens3
~/.ssh/id_rsa はSSHで利用するRSA秘密鍵のパスです。
例えば、Node 1の場合以下のようになります。
ssh -i ~/.ssh/id_rsa opc@129.146.109.106

ip addr | grep ens3
blog17.png

各ノードのプライベートIPアドレスを調べた結果を纏めました。
Nodes:Public IPPrivate IP
Node1 (NFS Server) 129.146.109.106 10.0.11.3
Node2 129.146.22.123 10.0.11.1
Node3 129.146.66.11 10.0.11.2

SSHでNode 1にログインし、NFSをインストール、設定します。
/etc/exports ファイルを編集して、Node 2、Node 3の内部IPアドレスを追加しておきます。
/scratch 10.0.11.1(rw)
/scratch 10.0.11.2(rw)
    • sudo su -
    • yum install -y nfs-utils
    • mkdir /scratch
    • chown -R opc:opc /scratch
    • vi /etc/exports
  1. systemctl restart nfs
  2. exit
SSHでNode 2にログインします。
ssh -i ~/.ssh/id_rsa opc@129.146.22.123
Node 1の内部IPを追加するために、 /etc/fstab を編集します。
10.0.11.3:/scratch /scratch nfs nfsvers=3 0 0
    • sudo su -
    • yum install -y nfs-utils
    • mkdir /scratch
    • vi /etc/fstab
  1. mount /scratch
  2. exit
Node 3に対しても同様の手順を繰り返します。
ssh -i ~/.ssh/id_rsa opc@129.146.66.11
/etc/fstabを編集し、Node 1の内部IPを追加します。
10.0.11.3:/scratch /scratch nfs nfsvers=3 0 0
    • sudo su -
    • yum install -y nfs-utils
    • mkdir /scratch
    • vi /etc/fstab
  1. mount /scratch
  2. exit

Upload the Docker images to the OCI Registry

WebLogic Server 12.2.1.3とWebLogic Kubernetes Operatorに必要なDockerイメージをビルドします。
WebLogic on Docker
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/
Oracle Weblogic Server Kubernetes Operator
https://github.com/oracle/weblogic-kubernetes-operator
TraefikのDockerイメージはDocker HubリポジトリからPullします。以下はその例です。
docker login

docker pull traefik:1.4.5
Dockerイメージに以下のようにタグを付けます。
docker tag [Name Of Your Image For Operator]  phx.ocir.io/weblogicondocker/weblogic-kubernetes-operator:latest

docker tag [Name Of Your Image For WebLogic Domain]  phx.ocir.io/weblogicondocker/weblogic:12.2.1.3

docker tag traefik:1.4.5 phx.ocir.io/weblogicondocker/traefik:1.4.5
認証トークンを生成してphx.ocir.ioOCIR Dockerリポジトリにログインします。
OCIダッシュボードにログインし、”User Settings"をクリックした上で、左側のメニューの”Auth Tokens"をクリックします。

生成されたパスワードを安全な場所に保存します。
OCIR Dockerレジストリに以下のコマンドを使ってログインします。
docker login phx.ocir.io
ユーザー名を尋ねてくるので、OCIテナント名/OCIユーザー名を指定します。
docker login phx.ocir.io

Username: weblogicondocker/myusername           
Password: 
Login Succeeded
Dockerレジストリシークレットを作成します。このシークレット名は小文字のアルファベットもしくは数字で構成されていなければなりません。
kubectl create secret docker-registry <secret_name> --docker-server=<region>.ocir.io --docker-username=<oci_tenancyname>/<oci_username>

--docker-password=<auth_token> --docker-email=example_email
例えば、PHX registry用にocisecretというDockerシークレットを作成する場合は以下の通りです。
kubectl create secret docker-registry ocisecret --docker-server=phx.ocir.io --docker-username=weblogicondocker/myusername --docker-password= _b5HiYcRzscbC48e1AZa  --docker-email=myusername@oracle.com
DockerイメージをOCIRにPushします。
docker push phx.ocir.io/weblogicondocker/weblogic-kubernetes-operator:latest

docker push phx.ocir.io/weblogicondocker/weblogic:12.2.1.3

docker push phx.ocir.io/weblogicondocker/traefik:1.4.5
OCIコンソールにログインしてイメージを検証します。
  1. Log in to the OCI consoleにログインし、正しいリージョンを使っていることを確認する(例:us-phoenix-1
  2. ContainersからRegistryを選択すると、イメージがRegistryのページで確認できるはず。
  3. イメージ名をクリックし、”Actions"を選択して”Public"に変更

Modify the configuration YAML files to reflect the Docker image names in the OCIR

最終ステップでは、入力ファイルのパラメータをカスタマイズし、WebLogic cluster、WebLogic OperatorのデプロイメントYAMLファイルを生成し、Traefikロードバランサを使ってイメージの変更とローカル構成を反映します。ここでは、事前に用意されているスクリプト(reate-weblogic-operator.sh and create-weblogic-domain.sh)を使います。

Gitを使い、WebLogic Kubernetes Operatorプロジェクトをダウンロードします。
git clone https://github.com/oracle/weblogic-kubernetes-operator.git


YAML入力ファイルを編集し、イメージ名を反映します。
cd $SRC/weblogic-kubernetes-operator/kubernetes
Change the ‘image’ フィールドを変更し、OCIRの対応するDockerリポジトリのイメージ名を指定します。
./internal/create-weblogic-domain-job-template.yaml:   image: phx.ocir.io/weblogicondocker/weblogic:12.2.1.3
./internal/weblogic-domain-traefik-template.yaml:      image: phx.ocir.io/weblogicondocker/traefik:1.4.5
./internal/domain-custom-resource-template.yaml:       image: phx.ocir.io/weblogicondocker/weblogic:12.2.1.3
./create-weblogic-operator-inputs.yaml:         weblogicOperatorImage: phx.ocir.io/weblogicondocker/weblogic-kubernetes-operator:latest
create-weblogic-operator-inputs.yaml と create-weblogic-domain-inputs.yaml のその他のパラメータを確認し、変更します。OperatorとWebLogicドメインのインストール手順にある全てのオプションや記述をチェックします。
WebLogic Kubernetes Operator Installation
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/installation.md
Creating a WebLogic domain
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/creating-domain.md
以下は create-weblogic-operator-inputs.yaml でこのデモ用にカスタマイズした値のリストです。
create-weblogic-operator-inputs.yaml
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/create-weblogic-operator-inputs.yaml
targetNamespaces: domain1

weblogicOperatorImage: phx.ocir.io/weblogicondocker/weblogic-kubernetes-operator:latest

externalRestOption: SELF_SIGNED_CERT

externalSans: IP:129.146.109.106
以下は create-weblogic-domain-inputs.yaml でこのデモ用にカスタマイズした値のリストです。
create-weblogic-domain-inputs.yaml
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/create-weblogic-domain-inputs.yaml
domainUID: domain1

t3PublicAddress: 0.0.0.0

exposeAdminNodePort: true

namespace: domain1

loadBalancer: TRAEFIK

exposeAdminT3Channel: true
weblogicDomainStoragePath: /scratch/external-domain-home/pv001
Note: 現時点では、OCI Container Engine for Kubernetes上でWebLogic Serverを動作させる場合、TraefikとApache HTTP Serverをロードバランサとして利用することを推奨しています。Voyager HAProxy Ingress ControllerはOKEでサポートしていないため、動作保証できません。

WebLogicドメインはパラメータweblogicDomainStoragePathで指定されたパスにマップされた永続ボリュームを使います。以下のコマンドで、永続ボリュームディレクトリをNode 1のNFSサーバに作成しましょう。
ssh -i ~/.ssh/id_rsa opc@129.146.109.106 "mkdir -m 777 -p /scratch/external-domain-home/pv001"
今回のデモドメインは名前空間 domain1 で動作するよう構成済みです。名前空間 domain1 を作成するには、以下のコマンドを実行します。
kubectl create namespace domain1
管理サーバへのアクセスのためのユーザー名とパスワードは、ドメイン稼働する名前空間と同一の名前空間のKubernetesシークレットに格納しておかねばなりません。ファイルへの資格証明を保存しないようにするため、スクリプトではシークレットを作成しません。Oracleは以下のコマンドをSSHで実行し、資格証明のセキュリティを保護するための適切な手段を講じることを推奨します。

シークレットを作成するには、以下のコマンドを発行します。
kubectl -n NAMESPACE create secret generic SECRET_NAME

  --from-literal=username=ADMIN-USERNAME

  --from-literal=password=ADMIN-PASSWORD
今回のデモでは、以下の値を使いました。
kubectl -n domain1 create secret generic domain1-weblogic-credentials --from-literal=username=weblogic --from-literal=password=welcome1
最後に、入力ファイルと出力ディレクトリを指定してcreateスクリプトを実行します。
./create-weblogic-operator.sh –i create-weblogic-operator-job-inputs.yaml  -o /path/to/weblogic-operator-output-directory
これで、関連する全てのOperatorデプロイメントを作成し、それらを起動します。

以下のコマンドを実行してOperatorとPodの状態を確認します。


同じコマンドを実行してWebLogicドメインの作成を実施します。
./create-weblogic-domain.sh –i create-weblogic-domain-job-inputs.yaml  -o /path/to/weblogic-domain-output-directory


WebLogicクラスタの状態を確認するには、以下のコマンドを実行します。
bash-4.2$ kubectl get pods -n domain1


ロードバランサが動作している様子を確認しましょう。そのために、WebLogic Server管理コンソールにログインし、testwebapp.warというアプリケーションをデプロイします。WebLogicドメイン用にカスタマイズした入力ファイルでは、AdminNodePortを公開するよう指定していました。ポート番号を確認するには、以下のコマンドを実行します。

Nodeの外部IPアドレスの一つを使い、管理コンソールにアクセスしましょう。今回の場合、 http://129.146.109.106:30701/console でアクセスします。WebLogic Server管理コンソールへのログインには、資格証明としてweblogic/welcome1を使います。

”デプロイメント”、”ロックして編集”をクリックして、testwebapp.warアプリケーションをアップロードします。
testwebapp.war
https://github.com/bhabermaas/kubernetes-projects/blob/master/apps/testwebapp.war
cluster-1をターゲットとして選択し、”終了”、”構成の解放"をクリックします。”制御”タブを選択し、"全てのリクエストを処理"をクリックします。これにより、デプロイメントの状態がアクティブに変わります。

KubernetesクラスタのIngress controllerとしてTraefikを使い、HTTPリクエストの負荷分散をデモしましょう。ロードバランサのNodePort番号を確認するために、以下のコマンドを実行します。

Traefikロードバランサはポート番号30305で動作しています。testwebappアプリケーションにアクセスする場合(http://129.146.22.123:30305/testwebapp/)、常にアプリケーションは現在使われている管理対象サーバの情報を表示します。

同じURLで別の接続では、管理対象サーバ1の情報が表示されます。

Because the WebLogicクラスタを外界に公開し、ノードの外部IPアドレスを使ってアクセス可能になっているため、認可されたWebLogicユーザーはT3プロトコルを使って全ての利用可能なWebLogicリソースにWLSTコマンドを使ってアクセスできます。ファイアウォールがある場合、プロキシトンネルを使ってT3を実行する必要があります(T3 over HTTPを使い、WebLogic Serverでトンネリングを有効化し、T3ではなくHTTPプロトコルを使う)。詳細は以下のエントリをご覧ください。
T3 RMI Communication for WebLogic Server Running on Kubernetes
https://blogs.oracle.com/weblogicserver/t3-rmi-communication-for-weblogic-server-running-on-kubernetes
https://orablogs-jp.blogspot.com/2018/02/t3-rmi-communication-for-weblogic.html
企業ネットワークの外部にいる場合、T3を制限なく利用できます。

Summary

このエントリでは、Oracle Cloud Infrastructure上で動作するOCI Container Engine for Kubernetesを使い、WebLogicクラスタを構成するために必要な全手順と、WebLogicクラスタにデプロイされたWebアプリケーションの負荷分散をご紹介しました。OCI Container Engine for KubernetesでWebLogic Serverを実行すると、マネージドKubernetes環境でWebLogic Serverアプリケーションを活用し、WebLogic Serverアプリケーションを他のクラウド・アプリケーションと統合し、WebLogic Serverの使用法を発展させ、Kubernetesの使用を拡大できます。また、以下の内容について詳細を説明する一連のブログエントリも公開しています。

  • Operatorの実行方法
  • 1個以上のWebLogicドメインをKubernetesで立ち上げる方法
  • WebLogic Diagnostics Framework(WLDF、WebLogic診断フレームワーク)もしくはPrometheusを使ってWebLogicクラスタを手動、もしくは自動でスケールする方法
  • WebLogicクラスタにデプロイされたWebアプリケーションの負荷分散をOperatorで管理する方法
  • OperatorログをElasticsearch、Logstash、Kibanaと連携して管理する方法

How to... WebLogic Server on Kubernetes
https://blogs.oracle.com/weblogicserver/how-to-weblogic-server-on-kuberneteshttps://orablogs-jp.blogspot.com/2018/01/how-to-weblogic-server-on-kubernetes.html

[Kubernetes, Docker, Cloud, WLS] Announcing WebLogic Server Certification on Oracle Cloud Infrastructure Container Engine for Kubernetes

原文はこちら
https://blogs.oracle.com/weblogicserver/announcing-weblogic-server-certification-on-oracle-cloud-infrastructure-container-engine-for-kubernetes

5月7日にWebLogic Server Kubernetes Operatorの一般提供(GA)を発表しました。これはOracle Cloud Infrastructure上でのWebLogic ServerとOperatorの動作構成を保証することも含んでいます。この最初の発表で、WebLogic ServerとOperator OCIの動作保証は、TerraForm Kubernetes Installerを使ってOCI上で構築した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
https://orablogs-jp.blogspot.com/2018/05/announcing-general-availability-version.html
本日、更にOCI上で動作するOracle Container Engine for KubernetesでのWebLogic ServerとOperatorの構成の動作保証を発表します。詳細は以下のエントリをご覧ください。
Kubernetes: A Cloud (and Data Center) Operating System?
https://blogs.oracle.com/cloud-infrastructure/kubernetes-a-cloud-and-data-center-operating-system
https://orablogs-jp.blogspot.com/2018/06/kubernetes-cloud-and-data-center.html
Oracle Container Engine for Kubernetesはスケーラブルで可用性の高い、フルマネージドのサービスで、これを使うとコンテナ化されたアプリケーションをクラウドにデプロイできます。
以下のエントリでは、OCI Registryに格納されたWebLogic ServerとOperatorのイメージを使って、OCI Container Engine for Kubernetesで動作するWebLogic Kubernetes Operatorが管理する、WebLogicドメインやWebLogicクラスタを実行する手順を説明しています。
How to run WebLogic clusters on the Oracle Cloud Infrastructure Container Engine for Kubernetes
https://blogs.oracle.com/weblogicserver/how-to-run-weblogic-clusters-on-the-oracle-cloud-infrastructure-container-engine-for-kubernetes
https://orablogs-jp.blogspot.com/2018/06/how-to-run-weblogic-clusters-on-oracle.html

まもなく、以下の内容について簡単な方法をご提示できそうです。
  • WebLogic Deploy Toolingを使った、Kubernetes上のWebLogic Serverドメインの移行
    WebLogic Deploy Tooling
    https://github.com/oracle/weblogic-deploy-tooling
  • Oracle Container Pipelinesを使ってKubernetes上のWebLogic環境のCI/CDの追加
  • 新機能や拡張機能の追加
説明されたWebLogic ServerとOperatorの機能は、 OCIとの間で完全な互換性がある、標準のKubernetesインフラストラクチャ、ならびにその他のKubernetesを使うプライベートクラウド、パブリッククラウドででサポートされます。Operator、Prometheus Exporter、WebLogic Deploy Toolingは全てオープンソースで開発されています。皆様からのフィードバックをお待ちしています!

[Kubernetes, Docker, Cloud] Kubernetes: A Cloud (and Data Center) Operating System?

原文はこちら
https://blogs.oracle.com/cloud-infrastructure/kubernetes-a-cloud-and-data-center-operating-system

主要なクラウドプロバイダー全体でKubernetesの採用が拡大するにつれて、Kubernetes自体をOSのコンセプトとの比較は興味深いものです。Wikipediaによると、OSは「コンピュータのハードウェアとソフトウェアのリソースを管理し、コンピュータプログラムに共通のサービスを提供するシステムソフトウェア」と定義されています。
Operating System (Wikipedia)
https://en.wikipedia.org/wiki/Operating_system
抽象的には、これはクラウドプロバイダーで動作するKubernetesと、Kubernetesの上で動作するように構築されたアプリケーションの現在のモデルとそれほど違いがありません。この文脈でKubernetesについて考え始めた場合、Kubernetesの過去と将来について何を学ぶことができるでしょうか。

Kubernetes Value Proposition

データセンター運用者は、運用コストやオーバーヘッドを最小限に抑えるために、OSを含む、より小さな基本コンポーネントの標準化に価値があることを長い間理解してきました。コンテナオーケストレーションの(多少複雑ですが)オープンな標準の価値を認識しているため、顧客とベンダーはどちらもその代替としてKubernetesに集まってきています。

企業がコンテナテクノロジを採用したことで、オンプレミスアプリケーションからクラウドへの移行を容易にし、クラウドプロバイダ間のロックインを回避し、将来のハイブリッド・デプロイメントやサーバーレスアプリケーションでも使用できるファブリックを提供する方法として、企業もまた、このオープンなKubernetesプラットフォーム上に構築する機会を認識しました。
Announcing Fn–An Open Source Serverless Functions Platform
https://blogs.oracle.com/developers/announcing-fn
https://orablogs-jp.blogspot.com/2017/10/announcing-fnan-open-source-serverless.html

Cloud OS - Present and Future

通常、OSを、OSの下の(ハードウェアとソフトウェア)リソースの間のレイヤー、その上で動作するアプリケーションという、サンドイッチの一部、として考えています。Kubernetesのアナロジーの文脈では、クラウドプロバイダー(もしくはオンプレミスのデータセンター)が下にあり、ビジネスアプリケーションが上にあります。一般に、OSレイヤーの仕事は基盤となるリソースと対話するという複雑性を抽象化し、アプリケーションの構築および実行をより簡単にすることです。

当然ながら、全てのプロバイダーがここで等しく立てるわけではありません。Raspberry PiやハイエンドのベアメタルサーバーでLinuxを動かすことができるのと同じように、洗練度の違いはあれどKubernetesをクラウドで実行できます。高い予測可能なパフォーマンスを備えた、基盤となるコンピュートやストレージ、ネットワークだけでなく、セキュリティ、ガバナンス、管理インターフェースなどの、まさにクラウド・ファブリックが、エンタープライズグレードのKubernetesとそれを利用するアプリケーションを実現するために重要です。

Linuxがカーネルの枠を超えて拡大しているように、将来の”Cloud OS”は基礎となるKubernetesの枠を超えて、今日”Kubernetes add-on"として一般に考えられているものを含むだけでなく、本当に必要なものクラウド(もしくはデータセンター)OSのコンポーネントとなるために必要なものも含めて実現するために広がっていくことでしょう。関連する例として、サービスメッシュ(IstioやLinkerd)、serverless functions(Fn project)、監視、ロギングのアドオン、そしてKubernetes "operators"、Kubernetesでステートフルなアプリケーション(例えばWebLogic Operator、MySQL Operator、さらにはKubernetes自身のためのoperatorもありです)を実現するためのフレームワークのようなものがあります。
Istio
https://istio.io/
Linkerd
https://linkerd.io/
Fn project
https://fnproject.io/
WebLogic Operator
https://blogs.oracle.com/weblogicserver/announcing-the-new-weblogic-server-kubernetes-operator
https://orablogs-jp.blogspot.com/2018/02/announcing-new-weblogic-server.html
MySQL Operator
https://github.com/oracle/mysql-operator
クラウドプロバイダーはこれらすべてのコンポーネントをマネージドCloud OSにパッケージングする方向に向かっています。こうすることで、自身のユーザー、開発者、企業が彼ら自身のコンテナインフラストラクチャの、特に高可用性の文脈における複雑な管理をしなくてすむようにし、OSの継続的な完全性と、下位のサービス層との互換性を確保できます。

Announcing Availability

これこそがOracle Cloud Infrastructureで将来に向けて取り組んでいることです。つまり、上流のオープンソースプロジェクトの成果をそのまま変更せずに採用し、優れたパフォーマンス、可用性、セキュリティを備え、エンタープライズグレードのクラウドインフラストラクチャで管理された、オープンな標準ベースのCloud OSです。弊社のお客様はお客様のアプリケーションを自身を持ってこの上で実行できますし、データセンターとクラウドの間を自由に移動できます。

Oracle Cloud Infrastructure RegistryとContainer Engine for Kubernetesという、2個の重要なCloud OSのピースを、Oracleはこのたび一般提供(GA)しました。
Oracle Cloud Infrastructure Registry
https://cloud.oracle.com/containers/registry
Container Engine for Kubernetes
https://cloud.oracle.com/containers/kubernetes-engine
  • レジストリは、デプロイメントと同じリージョン内にコンテナイメージを格納および共有するための、可用性の高い、プライベート・コンテナ・レジストリ・サービスです。
  • Container Engine for Kubernetesは、上流の標準Kubernetesのプロダクショングレードのコンテナオーケストレーションと、Oracleの次世代クラウドインフラストラクチャの管理とセキュリティ、予測可能な高いパフォーマンスを組み合わせた、フルマネージドの、エンタープライズ対応のコンテナ・サービスです。
    Oracle Cloud Infrastructure
    https://cloud.oracle.com/cloud-infrastructure
Cloud OSへの旅のいまどのあたりにいらっしゃいますか?現在のコンテナ戦略、弊社がお手伝いできるかどうか、伺えると幸甚です。みなさまから弊社の計画に対するご意見をお寄せください。