[Linux] Resilient RDMA IP Addresses

原文はこちら。
https://blogs.oracle.com/linux/resilient-rdma-ip-addresses

RDSのResilient RDMA IP機能をアップストリームへ導入するために実施している作業に関する記事を、Oracle Linuxカーネルの開発者Sudhakar Dindukurtiが寄稿しました。このコードは現在、OracleのオープンソースのUEKカーネルで管理されており、これを上流のLinuxソースコードに統合する作業を進めています。

1.0 Introduction to Resilient RDMA IP

Resilient RDMAIPモジュールは、InfiniBandおよびRoCEアダプタのフェールオーバー、フェールバック、および負荷分散を行うために、ULP(RDMA上位レベルプロトコル)を支援します。

RDMAIPは、Oracle LinuxのRDMA接続の機能です。active-active bondingとも呼ばれるこの機能を有効にすると、Resilient RDMAIPモジュールはアダプタのポート間にアクティブなbondingグループを作成します。正常時には利用可能な全帯域幅を使用しながら、ネットワークアダプターが失われた場合、そのポート上のIPは、アプリケーション用にHAを自動的に提供しながら、別のポートに移動されます。

Reliable Datagram Sockets (RDS) は、データグラム伝送のための高パフォーマンスで低レイテンシな信頼できるコネクションレスソケットです。RDSは、2ノード間で信頼性の高い単一のトランスポートを使用して、信頼性の高い順序付けされたデータグラム配信を提供します。RDSプロトコルの詳細については、RDSのドキュメントを参照してください。
RDS Wire Specification 3.1
http://oss.oracle.com/projects/rds/dist/documentation/rds-3.1-spec.html
RDS RDMAは、Resilient RDMAIPモジュールを使用してHAサポートを提供します。RDS RDMAモジュールは、Resilient RDMAIPモジュールが提供するRDMA CMアドレス変更イベントを待ち受けます。RDSは、アドレス変更イベントを受信した場合、接続に失敗したポートに関連付けられているすべてのRC接続を削除し、次回データを送信する前に新しいRC接続を再確立します。

透過的な高可用性は、標準のNIC(ネットワーク・インタフェース・カード)と比較して、RDMA対応NICアダプタにとって重要な問題です。標準的なNICの場合、IP層は、パケット送信のためにどの経路またはどのnetdevインタフェースを使用するかを決定できます。これは、ハードウェアを特定のポートとパスに結び付けるという、セキュリティとパフォーマンス上の理由から、RDMA対応アダプターでは不可能です。RDMAを使用してリモートノードにデータパケットを送信するには、いくつかの手順があります。
  1. クライアントアプリケーションはメモリをRDMAアダプタに登録し、RDMAアダプタは登録されたメモリ領域のR_Keyをクライアントに返す。
    (注意)登録情報はRDMAアダプタに保存される。
  2. クライアントはこの "R_key"をリモートサーバーに送信する。
  3. クライアントへのRDMA_READ/RDMA_WRITEを要求時には、サーバにはこのR_keyが含まれる
  4. クライアント側のRDMAアダプタは、"R_key"を使用してメモリ領域を見つけ出し、トランザクションを進める。"R_key"は特定のRDMAアダプタにバインドされているため、同じR_KEYを使用して別のRDMAアダプタでデータを送信することはできない。また、RDMAアプリケーションはカーネルをバイパスして直接ハードウェアと通信できるため、 (カーネルに備わる)これまでのbondingがHAを提供できない。
Resilient RDMAIPは、カーネルULPまたはOSバイパスアプリケーションに対して透過的なフェールオーバーを提供しませんが、RDMA対応アダプターでのULPのフェールオーバー、フェイルバック、およびロードバランスを可能にします。RDS(Reliable Datagram Sockets)プロトコルは、Resilient RDMAIPモジュールサポートを使用してHAを提供している最初のクライアントです。以下のセクションでは、さまざまな機能に対するResilient RDMAIPの役割について説明します。

1.1 Load balancing

Active-Active bondingグループに含まれる全てのインターフェースには個別のIPアドレスがあります。RDMAコンシューマは1個以上のインターフェースを利用して、同時にデータを送信することができ、全てのアクティブなインターフェース間で負荷を分散させる責任があります。

1.2 Failover

Active-Active Bondingグループに属する任意のインターフェースがダウンした場合、Resilient RDMAIPモジュールはインターフェイスのIPアドレスを同じグループ内の他のインターフェイスに移動し、また、RDMA CM(Communication Manager)アドレス変更イベントをRDMAカーネルULPに送信します。HA対応のRDMAカーネルULPは、ダウンしたインターフェイスの使用を停止し、他のアクティブなインターフェイスの使用を開始します。例えば、ダウンしたインターフェースでReliable Connection(RC)が確立されている場合、ULPはこれらの接続をすべて閉じて、フェールオーバーインターフェイスで再確立できます。

1.3 Failback

ダウンしたインターフェイスが(フェールオーバする前に)先に復旧した場合、Resilient RDMAIPモジュールはIPアドレスを元のインターフェイスに戻し、RDMA CMアドレス変更イベントをカーネルコンシューマに再度送信します。RDMAカーネルのコンシューマは、アドレス変更イベントを受信するとアクションを実行します。例えば、RDMAコンシューマは、フェールオーバーの一環で移動された接続を移動します。

2.0 Resilient RDMAIP module provides the below module parameters

  • rdmaip_active_bonding_enabled

    • Active-Active bondingを有効化する場合は1を設定
    • Active-Active bondingを無効化する場合は0を設定
デフォルトでは、Active-Active bondingは無効化されていますが、有効化すると、Resilient RDMAIPモジュールは、同じRDMAアダプタのポート間でアクティブなbondingグループを作成します。例えば、Infiniband(ib0とib1)とRoCE(eth5とeth5)のそれぞれに2つのポートを有する、2つのRDMAアダプタがあるシステムを考えてみましょう。この設定では、2つのアクティブなbondingグループが作成されます。
1)ib0とib1(Bond 1)
2)eth4とeth5(Bond 2)
  • rdmaip_ipv4_exclude_ips_list

    • このパラメータに記載のあるIPの場合、アクティブbonding機能は無効
デフォルトでは、リンクローカルアドレスはResilient RDMAIPによって除外されます。

3.0 How it works ?

Active-Active Bonding

上図で、1個の2ポートInfiniband HCAを備えた2つのノードがあり、HCAの各ポートは図のように異なるスイッチに接続されています。図に示すように、ポートごとに1つずつ、2つのIPoIBインターフェイス(ib0およびib1)が作成されます。Active-Active bondingを有効化すると、Resilient RDMAIPモジュールは自動的にInfiniband HCAの2つのポート間にbondingを作成します。

1) 全てのIBインターフェースが起動していて構成済み

#ip a
---
ib0: <broadcast,multicast,up,lower_up> mtu 2044 qdisc pfifo_fast state UP qlen 256
    link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:00:10:e0:00:01:29:65:01 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    inet 10.10.10.92/24 brd 10.10.10.255 scope global ib0
       valid_lft forever preferred_lft forever
  
  
ib1: <broadcast,multicast,up,lower_up> mtu 2044 qdisc pfifo_fast state UP qlen 256
    link/infiniband 80:00:02:09:fe:80:00:00:00:00:00:00:00:10:e0:00:01:29:65:02 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    inet 10.10.10.102/24 brd 10.10.10.255 scope global secondary ib0:P06
       valid_lft forever preferred_lft forever </broadcast,multicast,up,lower_up></broadcast,multicast,up,lower_up>

2) Node 1のPort 2がダウンすると、ib1のIP '10.10.10.102'がPort 1(ib0)に移動する(フェールオーバ)

