designetwork

ネットワークを軸としたIT技術メモ

Proxy環境のDocker RedmineでGemインストールするための設定

f:id:daichi703n:20180421011243p:plain

Docker Redmineへのプラグイン追加の際、Gemパッケージのインストールが必要となる場合には、docker-compose.ymlでのProxy環境変数の他に.gemrcの配備が必要となる。

発生した問題と調査内容、対応方法を示す。

前提環境

Redmine Docker Image: sameersbn/docker-redmine

github.com

こちらのdocker-compose-ymlで各パラメータを設定している。

docker-redmine/docker-compose.yml at master · sameersbn/docker-redmine · GitHub

環境変数でのProxy設定

コンテナへの環境変数設定はdocker-compose.ymlで定義している。docker-compose.ymlファイルに認証情報を含むプロキシ情報は記載したくないので、ホストOSの環境変数を引き継ぐようにしている。

version: '2'

services:
  redmine:
    image: sameersbn/redmine:3.4.4-2
    container_name: redmine
    depends_on:
    - postgresql
    restart: always
    environment:
    - TZ=Asia/Tokyo
    - HTTP_PROXY=${HTTP_PROXY}
    - http_proxy=${HTTP_PROXY}
    - HTTPS_PROXY=${HTTPS_PROXY}
    - https_proxy=${HTTPS_PROXY}
    - NO_PROXY=${no_proxy}
    <snip>

問題動作

このログの通り、Gemでのインストールに失敗している。UnknownHostErrorのログより、Proxyに通信していないことが原因となっている。ホストOSでのtcpdumpからも、rubygems.orgの名前解決(DNS)要求が発生していた。(本来はDNSなしでProxy通信)

