[Cloud, Linux] How to use Terraform with Oracle Linux and Oracle OpenStack 4.0

原文はこちら。
https://blogs.oracle.com/linux/how-to-use-terraform-with-oracle-linux-and-oracle-openstack-40

先日、Oracle Linux Developer CommunityにHow to use Terraform with Oracle Linux and Oracle Cloud Infrastructure (OCI)という記事を投稿しました。
How to use Terraform with Oracle Linux and Oracle Cloud Infrastructure (OCI)
https://community.oracle.com/docs/DOC-1019936
本日、Oracle Linux Developer CommunityにHow to use Terraform with Oracle Linux and Oracle OpenStack 4.0という記事を投稿しました。
How to use Terraform with Oracle Linux and Oracle OpenStack 4.0
https://community.oracle.com/docs/DOC-1022601
Infrastructure as a codeは関心のあるトピックであり、ol7_developer yumチャネルを使用してTerraformバイナリを簡単にインストールするなど、Oracle Linuxと協調します。Infrastructure as a codeは、データセンターのコンピューティングリソースを機械が読める定義ファイルを使ってプロビジョニングするというプロセスで、手作業によるシステム管理、対話型UI、コマンドラインといった、これまでのツールやテクニックを置き換えることができます。Terraformは、サポートされているパブリッククラウド内で利用されるハイレベルな構成言語で、APIを使いながら複雑なデータセンターのインフラストラクチャを定義することができるオープンソース・ソフトウェアです。

Oracle OpenStack 4.0の詳細情報は以下をご覧ください。
Oracle OpenStack 4.0
https://docs.oracle.com/cd/E90981_01/
TerraFormの詳細情報は以下をご覧ください。
Terraform
https://www.terraform.io/

[Linux] Development Versions of Oracle Linux UEK now available on GitHub

原文はこちら。
https://blogs.oracle.com/linuxkernel/development-versions-of-oracle-linux-uek-now-available-on-github

UEKのソースは、全てのgit履歴があるgitリポジトリとして、いつでもoss.oracle.comで入手できますが、UEKのソースをgithubに掲載するようになりました。これにより、私たちは作業の可視性を高め、人々がUEKのソースにアクセスしてもらいやすくすることを意図しています。
oss.oracle.com - linux-uek.git / tags
https://oss.oracle.com/git/gitweb.cgi?p=linux-uek.git;a=tags
Oracle Linux UEK: Unbreakable Enterprise Kernel
https://github.com/oracle/linux-uek/
また、パートナー企業やLinuxコミュニティの開発者との作業でもこのリポジトリを使用します。リポジトリには、メインラインのLinuxカーネルソースツリーでまだ受け入れられていない少数のOracleの追加コードを含む、Unbreakable Enterprise Kernelのソースが含まれています。

Unbreakable Enterprise Kernel(UEK)は、Oracleが構築し、Oracle Linuxサポートを通じてサポートされるLinuxカーネルです。メインラインのソースコードを可能な限り厳密に追随して、パフォーマンス、安定性、最小限のバックポートを重視しています。OracleのEngineered System、Oracle Cloud Infrastructure、およびOracleの顧客向けの大企業向けのデプロイメントのためにUEKは十分にテストされ、使用されています。

毎週の開発ビルドのソースをGitHubに掲載しています。このリポジトリからビルドするには、GitHub READMEファイルに示されている追加の依存関係が必要です。
Oracle Linux UEK: Unbreakable Enterprise Kernel
https://github.com/oracle/linux-uek
プロダクションビルドのソースはgitから引き続き入手可能です。
oss.oracle.com - linux-uek.git / tags
https://oss.oracle.com/git/gitweb.cgi?p=linux-uek.git;a=tags
KERNEL.ORG
のバージョン
リリース
ステータス
サポートする
Oracle Linux
バージョン
UEK Release 5: github uek5/master
https://github.com/oracle/linux-uek/tree/uek5/master
v4.14DevelopmentOracle Linux 7
UEK Release 4: github uek4/master
https://github.com/oracle/linux-uek/tree/uek4/master
v4.1ProductionOracle Linux 6
Oracle Linux 7
UEK Release 3: github uek3/master
https://github.com/oracle/linux-uek/tree/uek3/master
v3.8ProductionOracle Linux 5
Oracle Linux 6
Oracle Linux 7
UEK Release 2: github uek2/master
https://github.com/oracle/linux-uek/tree/uek2/master 
v3.0ProductionOracle Linux 5
Oracle Linux 6

Oracleは長年にわたりLinuxに貢献してきました。カーネルの変更をアップストリーム化してオープンソースにしておくことに常に重点を置いてきました。変更をオープンソースにしておくことで、アップストリームのLinuxカーネルとの迅速な統合が可能になり、自分たちが貢献した成果に加えて、最先端のドライバやファイルシステム、ハードウェアサポート、コミュニティからのセキュリティ修正が得られます。

2007年以来、オラクルは40万行以上のコードをLinuxに提供しており、Linuxのトップ15の常勤者に7,500以上のチェンジセットを提供する、Linuxにおけるトップ15に入るコントリビュータ―です。たとえば、Btrfs、OCFS2やRDSはもともとOracleで作成され、提出されました。また、XFS(メンテナーがOracleで働いています)とNFSにも大きな貢献をしています。

