OpenStack」カテゴリーアーカイブ

OpenStackでVIP冗長構成を作る

このエントリはOpenStack Advent Calender 2015の12/21のエントリです。今日はOpenStack運用ではまりがちなallowed-address-pairsについて書いてみようと思います。なお本エントリの内容はOpenStack Havanaを前提に記載しています。

allowed-address-pairsとは

OpenStackでは各インスタンスにポートを紐付けることにより、インスタンスは外部と通信が可能となります。そしてポートは基本的に1ポートに1つのIP、1つのMACアドレスが割り当てられています。allowed-address-pairsとはそのポートに紐付ける拡張アドレスのようなもので、例えばAというポートに10.1.1.1のIPが紐付いている場合に、Aに対してallowed-address-pairs=10.1.1.2を紐付けると、ポートAは10.1.1.110.1.1.2の通信が可能になります。具体的な用途としてはkeepalivedなどを用いてVIPを使用した冗長構成を取る場合に、VIPをallowed-address-pairsとして利用することが多いです。

設定方法

python-neutronclientで下記のコマンドを発行することでallowed-address-pairsを追加することが出来ます。

neutron port-update xxxxx-xxxx-xxxxx --allowed-address-pairs type=dict list=true ip_address=10.1.1.2

また解除する場合は空白を設定します。

neutron port-update xxxxx-xxxx-xxxxx --allowed-address-pairs ''

やっていはいけない落とし穴

一見便利に見えるこの機能ですが、SecurityGroup(SG)のremote-groupと組み合わせて使用する場合は注意が必要です。
allowed-address-pairsの実際の動きとしてはcompute-nodeiptablesにallowed-address-pairsで指定したIPアドレスのPermitルールが追加されます。この設定を一つ間違えると全てのポリシーが許可されてしまうケースが有ります。下記の図はLAN内のinternal-serverがインターネット上のサービスexample-serviceと通信する際の通信とIPヘッダを記載しています。
sozai.001
往路のパケットに関しては特に特別なことはなく、通常のNAT通信です。しかし、戻りのパケットを見てみましょう。
sozai.002
注目すべきはnat → internal serverの通信です。ここでのfrom ipはexample serviceのipとなるため、natサーバのinterfaceからexample serviceのipで通信するためには、allowed-address-pairsに0.0.0.0/0を追加する必要があります。これはexample serviceはインターネット上のサービスであり、あらゆるIPになり得るためです。またallowed-address-pairsを追加しない場合、natサーバのinterfaceからOpenStackの管理しないIP(200.200.200.200)のパケットが送出されたことになり、デフォルトのポリシーでパケットが捨てられてしまいます。

さて、natサーバに0.0.0.0/0のallowed-address-pairsが追加されたことにより、natサーバが存在するcompute-nodeには0.0.0.0/0からのip通信が許可される設定が追加されています。この状態でSecurity Groupのremote-groupを利用した場合に、なんと0.0.0.0/0のipを持つホストからの通信が許可されてしまうという状態に陥るケースが有ります。

remote-groupとは

公式ドキュメント

リモートグループは許可されたソースの CIDR を動的に定義する方法です。ユーザーがリモートグループ (セキュリティグループ名) を指定します。これにより、指定されたリモートグループを使用する、ユーザーの他のインスタンスが動的にすべて選択されます。この動的な選択により、クラスターのそれぞれの新しいメンバーを許可する、個別のルールの必要性を軽減できます。

通常Security Groupは例えば22番ポートを10.10.10.0/24のアドレス帯からのみ許可するといったSecurity Group定義を行うのですが、10.10.10.0/24の部分をSecurity Groupの名前で定義出来たりします。例として2つのポリシーを挙げてみます。

Security Group名:ssh

  • ポート:22
  • 許可IP: 10.10.10.0/24

Security Group名:proxy

  • ポート:80
  • リモートグループ:ssh

この定義をした場合、proxyルールを持つインスタンスはsshルールが割り当てられたインスタンス全てにポート80番の通信を許可すると言った挙動をします。しかし、これは裏の動きは単純にsshルールが割り当てられたインスタンスのIPから80番ポートに対して許可するiptablesが書かれているだけに過ぎません。先のnatサーバに話を戻しましょう。

natサーバの管理するアドレス

  • eth0:100.100.100.100
  • eth1:10.10.10.10
  • allowed-address-pairs: 0.0.0.0/0

この状態でnatサーバにSecurity Group:sshを割り当てると、Security Group:proxyを持つインスタンスに対して、from ip100.100.100.100,10.10.10.10,0.0.0.0/0からの80番ポートへの通信が許可されてしまいます。お気づきでしょうか?0.0.0.0/0が許可されることで全てのIPからの許可ポリシーが追加されてしまいます。こういった自体を避けるためにNATサーバのようにallwed-address-pairsに0.0.0.0/0を持ちうるサーバのSecurity Groupは分離して管理すべきです。

最後に

一見便利に見えるallowed-address-pairs,Security Groupですが実際裏で動いているのはiptablesということもあり、シンプルな反面、小回りが効かないことも多々あります。そして運用であれ・・・通信できないな・・・というときは8〜9割はこの2つの設定が誤っていることが多いですよね。allowed-address-pairsは意外と日本語の情報が少なかったので今回駆け足ながらも記事にしてみました。国内でこれからOpenStackを触るエンジニアのハマる時間を1時間でも短くできれば幸いです。それでは明日は@mizumotodaさんで「OpenStackにコンテナの実行環境をネットワークごとデプロイする」です。有難うございました。

