読者です 読者をやめる 読者になる 読者になる

nekop's blog

OpenShift / JBoss / WildFly / Infinispanの中の人 http://twitter.com/nekop

OpenShiftでプロジェクトの各種制限を設定する

内部利用などのユースケースではあまり問題にはなりませんが、OpenShiftを外部のユーザに利用させたりする場合はうっかり手がすべってビットコインを掘ったりする人が居るかもしれないのでそこそこにリソースを制限しないとなりません。

OpenShiftではユーザ毎のプロジェクト数はmaster-config.yamlのProjectRequestLimitで制限できます。

プロビジョニングされるプロジェクトの各種制限は、プロジェクトのテンプレートに設定します。

プロジェクトのデフォルトのテンプレートは以下のコマンドでファイル化できます。これを編集して制限を記述していきます。

oadm create-bootstrap-project-template -o yaml > project-request-template.yaml

制限には二つあり、LimitRangeという各Pod/Containerに割り当てることのできるリソースの制限と、Quotaというプロジェクト内のリソースの総数、もしくは個々のリソースを加算した全体に制限をかけるものがあります。

例えば自分が会社で運用していて他の人に使っていいよ、って置いてあるOpenShiftのクラスタでは、Quotaは内部利用なので特に設定していませんが、Java系のコンテナはlimitsが無い場合のデフォルトが-Xmx1303mとかになっていて1.5GBのメモリを無駄に確保してしまう関係上LimitRangeは設定しています。

以下の設定をプロジェクトテンプレートに追記することで、デフォルトで作成されるコンテナには128MBのメモリ、100m (1秒間あたり1CPUを占有した場合を1000ミリコアとしたときの100ミリコア)のCPUを最低で確保できるようにしています。コンテナはホストのリソースがある場合、512MBのメモリと4000ミリコア=4CPUまでの利用を許可しています。リソースはユーザが各デプロイの設定でこれらの範囲内であれば自由に設定できます。つまり、最初から4CPU 512MBを確保できるようにしてデプロイすることができます。それを超えるようなものをデプロイする場合(運用環境なのでリソース多めでお願いします、的なユースケース)はOpenShiftのcluster-admin権限でリソース制限を書き換える、というような流れになります。

- apiVersion: v1
  groupNames: null
  kind: LimitRange
  metadata:
    creationTimestamp: null
    name: default
    namespace: ${PROJECT_NAME}
  spec:
    limits:
      - type: "Pod"
        max:
          cpu: "4"
          memory: "512Mi"
        min:
          cpu: "100m"
          memory: "128Mi"
      - type: "Container"
        max:
          cpu: "4"
          memory: "512Mi"
        min:
          cpu: "100m"
          memory: "128Mi"
        default:
          cpu: "4"
          memory: "512Mi"
        defaultRequest:
          cpu: "100m"
          memory: "128Mi"

あとは高負荷が予想されるクラスタでは、コンテナにリソースを持って行かれてKubeletなどが満足に動作できない、というような状況を回避するためにシステム用にメモリをCPUを事前に予約しておくという機能があるので、本番運用ではこれらも設定しておく必要があります。

https://docs.openshift.com/container-platform/3.3/admin_guide/allocating_node_resources.html

このような設定をすることで安心してビットコインを掘ることができます。

KubernetesとOpenShiftの違い

Kubernetes Advent Calendar 2016の三日目の記事です。

OpenShiftというのはRed Hatが主導で開発しているコンテナプラットフォームで、最近の一行説明は"Enterprise Kubernetes for Developers"ということになっています。

f:id:nekop:20161203173054p:plain

OpenShiftはKubernetesの強化版であり、Kubernetesを内包しています。Red HatはKubernetesの公開直後から開発に参加しており、コントリビュータのグラフを見たときにコミット数第二位のsmarterclaytonさんがRed HatでOpenShiftの開発をリードしている人です。第一位の人はGoogleからMicrosoftに転職してKubernetesへのcommit数が低下しているので、このままのペースであれば第一位になります。