OracleのLinuxチームは、各アップストリーム・カーネル・リリースにおけるトップ10のコントリビュータです。 私たちの使命は、Linuxを改善すること、すなわち、より高い性能、より良いセキュリティ、より高度な診断能力を面での改善を意味します。また、OSの基本に焦点を当て、スケジューラとコアメモリの割り当てルーチンを改善しています。

Oracle Developer CommunityのOracle LinuxおよびUEKプレビュー・スペースで、質問をしたり、問題を報告したり、提案したりしてください。
Oracle Linux and UEK Preview
https://community.oracle.com/community/server_&_storage_systems/linux/oracle_linux_and_uek_preview
GitHub経由でプルリクエストを受け付けませんが、アップストリームコミットへのポインタは歓迎します。UEKソースはgithubに公開していますがサポートはありません。コンパイル済みバイナリおよびサポート対象のエンタープライズ・ディストリビューションの場合、Oracle Linuxは無料でダウンロード、配布、使用でき、以下から入手できます。
Oracle Linux Downloads
http://www.oracle.com/technetwork/server-storage/linux/downloads/index.html
個別のパッケージと更新は、Oracle Linux yumサーバからダウンロードできます。
Oracle Linux Yum Server
https://yum.oracle.com/

[Linux, Docker] Oracle Container Runtime for Docker on Oracle Linux for ARM64

原文はこちら。
https://blogs.oracle.com/linux/oracle-container-runtime-for-docker-on-oracle-linux-for-arm64

ARM64アーキテクチャ用のOracle Container Runtime for Dockerの提供を発表できうれしく思っています。インストールするには、以下のコマンドを実行してください。
yum install docker-engine
Docker Hubの公式Oracle Linuxイメージもアップデートされ、x86_64およびARM64アーキテクチャをサポートします。最新のOracle Linux 7ベースイメージをDocker HubからPullするには、以下のコマンドでOKです。
docker pull oraclelinux:7-slim
Dockerは自動的にアーキテクチャに対応した正しいイメージを取得します。Oracle Linux 7最小限のベースイメージを提供し、GitHubのDocker Imagesリポジトリに公開されているすべてのOracle製品イメージで使用されている7-slimタグを利用されることを推奨しますが、お好みであれば、latest、7、7.4タグも提供しています。
Official source for Docker configurations, images, and examples of Dockerfiles for Oracle products and projects
https://github.com/oracle/docker-images
REPOSITORY        TAG      IMAGE ID       CREATED     SIZE 
oraclelinux       7        b5e0e6470f16   2 hours ago 279MB 
oraclelinux       7.4      b5e0e6470f16   2 hours ago 279MB 
oraclelinux       latest   b5e0e6470f16   2 hours ago 279MB 
oraclelinux       7-slim   fdaeac435bbd   2 hours ago 146MB
ARM64で利用可能なOracle製品のイメージはまだないことにご注意ください。

Support

Oracle Linux for ARM64は開発者プレビューとして提供しており、Oracle Linux Supportの範囲外です。何か問題があれば、Oracle Technology Network (OTN) のOracle Linux for ARM64スペースで、コミュニティによるサポートを求めてください。
Oracle Linux for ARM64
https://community.oracle.com/community/server_&_storage_systems/linux/oracle-linux-for-arm64
Oracle Developer Community
https://community.oracle.com/welcome

[Cloud] Deploying Highly Available DC/OS on Oracle Cloud Infrastructure with Terraform

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/deploying-highly-available-dcos-on-oracle-cloud-infrastructure-with-terraform

Introduction

この記事では、Oracle Cloud InfrastructureにDC/OSを自動的にデプロイするためのTerraformテンプレートを紹介します。
Oracle Cloud Infrastructure
https://cloud.oracle.com/cloud-infrastructure
DC/OSは、Apache Mesos分散システムカーネルをベースにしたオープンソースの分散データセンターオペレーティングシステムです。単一のインタフェースから複数のシステムを管理し、これらのシステムにコンテナ、分散サービス、アプリケーションを展開することができます。

DC/OSは、クラスターを形成するマスター・ノードとエージェント・ノードのグループで構成されています。

Terraformテンプレートは、Oracle Cloud InfrastructureにこのDC/OSクラスタを自動的にデプロイします。テンプレートは、Terraformモジュールのセットと、Oracle Cloud Infrastructureで高可用性および構成可能なDC/OSクラスタを実行するために必要なリソースのプロビジョニングおよび構成に使用される基本構成の例で構成されています。

Oracle Cloud Infrastructure Environment

DC/OSクラスタをOracle Cloud Infrastructure内の任意のリージョンにデプロイできます。高可用性が必要な場合は、DC/OSマスタとエージェントノードをOracle Cloud Infrastructureのリージョンにある複数のアベイラビリティ・ドメインにデプロイすることを推奨します。

下図は、マスタ、パブリック・エージェント、GPUエージェント、通常のプライベートエージェントの各ノードを持つDC/OSクラスタのデプロイ例を示したものです。

Terraformテンプレートは、以下のComputeインスタンスをプロビジョニングします。
  • ブートストラップノード
  • マスターノード
  • パブリックエージェントノード
  • エージェントノード
  • GPUエージェントノード
テンプレートは、インスタンスシェイプ(GPUを含む)、これらのインスタンスの数、およびこれらのインスタンスの複数のアベイラビリティ・ドメインへの配置方法などを選択するための複数の入力変数を受け入れます。要件が基本構成を超えて拡張する場合、 関連モジュールをカスタマイズしてご自身の構成を形成することができます。