Pecの最近のバージョンアップ事情

どもー。
年末になり一層イケメンに磨きがかかってきました山下です。
今回は僕が開発し、メンテナンスしているOpenStackのインスタンス作成ラッパーのPecの最近のバージョンアップについてまとめてみました。

記事を書いた時点の最新バージョンは0.8.1です。

各コマンドに指定できるホスト名が動的に

例えばこれまでは、各コマンドに渡せるホスト名は一つでFQDNでした。

$ pec status example.foo.jp
Current machine status:
 example.foo.jp ACTIVE  muumuu m1.small nova comp-node.local  10.10.10.1

これが複数渡せるようになったり、

$ pec status example.foo.jp example.bar.jp
Current machine status:
 example.foo.jp ACTIVE  muumuu m1.small nova comp-node.local  10.10.10.1
 example.bar.jp ACTIVE  muumuu m1.small nova comp-node.local  20.20.20.1

ワイルドカードが利用できるようになっています。

$ pec status example*
Current machine status:
 example.foo.jp ACTIVE  muumuu m1.small nova comp-node.local  10.10.10.1
 example.bar.jp ACTIVE  muumuu m1.small nova comp-node.local  20.20.20.1

statusコマンドの高速化

こちらはキャッシュ周りのチューニングを行っていて、フェッチ回数を減らすことでこれまでと比べて爆速で表示できるようになっています。

インスタンス作成失敗時のポートリカバリ

これまではインスタンスの作成に失敗した時、既にポートが作成済みであった場合、作成されたポートはそのまま在庫として残ってしまっていましたが、リカバリで削除するように修正されています。

make start pyama-test001.test.com
image is centos-7.1_chef-12.3_puppet-3.7
flavor is m1.small
availability_zone is nova
port create start : eth0
assgin ip : 10.10.10.10
keypair is example001
create error
recovery start pyama-test001.test.com ⇐
start port recovery
port delete id:1
complete port recovery

ERBテンプレートに対応

これが最近の最大のアップデートです。
もともとyamlマージ記法に対応していたので、デフォルト値を定義すれば同じようなVMはほぼコピペで定義できました。
– Pec.yaml

_default_: &def                                                                                                                                                                                        
  os_type: centos
  tenant: your_tenant
  image: centos-7.1_chef-12.3_puppet-3.7
  flavor: m1.small
  availability_zone: nova
  networks:
    eth0:
      bootproto: static
      allowed_address_pairs:
      - 10.1.1.5/24
      ip_address: 10.1.1.0/24
      gateway: 10.1.1.254
      dns1: 8.8.8.8
# vm config
pyama-test001:
  <<: *def
pyama-test002:
  <<: *def

今回ERBテンプレートにしたことで内部にRubyのコードを埋め込むことが可能になり、こういった定義が可能になりました。
– Pec.yaml.erb

_default_: &amp;def                                                                                                                                                                                        
  os_type: centos
  tenant: your_tenant
  image: centos-7.1_chef-12.3_puppet-3.7
  flavor: m1.small
  availability_zone: nova
  networks:
    eth0:
      bootproto: static
      allowed_address_pairs:
      - 10.1.1.5/24
      ip_address: 10.1.1.0/24
      gateway: 10.1.1.254
      dns1: 8.8.8.8
# vm config
<% ["pyama-test001:", "pyama-test002:"].each do |name| %>
<%= name %>
  <<: *def
<% end %>

ERBを利用することで数100台のホスト定義も工夫すれば数行で定義できるようになったので定義の可読性も上がり、管理がしやすくなりました。
ERB化するにあたり、configコマンドで全定義の出力を差分比較することで、移行ミスを防げることが出来ると思うのでご活用下さい。

$ pec config

今後のアップデート予定

やりたいなぁと思っているのは設定ファイル内のパスワードとかを暗号化する仕組みを何か考えたい。
sshとかプロビジョニングは他のツールに任せて、Pecはいかにインスタンスを楽に作り、管理するかというところに注力していきたいと思っている。

openstackのkey-pairをAuthorizedKeysCommandに利用する

どもっす。
夏休み2日目のP山です。

スクリーンショット 2015-08-09 18.04.36

以前LDAP周りのログイン調べてた時にうっかり気づいた、sshd_configAuthorizedKeysCommand
openstackのkey-pair(ユーザーに紐づくssh公開鍵)をそのまま使えたら便利じゃないのかということで
goで書いてみました。

使い方

まず/etc/ssh/openstack-ssh.confを作成してください。

 auth_url = "http://your-api-host:35357/v2.0"
 user = "your name"
 password = "your password"
 tenant = "your tenant"
 region = "your region"(default regionOne)

あとは/etc/ssh/sshd_configに下記を追加

RSAAuthentication no
PubkeyAuthentication yes 
AuthorizedKeysFile      .ssh/authorized_keys
AuthorizedKeysCommand  /path/to/openstack-ssh
AuthorizedKeysCommandUser nobody
ChallengeResponseAuthentication no
PasswordAuthentication no
PermitRootLogin no

