【Openstack】policy.jsonについて
policy.jsonとは
- OpenStackコンポーネント毎の各種操作に必要な権限を設定するファイルのこと
- 例えば、nova createが誰でもできるとか、他人が作ったインスタンスを他人が削除できないようにとか設定が可能
- 設定ファイルは/etc/<コンポーネント>/policy.jsonにあって、Novaに関する設定なら
/etc/nova/policy.jsonにある - システムの実行中に項目を更新でき、サービスを再起動は不要
- OpenStack API 操作をした際に、ポリシーエンジンによって呼び出され評価される
例：nova/policy.json
...... "compute:create:attach_network": "", "compute:create:attach_volume": "", "compute:create:forced_host": "is_admin:True", "compute:get": "", "compute:get_all": "", "compute:get_all_tenants": "is_admin:True", ......
書式・ルール・書き方
ルール、書き方は以下サイトが大変参考になる。 複雑なので、勉強しないと。
参考
【Openstack】インスタンスOSにパスワードログインできるようする
なにがうれしいのか
- Openstackで利用するクラウド用イメージはデフォルトでパスワードログインができず、公開鍵認証でログインする必要がある
- そこでパスワード認証ができるように設定する方法をいくつか紹介する
1. password_injectionを設定する
設定方法
local_settings.pyの設定
/etc/dashboard/local_settings.py
以下を追記
OPENSTACK_HYPERVISOR_FEATURES = {
...
'can_set_password': False,
}
/etc/nova/nova.conf
以下を追記
[libvirt] inject_password=true
Injecting the administrator password
2. Userdataをインスタンス起動時に流し込む
#cloud-config
password: centos
chpasswd: { expire: False }
ssh_pwauth: True
$ nova boot --flavor <flavor-name> --image <image-id> --security-groups default --nic net-id=<net-id> --userdata user-data.txt <instance-name> # nova floating-ip-associate <instance-name> <floating-ip> # ssh centos@<floating-ip> centos@172.16.140.23's password:******
Horizonから設定する方法は以下:
その他の方法があれば追記していく
参考
OpenstackのUserdata・Metadata・Configドライブについて
Cloud-init
- クラウド上のインスタンスに各種設定を行うためのパッケージ
- 幅広いOS、ディストリビューションで利用が可能
- クラウド用OSイメージにはデフォルトでインストールされている場合が多い
Userdata
- cloud-initによる実行される
- インスタンス起動時にスクリプトを実行し、設定を入れ込むことができる
- 設定の形式は、シェルスクリプト形式(#! で始まるもの)とcloud-confg形式(#cloud-config で始まるもの)がある
- 2つの形式を同時に利用することも可能
実行方法
CLIで実行する場合
- ファイルに記述した記述をnovabootコマンド時に指定する
Usage: --user-data <user-data-file> パラメーター $ nova boot --image ubuntu-cloudimage --flavor 1 --user-data mydata.file
Horizonで実行する場合
centosのデフォルトパスワードを設定する例:
シェルスクリプトの書式
#!/bin/bash adduser --disabled-password --gecos "" clouduser setenforce 0
Cloud-configの書式
- yaml形式で定義されたコマンドとデータを記述
例:ホスト名の設定
#cloud-config hostname: mynode fqdn: mynode.example.com manage_etc_hosts: true
設定例は以下を参照
Metadata
- key=value形式の情報
- Userdataと同様にインスタンスに特定のデータを与えることができる
- インスタンス内部から
http://169.254.169.254にアクセスするといつでもデータが参照できる - user-dataもMetadataの一部として保存されている
- userdataと組み合わせてインスタンスの情報を取得して、自動化などが可能
- コマンドに
--meta <Key> <value>で値を指定する
Configドライブ
- metadataに与えたデータをディスク経由で渡すことができる
- ディスク領域としてOSにマウントされる
- ファイルを直接格納してインスタンスに渡すことも可能
- インスタンス内でネットワーク設定が行われる前にデータを渡すことができるためネットワーク設定そのものが可能
Configドライブの使い方
- nova boot コマンドに --config-drive true パラメーターを付け、コンフィグドライブを有効化する
- /etc/nova/nova.conf ファイルに
force_config_drive=trueを追加すると常にコンフィグドライブを作成するようにすることが可能
以下、configドライブを有効化し、複数のファイルを渡している例
# nova boot --config-drive true --image my-image-name --key-name mykey \ --flavor 1 --user-data ./my-user-data.txt myinstance \ --file /etc/network/interfaces=/home/myuser/instance-interfaces \ --file known_hosts=/home/myuser/.ssh/known_hosts \ --meta role=webservers --meta essential=false
- コンフィグドライブは、config-2 というボリュームラベルとなり、ゲスト OS がラベルでのディスクへのアクセスをサポートしている場合は、コンフィグドライブを /dev/disk/by-label/config-2 デバイスとしてマウントすることができる
# mkdir -p /mnt/config # mount /dev/disk/by-label/config-2 /mnt/config
参考
Openstackにおけるゾーニング・スケーリング
Openstackにおけるゾーニングとかスケーリングとかの用語がわかりにくかったので、以下にまとめてみた。
この図が分かりやすかったので参考にさせていただいた。
出展: openstack-zoning
Openstackそのものの分散
リージョン(Region)
- 地理的に離れたOpenstack環境
- 同一リージョン内では、APIエンドポイントが同一
- それぞれのリージョンで独立してコンポーネントが存在する
- エンドユーザが明示的にリージョンを指定してインスタンスの起動などを行う
- OpenStack dashboard (horizon) は、複数のリージョンを使用するよう設定が可能
- AWSでいう、ap-northeast-1/アジアパシフィック（東京）などのようなイメージに近い
セル(Cell)
- 同一リージョン内のOpenstackクラスタに複数のAQMPブローカーとデータベースを持つための仕組み
- 大規模場なOpenstack環境を想定した機能
- Novaと周辺コンポーネントをCellというまとまりにし、その上にAPIを受け付けるTop Cellをおいてツリー構造にしたのがCells
- Cellsを使うことで、このような大規模のOpenStack環境を、一つのAPIエンドポイントで見せることが可能になっている
- まだ実験的な機能だが、LibertyからCells V2 がNovaに標準搭載されているようだ
出展: Nova最新動向：スコープを広げず安定性と機能性を追求
OpenStackの次期リリース「Mitaka」、2016年4月に登場予定 多くのプロジェクトを集約
仮想マシンの分散
- Computenodeの分散のこと
- 両方ともNovaスケジューラーが管理を行う
- スケジューラーのフィルタを設定して利用する
アベイラビリティゾーン(Availability Zone)(Nova)
ホストアグリゲート(Host Aggregate)
- 管理者が明示的に定義する
- Opesntackクラスタ内(リージョン内)で仮想マシンの配置に法則を与える
- どのマシンに配置するかはユーザは意識しない
- ロースペックなサーバ群、ハイスペックなサーバ群、KVMホスト群、vmwareホスト群、開発環境ホスト群など
アベイラビリティーゾーンとホストアグリゲートの組み合わせ
- 複数のアベイラビリティーゾーンにまたがってホストアグリゲートを設定することを可能
Cinderにおけるアベイラビリティーゾーン
参考
【Openstack】プロジェクト・ユーザ・ロールについて
用語集
プロジェクト
- プロジェクトとは、ユーザーの割り当てが可能な、クラウド内の組織単位のこと
- プロジェクト=テナント=アカウントである
- ユーザーは、多数のプロジェクトに所属することは可能で最低でも 1つのプロジェクトと関連付ける必要がある
- 【Openstack】プロジェクト・ユーザ・ロールについての解説
- 仮想マシンや仮想ネットワークなどの管理単位で、ユーザーは権限のないテナント内の仮想マシンや仮想ネットワークについては操作・閲覧できない
ユーザ
- Openstackを操作するユーザのこと
- Keystoneで管理される
- インスタンスにログインするユーザとは別物
ロール(role)
- ユーザーが実行できるアクションを定義する。
- ユーザーとプロジェクトのペアに割り当てる。
- ロールのアクションは /etc/
/policy.jsonファイルに定義される - 例えば、Compute Service のロールが実行可能なアクションは /etc/nova/policy.json ファイルで定義する
オペレーション
※keystoneコマンドは廃止された
プロジェクト作成
## プロジェクト一覧 # openstack project list ## プロジェクト作成 # project create -h Usage:openstack project create --description "<description>" <project-name> # openstack project create --description "Demo Project" demo
ユーザ作成
# openstack user create --password-prompt demo-user
User Password: ******
Repeat User Password: *****
ロール割り当て
## ロール一覧 # openstack role list +----------------------------------+------------------+ | ID | Name | +----------------------------------+------------------+ | 01db5ff8fda04b1f8156f92c3dafcbb5 | ResellerAdmin | | 03ff15e6b5ce4ec0b59a61d1791cdd30 | heat_stack_user | | 897748bcc16a4ab7a4ad4689ffd04d59 | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | b865c86512f2485d924b5e12596121c6 | SwiftOperator | | c3e248d784f7493e9eacf139a14c3731 | heat_stack_owner | +----------------------------------+------------------+ ## _member_ ロールをdemoプロジェクトとdemoユーザに追加 # openstack role add --project demo --user demo-user _member_ +-----------+----------------------------------+ | Field | Value | +-----------+----------------------------------+ | domain_id | None | | id | 9fe2ff9ee4384b1894a90878d3e92bab | | name | _member_ | +-----------+----------------------------------+
クライアント環境スクリプトの作成
## クライアント環境スクリプトの作成 # vi /mnt/nfs/packstack/keystonerc_demo-user unset OS_SERVICE_TOKEN export OS_USERNAME=demo-user export OS_PASSWORD=******* export PS1='[\u@\h \W(keystone_demo-user)]\$ ' export OS_AUTH_URL=http://172.16.0.31:5000/v2.0 export OS_TENANT_NAME=demo-user export OS_IDENTITY_API_VERSION=2.0 ## クライアント環境スクリプト読込 # source /root/keystonerc_demo-user ## トークン情報を取得 # openstack token issue +------------+----------------------------------+ | Field | Value | +------------+----------------------------------+ | expires | 2016-04-19T11:46:23.396779Z | | id | 8f8ba9bb81a84229b8784e8cf8fe5046 | | project_id | bf1b0188cb884b9da04ecacaaad14705 | | user_id | dac2344e88b349208c26aa53ecae9f2f | +------------+----------------------------------+
policy.jsonについて
参考：
* Appendix A. The policy.json file
* 【OpenStackチャレンジ】 第6回 policy.json紹介編
* OpenStackのpolicy.jsonを個別ユーザ仕様にする
参考
【Opentack】プロジェクトごとにクォータを設定する
Openstackにおけるクォータとは
- クォータとは、運用上の制限値
- たとえば、各テナントに許容される容量 (GB) を制御して、単一のテナントで全ディスク容量すべてが消費されないようにすることができる
- プロジェクトレベルでクォータを有効にすることができる
- 例えば、起動できるインスタンスの数やCPUの数に制限を設けることができる
クォータ設計
インストールしたPackstackで、デフォルトのクォータ設定では、
インスタンス10個などになっているので、適切に設定を行う。
現状確認
## プロジェクト一覧を取得 # openstack project list +----------------------------------+----------+ | ID | Name | +----------------------------------+----------+ | 045278e3459a48f9812223d0d41ebd8e | services | | c9cbf3dd221a44ab966c88f26ca43bf0 | demo | | ffb0dcb85cc54f2eac7b70520cbdd5de | admin | +----------------------------------+----------+
クォータの詳細確認
Usage:openstack quota show <ID> # openstack quota show c9cbf3dd221a44ab966c88f26ca43bf0 +-----------------------+----------------------------------+ | Field | Value | +-----------------------+----------------------------------+ | backup_gigabytes | 1000 | | backups | 10 | | cores | 20 | | fixed-ips | -1 | | floating-ips | 50 | | gigabytes | 1000 | | gigabytes_nfs | -1 | | health_monitor | -1 | | ikepolicy | -1 | | injected-file-size | 10240 | | injected-files | 5 | | injected-path-size | 255 | | instances | 10 | | ipsec_site_connection | -1 | | ipsecpolicy | -1 | | key-pairs | 100 | | member | -1 | | network | 10 | | per_volume_gigabytes | -1 | | pool | 10 | | port | 50 | | project | c9cbf3dd221a44ab966c88f26ca43bf0 | | properties | 128 | | ram | 51200 | | rbac_policy | 10 | | router | 10 | | secgroup-rules | 100 | | secgroups | 10 | | server_group_members | 10 | | server_groups | 10 | | snapshots | 10 | | snapshots_nfs | -1 | | subnet | 10 | | subnetpool | -1 | | vip | 10 | | volumes | 10 | | volumes_nfs | -1 | | vpnservice | -1 | +-----------------------+----------------------------------+
サービスごとのクォータを確認するコマンド
Nova
# nova quota-defaults --tenant <Project ID>
Cinder
# cinder quota-defaults <Project ID>
設定変更
## CPUコア数を30に設定 # openstack quota set --core 30 c9cbf3dd221a44ab966c88f26ca43bf0
あとは、いい感じに設定していけばOK
Horizon上で設定する場合
- admin権限があるユーザでログインする
- ユーザ管理 > プロジェクト > アクション > クォータの変更
ただ、Horizon上で設定したほうが楽な気がした。Projectがたくさんあるとき以外は。
参考
【Openstack】Novaのインスタンス格納領域を変更する
概要
- デフォルトは/var/lib/nova/instances
- 試しに/dataに変更してみる
nova.confのstate_pathを変更
# vi /etc/nova/nova.conf #state_path=/var/lib/nova ↓ state_path=/data/nova
ディレクトリを作成
# cd /data # mkdir -p nova/instances # chown -R nova:nova nova/instances/
Cinderボリュームがアタッチできない対策
- novaの格納先を変更したことで、アタッチしたCinderボリュームがマウントできなくなるエラーが出る
- ので、以下のようにmntディレクトリを作成してオーナーをnovaに設定する
# mkdir -p /data/nova/mnt # chown nova:nova /data/nova/mnt # ls -l /data/nova ## novaサービスの再起動 # systemctl restart libvirtd.service openstack-nova-compute.service