Deploy DC/OS Cluster

Prerequisites

Quick Start

  • 構成のカスタマイズ
    • プロジェクトルートにある、構成を指定するための "env-vars" ファイルを開く
    • テナント、ユーザー、コンパートメントに関連する、Oracle Cloud Infrastructureの必須入力変数を設定
      • Tenancy OCID
      • User OCID
      • API fingerprint
      • API private key
      • Compartment OCID
      • DC/OSインスタンスへSSHアクセスするための公開鍵・秘密鍵のペア
    • デフォルトの入力変数を確認し、必要に応じてアップデート
      • dcos_installer_url:   DC/OSコード入手のためのURL。デフォルト値は早期アクセスリリースに設定されているので、安定リリース(stable)に変更する場合は以下のURLを使う。https://downloads.dcos.io/dcos/stable/dcos_generate_config.sh
      • dcos_master_ad1_count、dcos_master_ad2_count、dcos_master_ad3_count:  各アベイラビリティ・ドメインにおけるマスタノードの個数
      • dcos_agent_ad1_count、dcos_agent_ad2_count、dcos_agent_ad3_count:  各アベイラビリティ・ドメインにおけるエージェント・ノードの個数
      • dcos_public_agent_ad1_count、dcos_public_agent_ad2_count、dcos_public_agent_ad3_count:  各アベイラビリティ・ドメインにおけるパブリック・エージェント・ノードの個数
      • dcos_gpu_agent_ad1_count、dcos_gpu_agent_ad2_count、dcos_gpu_agent_ad3_count:  各アベイラビリティ・ドメインにおけるGPUエージェントの個数
  • 環境変数を設定
    . env-vars 
  • Terraformの初期化
    terraform init
  • 実際の実行前にTerraformの実行計画を確認
    terraform plan
  • DC/OSリソースをプロビジョニングし、DC/OSクラスタをOracle Cloud Infrastructureにセットアップ
    terraform apply
リソースのプロビジョニングが完了すると、Terraformテンプレートは以下のような出力を表示します。
Outputs:

master_private_ips = [
  xx.xx.xx.xx,
  xx.xx.xx.xx,
  xx.xx.xx.xx
]

master_public_ips = [
  xx.xx.xx.xx,
  xx.xx.xx.xx,
  xx.xx.xx.xx,
]

Notes:

エージェント、パブリックエージェント、およびGPUエージェントの各ノードのデプロイは、ブートストラップノードのデプロイによって変わりますが、Terraformモジュールを使えば、Terraform "resources" の依存関係で通常実施しているように、依存関係を明示的に設定する仕組みはありません。depends_onというキーワードは、Terraformモジュールでは機能しません。この問題を回避するために、変数を使用して暗黙の依存関係を使用します。
例えば、モジュール "dcos_agent_ad1"において、モジュール "dcos_bootstrap"の "dcos_bootstrap"インスタンスIDの生成に依存する変数 "dcos_bootstrap_instance_id"を定義します。
module  "dcos_agent_ad1" {
    source              = "./instances/agent"
    count               = "${var.dcos_agent_ad1_count}"
    availability_domain = "${lookup(data.oci_identity_availability_domains.ADs.availability_domains[0],"name")}"
    compartment_ocid    = "${var.compartment_ocid}"
    tenancy_ocid        = "${var.compartment_ocid}"
    dcos_cluster_name   = "${var.dcos_cluster_name}"
    image               = "${var.InstanceImageOCID[var.region]}"
    shape               = "${var.AgentInstanceShape}"
    subnet_id           = "${module.vcn.subnet_ad1_id}"
    ssh_public_key      = "${var.ssh_public_key}"
    ssh_private_key     = "${var.ssh_private_key}"
    display_name_prefix = "ad1"
    dcos_bootstrap_instance_id = "${module.dcos_bootstrap.instance_id}"
}

Access DC/OS Cluster

Once the DC/OSのデプロイが完了したら、DC/OSダッシュボードにhttp://<master_public_ip>/からアクセスできます。

Next Steps

入力変数を使用して、エージェント、パブリックエージェント、GPUエージェントの各ノードの数を拡大または縮小できます。たとえば、次のようにエージェントノードの数を増やすことができます。
terraform apply -var "dcos_agent_id1_count=xx"

Conclusion

Oracle Cloud Infrastructureは、DC/OSとそのサービスを実行するための高性能で柔軟な環境を提供します。このTerraform DC/OSインストーラを使用すると、OCI上へのDC/OSクラスタのデプロイを自動化できます。

[Cloud] Announcing Terraform support for Oracle Cloud Platform Services

原文はこちら。
https://blogs.oracle.com/developers/announcing-terraform-support-for-oracle-cloud-platform-services

OracleとHashiCorpは、Oracle Cloud Platform Terraformプロバイダがご利用いただけるようになったことを発表します。
Oracle Cloud Platform Terraform Provider
https://www.terraform.io/docs/providers/oraclepaas
The initial release of the Oracle Cloud Platform Terraform providerの初期リリースでは、Oracle Database Cloud ServiceとOracle Java Cloud Serviceインスタンスの作成ならびにライフサイクル管理をサポートします。
Oracle Database Cloud Service
https://cloud.oracle.com/ja_JP/database/enterprise/features
Oracle Java Cloud Service
https://cloud.oracle.com/ja_JP/java
Oracle Cloud Platformのサポートにより、Terraformのinfrastructure-as-code構成をスタンドアロンOracle PaaSの展開のために定義したり、完全なインフラストラクチャおよびアプリケーションのデプロイのために、OPCプロバイダやOCIプロバイダがサポートするOracle Cloud InfrastructureおよびInfrastructure Classicと組み合わせることができます。