ここまで設定を入れたら、あとはnovaにkey-pairを登録すればSSHログインできるようになります。

$ nova keypair-add --pub-key ~/.ssh/github_rsa.pub pyama
 $ ssh 192.168.70.11 -l pyama
Last login: Sun Aug  9 08:23:57 2015 from 192.168.70.1
[pyama@client ~]$ 

利用シーンとか

前提としてログインされるサーバ上にユーザーが存在することが必要になるため
sudo権限の管理とかグループ管理のことも考えるとldapと合わせて使うのが良さそうです。
LDAPのお手軽導入は以前エントリにまとめています。
黒川温泉産のLDAPサーバでSSH公開鍵認証する

参考にさせてもらったところ

始めてGo書いたので配布周りは@deeeetさんのリポジトリや、ブログが非常に参考になりました。

例外処理とかもうちょっと綺麗に書ける気がするので勉強します。

それでは皆様よい夏休みを!

VMを作っては壊すPecというコマンドを作った。

どうも!
イケメンの申し子P山です。

現在ペパボではOpenStackを用いてプライベートクラウドを絶賛構築中でして、
その中でVMををガンガン作ってガンガン壊してニヤニヤするためにコマンド作ってみました。

インストール

$ gem install specific_install
$ gem specific_install 'git@github.com:fog/fog.git'
$ gem install pec

specific_installを利用する理由はfogというgemを使用していて、
PRがmasterに取り込まれはしているのですが、
月に一回くらいのリリースのようなので、とりあえず今はgitからmasterブランチをインストールしてます。
(今時点でgem installされるfogだとSecurity Groupが適用されない)

追記
specific_installするとうまく動かないケースがあるので、その場合は抜いてください。

使い方

サンプル設定ファイルの作成と接続先の設定

pec initコマンドを実行すると対話式で接続先のAPIの設定を行ったり、
サンプルファイルが作成されます。

$ pec init
Start Configure by OpenStack
openstack auth_uri: http://your-api-url:35357/v2.0/tokens
openstack username: pyama
openstack api_key: your_password
openstack tenant: your_tenant
Configure Complete!
create directry user_datas
create configure file Pec.yaml

設定ファイルの編集

$ cat Pec.yaml
pyama-test001.cloud.local:
  tenant: pepabo
  image: centos-7.1
  flavor: m1.small
  networks:
    eth0:
      bootproto: static
      ip_address: 10.10.10.0/24
      gateway: 10.10.10.254
      dns1: 8.8.8.8
      dns2: 8.8.8.8
  security_group:
    - default
    - ssh_from_office
  templates:
    - users/default
  user_data:
    hostname: pyama-test001
    fqdn: pyama-test001.cloud.local

設定ファイルはyaml形式で、詳細なフォーマットはこちらに記載してます。
特徴はnetworksに設定を行うと、NeutronAPIとcloud-initのcloud-configを用いて、ifcfg-ethXXXファイルを自動で作成し、かつbootprotostatic を設定して、ip_addressにネットワークアドレスを指定すると
DHCPがない環境でも空きポートからIPアドレスを自動で採番します。
bootprotodhcpを設定した場合でも必要な設定が作成され、いずれの場合でも例えばonboot: noとか任意の項目を書いておくと設定ファイルに項目が追加されます。

またcloud-initに渡すuser-dataのtemplate管理が可能でtemplatesディレクティブに、users/defaultと定義しており、このファイルの中身はこんな感じです。

$ cat user_datas/users/default.yaml 
users:
  - name: centos
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh-authorized-keys:
      - ssh-rsa koukaikagidayooolfkjfsaldkjfaldkfjlasdjfa2398320fdskajf pyama

VM個別に書きたい内容があればuser_dataディレクティブに記載すればこちらももちろん適用されます。

仮想マシンの操作

起動

pec upコマンドで定義ファイルに記載されたファイルをまとめて起動する事ができます。

$ pec up     
pyama-test001.cloud.local: assingn ip 10.10.10.1
success create for server_name:pyama-test001.cloud.local
pyama-test002.cloud.local: assingn ip 10.1.10.2
success create for server_name:pyama-test002.cloud.local

こんな感じでホスト名を指定すると、指定したホストのみの操作も可能です。

$ pec up pyama-test001.cloud.local
pyama-test001.cloud.local: assingn ip 10.10.10.1
success create for server_name:pyama-test001.cloud.local

状態確認

VMの起動状態や、各種状態を確認可能です。
割り当てられたポートのIPも見れる。

$ pec status
Current machine stasus:
 pyama-test001.cloud.local         ACTIVE     pepabo     m1.small   comp-node0001.u01.cloud.local     10.10.10.1                                 
 pyama-test002.cloud.local         uncreated                                                        

VMの削除

VMをまとめて根こそぎ削除します。
一応Yes/No確認しますが-fを引数に渡すと有無を言わさず削除も可能です。

$ pec destroy
pyama-test001.cloud.local: Are you sure you want to destroy the 'pyama-test001.cloud.local' VM? [y/N] y
server_name:pyama-test001.cloud.local is deleted!
pyama-test002.cloud.local: Are you sure you want to destroy the 'pyama-test002.cloud.local' VM? [y/N] y
server_name:pyama-test002.cloud.local is not fond!
can't destroy server:pyama-test002.cloud.local

