[WLS, Kubernetes, Docker] Security Best Practices for WebLogic Server Running in Docker and Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes

Overview

WebLogic Server(WLS)チームは、KubernetesおよびDockerクラウド環境でWLSを実行するための新しい統合機能に投資しています。この取り組みの一環として、WebLogic Server実行時にDockerおよびKubernetes環境を保護するためのベストプラクティスを割り出しました。
これらのベストプラクティスは、以下のドキュメントにある一般的なWebLogic Serverの推奨事項に追加されるものです。
Oracle® Fusion Middleware
Securing a Production Environment for Oracle WebLogic Server
12c (12.2.1.3.0)
https://docs.oracle.com/middleware/12213/wls/LOCKD/intro.htm

Ensuring the Security of WebLogic Server Running in Your Docker Environment

References to Docker Security Resources

以下の推奨事項は、列挙したような様々なソースのドキュメントおよびホワイトペーパーを基にしています。

Summary of Recommendations

本番環境を保護するにあたっての推奨事項は以下の通りです。
  1. CIS Dockerベンチマークを使用してDockerの設定を検証します。これは、サードパーティのツールを使用して手動または自動で行うことができます。
  2. 適切なCIS Operating Systemベンチマークを使用して、ホストOSの設定を検証します。
  3. CISベンチマークで未対応の追加のホストハードニングの推奨事項を評価します。
  4. CISベンチマークで未対応の追加のコンテナランタイムの推奨事項を評価します。
これらについては、以降のセクションで詳しく説明します。

Validate Your Docker Configuration Using the Center for Internet Security (CIS) Docker Benchmark

The Center for Internet Security (CIS) は、Docker Community Editionと複数のDocker EEバージョンのベンチマークを作成しており、最新のベンチマークはDocker EE 1.13用で、Docker EEの新バージョンがリリースされた後に新たなベンチマークが追加されています。これらのベンチマークにはDockerを安全に設定するための100個ほどの詳細な推奨事項が含まれています。この推奨事項は、ホストコンポーネントとDockerコンポーネントの両方に適用され、以下のトピックで構成されています。
  • Host configuration(ホストの構成)
  • Docker daemon configuration(Dockerデーモンの構成)
  • Docker daemon configuration files(Dockerデーモンの構成ファイル)
  • Container Images and Build File(コンテナイメージとビルドファイル)
  • Container Runtime(コンテナランタイム)
  • Docker Security Operations(Dockerセキュリティオペレーション)
  • Docker Swarm Configuration(Docker Swarmの構成)
詳細は以下のベンチマークのドキュメントをご覧ください。
CIS Docker Benchmarks
https://www.cisecurity.org/benchmark/docker/
CIS Dockerベンチマークの各推奨事項に対して、手動または自動ツールを使用して構成を検証する必要があります。Dockerの構成を検証できるCISパートナーのベンチマークツールのリストは以下のURLからご覧いただけます。
CIS Center for Internet Security
https://www.cisecurity.org/
ベンチマークツールには、次のものが含まれます(アルファベット順)。
注:CISベンチマークは、商用使用のためのライセンスが必要です。詳細については、以下のURLをご覧ください。
CIS SecureSuite Membership Terms of Use
https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/

Validate Your Host Operating System (OS) Using the CIS Benchmark

The Center for Internet Security (CIS) では、さまざまなLinuxディストリビューションやAIX、Solaris、Microsoft Windows、OSXなど、さまざまなOSのベンチマークも作成しています。
これらのベンチマークには、ホストOSを安全に設定するための一連の詳細な推奨事項が含まれています。たとえば、CIS Oracle Linux 7ベンチマークには、200を超える推奨事項と300ページ以上の指示が含まれています。この推奨事項は、Linux構成におけるすべての側面に適用されます。
詳細は、ベンチマーク文書をご覧ください。
CIS Benchmarks
https://www.cisecurity.org/cis-benchmarks/
手動または自動ツールを使用して、適切なCIS Operating Systemベンチマークに対して構成を検証する必要があります。OSの設定を検証できるCISパートナーのベンチマークツールのリストは以下のURLからご覧いただけます。
CIS Center for Internet Security
https://www.cisecurity.org/
たとえば、CIS Oracle Linux 7の場合、以下のツールがあります(アルファベット順)。

Additional Host Hardening Recommendations

CISのベンチマーク以外に、以下のような追加のホスト・ハードニングの推奨事項と考慮すべき情報があります。
  • GrsecurityとPAXの利用
  • NCCグループによるホスト・ハードニングの推奨事項

Grsecurity and PaX

grsecurityプロジェクトは、システムの全体的なセキュリティを強化するさまざまなパッチをLinuxカーネルに提供します。これには、アドレス空間の保護、拡張された監査およびプロセス制御が含まれます。
PaXは、スタックなどのデータメモリに対し、非実行可能プログラムメモリおよび書き込み不可能プログラムメモリとしてフラグを立てます。PaXはまた、アドレス空間レイアウトのランダム化を提供します。
Dockerで利用するカーネルでGrsecurityとPAXを実行することができます。このときDockerの構成を変更する必要はありません。セキュリティ機能はホスト全体に適用されるため、全てのコンテナに適用されます。grsecurityとPaXを調査して、それらを運用環境で使用できるかどうかを判断することができます。詳細は以下のURLをご覧ください。
grsecurity
http://grsecurity.net/

NCC Group Host Hardening Recommendations

NCCグループのホワイトペーパーには、Linuxコンテナをハードニングする上での追加の推奨事項が含まれています。
NCC Group Whitepaper
Understanding and Hardening
Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf
There is overlap between these recommendations and the CIS Dockerベンチマークとこの推奨事項には重複する箇所が2箇所あります。
  • 10.1 Generation Container Recommendations
  • 10.3 Docker Specific Recommendations 
追加のホストハードニング項目も含まれています。
  • Keep the kernel as up to date as possible(カーネルを最新に保つ)
  • Typical sysctl hardening should be applied. 