$docker-compose up
Starting postgres-redmine ... 
Starting postgres-redmine ... doneRecreating redmine        ... 
Recreating redmine        ... doneAttaching to postgres-redmine, redmine
postgres-redmine | Initializing datadir...
redmine       | Initializing logdir...
redmine       | Initializing datadir...
redmine       | Symlinking dotfiles...
redmine       | Installing configuration templates...
redmine       | Configuring redmine...
postgres-redmine | Initializing certdir...
postgres-redmine | Initializing logdir...
postgres-redmine | Initializing rundir...
postgres-redmine | Setting resolv.conf ACLs...
postgres-redmine | Creating database user: redmine
postgres-redmine | Creating database: redmine_production...
postgres-redmine | ? Granting access to redmine user...
postgres-redmine | Starting PostgreSQL 9.6...
postgres-redmine | LOG:  database system was shut down at 2018-04-19 12:22:57 UTC
postgres-redmine | LOG:  MultiXact member wraparound protections are now enabled
postgres-redmine | LOG:  database system is ready to accept connections
postgres-redmine | LOG:  autovacuum launcher started
redmine       | Configuring redmine::database...
redmine       | Configuring redmine::unicorn...
redmine       | Configuring redmine::secret_token...
redmine       | Generating a session token...
redmine       | Note:
redmine       |   All old sessions will become invalid.
redmine       |   Please specify the REDMINE_SECRET_TOKEN parameter for persistence.
redmine       |   **SHOULD** be defined if you have a load-balancing Redmine cluster.
redmine       | Configuring redmine::max_concurrent_ajax_uploads...
redmine       | Configuring redmine::sudo_mode...
redmine       | Configuring redmine::autologin_cookie...
redmine       | Configuring redmine::email_delivery...
redmine       | Configuring redmine::backups...
redmine       | Configuring redmine::backups::schedule...
redmine       | Configuring nginx...
redmine       | Configuring nginx::redmine...
redmine       | Installing plugins...
redmine       | Installing gems required by plugins...
redmine       | Gem::RemoteFetcher::UnknownHostError: no such name
redmine       | (https://rubygems.org/gems/rubyzip-1.2.1.gem)
redmine       | An error occurred while installing rubyzip (1.2.1), and Bundler cannot continue.
redmine       | Make sure that `gem install rubyzip -v '1.2.1'` succeeds before bundling.
redmine       | 
redmine       | In Gemfile:
redmine       |   write_xlsx was resolved to 0.85.3, which depends on
redmine       |     zip-zip was resolved to 0.3, which depends on
redmine       |       rubyzip
redmine exited with code 5

gemは基本的に環境変数http_proxy, https_proxyを設定していれば問題ないはずだが、私の環境では期待動作とならなかった。

.gemrcファイルをRedmineコンテナに配備する

BundleとGemインストールでProxyの設定方法が異なるという情報を見た気がするので、設定方法を変更する。上記(とtcpdumpでの切り分け)より、パッケージ情報は取得できているためBundlerは問題なく、Gem installの際に期待するProxy動作となっていないと特定できる。

そのため、GemのProxy設定の一つである.gemrcをコンテナに配備した。

$ vi redmine/config/.gemrc
http_proxy: http://<Proxy IP or FQDN>:<Proxy Port>
https_proxy: http://<Proxy IP or FQDN>:<Proxy Port>

コンテナにマウントする。(volumesでマウント指定)

services:
  redmine:
    image: sameersbn/redmine:3.4.4-2
    container_name: redmine
    depends_on:
    - postgresql
    restart: always
    environment:
    - TZ=Asia/Tokyo
    - HTTP_PROXY=${HTTP_PROXY}
    - http_proxy=${HTTP_PROXY}
    - HTTPS_PROXY=${HTTPS_PROXY}
    - https_proxy=${HTTPS_PROXY}
    - NO_PROXY=${no_proxy}
    ports:
    - "10083:80"
    volumes:
    - /srv/docker/redmine/redmine:/home/redmine/data
    - ./config/.gemrc:/home/redmine/.gemrc

問題解消

上記.gemrcのコンテナ内配備により、プラグインで必要となるGemパッケージのインストールでも正常にProxy通信が可能となった。

(失敗パターン)コンテナ起動中に.gemrcを新規作成しても効果なし

失敗パターンの一つとして、.gemrcはコンテナ起動中に追加作成しても効果がないようだった。.gemrcをマウントしてRedmineコンテナを再起動(あるいは再作成)する必要がある。

まとめ - Proxy環境のDocker RedmineでGemインストールするための設定

http_proxy/https_proxy環境変数だけでなく、.gemrcRedmineコンテナに配備することで、Redmineプラグインで追加で必要となるGemパッケージについてもProxy経由でRubygemsからダウンロードすることができるようになった。

Docker RedmineのSMTPメール送信を非同期にして遅延を解消する

f:id:daichi703n:20180420234858p:plain

Dockerで稼働させているRedmineでのチケット作成・更新時のレスポンスが悪くなり、原因調査・対応実施して問題解消したため手順メモ。

結論としては、SMTPによるメール通知をAsync(非同期)にすることで、メール送信の完了を待たずにチケットの画面が遷移するようになり、快適な動作となった。いくつかの参考記事はあるがDocker環境での情報が見つからなかったのでメモする。

前提環境

Redmine Docker Image: sameersbn/docker-redmine

github.com

こちらのdocker-compose-ymlで各パラメータを設定している。

docker-redmine/docker-compose.yml at master · sameersbn/docker-redmine · GitHub

問題動作及び状況

今回問題と感じた動作概要・状況は以下の通り。

  • チケット作成に時間がかかる(30秒程度ブラウザのタブがくるくるマーク)
  • チケット更新に時間がかかる(30秒程度ブラウザのタブがくるくるマーク)
  • 遅いときと遅くないときがある
  • プロジェクト設定更新などの動作は全く問題ない
  • サーバ負荷は全く問題ない

類似事例がいくつかあり

Redmine チケット更新 遅い」とググるとこちらなどの情報が見つかった。

mussyu1204.myhome.cx

たしかに動作に問題がない動作はメール通知がないケースだったため、本件に該当すると推定した。config/configration.ymldelivery_method: :async_smtpと設定すればよいとのことだが、問題はDocker環境での設定方法。

Docker RedmineでのSMTP設定

先述のDocker Imageでは、基本的にdocker-compose.yml環境変数を定義することにより、Redmineの各種設定が可能となっている。SMTPに関する部分の設定例は以下の通り。(抜粋)

version: '2'

services:
  redmine:
    image: sameersbn/redmine:3.4.4-2
    depends_on:
    - postgresql
    environment:
    #<snip>
    - SMTP_ENABLED=false
    - SMTP_METHOD=smtp
    - SMTP_DOMAIN=www.example.com
    - SMTP_HOST=smtp.gmail.com
    - SMTP_PORT=587
    - SMTP_USER=mailer@example.com
    - SMTP_PASS=password
    - SMTP_STARTTLS=true
    - SMTP_AUTHENTICATION=:login
    #<snip>

sameersbn/redmineのサンプルではSMTP_METHODとしては通常のsmtpが指定されている。この場合、メール送信の完了を同期処理で待つため、メール送信のシーケンスに引きずられてRedmineのチケット更新画面の応答が遅くなることがある。

これをasync_smtpに変更する。

version: '2'

services:
  redmine:
    image: sameersbn/redmine:3.4.4-2
    depends_on:
    - postgresql
    environment:
    #<snip>
    - SMTP_ENABLED=false
-   - SMTP_METHOD=smtp
+   - SMTP_METHOD=async_smtp
    - SMTP_DOMAIN=www.example.com
    - SMTP_HOST=smtp.gmail.com
    - SMTP_PORT=587
    - SMTP_USER=mailer@example.com
    - SMTP_PASS=password
    - SMTP_STARTTLS=true
    - SMTP_AUTHENTICATION=:login
    #<snip>

これにより、環境変数が展開されて期待通りにコンテナ内のconfig/configration.ymlasync_smtpの設定がされる。(分かりやすいようにasync変更による差分-/+を記載しています)

$ docker exec -it redmine /bin/bash

root@xxx:/home/redmine/redmine# cat ./config/configuration.yml
# = Redmine configuration file
<snip>
options:
  # http://guides.rubyonrails.org/action_mailer_basics.html#action-mailer-configuration
  email_delivery:
-   delivery_method: :smtp
+   delivery_method: :async_smtp
-   smtp_settings:
+   async_smtp_settings:
      enable_starttls_auto: true
      address: "smtp.gmail.com"
      port: 587
      domain: "www.example.com"
      authentication: :login
      user_name: "mailer@example.com"
      password: "password"
      tls: false

Redmineの動作遅延が解消された

上記の通りasync_smtpに変更したところ、Redmineのチケット作成・更新等のメール送信を伴う操作の応答が遅い問題が解消された。ただし、設定の通り、メール受信には若干(数秒〜数分)のタイムラグが発生するようになった。しかし、チケット操作の遅延のストレスに比べたら全く問題ない。(リアルタイム性が問われる場合はこの限りでないが...)

まとめ - Docker RedmineSMTPメール送信を非同期にして遅延を解消する

Dockerで動作させているRedmineについて、SMTPメール通知をAsync(非同期)とすることで、チケット作成・更新時に応答が遅い問題に対処することができた。

DockerでHinemosをインストールする (初期構築)

f:id:daichi703n:20180415231822p:plain

NTTデータOSSとして開発している統合監視システムのHinemosをDockerで導入してみる。

こちらにオフィシャルのDocker Imageがあるが、バージョンが古く、メンテナンスもされていないようなので、自分でDockerfileから作成する。

https://hub.docker.com/r/hinemos/hinemos-5.0-jp/

なお、今回は初期のインストールとWebGUI確認までをスコープとするため、データ永続化、可用性等は考慮していない。引き続きHinemosの設定方法等を検証していく予定。

※まだ本内容では商用利用しないでください。

HinemosインストールDockerfile作成

Hinemosのインストールで必要となる作業はオフィシャルで説明されている通り。

github.com

こちらではサンプル構成を含めて説明されている。

Hinemos ver.6.0 入門編① Hinemos ver.6.0を使ってみよう | Hinemos | クラウド時代の統合運用管理

上記を踏まえて作成したDockerfileはこちら

github.com

How to Use

以下の手順で簡単に使用開始できます。

  • 前提条件
    • Dockerがインストールされていること
    • Docker Composeがインストールされていること(オプション)

docker run で起動する

docker run -d --privileged --name hinemos-manager -p 8080:8080 -p 8081:8081 -p 161:161/udp -p 162:162/udp -p 514:514 -p 10080:80 daichi703n/hinemos-manager /sbin/init

access to http://<DockerHost IP or FQDN>:10080

解放ポートは要件によって調整の余地あり。

docker-compose up で起動する

git clone https://github.com/daichi703n/docker-hinemos-manager
cd docker-hinemos-manager
docker-compose up -d

この場合、ImageのBuildから走りますのでご了承ください。

Hinemosにアクセスする

Hinemosを起動して、Webブラウザからアクセスすると、以下のようなログイン画面が表示される。(日本語ロケール未適用)

f:id:daichi703n:20180415233208p:plain

初期User ID/Passwordはhinemos/hinemos。 Manager URLはそのままでOK。

f:id:daichi703n:20180415233150p:plain

Hinemos WebGUIへのログインが成功すると、チュートリアル画面が表示される。

f:id:daichi703n:20180415233243p:plain

あとは案内されている通り、監視対象機器を追加して運用開始できる。(画像は機器未登録)

f:id:daichi703n:20180415233407p:plain

まとめ - DockerでHinemosをインストールする (初期構築)

Dockerで統合監視システムのHinemosをデプロイした。

基本的に手順はHinemosオフィシャルのVM環境を前提としたものであるため、Dockerでのデプロイ環境には最適化できていないが、簡単に初期構築ができるようになった。

引き続き検証しアップデートしていこうと思う。

ToDo

  • PostgreSQL DBデータ永続化
  • 日本語ロケール対応
  • Hinemos Agent連携
  • 設定ファイルの外部定義化
  • etc.

OpenStackにBOSH環境を構築する

f:id:daichi703n:20180311193820p:plain

基本的にこちらに記載の通りの手順でOpenStackにBOSHをインストールする。

https://bosh.io/docs/init-openstack.html

なお、OpenStackのホストとして使用しているCentOS等でも作業可能だが、PackStackを使用した私の環境ではOpenSSLの依存関係の問題でうまく動作しなかった。そのため、CentOS7 Minimalを別に作成して作業している。

※本手順はローカル環境で実施しており、セキュリティ等の課題が残っていますのでご注意ください。

OpenStackをインストールする

PackStackを使用してOpenStackの1台構成を構築する。

OpenStackインストール手順はこちらを参照。

designetwork.hatenablog.com

なお、リソース不足のためインストールするコンポーネントは以下の通り少なくしている。

# cat ./answers.cfg | grep INSTALL
CONFIG_MARIADB_INSTALL=y
CONFIG_GLANCE_INSTALL=y
CONFIG_CINDER_INSTALL=y
CONFIG_MANILA_INSTALL=n
CONFIG_NOVA_INSTALL=y
CONFIG_NEUTRON_INSTALL=y
CONFIG_HORIZON_INSTALL=y
CONFIG_SWIFT_INSTALL=n
CONFIG_CEILOMETER_INSTALL=n
CONFIG_AODH_INSTALL=n
CONFIG_PANKO_INSTALL=n
CONFIG_SAHARA_INSTALL=n
CONFIG_HEAT_INSTALL=n
CONFIG_MAGNUM_INSTALL=n
CONFIG_TROVE_INSTALL=n
CONFIG_IRONIC_INSTALL=n
CONFIG_CLIENT_INSTALL=y
# installation was not specified in CONFIG_MARIADB_INSTALL, specify
CONFIG_LBAAS_INSTALL=n
CONFIG_NEUTRON_METERING_AGENT_INSTALL=n
CONFIG_HEAT_CFN_INSTALL=n

事前準備

実行環境としては、CentOS7 Minimalを使用する。

BOSH CLIダウンロード

BOSH CLIをこちらからダウンロードする。

https://bosh.io/docs/cli-v2.html

※最新版をダウンロードしてください

$ curl -OL https://s3.amazonaws.com/bosh-cli-artifacts/bosh-cli-3.0.1-linux-amd64
$ chmod +x ./bosh-cli-3.0.1-linux-amd64
$ sudo mv ./bosh-cli-3.0.1-linux-amd64 /usr/local/bin/bosh
$ bosh -v
version 3.0.1-712bfd7-2018-03-13T23:26:43Z

Succeeded

Yumパッケージインストール

各種パッケージのコンパイルに必要となるパッケージをインストールする。パッケージが不足している場合、後述のエラーが発生する。

依存パッケージはこちらにも記載あり。 https://bosh.io/docs/cli-env-deps.html

(BOSH Docs)
$ sudo yum install -y gcc gcc-c++ ruby ruby-devel mysql-devel postgresql-devel postgresql-libs sqlite-devel libxslt-devel libxml2-devel patch openssl
$ gem install yajl-ruby

(Option)
$ sudo yum install -y git libtool zlib-devel openssl-devel

Rubyのパッケージ不足のエラー対応はこちらが参考になりました。

blog.inouetakuya.info

こちらでも同様のやりとりがなされていた。

https://groups.google.com/a/cloudfoundry.org/forum/#!topic/bosh-dev/isJWhSqLSBY

OpenStack CLIもインストールしておく。

$ sudo yum install -y epel-release python-devel python-pip
$ sudo pip install pip --upgrade setuptools
$ sudo pip install python-openstackclient

BOSH Directorをデプロイする

以下の手順を実行してBOSH Directorをデプロイする。

ネットワーク構成

次のようなネットワークを作成しておく。詳細な内容はBOSHドキュメントに記載の通り。

Step 1: Prepare an OpenStack environment

f:id:daichi703n:20180311191945p:plain

セキュリティルールは以下の通り。ICMPなどは環境に合わせて追加する。

$ cat ./create_security_group.sh
#!/bin/sh
openstack security group create bosh
openstack security group rule create bosh --ingress --protocol tcp --dst-port 22:22 --remote-ip 0.0.0.0/0
openstack security group rule create bosh --ingress --protocol tcp --dst-port 6868:6868 --remote-ip 0.0.0.0/0
openstack security group rule create bosh --ingress --protocol tcp --dst-port 25555:25555 --remote-ip 0.0.0.0/0
openstack security group rule create bosh --egress --ethertype IPv4 --remote-ip 0.0.0.0/0
openstack security group rule create bosh --egress --ethertype IPv6 --remote-ip ::/0
openstack security group rule create bosh --ingress --protocol tcp --dst-port 1:65535 --remote-group bosh

bosh-deploymentをダウンロード

$ mkdir bosh && cd bosh
$ git init
$ git submodule add https://github.com/cloudfoundry/bosh-deployment

Gitサブモジュールとしてbosh-deploymentをダウンロードしておくと、オフィシャルのアップデートを追従しやすくなる。

auth_url, 認証情報を確認する

PackStackでOpenStackをインストールしたサーバのホームディレクトリにOpenStackのクレデンシャル(認証情報)が生成されている。

[root@openstack1 ~]# cat keystonerc_admin
unset OS_SERVICE_TOKEN
    export OS_USERNAME=admin
    export OS_PASSWORD='PASSWORD'
    export OS_AUTH_URL=http://192.168.1.202:5000/v3
    export PS1='[\u@\h \W(keystone_admin)]\$ '

export OS_PROJECT_NAME=admin
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3

keystone API v2の場合はこちら https://bosh.io/docs/openstack-keystonev2.html

各パラメータは環境により異なりますが、記事内の一貫性を確保するためにそのまま記載しています。

デプロイコマンドをshellにしておく

引数を含めたコマンドは変更を追えるようにshellスクリプトファイルにしておくと便利。

$ touch deploy_bosh.sh
$ chmod +x ./deploy_bosh.sh

デプロイShellを編集する

$ vi deploy_bosh.sh
bosh create-env bosh-deployment/bosh.yml \
    --state=state.json \
    --vars-store=creds.yml \
    -o bosh-deployment/openstack/cpi.yml \
    -o bosh-deployment/external-ip-with-registry-not-recommended.yml \
    -v director_name=bosh-1 \
    -v internal_cidr=100.64.0.0/24 \
    -v internal_gw=100.64.0.1 \
    -v internal_ip=100.64.0.5 \
    -v external_ip=192.168.1.214 \
    -v auth_url=http://192.168.1.202:5000/v3 \
    -v az=nova \
    -v default_key_name=bosh \
    -v default_security_groups=[bosh] \
    -v net_id=1cdfa900-dfbb-4f95-8571-854bee863e69 \
    --vars-file=openstack_creds.yml \
    -v openstack_domain=Default \
    -v openstack_project=admin \
    -v private_key=../id_rsa_bosh.pem \
    -v region=RegionOne \
    -o operations_file/vm_size.yml \  #option
    -o operations_file/worker_instances.yml  #option

net_idはネットワーク名ではなく、IDで指定する必要あり。

OpenStackの認証情報は別ファイルに記載しておくと、Git管理する際に除外して流出を防げる。

$ cat openstack_creds.yml
openstack_username: admin
openstack_password: 'PASSWORD'

(オプション)また、デフォルトだとインスタンスのFlavorはm1.xlargeとなっているが、私の環境はリソース不足のため、オペレーションズファイルで設定を上書きする。これによりbosh-deployment/openstack/cpi.ymlに記載されている内容を上書きする。

$ cat operations_file/vm_size.yml
- type: replace
  path: /resource_pools/name=vms/cloud_properties?
  value:
    instance_type: m1.medium
    availability_zone: ((az))

あわせて、Workerのインスタンス数をデフォルトの4から1に減らしてリソース節約する。

$ cat ./operations_file/worker_instances.yml
- type: replace
  path: /instance_groups/name=bosh/properties/director/workers
  value: 1

デプロイする

デプロイShellを実行する。私の環境では90分以上かかった...。VMが小さいとruby_openstack_cpiコンパイルに時間がかかる...。

$ ./deploy_bosh.sh
Deployment manifest: '/root/bosh/bosh-deployment/bosh.yml'
Deployment state: 'state.json'

Started validating
  Downloading release 'bosh'... Finished (00:07:40)
  Validating release 'bosh'... Finished (00:00:01)
  Downloading release 'bosh-openstack-cpi'... Finished (00:00:05)
  Validating release 'bosh-openstack-cpi'... Finished (00:00:00)
  Validating cpi release... Finished (00:00:00)
  Validating deployment manifest... Finished (00:00:00)
  Downloading stemcell... Finished (00:30:56)
  Validating stemcell... Finished (00:00:04)
Finished validating (00:38:51)

Started installing CPI
  Compiling package 'ruby_openstack_cpi/ddb0f4a3013923fb1b074454d4314264c47d33c5'... Finished (00:00:00)
  Compiling package 'bosh_openstack_cpi/f4e7f49b87ef90a8c0186602cad189c00bd508ca'... Finished (00:00:00)
  Installing packages... Finished (00:00:03)
  Rendering job templates... Finished (00:00:00)
  Installing job 'openstack_cpi'... Finished (00:00:00)
Finished installing CPI (00:00:03)

Starting registry... Finished (00:00:00)
Uploading stemcell 'bosh-openstack-kvm-ubuntu-trusty-go_agent/3468.21'... Skipped [Stemcell already uploaded] (00:00:00)

Started deploying
  Creating VM for instance 'bosh/0' from stemcell '7c81c288-593b-4b3c-8d62-89037a5de635'... Finished (00:02:04)
  Waiting for the agent on VM '47382065-ac7e-4703-a7f6-edae677f46cf' to be ready... Finished (00:04:23)
  Creating disk... Finished (00:00:08)
  Attaching disk '29f04e0c-0f13-45d8-809f-525272023100' to VM '47382065-ac7e-4703-a7f6-edae677f46cf'... Finished (00:00:59)
  Rendering job templates... Finished (00:00:03)
  Compiling package 'ruby_openstack_cpi/ddb0f4a3013923fb1b074454d4314264c47d33c5'... Finished (01:37:04)
  Compiling package 'ruby-2.4-r3/8471dec5da9ecc321686b8990a5ad2cc84529254'... Skipped [Package already compiled] (00:00:02)
  Compiling package 'mysql/b7e73acc0bfe05f1c6cbfd97bf92d39b0d3155d5'... Skipped [Package already compiled] (00:00:02)
  Compiling package 'libpq/3afb51e921e950abb31e5d039d2144591a41482d'... Skipped [Package already compiled] (00:00:00)
  Compiling package 'postgres/3b1089109c074984577a0bac1b38018d7a2890ef'... Skipped [Package already compiled] (00:00:03)
  Compiling package 'bosh_openstack_cpi/f4e7f49b87ef90a8c0186602cad189c00bd508ca'... Finished (00:01:41)
  Compiling package 'registry/2231e6d61fb5a36afafad82ea6ff49f83334c9bb'... Skipped [Package already compiled] (00:00:05)
  Compiling package 'nginx/3518a530de39c41ec65abf1194c27aadae23b711'... Skipped [Package already compiled] (00:00:01)
  Compiling package 'bosh-gcscli/fce60f2d82653ea7e08c768f077c9c4a738d0c39'... Skipped [Package already compiled] (00:00:01)
  Compiling package 'postgres-9.4/52b3a31d7b0282d342aa7a0d62d8b419358c6b6b'... Skipped [Package already compiled] (00:00:02)
  Compiling package 'davcli/2672d0a96a775f5252fef6ac7bbab3928aa41599'... Skipped [Package already compiled] (00:00:00)
  Compiling package 'verify_multidigest/8fc5d654cebad7725c34bb08b3f60b912db7094a'... Skipped [Package already compiled] (00:00:00)
  Compiling package 'director/06635593362c742ed6027270d6fbe0ddd8439650'... Skipped [Package already compiled] (00:00:07)
  Compiling package 'gonats/866cdc573ac10dd85929abb531923197486ffa95'... Skipped [Package already compiled] (00:00:01)
  Compiling package 's3cli/b6e38c619dd5575e16ea9fcabc4b7c500effdd26'... Skipped [Package already compiled] (00:00:01)
  Compiling package 'health_monitor/81dd0f6b874d009696027d43282893df4c18b2c8'... Skipped [Package already compiled] (00:00:04)
  Updating instance 'bosh/0'... Finished (00:02:07)
  Waiting for instance 'bosh/0' to be running... Failed (01:07:13)
Failed deploying (02:56:28)

Stopping registry... Finished (00:00:00)
Cleaning up rendered CPI jobs... Finished (00:00:00)

Deploying:
  Received non-running job state: 'failing'

Exit code 1

最終的にエラーになっているが、次の通り接続確認ができた。

接続確認

boshコマンドでBOSH Directorにアクセスできることを確認する。以下のように結果が返って来ればOK。

$ bosh alias-env bosh -e 192.168.1.214 --ca-cert <(bosh int creds.yml --path /director_ssl/ca)
Using environment '192.168.1.214' as client 'admin'

Name      bosh-1
UUID      ca43266f-fee1-4627-a96c-f080cc2eab91
Version   264.7.0 (00000000)
CPI       openstack_cpi
Features  compiled_package_cache: disabled
          config_server: disabled
          dns: disabled
          snapshots: disabled
User      admin

Succeeded

BOSHでデプロイする

引き続き検証予定...

まとめ - OpenStackにBOSH環境を構築する

PackStackでインストールしたOpenStackにBOSH環境を構築した。リソース不足が顕著だが、どこまで使えるか引き続き検証を進める。


トラブルシューティング

private_key no such file or directory

private_keyは、デプロイするymlファイルを起点に指定する必要がある。今回はboshディレクトリに格納しているため、一つ上の階層としてファイルを指定する必要がある。

Deployment manifest: '/home/dev/bosh/bosh-deployment/bosh.yml'
Deployment state: 'state.json'

Started validating
Failed validating (00:00:02)

Parsing installation manifest '/home/dev/bosh/bosh-deployment/bosh.yml':
  Reading private key from /home/dev/bosh/bosh-deployment/bosh:
    Opening file /home/dev/bosh/bosh-deployment/bosh:
      open /home/dev/bosh/bosh-deployment/bosh: no such file or directory

Exit code 1

DISK容量不足

$ ./deploy_bosh.sh
Deployment manifest: '/home/dev/bosh/bosh-deployment/bosh.yml'
Deployment state: 'state.json'

Started validating
  Downloading release 'bosh'... Finished (00:07:51)
  Validating release 'bosh'... Finished (00:00:06)
  Downloading release 'bosh-openstack-cpi'... Finished (00:00:09)
  Validating release 'bosh-openstack-cpi'... Finished (00:00:02)
  Validating cpi release... Finished (00:00:00)
  Validating deployment manifest... Finished (00:00:02)
  Downloading stemcell...
 Finished (00:31:36)
  Validating stemcell... Failed (00:00:14)
Failed validating (00:40:03)

Extracting stemcell from '/home/dev/.bosh/downloads/301bb47087fe66403788c852a401f42006426be9-f08706560b67b50654998e46038b6adacc8a4b46':
  reading extracted stemcell manifest in '/home/dev/.bosh/installations/0a6fbed5-08af-4e7b-7e1f-27965a2522ac/tmp/stemcell-manager107784699':
    Extracting stemcell from '/home/dev/.bosh/downloads/301bb47087fe66403788c852a401f42006426be9-f08706560b67b50654998e46038b6adacc8a4b46' to '/home/dev/.bosh/installations/0a6fbed5-08af-4e7b-7e1f-27965a2522ac/tmp/stemcell-manager107784699':
      Shelling out to tar:
        Running command: 'tar --no-same-owner -xzf /home/dev/.bosh/downloads/301bb47087fe66403788c852a401f42006426be9-f08706560b67b50654998e46038b6adacc8a4b46 -C /home/dev/.bosh/installations/0a6fbed5-08af-4e7b-7e1f-27965a2522ac/tmp/stemcell-manager107784699', stdout: '', stderr: 'tar: image: 10240 バイトのうち、9216 バイトのみ書き込みました
tar: stemcell.MF: open 不能: デバイスに空き領域がありません
tar: stemcell_dpkg_l.txt: open 不能: デバイスに空き領域がありません
tar: 前のエラーにより失敗ステータスで終了します
':
          exit status 2

Exit code 1

対策: OpenStackホストのDISKを増やす。Cinderボリュームに空きがあってもrootの容量が上限としてリミットになるのでrootも増やす。

パッケージ不足

次のようなエラーが出る場合は記事中のYumインストールを確認する。なお、OpenStackを稼働させているサーバだとYumインストールしていても読み込みがうまくできないケースがある。回避策としては、別にBOSH Deployようサーバを用意する。

基本的にchecking xxx ...noとなっているパッケージを追加インストールする。

[root@openstack1 bosh]# ./deploy_bosh.sh
Deployment manifest: '/root/bosh/bosh-deployment/bosh.yml'
Deployment state: 'state.json'

Started validating
  Downloading release 'bosh'... Finished (00:07:40)
  Validating release 'bosh'... Finished (00:00:01)
  Downloading release 'bosh-openstack-cpi'... Finished (00:00:05)
  Validating release 'bosh-openstack-cpi'... Finished (00:00:00)
  Validating cpi release... Finished (00:00:00)
  Validating deployment manifest... Finished (00:00:00)
  Downloading stemcell... Finished (00:30:56)
  Validating stemcell... Finished (00:00:04)
Finished validating (00:38:51)

Started installing CPI
  Compiling package 'ruby_openstack_cpi/ddb0f4a3013923fb1b074454d4314264c47d33c5'... Failed (00:00:01)
Failed installing CPI (00:00:01)

Installing CPI:
  Compiling job package dependencies for installation:
    Compiling job package dependencies:
      Compiling package:
        Running command: 'bash -x packaging', stdout: 'Installing yaml
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... no
checking for cc... no
checking for cl.exe... no
', stderr: '+ set -e -x
...
+ ./configure --prefix=/root/.bosh/installations/05c8688b-3c66-4365-7a4a-d0d7eee3902c/packages/ruby_openstack_cpi --disable-shared
configure: error: in `/root/.bosh/installations/05c8688b-3c66-4365-7a4a-d0d7eee3902c/tmp/bosh-release-pkg026788788/yaml-0.1.7':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details
':
          exit status 1

Exit code 1
[root@openstack1 bosh]#
+ echo 'Installing rubygems'
+ tar zxvf ruby_openstack_cpi/rubygems-2.7.3.tar.gz
+ pushd rubygems-2.7.3
+ /root/.bosh/installations/05c8688b-3c66-4365-7a4a-d0d7eee3902c/packages/ruby_openstack_cpi/bin/ruby setup.rb
/root/.bosh/installations/05c8688b-3c66-4365-7a4a-d0d7eee3902c/tmp/bosh-release-pkg077630227/rubygems-2.7.3/lib/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- zlib (LoadError)
creating stemcell (bosh-openstack-kvm-ubuntu-trusty-go_agent 3468.21):
  Executing external CPI command: '/root/.bosh/installations/05c8688b-3c66-4365-7a4a-d0d7eee3902c/jobs/openstack_cpi/bin/cpi':
    Running command: '/root/.bosh/installations/05c8688b-3c66-4365-7a4a-d0d7eee3902c/jobs/openstack_cpi/bin/cpi', stdout: 'bundler: failed to load command: /root/.bosh/installations/05c8688b-3c66-4365-7a4a-d0d7eee3902c/packages/bosh_openstack_cpi/bin/openstack_cpi (/root/.bosh/installations/05c8688b-3c66-4365-7a4a-d0d7eee3902c/packages/bosh_openstack_cpi/bin/openstack_cpi)
', stderr: 'LoadError: cannot load such file -- openssl

プロセス多重起動?

Waiting for instance 'bosh/0' to be running... が完了しないためインスタンスSSHして確認したところ、同一プロセスが複数起動しているように見えた。CPU処理が競合して非効率に思えたので、一つを残してkillした。影響は不明。

$ ssh vcap@192.168.1.214 -i ./id_rsa_bosh.pem
bosh/0:~$ ps auxf
<snip>
root     21166  0.0  0.0  19616  3308 ?        S<   06:12   0:00 /bin/bash /var/vcap/jobs/director/bin/director_ctl start
vcap     21251 11.3  1.1 142288 47684 ?        R<l  06:14   2:06  \_ ruby /var/vcap/packages/director/bin/bosh-director-migrate -c /var/vcap/jobs/director/config/director.yml
root     21238  0.0  0.0  19616  3316 ?        S<   06:14   0:00 /bin/bash /var/vcap/jobs/director/bin/director_ctl start
vcap     21318 11.3  1.1 140184 45452 ?        R<l  06:15   1:57  \_ ruby /var/vcap/packages/director/bin/bosh-director-migrate -c /var/vcap/jobs/director/config/director.yml
root     21335  0.0  0.0  19616  3372 ?        S<   06:15   0:00 /bin/bash /var/vcap/jobs/director/bin/director_ctl start
vcap     21402 11.3  1.0 136236 43620 ?        R<l  06:17   1:47  \_ ruby /var/vcap/packages/director/bin/bosh-director-migrate -c /var/vcap/jobs/director/config/director.yml
vcap     21357 10.5  0.9 132160 39820 ?        R<l  06:16   1:44 ruby /var/vcap/packages/director/bin/bosh-director-worker -c /var/vcap/jobs/director/config/worker_1.yml -i 1

bosh/0:~$ kill -9 21402 21318 

(Queens)PackStackで実用的なOpenStackスタンドアロン検証環境を構築する

OpenStack Queensがリリースされたのでインストールから初期使用までを検証する。

OpenStack環境を簡単に構築できるPackStackで、少しのカスタマイズを加えて実用的なOpenStack検証環境を構築する。

OpenStackバージョン: Queens (Version: 13.0.0)

※あくまで検証環境ですので、セキュリティ、可用性、拡張性、マルチテナント等には課題が残ります。

PackStackインストール環境の課題

PackStackでのOpenStackインストールを試す中で、以下の点が課題と感じた。

  • Cinderのデフォルト容量が20GBのみ
  • Swiftのデフォルト容量が2GBのみ

いずれもストレージの課題で、インスタンスやオブジェクト数が増えてくるとすぐ容量不足となり使用できなくなる。

前提環境

物理サーバ

使用しているサーバはこちらで選定したDell PowerEdge T110 Ⅱ

designetwork.hatenablog.com

CPU: Intel XeonE3-1220v2
RAM: 24GB
DISK: 3TB

仮想サーバ

ハイパーバイザ: ESXi 6.5 スタンドアロン
ゲストOS: CentOS7(1708) Minimal
CPU: 4vCPU (ハードウェア仮想化ON)
RAM: 16GB
DISK: 32GB(OS), 128GB(Cinder), 128GB(Swift)

DISKはOS, Cinder, Swiftそれぞれ用として複数マウントする。

CentOS7セットアップ

詳細割愛。パーティション等は自動で問題なし。

ストレージ領域作成

OpenStackで使用するストレージ用にDISK設定をする。

用途は次の通り
/dev/sdb: Cinder
/dev/sdc: Swift

DISKパーティションを作成する。

[root@openstack1 ~]# fdisk /dev/sdb
Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-268435455, default 2048): 2048
Last sector, +sectors or +size{K,M,G} (2048-268435455, default 268435455): 268435455
Partition 1 of type Linux and of size 128 GiB is set

Command (m for help): t
Hex code (type L to list all codes): 8e
Command (m for help): p
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   268435455   134216704   8e  Linux LVM

Command (m for help): w
The partition table has been altered!

[root@openstack1 ~]# fdisk /dev/sdc
Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-268435455, default 2048): 2048
Last sector, +sectors or +size{K,M,G} (2048-268435455, default 268435455): 268435455
Partition 1 of type Linux and of size 128 GiB is set

Command (m for help): t
Hex code (type L to list all codes): 8e
Command (m for help): p
   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048   268435455   134216704   8e  Linux LVM

Command (m for help): w
The partition table has been altered!

[root@openstack1 ~]# lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0   32G  0 disk
├─sda1            8:1    0    1G  0 part /boot
└─sda2            8:2    0   31G  0 part
  ├─centos-root 253:0    0 27.8G  0 lvm  /
  └─centos-swap 253:1    0  3.2G  0 lvm  [SWAP]
sdb               8:16   0  128G  0 disk
└─sdb1            8:17   0  128G  0 part
sdc               8:32   0  128G  0 disk
└─sdc1            8:33   0  128G  0 part
sr0              11:0    1 1024M  0 rom

PV, VG, LV, FileSystemを作成する。

[root@openstack1 ~]# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created.
[root@openstack1 ~]# pvcreate /dev/sdc1
  Physical volume "/dev/sdc1" successfully created.
[root@openstack1 ~]# vgcreate cinder-volumes /dev/sdb1
  Volume group "cinder-volumes" successfully created
[root@openstack1 ~]# vgcreate swift-volumes /dev/sdc1
  Volume group "swift-volumes" successfully created
[root@openstack1 ~]# lvcreate -n swift-lvs -l 100%FREE swift-volumes
  Logical volume "swift-lvs" created.
[root@openstack1 ~]# vgs
  VG             #PV #LV #SN Attr   VSize    VFree
  centos           1   2   0 wz--n-  <31.00g    4.00m
  cinder-volumes   1   0   0 wz--n- <128.00g <128.00g
  swift-volumes    1   1   0 wz--n- <128.00g <128.00g
[root@openstack1 ~]# lvs
  LV            VG             Attr       LSize    Pool
  root          centos         -wi-ao----   27.79g
  swap          centos         -wi-a-----   <3.20g
  swift-lvs     swift-volumes  -wi-ao---- <128.00g

[root@openstack1 ~]# mkfs.ext4 /dev/swift-volumes/swift-lvs
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
8388608 inodes, 33553408 blocks
1677670 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2181038080
1024 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

[root@openstack1 ~]# lsblk
NAME                          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                             8:0    0   32G  0 disk
├─sda1                          8:1    0    1G  0 part /boot
└─sda2                          8:2    0   31G  0 part
  ├─centos-root               253:0    0 27.8G  0 lvm  /
  └─centos-swap               253:1    0  3.2G  0 lvm  [SWAP]
sdb                             8:16   0  128G  0 disk
└─sdb1                          8:17   0  128G  0 part
sdc                             8:32   0  128G  0 disk
└─sdc1                          8:33   0  128G  0 part
  └─swift--volumes-swift--lvs 253:2    0  128G  0 lvm
sr0                            11:0    1 1024M  0 rom
[root@openstack1 ~]# df -hT
Filesystem              Type      Size  Used Avail Use% Mounted on
/dev/mapper/centos-root xfs        28G  1.2G   27G   5% /
devtmpfs                devtmpfs  7.8G     0  7.8G   0% /dev
tmpfs                   tmpfs     7.8G     0  7.8G   0% /dev/shm
tmpfs                   tmpfs     7.8G  8.6M  7.8G   1% /run
tmpfs                   tmpfs     7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda1               xfs      1014M  171M  844M  17% /boot
tmpfs                   tmpfs     1.6G     0  1.6G   0% /run/user/0

(追記)DISK認識バグ

Horizon等で見えるLocal Disk Usageはこの構成の場合はcentos-rootの27GBになってしまい、cinder-volumeの全容量を使用できない...
暫定対処としては、rootを大きく作成して容量を大きく見せれば回避はできる。(別途本対処は必要)

If I boot from a Volume (cinder), why appears as I'm using Compute's Local Disk Usage? - Ask OpenStack: Q&A Site for OpenStack Users and Developers

NIC情報取得

OpenStackインストールに必要となるため、NICの情報を取得しておく。この場合ens192という情報が必要となる。

[root@openstack1 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:0c:29:39:e7:cf brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.201/24 brd 192.168.1.255 scope global ens192
       valid_lft forever preferred_lft forever
    inet6 fe80::a952:db6b:fd90:a906/64 scope link
       valid_lft forever preferred_lft forever

OpenStackインストール

PackStackを使用してOpenStackをインストールする。インストール方法は基本的にこちらを参照。

https://www.rdoproject.org/install/packstack/

言語設定

LANG=en_US.utf-8
LC_ALL=en_US.utf-8

CentOS各種パッケージを最新化

# yum update -y

ネットワーク環境設定

# systemctl disable firewalld
# systemctl stop firewalld
# systemctl disable NetworkManager
# systemctl stop NetworkManager
# systemctl enable network
# systemctl start network
# setenforce 0
# vi /etc/selinux/config
SELINUX=permissive

PackStackインストール・answer-file生成

# yum install -y python-setuptools
# yum install -y centos-release-openstack-queens
# yum update -y
# yum install -y openstack-packstack
# packstack --gen-answer-file=answers.cfg

python-setuptoolsがないとエラー発生

2018/3/6時点では以下のエラーが発生した。

# packstack --gen-answer-file=answers.cfg
ERROR:root:Failed to load plugin from file ssl_001.py
ERROR:root:Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/packstack/installer/run_setup.py", line 923, in loadPlugins
    moduleobj = __import__(moduleToLoad)
  File "/usr/lib/python2.7/site-packages/packstack/plugins/ssl_001.py", line 20, in <module>
    from OpenSSL import crypto
  File "/usr/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
    from OpenSSL import rand, crypto, SSL
  File "/usr/lib/python2.7/site-packages/OpenSSL/crypto.py", line 13, in <module>
    from cryptography.hazmat.primitives.asymmetric import dsa, rsa
  File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/primitives/asymmetric/rsa.py", line 14, in <module>
    from cryptography.hazmat.backends.interfaces import RSABackend
  File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/backends/__init__.py", line 7, in <module>
    import pkg_resources
ImportError: No module named pkg_resources

ERROR:root:Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/packstack/installer/run_setup.py", line 988, in main
    loadPlugins()
  File "/usr/lib/python2.7/site-packages/packstack/installer/run_setup.py", line 931, in loadPlugins
    raise Exception("Failed to load plugin from file %s" % item)
Exception: Failed to load plugin from file ssl_001.py


ERROR : Failed to load plugin from file ssl_001.py

こちらにある通り。

Bug 1526064 – python-cryptography should depend on python-setuptools

# yum install -y python-setuptools

でエラー解消する。

answer-file編集

生成されたanswer-fileを以下のように編集する。

# diff ./answers.cfg_default ./answers.cfg

< CONFIG_CINDER_VOLUMES_SIZE=20G
---
> CONFIG_CINDER_VOLUMES_SIZE=120G

< CONFIG_NEUTRON_OVS_BRIDGE_IFACES=
---
> CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:ens192

< CONFIG_SWIFT_STORAGES=
---
> CONFIG_SWIFT_STORAGES=/dev/swift-volumes/swift-lvs

< CONFIG_SWIFT_STORAGE_SIZE=2G
---
> CONFIG_SWIFT_STORAGE_SIZE=120G

< CONFIG_PROVISION_DEMO=y
---
> CONFIG_PROVISION_DEMO=n

CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:<ip aで確認したインタフェース>

CONFIG_SWIFT_STORAGES=<作成したLV>

cinderはVG名をcinder-volumesとしておけばここの個別設定不要。

少し古い情報だが、編集内容は以下が参考になる。

access.redhat.com

OpenStackインストール

answerファイルを読み込んでOpenStackをインストールする。puppetで各種インストールが走る。私の環境では30分程度かかった。

# packstack --answer-file=./answers.cfg

セッション断が起こりうるためコンソールから実行するのを推奨する。完了したら再起動する。

# reboot

OpenStack初期セットアップ

http://<IP or FQDN>にアクセスするとOpenStackのダッシュボードが表示される。

クレデンシャル(認証情報)はサーバrootに生成されている。

# cat ~/keystonerc_admin
unset OS_SERVICE_TOKEN
    export OS_USERNAME=admin
    export OS_PASSWORD='PASSWORD'
    export OS_AUTH_URL=http://192.168.1.201:5000/v3
    export PS1='[\u@\h \W(keystone_admin)]\$ '

export OS_PROJECT_NAME=admin
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3

キーペアを生成する

OpenStackでデプロイするVMへのアクセスはSSH秘密鍵が必要になる。 キーペアを生成して、ローカルに保存しておく。

f:id:daichi703n:20180304182756p:plain

ネットワークを作成する

今回はホストのCentOSをブリッジングして外部ネットワークと直接接続する。設定は次のようになる。(設定プロンプト割愛)

まずネットワークを作成する。 外部ネットワーク:true, ネットワークタイプ:フラット, 物理ネットワーク:extnet とする。

f:id:daichi703n:20180304182836p:plain

その中にサブネットを作成する。DHCPも有効にしておく。

f:id:daichi703n:20180304182909p:plain

セキュリティグループにICMP・SSH追加

セキュリティグループdefaultにALL ICMP, SSHを0.0.0.0/0で追加しておく。

f:id:daichi703n:20180304182924p:plain

イメージをダウンロードし登録する

OSのイメージをダウンロードする。とりあえずOpenStackテスト用のCirrOSを使用する。

OpenStack Docs: イメージの入手

なお、こちらから直接ダウンロードできる。(v0.4.0)

http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img

プロジェクト > コンピュート > イメージ から、ダウンロードしたイメージを登録する。

CirrOSインスタンスを起動する

登録したCirrOSイメージのインスタンスを起動する。

イメージ > cirros > 起動

フレーバーはm1.tinyで起動可能。ネットワーク、セキュリティグループ、キーペアは上記で作成したものを指定する。

作成されたインスタンスのログを確認する。以下のような出力になっていればOK。

=== system information ===
Platform: RDO OpenStack Compute
Container: none
Arch: x86_64
CPU(s): 1 @ 3092.836 MHz
Cores/Sockets/Threads: 1/1/1
Virt-type: AMD-V
RAM Size: 488MB
Disks:
NAME  MAJ:MIN       SIZE LABEL         MOUNTPOINT
vda   253:0   1073741824               
vda1  253:1   1064287744 cirros-rootfs /
vda15 253:15     8388608               
=== sshd host keys ===
-----BEGIN SSH HOST KEY KEYS-----
ssh-rsa AAAAB3...Tb root@cirros
ssh-dss AAAAB3...== root@cirros
-----END SSH HOST KEY KEYS-----
=== network info ===
if-info: lo,up,127.0.0.1,8,,
if-info: eth0,up,192.168.1.217,24,fe80::f816:3eff:fe5d:26c4/64,
ip-route:default via 192.168.1.5 dev eth0 
ip-route:192.168.1.0/24 dev eth0  src 192.168.1.217 
ip-route6:fe80::/64 dev eth0  metric 256 
ip-route6:unreachable default dev lo  metric -1  error -101
ip-route6:ff00::/8 dev eth0  metric 256 
ip-route6:unreachable default dev lo  metric -1  error -101
=== datasource: None None ===
=== cirros: current=0.4.0 uptime=260.09 ===
  ____               ____  ____
 / __/ __ ____ ____ / __ \/ __/
/ /__ / // __// __// /_/ /\ \ 
\___//_//_/  /_/   \____/___/ 
   http://cirros-cloud.net


login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root.
cirros login: 

CirrOSにSSH接続する

インスタンス情報に表示されているIPアドレス(=上記ログに表示のIPアドレス)にSSH接続する。パスワードはログ中に記載の通り。

$ ssh cirros@192.168.1.217

cirros@192.168.1.217's password: gocubsgo
$ pwd
/home/cirros
$ uname -a
Linux cirros 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 GNU/Linux

CirrOSにSSHアクセス・ログインできた。

SSHキーペアでログインできるようにする

上記のままだと登録したSSHキーペアでログインできない。(私の環境ではできなかった)

追加設定でSSH公開鍵によるログインを可能とする。

internalネットワーク・ルータ作成

下図のcirros-03の状態を作る。(cirros-01, 02構成ではSSHキーペアが登録されない)

f:id:daichi703n:20180304190206p:plain

設定概要は次の通り。

内部ネットワークを作成する。私は最終的にBOSH検証環境を構築したいためbosh-internalとしたが名前はなんでも良い。

f:id:daichi703n:20180304185734p:plain

あわせてサブネットも作成する。内部用ということでシェアードアドレスを割り当てる。

f:id:daichi703n:20180304185819p:plain

ルータを作成し、それぞれのネットワークに接続する。

f:id:daichi703n:20180304190038p:plain

Floating IPを作成する。

f:id:daichi703n:20180304190307p:plain

この環境で、internalネットワークを指定してインスタンスを起動、Associate Floating IPでIPアドレスを割り当てればOK。

SSH秘密鍵を指定してSSH接続

キーペアで正常にインスタンスに登録され、秘密鍵を使用してパスワードなしSSHログインが可能となる。

# ssh -i <key> cirros@192.168.1.212
The authenticity of host '192.168.1.212 (192.168.1.212)' can't be established.
ECDSA key fingerprint is SHA256:xxx.
ECDSA key fingerprint is MD5:xxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.212' (ECDSA) to the list of known hosts.
$ uname -a
Linux cirros-03 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 GNU/Linux
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000
    link/ether fa:16:3e:cb:11:e0 brd ff:ff:ff:ff:ff:ff
    inet 100.64.0.19/24 brd 100.64.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fecb:11e0/64 scope link
       valid_lft forever preferred_lft forever

まとめ - PackStackで実用的なOpenStackスタンドアロン検証環境を構築する

OpenStack環境を簡単に構築できるPackStackで、少しだけ実用的なOpenStack検証環境を構築した。

  • Cinderのデフォルト容量が20GBのみ
  • Swiftのデフォルト容量が2GBのみ

というストレージ関連の課題を解消し、検証で使用可能な環境を構築することができた。

OpenStack外部ネットワーク構成のときにSSHキーペアがインポートされない

f:id:daichi703n:20180304234757p:plain

検証用OpenStackを構築して、CirrOSをデプロイしたときに、SSHキーペアがインポートされず、インスタンスSSH公開鍵方式によるログインができない事象が発生した。OSはCirrOSもDebianでも同様。

発生事象

起動したインスタンス設定したSSHキーペアの秘密鍵でログインできない
(パスワード認証に切り替わりパスワード入力を要求される)

OpenStackバージョン:Pike (Version: 12.0.2)

構成概要

OpenStackはPackStackを使用してCentOS7上にスタンドアロン環境で構築している。

インストールした手順はこちら

designetwork.hatenablog.com

エラーログ

事象が発生した際の起動ログの抜粋は以下の通り。

...
udhcpc (v1.23.2) started
Sending discover...
Sending select for 192.168.1.212...
Lease of 192.168.1.212 obtained, lease time 86400
checking http://169.254.169.254/2009-04-04/instance-id
failed 1/20: up 20.64. request failed    //FAILED MESSEAGE//
failed 2/20: up 33.14. request failed    //FAILED MESSEAGE//
...
failed 20/20: up 252.96. request failed    //FAILED MESSEAGE//
failed to read iid from metadata. tried 20
failed to get instance-id of datasource
Top of dropbear init script
Starting dropbear sshd: failed to get instance-id of datasource
OK

...
=== cirros: current=0.4.0 uptime=260.09 ===
  ____               ____  ____
 / __/ __ ____ ____ / __ \/ __/
/ /__ / // __// __// /_/ /\ \ 
\___//_//_/  /_/   \____/___/ 
   http://cirros-cloud.net


login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root.
cirros login: 

http://169.254.169.254/2009-04-04/instance-id へのアクセスを試行して、20回失敗して諦めている。

OpenStackコミュニティの情報

上記エラーはインスタンスのMetadata設定に失敗したもので、その中にSSH公開鍵インポートが含まれている。 なお、SSH公開鍵はインポートされていないものの、OS自体は正常に起動し、パスワード認証でログインすることは可能。(CirrOSはデフォルトパスワードあり)

コミュニティでも同様にSSHキーペアでログインできない系の質問がいくつかある。NOVA_METADATA_IPの設定やnova-apiサービス起動、Firewall設定が起因していることが疑われているが、上記記事で記載したPackStack手順でインストールした場合はいずれも正しく設定されていた。

ask.openstack.org

ask.openstack.org

ask.openstack.org

# vi /etc/neutron/metadata_agent.ini

nova_metadata_ip=<Master IP>  //設定済み

ポートも空いている。

# ss -tuna | grep 8775
tcp    LISTEN     0      128       *:8775                  *:*

キーペア生成後にKeystoneやNovaの再起動が必要という情報もあり再起動したが状態変わらず...

ネットワーク構成の見直しでSSH公開鍵認証できるようになった

極力シンプルな環境で検証したかったため、当初は、extnetと紐付けてブリッジ接続によるフラットなネットワークを使用していた。下図の青のdesignetが自宅内のネットワークの一部で、そこにフラット接続していた。私の環境ではこのネットワーク構成見直しによりSSHキーペアの問題が解消した。

下図オレンジ部分のinternalネットワークを追加構築し、Routerで接続し、フロントからのアクセスはFloating IPを使用して接続する構成とした。

f:id:daichi703n:20180305001633p:plain

これにより、指定したSSHキーペアの公開鍵がCirrOSインスタンスにインポートされ、SSH秘密鍵を指定して接続することで、期待通りログインできた。

問題解消後のログ出力

Starting network...
udhcpc (v1.23.2) started
Sending discover...
Sending select for 100.64.0.19...
Lease of 100.64.0.19 obtained, lease time 86400
route: SIOCADDRT: File exists
WARN: failed: route add -net "0.0.0.0/0" gw "100.64.0.1"
checking http://169.254.169.254/2009-04-04/instance-id
successful after 1/20 tries: up 19.10. iid=i-00000033
failed to get http://169.254.169.254/2009-04-04/user-data
warning: no ec2 metadata for user-data
Top of dropbear init script
Starting dropbear sshd: OK

failed to get http://169.254.169.254/2009-04-04/user-data となっているのが気になるが、Connection Timeoutではなくなっている。

SSH公開鍵ログイン確認

192.168.1.212 はAllocateしたFloating IP。

# ssh -i <key> cirros@192.168.1.212
The authenticity of host '192.168.1.212 (192.168.1.212)' can't be established.
ECDSA key fingerprint is SHA256:xxx.
ECDSA key fingerprint is MD5:xxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.212' (ECDSA) to the list of known hosts.
$ uname -a
Linux cirros-03 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 GNU/Linux
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000
    link/ether fa:16:3e:cb:11:e0 brd ff:ff:ff:ff:ff:ff
    inet 100.64.0.19/24 brd 100.64.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fecb:11e0/64 scope link
       valid_lft forever preferred_lft forever

まとめ - OpenStack外部ネットワーク構成のときにSSHキーペアがインポートされない

検証用に構築したOpenStackで、CirrOSをデプロイしたときにSSHキーペアがインポートされず、インスタンスSSH公開鍵方式によるログインができない事象が発生した。

詳細動作原理までは追求していないが、ネットワーク構成の見直しにより問題解消し、期待通りSSH公開鍵認証によるSSHアクセスが可能となった。

NG構成:ブリッジ(extnet)フラット構成
OK構成:Internal + Router + Floating IP構成

(Pike)PackStackで実用的なOpenStackスタンドアロン検証環境を構築する

f:id:daichi703n:20180304191716p:plain

OpenStack環境を簡単に構築できるPackStackで、少しのカスタマイズを加えて実用的なOpenStack検証環境を構築する。

OpenStackバージョン: Pike (Version: 12.0.2)

※あくまで検証環境ですので、セキュリティ、可用性、拡張性、マルチテナント等には課題が残ります。

PackStackインストール環境の課題

PackStackでのOpenStackインストールを試す中で、以下の点が課題と感じた。

  • Cinderのデフォルト容量が20GBのみ
  • Swiftのデフォルト容量が2GBのみ

いずれもストレージの課題で、インスタンスやオブジェクト数が増えてくるとすぐ容量不足となり使用できなくなる。

前提環境

物理サーバ

使用しているサーバはこちらで選定したDell PowerEdge T110 Ⅱ

designetwork.hatenablog.com

CPU: Intel XeonE3-1220v2
RAM: 24GB
DISK: 3TB

仮想サーバ

ハイパーバイザ: ESXi 6.5 スタンドアロン
ゲストOS: CentOS7(1708) Minimal
CPU: 4vCPU (ハードウェア仮想化ON)
RAM: 16GB
DISK: 32GB(OS), 128GB(Cinder), 128GB(Swift)

DISKはOS, Cinder, Swiftそれぞれ用として複数マウントする。

CentOS7セットアップ

詳細割愛。パーティション等は自動で問題なし。

ストレージ領域作成

OpenStackで使用するストレージ用にDISK設定をする。

用途は次の通り
/dev/sdb: Cinder
/dev/sdc: Swift

DISKパーティションを作成する。

[root@openstack1 ~]# fdisk /dev/sdb
Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-268435455, default 2048): 2048
Last sector, +sectors or +size{K,M,G} (2048-268435455, default 268435455): 268435455
Partition 1 of type Linux and of size 128 GiB is set

Command (m for help): t
Hex code (type L to list all codes): 8e
Command (m for help): p
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   268435455   134216704   8e  Linux LVM

Command (m for help): w
The partition table has been altered!

[root@openstack1 ~]# fdisk /dev/sdc
Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-268435455, default 2048): 2048
Last sector, +sectors or +size{K,M,G} (2048-268435455, default 268435455): 268435455
Partition 1 of type Linux and of size 128 GiB is set

Command (m for help): t
Hex code (type L to list all codes): 8e
Command (m for help): p
   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048   268435455   134216704   8e  Linux LVM

Command (m for help): w
The partition table has been altered!

[root@openstack1 ~]# lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0   32G  0 disk
├─sda1            8:1    0    1G  0 part /boot
└─sda2            8:2    0   31G  0 part
  ├─centos-root 253:0    0 27.8G  0 lvm  /
  └─centos-swap 253:1    0  3.2G  0 lvm  [SWAP]
sdb               8:16   0  128G  0 disk
└─sdb1            8:17   0  128G  0 part
sdc               8:32   0  128G  0 disk
└─sdc1            8:33   0  128G  0 part
sr0              11:0    1 1024M  0 rom

PV, VG, LV, FileSystemを作成する。

[root@openstack1 ~]# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created.
[root@openstack1 ~]# pvcreate /dev/sdc1
  Physical volume "/dev/sdc1" successfully created.
[root@openstack1 ~]# vgcreate cinder-volumes /dev/sdb1
  Volume group "cinder-volumes" successfully created
[root@openstack1 ~]# vgcreate swift-volumes /dev/sdc1
  Volume group "swift-volumes" successfully created
[root@openstack1 ~]# lvcreate -n swift-lvs -l 100%FREE swift-volumes
  Logical volume "swift-lvs" created.
[root@openstack1 ~]# vgs
  VG             #PV #LV #SN Attr   VSize    VFree
  centos           1   2   0 wz--n-  <31.00g    4.00m
  cinder-volumes   1   0   0 wz--n- <128.00g <128.00g
  swift-volumes    1   1   0 wz--n- <128.00g <128.00g
[root@openstack1 ~]# lvs
  LV            VG             Attr       LSize    Pool
  root          centos         -wi-ao----   27.79g
  swap          centos         -wi-a-----   <3.20g
  swift-lvs     swift-volumes  -wi-ao---- <128.00g

[root@openstack1 ~]# mkfs.ext4 /dev/swift-volumes/swift-lvs
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
8388608 inodes, 33553408 blocks
1677670 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2181038080
1024 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

[root@openstack1 ~]# lsblk
NAME                          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                             8:0    0   32G  0 disk
├─sda1                          8:1    0    1G  0 part /boot
└─sda2                          8:2    0   31G  0 part
  ├─centos-root               253:0    0 27.8G  0 lvm  /
  └─centos-swap               253:1    0  3.2G  0 lvm  [SWAP]
sdb                             8:16   0  128G  0 disk
└─sdb1                          8:17   0  128G  0 part
sdc                             8:32   0  128G  0 disk
└─sdc1                          8:33   0  128G  0 part
  └─swift--volumes-swift--lvs 253:2    0  128G  0 lvm
sr0                            11:0    1 1024M  0 rom
[root@openstack1 ~]# df -hT
Filesystem              Type      Size  Used Avail Use% Mounted on
/dev/mapper/centos-root xfs        28G  1.2G   27G   5% /
devtmpfs                devtmpfs  7.8G     0  7.8G   0% /dev
tmpfs                   tmpfs     7.8G     0  7.8G   0% /dev/shm
tmpfs                   tmpfs     7.8G  8.6M  7.8G   1% /run
tmpfs                   tmpfs     7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda1               xfs      1014M  171M  844M  17% /boot
tmpfs                   tmpfs     1.6G     0  1.6G   0% /run/user/0

NIC情報取得

OpenStackインストールに必要となるため、NICの情報を取得しておく。この場合ens192という情報が必要となる。

[root@openstack1 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:0c:29:39:e7:cf brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.201/24 brd 192.168.1.255 scope global ens192
       valid_lft forever preferred_lft forever
    inet6 fe80::a952:db6b:fd90:a906/64 scope link
       valid_lft forever preferred_lft forever

OpenStackインストール

PackStackを使用してOpenStackをインストールする。インストール方法は基本的にこちらを参照。

https://www.rdoproject.org/install/packstack/

言語設定

LANG=en_US.utf-8
LC_ALL=en_US.utf-8

CentOS各種パッケージを最新化

# yum update -y

ネットワーク環境設定

# systemctl disable firewalld
# systemctl stop firewalld
# systemctl disable NetworkManager
# systemctl stop NetworkManager
# systemctl enable network
# systemctl start network
# setenforce 0
# vi /etc/selinux/config
SELINUX=permissive

PackStackインストール・answer-file生成

# yum install -y centos-release-openstack-pike
# yum update -y
# yum install -y openstack-packstack
# packstack --gen-answer-file=answers.cfg

answer-file編集

生成されたanswer-fileを以下のように編集する。

# diff ./answers.cfg_default ./answers.cfg

< CONFIG_CINDER_VOLUMES_SIZE=20G
---
> CONFIG_CINDER_VOLUMES_SIZE=120G

< CONFIG_NEUTRON_OVS_BRIDGE_IFACES=
---
> CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:ens192

< CONFIG_SWIFT_STORAGES=
---
> CONFIG_SWIFT_STORAGES=/dev/swift-volumes/swift-lvs

< CONFIG_SWIFT_STORAGE_SIZE=2G
---
> CONFIG_SWIFT_STORAGE_SIZE=120G

< CONFIG_PROVISION_DEMO=y
---
> CONFIG_PROVISION_DEMO=n

CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:<ip aで確認したインタフェース>

CONFIG_SWIFT_STORAGES=<作成したLV>

cinderはVG名をcinder-volumesとしておけばここの個別設定不要。

少し古い情報だが、編集内容は以下が参考になる。

access.redhat.com

OpenStackインストール

answerファイルを読み込んでOpenStackをインストールする。puppetで各種インストールが走る。私の環境では30分程度かかった。

# packstack --answer-file=./answers.cfg

セッション断が起こりうるためコンソールから実行するのを推奨する。完了したら再起動する。

# reboot

OpenStack初期セットアップ

http://<IP or FQDN>にアクセスするとOpenStackのダッシュボードが表示される。

クレデンシャル(認証情報)はサーバrootに生成されている。

# cat ~/keystonerc_admin
unset OS_SERVICE_TOKEN
    export OS_USERNAME=admin
    export OS_PASSWORD='PASSWORD'
    export OS_AUTH_URL=http://192.168.1.201:5000/v3
    export PS1='[\u@\h \W(keystone_admin)]\$ '

export OS_PROJECT_NAME=admin
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3

キーペアを生成する

OpenStackでデプロイするVMへのアクセスはSSH秘密鍵が必要になる。 キーペアを生成して、ローカルに保存しておく。

f:id:daichi703n:20180304182756p:plain

ネットワークを作成する

今回はホストのCentOSをブリッジングして外部ネットワークと直接接続する。設定は次のようになる。(設定プロンプト割愛)

まずネットワークを作成する。 外部ネットワーク:true, ネットワークタイプ:フラット, 物理ネットワーク:extnet とする。

f:id:daichi703n:20180304182836p:plain

その中にサブネットを作成する。DHCPも有効にしておく。

f:id:daichi703n:20180304182909p:plain

セキュリティグループにICMP・SSH追加

セキュリティグループdefaultにALL ICMP, SSHを0.0.0.0/0で追加しておく。

f:id:daichi703n:20180304182924p:plain

イメージをダウンロードし登録する

OSのイメージをダウンロードする。とりあえずOpenStackテスト用のCirrOSを使用する。

OpenStack Docs: イメージの入手

なお、こちらから直接ダウンロードできる。(v0.4.0)

http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img

プロジェクト > コンピュート > イメージ から、ダウンロードしたイメージを登録する。

CirrOSインスタンスを起動する

登録したCirrOSイメージのインスタンスを起動する。

イメージ > cirros > 起動

フレーバーはm1.tinyで起動可能。ネットワーク、セキュリティグループ、キーペアは上記で作成したものを指定する。

作成されたインスタンスのログを確認する。以下のような出力になっていればOK。

=== system information ===
Platform: RDO OpenStack Compute
Container: none
Arch: x86_64
CPU(s): 1 @ 3092.836 MHz
Cores/Sockets/Threads: 1/1/1
Virt-type: AMD-V
RAM Size: 488MB
Disks:
NAME  MAJ:MIN       SIZE LABEL         MOUNTPOINT
vda   253:0   1073741824               
vda1  253:1   1064287744 cirros-rootfs /
vda15 253:15     8388608               
=== sshd host keys ===
-----BEGIN SSH HOST KEY KEYS-----
ssh-rsa AAAAB3...Tb root@cirros
ssh-dss AAAAB3...== root@cirros
-----END SSH HOST KEY KEYS-----
=== network info ===
if-info: lo,up,127.0.0.1,8,,
if-info: eth0,up,192.168.1.217,24,fe80::f816:3eff:fe5d:26c4/64,
ip-route:default via 192.168.1.5 dev eth0 
ip-route:192.168.1.0/24 dev eth0  src 192.168.1.217 
ip-route6:fe80::/64 dev eth0  metric 256 
ip-route6:unreachable default dev lo  metric -1  error -101
ip-route6:ff00::/8 dev eth0  metric 256 
ip-route6:unreachable default dev lo  metric -1  error -101
=== datasource: None None ===
=== cirros: current=0.4.0 uptime=260.09 ===
  ____               ____  ____
 / __/ __ ____ ____ / __ \/ __/
/ /__ / // __// __// /_/ /\ \ 
\___//_//_/  /_/   \____/___/ 
   http://cirros-cloud.net


login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root.
cirros login: 

CirrOSにSSH接続する

インスタンス情報に表示されているIPアドレス(=上記ログに表示のIPアドレス)にSSH接続する。パスワードはログ中に記載の通り。

$ ssh cirros@192.168.1.217

cirros@192.168.1.217's password: gocubsgo
$ pwd
/home/cirros
$ uname -a
Linux cirros 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 GNU/Linux

CirrOSにSSHアクセス・ログインできた。

SSHキーペアでログインできるようにする

上記のままだと登録したSSHキーペアでログインできない。(私の環境ではできなかった)

追加設定でSSH公開鍵によるログインを可能とする。

internalネットワーク・ルータ作成

下図のcirros-03の状態を作る。(cirros-01, 02構成ではSSHキーペアが登録されない)

f:id:daichi703n:20180304190206p:plain

設定概要は次の通り。

内部ネットワークを作成する。私は最終的にBOSH検証環境を構築したいためbosh-internalとしたが名前はなんでも良い。

f:id:daichi703n:20180304185734p:plain

あわせてサブネットも作成する。内部用ということでシェアードアドレスを割り当てる。

f:id:daichi703n:20180304185819p:plain

ルータを作成し、それぞれのネットワークに接続する。

f:id:daichi703n:20180304190038p:plain

Floating IPを作成する。

f:id:daichi703n:20180304190307p:plain

この環境で、internalネットワークを指定してインスタンスを起動、Associate Floating IPでIPアドレスを割り当てればOK。

SSH秘密鍵を指定してSSH接続

キーペアで正常にインスタンスに登録され、秘密鍵を使用してパスワードなしSSHログインが可能となる。

# ssh -i <key> cirros@192.168.1.212
The authenticity of host '192.168.1.212 (192.168.1.212)' can't be established.
ECDSA key fingerprint is SHA256:xxx.
ECDSA key fingerprint is MD5:xxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.212' (ECDSA) to the list of known hosts.
$ uname -a
Linux cirros-03 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 GNU/Linux
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000
    link/ether fa:16:3e:cb:11:e0 brd ff:ff:ff:ff:ff:ff
    inet 100.64.0.19/24 brd 100.64.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fecb:11e0/64 scope link
       valid_lft forever preferred_lft forever

まとめ - PackStackで実用的なOpenStackスタンドアロン検証環境を構築する

OpenStack環境を簡単に構築できるPackStackで、少しだけ実用的なOpenStack検証環境を構築した。

  • Cinderのデフォルト容量が20GBのみ
  • Swiftのデフォルト容量が2GBのみ

というストレージ関連の課題を解消し、検証で使用可能な環境を構築することができた。