#ip a
--------------
 ib0: <broadcast,multicast,up,lower_up> mtu 2044 qdisc pfifo_fast state UP qlen 256
    link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:00:10:e0:00:01:29:65:01 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    inet 10.10.10.92/24 brd 10.10.10.255 scope global ib0
       valid_lft forever preferred_lft forever
    inet 10.10.10.102/24 brd 10.10.10.255 scope global secondary ib0:P06
       valid_lft forever preferred_lft forever
    inet6 fe80::210:e000:129:6501/64 scope link
       valid_lft forever preferred_lft forever
ib1: <no-carrier,broadcast,multicast,up> mtu 2044 qdisc pfifo_fast state DOWN qlen 256
    link/infiniband 80:00:02:09:fe:80:00:00:00:00:00:00:00:10:e0:00:01:29:65:02 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
----------------
</no-carrier,broadcast,multicast,up></broadcast,multicast,up,lower_up>

3) Node 1のPort 2が復旧すると、Port 2 (ib1)にIP '10.10.10.102'が戻る(フェールバック)

#ip a
---
ib0: <broadcast,multicast,up,lower_up> mtu 2044 qdisc pfifo_fast state UP qlen 256
    link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:00:10:e0:00:01:29:65:01 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    inet 10.10.10.92/24 brd 10.10.10.255 scope global ib0
       valid_lft forever preferred_lft forever
  
  
 ib1: <broadcast,multicast,up,lower_up> mtu 2044 qdisc pfifo_fast state UP qlen 256
    link/infiniband 80:00:02:09:fe:80:00:00:00:00:00:00:00:10:e0:00:01:29:65:02 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
      inet 10.10.10.102/24 brd 10.10.10.255 scope global secondary ib0:P06
       valid_lft forever preferred_lft forever
</broadcast,multicast,up,lower_up></broadcast,multicast,up,lower_up>

Example: RDS Implementation

フェイルオーバーおよびフェールバック中に発生するシーケンスを次に示します。ノード1のPort 1のIP1とノード2のIP3との間にRDSソケットを確立するRDSアプリケーションを考えます。この場合、RDSカーネルレベルでは、IP1とIP3の間に1つのRC接続が存在します。

Case 1: Node 1のPort 1がダウン

  • Resilient RDMAIPモジュールがIPアドレスIP1をポート1からポート2に移動
  • ポート2は2つのIP(IP1とIP2)を持つ
  • Resilient RDMAIPモジュールは、RDMA CMアドレス変更イベントをRDSに送信
  • RDS RDMAドライバは、アドレス変更イベントの処理の一環で、IP1(Port 1)とIP3の間のIB接続を切断
  • RDS RDMAドライバは、IP1からIP3への新たな送信リクエストを受信すると、IP1(Port 2)とIP3との間で新しいRC接続を作成
  • フェイルオーバー後、RDSがIP1を解決すると、IP1がPort 2にバインドされるため、RDSはPort 2のパスレコードを取得

Case 2: Node 1のPort 1が復旧

  • Resilient RDMAIPモジュールは、IPアドレスIP1をPort 2からPort 1に移動
  • Resilient RDMAIPモジュールは、RDMA CMアドレス変更イベントをRDSに送信
  • RDS RDMAドライバは、アドレス変更イベントの処理の一環で、IP1(Port 2)とIP3の間のIB接続を切断
  • RDS RDMAドライバは、IP1からIP3への新しい送信要求を受信すると、IP1(Port 1)からIP3への新しいRC接続を作成
  • フェールバック後、RDSがIP1を解決すると、IP1がPort 1にバインドされるため、RDSはPort 1のパスレコードを取得

4.0 Future work

Resilient RDMAIPモジュールの現在の実装は、ネットワークスタック実装と密接に結びついていません。例えば、RDMAカーネルコンシューマは、アクティブなBondingグループを作成する方法を有しておらず、また、アクティブなBondingグループやどのインターフェースがアクティブなBondingグループで構成されているのかをRDMAコンシューマに通知できるAPIはありません。結果として、現在の設計や実装はアップストリームに導入するには適していません。そのため、このモジュールのアップストリームのLinuxに提出可能なバージョンの開発に現在取り組んでいます。しかしながら、それまでの間はRDASIPのコードはoss.oracle.comとgithub上にあります。
Oracle Linux UEK: Unbreakable Enterprise Kernel
http://github.com/oracle/linux-uek

[Linux] Announcing Release 3 of Ceph Storage for Oracle Linux

原文はこちら。
https://blogs.oracle.com/linux/announcing-release-3-of-ceph-storage-for-oracle-linux

Ceph Storage for Oracle Linux Release 3を発表できうれしく思っています。このリリースでは、複数の物理的および論理的な汎用ハードウェアストレージデバイスのクラスタから、オブジェクトストレージおよびブロックストレージの統一されたビューが提供されます。Cephは、Ceph Storage Cluster内のストレージデバイス間でデータを複製およびストライピングすることにより、フォールトトレランスを提供し、I/Oパフォーマンスを向上させます。Cephの監視機能と自己修復機能により、管理オーバーヘッドを最小限に抑えられます。

Ceph Storage for Oracle Linux Release 3は、Ceph Community Luminousリリース(v12.2.5)に基づいています。 Oracleバージョンのソフトウェアとアップストリーム・リリースの違いは、特定のバグに対するOracle固有の修正およびパッチに限られます。

サポートされる機能には、Object Store、Block Device、Ceph Storage Cluster、Ceph File System(Ceph FS)、Simple Ceph Object Gateway、およびMultisite Ceph Object Gatewayコンポーネントがあります。

Notable new features:

  • クラスタ監視のためのCeph Managerデーモン(ceph-mgr)
  • WebベースのCeph Managerダッシュボード
  • HDDやSSDを管理するためにBlueStoreバックエンドを使うOSD(Object Storage Daemon)
  • OSD置換プロセスの簡略化 

Release 3 of Ceph Storage for Oracle Linux adds support for:

  • Ceph iSCSI gateway
  • Ceph FS
  • Ceph FSファイルシステムやblock storage over NFSのエクスポート
  • Ceph block devices with QEMU

Supported Upgrade Path

アップグレード手順は、製品ドキュメントのUpgradeに関する章を参照してください。

Product Support

Ceph Storage for Oracle Linux Release 3は、以前のリリースの2.0を置き換えるものです。Ceph Storage for Oracle Linux Release 3.0は、Unbreakable Enterprise Kernel Release 5を実行するOracle Linux 7(x86_64)で使用できます。Oracle Linux 7 Update 5が最小要件です。Release 3.0のceph-deploymentパッケージは、ULNまたはOracle Linux yumサーバーから入手できます。

Resources – Oracle Linux

Documentation

Software Download

Blogs

Community Pages

Social Media

Data Sheets, White Papers, Videos, Training, Support & more

[Linux] Latest Oracle Linux 7.5 and 6.10 Vagrant Boxes Now Available

原文はこちら。
https://blogs.oracle.com/linux/latest-oracle-linux-75-and-610-vagrant-boxes-now-available

Oracle VM VirtualBox用のOracle Linux Vagrant Boxが、Oracle Linux 7.5 + Unbreakable Enterprise Kernel release 5とOracle Linux 6.10にアップデートされました。
Oracle Linux Vagrant Boxes
https://yum.oracle.com/boxes
これらのVagrant Boxには以下のものが含まれています。
  • 最新のカーネル
    • Oracle Linux 7: UEK5 (4.14.35-1818.0.9.el7uek.x86_64)
    • Oracle Linux 6: UEK4 (4.1.12-124.16.4.el6uek.x86_64)
  • VirtualBox guest additions RPMインストール済み
  • Minimal package setインストール済み
  • rootボリューム:32 GB(XFS)
  • Swap:4 GB
  • VirtualBoxディスクイメージ16GB(動的割り当て)をアタッチ済み