(通常のsysctlハードニングを適用する)
  • Isolate storage for containers and ensure appropriate security.(コンテナのストレージを分離して適切なセキュリティを確保する)
  • Control device access and limit resource usage using Control Groups (cgroups)(デバイスアクセスを管理し、Control Group (cgroup)を使ってリソース利用を制限する)
詳細を調べたい場合には、以下のURLをご覧ください。
NCC Group Whitepaper
Understanding and Hardening Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf

Additional Container Runtime Recommendations

CISのDockerに対する推奨事項以外に、検討すべき追加のコンテナランタイムの推奨事項があります。
  • 手動もしくはDocker Slimなどのツールを使用して作成したカスタムのseccompプロファイルを使用する
  • Docker Security Enhanced Linux(SELinux)プロファイルを活用する
  • Docker起動時に追加の制限付きLinuxカーネル機能を指定する
  • ホストサーバー上でDockerのみを実行することで、分離を向上させ、攻撃の危険性を減らす
  • NCCグループの推奨に基づき、追加のコンテナハードニングを実施する

Run with a Custom seccomp Profile

セキュアコンピューティングモード(seccomp)は、コンテナ内で利用可能なアクションを制限するために使用できるLinuxカーネル機能です。この機能は、Dockerがseccompを伴ってビルドされていて、カーネルでCONFIG_SECCOMPが有効化されている場合にのみ使用できます。Oracle Linux 7はseccompをサポートしており、デフォルトではDockerはseccompプロファイルで動作します。
デフォルトのseccompプロファイルは、seccompを使ってコンテナを実行するための適切なデフォルト設定を提供し、300以上のシステムコールのうち約44を無効にします。デフォルトのseccompプロファイルを変更することはお勧めしませんが、以下のオプションを使い、カスタムプロファイルを指定して実行することができます。
--security-opt seccomp = /path/to/seccomp/profile.json
seccompのデフォルトプロファイルの詳細については以下をご覧ください。
Seccomp security profiles for Docker
https://docs.docker.com/engine/security/seccomp/#passing-a-profile-for-a-container
Docker運用環境に対して既定のseccompプロファイルが十分ではない場合は、カスタムプロファイルを作成して実行することもできます。Docker Slimなどのツールが、静的解析と動的解析によってカスタムseccompプロファイルを生成するのに役立つことでしょう。
DockerSlim (docker-slim): Optimize and secure your Docker containers (free and open source)
https://github.com/docker-slim/docker-slim

Run with SELinux

SELinux(Security-Enhanced Linux)は、強制アクセス制御(MAC)を含むアクセス制御セキュリティポリシーをサポートするためのメカニズムを提供するLinuxカーネルセキュリティモジュールです。Dockerコンテナ起動時にSELinuxを有効化できます。
SELinuxを有効化する前に、SELinuxがインストールされていることを確認してください。
yum install selinux-policy
DockerのSELinuxモジュールを有効化します。
semodule -v -e docker
SELinuxがDocker起動時に有効化されるように指定します。
# vi /etc/sysconfig/docker
OPTIONS='--selinux-enabled --group=docker -g /scratch/docker'

Run with Restricted Capabilities

Dockerは、制限されたLinuxカーネル機能でコンテナを実行します。追加の機能を指定して、環境の要件に基づいて削除できます。 詳細については以下のURLをご覧ください。
Linux kernel capabilities
https://docs.docker.com/engine/security/security/#linux-kernel-capabilities

Run Only Docker on Server

リソースの隔離と攻撃の危険性を減らすために、サーバー上でDockerのみを実行することをお勧めします。他のサービスはDockerコンテナに移動する必要があります。

NCC Group Docker Container Hardening Recommendations

NCCグループのホワイトペーパーには、Linuxコンテナを強化するための推奨事項が追加されています。
NCC Group Whitepaper
Understanding and Hardening Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf
CISベンチマークと以前の章でリストアップした推奨事項で、以下の2箇所に重複する部分があります。
  • 10.1 Generation Container Recommendations
  • 10.3 Docker Specific Recommendations 
追加のDockerコンテナハードニング項目も含まれています。
  • Control device access and limit resource usage using Control Groups (cgroups)(Control Groups (cgroups)を使ってデバイスアクセスを管理しリソース利用を制限する)
  • Isolate containers based on trust and ownership. Have one application per container if feasible.
    (信頼と所有権に基づいてコンテナを分離する。可能であれば、1コンテナ1アプリケーションとする)
  • Use layer two and layer three firewall rules to limit container to host and guest to guest communication.
    (L2、L3ファイアウォール・ルールを使ってコンテナからホスト、ゲスト間の通信を制限する)
  • Use Docker container auditing tools such as Clair, drydock, and Project Natilus.
    (Clair、drydock、Project NatilusといったDockerコンテナの監査ツールを使う)
これらの推奨事項の詳細は、以下をご覧ください。
NCC Group Whitepaper
Understanding and Hardening Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf

Ensuring the Security of WebLogic Server Running in Your Kubernetes Production Environment

References to Kubernetes Security Resources

以下の推奨事項は、列挙したような様々なソースのドキュメントやホワイトペーパーを基にしています。

Summary of Recommendations

環境を保護するための推奨事項は
  1. Kubernetesの構成をCIS Kuberbetesベンチマークを使って検証する。これは手作業でも、3rdパーティ製ツールを使っても実施できる。
  2. CISで未対応のKubernetesランタイムに対する追加の推奨事項を評価する。
詳細は以下で説明します。

Validate Your Kubernetes Configuration Using the CIS Kubernetes Benchmark

The Center for Internet Security (CIS) は、Kubernetesのベンチマークを作成しています。このベンチマークには、約250ページにわたって、Kubernetesを安全に構成するための一連の詳細な推奨事項が含まれています。この推奨事項は、さまざまなKubernetesコンポーネントに適用されます。推奨事項は以下のトピックで構成されています。
  • API Server、Scheduler、Controller Manager、構成ファイルやetcdを含む、マスターノードのセキュリティ構成
  • Kubelet、構成ファイルなどを含む、ワーカーノードのセキュリティ構成
  • Federated Deployments(Federation API ServerやFederation Controller Managerなど)