Red Hatは商用版のOpenShift Container Platformを2015/06(Kubernetesの発表はちょうどその一年前の2014/06)から展開しており、既に政府系、銀行や保険などの金融系、通信サービス業、旅行サービス業、IoT関連分野などで多く利用されています。日本のKubernetesのコミュニティの事例ではクラウドプロバイダと先進的なユーザ企業が多く、OpenShiftのようなエンタープライズ寄りな分野の利用事例はあまり聞かないのですが、サポートが無いからという側面が大きいのかもしれません。サポートと実績のあるKubernetesとしてOpenShiftが採用されているのだと思います。

KubernetesとOpenShiftの違い

KubernetesとOpenShiftの大きな違いですが、OpenShiftは「開発のスコープまでカバーできるKubernetes」になっています。Kubernetes単体ではほとんどのケースではインフラエンジニアが利用するインフラツールという位置付けになると思いますが、OpenShiftはデプロイだけではなくビルドを含めた開発のスコープまでをカバーすることで、様々なユースケースに利用できるようになっています。逆に、利用できる機能やユースケースが広すぎるために、最初はなんだか大きくてよくわからない、というような印象を受けるかもしれません。

一番基本的な機能は以下のようにソースコードを指定すると依存ライブラリの取得などの各言語の特有のビルド、コンテナイメージのビルドを行い、コンテナイメージをレジストリに登録してデプロイして実行、URLでのアクセスを可能にしてくれます。このあたりの基本機能はHerokuやCloud Foundryと言った他のPaaSとそれほど変わりません。

$ oc new-app http://github.com/nekop/hello-sinatra
$ oc expose svc hello-sinatra
$ open "http://hello-sinatra-myproject.apps.example.com"

コンテナエンジンには現状Dockerを利用していますが、利用者は手元のマシンにDockerをインストールしたりする必要はまったくありません。ワークロードは全部クラスタリソースに投げることができます。

OpenShiftがフィットする状況は以下のようなものがあります。

  • アプリケーションのコンテナ化を進めたいけど生Docker遅くてつらい
  • 隔離されていない共有開発環境しかないので開発がやりづらい、開発者ごとにさくっと開発環境を払い出したい
  • 開発者に個々に環境セットアップをさせたくないのでPaaSを利用させたい
  • 多言語利用マイクロサービス化したアプリケーションの開発運用ができるプラットフォームが欲しい
  • ビルド、テスト、デプロイなどを自動化してビルドパイプライン実現したい
  • 開発メンバーには軽量ラップトップを配布して開発サーバでVMを払い出せるようにしているけど、VMのセットアップのコストがどうにも高い

OpenShiftを使うと何ができるの?

典型的な例で、以下の図のようなものができます。大手のユーザ企業の事例では、開発テストアプリの運用を全てOpenShift上で行っており、近年のトレンドであれるマイクロサービス化にも伴って数千という数のアプリケーションがOpenShift上で開発され、動作しています。

f:id:nekop:20161203173112p:plain

OpenShiftの機能って何があるの?

代表的なものをいくつかピックアップします。ドキュメントはdocs.openshift.orgにあります。

  • Kubernetesの機能ほぼ全部
  • リッチなWebコンソール
  • コンテナイメージのビルド機能
    • 手元で遅いdocker buildを実行する必要がなくなる
    • ソースツリーを指定すればビルドしてコンテナイメージとしてデプロイしてくれる機能
  • フロントエンドルータ
  • コンテナレジストリ
    • イメージの情報の詳細を参照可能
  • セキュリティ
    • 基本的にコンテナ内でuid 0 rootは利用不可
    • SELinuxによる各コンテナ間およびホストの隔離
    • 各ネームスペース間は基本的に隔離されており不可侵
    • RBAC (ロールベースアクセス制御)
  • ネットワーキング
    • OpenShift SDNによるプロジェクト毎のネットワーク隔離
  • マルチテナント
    • 上記セキュリティとネットワーク, Linux cgroupsでのリソース制限の組み合わせ
  • イベントトリガー
    • GitHubにコミットpushされたらビルドを実行してデプロイ
    • イメージアップデートトリガーを利用してベースのコンテナイメージのセキュリティ修正などのアップデートを検知、関連するイメージを全てリビルドしてローリングアップデート
  • 柔軟なデプロイ制御
  • Jenkins Pipeline Pluginによるビルドパイプラインのサポート
    • 複数のビルドの連結、デプロイの制御やイメージのタグ付け、リリースなど
  • テンプレート
    • 事前に定義したテンプレートからビルドやデプロイの生成、WikiやGitサーバを立ち上げたり、データベースをアプリケーションにインスタントに追加など
  • 標準インストーラ
    • Ansible