Supported PaaS Services

初期段階では、Oracle Cloud Platform (PaaS) Terraformプロバイダは以下のOracle Cloud Platformサービスをサポートしています。今後サービスやリソースを追加拡充していく予定です。
  • Oracle Database Cloud Service Instances
  • Oracle Database Cloud Service Access Rules
  • Oracle Java Cloud Service Instances
  • Oracle Java Service Access Rules

Using the Oracle Cloud Platform Terraform provider

Terraformを使用してOracle Cloud Platformサービスをプロビジョニングする例として、1個のJava Cloud Serviceインスタンスと依存関係にあるDatabase Cloud Serviceのインスタンスを展開する例をご紹介します。
まず、プロバイダの定義を宣言し、アカウント資格情報と適切なサービスREST APIエンドポイントを設定します。アイデンティティ・ドメイン名、アイデンティティ・サービスIDおよびRESTエンドポイントURLは、マイ・サービス・ダッシュボードの「サービスの詳細」セクションにあります。
My Services Dashboard
https://myservices.us.oraclecloud.com/mycloud/cloudportal/dashboard
IDCS Cloudアカウントの場合、identity_domainには、アイデンティティ・サービスIDを使います。
provider "oraclepaas" {
  user              = "example@user.com"
  password          = "Pa55_Word"
  identity_domain   = "idcs-5bb188b5460045f3943c57b783db7ffa"  
  database_endpoint = "https://dbaas.oraclecloud.com"
  java_endpoint     = "https://jaas.oraclecloud.com"
}
Traditionalアカウントの場合、identity_domainにはアイデンティティドメイン名を使います。
provider "oraclepaas" {
  user              = "example@user.com"
  password          = "Pa55_Word"
  identity_domain   = "mydomain"
  database_endpoint = "https://dbaas.oraclecloud.com"
  java_endpoint     = "https://jaas.oraclecloud.com"
}

Database Service Instance configuration

oraclepaas_database_service_instanceリソースを使って、Oracle Database Cloud Serviceインスタンスを定義します。単一のテラフォーム・データベース・サービス・リソース定義で、単一インスタンスのOracle Database Standard Editionデプロイメントから、高可用性と災害復旧のためのRACおよびData Guardを備えた完全なマルチノードのOracle Database Enterprise Editionまでの構成を表現できます。
別のDatabase Serviceインスタンスのバックアップまたはスナップショットからインスタンスを作成することもできます(訳注:原文では Instances can also be created for backups or snapshots... と記載されていますが、このforはおそらくfromの間違いと思われます。そのためfromに読み替えています)。この例では、後で構成するJava Cloud Serviceで使用するための新しいシングルインスタンスのデータベースを作成します。
resource "oraclepaas_database_service_instance" "database" {
  name        = "my-terraformed-database"
  description = "Created by Terraform"

  edition           = "EE"
  version           = "12.2.0.1"    
  subscription_type = "HOURLY"
  shape             = "oc1m"

  ssh_public_key = "${file("~/.ssh/id_rsa.pub")}"

  database_configuration {
    admin_password     = "Pa55_Word"
    backup_destination = "BOTH"
    sid                = "ORCL"
    usable_storage     = 25
  }

  backups {
    cloud_storage_container = "Storage-${var.domain}/my-terraformed-database-backup"
    cloud_storage_username  = "${var.user}"
    cloud_storage_password  = "${var.password}"
    create_if_missing       = true
  }
}
構成設定を少々詳しくみていきましょう。この例では、これがoc1m(1 OCPU/15GB RAM)シェイプのOracle Database 12cリリース2(12.2.0.1)Enterprise Editionインスタンスで、時間単位課金であることを宣言しています。
edition           = "EE"
version           = "12.2.0.1"    
subscription_type = "HOURLY"
shape             = "oc1m"
ssh_public_keyは、SSHアクセスを許可するためにインスタンスにプロビジョニングされる公開鍵です。

database_configurationブロックは、データベースSID、初期パスワード、およびデータベースの初期使用可能ブロックボリューム記憶域を含む、Database Cloud Serviceで作成される実際のデータベースインスタンスの初期設定を設定します。
database_configuration {
  admin_password     = "Pa55_Word"
  backup_destination = "BOTH"
  sid                = "ORCL"
  usable_storage     = 25
}
backup_destinationは、バックアップ先(Object Storage Servive(OSS)、オブジェクトストレージとローカルストレージの両方(BOTH)、または無効(NONE))を設定します。Java Cloud Serviceインスタンスと組み合わせて使用するデータベースインスタンスには、OSSまたはBOTHのバックアップ先が必要です。
Object Storage Serviceの場所とアクセス資格情報は、backupsブロックで設定します。
backups {
  cloud_storage_container = "Storage-${var.domain}/my-terraformed-database-backup"
  cloud_storage_username  = "${var.user}"
  cloud_storage_password  = "${var.password}"
  create_if_missing       = true
}

Java Cloud Service Instance