詳細情報は以下のURLをご覧ください。
CIS Kubernetes Benchmark
https://www.cisecurity.org/benchmark/kubernetes/
CIS Kubernetesベンチマークの各推奨事項に対して、手動または自動ツールを使用して構成を検証する必要があります。以下のURLにKubernetes設定を検証できるCISパートナーのベンチマークツールのリストがあります。このリストには以下のものが含まれます(アルファベット順)。
CIS Center for Internet Security
http://www.cisecurity.org
注:CISベンチマークは、商用使用のためのライセンスが必要です。詳細については、以下のURLをご覧ください。
CIS SecureSuite Membership Terms of Use
https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/

Additional Container Runtime Recommendations

CIS Kubernetesベンチマークの推奨事項以外に、コンテナランタイムに対する検討すべき追加の推奨事項があります。

Images

イメージは脆弱性があってはならず、信頼できるレジストリまたは個人レジストリから取得する必要があります。セキュリティ上の脆弱性がないことを確認するためにイメージのスキャンを実行する必要があります。サードパーティ製のツールを使用してCVEスキャンを実行し、これらのツールをビルドプロセスに統合する必要があります。
詳細は以下のURLをご覧ください。
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

Security Context and Pod Security Policy

セキュリティ・コンテキストを使って、Podもしくはコンテナレベルでセキュリティポリシーを設定することができます。セキュリティコンテキストを使って以下のことが可能です。
  • コンテナをroot以外のユーザーで実行する
  • コンテナで利用する機能を管理する
  • ルートファイルシステムを読み取り専用にする
  • Podからrootとして実行しているユーザーでコンテナを使用しないようにする
詳細は以下のリンクをご覧ください。
Configure a Security Context for a Pod or Container
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

Secure Access to Nodes

ホストリソースへの不正アクセスというリスクを削減するため、SSHアクセスを使ったKubernetesノードへのアクセスは避けるべきです。SSHではなく、kubectl exec を使ってください。問題のデバッグが必要な場合は、SSHアクセスを許可した別のステージング環境を作成してください。

Separate Resources

Kubernetes名前空間を使用すると、作成されたリソースを論理的に名前のついたグループに分割できます。ある名前空間で作成されたリソースは、他の名前空間から隠すことができます。追加の名前空間を作成して、リソースやユーザーを追加した名前空間にアタッチできます。メモリ、CPU、およびPodがアタッチされた名前空間に対し、リソースクォータを利用できます。
詳細は、以下のURLをご覧ください。
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

Manage Secrets

secretには、パスワード、トークン、キーなどの機密データが含まれています。secretは、データボリュームとしてマウントすることも、Pod内のコンテナが使用する環境変数として公開することもできます。また、Podに直接公開せずに、システムの他の部分で使用することもできます。 以下のことを実施しておく必要があります。
  • secretへのユーザーアクセスやPodアクセスを管理する
  • secretをセキュアに保存する
  • secretにはファイルや環境変数を使わないようにする
詳細は以下のURLをご覧ください。
Secrets
https://kubernetes.io/docs/concepts/configuration/secret/

Networking Segmentation

さまざまなアプリケーションが同じKubernetesクラスタで実行されないようにネットワークを分割します。これにより、ある侵害されたアプリケーションが近隣のアプリケーションを攻撃するリスクが軽減されます。ネットワーク分割は、許可されていない限り、コンテナが他のコンテナと通信できないことを保証します。
詳細は以下のImplement Network Segmentationの項をご覧ください。
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

[Kubernetes, Docker, WLS] WebLogic on Kubernetes, Try It!

原文はこちら。
https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes%2c-try-it

WebLogicチームは、KubernetesでオーケストレーションされるWebLogicドメインの動作検証作業を実施中です。この作業の一環として、Kubernetes環境でWebLogicドメイン/クラスタをデプロイするサンプルを作成しました。これは、KubernetesとWebLogicの両方を使用してクラスタをスケールアウト・スケールインするものです。
WebLogic on Kubernetes Sample
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-K8s
WebLogic Serverには、サーバ、アプリケーション、およびリソースを監視および診断するための豊富な機能が用意されています。このサンプルでは、これらの指標をPrometheusを通して公開し、Grafanaに表示します。Prometheusが理解できる形式でWebLogicメトリックを公開するためのWebLogic Exporterを作成しました。

(訳注)
WebLogic Server on K8sは、現在動作検証中で、OpenWorld 2017では以下のような発表がありました。



WebLogic on Kubernetes Sample

このサンプル構成は、Kubernetes環境のWebLogic Server 12.2.1.3ドメインクラスタのオーケストレーションを説明するものです。このサンプルでは、Kubernetes環境のWebLogicクラスタの異なるスケールアクションを紹介します。
  1. ReplicaSetsの個数の増加・減少によりクラスタをスケールイン・スケールアウトする
  2. Open Session Count MBeanに基づいたWLDFポリシーを定義し、WebLogic Server管理サーバにスケールアクションを開始させる
StatefulSetsを使ってドメインのWebLogic Serverを定義します。これにより、管理対象サーバ名を割り当て、WebLogicクラスタ内の管理対象サーバに、well-known DNS名を使用して相互に矛盾のない可視性を与えるにあたって一貫性を持たせることができます。
WebLogicクラスタには2つのアプリケーションがデプロイされています。一つはOpen Sessionアプリケーションで、これはWLDFポリシーを呼び出して1つの管理対象サーバによりクラスタの規模を調整します。もう一つは、Memory Loadアプリケーションで、これはJVMのヒープ・メモリを割り当てます。
WLDFポリシーが呼び出されると、管理サーバと同じPodのコンテナ内で動作しているwebhookへの呼び出しが発生します。webhookはKubernetes APIを呼び出してKubernetes を起動し、Kubernetesクラスタを拡張します。これにより、WebLogicクラスタが拡張されます。
このサンプルの一環で、管理対象サーバから収集されたWLSランタイムMBeanメトリックを整形し、Prometheusが読んでGrafana UIに表示できる形式にして公開するWLS Exporterを開発しました。