もう、起動削除が楽しすぎて一人で423回くらい作っては壊してを繰り返してしまいました。

今後の野望

でもとりあえずテスト書きたい。

OpenStack上でLinuxルーター作る時の知見とか

ども。
昨夜は17時から飲み始め、22時前には潰れるという最高な週末でした、
P山です。

週末にかけて、OpenStackでOpenVPNのスループット取ろうと思って、
VPNルーターを作った際にハマった知見をご紹介します。

構成図

スクリーンショット 2015-04-05 18.26.27

ネットワーク

  • 仮想インターネット 210.252.100.0/24
  • SiteA-Internal 192.168.0.0/24
  • SiteB-Internal 172.16.0.0/24

ホスト

  • SiteA-vpn-host 210.252.100.2 / 192.168.0.7
  • SiteB-vpn-host 210.252.100.101 / 172.16.0.5
  • SiteB-host 172.16.0.8

やりたかったこと

SiteA-vpn-hostとSiteB-vpn-hostを仮想Internet上でVPNセッションを結び、
それぞれのサイトにhostを設置して、SiteA-hostとSiteB-host間の通信のスループットを取ろうと思っていました。

#
SiteA-host => SiteA-vpn-host <== VPN ==> SiteB-vpn-host <= SiteB-host
#
&#91;/shell&#93;

この時に、VPNセッションを結んで、SiteA-vpn-hostとSiteB-vpn-hostはVPNトンネル通して正常にtapに割り振られたIPでやりとりすることは出来ました。

しかし、ルーティングを正しく設定したとしても、SiteB-hostから送信したパケットが、SiteA-vpn-hostに到達しませんでした。


<h1>切り分け</h1>
上記から問題はSiteB-vpn-hostのルーターとしての機能に問題があると判断しました。


# sysctl -p
net.ipv4.ip_forward = 1

ルーティング設定は正常に行われています。

切り分けをわかりやすくするため、SiteB-hostからSiteA-vpn-hostへの通信を、SiteB-vpn-hostを経由するルーティングへと変更します。

SiteB-hostのルーティング設定

[root@siteb-host ~]# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.16.0.254    0.0.0.0         UG        0 0          0 eth0
10.8.0.0        172.16.0.5      255.255.255.0   UG        0 0          0 eth0
172.16.0.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.0.0     172.16.0.5      255.255.255.0   UG        0 0          0 eth0
210.252.100.0   172.16.0.5      255.255.255.0   UG        0 0          0 eth0 #このレコードを追加

この時点でSiteB-hostからSite-A-vpn-hostへpingを打つと、

[root@siteb-host ~]# ping 210.252.100.2
PING 210.252.100.2 (210.252.100.2) 56(84) bytes of data.
^C
--- 210.252.100.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

疎通がありません。

SiteB-vpn-host上でのtcpdump
仮想インターネット側

[root@siteb-vpn-host log]# tcpdump icmp -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:07:07.007524 IP host-172-16-0-8.openstacklocal > 210.252.100.2: ICMP echo request, id 916, seq 120, length 64
10:07:08.007539 IP host-172-16-0-8.openstacklocal > 210.252.100.2: ICMP echo request, id 916, seq 121, length 64
10:07:09.007531 IP host-172-16-0-8.openstacklocal > 210.252.100.2: ICMP echo request, id 916, seq 122, length 64

SiteA-vpn-host(210.252.100.2)に対して確かにパケットを送信しています。

SiteA-vpn-host上でのtcpdump

[root@sitea-vpn-host ccd]# tcpdump icmp -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

少なくとも、SiteB-vpn-hostはSiteB-hostからのパケットをSiteA-vpn-hostに送っていますが、
SiteA-vpn-hostに到達していないことから、通信経路がこのパケットの送信を許可していないことがわかります。

このことから仮説として、OpenStackのネットワークは自身が管理していないサブネットをFromIPかDestIPに持つパケットの送信を許可していないのではないかと思えます。

仮説の検証として、SiteB-vpn-hostのインターネット向けの通信をIPマスカレードしてみます。

$ systemctl start firewalld
$ firewall-cmd --zone=external --change-interface=eth0
$ firewall-cmd --zone=internal --change-interface=eth1

再度tcpdumpを取ると、

SiteB-vpn-host上でのtcpdump
仮想インターネット側

[root@siteb-vpn-host log]# tcpdump icmp -i eth0 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:22:24.591477 IP 210.252.100.101 > 210.252.100.2: ICMP echo request, id 921, seq 109, length 64
10:22:24.591778 IP 210.252.100.2 > 210.252.100.101: ICMP echo reply, id 921, seq 109, length 64
10:22:25.592018 IP 210.252.100.101 > 210.252.100.2: ICMP echo request, id 921, seq 110, length 64
10:22:25.592292 IP 210.252.100.2 > 210.252.100.101: ICMP echo reply, id 921, seq 110, length 64

先ほどと状況が変わり、SiteA-vpn-host(210.252.100.2)からパケットが戻ってくるようになりました。

SiteA-vpn-host上でのtcpdump