完全な最新の詳細情報は以下から確認してください。
Oracle Linux Vagrant Boxes
https://yum.oracle.com/boxes

VirtualBox Guest Addition RPMs

昨年、VirtualBox Guest AdditionのRPM版を導入しました。これにより、必須のドライバやゲストOS最適化機能のインストールやアップグレードが簡単になりました。今回のVagrant BoxではGuest AdditionのRPMは事前インストール済みです。

Get Up and Running Quickly with Pre-configured Software Stacks: Vagrantfiles on GitHub

Oracle Database、Docker、Kubernetesを試してみたいけれど、インストールの詳細に悩まされたくない、さくっと始めたいと思っているなら、GitHubのVagrantfilesにUpしたVagrantファイルをお使いください。
Official source for Vagrant configuration files and examples for Oracle products and projects
https://github.com/oracle/vagrant-boxes
例えば、以下のようなVagrantfilesと手順書がありますので、インストールや構成が簡単です。

References

[Cloud] Announcing Oracle Cloud Infrastructure Ansible Modules

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-cloud-infrastructure-ansible-modules

Oracle Cloud InfrastructureのAnsibleモジュールが公開されたことを発表できうれしく思っています。

より多くのお客様がOracle Cloud Infrastructureにアプリケーションをデプロイするにつれて、これらの操作を自動化するためのDevOps機能の必要性が増していると見ています。Ansibleはこうしたニーズに対応するもので、リソースのプロビジョニングと構成を自動化します。この新たなOracle Cloud Infrastructure Ansibleモジュールは、Oracle Cloud Infrastructureリソースをプロビジョニングし、構成する機能を提供します。現在のリリースですべてのコア・サービスをサポートします(将来のリリースではさらに多くのサービスが対象となります)。またAnsibleには、Oracle Cloud Infrastructure Ansibleモジュールと連携して、エンドツーエンドのニーズを満たすために利用可能な、組み込みモジュールのツールボックスが含まれています。
Ansible Module Index
http://docs.ansible.com/modules_by_category.html
Ansibleは、複雑なエージェントや、セキュリティのカスタマイズ、集中構成サーバーの設定は不要で、自動化するジョブを記述するだけでOKです。Oracle Cloud Infrastructureのリソースをプロビジョニングして構成するには、Ansibleのplaybookを使用して、必要な状態を宣言します。これらのplaybookをAnsibleが実行すると、要件に応じてOracle Cloud Infrastructureのリソースがプロビジョニングおよび構成されます。

Oracle Cloud Infrastructure AnsibleモジュールはGitHubのoci-ansible-modulesリポジトリにあり、マニュアルではサポート対象のモジュールのリストを参照できます。これらのモジュールおよび将来の改善についてのご意見をお待ちしております。oci-ansible-modulesのGitHubのIssueページで皆さんの意見を書き込んでください。
Oracle Cloud Infrastructure (OCI) Ansible Modules
https://github.com/oracle/oci-ansible-modules
Ansible Modules for Oracle Cloud Infrastructure
https://docs.cloud.oracle.com/iaas/Content/API/SDKDocs/ansible.htm
Oracle Cloud Infrastructure (OCI) Ansible ModulesのIssueページ
https://github.com/oracle/oci-ansible-modules/issues

Getting Started

  1. Python SDKをインストール
    Python SDK for Oracle Cloud Infrastructure
    https://github.com/oracle/oci-python-sdk#installation
    pip install oci
  2. Oracle Cloud Infrastructureの資格証明を使ってSDKを構成
    SDK and Tool Configuration
    https://docs.cloud.oracle.com/iaas/Content/API/Concepts/sdkconfig.htm
  3. AnsibleインストールガイドにしたがってAnsibleをインストール
    Installation Guide
    https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html
  4. Ansibleモジュールリポジトリをクローン
    $ git clone https://github.com/oracle/oci-ansible-modules.git
    $ cd oci-ansible-modules
  5. 以下のコマンドの一つを実行してAnsibleモジュールをインストール
    • root以外のユーザーでAnsibleをインストールした場合
      $ ./install.py
    • rootでAnsibleをインストールした場合
      $ sudo ./install.py
  6. サンプルのplaybook(例えばlist_buckets)を作成して実行
    Write a sample playbook
    https://docs.cloud.oracle.com/iaas/Content/API/SDKDocs/ansiblegetstarted.htm?tocpath=Developer%20Tools%20%7CAnsible%20Modules%20for%20Oracle%20Cloud%20Infrastructure%7C_____1#writeSample
    $ ansible-playbook list_buckets.yml

詳細は、以下のリソースをご覧ください。
以下のチャネルもお役にたつかもしれません。

[Linux] Translating Process ID between Namespaces

原文はこちら。
https://blogs.oracle.com/linux/translating-process-id-between-namespaces

pid(プロセスID)を異なる名前空間の間で変換する課題に関する、Oracle Linuxのカーネル開発者であるNagarathnam Muthusamyによる寄稿です。これはLinuxカーネルの名前空間サポートには現在ない機能ですが、CDBを使ってOracle Databaseのマルチテナント利用を実現するために重要な機能です。
Oracle Database 12c Feature: Multitenant Database
http://www.oracle.com/technetwork/articles/database/multitenant-part1-pdbs-2193987.html
LinuxカーネルのプロセスID(PID)名前空間機能は、プロセス・グループ間で分離を提供する効果的な方法で、さまざまなコンテナの実装で利用されてきました。プロセス間の強力な分離が求められていますが、システム内の他のプロセスの活動やリソースの利用状況を監視したいプロセスが常に存在します。PID名前空間の各々には独自のPIDシーケンスがあり、プロセスIDと独自のPID名前空間との間で相互変換するために、階層の先頭からプロセスを監視するためのプロセスが必要です。Linuxカーネルには、結果PIDを返すさまざまなAPIセットがありますが、これらのAPIはいずれもPID変換に使用できます。以下でその方法をご紹介します。

SCM_CREDENTIALS:

送信側は、SCM_CREDENTIALSメッセージを送受信して、自身の名前空間のPIDをターゲットの名前空間のPIDに変換できます。この方法の欠点は、PID変換に対するソケット通信チャネルが必要で、その管理オーバーヘッドが増える点です。このメソッドは、ルートでない、もしくはCAP_SYS_ADMINを持たない限り、送信側が他のプロセスのPIDを変換できません。
unix - sockets for local interprocess communication
http://man7.org/linux/man-pages/man7/unix.7.html

/proc/<pid>/status file

/proc/<pid>/statusファイルは、異なる名前空間のプロセスに関連付けられたPIDを見つける方法を提供します。親名前空間からの、親名前空間から子名前空間へのPID変換は、所望のレベルで所望のPIDを見つけるために、親名前空間内のすべてのstatusファイルを検索する必要があります。
proc - process information pseudo-filesystem
http://man7.org/linux/man-pages/man5/proc.5.html
Patchwork [resend,v10,1/2] /proc/PID/status: show all sets of pid according to nslogin
https://patchwork.kernel.org/patch/5861791/

shmctl(..,IPC_STAT,..), msgctl(..,IPC_STAT,..)

共有メモリのIPC_STATが提供する構造体shmid_dsには、以下の2要素が含まれています。
pid_t           shm_cpid;    /* PID of creator */
pid_t           shm_lpid;    /* PID of last shmat(2)/shmdt(2) */
メッセージキューのIPC_STATが提供する構造体struct msqid_dsには、 以下の2要素が含まれています。
pid_t           msg_lspid;    /* PID of last msgsnd(2) */
pid_t           msg_lrpid;    /* PID of last msgrcv(2) */
これらの要素のPIDは、呼び出し元のPID名前空間に変換されます。名前空間にかかわらず、プロセス共有リソースの利用状況を監視するために監視側がこれらのPIDを利用できますが、共有メモリやメッセージキューを作成せずに、これらのAPIを汎用的なPID変換のために利用することはできません。
shmctl - System V shared memory control
http://man7.org/linux/man-pages/man2/shmctl.2.html
msgctl - System V message control operations
http://man7.org/linux/man-pages/man2/msgctl.2.html