OpenShiftのWeb Consoleってどんな感じ?

こんな感じです。

f:id:nekop:20161203173150p:plain f:id:nekop:20161203173154p:plain

どうやって試すのがいいの?

fedoraVM立ち上げてoc cluster upをするスクリプトを流せばすぐ使えます。

nekop.hatenablog.com

今日はこのへんで。

OpenShift Container Platform 3.3をシングルノードでインストール

OpenShift Container Platform 3.3をシングルノードでインストールするときのAnsibleのinventoryファイルのメモです。ホスト名はsingle.example.comワイルドカードアプリケーションドメイン*.apps.example.comという名前の想定です。

[OSEv3:children]
masters
nodes

[OSEv3:vars]
ansible_ssh_user=nekop
ansible_become=true
deployment_type=openshift-enterprise
openshift_master_identity_providers=[{'name': 'allow_all', 'login': 'true', 'challenge': 'true', 'kind': 'AllowAllPasswordIdentityProvider'}]
os_sdn_network_plugin_name=redhat/openshift-ovs-multitenant
osm_default_subdomain=apps.example.com

openshift_hosted_metrics_deploy=true
openshift_hosted_metrics_public_url=https://hawkular-metrics.apps.example.com/hawkular/metrics

openshift_hosted_logging_deploy=true
openshift_master_logging_public_url=https://kibana.apps.example.com/

[masters]
single.example.com openshift_node_labels="{'region': 'infra'}" openshift_schedulable=true

[nodes]
single.example.com openshift_node_labels="{'region': 'infra'}" openshift_schedulable=true

シングルノードの場合はinfraノードの役割も持つということなので、openshift_node_labels="{'region': 'infra'}" openshift_schedulable=trueにしないとregistry/routerがデプロイされません。

この範囲で3.2と比較すると、メトリクスのホスト名openshift_public_metrics_public_urlopenshift_hosted_metrics_public_urlにリネームされています。3.2からinventory設定を引き継いでいる場合は修正が必要です。まぁこの設定はインストール後に一瞬で直せるものなので、直さなくても大丈夫です。似たような設定のloggingのほうはリネームされていません。

loggingデプロイはまだサポートではなく、リリース時点でのインストーラではPVを追加すると正常に動作しません。

OpenShift Container Platform 3.3リリース

OpenShift Container Platform 3.3をリリースしました。Enterprise Kubernetesのコンテナプラットフォームです。

今回のリリースはかなり実用や応用に踏み込んだ機能追加が数多く実装されています。

ハイライトをざくっと抜き出すと以下のような感じです。

RHEL7のVMが用意できるのであれば、ocコマンドをダウンロードしていつもと同じ手順でoc cluster upしてすぐ動かせます。

oc cluster up --image="registry.access.redhat.com/openshift3/ose" --version=v3.3

OpenShift Origin v1.3.0リリース

いつものoc cluster upの手順を書いておきます。oc cluster upのドキュメントはLocal Cluster Managementにあります。Windows/Macや、デフォルトの毎回初期化する挙動ではなく、データを保存して引き継いで起動するオプションとかも載っています。

VagrantVMセットアップする部分は前回のFedora 24でoc cluster upを利用してOpenShift Originをセットアップするを参照。メモリは4096でやってます。

DOWNLOAD_URL=https://github.com/openshift/origin/releases/download/v1.3.0/openshift-origin-client-tools-v1.3.0-3ab7af3d097b57f933eccef684a714f2368804e7-linux-64bit.tar.gz
FILENAME=$(basename $DOWNLOAD_URL)
PATHNAME=${FILENAME%%\.tar\.gz}