[root@sitea-vpn-host ccd]# tcpdump icmp -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:21:40.592578 IP 210.252.100.101 > 210.252.100.2: ICMP echo request, id 921, seq 65, length 64
10:21:40.592623 IP 210.252.100.2 > 210.252.100.101: ICMP echo reply, id 921, seq 65, length 64
10:21:41.592974 IP 210.252.100.101 > 210.252.100.2: ICMP echo request, id 921, seq 66, length 64
10:21:41.593021 IP 210.252.100.2 > 210.252.100.101: ICMP echo reply, id 921, seq 66, length 64

こちらも問題なくパケットが到達するようになりました。
ただやはり、FromIP 210.252.100.2 DestIp 172.16.0.8のパケットがSiteB-Intを通過できない問題が残るので、
何か設定がないかドキュメント読み込んでみます。

まとめ

OpenStackのNWはL3までパケットを見ているっぽくて、異なるNWセグメントのパケットを通すことが出来ないっぽい。

Ubuntu 13系から14系へバージョンアップとOpenStack構築

やりたいこととか

先日書いたロードマップの検証やるために久しぶりに家のサーバを起動した。
作りたいのはWEBサーバとNginXを持ったテナントを自由に作ったり壊したり出来たりする環境が欲しくて。
ubuntuの13.10使っていたのだけど、14系だったらコマンド数発でopenstack入るらしいのでコマンド叩いて、バージョンアップした。

root@openstack:/etc/update-manager$ do-release-upgrade

見ているとエラーがちらほら出ていましたが、家のサーバなのでガンガン進める。
再起動したところ、こんなメッセージで起動しなくなったorz

[Shell]
Nov 23 13:52:14 openstack dbus[449]: [system] Activated service \’org.freedesktop.ConsoleKit\’ failed: The permission of the setuid helper is not correct
[/Shell]

休みの日に/var/log/syslog分析してトラブルシュートする活力なんて無いので、とりあえずyoutubeでテンション上げる。

1.テンション上がったので対処する

パーミッションっぽいので、ネットで調べて下記を投入

[Shell]
chmod u+s /usr/lib/dbus-1.0/dbus-daemon-launch-helper
[/Shell]

これで起きくるかな・・・なんて思ってたら、

[Shell]
saned disabled; edit /etc/default/saned
[/Shell]

とかいって止まってる。
調べるとグラフィック系のドライバの問題らしかったです。
そもそも14系のアップデートで何個かエラー発生してたからそこが悪さしてるっぽい。

失敗してた分を強制的に入れて、グラフィックドライバの再インストールを試みる。
あとはとりあえず起きてきたらエラー対応すっかぐらいのスタンスで作業継続。

[Shell]
apt-get -f install
sudo apt-get purge nvidia-current
sudo apt-get install nvidia-current
[/Shell]

画面が起動してきたのであらためて、再度バージョンアップし直す。

[Shell]
root@openstack:/etc/update-manager$ do-release-upgrade
新しい Ubuntu のリリースをチェックしています
0% [作業中] 0% [jp.archive.ubuntu.com へ接続しています] 0% [jp.archive.ubuntu.com (160.26.2.181) へ接続しています] 0% [ヘッダの待機中です] 取得:1 ツールの署名のアップグレード [198 B]
99% [ヘッダの待機中です] 取得:2 ツールのアップグレード [1,147 kB]
100% [作業中] 1,148 kバイト/0秒 を取得しました (0 B/秒)
「utopic.tar.gz.gpg」を用いて「utopic.tar.gz」の認証を行ないます
gpg exited 2
Debug information:

gpg: fatal: can\’t open fd 6 for status output: 不正なファイル記述子です
secmem usage: 0/0 bytes in 0/0 blocks of pool 0/0

認証に失敗しました
アップグレードの認証に失敗しました。おそらくネットワークまたはサーバーの問題です。
[/Shell]

ぬぉぉぉぉーーーーーー、めんどくさすぎるぞ!!ジョジョォォォォオーーー!!!

なんて思いましたが、ここで再インストールなんてやると負けた気分になるので、
対処します。
手動でアップデートを試みます。

[Shell]
root@openstack:/etc/update-manager$ apt-get update
root@openstack:/etc/update-manager$ apt-get dist-upgrade
[/Shell]

正常終了したので念のためもう一回アップデート。

[Shell]
root@openstack:/etc/update-manager$ do-release-upgrade
新しい Ubuntu のリリースをチェックしています
新しくリリースされたものはありません
[/Shell]

やったぜ!!!
深くは調べてないですが、一回目のバージョンアップでしくじってた分が、dist-upgradeで綺麗に入った感じだと思います。

2.OpenStackインストール

出鼻くじかれましたが引き続き入れて行きます。

[Shell]
kz_yamashita@openstack:~$ sudo apt-add-repository ppa:cloud-installer/ppa
kz_yamashita@openstack:~$ sudo apt update
kz_yamashita@openstack:~$ sudo apt install cloud-installer
[/Shell]

1時間ほど放置して、こんな画面が出たらOKです。
\"キャプチャ\"

2-1.nginXのインストール

外部からアクセスするためにnginXをセットアップします。

[Shell]
kz_yamashita@openstack:~$ sudo apt install nginx
[/Shell]

2-1-1.公開鍵の作成