oraclepaas_java_service_instanceリソースを使って、Oracle Java Cloud Serviceインスタンスを定義します。1つのTerraformリソース定義で、Oracle WebLogic Serverの単一インスタンスのデプロイメントから、Oracle CoherenceデータグリッドクラスタおよびOracle Traffic Directorロードバランサを使用する完全なマルチノードOracle WebLogicクラスタまでの構成を表現できます。
別のJava Cloud Serviceインスタンスのスナップショットからインスタンスを作成することもできます。この例では、新たに2ノードのWebLogic Serverクラスタ(ロードバランサ付き)を作成し、先ほど作成したDatabase Cloud Serviceインスタンスに関連付けます。
resource "oraclepaas_java_service_instance" "jcs" {
  name        = "my-terraformed-java-service"
  description = "Created by Terraform"

  edition              = "EE"
  service_version      = "12cRelease212"
  metering_frequency   = "HOURLY"
  enable_admin_console = true

  ssh_public_key = "${file("~/.ssh/id_rsa.pub")}"

  weblogic_server {
    shape = "oc1m"

    managed_servers {
      server_count = 2
    }    

    admin {
      username = "weblogic"
      password = "Weblogic_1"
    }

    database {
      name     = "${oraclepaas_database_service_instance.database.name}"
      username = "sys"
      password = "${oraclepaas_database_service_instance.database.database_configuration.0.admin_password}"
    }
  }

  oracle_traffic_director {
    shape = "oc1m"
    listener {
      port         = 8080
      secured_port = 8081
    }
  }

  backups {
    cloud_storage_container = "Storage-${var.domain}/my-terraformed-java-service-backup"
    auto_generate           = true
  }
}
細かくみていきましょう。ここでは、これが12c Release 2 (12.2.1.2) Enterprise Edition Java Cloud Serviceのインスタンスで、時間単位の課金ルールを利用すると宣言しています。
edition              = "EE"
  service_version      = "12cRelease212"
  metering_frequency   = "HOURLY"
ssh_public_keyは、ここでもSSHアクセスを許可するためにインスタンスにプロビジョニングされる公開鍵です。
weblogic_serverブロックでは、このJava Cloud ServiceインスタンスにデプロイされたWebLogic Serverインスタンスの構成の詳細を提供します。 weblogic_server定義は、インスタンス・シェイプを設定します。この場合、oc1m(1 OCPU/15GB RAM)です。
adminブロックでは、WebLogic Serverの管理者ユーザーと初期パスワードを設定します。
admin {
    username = "weblogic"
    password = "Weblogic_1"
  }
databaseブロックでは、すでに上で定義したDatabase ServiceインスタンスにWebLogic Serverを接続します。この例では、Database Cloud ServiceインスタンスとJava Cloud Serviceインスタンスが同じ構成で宣言されていると仮定しているので、データベース構成値を取得できます。
database {
    name     = "${oraclepaas_database_service_instance.database.name}"
    username = "sys"
    password = "${oraclepaas_database_service_instance.database.database_configuration.0.admin_password}"
  }
The oracle_traffic_director ブロックでは、ロードバランサを構成してトラフィックをWebLogic Serverの管理対象サーバインスタンスに流すようにします。
oracle_traffic_director {
    shape = "oc1m"
    listener {
      port         = 8080
      secured_port = 8081
    }
  }
デフォルトでは、ロードバランサはweblogic_serverブロックで定義された同じ管理者資格情報で設定されますが、必要に応じて異なる資格情報を設定することもできます。安全でないポートが設定されていない場合、secured_portだけが有効になります。

最後に、Database Cloud Serviceインスタンスの設定と同様に、backupsブロックで、Java Cloud ServiceインスタンスのバックアップのObject Storage Serviceの場所を設定します。
backups {
    cloud_storage_container = "Storage-${var.domain}/-backup"
    auto_generate           = true
  }

Provisioning

プロバイダとterraformプロジェクトで構成されたリソース定義(例えば、全てがmain.tfファイルに入っている)を使うと、上記構成の展開は簡単ですにプロバイダとリソース定義が設定されているので、上記の設定を展開するのは簡単です。
$ terraform init
$ terraform apply
terraform initコマンドは、oraclepaasプロバイダの最新バージョンを自動的に取得します。terraform applyコマンドでプロビジョニングを開始します。Database CloudおよびJava Cloudインスタンスの完全なプロビジョニングは長時間にわたることがあります。プロビジョニングインスタンスを削除するには、terraform destroyを使います。


Related Content

Terraform Provider for Oracle Cloud Platform
https://www.terraform.io/docs/providers/oraclepaas
Terraform Provider for Oracle Cloud Infrastructure
https://github.com/oracle/terraform-provider-oci
Terraform Provider for Oracle Cloud Infrastructure Classic
https://www.terraform.io/docs/providers/opc/

[Linux] Tracing Linux Networking with DTrace on Oracle Linux

原文はこちら
https://blogs.oracle.com/linuxkernel/tracing-linux-networking-with-dtrace-on-oracle-linux

Alan Maguireのこの記事では、DTraceを使用した一般的なネットワーク関連のシステムコールを調査方法を紹介します。DTraceは、ユーザーおよびカーネルプロセスを理解するための強力なトレースツールです。