Run Sample

このサンプルの実行手順は、Minikubeを使って説明していますが、このサンプルは任意のKubernetes環境で実行できます。minikube、kubectlがインストールされていることを確認し、WebLogic Server開発者インストールイメージであるoracle/weblogic:12.2.1.3-developerをビルドしてください。以下のGitHub上に、このイメージをビルドするためのDockerfileとスクリプトがあります。
Oracle WebLogic Server on Docker
http://github.com/oracle/docker-images/tree/master/OracleWebLogic/dockerfiles/12.2.1.3
このサンプルでWebLogic 12.2.1.3ドメインイメージを作成します。
$ cd wls-12213-domain
$ docker build --build-arg  ADMIN_PASS=<Admin Password> --build-arg ADMIN_USER=<Admin  Username> -t wls-12213-domain .
2個のWebアプリケーション(Open SessionアプリケーションとMemory Loadアプリケーション)をWebLogicクラスタにデプロイします。ドメインイメージ wls-12213-domainを拡張し、 wls-12213-oow-demo-domain イメージを作成します。
$ docker build -t wls-12213-oow-demo-domain -f Dockerfile.adddemoapps .
WLDFポリシーが呼び出された際にクラスタをスケールするために使われるイメージ(oow-demo-webhook イメージ) であるwebhook イメージを作成します。
$ docker build -t oow-demo-webhook -f Dockerfile.webhook .
Save the WebアプリケーションのDockerイメージとwebhookのDockerイメージをファイルシステム(*.tar)に保存して、minikubeレジストリにロードできるようにします。
$ docker save -o wls-12213-oow-demo-domain.tar wls-12213-oow-demo-domain
$ docker save -o oow-demo-webhook.tar oow-demo-webhook
minikube を起動し、環境を設定します。
$ minikube start
$ eval $(minikube docker-env)
保存済みのWebアプリケーションのDockerイメージとwebhookのDockerイメージをminikubeにロードします。
$ minikube ssh "docker load -i $PWD/wls-12213-oow-demo-domain.tar"
$ minikube ssh "docker load -i $PWD/oow-demo-webhook.tar"
OracleWebLogic/samples/wls-k8s ディレクトリから、WebLogic管理サーバと管理対象サーバを起動します。
$ kubectl create -f k8s/wls-admin-webhook.yml
$ kubectl create -f k8s/wls-stateful.yml
インスタンスが動作していることを確認しましょう。
$ kubectl get pods
管理サーバと2個の管理対象サーバが動作していることを確認できるはずです。
NAME                          READY  STATUS     RESTARTS         AGE
ms-0                          1/1    Running           0          3m
ms-1                          1/1    Running           0          1m
wls-admin-server-0            1/1    Running           0          5m
3個の全てのサーバがRunning状態になっていることを確認してから、作業を継続しましょう。
サーバはminikubeのIPアドレスでアクセスできます。通常これは192.168.99.100です。以下の方法でIPアドレスを確認します。
$ minikube ip
192.168.99.100
WebLogic Server管理コンソールにログインするには、ブラウザでhttp://192.168.99.100:30001/consoleにアクセスします。WebLogic Serverドメインイメージ(wls-12213-domain)ビルド時に引数として渡した資格証明を使ってログインします。

Prometheusを起動し、管理対象サーバを監視します。
$ kubectl create -f prometheus/prometheus-kubernetes.yml
http://192.168.99.100:32000を確認して、Prometheusが両管理対象サーバを監視していることを確認します。メトリックのプルダウンメニューをクリックしてwls_scrape_cpu_secondsを選択し、executeをクリックすると、各管理対象サーバから収集されたメトリックを確認できるはずです。

Grafanaを起動して管理対象サーバの監視をします。
$ kubectl create -f prometheus/grafana-kubernetes.yml
Connect to Grafana at: http://192.168.99.100:31000
    Log in with admin/pass
    Click "Add Data Source" and then connect Grafana to Prometheus by entering:
    Name:    Prometheus
    Type:      Prometheus
    Url:     http://prometheus:9090
    Access:  Proxy
    Click the leftmost menu on the menu bar, and select Dashboards > Import.
Upload and Import the file prometheus/grafana-config.jsonをアップロードしてインポートし、以前の手順で追加したデータソース("Prometheus")を選択します。"WLS_Prometheus"という名前のダッシュボードが生成されるはずです。
3つのグラフ、まず「Managed Servers Up Time」、続いてWebアプリケーション「Open Session Count」、3番目に「Used Heap Current Size」がが確認できます。

Webアプリケーション“Memory Load”を実行するためには、ブラウザでhttp://192.168.99.100:30011/memoryloadappにアクセスします。"Run Memory Load"をクリックすると、メモリのスパイクの状況を"Used Heap Current Size"とラベルされたGrafanaのグラフに表示します。
kubectlを呼び出し、クラスタのレプリカの個数を増やして、Kubernetesクラスタをスケールします。
$ kubectl scale statefulset ms --replicas=3
The Kubernetesクラスタには、WebLogic Serverの管理サーバとwebhookが動作する1個のPod、そして1個の管理対象サーバがそれぞれ動作する3個のPodが表示されるはずです。“kubectl get pods” を実行して、 ms-0, ms-1, ms-2 and wls-admin-server-0 を確認しましょう。