semctl(..,GETPID,..)

semctlのGETPIDコマンドは、セマフォに対して最後の操作を実行したプロセスのPIDを提供します。shmctlおよびmsgctlと同様に、これはセマフォのユーザを監視する優れた方法ですが、セマフォを作成しないで汎用PID変換に使用することはできません。shmctlとsemctlはアップストリームのLinuxカーネル4.17で修正されました。この機能は、旧リリースでは使用できない可能性がありますが、Oracle UEKに取り込まれる予定です。
semctl - System V semaphore control operations
http://man7.org/linux/man-pages/man2/semctl.2.html

fcntl(..,F_GETLK,..)

fcntlのF_GETLKコマンドは、ファイルロック保持中のプロセスに関する情報を提供します。この情報は、呼び出し元の名前空間に変換されます。異なるPID名前空間を通じた変換を必要とするプロセスは、ロック可能な共通の場所にダミーファイルを作成できます。fcntlを使ったファイルロック所有者に関する問い合わせは、呼び出し元の名前空間の下で観測されるプロセスの変換後のPIDを返します。確かにファイルはどのIPCメカニズムよりも軽量ですが、PID変換のためだけにシステム内のすべてのプロセスのファイル作成とクリーンアップという、追加のオーバーヘッドが必要です。

Is there any cleaner way?

通常、監視プロセスやシステム内の他のプロセスでPID変換が必要な場合、前述の方法のいずれかを使用してこの問題を回避できます。上記のオプションのいずれもあなたのユースケースを満足しない場合ですが、その状況はあなただけではありません。

私はKonstantinと協力して、translate_pidという新しいシステムコールを使いPID変換機能を提供する古いパッチを復活させました。この議論は以下のURLで追いかけることができます。このリンクには、APIの以前のバージョンへのポインタもあります。
[PATCH RFC v5] pidns: introduce syscall translate_pid
https://lkml.org/lkml/2018/4/4/677
このAPIは以下の関数シグネチャを伴って動き始めました。
pid_t getvpid(pid_t pid, pid_t source, pid_t target)
ここで強調されている大きな問題は、名前空間を識別するためのPIDの使用でした。PIDを使うすべてのAPIは、PIDの再利用に関わる競合状態の影響を受けやすいのですが、Linuxカーネルには、それらのインタフェースが設計されたときにリソースを識別する優れた方法がなかったために、多くの既存のPIDベースのインタフェースしか持っていませんでした。この提案は次のAPIにつながります。
pid_t translate_pid(pid_t pid, int source, int target);
ここで、sourceとtargetは、ソースとターゲットの名前空間の/proc/<pid>/ns/pidファイルを指すファイル記述子です。このAPIの大きな問題は、すべてのPID変換のためにファイルの開閉に関する追加ステップです。このAPIは、PID変換を必要とするが、/proc/<pid>/ns/pidファイルを開く権限を持たないユースケースでも利用できません。

このブログを書いている時点で議論中のAPIは、以下のように両方の世界の最善を取り込もうとしています。
pid_t translate_pid(pid_t pid, int source_type, int source, int target_type, int target);
ここで、以下のように *type 引数を使って、ソースとターゲットを解釈する方法を変更します。
TRANSLATE_PID_CURRENT_PIDNS //現在のPID名前空間、引数を使わない
TRANSLATE_PID_TASK_PIDNS //task pid-ns、引数はtask pid
TRANSLATE_PID_FD_PIDNS //pidns fd、引数はファイル記述子
APIが完成すると、他の既存のメソッドの問題を回避しない、PIDを変換するためのよりクリーンなメソッドが用意されることでしょう。

[Network] Openswan on Oracle Cloud Infrastructure

原文はこちら
https://blogs.oracle.com/cloud-infrastructure/openswan-on-oracle-cloud-infrastructure

Oracle Cloud Infrastructureなどのクラウド・プロバイダを使用してオンプレミス・サービスを移行または統合するユーザーは、通常、IPセキュリティ(IPSec)テクノロジを使用して環境間で暗号化トンネルを作成し、データ転送やアプリケーションの統合を行います。
IaaS - Enterprise Cloud - Oracle Cloud Infrastructure
http://cloud.oracle.com/iaas
OpenswanのようなIPSecテクノロジを使用すると、ユーザーはPublic Internetにデータやアプリケーションを公開しなくてすみます。この記事の目的は、OpenswanとLibreswanのIPSec技術を明確にすることです。

Openswanは、Linux用のよく知られたIPSec実装です。今は亡きFreeS/WANプロジェクトのフォークとして始まりましたが、FreeS/WANプロジェクトとは異なり、GNU/Linux OSのみをターゲットにするのではなく、他のOSへもユーザビリティを拡大しました。2012年には、openswanという名前に関する商標の訴訟のため、The Libreswan Projectに改名されました。
Openswan
https://www.openswan.org/
Linux FreeS/WAN
http://www.freeswan.org/
Libreswan VPN software
https://libreswan.org/
その結果、OpenswanパッケージをOracle Linuxにインストールもしくはクエリしようとすると、デフォルトでLibreswanパッケージがインストールされるか、もしくは表示されます。yum search queryコマンドでこの挙動がわかります。
sudo yum search openswan
読み込んだプラグイン:ulninfo
Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast
============================================================ 一致: openswan ============================================================
NetworkManager-libreswan.x86_64 : NetworkManager VPN plug-in for libreswan
NetworkManager-libreswan-gnome.x86_64 : NetworkManager VPN plugin for libreswan - GNOME files
libreswan.x86_64 : IPsec implementation with IKEv1 and IKEv2 keying protocols
LibreswanはLibreswanプロジェクトがメンテナンスしており、さかのぼることFreeS/WANプロジェクトから、15年以上にわたって活発に開発されています。詳細については、プロジェクトの歴史を参照してください。
History of The Libreswan Project
https://libreswan.org/wiki/History
データを特定の場所からクラウドに移動するための安全な暗号化されたポイントツーポイントチャネルを持つことで、侵害やデータの損失を防ぐ、より安全なソリューションになります。Oracle Cloud Infrastructureと異なるクラウド・プロバイダやオンプレミス環境、またはその両方の間でIPSecのポイント・ツー・ポイント暗号化トンネルを作成する場合は、Libreswanを使用した構成方法を説明する以下のエントリをご覧ください。
Creating a Secure Connection Between Oracle Cloud Infrastructure and Other Cloud Providers
https://blogs.oracle.com/cloud-infrastructure/creating-a-secure-connection-between-oracle-cloud-infrastructure-and-other-cloud-providers

[Hardware, Security, Support] Updates about the “Spectre” series of processor vulnerabilities and CVE-2018-3693

原文はこちら
https://blogs.oracle.com/oraclesecurity/updates-about-the-spectre-series-of-processor-vulnerabilities-and-cve-2018-3693

新たなプロセッサの脆弱性が本日発表されました。CVE-2018-3693 (“Bounds Check Bypass Store” もしくは BCBS) と呼ばれる脆弱性で、Spectre v1と密接に関連しています。以前SpectreとMeltdownで繰り返したように、OracleはIntelや業界のパートナーと協力し、このプロセッサの脆弱性を緩和する技術的な方策を開発しています。

ご注意いただきたいのは、業界の多数のエキスパートが最新のプロセッサ設計におけるこれらの既知の欠陥を利用した多数の新しいエクスプロイトの変種が、近い将来開示され続けると予想している、ということです。これらの問題は、主にOSや仮想化プラットフォームに影響を与える可能性があり、ソフトウェアの更新、マイクロコードの更新、またはその両方が必要になる場合があります。幸運なことに、これらの問題を悪用するための条件は似ています。悪意のある攻撃を行うには、標的のシステムに対して悪意のあるコードをインストールして実行するために必要な権限をまず取得する必要があります。

