[Identity Management] IDCS Users Can Now Use the Oracle Cloud Infrastructure SDK and CLI

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/idcs-users-can-now-use-the-oracle-cloud-infrastructure-sdk-and-cli

Oracle Identity Cloud Serviceを使用したフェデレーション機能の強化を発表します。本日から利用可能で、IDCSとフェデレーションされているユーザーは、Oracle Cloud Infrastructure SDKおよびCLIに直接アクセスできます。

この機能拡張は、ガバナンスと管理タスクの簡素化を含む、幅広いユースケースをサポートするもので、すべてのCLIアクセスにIDCSユーザーを使用できるようになりました。例えば、IDCSユーザーはスクリプトを使用して、CLIを使用して共通タスクを自動化するだけでなく、OCIのタスクを他のインフラストラクチャ・ツールやシステムと統合することもできますし、ファイルをObject Storageにコピーするスクリプトを作成したい場合、IDCSユーザーを使えるようになりました。もうOracle Cloud Infrastructureのユーザーを作る必要はありません。この結果、保護、管理対象のユーザーの個数を劇的に削減できます。

フェデレーションを使用すると、ID管理ソフトウェアを使用してユーザーとグループを管理できます。2017年12月以降に作成されたすべてのテナントには自動的にIDCSとのフェデレーションが構成されています。これはつまり、現在のユーザーがIDCSユーザーの場合、Oracle Cloud ApplicationおよびOracle Cloud Infrastructureを含むすべてのOracle Cloudソリューションにわたって同じ資格証明セットを活用できる、ということです。さらに、Oracle Cloud InfrastructureグループにマップされたIDCSグループのメンバーであるすべてのユーザーは、IDCSからOracle Cloud Infrastructureに同期されます。この同期により、どのIDCSユーザーがOracle Cloud Infrastructureにアクセスできるのかを管理できると共に、全てのユーザー管理をIDCSに統合できます。この新機能を活用するには、以下のドキュメントに記載の設定手順に従って構成する必要があります。
Upgrading Your Oracle Identity Cloud Service Federation
https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/usingscim.htm#Oracle
続いて、この機能のおかげで劇的に簡素化される、コスト管理のシナリオをご紹介します。SDKを使って、CostCenterというコストトラッキングタグを持たないComputeインスタンスを発見し、停止するというPythonスクリプトを実行したい、としましょう。Oracle Cloud Infrastructureのローカルユーザーを作成するのではなく、IDCSのユーザーを設定してこのスクリプトを実行できます。このシナリオは以下の手順で実行できます。

Step 1: Ensure that your federation has been upgraded

前提となる設定をまだ実施していない場合は、以下のドキュメントの記載に従って実施してください。
Upgrading Your Oracle Identity Cloud Service Federation
https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/usingscim.htm#Oracle

Step 2: Set up the user in IDCS and associate that user with the correct groups

Identity Providerからすべてのユーザを管理するのは、ユーザIDを管理する上でよりスケーラブルで、管理しやすく、安全な方法です。最低特権の原則に従い、IDCSユーザーを作成し、そのユーザーは、自身の作業を行う上で最低限必要なIDCSグループにのみ関連付けてください。

Step 3: Set up the Oracle Cloud Infrastructure group

このタスクに使用されるローカルのOracle Cloud Infrastructureグループを作成し、作業に必要なアクセス制御のみを可能にするポリシーがあることを確認します。必要な管理者(たとえば、Computeインスタンス管理者)のタイプに特化したグループを設定するようにしてください。きめ細かいグループおよびアクセス・ポリシーの設定に関するベスト・プラクティスの詳細は、以下のホワイトペーパーをご覧ください。なお、マッピング時にグループを作成することもできます。
Oracle Cloud Infrastructure Security
https://cloud.oracle.com/iaas/whitepapers/oci_security.pdf

Step 4: Map the IDCS group to the Oracle Cloud Infrastructure group

以下のドキュメントの記述に従ってグループおよびユーザーを追加し、IDCSからOracle Cloud Infrastructureの同等のグループに正しいグループをマップするようにしてください。IDCSからテナントで作成されたユーザーが表示されれば成功です(フェデレーションされたユーザーのみを表示できるフィルタがあります)。マッピング時にグループを作成することもできます。
Adding Groups and Users for Tenancies Federated with Oracle Identity Cloud Service
https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/addingidcsusersandgroups.htm#

Step 5: Set up the user with an API key

IDCSユーザーがOracle Cloud Infrastructureでプロビジョニングされたユーザーとして存在するので、APIキーペアを作成し、そのキーペアをユーザーにアップロードする必要があります。各ユーザーはそれぞれキーペアを持ちます。詳細は以下のSDKの設定に関するドキュメントをご覧ください。
Required Keys and OCIDs
https://docs.cloud.oracle.com/iaas/Content/API/Concepts/apisigningkey.htm

Step 6: Check the user's capabilities 

最終チェックとして、ユーザーがCLIもしくはSDKを利用できることを確認しましょう。また、SDKのみ利用可能でWebコンソールは利用できなくすることもできます。

これでIDCSユーザーの設定が完了したので、SDKを活用し、Oracle Cloud Infrastructureユーザーに権限が付与されたスクリプトを実行できます。

Tips

  • ユーザー名の前にIdentity Providerの名前が付いている場合、そのユーザーはフェデレートされていることがわかります。デフォルトでは、IDCSとのフェデレーションがなされているユーザーにはoracleidentitycloudserviceがついています。具体的には、oracleidentitycloudservice/Martinという感じです。
  • ユーザーが複製されなかった場合、設定手順とグループ間のマッピングを確認してください。それでもうまくいかない場合には、My Oracle Supportにサポートを依頼してください。
    My Oracle Support
    https://support.oracle.com/
  • マッピングされたグループに割り当てられたユーザーのみが複製されます。ユーザーは存在するものの、そのユーザーが所望のIDCSユーザーではない場合、当該ユーザーはIDCSからOracle Cloud Infrastructureにマッピングされたグループに所属していないということです。
  • SDKもしくはCLIを使うためには、CLIまたはSDKを実行するクライアントに、クライアントマシンに一致する秘密鍵が格納されている必要があります。不適切なアクセスを防ぐため、適切にクライアントマシンを保護する必要があります。

Conclusion

フェデレーションに関する将来の発表をお待ちください。他のフェデレーションプロバイダもサポート予定があります。情報アップデート時にお知らせします。

[Virtualization] Oracle VM VirtualBox 6.0 now available!

原文はこちら。
https://blogs.oracle.com/virtualization/oracle-vm-virtualbox-60-now-available

世界で最も人気のある、無料かつオープンソースのクロスプラットフォーム仮想化ソフトウェアの最新のリリースである、Oracle VM VirtualBox 6.0の一般提供の発表ができることをOracleはうれしく思っています。このリリースでは、Oracle Cloud Infrastructureとの緊密な統合により、組織や開発者がアプリケーションをオンプレミスでより簡単かつ柔軟に構築し、数回のクリックでクラウドに展開できるようになります。

フル・サーバー環境を使用するというオーバーヘッドなしにクラウドおよびローカル・アプリケーションを作成する開発者およびユーザーにとって重要なツールであるため、Oracle VM VirtualBoxは、標準のx86デスクトップおよびラップトップ・コンピュータ上で動作します。これにより、ユーザーは(オプションのランタイム暗号化もしつつ)ソフトウェア開発やテスト、一般的なOSの仮想化、のためのマルチプラットフォームの仮想マシン環境をセットアップできます。ソフトウェアエンジニアは自身のWindowsやmacOS、Linux、Oracle Solarisのマシン上のOracle VM VirtualBox VM内からクラウドネイティブ環境のための開発が可能です。標準的なラップトップだけでより簡単にマルチティアアプリケーションを作成できます。

Oracle VM VirtualBoxを使うと、ローカル環境でOSやアプリケーションを含む仮想マシンを作成、アップデートできるため、これらを業界標準のファイル形式にパッケージングして、簡単に配布したり、Oracle VM Serverやその他のサーバー仮想化ソリューションと連携し、クラウドへデプロイしたりすることが簡単に実現できます。

Oracle VM VirtualBoxを使用すると、ほとんどすべての標準x86 OSを実行できるため、システム上でネイティブに使用できないアプリケーションを実行できます。

What's New with Oracle VM VirtualBox 6.0?

6.0では、最新のゲストOSならびにホストOSをサポートしています。例えば、Apple macOS X、Microsoft Windows、Oracle Linux、Oracle Solaris、その他のLinux OS、レガシーOSなどです。Oracle VM VirtualBox 6.0の新機能をご紹介しましょう。
  • Oracle Cloud Infrastructure Support Added for Export Appliance:  Export Appliance機能を起動することで、Oracle VM VirtualBoxはOracle Cloud InfrastructureサービスへのVMのエクスポートをサポートします。
  • Support for Nested Virtualization: このリリースでは、Oracle VM VirtualBox やKVM、Oracle VM VirtualBoxゲストのようなハイパーバイザーをインストール可能な特定のハードウェアプラットフォームにてNested Virtualizationをサポートします。これらの環境では、仮想マシンをゲストVMで作成、実行できます。Nested Virtualizationのサポートを使えば、VirtualBoxを使ってより柔軟かつ洗練された開発・テスト環境を作成できます。
  • Moving a VM or a Disk Image to a New Location: このリリースでは、ディスクイメージを異なる場所に移動できるだけでなく、VMを異なる場所に移動することもできます。
  • Improved Export and Import of Appliances in OVF/OVA Format: OVF/OVA形式でのアプライアンスのエクスポートおよびインポート機能が改善されました。エクスポートファイルアーカイブのサイズやコンテンツに影響を与える追加オプション、アプライアンスのインポートに対する追加オプションを選択できるようになっています。
  • Enhancement for Cloning VMs: VMの複製時にハードウェアUUIDを維持できるようになりました。
  • User Interface Improvements: このリリースで数多くのユーザビリティ、アクセシビリティに対する改善が入りました。
  • Guest Control File Manager: この機能を使うと、ゲストVMユーザーがファイルをゲストとホストの間で伝送できます。
  • Improved 3D Graphics Support: 3Dグラフィックのパフォーマンスが改善されました。また、VMware SVGAグラフィックデバイスのエミュレートをサポートするようになりました。
  • FUSE Mounting of Virtual Disk Imagesvboximg-mount という、macOS Xホストのための新たなコマンドラインユーティリティが追加されました。macOS XホストがOracle VM VirtualBox仮想ディスクイメージへのRAWアクセスを可能にするものです。
  • Improved Integration with Microsoft Hyper-V: Hyper-Vが稼働しているWindowsホスト上でOracle VM VirtualBoxを利用できるようになりました。そのための構成は不要で、Oracle VM VirtualBoxはHyper-Vを自動的に検知し、検知した場合、ホストの仮想エンジンとしてHyper-Vを利用します。これは実験的機能です。
完全な機能強化リストや詳細は、リリースノートをご覧ください。
Oracle® VM VirtualBox
Release Notes for Release 6.0
https://docs.oracle.com/cd/E97728_01/F12470/html/index.html

Oracle VM VirtualBox Upgrade Path


Oracle VM VirtualBoxは以前のサポートされているリリースから6.0へ簡単にアップグレードできます。

Oracle VM VirtualBox Product Support      

Oracle VM VirtualBoxはさまざまなホストOSおよびゲストOSをサポートしています。
Getting Support for Oracle VM VirtualBox
http://www.oracle.com/technetwork/server-storage/virtualbox/support/index.html

Resources 

Documentation


Software Download


Blogs 


Social Media


Additional Resources

[Linux] Announcing Software Collection Library 3.2 for Oracle Linux

原文はこちら。
https://blogs.oracle.com/linux/announcing-software-collection-library-32-for-oracle-linux

We are pleased to announce the release of the Software Collection Library 3.2のリリースを発表できうれしく思っております。Software Collection Library 3.2はUnbreakable Linux NetworkおよびOracle LinuxのYumサーバからご利用いただけます。
Unbreakable Linux Network
https://linux.oracle.com/
Oracle Linux yum server
https://yum.oracle.com/
ソフトウェア・コレクションはPerlやPHP、Pythonといったソフトウェアコンポーネントの最新機能にアクセスする必要のある開発環境で使ってもらうことを想定しています。こうした環境では、これらのコンポーネントのバージョンに依存するシステムプロセスの中断を最小限にする必要がありますが、Software Collectionsライブラリを使用すると、同じソフトウェアの複数のバージョンをシステムに同時に、中断することなく、インストールして使用できます。

Software Collectionsライブラリユーティリティ(scl)を使用して、インストール済みのSoftware Collectionsから開発ツールを実行します。sclユーティリティはインストールされている同一ソフトウェア・ユーティリティの別のバージョンが、これらのツールの実行に影響を与えないようにします。

