Horizontal Pod Autoscaler
Kubernetes Advent Calendar 2016。投稿が遅れてしまいましたが、コンテナを本番サービスで利用する場合にすごく便利ではないかなと思われる Horizontal Pod Autoscaler について紹介します。
Horizontal Pod Autoscalerとは
Horizontal Pod Autoscaler(HPA)はPodに割り当てられた CPU の使用率にしたがって、Pod の数を増減させる仕組みです。この仕組みを使うと Pod として動かしているアプリケーションが高負荷になった場合に、スケールアウトして負荷分散が可能になります。 デフォルトでは 30 秒ごとに負荷状況がチェックされ、スケールアウト/ダウンが実行されます。
ここまでで想像ができるかもしれませんが、CPU の使用率にしたがってPodを増減させるということは、CPU のメトリクスを収集する機能が実装されていなければいけません。Kubernetes では Heapster を使って CPU の使用を収集します。
OpenShift でのメトリクス収集とHPAの仕組み
メトリクス収集の仕組み
OpenShiftでは、Heapsterを使ったメトリクスの収集に加えて、Hawkular Metricsと Cassandra を利用してメトリクスの蓄積と可視化を行っています。 Heapster, Hawkular Metrics, Cassandra もそれぞれコンテナとして OpenShift 上で実行されます。
メトリクス収集の仕組みを有効にしておくと、OpenShift 管理コンソールではCPU, Memory, Network IO の状況を図のような折れ線グラフで参照することが可能になります。
HPA の仕組み
OpenShift は Kubernetes を活用した Container 型のアプリケーションプラットフォームですので、HPA の仕組みも Kubernetes の HPA と同様です。
HPA が Heapster から CPU の利用状況を、Replication Controller から稼働中のレプリカ数を取得します。CPU の使用率が閾値を超えている場合にはレプリカ数を増やし、CPU の使用率が閾値を下回った場合にはレプリカ数を減らします。また、レプリカ数が変更された場合には、 Replication Controller のステータスもアップデートされます。
OpenShift では、CPU、Memory のリソース割り当ては、Pod のデプロイ方式を定義した Deployment Config で行います。例えば、CPU の割り当てが 50m 〜 100m、メモリの割り当てが 100Mi 〜 200Mi の場合には、Deployment Config は次のようになります。
resources: limits: cpu: 100m memory: 200Mi requests: cpu: 50m memory: 100Mi
レプリカ数を 1 〜 4 個、CPU 使用率の閾値を 80% とした場合、HPA は次のようになります。
spec: maxReplicas: 4 minReplicas: 1 scaleTargetRef: apiVersion: extensions/v1beta1 kind: DeploymentConfig name: php targetCPUUtilizationPercentage: 80
OpenShift での設定
OpenShift でメトリクス収集を有効にする場合は、Heapster, Hawkular Metrics, Cassandra をそれぞれデプロイするのではなく、Metrics Deployer という、Metrics収集プラグインをセットアップするためのコンテナに環境設定を任せてしまうことができます。
設定方法を紹介する前に、ちょっとはまったことを...
今回は OpenShift Origin で環境構築をしたので、Kubernetes と Heapster のバージョンの組み合わせには注意が必要でした。
Metrics Deployer は Docker Hub から origin-metrics-deloyer のコンテナイメージ(docker.io/openshift/origin-metrics-deployer)を Pull してきて利用するのですが、latest のイメージだと、Kubernetes と Heapster のAPIバージョンが不一致となってしまい、Metrics 収集機能はりようできるけれでも HPA がちゃんと動作しませんでした。正しい組み合わせは、
Kubernetes | Heapster |
---|---|
ver 1.3 | ver 1.1 |
ver 1.4 | ver 1.2 |
Kubernetes 1.3 で heapster 1.2 を使った場合には、ログ(journal)に以下のように unmarshall できないというエラーメセージが出ていました。
W1214 05:04:48.140190 112006 horizontal.go:99] Failed to reconcile hello: failed to compute desired number of replicas based on CPU utilization for DeploymentConfig/test/hello: failed to get CPU utilization: failed to get CPU consumption and request: failed to unmarshall heapster response: json: cannot unmarshal object into Go value of type []v1alpha1.PodMetrics
メトリクスプラグインの設定
OpenShift Originのインストールは https://docs.openshift.org/latest/install_config/install/advanced_install.html に従って実施します。
メトリクス収集機能は openshift-infra というProjectにデプロイします。
Project : Kubernetes の Namespace を拡張した概念
1. Metrics URL の追加
OpenShift の Master サーバの定義ファイル /etc/origin/master/master-config.yaml
に metricsPublicURL を追加します。
Hawkular のコンテナも他のアプリケーションと同様に OpenShift にデプロイされるので、他のアプリケーションと同様に OpenShift の Route 経由でアクセス可能な URL を指定します。
assetConfig: < 中 略 > metricsPublicURL: "https://hawkular-metrics.192.168.1.1.xip.io/hawkular/metrics" < 中 略 > routingConfig: subdomain: "192.168.1.1.xip.io"
2. Service Account の作成
Metrics 収集のデプロイと実行に必要な Service Accountを作成します。
oc project openshift-infra oc create -f - <<API apiVersion: v1 kind: ServiceAccount metadata: name: metrics-deployer secrets: - name: metrics-deployer API
3. ポリシーの設定
先ほど作成した metrics-deployer、heapster, hawkular 用の Service Account に権限を付与します。
Metrics Deployer 用の Service Account に、openshift-infra プロジェクトの edit 権限を付与します。
oadm policy add-role-to-user \ edit system:serviceaccount:openshift-infra:metrics-deployer
Heapster 用の Service Account に、cluster-reader 権限を付与します。
oadm policy add-cluster-role-to-user \ cluster-reader system:serviceaccount:openshift-infra:heapster
Hawkular 用の Service Account に openshift-infra プロジェクトの view 権限を付与します。
oadm policy add-role-to-user view \ system:serviceaccount:openshift-infra:hawkular \ -n openshift-infra
4. metrics-deployer の secrets を作成
oc secrets new metrics-deployer nothing=/dev/null -n openshift-infra
5. metrics-deployer の準備
kubernetes v1.3 を使っている場合には、heapster の最新版を使ってしまうと、API バージョンが不整合になってしまいます。 そこで、既存のテンプレートを少し修正して利用します。
まず、既存のテンプレートを使って metrics-deployer をデプロイするための yaml ファイルを生成します。ここでは、簡易的にデプロイするために永続化ストレージを使わないオプション USE_PERSISTENT_STORAGE=false
もつけておきます。
oc get templates -n openshift oc process metrics-deployer-template -v HAWKULAR_METRICS_HOSTNAME=hawkular-metrics.192.168.1.1.xip.io -v USE_PERSISTENT_STORAGE=false -n openshift > metrics.yaml
Template : OpenShift にアプリケーションをデプロイするための雛形。OpenShift の Cluster 全体で利用するものは openshift プロジェクトに保持されている。
6. YAML ファイルの編集
生成された metrics.yaml
ファイルを編集します。
IMAGE_VERSION を latest から v1.3.1 に変更します。
{ "name": "IMAGE_VERSION", "value": "v1.3.1" },
利用する metrics-deployer の Image Tag を latest から v1.3.1 に変更します。
"image": "openshift/origin-metrics-deployer:v1.3.1",
7. Metrics プラグインのデプロイ
編集した YAML ファイルを利用して、metrics-deployer をデプロイします。
oc create -f metric.yaml
あとは、気長に待ちましょう。。。
8. アプリケーションの設定
https://github.com/akubicharm/OpenShiftv3HandsOn/blob/master/3.3/autoscale/autoscale.md を参考に、やってみてください。
HPA で CPU の使用率を見ていくと、こんな風に使用率が表示されます。
oc get hpa -n test -w NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE php DeploymentConfig/php 10% 0% 1 4 21h NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE php DeploymentConfig/php 10% 168% 1 4 21h php DeploymentConfig/php 10% 168% 1 4 21h php DeploymentConfig/php 10% 700% 1 4 21h php DeploymentConfig/php 10% 700% 1 4 21h
終わりに
HPA のような仕組みで簡単にアプリケーションをスケールアウトできるのは、Container & Kubernetes だからこそですね。HPA を設定しておけば、急なアクセス過多になった場合でも滞りなくサービスを持続することができますので、運用の利便性も高くなりますので、ぜひ、試してみてください。
OpenShift Online Next Generationがやってきたー
Red Hatが管理・運営をしているPublicなPaaS環境であるOpenShift Onlineに、待望のOpenShift v3対応のプレビュー版がリリースされました。 環境があったらOpenShift v3 を試してみたい!と考えている方必見です。
利用方法
前提条件
- Github.com のアカウントがあること。
※Github.comのアカウントがない方はまずアカウントを登録しましょう。
利用登録登録
- https://www.openshift.com/devpreview/register.html にアクセスします
Login with GitHub ボタンをクリックします
github.com のアプリケーション認証サイトで認証可能にします
OpenShift Onlineの登録フォームで必要事項を入力して「REGISTER」ボタンをクリックします このとき、Github Username, Github ID はプリセットされています。
あとはアカウント作成完了のメールを待ちましょう
メールに、OpenShift Online (v3 版)のURLがあるのでアクセスしましょう。
アプリケーションをデプロイしよう
利用登録ができたら、早速アプリケーションをデプロイしてみましょう。ここではWebUIを使ったアプリケーションのデプロイ方法をご紹介します。
OpenShiftのクラスタ内では、プロジェクト名が一意である必要があります。もしもすでに他の人が使っている名前を指定すると、こんな風にエラーになります。
OpenShiftは、テンプレートを使って簡単にアプリケーションの実行環境を構築することができます。テンプレートはベースとなるコンテナイメージ、ビルド方式、デプロイ方式などを定義することができます。 ここでは、JBoss EAPのテンプレートを使って、JBoss のサンプルアプリケーションをデプロイします。
https://github.com/jboss-developer/jboss-eap-quickstarts/tree/6.4.x/kitchensink
- 「LOGIN WITH GITHUB」ボタンをクリックしてログイン
2.「New Project」ボタンをクリックして、プロジェクト作成を開始
Nameでプロジェクト名を指定して「Create」ボタンをクリック
テンプレート一覧から「jboss-eap64-openshift:1.3」を選択
Nameにアプリケーション名を入力、「Try it」をクリックして、Git Repository URLのテキストフィールドにGithubのリポジトリを指定 ※アプリケーション名はプロジェクト内で一意であれば良いので、好きな名前をつけましょう。
「Create」ボタンをクリックして、アプリケーションのビルド&デプロイの開始
「Continue to deploy」をクリックして Overview 画面を表示
- デプロイが終わったら、アプリケーションへのリ ンクをクリックしてアプリケーションを利用
FAQ(抜粋)
https://www.openshift.com/devpreview/register.htmlにFAQがありますので、詳細はそちらを参照してください。
- 30日でアカウントは失効しデプロイしたアプリケーションも消滅します。再び利用したい場合は、再度、登録フォームで登録します。
- 1プロジェクトにつき 2GiBメモリ、4CPU Core、 1GiBの永続化ストレージx2 のリソースが利用可能です。
- 2016/6/16 時点で、利用できる言語やミドルウェアは Node.js(0.10)、 PHP(5.5, 5.6)、Python(2.7, 3.3, 3.4)、Ruby(2.0, 2.2)、 Perl(5.16, 5.20), Java(6, 7, 8, EE)とJBoss EAPとJBoss Web Server が利用可能です。 利用できるデータベースは、MongoDB(2.4, 2.6)、MySQL(5.5, 5.6)と PostgreSQL(9.2, 9.4)です。
- コンテナ内のプロセスを root ユーザ(PID=1)で実行するコンテナは、セキュリティの制限により利用できません。
OpenShift Enterprise 3 on Microsoft Azure - RHELインストール編 -
準備するもの
準備
1.Cloud Accessの登録
(1)azureのサブスクリプションの確認
(2)Red Hat Cloud Accessのエンロールを開始
http://www.redhat.com/en/technologies/cloud-computing/cloud-access にアクセスして、Cloud Access の登録をします。 画面左下の "ENROLL" をクリックします。
(3)登録
CloudProviderとMicrosoftSubscriptionNumberを入力します。
|Name|Value| |---|---| |CloudProvicer|Microsoft Azure| |MicrosoftSubscriptionNumber|(3)で確認したazureのサブスクリプション番号| |ProductName|azureで利用するRed Hatのサブスクリプションを選択| |Quantity|導入するサブスクリプションの本数を入力|
(4)登録完了
VDH イメージ
Linux VHD の作成とアップロード | Microsoft Azure に従って、アップロードするイメージの作成。
Kickstartを使いたかったのですが、Hyper-V Manager の使い方がわからないので断念。
(1)KVMイメージをダウンロード
https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.2/x86_64/product-software から、KVM イメージをダウンロードします。
(2)qcow2からvdhの変換
Linux VHD の作成とアップロード | Microsoft Azure に従って guestfish で、root パスワードをchangemeに変更後、VDHへ変換。
virt-install で KVM イメージをインポート
sudo virt-install \ --connect qemu:///system \ --ram 1024 -n rhel_72_azure -r 2048 \ --os-type=linux \ --os-variant=rhel5 \ --disk path=/home/komizo/azure/rhel-guest-image-7.2-20151102.0.x86_64.qcow2,device=disk,bus=virtio,format=qcow2 \ --vcpus=2 \ --vnc \ --noautoconsole \ --import
virsh で仮想OSの起動
virsh -c qemu:///system console rhel_72_azure
Azure CLIのイストール
Azure SDK とツールのダウンロード | Azure からAzure CLI ツールをダウンロード
RHELのVM作成
(1)VDHイメージのアップロード
Linux VHD の作成とアップロード | Microsoft Azure の手順2に従って、イメージをアップロード
azure vm image create rhel-7.2 --location "Japan East" --os Linux rhel-guest-image-7.2-20151102.0.x86_64.vhd
1回目は container がないとエラーになるので、もう一度やったら出来ているっぽい。
azure vm image list
で一覧を表示すると、rhel-7.2 が表示されます。WebUIでは表示されないっぽい。
$ azure vm image list |grep rhel-7.2 data: rhel-7.2 User Linux undefined
(2)仮想OSの作成
azure vm create <仮想マシン名>.cloudapp.net rhel-7.2 --vm-size "Medium" guest --location "Japan East" info: Executing command vm create + Looking up image rhel-7.2 Enter VM 'guest' password:******** ← @Dmin123 Confirm password: ******** + Looking up cloud service info: cloud service <仮想マシン名> not found. + Creating cloud service + Creating VM info: vm create command OK
ここで、location か affinity-group の指定が必要なので、azure vm location list
か azure account affinity-group list
で確認します。
(3) SSH の有効化
仮想OS起動したのに、SSHできないーと悩んでいたら、SSHのエンドポイントがありませんでした。自分で追加する必要があります。
Webコンソールで「仮想マシン(クラッシック) > [仮想サーバ名] > 設定 > エンドポイント」を指定し、エンドポイントに SSH ようの 22 番ポートを指定。
(4)追加ユーザの作成
Webコンソールで「仮想マシン(クラッシック) > [仮想サーバ名] > 設定 > ユーザ」を指定し、ユーザと認証方式を設定します。
(5)ログイン
パスワード認証にした場合は、ユーザと仮想マシンを指定して ssh を実行します。
ssh -l <ユーザ名> <仮想マシン名>.cloudapp.net>
参考
1.Linux VHD の作成とアップロード | Microsoft Azure 2.Create and upload a Linux VHD | Microsoft Azure 3.Use the Azure CLI with Service Management | Microsoft Azure 4.Use SSH on Linux and Mac | Microsoft Azure
Optimizing Twelve-Factor Apps for OpenShift by Red Hat
原文 : Optimizing Twelve-Factor Apps for OpenShift by Red Hat - Red Hat Customer Portal
OpenShift Enterprise by Red Hat は、アプリケーションアーキテクチャ非依存な PaaS 基盤です。さらに、ステートフルな旧来型のアプリケーションも実行することができます。OpenShift Enterpriseは、モダンでステートレスな Twelve-Factor Apps も実行することができます。この文書では、Twelve-Factor Apps のアーキテクチャの最適化とOpenShift Enterprise へのデプロイの方法を紹介します。
Note: Twelve-Factor App は、モダンなクラウド環境にアプリケーションを構築するためのメソドロジーです。詳細は http://12factor.net/ja/ を参照してください。
Factor | Relationship |
---|---|
Codebase - コードベース | バージョン管理されている1つのコードベースと複数のデプロイ。OpenShift Enterpriseは、ソースコードリポジトリからソースコードを取得してアプリケーションのビルドとデプロイが可能。 |
Dependencies - 依存関係 | 依存関係を明示的に宣言し分離。OpenShift Enterprisは、プログラミング言語ごとの依存関係の管理システムの利用が可能。Maven、Java、CPANやその他にも多数のプログラミング言語の依存関係管理システムをサポート。 |
Config - 設定 | 設定を環境変数に格納する。OpenShift Enterpriseは、複数の環境変数の設定方法を提供。 |
Baking Service - バックエンドサービス | バックエンドサービスをアタッチされたリソースとして扱う。OpenShift Enterpriseでは、多数のバックエンドサービスを提供いしている(データベース、メッセージブローカなど)。さらに、外部リソースをアタッチすることも可能。 |
Build, release, run - ビルド、リリース、実行 | ビルド、リリース、実行の3つのステージを厳密に分離する。OpenShift Enterpriseは、厳密にビルド、リリース、実行のステージのコードベースを分離し、サードパーティのデプロイツール統合し、継続的インテグレーション/継続的デリバリ(CI/CD)が可能。 |
Processes - プロセス | アプリケーションを1つもしくは複数のステートレスなプロセスとして実行。OpenShift Enterpriseな、デプロイ可能な単位としてDockerコンテナをネイティブにサポート。Dockerコンテナはステートレスでポータブル。 |
Port binding - ポートバインディング | ポートバインディングを通してサービスを公開。OpenShift Enterpriseは、アプリケーションをポートバインディングによって公開し、サービスを公開可能。サービスな OpenShift 内部での利用も、バックエンドサービスとして外部に公開することも可能。 |
Concurrency - 並行性 | プロセスモデルによってスケールアウト。OpenShift Enterpriseは、手動/自動でアプリケーションをスケールアウトが可能で、真のウェブスケールのアプリケーションのデプロイが可能。 |
Disposability - 廃棄容易性 | 高速な軌道とグレースフルシャットダウンで堅牢性を最大化。コンテナの起動と停止。OpenShift Enterpriseはコンテナを利用し、堅牢なツールの仕組みを活用して、迅速な起動とグレースフルシャットダウンが可能。 |
Dev/prod parity - 開発/本番一致 | 開発、ステージング、本番環境をできるだけ一致させた状態を保つ。OpenShift Enterpriseの中の”環境”は名称が異なるだけ。唯一の本番環境か100ステップの本番環境かに関わらず、インフラもアプリケーションアーキテクチャも変更なし |
Logs - ログ | ログをイベントストリームとして扱う。OpenShift Enterpriseは、アプリケーション開発者が特別な操作をすることなしに、すべてのインスタンスのアプリケーションログデータを集約可能。 |
Admin process - 管理プロセス | 管理タスクを1回限りのプロセスとして実行。OpenShift Enterpriseはデプロイ前後のフックを実行する昨日を提供する。また、同様にcronのようなタスクを”管理/運用タスク”として実行可能。 |
Red Hat は、Twelve-Factor Apps には上記以外にも特徴があると考えている。
Characterristics | Relationship |
---|---|
Microservices - マイクロサービス | 業務として意味のある単位または、ビジネスの価値を提供することができる最小単位でのソフトウェアのビルド方式 |
Self Service Full Stack Infrastructure | OpenShiftは、セルフサービスでアプリケーションの実行環境の取得を可能にする。OS、コンテナ、ストレージ、ネットワーク、ミドルウェア、ソースコード管理/ビルド/デプロイツール |
Support your choice of deployment | OpenShiftは、物理サーバ・仮想サーバ、プライベートクラウド・パブリッククラウドなど、お好きな環境に構築可能! |
Enterprise Ready Containers | OpenShiftで採用しているDockerコンテナは、単に root ユーザ以外でコンテンを実行するだけではなく、SELinuxによってセキュリティを担保。さらに Red Hat は、Docker社以外でDockerの開発に最も貢献している。Red Hat Enterprise Linux が Docker の最適な実行環境となることを目標としている。 |
Immutable Infrastructure | OpenShift は、テストされたアプリケーションのバージョンを本番環境にデプロイできるような機能を提供。この機能により、コードベースのトレーサビリティが向上し、環境の違いによる障害を減らすことが可能。 |
API-Based Collaboration | 複数のサービスやアプリケーションを跨る連携は、公開されバージョン付けられたAPIを通じて利用。Red Hatは、サービスやアプリケーションを WebService、REST、JMSやその他のプロトコルやフォーマットを利用して連携するプロダクトを提供。→JBoss Fuse、JBoss AMQ |
Test Driven Development | Red Hatは、OpenShift/Kubernetesに配備されたアプリケーションをテストするためのMavenのプラグイン(fabric8-arquillian)を提供。fabric8-arquillianは、OpenShift/KubernetesのDockerのクラスタ環境で利用するためのArquillianの拡張。OpenShift/Kubernetesにデプロイされた環境のテストで利用可能。 |
Community Based Innovation | OpenShiftは、Kubernetes、Dockerなどのオープンソースのプロジェクトを活用。これらのプロジェクトへの有力な貢献者でありかつ、これらのプロジェクトの利用者でもある。Red Hatは、より良いソフトウェア開発を牽引している。 |
Continuous Integration and Continuous Deployment | OpenShiftは、CI/CDを実現可能とする Jenkins の Docker イメージを提供。 |
備忘録:OpenShift 3.1のインストール
Mac側の準備
毎回、DNSMasq を仮想環境に設定するのは手間なので、ホストOSであるMacでDNSMasqを動かして、/etc/resolver にファイルを配置することでホストOSのネットワーク環境の変化の影響を受けなくなって、かなり快適です。
Dnsmasq のインストール
http://qiita.com/ono_matope/items/cd3be40b5179731d4460
起動と停止
sudo launchctl start homebrew.mxcl.dnsmasq sudo launchctl stop homebrew.mxcl.dnsmasq
設定ファイル
/usr/local/etc/dnsmasq.conf
address=/apps.ose31/192.168.31.11
resolverの設定
/etc/resolver にdnsmasqで名前解決させたいドメイン名でファイルを作成 ex. apps.ose31 を解決したい場合は、 /etc/resolver/apps.ose31 を作成
nameserver 127.0.0.1
OS の準備
Box イメージのサイズ拡張
ディスクの拡張
VBoxManage clonehd "vagrant-virtualbox-box.vmdk" "cloned.vdi" --format vdi VBoxManage modifyhd "cloned.vdi" --resize 20480 VBoxManage clonehd "cloned.vdi" "resized.vmdk" --format vmdk
ボリュームの拡張
参考にしたサイトhttp://qiita.com/nouphet/items/fea026c03ca86ec54111 *lvdisplay, pvdisplay でストレージ確認 -fdisk でパーティション追加
# fdisk /dev/sda3 # n 新たに領域を作成する n # p 領域テーブルを表示する p # 領域番号 (1-4): 1 # 最初 シリンダ (1-1827, default 1): Enter # 終点 シリンダ または +サイズ または +サイズM または +サイズK (1-1827, default 1827): Enter # t 領域のシステム ID を変更する t # 16進数コード (L コマンドでコードリスト表示): 8e # p 領域テーブルを表示する p # w テーブルをディスクに書き込み、終了する w
ボリューム作成
pvcreate /dev/sda4 vgextend VolGroup00 /dev/sda4 lvextend -L +20Gb /dev/VolGroup00/LogVol00 resize2fs /dev/VolGroup00/LogVol00
OpenShiftのインストール
クイックインストールの場合、インストールを実行するユーザのホームディレクトリ配下に設定ファイル(~/.config/openshift/installer.cfg.yml)を配置して、インストールを開始します。
atomic-openshift-installer -u install
アンインストールは
atomic-openshift-installer -u uninstall
備忘録:Cisco UCS セットアップ
RHEL がインストールできるようになるまで
RHEL7.1 から 7.2 へのアップグレード
yum upgrade redhat-release
KVM のインストール
yum install qemu-kvm qemu-img yum install virt-manager
Vagrant インストール
この辺を参考にインストールhttps://github.com/pradels/vagrant-libvirt
wget https://releases.hashicorp.com/vagrant/1.7.4/vagrant_1.7.4_x86_64.rpm rpm -i vagrant_1.7.4_x86_64.rpm vagrant -v vagrant plugin install vagrant-libvirt yum install libxslt-devel libxml2-devel libvirt-devel libguestfs-tools-c
- vagrantup で起動しなかったので、ld のリンクを修正
alternatives --set ld /usr/bin/ld.gold
- 色々設定
groupadd libvirt usermod -aG libvirt <user> vi /etc/libvirt/libvirtd.conf # Enable following lines to skip auth unix_sock_group = "libvirt" unix_sock_ro_perms = "0777" auth_unix_ro = "none" auth_unix_rw = "none" systemctl enable libvirtd && systemctl start libvirtd
Box イメージのダウンロード
Red Hat のカスタマーポータルで配布している box イメージをゲット https://access.redhat.com/downloads/content/293/ver=2/rhel---7/2.0.0/x86_64/product-downloads
nginx でリバプロ
この辺りを参考に、見よう見まねで設定。 https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-with-ssl-as-a-reverse-proxy-for-jenkins
証明書作成
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/cert.key -out /etc/nginx/cert.crt
設定
/etc/nginx/conf.d/default.cfg を編集
server { listen 8443; server_name master.m1n2.cloud; ssl_certificate /etc/nginx/cert.crt; ssl_certificate_key /etc/nginx/cert.key; ssl on; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; access_log /var/log/nginx/master.m1n2.cloud.access.log; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # Fix the “It appears that your reverse proxy set up is broken" error. proxy_pass https://192.168.1.100:8443; proxy_read_timeout 90; proxy_redirect http:/// https://; } }
OpenShift v3 のLDAP認証
OpenShiftの設定はマニュアルに書いてありありますが、そもそもLDAPサーバの証明書の準備などなど少し手間取ったので、メモです。
LDAPサーバの準備
インストール
これらのページを参照
- http://linux-hacking-guide.blogspot.jp/2015/04/ldap-authentication-server-in-rhel7.html
- http://www.certdepot.net/rhel7-configure-ldap-directory-service-user-connection/
確認
参照サイト(2)の方法で、/etc/passwd からユーザを移行している場合は、以下のコマンドで確認できます。
ldapsearch -x cn=ldapuser01 -b dc=example,dc=com
curl "ldap://client.cloud:389/dc=example,dc=com?cn?sub?uid=ldap*" -u "cn=Manager,dc=example,dc=com" Enter host password for user 'cn=Manager,dc=example,dc=com’:redhat DN: uid=ldapuser01,ou=People,dc=example,dc=com cn: ldapuser01 password=user01ldap DN: uid=ldapuser02,ou=People,dc=example,dc=com cn: ldapuser02 password=user02ldap
TLSの利用設定とオレオレ証明書発行
証明書の発行
参照サイト (1) の以下の手順で証明書を発行します。
10) Create Server Certificate. Follow the following steps:
10.1) Create a local Certificate Authority (CA).
[root@oserver1 ~]# /etc/pki/tls/misc/CA -newca
ここで設定するホスト名は、LDAPサーバのホスト名にしました。
10.2) Create public-private key pair
[root@oserver1 ~]# openssl genrsa -out ldapserver.key
10.3) Create a certificate signing request (CSR)
[root@oserver1 ~]# openssl req -new -key ldapserver.key -out ldapserver.csr
10.4) Sign the certificate with the local CA.
[root@oserver1 ~]# openssl ca -in ldapserver.csr -out ldapserver.crt
10.5) Copy the files 'ldapserver.key' and 'ldapserver.crt' to the dir. '/etc/openldap/certs/'
10.6) We have to copy the CA cert file '/etc/pki/CA/cacert.pem' to the dir '/etc/openldap/cacerts/' on every client machine.
10.7)Create a file 'cert.ldif' with the following entries.
dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/ldapserver.crt dn: cn=config changetype: modify replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/ldapserver.key
10.8) Make entry
[root@oserver1 ~]# ldapmodify -Y EXTERNAL -H ldapi:/// -f cert.ldif
追加設定
※ここは私の勘違いがありそうな予感。。。
TLSCACerfiticationを有効にするため、/etc/openldap/slapd.d/cn=config.ldif
にolcTLSCACertificateFile: /etc/openldap/cacerts/cacert.pem
の記述を追加します。
すでに、olcTLSCACertificateFileの定義がある場合は、次のldifを使って更新します。
dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/openldap/cacerts/cacert.pem
ldaps の有効化
/etc/sysconfig/slapd
を編集してSLAPD_URLS
を変更します。
#SLAPD_URLS="ldapi:/// ldap:///" SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"
トラブルシューティング
データベースの更新エラー
色々と悪銭苦闘していると、証明書を発行し直したり。で、そんなこんなでopenssl ca
実行時にエラーが発生。
failed to update database TXT_DB error number 2
古い証明書を無効にする必要があります。
openssl ca -revoke /etc/pki/CA/newcerts/00.pem
revoke
もできない場合は、`/etc/pki/CA/index.txt を編集します。
cp -p /etc/pki/CA/index.txt{,.old} : > /etc/pki/CA/index.txt
動作確認
# openssl s_client -connect client.cloud:636 -CAfile my-ldap-ca-bundle.crt CONNECTED(00000003) depth=1 C = XX, ST = Default State, O = Default Company Ltd, OU = Default Organization, CN = client.cloud verify return:1 depth=0 C = XX, ST = Default State, O = Default Company Ltd, OU = Default Organization, CN = client.cloud verify return:1 --- Certificate chain 0 s:/C=XX/ST=Default State/O=Default Company Ltd/OU=Default Organization/CN=client.cloud i:/C=XX/ST=Default State/O=Default Company Ltd/OU=Default Organization/CN=client.cloud 1 s:/C=XX/ST=Default State/O=Default Company Ltd/OU=Default Organization/CN=client.cloud i:/C=XX/ST=Default State/O=Default Company Ltd/OU=Default Organization/CN=client.cloud --- Server certificate -----BEGIN CERTIFICATE----- MIIDbDCCAlSgAwIBAgIJANs2X7OV8HUkMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV BAYTAlhYMRYwFAYDVQQIDA1EZWZhdWx0IFN0YXRlMRwwGgYDVQQKDBNEZWZhdWx0 IENvbXBhbnkgTHRkMR0wGwYDVQQLDBREZWZhdWx0IE9yZ2FuaXphdGlvbjEVMBMG A1UEAwwMY2xpZW50LmNsb3VkMB4XDTE1MTAwNzIxNDQyNFoXDTE2MTAwNjIxNDQy NFoweTELMAkGA1UEBhMCWFgxFjAUBgNVBAgMDURlZmF1bHQgU3RhdGUxHDAaBgNV BAoME0RlZmF1bHQgQ29tcGFueSBMdGQxHTAbBgNVBAsMFERlZmF1bHQgT3JnYW5p emF0aW9uMRUwEwYDVQQDDAxjbGllbnQuY2xvdWQwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAMOUaNe/BY4cj6Q5eFZvfsKMnLCKXP6Ui6MVA4D5FuxoU7lSfUm5 VIvcxsxJNWGExPC9ZpDK0Yulpr3+FXbRhcwcZb6N5/F2UldamC4mscZT1AsfwRZJ zMN+14HGV0lfAGkaA/ctbgOw41rd0oyy+VGODRAUMFlt6kF7/VFixTITAgMBAAGj ezB5MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVk IENlcnRpZmljYXRlMB0GA1UdDgQWBBSRtt3qakgF9XS09BNnhT8GfT7C6zAfBgNV HSMEGDAWgBShCPFk9kdbkAQoYRxf46abhM6DzTANBgkqhkiG9w0BAQsFAAOCAQEA IVGB3hSQWXzAl2jHP8pHQ/s1qeRQZAKHuCp687CycikhSVgVd/VFA+VLeoTJrL7m ESdfz0L3j+jJtlWTjN9Evs4QJBfqHkIyFlxz+ud0k+2tXdggqV+Cqo1i0hi+u9F1 KZL8BhPJwnN+Z8vEhA0RaWctqbTr2jMJ0ySEHGghmaPEggkZjbJ7TCub4KCwlKVF 12XIAEr4xLx6eOlwFQRmC8TpgGkKLj2HZ/k+7ywlApbv1zJErq3C1fyB9TQNNPEX 0Wdow+uuIQIgCog65YepsVHE4cMikX0uaXZW3tyE6FcD0Y3uaU9+X5pyJ+XGosC4 i46cMdt0xQutdACKdrRteA== -----END CERTIFICATE----- subject=/C=XX/ST=Default State/O=Default Company Ltd/OU=Default Organization/CN=client.cloud issuer=/C=XX/ST=Default State/O=Default Company Ltd/OU=Default Organization/CN=client.cloud --- No client certificate CA names sent --- SSL handshake has read 2003 bytes and written 439 bytes --- New, TLSv1/SSLv3, Cipher is AES128-GCM-SHA256 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : AES128-GCM-SHA256 Session-ID: 268668D6A0B3813C46718D3502D5F028A068BE44F5A9CE23407611499A62D77D Session-ID-ctx: Master-Key: 808949603CFADCDC98FDB435495C3DE5D8A6106FD2214D891142148F5FE5CC546A552F19EF90C45BCBE02E0AAB00AE28 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1444300644 Timeout : 300 (sec) Verify return code: 0 (ok) ---
OpenShiftの認証設定
証明証の配置
LDAPサーバから証明書(/etc/openldap/cacerts/cacert.pem
)を取得して、/etc/openshift/master/my-ldap-ca-bundle.crt
に保存します。
oauthConfig: assetPublicURL: https://master.cloud:8443/console/ grantConfig: method: auto identityProviders: - name: my_ldap_provider challenge: True login: True provider: apiVersion: v1 kind: LDAPPasswordIdentityProvider attributes: id: - dn email: - mail name: - cn preferredUsername: - uid bindDN: "cn=Manager,dc=example,dc=com" bindPassword: "redhat" ca: "my-ldap-ca-bundle.crt" insecure: false url: "ldaps://client.cloud:636/dc=example,dc=com?uid"
なお、CAの認証をしない場合、ca
、insecure
、url
の設定は以下の通りです。
ca: "" insecure: true url: "ldap://client.cloud:389/dc=example,dc=com?uid"
openshift-master を再起動して、LDAP認証の完了です