sudo dnf install git docker -y
sudo sh -c "echo INSECURE_REGISTRY='--insecure-registry 172.30.0.0/16' >> /etc/sysconfig/docker"
sudo systemctl start docker
sudo systemctl enable docker
curl -LO $DOWNLOAD_URL
sudo tar xf $FILENAME --strip=1 -C /usr/bin $PATHNAME/oc
sudo curl -L https://raw.githubusercontent.com/openshift/origin/master/contrib/completions/bash/oc -o /etc/bash_completion.d/oc
. /etc/bash_completion.d/oc
sudo oc cluster up --metrics
mkdir ~/.kube/
sudo cat /var/lib/origin/openshift.local.config/master/admin.kubeconfig > ~/.kube/config

Nexus 7 2012にPure Nexus 6.0.1をインストール

Nexus 7 2012 "grouper"のオフィシャルアップデートがパフォーマンスが致命的に悪いポンコツ5.1.1で終わってしまっていて使い物にならなかったのでCyanogenMod 12.1を入れて子どものYouTube端末にしていたんだけど、こちらも最近パフォーマンスが非常に悪い状態で10秒くらい固まることが多くなってきていた。

CyanogenModもstableは2015-11のままでアップデートされていないようなので、Pure Nexus 6をつっこんだ。前回CyanogenModを入れたときには、Pure Nexus 6はまともに動かなかったので、CyanogenModを入れたのだった。

Fedora 24ではandroid-toolsを入れるとadb/fastbootが使える。

sudo dnf install -y android-tools

bootloaderを起動した状態でunlockを発行する。bootloaderはUSB Debugging有効でsudo adb reboot bootloaderか、電源ボタン+ボリューム下ボタン長押しで電源ONにするかで起動できる。

sudo fastboot oem unlock

recovery領域をTWRPに入れ替える。

sudo fastboot flash recovery twrp.img

flashしたら、bootloaderからRecover起動を選択するとTWRPが起動する。

USB接続からPure NexusとOpen GAppsのzipをNexus 7のDownloadディレクトリに転送する。転送したらTWRP上のInstallでzip選択して実行。再起動するとPure Nexusになる。

さて、Pure NexusだとYouTube閲覧端末として十分なパフォーマンス出るかな?

WildFly Swarm 2016.9 リリース、MicroProfileで実行

WildFly Swarm 2016.9がリリースされたので試してみます。

WildFly Swarm Project Generatorでデフォルトのまま生成してみると以下のpom.xmlが生成されました。Swarmのバージョンが2016.8.1とひとつ前のものになっているので、2016.9に書き換えてmvn packageでビルドします。ビルドしたら50MB弱のtarget/demo-swarm.jarが出来上がり、java -jar target/demo-swarm.jarで起動できます。http://localhost:8080/rest/helloにアクセスするとHello from WildFly Swarm!が表示されます。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>demo</artifactId>
  <name>Wildfly Swarm Example</name>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>war</packaging>

  <properties>
    <version.wildfly.swarm>2016.8.1</version.wildfly.swarm>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
    <failOnMissingWebXml>false</failOnMissingWebXml>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.wildfly.swarm</groupId>
        <artifactId>bom-all</artifactId>
        <version>${version.wildfly.swarm}</version>
        <scope>import</scope>
        <type>pom</type>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <build>
    <finalName>demo</finalName>
    <plugins>
      <plugin>
        <groupId>org.wildfly.swarm</groupId>
        <artifactId>wildfly-swarm-plugin</artifactId>
        <version>${version.wildfly.swarm}</version>
        <executions>
          <execution>
            <goals>
              <goal>package</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

  <dependencies>
    <!-- Java EE 7 dependency -->
    <dependency>
      <groupId>javax</groupId>
      <artifactId>javaee-api</artifactId>
      <version>7.0</version>
      <scope>provided</scope>
    </dependency>
    <!-- Wildfly Swarm Fractions -->
  </dependencies>
</project>

demo-swarm.jarの中には_bootstrap/demo.warというようにアプリケーションのwarが含まれています。

swarm.jarを実行するのではなく、WildFly Swarm MicroProfileを使って指定したwarを実行することもでできます。

java -jar microprofile-2016.9-hollowswarm.jar target/demo.war