CVE-2018-3640(Spectre v3a)およびCVE-2018-3639(Spectre v4)に関して言うと、Oracleが製造したSPARCプロセッサ(すなわち、SPARC M8、T8、M7、T7、S7、M6、M5、T5、T4、T3、T2、T1)はこれらの変種の影響を受けないと断定しました。
Updates about processor vulnerabilities CVE-2018-3640 (“Spectre v3a”) and CVE-2018-3639 (“Spectre v4”)
https://blogs.oracle.com/oraclesecurity/updates-about-processor-vulnerabilities-cve-2018-3640-and-cve-2018-3639
https://orablogs-jp.blogspot.com/2018/07/updates-about-processor-vulnerabilities.html
また、Oracleは過去4世代のOracle x86 Server向けのマイクロコードのパッチを提供しています。
CVE-2018-3640 (Spectre v3a), CVE-2018-3639 (Spectre v4) Vulnerabilities : Intel Processor Microcode Availability (ドキュメントID 2406316.1)
https://support.oracle.com/rs?type=doc&id=2406316.1
以前のバージョンのSpectreとMeltdownの脆弱性(My Oracle Support ドキュメントID 2347948.1)と同様に、Oracleはこれらの問題に関する情報をMy Oracle Supportに公開する予定です。
Addendum to the January 2018 CPU Advisory for Spectre (CVE-2017-5715, CVE-2017-5753) and Meltdown (CVE-2017-5754) vulnerabilities (ドキュメントID 2347948.1)
https://support.oracle.com/rs?type=doc&id=2347948.1

[Hardware, Security, Support] Processor vulnerabilities CVE-2018-3640 (“Spectre v3a”) and CVE-2018-3639 (“Spectre v4”)

原文はこちら。
https://blogs.oracle.com/oraclesecurity/processor-vulnerabilities-cve-2018-3640-and-cve-2018-3639

Oracle security and developmentチームはCVE-2018-3640 (a.k.a. “Spectre v3a”) と CVE-2018-3639 (a.k.a. “Spectre v4”) という脆弱性を認識しています。

Oracleは活発にIntelyその他の業界パートナーと強力して、これらのプロセッサの脆弱性の技術的な緩和策を開発しています。このような軽減策には、ソフトウェアとマイクロコードの両方の更新が必要です。

SpectreとMeltdownという脆弱性の以前のバージョンと同様、Oracleは影響を受ける製品リストを公開すると共に、その他の技術情報もMy Oracle Supportで公開していきます。
Addendum to the January 2018 CPU Advisory for Spectre (CVE-2017-5715, CVE-2017-5753) and Meltdown (CVE-2017-5754) vulnerabilities (ドキュメントID 2347948.1)
https://support.oracle.com/rs?type=doc&id=2347948.1
Information about processor vulnerabilities CVE-2018-3640 ("Spectre v3a") and CVE-2018-3639 ("Spectre v4") (ドキュメントID 2399123.1)
https://support.oracle.com/rs?type=doc&id=2399123.1

また、Oracleおよびサードパーティのサプライヤからアップデートが利用可能になると、Oracle Cloudチームは、そのアップデートが保証される場合には、適切な変更管理プロセスに従って、必要なアップデートを特定して適用します。

[Hardware, Security, Support] Updates about processor vulnerabilities CVE-2018-3640 (“Spectre v3a”) and CVE-2018-3639 (“Spectre v4”)

原文はこちら。
https://blogs.oracle.com/oraclesecurity/updates-about-processor-vulnerabilities-cve-2018-3640-and-cve-2018-3639

プロセッサの2個の脆弱性が2018年5月21日に公開されました。
Processor vulnerabilities CVE-2018-3640 (“Spectre v3a”) and CVE-2018-3639 (“Spectre v4”)
https://blogs.oracle.com/oraclesecurity/processor-vulnerabilities-cve-2018-3640-and-cve-2018-3639
https://orablogs-jp.blogspot.com/2018/07/processor-vulnerabilities-cve-2018-3640.html
これらの脆弱性は、CVE-2018-3640 ( “Spectre v3a” もしくは “Rogue System Register Read”) と CVE-2018-3639 (“Spectre v4” もしくは “Speculative Store Buffer Bypass”) と呼ばれるものです。両者とも4.3というCVSSのベーススコアが付けられています。

脆弱性CVE-2018-3639の悪用を成功させるには、ターゲット・システムへのローカルアクセスが必要です。影響を受けるシステムでこの脆弱性を緩和するには、ソフトウェアとマイクロコードの両方の更新が必要です。

脆弱性CVE-2018-3640の悪用を成功させるには、こちらもターゲット・システムへのローカルアクセスが必要です。影響を受けるインテルプロセッサーに対してこの脆弱性を緩和するには、更新されたプロセッサー固有のマイクロコードを適用する以外の方法はありません。

業界で協力して、Oracleは特定のx86プラットフォーム用にインテルが最近リリースしたマイクロコードと共に、Oracle LinuxおよびOracle VMで必要なソフトウェア・アップデートをリリースしました。
CVE-2018-3639
https://linux.oracle.com/cve/CVE-2018-3639.html
商用のマイクロコードがIntelからから入手できるようになれば、Oracleは、マイクロコードの新たなアップデートおよびファームウェア・パッチを引き続きリリースします。
CVE-2018-3640 (Spectre v3a), CVE-2018-3639 (Spectre v4) Vulnerabilities : Intel Processor Microcode Availability (ドキュメントID 2406316.1)
https://support.oracle.com/rs?type=doc&id=2406316.1
Spectre と Meltdownの脆弱性の以前のバージョン(MOS Note ID 2347948.1を参照)に関しては、OracleはCVE-2018-3639およびCVE-2018-3640の影響を受ける製品のリストをその他の技術情報と共にMy Oracle Support(MOS Note ID 2399123.1)で公開します。
Addendum to the January 2018 CPU Advisory for Spectre (CVE-2017-5715, CVE-2017-5753) and Meltdown (CVE-2017-5754) vulnerabilities (ドキュメントID 2347948.1)
https://support.oracle.com/rs?type=doc&id=2347948.1
Information about processor vulnerabilities CVE-2018-3640 ("Spectre v3a") and CVE-2018-3639 ("Spectre v4") (ドキュメントID 2399123.1)
https://support.oracle.com/rs?type=doc&id=2399123.1
さらに、Oracleおよびサードパーティのサプライヤからアップデートが利用可能になると、Oracle Cloudのチームは、そのアップデートが保証される場合には、適切な変更管理プロセスに従って、必要なアップデートを特定して適用します。

[Cloud] Automate Application Deployment Across Availability Domains on Oracle Cloud Infrastructure with Terraform

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/automate-application-deployment-across-availability-domains-on-oracle-cloud-infrastructure-with-terraform

このエントリの目的は、Terraformを使ってOracle Cloud Infrastructureの複数のアベイラビリティ・ドメインにわたってアプリケーションのデプロイを自動化する方法とそのコツを説明することです。

Oracle Cloud Infrastructureのリージョンには、複数のアベイラビリティ・ドメインが含まれており、これらのアベイラビリティ・ドメインはそれぞれ分離しており、フォールトトレラントであり、同時に障害が発生したり、別のアベイラビリティ・ドメインの障害によって影響を受けることはありません。高可用性を確保し、リソースの障害から保護するには、複数のアベイラビリティ・ドメインにアプリケーションをデプロイすることをお勧めします。