Additions and Updates for Oracle Linux 7

以下のコレクションをSoftware Collection Library 3.2で追加しました。
  • devtoolset-8
  • rh-git218
  • rh-haproxy18
  • rh-nginx114
  • rh-nodejs10
  • rh-perl526
  • rh-php72
  • rh-ruby25
  • rh-varnish5
  • rh-varnish6
以下のコレクションをSoftware Collection Library 3.2でアップデートしました。
  • devtoolset-7
  • httpd24
  • rh-git29
  • rh-nodejs6
  • rh-nodejs8
  • rh-php70

Software Collections Libraries Available for Oracle Linux 7 (aarch64)

ARM (aarch64) プラットフォーム用のSoftware Collections Librariesに最新バージョンや新規追加するのは、Oracleだけです。これらはOracle Linux 7の最新のアップデートでのみサポートされます。x86_64プラットフォームでご利用いただけるように、完全なSoftware Collections Librariesのサブセットがaarch64でご利用いただけます。

以下のコレクションが現在Oracle Linux 7(aarch64)でご利用いただけます。
  • devtoolset-6
  • devtoolset-7
  • devtoolset-8
  • httpd24
  • oracle-armtoolset-1
  • python27
  • rh-git218
  • rh-git29
  • rh-maven35
  • rh-nginx112
  • rh-nginx114
  • rh-nodejs10
  • rh-nodejs6
  • rh-nodejs8
  • rh-perl526
  • rh-php70
  • rh-php71
  • rh-php72
  • rh-python36
  • rh-ruby25
  • rh-varnish5
  • rh-varnish6
Oracle Linux 7(aarch64)用Software Collections Librariesには、64ビットARMプラットフォーム用のコードをビルドし、提供されたカーネルに対してモジュールをコンパイルするための堅実な開発者向けツールセットを提供するoracle-armtoolset-1も追加されています。これにはaarch64版UEK R5をビルドする際に利用するgccコンパイラ ver 7.3が含まれています。

Oracle Linux 7をご利用のお客様は、以下のURLで詳細情報をご覧ください。
Software Collection Library 3.2 for Oracle® Linux - Release Notes
https://docs.oracle.com/cd/E52668_01/E59096/html/index.htmlOracle Linux 7 Documentation Library
https://docs.oracle.com/cd/E52668_01/index.html

Additions and Updates for Oracle Linux 6

Oracle Linux 6向けの以下のコレクションがSoftware Collection Library 3.2に追加されています。
  • devtoolset-8
以下のコレクションがSoftware Collection Library 3.2でアップデートされています。
  • devtoolset-7
  • httpd24
  • rh-git29
  • rh-nodejs6
  • rh-php70
Oracle Linux 6をご利用のお客様は、以下のURLで詳細情報をご覧ください。
Software Collection Library 3.2 for Oracle® Linux - Release Notes
https://docs.oracle.com/cd/E37670_01/E59096/html/index.html
Oracle Linux 6 Documentation Library
https://docs.oracle.com/cd/E37670_01/index.html

Support

Oracle Linux Premier Supportをご契約であれば、Software Collection Libraryのサポートを無料でご利用いただけます。

有償サポートをご契約でない場合は、Oracle Communityフォーラムでのピアサポート(peer support)をご利用ください。
Oracle Community
https://community.oracle.com

Resources – Oracle Linux

Documentation

Software Download

Blogs

Community Pages

Social Media

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

Product Training and Education (Oracle Linux)

[Cloud, Network] Configure a FastConnect Direct Link with Equinix Cloud Exchange Fabric

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/configure-a-fastconnect-direct-link-with-equinix-cloud-exchange-fabric

このエントリはSergio J. Castro(Senior Solutions Engineer, Oracle)とBill Blake(Global Solutions Architect, Equinix)によるものです。

Oracle Cloud Infrastructure FastConnectは、オンプレミスのデータ・センターまたはネットワークをOracle Cloud Infrastructureに接続するためのPublicインターネットの代替ネットワーク接続です。

Equinixは最初かつ最大のFastConnectパートナーで、最も相互接続されているデータセンター内で世界の名だたる企業をお客様や従業員、パートナーとを接続しています。Equinix Cloud Exchange Fabric ™ (ECX Fabric)を使用すると、お客様はUS、EMEA、APACの30箇所以上でOracle IaaSおよびPaaSソリューションをOracle Cloudに拡張できます。

Equinix Cloud Exchange Fabricは、FastConnectを活用してOracle Cloud Infrastructureサービスへの接続に最適化されています。その結果、最大10 GBPSの専用速度を実現する、予測可能で一貫性のあるレイテンシと高い帯域幅を提供する安全な接続を実現します。

このエントリでは、OracleとEquinixのクラウド・アーキテクトが、Equinix Cloud Exchange Fabricを使用して、Oracle Cloud Infrastructureとオンプレミス・ルータ間のFastConnect接続を完全に構成するために必要なすべての手順を示します。

Oracle Cloud InfrastructureとEquinixの両方のアカウントが必要です。オンプレミス側の接続では、顧客宅内機器として機能するルータへの管理者アクセスが必要です。この記事では、Cisco CSRを使用しています。

Oracle Cloud Infrastructureでは、仮想クラウド・ネットワーク(VCN)を構築し、動的ルーティング・ゲートウェイ(DRG)を構成し、DRGをVCNに関連付け、VCNトラフィックをDRGにルーティングするルーティング・ルールを追加します。次に、FastConnectリンクを設定します。FastConnectの設定から、Virtual Circuit(仮想回線)のOCIDを取得し、プライベートピアリング設定のためのCloud Exchange Fabricの構成をEquinixに渡します。

Equinix Cloud Exchange Fabricでは、OCIDと、リージョン、Border Gateway Protocol(BGP)のIP、AS番号(Autonomous System Number、ASN)などの情報を使用してOracle Cloud Infrastructureへの接続を作成し、構成を完了します。

Create a Virtual Cloud Network
(You can skip this step if you already have the VPC that you want to use)

Virtual Cloud Network (VCN) はOracle Cloud Infrastructureで構成される、ソフトウェアで定義されたプライベートネットワークで、ルーター、ルート、およびセキュリティールールを備えた物理ネットワークの仮想表現です。 VCNはFastConnectリンク構成に必須ではありませんが、オンプレミスとクラウドネットワーク間の相互接続を目的に作成します。このエントリでは、End to Endの接続テストをICMPで実施します。
  1. Oracle Cloud Infrastructure Consoleで貴社のテナントにサインイン
    Oracle Cloud Sign In
    https://cloud.oracle.com/en_US/sign-in
  2. 構成しようとしているEquinixの宛先リージョンに一致するOracle Cloud Infrastructureのリージョンであることを確認する。この例ではAshburnリージョンを利用している。

  3. ホームページのQuick LaunchセクションでCreate a virtual cloud network: Networkingをクリック

  4. Create Virtual Cloud Networkダイアログボックスでコンパートメントを選択。事前に選択されている場合、そのコンパートメントにVCNを配置することでよいのか確認し、異なる場合は別のコンパートメントを選択する。Oracle Cloud Infrastructureはリソースの編成のためにコンパートメントを利用している。
    Understanding Compartments
    https://docs.cloud.oracle.com/iaas/Content/GSG/Concepts/console.htm#Understa
  5. VCN名を指定する。このフィールドが空白の場合、作成日時をVCN名として自動設定する。
  6. Create Virtual Cloud Network Plus Related Resourcesを選択。このオプションは以下のオブジェクトを生成する。構成をカスタマイズしたい場合、この設定ではなくCreate Virtual Cloud Networkを選択してこれらのリソースの各々を作成する。
    1. デフォルトのCIDRブロックの割り当て
    2. 各アベイラビリティ・ドメインにサブネットを作成
    3. インターネットゲートウェイを追加
    4. セキュリティリストの生成
    5. オープンなインターネットへのEgressルールを構成済みのルーティングテーブルの生成
  7. Create Virtual Cloud Networkをクリックすると、VCNの詳細ページが表示される。
注意: この例では、10.0.2.2というプライベートIPを持つLinux VMのComputeインスタンスを立ち上げている。Oracle Cloud InfrastructureでComputeインスタンスの起動方法の詳細は以下のURLを参照のこと。
Welcome to Oracle Cloud Infrastructure
https://docs.cloud.oracle.com/iaas/Content/GSG/Concepts/baremetalintro.htm


Create a Dynamic Routing Gateway

Dynamic Routing Gateway (DRG) は仮想ルータで、仮想トラフィックVCNと他のネットワーク、例えばオンプレミスのネットワーク間のプライベートトラフィックのための経路を提供します。
  1. Consoleの左側で、Networking > Dynamic Routing Gatewaysをクリック
  2. Create Dynamic Routing Gatewayをクリック
  3. Create Dynamic Routing Gatewayダイアログボックスで、DRGを配置したいコンパートメントを選択し、DRGに名前を付ける(この例ではEquinixDRG)。

  4. Create Dynamic Routing Gatewayをクリック
  5. DRGのプロビジョニングが完了してから、DRGを選択
  6. Consoleの左側で、Resources > Virtual Cloud Networksをクリック
  7. Attach to Virtual Cloud Networkをクリック
  8. Attach to Virtual Cloud Networkダイアログボックスで、VCNが存在するコンパートメントと同じコンパートメントを選択して、VCNを選択(この例ではEquinixVCN)

    Associate with Route Table 設定は無視してもよい。このオプションの詳細情報は、リンクもしくはダイアログボックス内の情報アイコンをクリックする

  9. Attachをクリック
これでVCNがDRGにアタッチされました。

Add a Rule to the DRG on Your Route Table

VCNは、インターネットやオンプレミスネットワークといったVCN外にトラフィックを送信するために仮想ルーティングテーブルを使います。
  1. Networking に戻って作成したVCN(EquinixVCN)を選択
  2. ResourcesRoute Tablesをクリック
  3. Default Route Table for EquinixVCNをクリック
  4. Edit Route Rulesをクリック
  5. +Another Route Ruleをクリック
  6. 広がったダイアログボックスで、以下の情報を入力
    • Target Type は Dynamic Routing Gateway
    • Compartment は この演習で使ってきたものと同じものを選択(今回の場合はEquinix)
    • Destination CIDR Block は、オンプレミスのネットワークCIDRブロックを入力。今回の例では192.168.1.0/24を使用。
    • Target Dynamic Routing Gatewayは、先ほど作成したDRG(今回の場合はEquinixDRG)を選択

  7. Saveをクリック

Create a FastConnect Virtual Circuit

The final step on Oracle Cloud Infrastructureでの最後の手順は、DRGがオンプレミスネットワークに到達するために利用するFastConnect Circuitの構成です。この手順を実施するにあたり、以下の情報を知っておく必要があります。Equinixがこの情報を提供してくれます。
  • Border Gateway Protocol (BGP) IPアドレス
  • AS番号(Autonomous System Number、ASN)
  1. Networking に戻る
  2. Networking, > FastConnectをクリック
  3. Create Connectionをクリック
  4. Create Connectionダイアログボックスで、Connect Through a Provider を選択した上で、Equinix: CloudExchangeを選択

  5. Continueをクリック
  6. 新たな Create Connection ダイアログボックスで、以下の情報を入力する。ここに記載の値は、この例固有のものである。
    • Name: 接続名、この例ではEquinix
    • Compartment: この演習で使ってきたものと同じコンパートメントを選択、この例ではEquinix
    • Virtual Circuit Type: Private Virtual Circuit
    • Dynamic Routing Gateway Compartment: Equinix
    • Dynamic Routing Gateway: EquinixDRG
    • Provisioned Bandwidth: 1 GBPS
    • Customer BGP IP Address: 172.16.4.1/30
    • Oracle BGP IP Address: 172.16.4.2/30
    • Customer BGP ASN: 65100

  7. Continueをクリック。接続をOracle Cloud Infrastructureから作成する。
  8. 接続の詳細ページで、OCIDをコピーする。この値は、次のセクションのEquinixからの仮想接続をプロビジョニングする際に使う。また、Equinixリンクをクリックすることもできる。これをクリックすると、Equinixのメインページに遷移し、ポータルにログインできる(次のセクションで説明)

Complete the Connection from Equinix to Oracle Cloud Infrastructure