[Shell]
kz_yamashita@openstack:~$ openssl req -new -x509 -nodes -keyout cert.key -out cert.crt
Generating a 2048 bit RSA private key
………………………+++
…………………………………………………………………………………………………………………..+++

writing new private key to \’cert.key\’

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,

If you enter \’.\’, the field will be left blank.

Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Fukuoka
Locality Name (eg, city) []:Fukuoka
Organization Name (eg, company) [Internet Widgits Pty Ltd]:kz_yamashita
Organizational Unit Name (eg, section) []:kz_yamashita
Common Name (e.g. server FQDN or YOUR name) []:open-stack.local
Email Address []:mailaddress@fqdn
[/Shell]

2-1-2.公開鍵のインストール

[Shell]
kz_yamashita@openstack:~$ sudo install -m 400 cert.key /etc/nginx/
kz_yamashita@openstack:~$ sudo install -m 644 cert.crt /etc/nginx/
[/Shell]

2-1-3.nginXの定義ファイルを作成

[Shell]
kz_yamashita@openstack:~$ cat /etc/nginx/sites-available/cloudinstaller
server {
listen 80; # OpenStack Dashbord
location / {
proxy_pass http://10.0.3.2;
proxy_set_header Host $http_host;
}
}

server {
listen 8080; # JujuGUI
location / {
proxy_pass http://10.0.3.25;
proxy_set_header Host $http_host;
}
}

server {
listen 443 ssl;
ssl on;
ssl_certificate /etc/nginx/cert.crt;
ssl_certificate_key /etc/nginx/cert.key;
location / {
proxy_pass https://10.0.3.2;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection \”upgrade\”;
}
}
[/Shell]

2-1-4.デフォルトプロファイルの削除、コンフィグテスト、コンフィグの有効化

kz_yamashita@openstack:~$  sudo rm /etc/nginx/sites-enabled/default
kz_yamashita@openstack:~$  sudo ln -s /etc/nginx/sites-available/cloudinstaller /etc/nginx/sites-enabled/
kz_yamashita@openstack:~$  sudo service nginx configtest
 * Testing nginx configuration                                                                                                                                                                                                                     

ここまで終わるといよいよブラウザからダッシュボード、jujuGuiにアクセスできます。

\"キャプチャ\"

あとは仮想マシンの作成やら、Chefの構築やらやっていく感じですが、今日はここまで!
よい連休をお過ごし下さい。
それでは!

参考URL

Ubuntu Weekly Recipe 第341回 OpenStack環境を30分で構築する

Ubuntu 13.10にOpenStackインストール ~Glance編~

だいぶ停滞していましたが、時間が作れたので今日は
Glanceをインストールしていきます。

Glanceというのは仮想マシンのイメージを管理するサービスらしいです。
実際の動きは今後確認していきたいと思います。

今日の動画は秦基博 鱗。
何度聞いてもいい声してますねー。

まずはDBの作成から

root@openstack:~# mysql -u root -p
mysql> CREATE DATABASE glance;
Query OK, 1 row affected (0.00 sec)
mysql> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' \
    ->   IDENTIFIED BY 'GLANCE_DBPASS';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' \
    ->   IDENTIFIED BY 'GLANCE_DBPASS';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

設定ファイルにDBの接続設定を追記

root@openstack:/etc/glance# sdiff -s glance-api.conf glance-api.conf_before
#sql_connection = sqlite:////var/lib/glance/glance.sqlite     | sql_connection = sqlite:////var/lib/glance/glance.sqlite
sql_connection = mysql://glance:GLANCE_DBPASS@localhost/glanc |
root@openstack:/etc/glance# sdiff -s glance-registry.conf glance-registry.conf_before
#sql_connection = sqlite:////var/lib/glance/glance.sqlite     | sql_connection = sqlite:////var/lib/glance/glance.sqlite
sql_connection = mysql://glance:GLANCE_DBPASS@localhost/glanc |

設定入れたらテーブルを作成する

root@openstack:/etc/glance# glance-manage db_sync

#商用に入れたらぶっ飛ばされそうなパスワードなのは仕様です(キリッ

ここまで出来たら、次は先日構築したkeystoneにユーザーを作成して、
ロールを割り当てていきます。

root@openstack:/etc/glance# keystone user-create --name=glance --pass=GLANCE_DBPASS --email=glance@utlab.local
+----------+----------------------------------+
| Property |              Value               |
+----------+----------------------------------+
|  email   |        glance@utlab.local        |
| enabled  |               True               |
|    id    | 95346d4ea63c4289ab2e98c8e9337b8e |
|   name   |              glance              |
+----------+----------------------------------+
root@openstack:/etc/glance# keystone user-role-add --user=glance --tenant=service --role=admin

ユーザーが無事作成できたら先ほど触ったglance-api.conf と glance-registry.conf に
認証情報を記載する項目があるので、編集していきます。

