[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