WebLogic Server管理コンソールもまたms-0、ms-1、 ms-2が実行中で、ms-3 と ms-4 が停止している状況を示しています。Prometheusは3個の管理対象サーバすべてのメトリックを表示し、Grafanaのグラフ「サーバ稼働時間」では、管理対象サーバを表す3行が表示されます。
それでは、Kubernetesクラスタを2つのレプリカにスケールダウンしましょう。
$ kubectl scale statefulset ms --replicas=2
コマンド "kubectl get pods"もしくは管理コンソールを使ってスケールの確認ができます。
管理コンソールで、スケーリングイベントをトリガーするWLDFルールを定義しました。OpenSessionAppというApplicationRuntimeのWebAppComponentRuntimeMBeanのOpenSessionsCurrentCountを監視するように構成したWLDFスマートルールを定義しました。このルールは、毎秒サンプリングした過去10秒の間で、"DockerCluster"と呼ばれるWebLogicクラスタ内の5%以上のサーバで開かれたセッションの平均個数が0.01以上に達した場合、RESTアクションを呼び出すというものです。このRESTアクションでは、webhookを呼び出して、1個"ms"という名前のStatefulsetをスケールアップします。WLDF ルールは1分アラームで構成されているため、1分間に別のアクションを呼び出すことはありません。
WebアプリケーションOpen Sessionへは、ブラウザでhttp://192.168.99.100:30011/opensessionappにアクセスします。
1分もしくは2分以内に、新たなms-1インスタスが作成されます。このms-1インスタンスは管理コンソールやkubectlコマンド、grafanaで確認できます。
Grafanaに接続して、OpenSessionCountの収集メトリックをグラフ"Open Sessions Current Count"で確認します。

環境のクリーンアップの準備ができたら、以下のコマンドでサービスを停止します。
$ kubectl delete -f prometheus/grafana-kubernetes.yml
$ kubectl delete -f prometheus/prometheus-kubernetes.yml
$ kubectl delete -f k8s/wls-stateful.yml
$ kubectl delete -f k8s/wls-admin-webhook.yml
最後に、minikubeを停止します。
$ minikube stop

Summary

このサンプルでは、Kubernetes環境でのWebLogicドメインの実行を紹介しています。WebLogicチームは現在、Kubernetes上でのWebLogicドメイン/クラスタの動作検証に取り組んでいます。動作検証の一環として、KubernetesのWebLogicドメイン/クラスタの管理、アプリケーションのアップグレード、アプリケーションのアップグレード、パッチ適用、および安全なWebLogic環境のガイドラインを公開する予定です。以下のガイドラインのブログを参照してください。
Security Best Practices for WebLogic Server Running in Docker and Kubernetes
https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes
https://orablogs-jp.blogspot.jp/2017/10/security-best-practices-for-weblogic.html
動作検証作業の一環で、WebLogicチームはWebLogic Kubernetes Operatorをリリースする予定です。これはKubernetes APIを拡張し、ドメインやクラスタのWebLogic Serverインスタンス、アプリケーションをKubernetesユーザーの代わりに構成、管理するものです。WebLogic Kubernetes OperatorはKubernetesの設定を知っており、Kubernetesのリソースとコントローラに立脚していますが、WebLogicデプロイメントの自動化および管理のためのWebLogicドメインやアプリケーション固有の知識も含まれています。WebLogic Kubernetes Operatorのリリースについての今後の発表と、KubernetesへのWebLogic環境のデプロイ方法とビルド方法に関するガイドラインに乞うご期待!

Safe Harbor Statement
上記の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。上記の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

[Linux, Docker] Announcing Oracle Container Runtime for Docker 17.06

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

Oracle Container Runtime for Docker Release 17.06の発表ができることをうれしく思っています。Oracle Container Runtimeを使うとOracle Linuxを使ったシステムやDockerをサポートする他のOS間でアプリケーションを作成、配布することができます。Oracle Container Runtime for DockerはDocker Engineから構成されており、アプリケーションのパッケージングおよび実行ならびにDocker Hub、Docker StoreやOracle Container Registryとの統合してアプリケーションをSoftware-as-a-Service (SaaS) クラウドで共有することができます。
Oracle Container Registry
https://container-registry.oracle.com/
Oracle Container Runtime for Dockerの最新リリースはDocker 17.06ベースで、Dockerの以前のリリースからの変更が組み込まれています。Oracle Container Runtime for Docker Release 17.06はOracle Linux 7 (x86_64) でご利用いただけます。これはOracleが提供した以前のリリースからのアップグレードです。

Notable Updates

Oracle Container Runtime for Dockerの最も重要な新機能の一つが、マルチステージ・ビルドのサポートです。これを使うと、最終イメージ作成のための中間ビルド成果物を作成するDockerfileを作成することができますが、この中間ビルド成果物自体は最終イメージ自身に含める必要がありません。これは、イメージサイズを小さくするだけでなく、ロード時間やコンテナ実行時のパフォーマンス向上にも寄与します。マルチステージ・ビルドに関する詳細情報は、以下のユーザーガイドをご覧ください。
Oracle® Linux 7Oracle Container Runtime for Docker User's Guide
Multi-stage Builds
http://docs.oracle.com/cd/E52668_01/E87205/html/section_m5g_mpz_3bb.html
環境ビルドにおけるその他の改良点として、DockerfileのARG命令の形式でビルド時引数を使用できるようになりました。これにより、環境変数を各イメージに渡すことができます。FROM命令では、Dockerfile中でFROM命令の前にある、ARG命令で定義された変数をサポートします。

このリリースでは、overlay2ストレージドライバはSELinuxでもサポートされるようになっています。以前のリリースでは、SELinuxが有効で、オーバーレイファイルシステムを使っている場合、Docker Engineが始動しませんでした。このチェックは、新しいカーネルがこの組み合わせをサポートし、SELinuxサポートのパッケージが更新されたため削除されました。

このリリースには、docker-storage-configユーティリティも含まれています。このユーティリティを使用すると、新規ユーザーが新規インストール時に、Dockerストレージを正しくOracleのガイドラインに従うように設定できます。詳細については、以下のユーザーガイドをご覧ください。
Oracle® Linux 7Oracle Container Runtime for Docker User's Guide
Using the docker-storage-config Utility to Automatically Configure Docker Storage
http://docs.oracle.com/cd/E52668_01/E87205/html/docker_install_upgrade_storage.html#docker_install_storage_config_script

Deprecated Features

ご注意頂きたいのは、このリリースでは、デフォルトでv1プロトコルを実行する従来のレジストリとの通信が無効になっているという点です。
--disable-legacy-registry=false
上記のデーモンオプションを設定することで、このバージョンのプロトコルを使用した通信を許可することは可能ですが、v1レジストリのサポートは非推奨です。