root@openstack:/etc/glance# sdiff -s glance-api.conf glance-api.conf_before
#sql_connection = sqlite:////var/lib/glance/glance.sqlite     | sql_connection = sqlite:////var/lib/glance/glance.sqlite
sql_connection = mysql://glance:GLANCE_DBPASS@localhost/glanc |
admin_tenant_name = service                                   | admin_tenant_name = %SERVICE_TENANT_NAME%
admin_user = glance                                           | admin_user = %SERVICE_USER%
admin_password = GLANCE_DBPASS                                | admin_password = %SERVICE_PASSWORD%
root@openstack:/etc/glance# sdiff -s glance-registry.conf glance-registry.conf_before
#sql_connection = sqlite:////var/lib/glance/glance.sqlite     | sql_connection = sqlite:////var/lib/glance/glance.sqlite
sql_connection = mysql://glance:GLANCE_DBPASS@localhost/glanc |
admin_tenant_name = service                                   | admin_tenant_name = %SERVICE_TENANT_NAME%
admin_user = glance                                           | admin_user = %SERVICE_USER%
admin_password = GLANCE_DBPASS                                | admin_password = %SERVICE_PASSWORD%

続いてkeystoneにサービスとして登録します。

root@openstack:/etc/glance# keystone service-create --name=glance --type=image \
>   --description="Glance Image Service"
+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |       Glance Image Service       |
|      id     | c5e52680f2a045e7b49cfdeb59b5f69d |
|     name    |              glance              |
|     type    |              image               |
+-------------+----------------------------------+

先日も作成したエンドポイントの作成(APIのアクセスURL)

keystone endpoint-create \
  --service-id=c5e52680f2a045e7b49cfdeb59b5f69d  \
  --publicurl=http://openstack.local:9292 \
  --internalurl=http://openstack.local:9292 \
  --adminurl=http://openstack.local:9292

最後にサービスの再起動

root@openstack:/etc/glance# service glance-registry restart
glance-registry stop/waiting
glance-registry start/running, process 4710
root@openstack:/etc/glance# service glance-api restart
glance-api stop/waiting
glance-api start/running, process 4726

ここから動作試験です。
cirrosという非常に軽量なLinuxOSで確認していきます。

root@openstack:~# mkdir images
root@openstack:~# cd images/
root@openstack:~/images# wget http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img

#glanceに標準出力を介してアップロードする
root@openstack:~/images# glance image-create \
> –name=”CirrOS 0.3.2″ \
> –disk-format=qcow2 \
> –container-format=bare \
> –is-public=true < cirros-0.3.2-x86_64-disk.img +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | 64d7c1cd2b6f60c92c14662941cb7913 | | container_format | bare | | created_at | 2014-06-06T15:24:32 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | cbff1ca3-81c2-49a7-90f0-435e3c9b157c | | is_public | True | | min_disk | 0 | | min_ram | 0 | | name | CirrOS 0.3.2 | | owner | None | | protected | False | | size | 13167616 | | status | active | | updated_at | 2014-06-06T15:24:32 | +------------------+--------------------------------------+ #正常に登録されたか確認する root@openstack:~/images# glance index ID Name Disk Format Container Format Size ------------------------------------ ------------------------------ -------------------- -------------------- -------------- cbff1ca3-81c2-49a7-90f0-435e3c9b157c CirrOS 0.3.2 qcow2 bare 13167616 [/shell] ここまでがGlanceの設定です。 単純に設定するだけでしたが、内容的にはDB作って、 設定ファイルに接続定義入れて、keystoneにエンドポイント作りーの、 イメージファイルうpだけでしたね。 早く環境作ってHadoopやら検証したいので明日も早く起きたら・・・やろっかな。

Ubuntu 13.10にOpenStackインストール ~Keystone編~

今週はまさかの4連休だったりして、スノボ行く前に
OpenStack入れちゃうかと。
まずは超絶かっこいい壊れかけのアコギ、弦一本での弾き語り。

そんな感じで。。
環境はUbuntu 13.10です。
まずはこの辺を参考にパッケージをインストール

apt-get install python-mysqldb mysql-server \
rabbitmq-server \
keystone python-keystone python-keystoneclient \
glance \
nova-novncproxy novnc nova-api nova-ajax-console-proxy \
  nova-cert nova-conductor nova-consoleauth nova-doc nova-scheduler python-novaclient \
memcached libapache2-mod-wsgi openstack-dashboard \
cinder-api cinder-scheduler \
swift openssh-server rsync memcached python-netifaces python-xattr python-memcache \
neutron-plugin-openvswitch openvswitch-switch

次にデータベースの設定

root@openstack:~# mysql_secure_installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
In order to log into MySQL to secure it, we'll need the current
password for the root user.  If you've just installed MySQL, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none):
OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.
You already have a root password set, so you can safely answer 'n'.
Change the root password? [Y/n] n
 ... skipping.
By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
 ... Success!
Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
 ... Success!
By default, MySQL comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n] y
 ... Success!
Cleaning up...
All done!  If you've completed all of the above steps, your MySQL
installation should now be secure.
Thanks for using MySQL!
root@openstack:~# service mysql restart
mysql stop/waiting
mysql start/running, process 11466

KeyStone用のDBの作成とユーザーの作成…の前に、
KeyStoneとは。
OpenStackの認証を司るサービスで、以前はNoveなどのサービスごとに
持っていた認証サービスを分離したもの。
オープンソースカンファレンスの資料より