Terraformを使ったデプロイメント自動化を説明するために、bastion(踏み台)、パブリックエージェント、マスター、およびワーカーノードで構成されるクラスタアプリケーションを使用します。 これらのノードは、高可用性を確保するために、複数のアベイラビリティ・ドメインにデプロイする必要があります。bastionノードとパブリックエージェントノードはpublicサブネットに、マスターノードとワーカーノードはprivateサブネットにそれぞれデプロイされます。

Create Subnets in Each Availability Domain

このクラスタデプロイメントのために高可用性と冗長性を実現するには、各アベイラビリティ・ドメインに3つのサブネット(bastion、public、private)を作成し、対応するクラスタノードをこれらのサブネットに展開する必要があります。Terraformでは、count変数を使用して、各アベイラビリティ・ドメイン内でこれらのサブネットを作成できます(個別に作成する必要はありません)。ここでのコツは、count.indexを使用して、これらのサブネットを作成する際に各アベイラビリティ・ドメインを参照することです。

以下のコードは、3個のprivateサブネットを各アベイラビリティ・ドメインに作成する例です。
data "oci_identity_availability_domains" "ADs" {
  compartment_id = "${var.tenancy_ocid}"
}

resource "oci_core_subnet" "private" {
  count = "3"
  availability_domain = "${lookup(data.oci_identity_availability_domains.ADs.availability_domains[count.index],"name")}"

  cidr_block = "${var.sampleapp_cidr[count.index]}"
  display_name = "private_ad${count.index}"
  compartment_id = "${var.compartment_ocid}"
  vcn_id = "${oci_core_virtual_network.sampleapp_vcn.id}"
  route_table_id = "${oci_core_route_table.sampleapp.id}"
  security_list_ids = ["${oci_core_security_list.PrivateSubnet.id}"]
  dhcp_options_id = "${oci_core_virtual_network.sampleapp_vcn.default_dhcp_options_id}"

  dns_label = "private${count.index}"
}

Deploy Cluster Nodes Across Availability Domains

同じやり方で、クラスタノードを対応するアベイラビリティ・ドメイン内にプロビジョニングし、デプロイできます。ここでのトリックは、count変数と剰余演算子%を使用する、という点です。これにより、簡単にこれらのノードを異なるアベイラビリティ・ドメインに配布できます。

例えば、count.index%3を使用して、デプロイするアベイラビリティ・ドメインを判断し、前章で作成したサブネットのリストからsubnet_idを取得できます。以下のコードは、ユーザーが指定した数のワーカー・ノードを作成し、これらのノードを異なるアベイラビリティ・ドメインにデプロイする例です。
resource "oci_core_instance" "WorkerNode" {
  count = "${var.worker_node_count}"
  availability_domain = "${lookup(data.oci_identity_availability_domains.ADs.availability_domains[count.index%3],"name")}"

  compartment_id      = "${var.compartment_ocid}"
  display_name        = "Worker ${format("%01d", count.index+1)}"
  hostname_label      = "Worker-${format("%01d", count.index+1)}"
  shape               = "${var.WorkerInstanceShape}"
  subnet_id           = "${oci_core_subnet.private.*.id[count.index%3]}"

  source_details {
    source_type = "image"
    source_id = "${var.image_ocid}"
    boot_volume_size_in_gbs = "${var.boot_volume_size}"
  }

  metadata {
    ssh_authorized_keys = "${var.ssh_public_key}"
  }

  timeouts {
    create = "30m"
  }
}

Attach Block Volumes to Cluster Nodes

ブロックボリュームを作成し、アベイラビリティ・ドメインに分散しているクラスタノードへアタッチする場合には、同様の方法を使い、count変数に基づいて剰余演算子(%)を実行できます。

以下のコード例では、ブロックボリュームを作成し、各アベイラビリティ・ドメイン内の対応するマスターノードに割り当てています。
resource "oci_core_volume" "MasterVolume" {
  count="${var.MasterNodeCount}"
  availability_domain = "${lookup(data.oci_identity_availability_domains.ADs.availability_domains[count.index%3],"name")}"
  compartment_id = "${var.compartment_ocid}"
  display_name = "Master ${format("%01d", count.index+1)} Volume"
  size_in_gbs = "${var.blocksize_in_gbs}"
}

resource "oci_core_volume_attachment" "MasterAttachment" {
  count="${var.MasterNodeCount}"
  attachment_type = "iscsi"
  compartment_id = "${var.compartment_ocid}"
  instance_id = "${oci_core_instance.MasterNode.*.id[count.index]}"
  volume_id = "${oci_core_volume.MasterVolume.*.id[count.index]}"
}
このエントリが皆様のお役に立って、Oracle Cloud Infrastructure上の複数のアベイラビリティ・ドメインにわたるアプリケーション・デプロイメントを簡単に自動化できるようになることを願っています。

[Kubernetes, Cloud] Deploy Jenkins on Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/deploy-jenkins-on-oke




以前のエントリで、Oracle Cloud Infrastructure Compute plugin for Jenkinsを使ってOracle Cloud Infrastructure上にマスタ/スレーブアーキテクチャでJenkinsをデプロイする方法を説明しました。
Deploy Jenkins on Oracle Cloud Infrastructure
https://blogs.oracle.com/cloud-infrastructure/deploy-jenkins-on-oracle-cloud-infrastructure
Oracle Cloud Infrastructure Compute Plugin
https://github.com/oracle/oci-compute-jenkins-plugin
このプラグインを使うと、仮想マシン(VM)やベアメタルインスタンスをOracle Cloud Infrastructure内でオンデマンドにスレーブ/エージェントとしてスピンアップし、ジョブ完了後自動的に切り離すことができます。数多くのエージェントをスピンアップすることにより、Jenkinsは多数のジョブを並列実行できます。
VMベースのプラグインを使うことに対する代替策として、その代わりにコンテナベースのJenkinsエージェントを作成できます。これはVMよりも迅速にスピンアップできます(秒単位と分単位の違い)し、ビルドジョブ完了後の切り離しも迅速です。必要な全ツールや環境設定を備えたDockerコンテナイメージを基にしてコンテナベースのJenkinsエージェントをプロビジョニングします。

このエントリでは、JenkinsエージェントをDockerコンテナとしてセットアップし、Kubernetesクラスタ内にデプロイする方法を紹介します。これを実現するために、別のJenkinsプラグインを使用します。それがKubernetes plugin for Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) です。 OKEは安全で可用性の高いKubernetesクラスタを提供し、Oracle Cloud Infrastructureでコンテナ化されたアプリケーションを管理します。このエントリの手順に従うと、下図のようにJenkinsを展開できます。

Prerequisites

Step 1: Install the Kubernetes Plugin for Jenkins

Kubernetes plugin for Jenkinsを使って動的なJenkinsエージェントをKubernetesクラスタ内で実行します。
  1. Jenkins Dashboardで、Manage Jenkins > Manage Plugins を選択
  2. Available タブで、Kubernetes pluginを探し、インストール(再起動しない)