私たちは、DTraceのOracle Linuxのネットワーキングに対するサポートは着実に追加されています。これらのプローブを使ってネットワークの動作をよりよく理解する方法を見ていきましょう。ネットワークスタックの動的トレースでどのようなサポートが利用できるかを簡単に見てみましょう。
しかし、詳細を知る前に、なぜDTraceを使うのがいいのでしょうか。ネットワークの領域で十分なツールがあるのではないでしょうか。私がDTraceを使用する理由は次のとおりです。
  • DTraceは実稼動環境で安全でありつつ、制約がありません。つまり、何かを見つけたいのであれば、通常はそれを行う方法があります。最も重要なのは、システムがパニックを起こさずに実行できることです。当然のことながら、その困難な部分が、これらの質問からDTraceが理解する問い合わせになっています。私は、次回以後のエントリでそうする方法についていくつかの有用なヒントを提供できると思っています。
  • DTraceを使用すると、複数のサブシステムにアクセスできます。例えば、以下のような情報を取得できます。
    • パケットを受信するときに割り込みをどれぐらい効率的に合体させているのか
    • どのロックがネットワーク受信パスでホットな状態なのか
    特にクラウド環境では、ネットワークの振る舞いから他のサブシステムや抽象に結びつけて全体像を作り上げることが不可欠です。人々は "ネットワーク"を責めたがりますが、DTraceを使用すると、コストが本当にどこで発生しているかを確認できます。

Socket layer: syscall provider - available since UEK2

他のオペレーティングシステムと同様に、syscallプロバイダも利用でき、ネットワーク関連のシステムコール(sendto、sendmsg、sendmmsg、recvfrom、recvmsg、recvmmsg)をトレースできます。
以下は、実行可能な単位で送信されるバイトトレースの簡単な例です。情報を収集したら、Ctrl+Cキーを押します。
# dtrace -n 'syscall::sendto:entry { @c[execname] = sum(arg2); }'
dtrace: description 'syscall::sendto:entry ' matched 1 probe
^C
  
  DNS Resolver #6                                                  65
  ping                                                            192
  Socket Thread                                                  2006
  vpnagentd                                                      3872
これがDTraceのone-linerです。一つずつ見ていきましょう。
  • -nオプションは、DTraceスクリプトを使用するのではなく、プローブを直接指定していることを示しています(DTraceスクリプトを使用するには、 "dtrace -s <scriptname>"を使用します)。
  • プローブは4要素を記述し、各要素は ":"で区切ります。最初の要素は、私たちが使用しているDTraceサブシステムのプロバイダです。今回の場合、syscall(システムコール)です。もう1つはモジュールです。これは他のDTraceプロバイダには関係しますが、ここでは使用できません(Linuxでは常に "vmlinux"ですので空白にしておきます)。 3番目は関数です - システムコールプロバイダの場合はシステムコール名です。最後にプローブ名です。システムコールごとに、システムコールの要求/完了に対応するエントリとリターンの2つのプローブがあります。
  • 次は、中括弧に含まれるアクションです。DTraceコードは、"probe/predicate/{action}"の形式をとります。この場合、述語はありませんが、もし述語がある場合、ボディが実行されたか否かを判断します。続いてアクションを説明します。
  • ここでは、集計変数 "c"を使用しています。集計は "@"記号で表されています。アグリゲーションでは、角括弧の間に複数のキーを指定でき、sum()、count()、avg()などのいずれかの集計関数を使用して、さまざまなキーセットに関連付けられた値を計算します。アグリゲーションは効率的にカーネル内で収集されます。この例では、sendto()の3個目の引数であるarg2のSummationを取得しています。マニュアルを見ればarg2のサイズがわかります。
まとめると、one-linerでは「システムコールsendto()経由で送信されたバイト数の合計を表示し、各プログラム名での合計を収集」しています(execnameは組み込み済みの変数で、現在のプロセス実行可能ファイル名を表す)。
もちろん、これらはリクエストであり、失敗するものもあります。 再度使用したプローブはsyscall::sendto:entryでした。対応するsyscall::sendto:returnもあります。DTraceの一般的なパターンは、:entryから:returnまでの時間を測定します。

Layer 4 (Transport layer): TCP, UDP providers - available since UEK4QU5

Linuxの場合(Solarisでも同様です)、TCPやUDPのトランスポートレベル・プロバイダがあります。これらは送受信イベントをトレースし、TCPについてはTCPステートマシン遷移と接続確立マイルストンもトレースします。
# dtrace -l -P udp
   ID   PROVIDER            MODULE                          FUNCTION NAME
 1836        udp           vmlinux                      udp_send_skb send
 1838        udp           vmlinux                       udp_recvmsg receive
 1840        udp           vmlinux                 udp_queue_rcv_skb receive
 1868        udp           vmlinux                   udp_v6_send_skb send
 1869        udp           vmlinux                     udpv6_recvmsg receive
 1871        udp           vmlinux               udpv6_queue_rcv_skb receive
  