デーモンオプション --graph もまた非推奨になっています。より説明的で混乱を避けるため、 --data-root を利用してください。このオプションはイメージやボリューム、コンテナ、ネットワーク、Swarmクラスタの状態やSwarmノードの証明書といったデータを含む親ディレクトリのパスを示します。

Oracle Linux Resources

Documentation

Software Download

Blogs

Community Pages

Social Media

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

Product Training and Education

コミュニティベースのサポートをお求めであれば、Oracle Technology Network CommunityのOracle Linuxスペースへどうぞ。
Space : Oracle Linux
https://community.oracle.com/community/server_&_storage_systems/linux/oracle_linux
Oracle Developer Community
https://community.oracle.com/welcome

[Database] How fast is Oracle TimesTen Velocity Scale?

原文はこちら。
https://blogs.oracle.com/timesten/how-fast-is-oracle-timesten-velocity-scale

Oracle TimesTen Velocity Scaleは、TimesTen In-Memory Databaseの基盤をベースにしています。TimesTenでは、マイクロ秒の単位という非常に低レイテンシのSQL操作を実現しています。
TimesTen Latency is measured in Microseconds not milliseconds
非常に多くの変動要素があるため、データベース間でApple to Appleでの比較を行うことは困難です。DBベンダーが互いの製品をベンチマークする際、競合他社のDBが最適に調整されていないという疑いが常にあります。以下は、Apple to AppleのDBベンチマークの例です。
2016年8月、Googleは、Sysbench DBの読み取り/書き込みワークロードを使用して、2つのアベイラビリティゾーン間での高可用性構成のOLTP DBベンチマークを公開しました。
Cloud SQL Second Generation performance and feature deep dive 
https://cloudplatform.googleblog.com/2016/08/Cloud-SQL-Second-Generation-performance-and-feature-deep-dive.html
Sysbench : Scriptable database and system performance benchmark 
https://github.com/akopytov/sysbench
Google Cloudに最適化されたGoogle Cloud SQL Second GenerationとGoogleはAWS上でAmazon RDS MySQLとAuroraを実行しましたが、コンサルティング会社(2ndWatch.com)はすぐにベンチマークを再実行し、Amazon Auroraが最適に調整されていないことを示しました。(Amazonからのコンサルティングを受けた)2ndWatchは、AWS AuroraがGoogle Cloud SQL Second Generationより優れた性能を発揮したことを証明できました。
Benchmarking Amazon Aurora
http://2ndwatch.com/blog/benchmarking-amazon-aurora/
これは、OracleではなくDBベンダーが、このベンチマークに対してデータベースが最適に調整されていることを確認したことを意味していました。
このSysbench read/write DBは、2個のアベイラビリティゾーン(データセンター)間での同期レプリケーションを実施しているため、ネットワークのラウンドトリップタイムがTimesTen Velocity Scaleの支配的な要因でした。
Sysbench throughput
上記のスループットベンチマークでの変動要素は、RDBMSとパブリッククラウドです。下図は同じSysbenchベンチマークでのレイテンシ(小さいほどよい)の結果です。
Sysbench latency
見ておわかりのように、TimesTen Velocity Scaleは最低のレイテンシならびに最高のスループットを叩き出しています。Google Cloud SQL Second GenerationやAmazon RDS MySQLおよびAmazon Auroraは全てactive-standbyレプリケーション構成を使っています。もっと読み取りのスケールのために読み取り専用のレプリカを追加することができるとしても、書き込みのスループットはアクティブなデータベースが一つであるために制限をうけます。Oracle TimesTen Velocity Scaleはactive-activeレプリケーションを使っているため、 Velocity Scaleデータベースにマシンを追加することにより、書き込みのスループットもスケールすることができます。
下図のOLTPベンチマークでは、TPTBMベンチマークを使いread/writeのスケールの様子を示しています。このワークロードは80%が読み取り、20%が書き込みです。
147 Million TPS for an 80$ read and 20% write TPTBM workload
このベンチマークでは、Oracle Bare Metal Cloud(現Oracle Cloud Infrastructure)上の32個のSun X5-2 Linux x86-64マシンを使いTPTBM read/writeワークロードがリニアにスケールすることを示すものです。
Oracle Server X5-2
http://www.oracle.com/us/products/servers/x5-2-datasheet-2312923.pdf 
コミットされた書き込みトランザクションの永続化がボトルネックだったため、マシンごとにVelocity Scaleの2つのインスタンスを使用しました。そのため、32台のマシンで64のVelocity Scaleノードが実行されていました。
書き込みI/Oのボトルネックが発生した場合に、100%読取りワークロードでテストを再実行しました。その結果、64台のマシンを使用して、毎秒120億PKのSQLのSelectという結果になりました。
1.2 Billion SQL PK reads per second

この100%読取り専用ワークロードでは、Oracle Bare Metal Cloudの64台のSun X5-2 Linuxマシンでリニアにスケールすることがわかります。より高速なマシンでこれらのテストを繰り返すことができればと考えています。
詳細は、Oracle Open World 2017のセッションでご紹介します。
TimesTen and Velocity Scale at Oracle Open World 2017
https://blogs.oracle.com/timesten/timesten-and-velocity-scale-at-oracle-open-world-2017
免責事項:これは私の個人的な考えであり、いかなる形であれ、オラクルの公式見解を表すものではありません。

[Database] What is Oracle TimesTen Velocity Scale ?

原文はこちら。
https://blogs.oracle.com/timesten/what-is-oracle-timesten-velocity-scale