上図の通りOracle Cloud Infrastructure側の作業は完了したので、FastConnectのステータスはPending Providerの状態です。これからは、実際の物理リンクのプロバイダであるEquinix側での設定が必要です。
  1. Equinix Cloud Exchange Portalにログイン
    Cloud Exchange Fabric Portal
    https://ecxfabric.equinix.com/
  2. Create Connection タブをクリック
  3. Oracle Cloudを選択
  4. 4個の選択肢からOracle Cloud Infrastructure –OCI- FastConnect(Layer 2) を選択し、 Create a Connection.をクリック

  5. originとdestinationを選択。この例では、Equinix Chicagoから、Equinix Ashburnに近いOracle Cloud Infrastructure Ashburnリージョンへの仮想接続を作成する。

    Equinix Cloud Exchange (ECX) WAN Fabricを使ってChicagoとAshburn間をつなごうとしていることに注意が必要。

  6. 仮想接続構築に必要な情報を入力する。
    • FastConnect Virtual Circuit: 接続名を入力
    • VLAN: ルータで利用するVLANを入力(値は完全一致していなければならない)
    • Virtual Circuit OCID: 以前の手順でOracle Cloud Infrastructure ConsoleからコピーしたOCIDを入力。この値をシステムが検証する。
    • Purchase Order Number: このオプションフィールドはお客様の追跡のために利用される。

  7. Nextをクリック。回線速度はOracle Cloud InfrastructureからOCIDに基づいて自動的に決まる。

  8. 仮想接続の設定Reviewページで、設定の検証ならびに注文通知のためのメールアドレスを追加

    確認画面が現れる

  9. Inventory をクリックして、新しく作成した仮想接続を確認
  10. 仮想接続をクリックしてステータスを閲覧する。Equinix Cloud ExchangeがEquinixとOracle側の構成するのに通常、5〜10分要する。
  11. Status と Provider Status フィールドが Provisionedになっていることを確認

    仮想接続のOracle側の追加情報は、後々のトラブルシューティングに利用できる。

    Oracle Cloud Infrastructureの接続の詳細ページでは、リンクをプロビジョニング中でまだ同期できていないことがわかる。

Complete the Router Configuration from Equinix to Your Network

これでEquinix側の作業が完了しました。最後にオンプレミスネットワークへの接続の構成を実施します。
  1. ルータにアクセスしてBGPプロパティを構成し、ルートの交換をするためOracle Cloud InfrastructureのDRGとのピアリングの関係を確立する。この手順はベンダーによってまちまちである可能性がある。ここではCisco CSRを例にするが、BGPの構成については各社のドキュメントを参照してもらいたい。

    Equinix Cloud Exchangeを使う場合、OracleのBGP AS番号は 31898 である。貴社のAS番号はお持ちのプライベート、パブリックどちらのAS番号でもよい。
  2. ルータのIPアドレスとBGP情報を構成する
    • この例では、172.16.4.0/30 を使用
    • この例では、プライベートBGPのAS番号 65100 を使用

Validate Connectivity Between the Router and Oracle Cloud Infrastructure

以下は接続テストの推奨手順です。
  1. BGPの確立を確認
  2. BGPルートを送信し、Oracle Cloud Infrastructureで受信していることを確認
  3. Oracle DRGにpingもしくはtracerouteコマンドを送信
  4. Oracle Cloud Infrastructure内のOracleベアメタルのホストもしくはVMにpingもしくはtracerouteコマンドを送信
  5. 複数の仮想接続を使っている場合、フェールオーバーをテスト
  6. 貴社のルータ(192.168.1.1)からOracle Cloud InfrastructureのComputeインスタンス(10.0.2.2)へのpingが通ることを確認
  7. 貴社のルータからOracle DRGのIPアドレス(172.16.4.2)へのpingが通ることを確認

  8. Oracle Cloud Infrastructure Consoleで、FastConnectのステータスがUPになっていることを確認

これでエッジルータからOracle Cloud Infrastructure間の基本的な接続は確立されました。

Oracle Cloud Infrastructure FastConnectの詳細を知りたい方は、以下のドキュメントをご覧ください。
FastConnect Overview
https://docs.cloud.oracle.com/iaas/Content/Network/Concepts/fastconnectoverview.htm
Equinix Cloud Exchange Fabricの詳細を知りたい方は、以下のURLをご覧ください。
Equinix Cloud Exchange - Multi-Cloud Access
https://www.equinix.com/services/interconnection-connectivity/cloud-exchange/

著者について

Bill Blake は13年以上ネットワークに携わっているベテランで、ワイヤレス、ルーティング、スイッチング、セキュリティ、クラウド、データセンター、負荷分散などのほぼ全ての関連テクノロジーをカバーしてきました。大規模なデータセンターの移行を実行する大規模なVARだけでなく、技術者、アーキテクト、管理者としての役割で大企業でも働いてきました。最近はEquinixで、グローバル規模での顧客のデータセンター、WAN、およびクラウド戦略の構築支援をしています。

Sergio Castro は Oracle Cloud Infrastructure Certified Architect Associateで、ネットワーキングおよび次世代ITサービスに注力しています。

[Integration, Security, Cloud] Securely Connect to REST APIs from Oracle Integration Cloud

原文はこちら。
https://blogs.oracle.com/integration/securely-connect-to-rest-apis-from-oracle-integration-cloud

Oracle REST Adapterは、外部RESTful APIを利用するにあたって包括的な方法を提供しています。このエントリでは、REST Adapterを使って保護されたAPIを利用する方法の概要をご紹介します。

Oracle Integration Cloud(OIC、以下OIC)は、保護されたAPIへのアクセスのためのセキュリティポリシーを指定するために利用できる再利用可能な接続を提供します。一度構成すれば、ユーザーは接続をテスト、保存、完成し、統合フロー内で他の接続と同様に利用できます。

REST Adapter接続を新たなセキュリティ資格証明で更新すると、その変更は自動的に全てのデプロイ済みの統合に伝播するため、統合フローのアップデートや再デプロイは必要ありません。統合フローの開発者は、新たなセキュリティ資格証明が統合フロー内で参照されるAPIやリソースに対して(以前のセキュリティ資格証明と)同じアクセス権限を有していることを確認しておく必要があります。

その他の変更、特にベースURI、SwaggerやRAMLドキュメントへのURLのような外部REST APIと関連するものである場合、影響を受けるフローを一度非アクティブ化した上で再アクティブ化する必要があったり、場合によっては、影響を受けるアダプターのエンドポイントを再編集が必要だったりする場合もあります。

以下のセキュリティポリシーをOICではサポートしています。

Basic Authentication 

HTTP Basic認証はHTTPプロトコルに組み込まれているシンプルな認証スキームで、クライアントはHTTPリクエストをAuthorizationヘッダーで送信します。このAuthorizationヘッダーには、Basicに続いて空白、そしてユーザー名:パスワードをBase64でエンコードした文字列が設定されています。REST Adapterでは、Basic Authenticationセキュリティポリシーを選択し、ユーザー名とパスワードを指定する必要があります。


REST Adapterは資格証明がCredential Storeに安全に格納されることを保証します。API呼び出し時にAdapterはHTTPヘッダーにリクエストと共に以下のように注入します。
Authorization: Basic <base64-encoded-value-of-credentials>
テスト接続が成功しても、ユーザー名とパスワードは検証されません。統合の開発者が資格証明を事前に検証しておく必要があります。


API Key Based Authentication

API keyで保護されているAPIを利用する場合、統合開発者はAPI Key Based Authenticationセキュリティポリシーを利用する必要があります。

REST Adapterは開発者に対し、API Keyをどのようにリクエストと共に送信する必要があるのかを宣言的に定義できる拡張性のあるインターフェースを提供しています。API呼び出し時にAdapterはリクエストと共に指定されたAPI Keyの利用方法に従ってAPI keyを注入します。
テスト接続が成功しても、API Keyは検証されてはいません。統合の開発者が事前にAPI Keyを検証しておく必要があります。
このセキュリティポリシーの詳細を知りたい方は、以下のエントリをご覧ください。
API-Key Based Authentication: Quickly and Easily
https://blogs.oracle.com/integration/api-key-based-authentication%3a-quickly-and-easily
https://orablogs-jp.blogspot.com/2018/10/api-key-based-authentication-quickly.html

OAuth Client Credentials

リソースオーナーの介入なくClient IdとClient Secretを使ってクライアントアプリケーションが直接アクセスを取得します。

REST Adapterでは、OAuth Client Credentialsセキュリティポリシーを選択して必要な情報を設定する必要があります。

テスト接続では設定した資格証明を使ってアクセストークンを認可サーバから取得します。アクセストークンは安全に内部にキャッシュされ、必要に応じてリフレッシュされます。