Step 2: Configure the Kubernetes Plugin with OKE

  1. In the Jenkins Dashboardダッシュボードで、Manage Jenkins > Configure System を選択
  2. Add a new cloud をクリックし、Kubernetesを選択
  3. Kubernetes クラウド設定の項目に移動し、以下の情報を入力する
    1. Name: Kubernetes クラウド設定の名前
    2. Kubernetes URL: OKEクラスタのエンドポイント。以下のコマンドを実行してKubernetes URLを取得できる(すでにkubeconfigファイルをダウンロード済みである前提)
    3. Kubernetes server certificate key: X509 PEM エンコードされた証明書。Disable https certificate checkを選択した場合にはオプション扱い。以下のコマンドを実行してKubernetesシークレット・トークンを取得できる(すでにkubeconfigファイルをダウンロード済みである前提)
    4. Kubernetes namespace: Kubernetesクラスタの名前空間。
    5. Credentials: Kubernetesシークレット・トークンを格納するシークレットテキスト。kubeconfigファイルでKubernetes証明書キーを取得できるが、base64エンコードされているので、デコードする必要がある。
  4. Kubernetesロールベースアクセス制御(RBAC)を構成し、デフォルトサービスアカウントトークンを有効化し、adminロールを付与することによってクラスタとの対話を可能にする
  5. Test Connection をクリックしてレスポンスが以下のスクリーンショットのように “Connection test successful” であることを確認する
    Note: “No valid crumb was included in the request” というエラーメッセージが表示されることがあるが、このエラーはJenkins Kubernetes Pluginの不具合である。エラーを修正するには、以前のページに戻って再実行する。
  6. Configure the Jenkins URL by entering your Jenkins Master URLを指定してJenkins URLを構成する。残りの入力フィールドはデフォルト値を使ってもよい。
  7. 以下のスクリーンショットのように、 Kubernetes Pod Template を設定する。ビルドジョブ実行時に必要なので、Jenkinsエージェントに設定したラベルを忘れないようにする。
  8. 以下のスクリーンショットのように、Container Template を設定する。このエントリの目的のため、カスタムJenkinsのjnlp-slave Dockerイメージのpull元としてOracle Container Registryを利用する。Jenkinsのjnlp-slave Dockerイメージはすでにレジストリで利用可能になっていることを確認しておくこと。また、パブリックのDocker Hubレジストリを使ってJenkinsのjnlp-slaveイメージをpullすることもできる。この場合、Docker image フィールドにはjenkins/jnlp-slaveを指定する。完了したら設定を保存する。
Notes:
  • Oracle Container Registryのリポジトリにpublicとしてマークを付け、カスタムjnlp-slave Dockerイメージを取得できるようにしているが、プライベートリポジトリを使用している場合は、リポジトリにアクセスするための適切な資格情報を使うようJenkinsを設定する必要がある。
  • パブリックDocker Hubレジストリを使用してjnlp-slaveイメージを取得する場合は、必ずjenkins/jnlp-slaveと入力する。多くのオンラインリソースにはjenkinsci/jnlp-slaveを指定するような記述がありますが、この設定は廃止予定である。

Step 3: Test the Kubernetes Plugin with OKE

  1. New > Freestyle project を選択してJenkinsで簡単なプロジェクトを作成する
  2. このプロジェクト名を testOKE とし、デフォルト値を使う。Label Expressionにはk8sを指定しておく(以前の設定で利用したもの)その後、プロジェクトをビルドする。

    ビルド開始後、 jnlp-slave コンテナがJenkins Dashboardでプロビジョニングされる。
  3. 以下のコマンドを実行してステータスを確認する。
これで、Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) へのJenkinsエージェントのデプロイは完了です。

Extending the Deployment

以前のデプロイで、JenkinsマスターをVMとして実行し、Container Service for Kubernetes (OKE)上でJenkinsエージェント/スレーブをDockerコンテナとしてスケールアウトしました。JenkinsマスタをJenkinsスレーブのそばのKubernetesクラスタ内にデプロイすることで、このデプロイメントを拡張できます。この構成では、Jenkinsコンテナ(マスタとスレーブの両方)の耐障害性、サービス・レジリエンシ、リソース利用率が向上します。設定方法を見ていくことにしましょう。このデプロイメントは下図の設定に類似しています。

Prerequisites

  • Oracle Cloud InfrastructureにKubernetesクラスタが展開済みであること

Deployment

KubernetesにJenkinsマスタをデプロイする手順は以下のようです。
  1. Jenkins用のKubernetes manifestファイルを準備
  2. Oracle Cloud Infrastructure Block Volume上に、永続ボリュームとともにJenkinsマスタをデプロイ
  3. Jenkinsサービスをロードバランサを使って公開
  4. Jenkinsマスタを構成

Step 1: Prepare the Kubernetes Manifests for Jenkins

jenkins-master.yaml manifestファイルには、Jenkinsマスタをデプロイするための構成が含まれており、1個のレプリカを作成します。この設定では、最新のJenkinsイメージを使用し、Jenkinsのマスターコンテナにポート8080と50000を公開します。jenkins-dirボリュームマウントは、jenkins-master-pvcというPVCに関連付けられています。

jenkins-pvc.yamlファイルは、Oracle Cloud Infrastructureのブロックボリュームを含むPVCの設定で構成されています。ブロックボリュームとして50GB確保していますが、これは必要に応じてJenkinsビルドファイルやアーティファクトを格納するために使われます。

Step 2: Deploy to the Kubernetes Cluster

Store the manifestファイルをディレクトリ(例えばjenkins-k8s)に格納し、以下のコマンドを実行してPVCを使ってJenkinsマスタデプロイメントを作成します。

デプロイメントPodが作成されたことを確認します。


PVCが作成されたことを確認します。その際には以下のコマンドを実行するか、もしくはOracle Cloud InfrastructureコンソールのBlock Volumeの画面を使います。


Step 3: Expose the Deployment via a Load Balancer

デプロイメントを作成したら、サービスを作成し、そのサービスをOracle Cloud Infrastructureロードバランサを使って80/tcpで公開できます。(Jenkinsマスタはデフォルトでは8080/tcpをリスニングしているため)ターゲット・ポートとして8080/tcpを指定します。

Oracle Cloud Infrastructureコンソールでロードバランサがプロビジョニングされていることを確認できます。プロビジョニング後、リスナーとして80/tcpを使って、パブリックIPアドレスが公開されます。

サービスのパブリックIPアドレスを以下のコマンドを実行して確認できます。

Step 4: Configure the Jenkins Master

Step 3で入手したパブリックIPと80/tcpを使ってJenkinsダッシュボードにアクセスすると、以下のような画面が確認できるはずです。

以下のコマンドを実行してJenkinsのadminの初期パスワードを取得します。


この後、Jenkinsマスタの構成プロセスは以前のエントリに記述した内容に類似しています。
Deploy Jenkins on Oracle Cloud Infrastructure
https://blogs.oracle.com/cloud-infrastructure/deploy-jenkins-on-oracle-cloud-infrastructure
Jenkinsマスタを構成後、Kubernetesプラグインをインストールすれば、このエントリの最初に説明したようにJenkinsスレーブをスケールアウトできます。

Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)は、Jenkins Kubernetesプラグインとのシームレスに統合できます。Jenkins KubernetesプラグインでのOKEの設定は、他のKubernetesエンジンの設定に類似しています。OKEは安全で可用性の高いKubernetesクラスタを提供し、Oracle Cloud Infrastructureでコンテナ化されたアプリケーションを管理します。

[Linux, Cloud] New Oracle Linux KVM Image for Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/new-oracle-linux-kvm-image-for-oracle-cloud-infrastructure

仮想マシンの簡単な展開がほとんどのクラウドデプロイメントにとって重要なわけですが、Oracle Linux KVMイメージを使うと、oci-utilsを含むスクリプティングツールを使って、ブロックストレージや仮想ネットワークインターフェースなどのサービスと統合することにより、VMの展開が簡単になります。
oci-utils (oracle cloud infrastructure) for Oracle Linux package
https://blogs.oracle.com/wim/oci-utils-oracle-cloud-infrastructure-for-oracle-linux-package
これらのツールによって、VMゲストドメインを定義し、特定のブロックボリュームやVNICを割り当て、Oracle Cloud InfrastructureでのVMの起動や削除が簡単になります。先頃Oracle Linux KVM Image for Oracle Cloud Infrastructureをアップデートしました。以下のような機能強化がなされています。
  • oci-utilsスクリプトを使ったVNIC作成のサポート: oci-network-config --create-vnic
    VNIC作成の例:この例では、VNICを作成し、パブリックIPアドレスを割り当てています。
    $ sudo oci-network-config --create-vnic --vnic-name vnic-guest3 --assign-public-ip
  • oci-utilsスクリプトを使ったブロックボリューム作成のサポート: oci-iscsi-config --create-volume
    ブロックデバイス作成の例:この例では、100GBのボリュームを作成し、iSCSIデバイスをアタッチしています。
    $ sudo oci-iscsi-config --create-volume 100 --volume-name vol-guest3
  • Oracle Linuxネイティブのsystemd LSBネットワーキングを使ったVirtual Functionネットワークインターフェースの完全な構成(ifcfg ネットワーク構成ファイル)
  • oci-utils ver. 0.6へのアップデート
    oci-utils-0.6-34.el7
    https://blogs.oracle.com/wim/oci-utils-06-34el7
  • Oracle Linux 2018-05-08ベースイメージへのアップデート