root@openstack:~# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 36
Server version: 5.5.35-0ubuntu0.13.10.2 (Ubuntu)

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE DATABASE keystone;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' \
    -> IDENTIFIED BY 'KEYSTONE_DBPASS';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' \
    -> IDENTIFIED BY 'KEYSTONE_DBPASS';
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql> quit
Bye

Ketstoneの設定
テーブルの作成と設定ファイルの編集
認証トークンの作成

root@openstack:~# openssl rand -hex 10
099aa8b08ff72ee3a431

設定ファイルの編集(diffの結果で編集箇所は察して)

root@openstack:~# diff -y --suppress-common-lines /etc/keystone/keystone.conf /etc/keystone/keystone.conf_def
admin_token = 099aa8b08ff72ee3a431                            | # admin_token = ADMIN
admin_token = 099aa8b08ff72ee3a431                            | # admin_token = ADMIN
connection = mysql://keystone:KEYSTONE_DBPASS@localhost/keyst | connection = sqlite:////var/lib/keystone/keystone.db

サービスの再起動

root@openstack:~# service keystone restart
keystone stop/waiting
keystone start/running, process 11868

テーブルの作成

root@openstack:~# keystone-manage db_sync

ユーザ、テナント、ロールの設定
テナントというのは、仮想ネットワークや仮想マシンの管理単位で、IaaSとか提供する時に、
例えばA社にはテナントA,B社にはテナントBといったように、テナント単位で
うるわけですね。

export OS_SERVICE_TOKEN=099aa8b08ff72ee3a431
export OS_SERVICE_ENDPOINT=http://openstack.localhost:35357/v2.0
root@openstack:~# keystone tenant-create --name=admin --description="Admin Tenant"
+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |           Admin Tenant           |
|   enabled   |               True               |
|      id     | 0a0c8aa731da4b238bbc3b5128f35ce8 |
|     name    |              admin               |
+-------------+----------------------------------+
root@openstack:~# keystone tenant-create --name=service --description="Service Tenant"
+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |          Service Tenant          |
|   enabled   |               True               |
|      id     | 71f83e15dd70496486558f90be378138 |
|     name    |             service              |
+-------------+----------------------------------+

管理者ユーザのパスワードとメールアドレスを設定

root@openstack:~# keystone user-create --name=admin --pass=ADMIN_PASS --email=admin@openstack.localhost
+----------+----------------------------------+
| Property |              Value               |
+----------+----------------------------------+
|  email   |    admin@openstack.localhost     |
| enabled  |               True               |
|    id    | b320b6a4aa444bcaaf30a9b76afbfdd4 |
|   name   |              admin               |
+----------+----------------------------------+

管理者ロールの作成とそのロールへのadminユーザーの追加

root@openstack:~# keystone role-create --name=admin
keystone user-role-add --user=admin --tenant=admin --role=admin+----------+----------------------------------+
| Property |              Value               |
+----------+----------------------------------+
|    id    | 3c2a249d0be44d36bf1b3c3fde6c8b51 |
|   name   |              admin               |
+----------+----------------------------------+
root@openstack:~# keystone user-role-add --user=admin --tenant=admin --role=admin

つぎにKeystoneのサービスとAPIエンドポイントの作成
APIエンドポイントとはKeystoneのサービスにアクセスするURLのことです。

root@openstack:~# keystone service-create --name=keystone --type=identity \
>   --description=&quot;Keystone Identity Service&quot;
+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |    Keystone Identity Service     |
|      id     | f24e7d4c10554feca265ab70acf933d1 |
|     name    |             keystone             |
|     type    |             identity             |
+-------------+----------------------------------+

戻ってきた値を元にエンドポイントを作成

root@openstack:~# keystone endpoint-create \
>   --service-id=f24e7d4c10554feca265ab70acf933d1 \
>   --publicurl=http://openstack.local:5000/v2.0 \
>   --internalurl=http://openstack.local:5000/v2.0 \
>   --adminurl=http://openstack.local:35357/v2.0
+-------------+-----------------------------------+
|   Property  |               Value               |
+-------------+-----------------------------------+
|   adminurl  | http://openstack.local:35357/v2.0 |
|      id     |  d603271e95684e2b872cf5e8ec4e947f |
| internalurl |  http://openstack.local:5000/v2.0 |
|  publicurl  |  http://openstack.local:5000/v2.0 |
|    region   |             regionOne             |
|  service_id |  f24e7d4c10554feca265ab70acf933d1 |
+-------------+-----------------------------------+

最後に、実際にトークンの要求を投げてみて、
値が返ってきたら設定終わり!

keystone --os-username=admin --os-password=ADMIN_PASS \
  --os-auth-url=http://openstack.local:35357/v2.0 token-get

keystone --os-username=admin --os-password=ADMIN_PASS \
  --os-tenant-name=admin --os-auth-url=http://openstack.local:35357/v2.0 token-get

なにやらこんなファイルを作っとくと、コマンド楽に打てるらしいです。

root@openstack:~# cat ~/keystonerc
export OS_USERNAME=admin
export OS_PASSWORD=ADMIN_PASS
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://openstack.local:35357/v2.0

実行のやり方

source ~/keystonerc
keystone token-get
keystone user-list

さくっと調べながら記事書きながらやって1時間位。
今週中に何とかおぉぉ~~~ってなるところまで作りこみたいと思います。
では、ジムに行ってきます♡。