REST Adapterは以下のようなセキュリティポリシーに設定された値を使ってアクセストークンを取得します。
curl -X POST -H 'Content-Type: [Auth Request Media Type]' -H "Accept: application/json" -H 'Authorization: Basic {base64#[YOUR_CLIENT_ID]:[YOUR_CLIENT_SECRET]}' -d  ‘{'grant_type=client_credentials&scope=[YOUR_SCOPE]' '[YOUR_ACCESS_TOKEN_URI]'
During API呼び出し時にAdapterはリクエストと共に以下のようにアクセストークンをAuthorizationヘッダーとして注入します。
Authorization: Bearer <access_token_obtained_using_oauth_client_credentials>
アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一のスコープ内のリソースにアクセスできることを確認する必要があります。

[注意]
OAuth2仕様は、クライアント認証のための厳密なメカニズムを意図的に省略しています。保護されたリソースへのアクセスに使用されるアクセストークン属性とメソッドもこの仕様の範囲を超えています。その結果、標準ポリシーを使用して対処できないOAuth2の実装が数多くあります。
RFC 6749 The OAuth 2.0 Authorization Framework
Client Authentication
https://tools.ietf.org/html/rfc6749#section-2.3
    Oracle REST Adapterでは任意のOAuthクライアント資格情報設定で使用できる柔軟なCustom Two Legged OAuthセキュリティポリシーを利用できます。詳細は以下のエントリをご覧ください。後の章でも紹介します。
    OAuth Custom Two Legged Security Policy In Oracle Integration Cloud
    https://blogs.oracle.com/adapters/integrate-ics-with-a-third-party-oauth-protected-rest-service-using-the-generic-rest-adapter-part-1

    OAuth Resource Owner Password Credentials

    アクセストークン取得のために、認可グラントとして直接リソースオーナーパスワード資格証明を利用できます。リソースオーナーは資格証明をクライアントに共有するため、ポリシーを利用します。このポリシーは、リソースオーナーとクライアント間の信頼度が高い場合に使用されます。

    REST Adapterでは、ユーザーがResource Owner Password Credentialsセキュリティポリシーを選択して、必要な情報を設定する必要があります。

    テスト接続時には入力した資格証明を使ってアクセストークンを認可サーバから取得します。このアクセストークンを安全に内部にキャッシュし、必要に応じてリフレッシュします。
    REST Adapterは、以下のようにセキュリティポリシーに指定した値を使って、アクセストークンを入手します。
    curl -X POST -H "Authorization: Basic {base64#[YOUR_CLIENT_ID]:[YOUR_CLIENT_SECRET]}" -H "Content-Type: [Auth Request Media Type]" -d '{"grant_type": "password", "scope": "[YOUR_SCOPE]",    "username": "[USER_NAME]", "password": "[PASSWORD]" }' "[YOUR_ACCESS_TOKEN_URI]"
    API呼び出し時にAdapterはAuthorizationヘッダーとしてアクセストークンをリクエストと共に以下のように注入します。
    Authorization: Bearer <access_token_obtained_using_oauth_ropc>
    アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースにアクセスできることを確認する必要があります。

    [注意]
    OAuth2仕様は、クライアント認証のための厳密なメカニズムを意図的に省略しています。保護されたリソースへのアクセスに使用されるアクセストークン属性とメソッドもこの仕様の範囲を超えています。その結果、標準ポリシーを使用して対処できないOAuth2の実装が数多くあります。
    RFC 6749 The OAuth 2.0 Authorization Framework
    Client Authentication
    https://tools.ietf.org/html/rfc6749#section-2.3
    Oracle REST Adapterでは任意のOAuthクライアント資格情報設定で使用できる柔軟なCustom Two Legged OAuthセキュリティポリシーを利用できます。詳細は以下のエントリをご覧ください。後の章でも紹介します。
    OAuth Custom Two Legged Security Policy In Oracle Integration Cloud
    https://blogs.oracle.com/adapters/integrate-ics-with-a-third-party-oauth-protected-rest-service-using-the-generic-rest-adapter-part-1

    OAuth Custom Two Legged Flow

    Custom Two leggedセキュリティポリシーにより、OICはOAuth Client CredentialsおよびOAuth Resource Owner Password Credentialsフローを使って保護されたサービスを含む、OAuthで保護された多くのサービスに接続するために必要な柔軟性を提供します。

    REST Adapterでは、OAuth Custom Two Legged Flowセキュリティポリシーを選択して、必要な情報を設定する必要があります。

    テスト接続では設定された資格証明を使って認可サーバからアクセストークンを取得します。このアクセストークンは安全に内部にキャッシュされ、必要に応じてリフレッシュされます。

    Access Token Usageは開発者に対し、アクセストークンをどのようにリクエストと共に送信する必要があるのかを宣言的に定義できる拡張性のあるインターフェースを提供しています。API呼び出し時にAdapterはリクエストと共にAccess Token Usageの指定に従ってアクセストークンを注入します。

    アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースへのアクセスを確認する必要があります。

    詳細は以下のエントリをご覧ください。
    OAuth Custom Two Legged Security Policy In Oracle Integration Cloud
    https://blogs.oracle.com/adapters/integrate-ics-with-a-third-party-oauth-protected-rest-service-using-the-generic-rest-adapter-part-1

    OAuth Authorization Code Credential

    認可コードグラントは、クライアントアプリケーションにアクセストークンを付与する前にリソースオーナーの同意が必要なOAuthフローです。

    REST Adapterでは、OAuth Authorization Code Credentialセキュリティポリシーを選択して必要な情報を設定する必要があります。

    構成が済めば、統合の開発者はprovide consentをクリックできます。この操作でユーザーは認可URLにリダイレクトされ、ここでリソースオーナーが認可サーバで認証、クライアントアプリケーションに同意を提供します。この操作でOAuthフローが無事に完了します。統合の開発者は接続をテスト、保存、完了でき、統合フロー内でその他の接続のように利用できます。

    テスト接続では設定された同意フローが成功し、認可サーバからアクセストークンの取得を検証します。このアクセストークンは安全に内部にキャッシュされ、必要に応じてリフレッシュされます。

    API呼び出し時に、Adpaterは以下のようにリクエストと共にAuthorizationヘッダーとしてアクセストークンを注入します。
    Authorization: Bearer <access_token_obtained_using_code_authorization>
    アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースへのアクセスを確認する必要があります。

    [注意]
    OAuth2仕様は、クライアント認証のための厳密なメカニズムを意図的に省略しています。保護されたリソースへのアクセスに使用されるアクセストークン属性とメソッドもこの仕様の範囲を超えています。その結果、標準ポリシーを使用して対処できないOAuth2の実装が数多くあります。
    RFC 6749 The OAuth 2.0 Authorization Framework
    Client Authentication
    https://tools.ietf.org/html/rfc6749#section-2.3
    Oracle REST Adapterでは任意のOAuthクライアント資格情報設定で使用できる柔軟なCustom Three Legged OAuthセキュリティポリシーを利用できます。次章で紹介します。

    OAuth Custom Three Legged Flow

    OAuth Custom Three leggedセキュリティポリシーにより、OICは認可コードフローを使って保護されたサービスを含む、OAuth2で保護された多くのサービスに接続するために必要な柔軟性を提供します。

    REST Adapterでは、OAuth Custom Three Legged Flowセキュリティポリシーを選択し、必要な情報を設定する必要があります。

    構成が済めば、統合の開発者はprovide consentをクリックできます。この操作でユーザーは認可URLにリダイレクトされ、ここでリソースオーナーが認可サーバで認証、クライアントアプリケーションに同意を提供します。この操作でOAuthフローが無事に完了します。統合の開発者は接続をテスト、保存、完了でき、統合フロー内でその他の接続のように利用できます。

    テスト接続では設定された同意フローが成功し、認可サーバからのアクセストークン取得を検証します。このアクセストークンは安全に内部にキャッシュされ、必要に応じてリフレッシュされます。

    同意の提供フローではリソースオーナーの操作が必要なので、アクセストークンを実行時にリソースオーナーが操作しなくてもアクセストークンをリフレッシュできるよう、アクセストークンのリフレッシュの仕組みを指定しておくことを推奨します。

    Access Token Usageは開発者に対し、アクセストークンをどのようにリクエストと共に送信する必要があるのかを宣言的に定義できる拡張性のあるインターフェースを提供しています。API呼び出し時にAdapterはリクエストと共にAccess Token Usageの指定に従ってアクセストークンを注入します。

    アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースへのアクセスを確認する必要があります。

    OAuth Custom Three Leggedポリシーを詳細に説明するエントリを今後用意する予定です。

    OAuth 1.0 One legged Authentication

    OAuth 1.0a (One-legged) を使うと、クライアントは認証されたHTTPリクエストに対し、リソースの資格証明で保護されたリソースへアクセスさせることができます。この方法は、各リクエストに2個の資格証明セットを含むように設計されています。1つはクライアントの識別、もう1つはリソース所有者の識別用途です。クライアントは、リソースオーナーに代わって認証されたリクエストを作成する前に、リソースオーナーが認可したトークンを取得する必要があります。

    テスト接続では、必要な値が設定されているかどうかだけチェックします。実行時にこれらの資格情報を署名付きアクセストークンの生成に使用します。認証済みトークンは一度だけ使用されるため、生成されたトークンはキャッシュしません。

    API呼び出し時にAdapterはリクエストと共にAuthorizationヘッダーとしてアクセストークンを注入します。
    Authorization: OAuth <generated_oauth1.0a_access_token>
    アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースへのアクセスを確認する必要があります。

    APIを使って外部のステークホルダーや内部のチームで情報を共有する、今日のConnected worldでは、セキュリティは最重要課題です。ほとんどのサービスプロバイダーは上記の機構を使ってAPIへのセキュアなアクセスを提供しています。このエントリでは、Oracle REST Adapterを使って安全にこれらの保護されたサービスを利用する方法をご紹介してきました。このあと、上記のほとんどのセキュリティポリシーの詳細説明をする予定です。特に、Custom OAuthポリシーは多数のOAuthで保護されたサービスと連携するための柔軟なインターフェイスを提供します。

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

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

    Oracle Linuxオペレーティングシステムはオープンなクラウドインフラストラクチャのために設計され、エンタープライズ向けSaaS、PaaSワークロードだけでなく、これまでのエンタープライズアプリケーションに対しても優れたパフォーマンス、拡張性ならびに信頼性を提供します。Oracle Linux Supportをご契約いただくと、受賞歴のあるOracleサポートリソースおよびLinuxサポートスペシャリスト、Kspliceを使ったゼロダウンタイム・アップデート、そのたOracle Enterprise ManagerとSpacewalkといった管理ツール、そしてライフタイムサポートに、全て低コストでアクセスできます。他の商用Linuxディストリビューションとは異なり、Oracle Linuxはダウンロードが簡単で利用、配布、アップデートは全て無料です。

    What's New?

    Unbreakable Enterprise Kernel Release (UEK) 5 Update 1はメインラインカーネルバージョン 4.14.35 をベースにしています。UEK5 Update 1には新機能、追加機能、サブシステム全体にわたるバグ修正が含まれています。

    Notable changes

    • 64-bit ARM(aarch64)アーキテクチャのサポート改善
      • Oracleは、64-bit ARM (aarch64) アーキテクチャのサポートを改善するために、カーネルの修正を引き続き提供しています。これらの変更は、既存のARMハードウェアで構築およびテストされており、Oracle Linux for ARMでサポートを提供します。
    • kABIサポートのため、cgroup v2 CPUコントローラをバックポート
      • このアップデートには、cgroupリソース使用状況の統計を処理するコードに対する変更が含まれており、アクティブでない多数のcgroupが存在する場所で頻繁な読み取りを処理する際のパフォーマンスが向上します。
    • fast pathに対するスケジューラの拡張性が向上
      • このリリースには、fast pathの拡張性向上が含まれています。また、Oracle Database OLTPなどの特定のワークロードのパフォーマンスを向上させるために、新しいスケジューラ機能SIS_COREが導入されています。
    • DTraceを拡張し、 x86_64 およびArmアーキテクチャに実行時の追加オプションを追加
      • 上記に加え、ARMアーキテクチャでSDTプローブ、FBTエントリプローブ、FBTリターンプローブの実装とともにustack()の実装を含むようにDTraceを拡張しました。
    • PMEM と DAXのためにlibnvdimmサブシステムを更新
      • libnvdimm カーネルサブシステムは、非揮発性デュアルインラインメモリモジュール(NVDIMM、Non-Volatile Dual Inline Memory Modules)の検知、構成、管理を司ります。大量のアップストリーム・パッチ、バグ修正、バックポートを活用してlibnvdimm カーネルサブシステムをUEK R5U1でアップデートしました。特に、これらには実際のPMEMページサイズを反映するための/proc/smapsへの修正と、Address Range Scrub (ARS) を改善するための成果が含まれています。その他、ext4またはXFSファイルシステムを使用するNVDIMMでのダイレクトアクセス(DAX)ページ操作のサポートも含まれています。
    上記で紹介した新機能やその他の新機能や変更点の詳細については、リリースノートを参照してください。
    Oracle® Linux
    Release Notes for Unbreakable Enterprise Kernel Release 5 Update 1
    https://docs.oracle.com/cd/E93554_01/F10511/html/index.html

    Security (CVE) Fixes

    このリリースで修正されたCVEの全リストはリリースノートでご覧いただけます。
    Oracle® Linux
    Release Notes for Unbreakable Enterprise Kernel Release 5 Update 1
    Security Fixes for CVEs
    https://docs.oracle.com/cd/E93554_01/F10511/html/uek-cve-fixes.html

    Supported upgrade path

    既存のOracle Linux 7 Update 5以後をお使いのお客様は、Unbreakable Linux NetworkやOracle Linuxのyumサーバーを使ってアップデートできます。
    Unbreakable Linux Network
    https://linux.oracle.com/
    Oracle Linux yum server
    https://yum.oracle.com/

    Software Download

    Oracle Linuxはダウンロード、利用、配布は全て無料で、全てのアップデート、エラータも無料でご利用いただけます。
    Oracle Linux
    https://www.oracle.com/linux/
    Free Updates and Errata for Oracle Linux
    https://blogs.oracle.com/linux/free-updates-and-errata-for-oracle-linux
    https://orablogs-jp.blogspot.com/2012/03/free-updates-and-errata-for-oracle.html
    それゆえ、お客様はどのシステムでサポートサブスクリプションが必要かを決定できます。これが、お客様の開発、テスト、本番システムにとってOracle Linuxが理想的な選択肢たらしめる理由です。全てのシステムを最新かつ安全に保ちながら、各システムでどのサポート範囲が最適かを個別に決定してください。Oracle Linux Premier Supportをご契約のお客様であれば、無停止でカーネルをアップデートできるOracle Ksplice、Oracle OpenStackのサポートもご利用いただけます。
    Oracle Ksplice
    https://www.oracle.com/linux/security/
    Oracle OpenStack
    https://www.oracle.com/linux/openstack/

    Compatibility

    UEK R5 Update 1はUEK R5のGA版と完全な互換性があります。UEK R5のカーネルABIは、初期リリースに対する後続のアップデート全てで同じです。このリリースでは、UEK R4と比較すると変更が入っているため、システムで3rdパーティー製カーネルモジュールは再コンパイルが必要です。 UEK R5をインストールする前に、アプリケーションベンダーにサポート状況を確認してください。

    Resources – Oracle Linux

    Documentation

    Software Download

    Blogs

    Community Pages

    Social Media

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

    Product Training and Education (Oracle Linux)

    [Security] Core-to-Edge Security: The Oracle Cloud Infrastructure Edge Network

    原文はこちら。
    https://blogs.oracle.com/cloud-infrastructure/core-to-edge-security%3a-the-oracle-cloud-infrastructure-edge-network

    インターネットに接続されたデジタルチャネルを通じて顧客、パートナー、従業員の交流が増え、脅威の状況がより複雑で多様化するにつれて、セキュリティの緊急課題が混じり合ってきています。そのため、Oracle Cloud Cloud Infrastructureはセキュリティに対して異なるアプローチを取っています。それは、データベースを含むコアインフラストラクチャからuser edgeにまで拡張するものです。

    Oracle Cloud Infrastructureのcore-to-edgeセキュリティ戦略により、お客様を様々な内外の脅威から保護し、共通のイベント管理、アラート、(脅威の)軽減のオーケストレーションを包含します。

    コアだけでなくエッジも加えることで様々なメリットがもたらされます。
    • ユーザー、アプリケーション、データ、およびインフラストラクチャを保護するために設計された防御層
    • 防御層の統合により、エッジでボットネット攻撃が検出されると、自動的にセキュリティ警告やセキュリティ態勢を増加させることができます。
    • ユーザーと顧客がどこにいるか、どの配信メカニズムを使用しているかに関係なく、(シングル・クラウド、マルチ・クラウド、またはエッジにおける)複数の場所のワークロードのサポート
    • ネットワーク、ユーザ、およびアプリケーション層での同時ベクトルを使用した攻撃の自動検出と軽減
    • 全世界でのインターネットパフォーマンスやセキュリティイベントのデータを提供するセンサーのdeep monitoringネットワーク
    Web Application FirewallとDDoS保護が含まれる新しいエッジ・セキュリティ・サービスはOracle OpenWorld 2018で発表され、信頼性のあるパフォーマンスで安全なクラウドを提供します。
    Inside Oracle's Cloud Security Enhancements at OpenWorld 2018
    https://blogs.oracle.com/cloudsecurity/inside-oracles-cloud-security-enhancements-at-openworld-2018
    このサービスは新しい全世界に散らばるOracle Cloud Infrastructure Edge Networkで動作し、多くのエンタープライズクラウド移行に関する懸念を緩和するように設計されています。Oracleのエッジ・セキュリティ・サービスは、あらゆるクラウドおよびオンプレミス・インフラストラクチャのアプリケーションを保護できます。

    What Is an Edge Network?

    クラウドエッジは、ユーザーとデバイスがネットワークに接続する場所で、クラウド内のアプリケーションとのユーザーのやり取りの重要なポイントであると共に、潜在的な攻撃の開始点になる可能性があります。

    enterprise-readyなクラウドでは以下を提供するエッジネットワークが含まれている必要があります。
    • 例えばWebトラフィックのような大量のデータセットの低レイテンシかつリアルタイムの処理
    • ロードバランサ、DNSによるホスト名解決、ローカルキャッシュ、インターネットのルート変更の追跡といったパフォーマンス向上手法
    • ローカルラーニングと自動化手法
    • リアルタイムのインターネットヘルス分析
    多くのアプリケーションやサービスは、デバイスからアクセスするCompute環境を活用して、エッジで動作するよう設計されているだけでなく、直近のクラウドサーバでワークロードを実行するよう設計されています。今日では、任意の場所でビジネスクリティカルな機能を実現できる必要があります。 コンピューティング能力がコアネットワークの能力を上回るにつれ、組織はビジネスロジックを処理するためにエッジサービス、サーバー、およびデバイス自体への依存を強めます。

    Oracleのエッジ・ネットワークは、多くのマーケットのエンド・ユーザーの近くに配置され、Webアプリケーションに入るトラフィックに重要なセキュリティとパフォーマンスの層を追加することで、ワークロードをホストする大規模で安全なOracle Cloud Infrastructureのリージョンを補完します。
    Rapid Global Expansion for Oracle Cloud Infrastructure
    https://blogs.oracle.com/cloud-infrastructure/rapid-global-expansion-for-oracle-cloud-infrastructure
    現在ネットワークは、グローバルに分散された非常に大容量のPOP(point of presence)に大規模に展開されています。各POPは完全に冗長で、マルチテナント、フォールトトレラント、および自己修復機能を備えています。

    エッジネットワークのコンピュート・キャパシティにより、Oracleのお客様がお使いのOracle Cloudリージョンやその他のクラウドプロバイダ、オンプレミスのインフラストラクチャにリクエストやデータを最適にルーティングする前に、エッジでアプリケーション保護します。

    下図は、Oracle Cloud Infrastructure Edge NetworkのPOPのロケーションマップです。15か所はアプリケーションセキュリティ専用で、5か所は大容量のDDoSスクラビングセンターがあります。19か所はDNS専用です。

    Stopping Attacks at the Edge

    セキュリティは2018年のクラウドの課題第1位です。77%のITプロフェッショナルが、RightScale 2018 State of the Cloud Surveyで課題と認識していました。
    Cloud Computing Trends: 2018 State of the Cloud Survey
    https://www.rightscale.com/blog/cloud-industry-insights/cloud-computing-trends-2018-state-cloud-survey
    セキュリティに関しては、場所が重要です。Oracle Cloud Infrastructureのセキュリティ防御プラットフォームは、Webサーバーのコア・インフラストラクチャから離れ、エンド・ユーザーに近いネットワーク・エッジに位置します。したがって、潜在的な脅威がネットワークに到達する前に、検出と緩和のプロセスが発生します。さらに、この構成では、特定のイベント(攻撃のエスカレーションなど)に基づいてアドホックなセキュリティ防御を実行したり、攻撃中に、残りのインフラストラクチャに影響を与えず、対処する必要のある特定のアプリケーションのみに集中したりすることができます。
    How an application security POP works at the edge

    Protecting Hybrid and Multi-Cloud Architectures

    企業はいくつかのクラウドプロバイダーを使うことがふつうで、オンプレミスのレガシーシステムと接続することも多々あります。このために、Oracle Cloud Infrastructure Edge Networkで動作する全てのセキュリティサービスはアプリケーションがホストされている場所に依存せずに動作するように設計されています。この設計は特にセキュリティおよびパフォーマンス面で重要です。それは、アプリケーションのホスト先やや配信メカニズムに関係なく、すべてのイベントを包括的に表示したり、これらの1つのユニークなプラットフォーム内のありとあらゆるアプリケーションの監視および保護を可能にするためです。エッジセキュリティサービスは純粋なクラウドネイティブのマルチテナントソリューションです。

    Helping Move and Improve

    企業が直面する最大の障害の1つは、ワークロードのクラウドへの移行中にも強力なセキュリティを維持することです。Oracleはこの懸念を理解しており、この移行をサポートするツールとソリューションを作成してきました。アプリケーションセキュリティサービスはアプリケーションのホスティング場所とは独立しているため、古いインフラストラクチャに適用されたものと同じセキュリティポリシーが移行前、移行中、移行後に新しいインフラストラクチャにシームレスに適用されます。

    したがって、移行および改善プロセスからリスクをなくすために、移行前に古いインフラストラクチャ内にある現在のアプリケーションで、Oracleアプリケーション・セキュリティ・サービスを有効化することをOracleはお薦めします。顧客がアプリケーションサーバーを新しいインフラストラクチャに移行した際には、すべてのセキュリティサービスが既に配置され、有効化されている状態にあります。

    これは、エンタープライズクラウドの移行に対して、同様のリスクを伴わないソリューションを提供できない、IaaS市場の他のベンダーとの主要な差別化要因です。

    Deep Monitoring of the Internet

    Oracleはディープモニタリングネットワークも導入してきました。これを使うとパフォーマンス低下、インターネット・ルーティングの変更、ネットワーク・セキュリティ・アラートに関するリアルタイムの情報と共に世界中のインターネットパフォーマンスやセキュリティイベントに関するデータを入手できます。Market PerformanceやIP TroubleshootingといったOracle Cloud製品は、このInternet Intelligenceデータに基づいています。

    OracleのInternet Intelligence Mapは、インターネット全体の不安定性を監視します。最も重要なサービスのために第三者プロバイダに依存する組織が増えてきているため、インターネットの全体的な健全性の監視がますます重要になっています。
    Oracle Internet Intelligence Map
    https://map.internetintel.oracle.com/

    Oracle Cloud Infrastructure Edge Networkによって収集されたデータは、世界中のBGPルート変更やDDoSアクティベーションに関して、Oracle Security Researchチームに貴重なインサイトを提供するためにも使用されています。Oracle Security Researchチームは、DDoS保護がアクティブ化されている場所や攻撃が発生している場所などを含め、1日あたり2億5000万回のルート更新を監視できます。ほとんどのクラウドベースのDDoS保護を提供するベンダーによるクラウドDDoS保護のアクティブ化は、ほぼリアルタイムで測定します。この情報を使って、保護ソリューションの有効性を測定できます。

    The Pillar of Security

    クラウドの敏捷性、拡張性、統合能力は、大幅なコスト削減とあいまって、クラウドへの移行はエンタープライズグレードの組織にとって不可欠になりました。しかし、セキュリティからそのような移行の規模にいたるまでのあらゆるものについて、エンタープライズクラウドの移行に関わるリスクがあります。Oracle Cloud Infrastructureはこれを考慮して設計されています。

    セキュリティは、データセンターの展開からネットワークの構築、サービスの監視とスケーリングにいたるまで、私たちがやるすべての中核的な柱です。Oracle Cloud Infrastructure Edge Networkは、オラクルの将来を見据えた戦略の一環です。世界がクラウドに移行するにつれて、我々は、安全かつ効率的に、境界なく、コア・ツー・エッジのソリューションを提供します。

    [Cloud] Announcing Oracle Cloud Infrastructure Streaming

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

    今週シアトルで開催されているCloudNativeCon North America 2018で、Oracle Cloud Infrastructure Streaming(以下Streaming)という新しいサービスを発表できうれしく思っています。
    CloudNativeCon North America 2018
    https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
    Streamingサービスは、リアルタイムに消費、処理できる大量のデータストリームを連続的に取り込むためのフルマネージドで拡張性のある永続ストレージを提供します。Streamingはメッセージング、アプリケーションログデータ、運用テレメトリデータ、Webクリックストリームデータやpublish-subscribeメッセージングモデルでデータが連続して順次生成され、処理されるようなユースケースなどといった大容量データに利用できます。

    Use Cases

    以下はOracle Cloud Infrastructure Streamingの多数考えられるユースケースのうちの一部です。
    • Messaging:
      Streamingをバックプレーンとして使用して、大規模システムのコンポーネントを疎結合にします。Streamingの主要なスコープである順序、低レイテンシ、永続性の保証により、さまざまなメッセージングパターンを実装するための信頼性の高いプリミティブを利用できます。高スループットに耐えるため、このようなシステムでのスケールが可能です。
    • Web/Mobile activity data ingestion:
      Webサイトやモバイルアプリからの利用状況データ(ページビュー、検索といったユーザーが取る得る操作)の流入パイプラインとしてStreamingを使用します。Streamingのコンシューマモデルにより、複数のリアルタイムモニタリングシステムおよび分析システム、オフライン処理およびレポート用のデータウェアハウスへの情報供給が簡単です。
    • Metric and log ingestion:
      伝統的なログやメトリックの集約アプローチの代わりにStreamingを使用し、重要な運用データをより迅速にインデックス作成、分析、および可視化に利用できるようにします。
    • Infrastructure and application event processing:
      監査、会計、および関連するアクティビティのライフサイクルイベントを報告するため、クラウドコンポーネントの統一されたエントリポイントとしてStreamingを使用します。

    Managed Service

    Oracle Cloud Infrastructure Streamingはサービス運用に必要な全てを管理しています。つまり、データをストリーミングするためのサービスのプロビジョニングからデプロイメント、メンテナンス、セキュリティパッチ、インフラストラクチャのストレージ、ネットワーク、ハードウェアやソフトウェアの構成の複製に至るまでです。

    Security

    Oracle Cloud Infrastructure Streamingはデフォルトでセキュアです。アカウントおよびデータストリームの所有者だけが作成するストリームリソースにアクセスできます。データアクセス制御のためのユーザー認証をサポートしており、Oracle Cloud Infrastructure Identity and Access Management (IAM) ポリシーを使用してユーザーおよびユーザー・グループに権限を選択的に付与できます。HTTPSプロトコルを使用して、SSLエンドポイントを介してStreamingに安全にデータを送信したり、取得したりできます。最後に、ユーザーデータは保存時、転送中ともども暗号化されます。

    Getting Started

    Oracle Cloud Infrastructure Streamingは2019年に一般提供される予定ですが、現在、Cloud Native Limited Availability Programを通じて、特定のお客様に限定してご利用いただけるようにしています。Streamingの詳細やStreamingへのアクセスを希望される場合には、こちらのフォームに登録してください。

    [Cloud] Announcing Oracle Cloud Infrastructure Resource Manager

    原文はこちら。
    https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-cloud-infrastructure-resource-manager-v2

    今週シアトルで開催されているCloudNativeCon North America 2018で、Oracle Cloud Infrastructure Resource Manager(以下Resource Manager)という新しいサービスを発表できうれしく思っています。これはOracle Cloud Infrastructureのインフラストラクチャリソースの管理を簡単にするためのサービスです。Resource Managerを使うと、infrastructure as code (IaC)を使って、Compute、Networking、Storage、Load Balancingなどのインフラストラクチャ・リソースのプロビジョニングを自動化できます。
    IaCの利用とは、つまりDevOpsプラクティスであり、これによって迅速かつ信頼性高い状態で大規模にインフラストラクチャのプロビジョニングが可能です。対象のシステムではなく、コードを変更します。そのコードはソース管理システムでメンテナンスできるので、必要に応じて協同作業や変更の追跡、文書化、逆展開も簡単です。

    Terraform

    インフラストラクチャを記述するため、Resource Managerは、クラウドインフラストラクチャを記述するための支配的な標準となっているオープンソースプロジェクトであるTerraformを使用します。OracleはTerraformに対して強くコミットしており、すべてのクラウドインフラストラクチャサービスをTerraformを通じて管理できるようにする予定です。今年初めにTerraform Providerをリリースし、Oracle Cloud Infrastructure用のTerraformモジュールをModule Registryに上げ始めました。
    Oracle Cloud Infrastructure Terraform Provider Now Supported by HashiCorp
    https://blogs.oracle.com/cloud-infrastructure/oracle-cloud-infrastructure-terraform-provider-now-supported-by-hashicorp
    https://orablogs-jp.blogspot.com/2018/09/oracle-cloud-infrastructure-terraform.html
    Terraform Module Registry
    https://registry.terraform.io/search?q=oci&verified=false
    今回、マネージドサービスを提供することで次のステップに踏み出ています。

    Managed Service

    プロバイダやモジュールに加えて、Oracleは、Terraformを操作するフルマネージドなサービスであるResource Managerを提供します。Resource ManagerはOracle Cloud Infrastructure Identity and Access Management (IAM)と統合されているため、Terraformの操作に対し詳細な権限設定が可能です。さらに、ステート・ロック(state locking)を提供します。これはユーザーにステートを共有する機能を提供し、チームがTerraformのデプロイメントにあたって効果的に共同作業を行うことを可能にします。何よりも、Terraformの操作をより簡単で信頼性の高いものにします。

    Resource Managerを使用すると、スタックを作成してからTerraformアクションを実行できます。スタックを使用すると、Terraformの構成を分離できます。ここで、1個のスタックは一緒に作成したいOracle Cloud Infrastructureリソースの集合を表します。各スタックは、ダウンロード可能なTerraformの状態ファイルに個別にマップされます。

    スタックを作成するには、コンパートメントを定義し、このスタックを作成する際にTerraform設定をアップロードします。このzipファイルには、作成したいリソースを定義しているすべての.tfファイルが含まれています。オプションでvariables.tfファイルを含めることも、コンソール上で(key,value) 形式で変数を定義することもできます。

    スタック作成後、このスタックでplanapplydestroyといった様々なTerraformアクションを実行できます。これらのTerraformアクションはjobと呼ばれます。必要に応じて、新たなzipファイルをアップロードしてこのスタックを更新したり、この設定をダウンロードしたり、スタックを削除することもできます。

    • Plan: Resource Managerは構成を解析し、終了状態を説明するOracle Cloud Infrastructureリソースを並べた実行計画を返します。
    • Apply: Resource Managerは、planジョブの結果に基づいてスタックを作成します。この操作が完了すると、定義されたコンパートメントで正常に作成されたリソースを確認できます。
    • Destroy: Terraformはスタック内のすべてのリソースを削除しようとします。

    IAMポリシーを使用して、スタックやジョブに対する権限を定義できます。 詳細な権限を定義し、特定のユーザーまたはグループのみがplan、apply、destroyといったアクションを実行できるように設定できます。

    Availability

    Resource Managerは2019年はじめに一般提供される予定ですが、現在、Cloud Native Limited Availability Programを通じて、特定のお客様に限定してご利用いただけるようにしています。現在利用可能な初期バージョンでは、Compute、Networking、Block Storage、Object Storage、IAM、Load Balancingの各サービスへのアクセスが可能です。Resource Managerの詳細やResource Managerへのアクセスを希望される場合には、こちらのフォームに登録してください。

    [Cloud] Announcing Oracle Cloud Infrastructure Monitoring

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

    今週シアトルで開催されているCloudNativeCon North America 2018で、Oracle Cloud Infrastructure Monitoring(以下Monitoring)という新しいサービスを発表しました。
    CloudNativeCon North America 2018
    https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
    Monitoringを使用すると、企業はスタック全体を監視するきめ細かなメトリックと通知を利用できます。Monitoringサービスを使用して、貴社はOracle Cloud Infrastructure Resourcesを含むスタックの健全性とパフォーマンスを理解し、リソース使用率を最適化し、異常にリアルタイムで対応できます。

    Computeインスタンス、Virtual Cloud Network (VCN)、Virtual NIC、Block Store Volume、Load Balancer as a Service (LBaaS) などのOracle Cloud Infrastructure Resourcesには、パフォーマンスとヘルスのためのメトリックが用意されています。独自のCustom Metricを追加して、スタック全体の状況を可視化することもできます。

    さらに、業界標準の統計、トリガーオペレータ、および時間間隔を使用して、これらのMetricでAlarmsも作成できます。Alarmは、Oracle Cloud Infrastructure Notificationsを使用して電子メールやPagerDutyを使ってスタック全体の重要な変更をリアルタイムで警告します。

    Oracle Cloud Infrastructure ConsoleのインタラクティブなMetrics Explorerを使うと、データのフィルタリングやカスタマイズをしながら、リソース全体のMetricやCustom Metricを包括的に閲覧できます。Monitoringではクラス最高のメトリック・エンジンを搭載しているため、リアルタイムで複数のメトリック・ストリームやディメンションにわたって強力な集約様々な分析クエリを実行できます。MonitoringサービスのパブリックAPIとSDK/CLIを使えば、既存のエンタープライズインフラストラクチャとの容易な統合が可能になります。

    Sample Monitoring use cases

    Metrics Explorerを使うと、Oracle Cloud Infrastructure Resourcesの健全性を理解できます。メトリックは個別もしくは複数のリソースで集約して表示できます。以下の例は複数のComputeインスタンスの前日のCPU利用率です。

    OCI Monitoringでは、事前遅疑した利用率の閾値を超えたCPU使用率などを通知します。リソースのCPU使用率が閾値を超えた場合、PagerDutyへの通知が呼びだされるか、チームに対してメール通知します。以下の例は、リソース使用率が24時間以上にわたって3%を下回るとアラームが呼び出されます。

    Availability

    Monitoringサービスは、Oracle Cloud Infrastructureがすべてのエンタープライズのワークロードやユースケースに対してクラス最高の基盤を提供することを保証するためのもう1つの中核的な柱を提供しています。Monitoringは2019年はじめに一般提供される予定ですが、現在、Cloud Native Limited Availability Programを通じて、特定のお客様に限定してご利用いただけるようにしています。Monitoringの詳細やMonitoringへのアクセスを希望される場合には、こちらのフォームに登録してください。

    [Cloud] Announcing Oracle Cloud Infrastructure Notifications

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

    今週シアトルで開催されているCloudNativeCon North America 2018で、Oracle Cloud Infrastructure Notifications(以下Notifications)という新しいサービスを発表しました。
    CloudNativeCon North America 2018
    https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
    Notificationsはフルマネージドで、永続性のある、セキュアなPub-Subメッセージングサービスで、メッセージを多数の分散アプリケーションに大規模に配信します。サブスクライバのエンドポイントにメッセージをプッシュすることで、ポーリングのオーバーヘッドを削減します。NotificationsはOracle Cloud Infrastructureおよび外部にホストされているアプリケーションに向け、セキュア、高い信頼性と低レイテンシ、永続化されたメッセージを配信します。通知を送信し、分散システムとマイクロサービスを統合できるようになります。

    Notifications Use Cases

    以下はたくさん考えられるNotificationsのユースケースのうちの一部です。
    • Operational alerts
      Notificationsを使って、アプリケーションのアラート起因の通知を受け取ることができます。たとえば、Oracle Cloud Infrastructure Alarmsを構成して、通知をNotificationsのtopicに送信できます。そして、電子メールまたはPagerDutyのいずれかを使用してtopicをサブスクライブできます。
    • Application integration
      このfan-outシナリオでは、アプリケーションイベントをNotificationsのトピックに送信できます。その後、Notificationsはすべてのサブスクライバにメッセージをプッシュします。たとえば貨物管理アプリケーションでは、貨物ステータスの任意の変更をNotificationsを使って複数のアプリケーションに配信し、プロセスを開始したり、お客様に通知したりすることができます。

    Getting Started

    Oracle Cloud Infrastructure Notificationsは2019年はじめに一般提供される予定ですが、現在、Cloud Native Limited Availability Programを通じて、特定のお客様に限定してご利用いただけるようにしています。Notificationsの詳細やNotificationsへのアクセスを希望される場合には、こちらのフォームに登録してください。

    [Cloud] Announcing Oracle Cloud Native Framework at KubeCon North America 2018

    原文はこちら(いずれも内容は同一です)。
    https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-cloud-native-framework-at-kubecon-north-america-2018-iaas
    https://blogs.oracle.com/cloudnative/announcing-oracle-cloud-native-framework-at-kubecon-north-america-2018

    Oracleは、KubeCon + CloudNativeCon North America 2018で、パブリック・クラウド、オンプレミス、およびハイブリッド・クラウドのデプロイメント・モデルを含む、包括的で持続可能でオープンなCloud Native開発ソリューションであるOracle Cloud Native Frameworkを発表しました。
    KubeCon + CloudNativeCon North America 2018
    https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
    Oracle Arms Developers with the Most Comprehensive Cloud Native Framework
    https://www.oracle.com/corporate/pressrelease/oracle-cloud-native-framework-121118.html
    Oracle Cloud Native Frameworkは、最近発表されたOracle Linux Cloud Native Environmentと、オープンソースのFnプロジェクトをベースにした、マネージド・クラウドサービスとして利用できる、業界初のオープン・サーバーレス・ソリューションであるOracle Functionsを含む、Oracle Cloud Infrastructureクラウドネイティブサービスで構成されています。
    Announcing Oracle Linux Cloud Native Environment
    https://blogs.oracle.com/linux/announcing-oracle-linux-cloud-native-environment
    Oracle Cloud Native Services
    https://www.oracle.com/cloud/cloud-native/
    Announcing Oracle Functions
    https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-functions
    https://blogs.oracle.com/developers/announcing-oracle-functions-v2
    https://orablogs-jp.blogspot.com/2018/12/announcing-oracle-functions.html
    Fn Project
    https://fnproject.io/
    今回の発表で、Oracleはパブリック・クラウド(Oracle Cloud Infrastructure)、ハイブリッド・クラウドおよびオンプレミス・ユーザー向けに、マネージド・クラウド・サービスおよびオンプレミス・ソフトウェアの間で統一されたクラウド・ネイティブ・ソリューションを提供およびサポートする唯一の主要クラウド・プロバイダーであること、そしてフレームワーク上に構築されたクラウド・ネイティブ・アプリケーションを任意の場所に双方向にシームレスに移植できるようにサポートします。フレームワークはオープンでCNCFが認定した準拠標準をベースにしているため、Oracle Cloud Native Framework上に構築されたアプリケーションは、任意のクラウドやインフラストラクチャ上のあらゆるKubernetes準拠の環境に移植可能です。

    Oracle Cloud Native Framework – What is It?

    Oracle Cloud Native Frameworkは、オープンなコミュニティ指向のCNCFプロジェクトをベースにした、Oracle Cloud Infrastructureクラウド・サービスとOracle Linuxオンプレミス・ソフトウェアのサポート対象のソリューションを提供します。これらは、昨年リリースされ、認定された最初のk8s製品の中で、オープンなKubernetes基盤上に構築されています。6つの新しいOracle Cloud Cloud Infrastructureクラウドネイティブサービスが、このソリューションの一部として発表され、既存のOracle Container Engine for Kubernetes (OKE)、Oracle Cloud Infrastructure Registry、Oracle Container Pipelinesサービス(a.k.a Wercker)上に構築されています。
    Container Engine for Kubernetes
    https://cloud.oracle.com/containers/kubernetes-engine

    Cloud Native at a Crossroads – Amazing Progress

    立ち止まってクラウドネイティブエコシステムがどこまで来たのかを考えるべきです。今週の完売したKubeConカンファレンスやKubernetesがもたらした成功と強力な基盤に関するスケール、興奮、そしてざわめきからもわかるかと思います。私たちは、開発者の黄金時代、大きな可能性を生み出す、以下の3つの力が集まって形成するクラウドネイティブ・デプロイメントとテクノロジーの文字通り「第一の波(First Wave)」に生きています。
    • Culture: DevOpsのカルチャーは、ソフトウェア開発とデプロイの方法を根本的に変え、アプリケーション開発チームの連携方法を根本的に変えました。方法論やカルチャーの変化サポートする作業やメトリックに約10年を費やして、SRE、DevSecOps、AIOps、GitOps、NoOpsなど、多くの関連する派生するものが生まれました(リストは間違いなく進化し続けるでしょう)。
    • Code: Netflix、Google、Uber、Facebook、TwitterなどのWebスケールの組織で徹底的にテストされとスピンアウトされたオープンソースとそのプロジェクトは、CNCF(Cloud Native Computing Foundation)のような組織の下で民主化されました。これは、最大の組織のエンタープライズ開発者と同じように、家庭で遊んだり学んだりするcitizen developers にも同じアクセスと機会が与えられます。
    • Cloud: 今日のクラウドでは、まったく新しいコンピューティング、ネットワーク、ストレージが利用可能であり、その力はベアメタルからGPUに至るまで、絶えず爆発的な規模で発展を続けています。これにより、HPCアプリ、Big Data、AI、ブロックチェーンなどの分野の開発者向けに新しいアプリケーションの開発の制約がなくなります。

    Cloud Native at a Crossroads – Critical Challenges Ahead

    あらゆる進歩にもかかわらず、この第1の波の成功の先に到達するための新たな課題に直面しています。多くの開発者やチームがカルチャーの変化に置き去りにされています。オープンソースは何千もの新しい選択肢やオプションを提供していますが、これにより、見かけ上は開発者用にすべて事前決定済みかつクローズドでプロプライエタリな場合よりも複雑になります。単一クラウドモデル(single source cloud model)への急激な動きは、クラウドロックインの問題を多く残し、その結果、選択肢が減少し、コストが上昇します。これは、オープンソースとクラウドが提供しようとしていたものとは正反対です。

    以下の課題は上記の肯定的な勢力を反映しており、2018年8月のCNCF調査にも現れています。
    CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%
    https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/
    • Cultural Change for Developers: オンプレミスの伝統的な開発チームが置き去りにされています。カルチャーの変化が遅く、変化が進みません。
    • Complexity: あまりにも多くの選択肢があり、メンテナンスや管理を自身でするのは難しい状態です。
    • Cloud Lock-in: プロプライエタリな単一クラウドの場合、クローズドなAPIやサービス、可搬性のないソリューションでロックインされる可能性があります。

    The Cloud Native Second Wave – Inclusive, Sustainable, Open

    必要なのは、異なるアプローチです。
    • Inclusive(包括的):クラウドもオンプレミスも、モダンな方法も伝統的な方法も、dev(開発)もops(運用も、スタートアップも大企業も
    • Sustainable(持続可能):マネージドサービス vs DIY、オープンではあるがキュレーションされており、サポート対象のエンタープライズグレードのインフラストラクチャ
    • Open(オープン):真にオープン、コミュニティ主導、プロプライエタリのテクノロジーや利己的なOSS拡張には基づかない

    Introducing the Oracle Cloud Native Framework – What’s New?

    Oracle Cloud Native Frameworkは、パブリック・クラウド、オンプレミス、そしてハイブリッド・クラウドのデプロイメント・モデルにまたがるもので、選択肢を提供しつつ、開発者の幅広いデプロイメントニーズを唯一満足するものです。これには、Oracle Cloud Infrastructure Cloud Native ServicesとOracle Linux Cloud Native Environmentが含まれています。既存のOracle Container Engine for Kubernetes (OKE)、Oracle Cloud Infrastructure Registry、Oracle Container Pipelines (Wercker) といったサービス上で、プロビジョニング、アプリケーション定義および開発、 可観測性と分析にわたるサービスを有する一連の新しいOracle Cloud Infrastructureのクラウドネイティブサービスが発表されました。
    The Journey to Enterprise Managed Kubernetes
    https://blogs.oracle.com/cloud-infrastructure/the-journey-to-enterprise-managed-kubernetes

    Use Cases for the Oracle Cloud Native Framework: Inclusive, Sustainable, Open

    Inclusive:
    Oracle Cloud Native Frameworkには含まれます、クラウドとオン・プレミスの両方が含まれており、モダンなアプリケーションならびに従来のアプリケーションならびにdevとopsをサポートします。さらに、新興企業でも大企業でもご利用いただけます。業界として、クラウドネイティブの高速道路へのより多くの流入路を作成する必要があると考えています。特に、チームやテクノロジーに触れ、人々が日々知り取り組んでいるものにクラウドネイティブを結合することによって、より多くの流入路を作成する必要があると考えています。WebLogic Server Operator for Kubernetesは、まさにその素晴らしい例です。 これにより、既存のWebLogicアプリケーションを、Kubernetesクラスタ管理に簡単に統合して活用できます。
    Announcing WebLogic Server Certification on Oracle Cloud Infrastructure Container Engine for Kubernetes
    https://blogs.oracle.com/weblogicserver/announcing-weblogic-server-certification-on-oracle-cloud-infrastructure-container-engine-for-kubernetes
    https://orablogs-jp.blogspot.com/2018/06/announcing-weblogic-server.html
    Oracle Weblogic Server Kubernetes Operator
    https://github.com/oracle/weblogic-kubernetes-operator

    別の例として、Project Helidonでは、より迅速にクラウドネイティブの世界に移行するため、マイクロサービス・アーキテクチャとJavaアプリケーションのためのフレームワークを作成しています。
    Project Helidon
    https://helidon.io/

    多くのOracle Databaseのお客様は、新しいWebフロントエンドやAI/ビッグ・データ処理のバックエンドのために、Kubernetesベースのクラウドネイティブ・アプリケーションに接続されており、Oracle Autonomous DatabaseとOKEの組み合わせにより、自動運転、セキュリティ確保、 クラウドネイティブアプリケーションの修復のための新しいモデルが作成されます。たとえば、Kubernetesサービス・ブローカとサービス・カタログ・テクノロジを使用することで、開発者はAutonomous Transaction ProcessingアプリケーションをOracle Cloud Infrastructure上のOracle Cloud Infrastructure上のOKEサービスと簡単に接続できます。
    Oracle Autonomous Database
    https://www.oracle.com/database/autonomous-database.html

    Sustainable:
    Oracle Cloud Native Frameworkは、マネージド・クラウド・サービスのセットとサポートされているオンプレミス・ソリューションを提供します。これはオープンでキュレーションされており、エンタープライズ・グレードのインフラストラクチャ上に構築されています。新しいオープンソースプロジェクトが毎日現れており、Kubernetesのような既存のプロジェクトの変更の割合は驚異的です。ランドスケープが成長している間、企業やチームは非常に迅速に学び、変更し、採用することしかできないため、業界とベンダーは複雑さの結果としての挑戦に直面しなければなりません。

    統一されたフレームワークにより、キュレーションとサポートを通じてこの複雑さが軽減されます。マネージド・クラウドサービスは、企業がやらざるを得なかった管理、トレーニング、学習の問題を軽減する秘密の武器です。これまでDIYのアプローチしか選択できませんでしたが、OKEのようなマネージド・クラウドサービスは、開発者がクラウドネイティブに飛び乗るチャンスを与えます。長くて厄介な学習曲線は必要ありません。

    オープンなエンタープライズ・グレードのインフラストラクチャ上に構築された持続可能なモデルは、企業に対し、次の5つの主要なハイブリッドクラウドユースケースを含むリアルなハイブリッド・クラウド・デプロイメントを構築するためのセキュアで高性能なプラットフォームを提供します。
    1. Development and DevOps: クラウドで開発・テストをして、本番はオンプレミス
      1. Application Portability and Migration: 双方向のクラウド・ネイティブ・アプリケーションの移植性(オンプレミスからクラウド、クラウドからオンプレミス)と lift and shift の移行を可能にします。Oracle MySQL Operator for Kubernetesは、移植性とMySQLアプリケーションのクラウドネイティブなツールへの統合を簡素化する極めて人気のあるソリューションです。
        Introducing the Oracle MySQL Operator for Kubernetes
        https://blogs.oracle.com/developers/introducing-the-oracle-mysql-operator-for-kubernetes
        これにより、データベースバックアップや既存のバックアップからの復元といった運用作業を含め、シンプルな宣言的な構成形式に基づいて、本番運用可能なMySQLクラスタの作成と管理が可能になります。MySQL Operatorを使うと、Kubernetes上でのMySQLの実行、ならびにアプリケーションの移植性と移行性の向上を簡単に実現できます。
        MySQL Operator - Create, operate and scale self-healing MySQL clusters in Kubernetes
        https://github.com/oracle/mysql-operator
      2. HA/DR: クラウド、本番系のオンプレミスにおけるディザスタリカバリや高可用性サイト
      3. Workload-Specific Distribution: 例えばレイテンシ、法令、新しいもの、レガシーなものなどといったワークロードの種類に基づいて、ワークロードの実行先をクラウド、オンプレミスで選択してください。
      4. Intelligent Orchestration: もっと先進的なハイブリッドのユースケースでは、洗練された分散アプリケーション・インテリジェンスとフェデレーションが必要です。これらにはクラウドバーストやKubernetesのフェデレーションが含まれます。
      Open: ここ数年の間にわたって、開発チームは単一クラウドモデル、換言すると、素早く簡単なソリューションを採用して、迅速に移動し、複雑さの軽減を選択することが通常でしたが、その結果、プロプライエタリなサービス、クローズドなAPI、可搬性のなソリューションに起因するクラウドロックインに対してお金を支払っているのが現状です。これは、オープンソース、CNCFベースのコミュニティ主導型の技術のおかげにもかかわらず、業界として産業として我々が進むべきところとは正反対です。

      オープンなエコシステムにより、ハイブリッド・クラウドの世界だけでなく、本当のマルチ・クラウドの世界を実現します。そしてそれこそがOracle Cloud Native Frameworkを推進するビジョンなのです。

      [Functions, Cloud] Announcing Oracle Functions

      原文はこちら(内容はほぼ同じです。今回はv2を対象にしています)。
      https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-functions
      https://blogs.oracle.com/developers/announcing-oracle-functions-v2

      Seattleで開催中のKubeCon 2018で、OracleはOracle Functionsという、企業がサーバーレスアプリケーションをクラウドで開発、実行できる新たなクラウドサービスを発表しました。

      Oracle Functionsはサーバーレス・プラットフォームで、これを使うと簡単に開発者がコードを記述、デプロイできます。コンピューティング基盤やネットワーク基盤のプロビジョニングおよび管理を心配する必要はありません。Oracle Functionsは全ての基盤となるインフラストラクチャを自動的に管理し、サービスへの着信リクエストにあわせてエラスティックにスケールします。Oracle Functionsを使うと、開発者はビジネスバリューを提供するコードを記述することに集中できます。

      Pay-per-Use

      Serverless functionsはクラウドコンピューティングの経済モデルを変えています。お客様に対してはfunction実行時に使うリソースに対してのみ課金し、アイドル時間に課金されることはありません。このアプローチは、ユーザーがプロビジョニングし、管理する仮想マシンやコンテナにコードをデプロイするこれまでのアプローチとは異なるものです。これまでのアプローチでは、24x7実行する場合、アイドル時間であっても支払う必要がありますが、Pay-per-use(使った分だけお支払い)のため、断続的なワークロードやスパイクする使用パターンのワークロードにとって、Oracle Functionsは理想的なプラットフォームです。

      Open Source

      オープンソースにより、Oracleを含む企業のソフトウェアビルド方法が変わりました。独自のクラウドfunctionプラットフォームを構築するのではなく、OracleはApache 2.0ライセンスのオープンソースFn Projectに投資し、FnでOracle Functionsを構築することを選択しました。この方法を使えば、Oracle Functions用に作成されたコードは任意のFnサーバー上で実行されます。functionは、Oracle Functionsまたはオンプレミス、または別のクラウド・プラットフォーム上でお客様が管理されるFnクラスタにデプロイできます。

      つまり、Oracle Functionsの利点は、サーバーレスサービスゆえに、お客様は顧客がFnクラスタや基盤となるコンピューティング・インフラストラクチャを手動で管理する必要がなくなります。とはいえ、オープンソースのFnのおかげで、お客様は常に最善の価格やパフォーマンスを定休するプラットフォームにご自身のfunctionをデプロイする選択肢を有します。我々はお客様が選択されるそのプラットフォームがOracle Functionsであるものと自信を持っています。

      Container Native

      他のほとんどのfunctionsプラットフォームとは異なり、Oracle FunctionsはContainer Nativeであり、functionはDockerコンテナ・イメージとしてパッケージ化されます。このアプローチは、新規ユーザのための生産性の高い開発者エクスペリエンスをサポートしつつ、パワーユーザは、必要なネイティブライブラリをインストールするなど、functionランタイム環境を完全にカスタマイズすることができます。幅広いDockerエコシステムとその柔軟性により、開発者はビジネス上の問題の解決に集中できます。独自のクラウドfunctionプラットフォームで頻繁に発生する制限を克服する方法を理解することに注力する必要はありません。

      functionはDockerコンテナとしてデプロイされます。そのため、Oracle Functionsはfunctionコンテナ・イメージの格納に使用されるDocker Registry v2準拠のOracle Cloud Infrastructure Registryとシームレスに統合されています。Oracle Functionsと同様に、Oracle Cloud Infrastructure Registryもサーバレスであり、pay-per-useでもあります。単にfunctionをビルドし、コンテナイメージをレジストリにプッシュすれば、使用されたリソースだけに対して課金されます。

      Secure

      セキュリティはOracle Cloudにとって最重要項目で、Oracle Functionsも例外ではありません。Oracle Functionsにデプロイされたfunctionへの全てのアクセスはOracle Identity and Access Management (IAM)で管理されています。IAMを使ってfunction管理とfunction実行権限を特定のユーザーやユーザーグループに割り当てることができます。デプロイの後、function自信は明示的にアクセスを許可されたコンパートメントのVCNのリソースにしかアクセスできません。セキュアなアクセスもまた、Registryに格納されたfunctionコンテナ・イメージのデフォルトです。認可されたユーザーのみがfunctionコンテナにアクセス、デプロイできることを保証するため、Oracle FunctionsはRegistryというプライベート・レジストリと連携します。いずれの場合も、お客様にはお客様自身のfunctionアセットに対して完全なアクセスを提供しつつ、Oracle Functionsは"secure by default"のアプローチを取ります。

      Getting Started

      Oracle Functionsは2019年に一般提供の予定ですが、現在Cloud Native Limited Availability Programを通じて一部のお客様に限定して提供しています。Oracle Functionsの詳細を知りたい方は、アクセスリクエストをしたい方は、是非こちらのフォームに登録してください。Oracle Functionsの基盤のオープンソーステクノロジーについて知りたい方は、以下のFn Projectのページをご覧ください。
      Fn Project - Open Source. Container-native. Serverless platform
      http://fnproject.io/

      [Java] Java Local Variable Type Inference: Frequently Asked Questions

      原文はこちら。
      https://openjdk.java.net/projects/amber/LVTIFAQ.html

      Why have var in Java?(なぜJavaにvar?)

      ローカル変数はJavaの主役です。ローカル変数を使うと、メソッドが中間値を安いコストで格納することにより、重要な結果を計算できます。フィールドとは異なり、ローカル変数は宣言されたブロック内でのみ利用するため、コンパイラは常にローカル変数が利用前に初期化されていると保証できます。コードを理解する上で、ローカル変数の名前や初期値は、ローカル変数の方よりも重要であることがよくあります。型は重要ではありますが、次の行で使う名前のほうが重要なことがあります。varを使うことで、ローカル変数宣言の重要な部分を目立たせることができます。

      型ではなくvarを使う場合、Javaコンパイラは初期値から変数の型を推論します。これは特に型が長い名前であったり、複雑なパラメータ化された型、もしくは型が初期値と重複している場合に価値があります。varを使うことで、コードの読みやすさを犠牲にせずに簡潔にできますし、土岐には冗長性を取り除いて可読性を向上させることもできます。

      Does this make Java dynamically typed? Is this like var in JavaScript?(これはJavaが動的な型になるということですか?JavaのvarはJavaScriptのvarのようなものですか?)

      どちらの質問に対する答えも、Noです。Javaは変わらず静的型言語で、varが加わったからといって変わることはありません。型ではなく、varをローカル変数の宣言で利用可能、というだけです。varを使う場合、Javaコンパイラはコンパイル時に変数のイニシャライザから取得する型情報を使って変数の型を推論します。その後、変数の静的型として推論された型を使います。通常、推論した型は明示的に書いた場合と同じ型のため、varを使って宣言した変数は、型を明示的に記述した場合とまったく同じように正しく振る舞います。

      Javaコンパイラは長年にわたって型推論をしてきました。例えばJava 8では、ラムダ式のパラメータには明示的な型を必要としていませんが、これはコンパイラがラムダ式での使われ方から、パラメータの型を推論しているからです。
      List<Person> list = ...
      list.stream().filter(p -> p.getAge() > 18) ...
      上記のコード・スニペットでは、ラムダ式のパラメータ p は静的な型Personを持つと推論しています。getAgeメソッドを持たないようにPersonクラスを変更した場合、もしくはPerson以外の型のリストに変更した場合、型推論はコンパイル時のエラーで失敗します。

      Is a var variable final?(varで宣言した変数はfinalですか?)

      いいえ。varで宣言したローカル変数はデフォルトでfinalではありません。ただし、final修飾子はvar宣言に追加できます。
      final var person = new Person();
      Javaではfinal varの短縮はありません。Scalaのような言語ではvalを使ってイミュータブル(final)変数を宣言します。Scalaの場合、全変数(ローカル変数でもフィールドでも)が以下の形式の構文を使って宣言されるため、うまくいきます。
      val name : type
      もしくは
      var name : type
      型推論させたいか否かによって、宣言の": type"部分を含めることも、省略することもできます。Scalaの場合、可変性(mutability)と不変性(immutability)の選択が型推論と直交します。

      Javaの場合、varは型推論が必要な場合にのみ利用できます。つまり、明示的に型宣言されている箇所では利用できません。valを追加した場合、この場合も型推論を用いる箇所でのみ利用できます。型が明示的に宣言されている場合、Javaでvarもしくはvalの利用によって不変性を制御することはできません。

      さらに、Javaではvarをローカル変数に対してのみ利用できます(フィールドは対象外です)。不変性はフィールドではずっと重要ではありますが、イミュータブルなローカル変数は(イミュータブルなフィールド変数に比べると)あまり使われません。

      var/val キーワードを使って不変性を制御することはScalaからJavaへきれいに引き継ぐべきであるような機能ですが、JavaにおいてはScalaにおける場合ほど有用ではないと思われます。

      Won't bad developers misuse this feature to write terrible code?(ひどい開発者がこの機能を誤用してとんでもないコードを書くのではないでしょうか?)

      はい、ひどい開発者はどんなふうにしてもひどいコードを書くことでしょう。機能を保留しても、ひどいコードを禁止できないでしょうしかし、適切に利用すれば、開発者は型推論を使ってよりよいコードを書くことができます。

      varの利用によって、新しい変数の宣言のオーバーヘッドが減るため、開発者はよりよいコードを書くことができます。変数の宣言のオーバーヘッドが高いと、開発者はそのオーバーヘッドを避けようとします。そのため、より多くの変数宣言をせずにすむよう、可読性を損なう複雑なネスト、もしくはチェーンになった式を作成するでしょう。varを使うと名前付き変数に部分式(subexpression)を引き渡すオーバーヘッドが少なくなるため、開発者はvarを使うようになるでしょう。その結果、コードがきれいになるでしょう。

      機能が導入されると、まず最初はプログラマーがその機能を使用したり、過度に使用したり、悪用したりすることさえあるでしょう。が、それはよくあることです。合理的な利用方法に関するガイドラインにコミュニティが落ち着くまでには時間がかかります。大部分のローカル変数宣言ではなく、かなり頻繁にvarを使用することはおそらく合理的です。

      ローカル変数の型推論[Local Variable Type Inference (LVTI)]から、機能提供開始時期にあわせてこのFAQやLVTI Style Guidelinesのような、推奨する利用方法に関する資料を公開しています。
      Style Guidelines for Local Variable Type Inference in Java
      https://openjdk.java.net/projects/amber/LVTIstyle.html
      https://orablogs-jp.blogspot.com/2018/03/style-guidelines-for-local-variable.html
      こうした取り組みがコミュニティによる合理的なvarの利用方法の収束を加速し、ほとんどのvarの乱用を避ける手助けになることを願っています。

      Where can var be used?(varを利用可能な箇所は?)

      var はローカル変数やfor-loopのインデックス変数、try-with-resourcesにおけるリソース変数の宣言目的で利用できます。

      ただし、var はフィールドやメソッドパラメータ、メソッドの戻り値で利用することはできません。それは、これらの場所の型は明示的にクラスファイルやjavadoc仕様書に現れているからです。型推論を使えば、イニシャライザへの変更によって変数の推論された型を変更するのはきわめて簡単です。ローカル変数の場合、これは問題ありません。というのも、ローカル変数はスコープが限定されており、ローカル変数の型はクラスファイルに直接記録されていないからです。しかしながら、フィールドやメソッドのパラメータ、メソッドの戻り値の型を推論する場合、型推論では簡単に問題が発生する可能性があります。

      例えば、メソッドの戻り値がメソッドのreturn文から推論されたとしましょう。メソッドの実装に対する変更により、return文の式の型が変更される可能性があります。この結果、メソッドの戻り値の型が変わるため、ソースやバイナリの非互換性が発生する可能性があります。このような互換性のない変更は、実装の無害な変更から生じるべきではありません。

      推論によりフィールドの型が決まる場合、フィールドのイニシャライザへの変更の結果フィールドの型が変わる可能性があり、結果としてreflective codeを予期せずに破壊する可能性があります。

      型推論は実装内ではOKですが、APIではNGです。APIのコントラクトは明示的に宣言すべきです。

      APIの一部ではないプライベート・フィールドやメソッドではどうでしょうか?理論的には、従属コンパイルと動的リンクにより互換性を損なう心配がないため、privateフィールドとprivateメソッドの戻り値の型に対してvarをサポートすることも可能でしたが、簡単のためにこのように型推論のスコープを制限することにしました。いくつかのフィールドといくつかのメソッドの戻り値を含むように境界をプッシュしようとすると、そのフィーチャはかなり複雑で難しくなるものの、有用性はそれほど向上しません。

      Why is an initializer required on the right-hand side of var?(イニシャライザがvarの右辺に必要な理由は?)

      変数の型は、イニシャライザの型から推測されます。これはもちろん、varはイニシャライザがある場合にのみ使用できるということです。変数への代入から型を推測することも可能でしたが、その場合、この機能がかなり複雑になってしまい、誤解を招くか、診断しづらいエラーにつながる可能性があります。物事を単純にするために、ローカル情報だけを使って型推論するようvarを定義しました。

      宣言とは別の複数の場所での代入を基にして型推論できたとしましょう。例えば以下のような例です。
      var x;
      ...
      x = "foo";
      ...
      x = 17;
      (例えば)最初の代入に基づいて型を選択した場合、エラーの原因から遠く離れた別の文でエラーが発生します(これは「遠隔操作」問題とも呼ばれることがあります)。

      あるいは、すべての割り当てと互換性のあるタイプを選択することもできますが、この場合、推論される型がObjectであると予想される方がいらっしゃるかもしれません。というのも、ObjectStringIntegerの共通のスーパークラスであるためです。しかし残念ながら、この状況はもっと複雑です。StringIntegerの両方がSerializableにしてComparableであるため、共通のスーパータイプは以下のような奇妙な交差型になるでしょう。
      Serializable & Comparable<? extends Serializable & Comparable<...>>
      (この型の変数を明示的に宣言できないことに注意してください。)また、17をxに代入すると、予期せず、望ましくないボクシング変換(boxing conversion)が発生します。

      これらの問題を避けるため、明示的なイニシャライザを使った型推論を要求したほうがよいと思われます。

      Why can't you use var with null?(nullと一緒にvarを使ってはいけない理由は?)

      以下のような宣言を考えてみましょう(これは誤りです)
      var x = null; // ERROR
      nullリテラルは、Javaのすべての参照型のサブタイプである特殊なnull型(JLS 4.1)の値を示します。
      The Java® Language Specification - Java SE 11 Edition
      The Kinds of Types and Values
      https://docs.oracle.com/javase/specs/jls/se11/html/jls-4.html#jls-4.1
      null型の唯一の値はnullそのものなので、null型の変数に代入できる唯一の値はnullです。これはあまり役に立ちません。

      nullに初期化されたvar宣言がObject型を持つと推測されるように特別な規則を作ることもできました。確かに可能なのですが、プログラマの意図に対する疑問が出てきます。変数は後で他の値に割り当てることができるように、nullに初期化されている場合、変数の型をObjectとして推論するのは正しい選択であるとは考えづらいのです。

      このケースを処理するための特別なルールを作らず、禁止することにしました。Object型の変数が必要な場合、明示的に宣言する必要があります。

      Can you use var with a diamond on the right-hand side?(右辺でダイアモンド演算子と一緒にvarを利用できる?)

      はい、可能です。しかし、おそらくは期待されているようなものではないでしょう。例えば以下の例を考えます。
      var list = new ArrayList<>();
      この場合、リストの型がArrayList<Object>であると推論されます。一般的には、右側でダイヤモンドを使う場合は左側で明示的な型を、左側でvarを使う場合には右側には明示的な型を、それぞれ使用するのが望ましいでしょう。詳細については、LVTIスタイルガイドラインのガイドラインG6を参照してください。
      Style Guidelines for Local Variable Type Inference in Java
      G6. Take care when using var with diamond or generic methods.
      https://openjdk.java.net/projects/amber/LVTIstyle.html#g6.-take-care-when-using-var-with-diamond-or-generic-methods.
      https://orablogs-jp.blogspot.com/2018/03/style-guidelines-for-local-variable.html#G6