Oracle Open World 2017にお出でになって、Oracle TimesTen Velocity Scale.について知ってください。
Velocity Scaleは、新しいSQL、Shared-Nothing、スケールアウト、の特徴のあるTimesTenベースのIn-memory RDBMSです。
Just how fast is TimesTen In-Memory Database?
https://blogs.oracle.com/timesten/just-how-fast-is-timesten-in-memory-database
Oracle TimesTen Velocity Scale architecture
Oracle Open World 2017ではVelocity Scaleの重要な点について知って頂けることでしょう。具体的には
  • SQL書き込みのスケールアウト方法
  • SQL読み込みのスケールアウト方法
  • 高可用性(High Availability)とリカバリ
  • SQLならびにPL/SQLでサポートされる機能
  • マシン間でのデータ分散
  • Velocity ScaleでサポートするAPI
  • 以下の他社製品とVelocity Scaleとの比較 
    • Amazon Aurora
    • Google Cloud SQL
    • MySQL Cluster
    • memSQL
    • VoltDB
    • Google Spanner
    • Apache Cassandra
  • YCSBやSysbench、TPTBMといったベンチマークでのVelocity Scaleの性能
  • Velocity Scaleが稼働するオンプレミス環境
  • Velocity Scaleが稼働するパブリック/プライベートクラウド環境
  • RAC、NoSQL、ShardingやCoherenceといったOracle製品とVelocity Scaleの違い
OOW 2017でのVelocity Scaleを取り扱うセッションやハンズオンスケジュールは以下のURLにまとめてあります。
TimesTen and Velocity Scale at Oracle Open World 2017
https://blogs.oracle.com/timesten/timesten-and-velocity-scale-at-oracle-open-world-2017

[Cloud] Announcing Fn–An Open Source Serverless Functions Platform

原文はこちら。
https://blogs.oracle.com/developers/announcing-fn

新たなオープンソースの、クラウド非依存の、サーバレスプラットフォームのFnを発表できることに非常に興奮しています。

このFn Projectは、Apache 2.0ライセンスで提供される、コンテナネイティブのサーバーレス・プラットフォームで、クラウド、オンプレミス問わずどこでも実行することができます。簡単に利用でき、全てのプログラミング言語をサポートし、拡張性とパフォーマンスに優れています。
Fn Project - The Container Native Serverless Framework
http://fnproject.io/
私たちは、始めるのが本当に簡単に始められるように注力しました。数分で試してみることができ、進歩するにつれてより高度な機能を使用することができます。ぜひクイックスタートをチェックして、数分間でご自身のfunctionを起動し、デプロイしてください。
QuickStart
https://github.com/fnproject/fn#quickstart

History

Fn ProjectはIronFunctionsを作ったチームが開発しています。このチームはサーバーレス・テクノロジーのパイオニアで、サーバーレス・プラットフォームを6年間ホストしてきました。数多くのお客様の無数のコンテナを稼働後、Dockerの登場前後の時期ですが、コンテナを大規模に稼働させる、具体的には、functions-as-a serviceのスタイルで稼働させることをチームは体得しました。

現在はOracleで、このチームはこの知見と体験をFnに注ぎ込んできました。

Features

Fnには、開発と運用のための素晴らしい機能がたくさんあります。

  • コマンドラインツールを使用して簡単にfunctionを開発、テスト、およびデプロイできます。
  • 依存関係はDocker一つだけ
  • 高性能アプリケーションのためのホットfunction
  • ラムダコードとの互換性 - ラムダコードをエクスポートしてFnで実行できます
  • 多くの人気のある言語用のFDK (Function Developer Kit)
    FDK - Java API and runtime for fn.
    https://github.com/fnproject/fdk-java
  • 高度なJava FDKとJUnitテストフレームワーク
  • Kubernetes、Mesosphere、Docker Swarmなどのお気に入りのオーケストレーションツールでFnをデプロイできます
    Kubernetes
    https://kubernetes.io/
    Mesosphere
    https://mesosphere.com/
    Docker Swarm
    https://docs.docker.com/engine/swarm/
  • トラフィックをfunctionにルーティングするために特別に構築されたスマートなロードバランサ
  • カスタムアドオンやインテグレーションを可能にする拡張性とモジュール性を備えています
プロジェクトのホームページはfnproject.ioですが、すべてのコードやリソースはGitHubにあります。
Fn Project - The Container Native Serverless Framework
http://fnproject.io/
Fn Project - The container native, cloud agnostic serverless platform.
https://github.com/fnproject/fn
皆様からのフィードバックやFnを最高最適なサーバーレス・プラットフォームにするための貢献を歓迎いたします。

Related Content


[Cloud] Cloud Foundry Arrives on Oracle Cloud with a Provider Interface and Service Brokers

原文はこちら。
https://blogs.oracle.com/developers/cloud-foundry-arrives-on-oracle-cloud

Oracle Cloudの採用がすすむにつれて、さまざまなワークロードを実行する必要性が高まっています。Cloud Foundryアプリケーション開発プラットフォームの人気があるため、昨年、Oracleのお客様がOracle CloudでCloud Foundryを実行するオプションをリクエストされました。その理由は以下の通りです。
  • Cloud Foundryは非常に人気のあるアプリケーション開発プラットフォームであり、多くのCloud Foundry開発者が他の相互に関連するプロジェクトにOracle Cloudを使用している
  • Oracle Cloudは、Cloud Foundryアプリケーションを拡張するために利用可能なOracle Cloud Platformという大きなエコシステムを備えている。逆に言えば、Cloud Foundryを使用してOracleサービスを新しい方法で拡張できる。
    Oracle Cloud Platform
    https://cloud.oracle.com/en_US/paas
  • Cloud Foundryユーザーの多くは、統合する必要のある重要なOracleワークロードを持っており、ますます多くのOracleのお客様が、これらのワークロードをOracle Cloudに移動することがより簡単であることを認識されつつある。クラウド上のOracleのワークロードの近くにCloud Foundryのワークロードを配置することで、両者を容易に相互運用し統合することができる。
それでは、Oracleはこれを実現するためにどうしたのでしょうか。

Cloud Foundry Running on Oracle Cloud

過去数ヶ月にわたり、Pivo​​talとOracleのエンジニアリングチームは、Oracle CloudでCloud Foundryを実行するためのいくつかの統合ソリューションを構築するために協力してきました。