# dtrace -l -P tcp
   ID   PROVIDER            MODULE                          FUNCTION NAME
 1818        tcp           vmlinux                     tcp_set_state state-change
 1819        tcp           vmlinux                  tcp_conn_request state-change
 1820        tcp           vmlinux                tcp_finish_connect connect-established
 1821        tcp           vmlinux             tcp_rcv_state_process accept-established
 1822        tcp           vmlinux             tcp_rcv_state_process connect-refused
 1823        tcp           vmlinux                  tcp_transmit_skb send
 1824        tcp           vmlinux                  tcp_transmit_skb connect-request
 1825        tcp           vmlinux                       tcp_connect state-change
 1826        tcp           vmlinux                   tcp_v4_send_ack send
 1827        tcp           vmlinux                 tcp_v4_send_reset send
 1828        tcp           vmlinux                 tcp_v4_send_reset accept-refused
 1829        tcp           vmlinux                tcp_v4_send_synack send
 1830        tcp           vmlinux                        tcp_v4_rcv receive
 1831        tcp           vmlinux                     tcp_time_wait state-change
 1882        tcp           vmlinux              tcp_v6_send_response send
 1883        tcp           vmlinux              tcp_v6_send_response accept-refused
 1884        tcp           vmlinux                tcp_v6_send_synack send
 1885        tcp           vmlinux                        tcp_v6_rcv receive
以下は、どのシステム(リモートIP)への接続を拒否しているのか、どのポートに接続しようとしているのか、という例です。
# dtrace -n 'tcp:::accept-refused { @c[args[2]->ip_daddr, args[4]->tcp_sport] = count(); }'
dtrace: description 'tcp:::accept-refused ' matched 2 probes
^C
  
  127.0.0.1                                              7                1
この例を生成するために、別のウィンドウでポート7に対しローカルにtelnetで接続しました。ポート7は閉じられているため、1つの接続が拒否されています。TCP、UDP、およびIPプロバイダーはすべて静的定義トレース(SDT)プロバイダーです。これらの考え方は、絶えず変化する機能のエントリやリターンに位置するプローブを作成して変化するデータ構造から情報を収集しようとするのではなく、関心のあるイベントや、これらのイベントが発生するコードの各ポイントを定義して、静的プローブを配置します。たとえば、tcp:::sendプローブがtcp_v4_send_reset、tcp_v4_send_ackなどにあることがわかります。重要なのは、これらのプローブは、OS固有の構造をとり、DTraceコンシューマが信頼できる安定した引数に変換する安定したトランスレータを定義します。 Oracle Linuxの関連する定義を参照するには、/usr/lib64/dtrace/4.1/tcp.d、udp.d、ip.dを参照してください。

ほとんどの場合、Solarisとの互換性は維持されています、本当に必要なのが見つからない場合はお知らせください。様々な引数がどのように見えるかご紹介しましょう。arg0ではなくargs[0]を使って、安定した、変換済み引数へアクセスしようとしていることをDTraceに知らせています。素の引数はarg0、arg1などを使って引き続き利用できます。
args[0] - pktinfo_t * [packet information]
args[1] - csinfo_t * [ connection information]
args[2] - ipinfo_t * [IP protocol information]
args[3] - tcpsinfo_t * for TCP, udpsinfo_t * for UDP [TCP/UDP state information]
args[4] - tcpinfo_t * for TCP, udpinfo_t * for UDP [TCP/UDP header information]

Layer 3 (IP provider) - available since UEK4QU4


IPプロバイダは送信、受信、インバウンド/アウトバウンドのパケットドロップをトレースします。
 # dtrace -l -P ip
   ID   PROVIDER            MODULE                          FUNCTION NAME
 1839         ip           vmlinux                     ip_rcv_finish drop-in
 1840         ip           vmlinux                  ip_local_deliver receive
 1841         ip           vmlinux                            ip_rcv drop-in
 1842         ip           vmlinux                  __ip_append_data drop-out
 1843         ip           vmlinux                 __ip_local_out_sk send
 1844         ip           vmlinux                    ip_append_page drop-out
 1845         ip           vmlinux                       ip_send_skb drop-out
 1861         ip           vmlinux                       raw_sendmsg send
 1878         ip           vmlinux        __ip6_flush_pending_frames drop-out
 1879         ip           vmlinux                          ip6_xmit send
 1880         ip           vmlinux                          ip6_xmit drop-out
 1881         ip           vmlinux                ip6_finish_output2 drop-out
 1882         ip           vmlinux                 __ip6_append_data drop-out
 1883         ip           vmlinux                       ip6_forward drop-out
 1884         ip           vmlinux                        ip6_output drop-out
 1885         ip           vmlinux                      ip6_send_skb drop-out
 1886         ip           vmlinux                  ip6_input_finish drop-in
 1887         ip           vmlinux                          ipv6_rcv drop-in
 1888         ip           vmlinux                         ip6_input receive
 1895         ip           vmlinux                    ndisc_send_skb send
 1900         ip           vmlinux                     rawv6_sendmsg send
 1903         ip           vmlinux                      mld_sendpack send
 1904         ip           vmlinux                      mld_sendpack drop-out
 1905         ip           vmlinux                        igmp6_send send
 1906         ip           vmlinux                        igmp6_send drop-out
 1923         ip           vmlinux                __ip6_local_out_sk send
IPプロバイダにおける引数は以下のようです。
args[0] - pktinfo_t * [packet information]
args[1] - csinfo_t * [connection information]
args[2] - ipinfo_t * [IP protocol information]
args[3] - ifinfo_t * [IP interface info]
args[4] - ipv4info_t * [IPv6 header info if IPv6 packet]
args[5] - ipv6info_t * [IPv6 header info if IPv6 packet]

Other