Oracle Cloud Infrastructureの新しいKVMイメージをデプロイするには、下記ページにあるURLを使ってインポートし、カスタムイメージを使ってインスタンスを作成してください。
Oracle Linux KVM Image for Oracle Cloud
http://www.oracle.com/technetwork/server-storage/linux/technologies/ol-kvm-image-4466272.html
詳細は、以下のURLをご覧ください。

[Linux] Announcing the release of Oracle Linux 6 Update 10

原文はこちら。
https://blogs.oracle.com/linux/announcing-the-release-of-oracle-linux-6-update-10

i386およびx86_64向けOracle Linux 6 Update 10の一般提供を発表できうれしく思っています。個別のRPMパッケージをULN(Unbreakable Linux Network)、Oracle Linux Yumサーバからダウンロードできます。
Unbreakable Linux Network (ULN)
https://linux.oracle.com/
Oracle Linux Yum Server
https://yum.oracle.com/
ISOインストールイメージはOracle Software Delivery Cloudからダウンロードできます。
Oracle Software Delivery Cloud
http://edelivery.oracle.com/new
DockerイメージはOracle Container RegistryもしくはDocker Hubから利用できます。
Oracle Container Registry
https://container-registry.oracle.com/
Docker Hub
https://hub.docker.com/_/oraclelinux/
Oracle Linux 6 Update 10は以下のカーネルパッケージを同梱しています。
  • x86-64向け
    • Unbreakable Enterprise Kernel (UEK) Release 4 (kernel-uek-4.1.12-124.16.4.el6uek) for x86-64
    • Red Hat Compatible Kernel (kernel-2.6.32-754.el6)
  • i386向け
    • Unbreakable Enterprise Kernel (UEK) Release 2 (kernel-uek-2.6.39-400.294.3.el6uek) for i386
    • Red Hat Compatible Kernel (kernel-2.6.32-754.el6)
デフォルトでは、特定のアーキテクチャ(i386もしくはx86_64)のUEKならびにRHCKがインストールされ、システムはUEKを使ってブートします。

Application Compatibility

Oracle LinuxはRed Hat Enterprise Linux (RHEL)とのユーザー空間の互換性を保っており、これはOS以下のカーネルバージョンに依存しません。既存のユーザー空間のアプリケーションは、Oracle Linux 6 Update 10とUEK Release 4の組み合わせの上で、変更せずに引き続き動作します。すでにアプリケーションがRed Hat Enterprise Linux 6やOracle Linux 6での動作保証が済んでいる場合、再認証は必要ありません。

Notable updates in this release:

  • Retpoline Support Added to GCC
    このアップデートで、retpolines へのサポートをGNU Compiler Collection (GCC)に追加しました。カーネルはこのテクニックを使って、CVE-2017-5715で説明されているSpectre Variant 2攻撃を軽減するオーバーヘッドを削減します。
新機能や変更点の詳細は以下のリリースノートをご覧ください。
Oracle Linux Release Notes for Release 6 Update 10
https://docs.oracle.com/cd/E37670_01/E96232/html/index.html
Operating Systems Documentation
https://docs.oracle.com/en/operating-systems/linux.html
Oracle Linuxは無料でダウンロード、利用、配布できるとともに、全てのアップデートやエラータを無料でご利用いただけます。お客様が、どのシステムでサポート契約が必要なのかを決めてください。この結果、Oracle Linuxが開発、検証、本番システム用途に理想的な選択肢になるのです。
Oracle Linux Support
http://www.oracle.com/us/technologies/linux/support/overview/index.html
お客様がどのサポート範囲が個々のシステムに対して最適かを決定することもできますし、全てのシステムをアップデートして安全に保つこともできます。
Oracle Linux Premier Supportを契約のお客様は、追加Linuxプログラムのサポートも受け取ることができます。これにはOracle Linuxソフトウェアコレクション、Oracle OpenStack、Oracle Kspliceを使ってダウンタイム無しのカーネルアップデートが含まれます。

Oracle Linuxに関する詳細は、以下のURLをご覧ください。
Oracle Linux
http://www.oracle.com/linux

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

以下は個人的な見解です。そのため、お約束の文言を再度入れておきます。

このエントリは個人の見解であり、所属する会社の公式見解ではありません。
Opinions expressed in this blog entry is my personal one and does not represent the official opinion of my employer.

以前、以下のようなエントリを公開しました。
[Java] 新しいJavaリリースモデルについて
https://orablogs-jp.blogspot.com/2018/05/misunderstanding-new-java-release-model.html
そして、2018年6月20日に、JJUG主催で「緊急特集! Javaの無償版はなくならないぞ!」というナイトセミナーが開催されました。弊社伊藤( @itakash )からの発表で仕様したスライドは以下からどうぞ。


彼のTweetからでもアクセスできます。
そして、OTNにも記事が出ました。
JDKの新しいリリース・モデルおよび提供ライセンスについて
http://www.oracle.com/technetwork/jp/articles/java/ja-topics/jdk-release-model-4487660-ja.html
さすがに上記の記事やスライドをご覧いただくことで、「Oracleは今後有償のJDKのみをリリースする」という話は誤りであることを理解いただけると思います。

それでも信じられない人(?)やこだわり(??)、願望(???)を持つ方が多いようなので、今回のリリースモデル変更の要点を改めて記載しておきます。

Point

  • OpenJDKバイナリ(Oracleがビルドし配布、GPL+Classpath Exception)
    • 6ヵ月ごとにリリース(3月と9月)、6ヵ月過ぎるとEoL
    • 無償、コミュニティによるサポート
    • http://jdk.java.net/ で配布
    • セキュリティアップデートは6ヵ月の範囲で2回リリース(1、4、7、11月)
    • インストーラはない(Java 10のJDKはWindows、Linux、Macともtar.gz形式で提供、Java 11からはWindows用JDKはzip形式で提供)
    • Java 11からはJREは提供されず、自身の環境に合わせて jlinkを使って作成
  • Oracle JDK(OpenJDKベース、BCL)
    • 3年ごとにリリース(LTS / Long Term Support)
    • Java 11から開始
    • 有償サポート、サブスクリプションモデルとしてサポート契約可(日本での価格は未定)
      • Desktop $2.5/Processor/month
      • Server Side $25/Processor/month
    • サポートはOracle Lifetime Support Policyに従う。
      • Premier Support (5年)
      • Extended Support (3年)
      • Sustaining Support (無期限)
    • セキュリティアップデートは年4回リリース(1、4、7、11月)
    • インストーラあり
  • OpenJDKバイナリ、Oracle JDKに共通すること
    • JavaFXは同梱されない(利用するならOpenJFX)
なお、JDKのバイナリは当然ながら各社で異なります。つまり、OpenJDKベースであったとしても、Red Hatが配布するOpenJDKバイナリ(RHELに同梱されるもの)やAdoptOpenJDK、Zuluが配布するOpenJDKバイナリは、Oracleが配布するものとは異なりますので、ご注意を。

その他のリソース

[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