まずBOSH Cloud Provider Interfaceから始めました。
Cloud Provider Interface (CPI)
https://bosh.io/docs/bosh-components.html#cpi
Cloud Foundryアーキテクチャのこのレイヤーは、Cloud Foundry開発者に対し、インフラストラクチャプロバイダを抽象化します。これにより、AWS、Microsoft Azure、Google Cloud Platform、現在のOracle Cloud InfrastructureなどのさまざまなクラウドプロバイダにCloud Foundryをインストールできます。

このコードはGitHubリポジトリにプッシュされ、Oracleチームが活発に作業しています。現段階ではGAではないため、Proof of Concept(概念の証明、PoC)に使用してください。
BOSH Cloud Provider Interface for Oracle Cloud Infrastructure
https://github.com/oracle/bosh-oracle-cpi
これは、OracleとPivotalの素晴らしいコラボレーションの成果でした。今後数か月の間、このCPIは、標準のCloud Foundryビルドプロセスの一部として、またCloud Foundryで利用可能なCPIの一部として定期的にテストされることになっています。

Oracle Cloud Service Brokers for Cloud Foundry

Oracle Cloud InfrastructureでCloud Foundryを実行する以外にも、開発者から聞いた重要な技術要件の1つとして、Oracle DatabaseからWebLogic Server、MySQLに至るまでの、さまざまなOracle Cloud Servicesと統合することがありました。

Cloud Foundryには、Service Brokerと呼ばれるインターフェースを介してこれを実現するための自然なモデルがあります。
Managing Service Brokers
https://docs.cloudfoundry.org/services/managing-service-brokers.html
Cloud Foundryアプリケーションは、サービスブローカーを使ってCloud Foundry上もしくはそれ以外のサービスと簡単にやりとりすることができます。操作には、プロビジョニングとデプロビジョニング、バインディングとバインド解除、インスタンスの更新とカタログ管理が含まれます。

一つ目のサービス・ブローカ・タイプは、Oracle Cloud Platform PaaSサービス用です。このモデルでは、Oracle Cloudでホストされている1つのサービスブローカーを構成することにより、Cloud FoundryがDatabase Cloud Service、Java Cloud Service、MySQL Cloud Service、DataHub Cloud Service (Cassandra) 、Event Hub Cloud Service (Kafka) を含む、5個を超える異なるPaaSサービスとやりとりすることができます。これはクラウド・サービスの初期セットであり、オラクルは市場の需要に基づいて他のものを評価する予定です。下図は、このサービスブローカーアプローチを図示したものです。

Oracleが開発した2番目のサービス・ブローカーは、Oracle Cloud Infrastructureの機能、特にOracle Cloud Infrastructure Oracle Database Cloud ServiceとOracle Cloud Infrastructure Object Storageのためのサービス・ブローカーです。これらは、これらのOracle Cloud Infrastructureサービスに直接アクセスできるようにCloud Foundryにインストールおよび設定できるサービス・ブローカーです。下図は、このモデルを図示したものです。

Deployment Approaches

Cloud FoundryとOracle Cloudの統合は、当然ながら、このソリューションが使用される典型的な展開トポロジとは何かを問われています。最初の概要として、3つのタイプのトポロジが存在することを想定しています。
  1. 全てOracle Cloudにある場合
    all in Oracle Cloudの場合、Cloud FoundryとCloud Foundryがやりとりするサービスの両方がOracle Cloudで動作し、オンプレミスでは動作しません。下図は、これを説明するためにBOSH CPIと2つのサービスブローカーをまとめたものです。

  1. ハイブリッド構成の場合
    2つめのアプローチは、Cloud Foundry がOracle Cloud以外で動作している(オンプレミス環境もしくは他社クラウドの可能性もあります)けれども、サービス・ブローカーを使い、Oracle Cloudサービスとリモートで統合するという、ハイブリッドなアプローチです。このアプローチは、ネットワークレイテンシなどの問題によって構造的な制約を受けるのは明らかですが、クラウドサービス次第では、ユースケースによっては有用なトポロジとなる場合もあります。下図は実際の動作を図示したものです。

  1. 全てオンプレミスにある場合
    3つ目のアプローチは、OracleがOracle Cloud at Customerと呼ぶ機能を活用する、全てオンプレミスにある場合のアプローチです。
    Oracle Cloud at Customer
    https://www.oracle.com/cloud/cloud-at-customer.html
    これにより、お客様はデータセンターでOracle Cloudサービスを実行できます。このアプローチは、オンプレミスでCloud Foundryを実行してパブリッククラウドにアクセスする際の、データの配置場所に対する懸念、規制上の懸念、パフォーマンスやレイテンシに関する懸念があるお客様に特に有効です。Oracle Cloud at Customerには、Oracle Cloud Machine上で実行されるOracle PaaS Service Brokerを使って通じて全ての利用可能なサービスだけでなく、Oracle Exadata Cloud Machineも含まれ、これらは全てオンプレミスで動作します。下図は、このトポロジの実際の動作を示しています。

全体として、この領域では案件ごとにたくさんの方法があります。これらの3個の異なるアプローチは、実際には指図するものではなく、どのように実現できるかというというアイデアを提供することを意図しています。

What’s Next?

この成果は、Cloud Cloud上でCloud Foundryワークロードを実行し、Oracle Cloudとやりとりするための旅の始まりです。今後数ヶ月にわたってこの作業を進めていきますので、発表をチェックしてください。

Oracle CloudのBOSH CPIおよびOracle Cloud Infrastructure Service Brokersの詳細は、以下のエントリを参照してください。
Announcing BOSH Cloud Provider Interface for Oracle Cloud Infrastructure
https://blogs.oracle.com/developers/cloudfoundry-bosh-cpi
https://orablogs-jp.blogspot.com/2017/10/announcing-bosh-cloud-provider.html
この成果に関するPivotalの展望については、以下のエントリを参照してください。
On Choice and Oracle Joining the Cloud Foundry Party
https://content.pivotal.io/blog/on-choice-and-oracle-joining-the-cloud-foundry-party