Oracle LinuxのDTraceには、perfイベントをトレースするperfプロバイダが含まれています。もちろん、関数境界トレース(fbt)も利用できます。以下は、関数境界トレースを使用してソケットバッファ(struct sk_buff)の割り当てサイズを取得する例です。sk_buffはネットワークデータのキー構造です。ここでは、2のべき乗のバケット(0-1、1-2、2-4など)に入る個数を調べています。これはquantize()という集約アクションです。例えば、大多数が2048〜4096の範囲にあったことがわかります。
# dtrace -n 'fbt::__alloc_skb:entry { @size = quantize(arg0); }'
dtrace: description 'fbt::__alloc_skb:entry ' matched 1 probe
^C
           value  ------------- Distribution ------------- count   
              -1 |                                         0       
               0 |                                         80      
               1 |                                         3       
               2 |                                         0       
               4 |                                         137     
               8 |                                         988     
              16 |@@                                       5719    
              32 |@@@@@                                    10977   
              64 |                                         779     
             128 |@@@                                      6805    
             256 |@@@@@@@@@@@                              25462   
             512 |                                         508     
            1024 |@@                                       5108    
            2048 |@@@@@@@@@@@@@@@@                         39011   
            4096 |                                         8       
            8192 |                                         0       
           16384 |                                         16      
           32768 |                                         0
将来のエントリで、fbtプロバイダやperfプロバイダを使った例を説明する予定にしています。

[Linux] btrfs Development: Year in Review

原文はこちら
https://blogs.oracle.com/linuxkernel/btrfs-development%3a-year-in-review

このbtrfs開発のアップデートはLiu Bo(Oracle Linux Kernel開発者であり、主要なアップストリームbtrfsコントリビュータ)によるものです。

btrfsコミュニティは引き続き繁栄しています。2017年、btrfsには富士通、Facebook、Oracle、SuSEの主要開発者といくつかのNAS企業の貢献がありました。btrfsの主な使用例は2つのカテゴリに分類されます、 すなわち、'/'と '/ home'のための1個のディスクでのbtrfsの利用と、NASタイプのワークロードのための複数のディスクでのbtrfsの利用です。

過去1年間で、btrfsを安定させることを最優先課題とし、 "btrfs: fix ..."で始まる117個のコミットがありますので、基本的に全ての領域でbtrfsを修正しています。

BTRFSの主な特長は以下の通りです。
  • Linux kernel v4.13
    新しい圧縮アルゴリズム 'zstd'がbtrfsに導入されました。これはlzoと同じくらい速く、zlibと同等の圧縮率を提供します。ベンチマークの詳細は「btrfs: Add zstd support」で入手できます。
    btrfs: Add zstd support
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c1aab1dd5445ed8bdcdbb575abc1b0d7ee5b2e7
  • Linux kernel v4.14
    圧縮ヒューリスティックサポートがbtrfsに導入されました。圧縮前にデータにいくつかのヒューリスティックを適用して、スペースを節約できるかどうかを判断できます。
  • Linux kernel v4.15
    内部の遅延参照に対するデバッグ機能を提供するため、新しいマウントオプションref-verifyと新しいconfig CONFIG_BTRFS_FS_REF_VERIFYが追加されました。
  • 将来的には、ホットスペア、DAXによる永続メモリのサポート、RAID 56ジャーナル(ライトホールを塞ぐため)、iomapインフラストラクチャへの変換の作業を継続する予定です。これらの作業すべてにはすでに少なくともRFCパッチがありますので、メーリングリストで上がっている懸念やフィードバックに対処するために、それらを改訂し改善する必要があります。
これらの特長に加え、不具合も修正してきました。
  • ENOSPC : チケット予約メカニズムをbtrfsが採用した後でさえも、初期のno spaceエラーが発見されており、改善のための修正が行われてきました。問題はほぼすべてがbtrfsファイルシステムでのみ発生します。この変更により、ファイルシステムのサイズが増えても全体のパフォーマンスが向上します。
  • send : btrfs sendは、インクリメンタルアップデートをサポートするためによく使われており、いくつかのNASソリューションに統合されていますが、rmdirを送信する際の誤った動作や、NO_HOLE機能とインライン・エクステントが協調する際のその他の不具合を発見し、修正しました。
  • (オフライン重複排除のための)backref巡回(backref walking): オフライン重複排除は、多数の共有エクステントを生成する可能性があります。これにより、複数のファイル(または同じファイル内でも)が共有されるかどうかをチェックする際にFIEMAPを使用するツールが遅くなることがあります。これらの変更により、メモリ内のbackrefは、リストではなくrb-treeに格納されるようになりました。これにより、挿入マージが可能になり、共有エクステントを簡単に発見し、backrefを挿入しながら即座に返すことができるようになりました。
  • raid6 とスクラブ(scrub) :  btrfsのマウントを妨げるraid6再構成プロセスにある不具合を確認しました。アップストリームとstableカーネルの両方で修正を提供済みです。さらに、コミュニティはraid6でのスクラブのサポートで不具合を見つけて修正しました。この不具合は、特定のデータストライプで誤ったパリティを引き起こす可能性があります。
上記に加えて、btrfs-progsをpythonライブラリ(libbtrfsutil)として書き換え、ライセンスをGPLからLGPLに変更するというbtrfs-progsへの変更提案もあります。このライセンスの変更により、単体テストやサードパーティのツールとの統合が容易になることでしょう。
これは、btrfsの多くの優れた機能のちょっとした例です。btrfsの現在の機能を引き続き改善していきます。