データベース
 Computer >> コンピューター >  >> プログラミング >> データベース

DevStackのない生活：OSAを使用したOpenStack開発

OpenStackの貢献者であれば、ほとんどの作業をDevStackに依存している可能性があります。 DevStackは、貢献者が開発、テスト、およびレビューに使用する事実上のプラットフォームであり、長い間使用されてきました。この記事では、私が貢献しているopenstack-ansibleというプロジェクトを紹介します。過去数か月間、私はこのプロジェクトをDevStackfor OpenStackアップストリーム開発の代替として使用しており、その経験は非常に好意的です。

DevStackの何が問題になっていますか？

openstack-ansibleについて詳しく説明する前に、DevStackに代わるものを探す動機となった理由について簡単に説明したいと思います。全体として、DevStackは非常に充実したプロジェクトですが、私を悩ませているアーキテクチャ上の決定がいくつかあります。

まず、DevStackにはモノリシックインストーラーが付属しています。インストールを実行するには、stack.shを実行します これにより、構成したすべてのモジュールがインストールされます。後でモジュールを追加または削除する場合は、unstack.shを実行するしかありません。 すべてをアンインストールしてから、stack.shを再実行します 更新された構成で。数回、モジュールにソースコードを変更したときに、誤ってモジュールが異常な方法で動作するようになりました。そのような状況にある場合、最も安全なオプションはそれを再インストールすることです。DevStackでそれを行う唯一の方法は、すべてを再インストールすることです。

DevStackは、すべてのモジュールの開発インストールを実行します。これにより、実稼働環境とは大きく異なる環境が作成されます。私の意見では、適切な開発環境では、作業中のモジュールが開発用にインストールされ、他のすべてが本番用にインストールされます。これは、DevStackでは実行できません。

私がDevStackで抱えていたもう1つの問題は、依存関係を一貫した状態に保つための絶え間ない戦いです。 DevStackでは、依存関係はすべてのモジュール間で共有されるため、1つのモジュールの依存関係を同期するという単純なアクションにより、他のいくつかのモジュールを更新する必要がある連鎖反応が発生する可能性があります。最近のDevStackリリースでは、モジュールごとの仮想環境を使用することである程度これを軽減できますが、それでもOSレベルのパッケージは共有されたままです。

openstack-ansible（OSA）とは何ですか？

openstack-ansibleプロジェクトは、Ansibleのパワーを使用してOpenStackをデプロイするRackspaceオープンソースイニシアチブです。 os-ansible-deploymentという名前のこのプロジェクトを聞いたことがあるかもしれません。 OpenStackの大きなテントに移動する前にStackForgeで。

DevStackと同様に、openstack-ansibleは、ベンダーのパッチやアドオンを使用せずに、すべてのOpenStackサービスをgitリポジトリーから直接デプロイします。ただし、大きな違いは、openstack-ansibleがOpenStackサービスをLXCcontainersにデプロイすることです。そのため、アノードでホストされるサービス間で完全なOSレベルとPythonパッケージの分離が行われます。

DevStackとopenstack-ansibleのもう1つの違いは、後者が本番環境のディストリビューションであるということです。これを使用すると、少数のノードから数百または数千のノードを持つ大規模なクラスターまで、エンタープライズ規模のプライベートクラウドをデプロイできます。

次の図は、openstack-ansibleprivatecloudの構造を示しています。

DevStackのない生活：OSAを使用したOpenStack開発

これを見た後、マルチノードのプライベートクラウドに明確に向けられていることを考えると、このプロジェクトがアップストリーム開発用のDevStackのシンプルさにどのように対応できるかを考えていると思います。絶望するな！これについては次のセクションで説明します。

OSAオールインワン

openstack-ansibleプロジェクトの貢献者は、日常業務とゲーティングに単一ノードのデプロイメントを使用します。これは、はるかに便利でリソース効率が高いためです。この展開方法では、クラウドサーバーまたは仮想マシン上でOSAを立ち上げることができるため、この機能を利用すると、このプロジェクトはDevStackに匹敵します。

残念ながら、OSAの単一ノード展開のホスト要件は、主にコンテナーインフラストラクチャによって導入されるオーバーヘッドのために、DevStackよりも高くなります。使用可能なインストールを行うには、ホストに16GBのRAMと80GBのディスク容量が必要です。現時点でサポートされているホストOSはUbuntu14.04のみです。

OSAがDevStackより優れている点の1つは、コンテナー化されたアーキテクチャーのおかげで、単一ノードのインストールでも冗長サービスをデプロイできることです。デフォルトの単一ノード展開では、galera、rabbitmq、およびkeystoneが冗長性を持って展開され、負荷分散を行うためにHAProxyがホストにインストールされます。

手を汚す準備はできていますか？上記の仕様を満たす新しいUbuntu14.04サーバーにアクセスできる場合は、次のコマンドを使用してOSArepositoryのクローンを作成できます。

# apt-get -y install git
# git clone https://github.com/openstack/openstack-ansible /opt/openstack-ansible

プロジェクトをこのディレクトリに複製する必要はありません。代わりに、好きな場所でクローンを作成できます。

次に、単一ノードの構成ファイルを生成します。幸い、プロジェクトにはそれを行うスクリプトが付属しています：

# cd /opt/openstack-ansible
# scripts/bootstrap-aio.sh

上記のコマンドを実行した後、ディレクトリ / etc / openstack_deploy YAML形式のいくつかの構成ファイルが入力されます。特に興味深いのはファイルuser_secrets.ymlです。 、インストールで使用されるすべてのパスワードが含まれています。これらのパスワードはランダムに生成されるため、覚えにくいです。私は通常、管理者パスワードを編集します。これは、管理者パスワードを頻繁に使用するためです。基本的に私はこれを変更します：

keystone_auth_admin_password: cY3QHwjMLRdSuZMlKI3OvujScCNeIMdH

これに：

keystone_auth_admin_password: secrete

残りのパスワードはそれほど役に立たないので、そのままにしておきます。ただし、使用する必要があると思われるパスワードは、覚えやすいものに変更できます。

次に、Ansibleをホストにインストールする別のスクリプトに加えて、その使用を簡素化するいくつかのAnsibleエクストラとラッパースクリプトを実行します。

# scripts/bootstrap-ansible.sh

この時点で、ホストはOSAインストールを受信する準備ができているので、インストールを実行するAnsibleプレイブックを実行します。

# scripts/run-playbooks.sh

Rackspace Public Cloudサーバーでは、すべてのプレイブックの完全な実行が完了するまでに約45分かかります。 Ansibleを使用することの優れた点の1つは、すべてのタスクがべき等であるということです。つまり、問題を発生させることなく、プレイブックを複数回実行できます。タスクがすでに実行されている場合、それを2回実行しても何も起こりません。これは、適切な構成ファイルを変更してプレイブックを再実行するだけで、最初にすべてを破棄することなく、ライブシステムを再構成できるため、実際には非常に便利です。

openstack-ansibleのクイックツアー

このセクションでは、OSAシングルノード構造の概要を説明します。これにより、立ち上がる勇気のある人は、すべてがどこにあるかを知ることができます。

まず、Horizo​​nダッシュボードがデプロイされ、ホストのパブリックIPアドレスからアクセスできる必要があります。 adminを使用できます アカウント、 /etc/openstack_deploy/user_secrets.ymlに入力したパスワード このファイルを編集しなかった場合は、このファイルを開いてkeystone_auth_admin_passwordを見つける必要があります。 使用されたパスワードを確認するための設定。

前述したように、サーバーはすべてLXCコンテナーにインストールされます。次のコマンドは、コンテナのリストを表示します：

root@miguel-lxc-server:~# lxc-ls -f
NAME                                          STATE    IPV4                                        IPV6  AUTOSTART
--------------------------------------------------------------------------------------------------------------------------------
aio1_ceilometer_api_container-c8e825de        RUNNING  10.0.3.203, 172.29.237.195                  -     YES (onboot, openstack)
aio1_ceilometer_collector_container-2da3371f  RUNNING  10.0.3.10, 172.29.238.178                   -     YES (onboot, openstack)
aio1_cinder_api_container-88e59c04            RUNNING  10.0.3.125, 172.29.238.106, 172.29.247.183  -     YES (onboot, openstack)
aio1_cinder_scheduler_container-69d2bec4      RUNNING  10.0.3.4, 172.29.239.79                     -     YES (onboot, openstack)
aio1_galera_container-2f36d624                RUNNING  10.0.3.95, 172.29.237.18                    -     YES (onboot, openstack)
aio1_galera_container-3b8e14d7                RUNNING  10.0.3.18, 172.29.237.166                   -     YES (onboot, openstack)
aio1_galera_container-618973ae                RUNNING  10.0.3.82, 172.29.238.189                   -     YES (onboot, openstack)
aio1_glance_container-4b41140f                RUNNING  10.0.3.21, 172.29.237.77, 172.29.246.233    -     YES (onboot, openstack)
aio1_heat_apis_container-40ec9f3e             RUNNING  10.0.3.193, 172.29.239.6                    -     YES (onboot, openstack)
aio1_heat_engine_container-36e270c9           RUNNING  10.0.3.171, 172.29.239.171                  -     YES (onboot, openstack)
aio1_horizon_container-3497588e               RUNNING  10.0.3.33, 172.29.239.114                   -     YES (onboot, openstack)
aio1_horizon_container-6cac5348               RUNNING  10.0.3.30, 172.29.238.168                   -     YES (onboot, openstack)
aio1_keystone_container-821e7cf8              RUNNING  10.0.3.38, 172.29.238.105                   -     YES (onboot, openstack)
aio1_keystone_container-d63c657e              RUNNING  10.0.3.69, 172.29.239.208                   -     YES (onboot, openstack)
aio1_memcached_container-8baf34d5             RUNNING  10.0.3.158, 172.29.237.135                  -     YES (onboot, openstack)
aio1_neutron_agents_container-21b819b7        RUNNING  10.0.3.233, 172.29.239.130, 172.29.240.182  -     YES (onboot, openstack)
aio1_neutron_server_container-b4279bbe        RUNNING  10.0.3.52, 172.29.239.216                   -     YES (onboot, openstack)
aio1_nova_api_metadata_container-79faf41a     RUNNING  10.0.3.60, 172.29.239.110                   -     YES (onboot, openstack)
aio1_nova_api_os_compute_container-fed67563   RUNNING  10.0.3.231, 172.29.239.17                   -     YES (onboot, openstack)
aio1_nova_cert_container-72f66c56             RUNNING  10.0.3.155, 172.29.237.152                  -     YES (onboot, openstack)
aio1_nova_conductor_container-7d0f1b0f        RUNNING  10.0.3.164, 172.29.239.144                  -     YES (onboot, openstack)
aio1_nova_console_container-62af2918          RUNNING  10.0.3.106, 172.29.238.236                  -     YES (onboot, openstack)
aio1_nova_scheduler_container-e6b79b3b        RUNNING  10.0.3.250, 172.29.236.153                  -     YES (onboot, openstack)
aio1_rabbit_mq_container-0e0fe308             RUNNING  10.0.3.86, 172.29.239.93                    -     YES (onboot, openstack)
aio1_rabbit_mq_container-a4a04124             RUNNING  10.0.3.253, 172.29.237.188                  -     YES (onboot, openstack)
aio1_rabbit_mq_container-b9c6dce6             RUNNING  10.0.3.22, 172.29.238.111                   -     YES (onboot, openstack)
aio1_repo_container-6a8377fc                  RUNNING  10.0.3.102, 172.29.237.47                   -     YES (onboot, openstack)
aio1_repo_container-b92c563a                  RUNNING  10.0.3.223, 172.29.239.251                  -     YES (onboot, openstack)
aio1_rsyslog_container-a6e4f7d4               RUNNING  10.0.3.170, 172.29.237.249                  -     YES (onboot, openstack)
aio1_swift_proxy_container-9f0130d3           RUNNING  10.0.3.20, 172.29.237.227, 172.29.247.52    -     YES (onboot, openstack)
aio1_utility_container-d83fab91               RUNNING  10.0.3.39, 172.29.237.161                   -     YES (onboot, openstack)

このリストを確認することで、どのサービスが展開されたかを確認できます。 lxc-attachを使用してコンテナ内に入ることができます 指図。特に興味深いコンテナは、ユーティリティを備えたコンテナです。 リストの一番下にある名前。このコンテナに入るには、次のコマンドを使用する必要があります：

# lxc-attach -n aio1_utility_container-d83fab91

ユーティリティコンテナは、すべてのOpenStackコマンドラインクライアントがインストールされているだけでなく、すぐに使用できる openrc があるため、便利です。 管理者アカウントのファイル。次のセッション例では、openstackを使用します。 デプロイメント内のユーザーのリストを照会するユーティリティ：

root@miguel-lxc-server:~# lxc-attach -n aio1_utility_container-d83fab91
root@aio1_utility_container-d83fab91:~# source openrc
root@aio1_utility_container-d83fab91:~# openstack user list
+----------------------------------+--------------------+
| ID                               | Name               |
+----------------------------------+--------------------+
| 2257ddc66d4c41ba8500114944cbb852 | dispersion         |
| 22f1824610b34eb2a6cfaba09b8feb93 | ceilometer         |
| 271f9bd069b2440ebb27c8f460bb3bcf | neutron            |
| 2ecb372f6563410ab8138625c45a72e3 | heat               |
| 35a7c9373ff640c4ba768963c1f53f02 | keystone           |
| 37041c2377c44f5cb84ffafee5bfed6f | cinder             |
| 4b7f43c7c2cc443889cd6b5d90a30e49 | glance             |
| 6ee6a4abb7e64b3d801f2653efb9c9ec | swift              |
| 9b375e06cb0a481a8ed2f94e28e1cb39 | nova               |
| b2b90c7eed704c63bbc8ea0eb23f43c4 | admin              |
| bd3eed1e0cf54b93a0d7c6a7849be778 | stack_domain_admin |
+----------------------------------+--------------------+

コンテナを終了してホストに戻るには、exitと入力します または、Ctrl-Dを押します。

Ansibleのもう1つの優れた機能は、開発中に誤って破損したようなサービスを再インストールできることです。これを行うには、影響を受けたコンテナを破棄するだけです：

# lxc-stop -n <container-name>
# lxc-destroy -n <container-name>

病気のコンテナが破壊された後、プレイブックをもう一度実行すると、すべてを最初からインストールするのにかかる時間の何分の1かで、新しいものが交換として作成されます。

開発ワークフロー

実際には、DevStackの代わりにOSAオールインワンデプロイメントをどのように使用するかを知りたいと思います。このプロセスには、いくつかの簡単な手順が含まれます。

  1. OSA-AIOをデプロイする

    明らかに、すべては単一ノードのopenstack-ansiblecloudのデプロイから始まります。私は通常、Rackspace Public Cloudサーバーをホストとして使用していますが、上記の仕様で任意のUbuntu14.04ホストを使用できます。

  2. ターゲットコンテナにアタッチする

    次に、lxc-attachを使用して、作業したいサービスを実行するコンテナー内に入ります。 上に示したコマンド。冗長性を備えて展開されたサービスで作業する場合は、最初にHAProxy構成を編集して、1つのコンテナーのみをアクティブのままにします。残りのコンテナは、選択したコンテナに問題が発生した場合のバックアップとして使用できます。

  3. ターゲットサービスを停止します

    コンテナは、私が取り組む予定のサービスの製品版を実行しています。このサービスは役に立たないので、標準のservice <name> stopを使用して停止します 指図。たとえば、熱機関のコンテナにいる場合は、service heat-engine stopを実行します。 。

  4. クローン開発バージョン

    これで、ターゲットサービスを実行する準備ができたコンテナーができたので、操作する実際のコードのクローンを作成できます。このために、公式のgitリポジトリ、カスタム変更を加えたフォーク、またはレビューを行う場合はGerritのパッチを使用する場合があります。

  5. 依存関係を更新する

    開発バージョンでは、Ansibleプレイブックによってインストールされたバージョンとは異なる依存関係のセットが必要になる場合があるため、安全のために、Irun pip install -r requirements.txt コンテナ内。 OSAは独自のプライベートPythonパッケージリポジトリを作成するため、必要なバージョンのパッケージがそのリポジトリで利用できない場合があります。その場合、no-index = Falseを設定します コンテナの/root/.pip/pip.conf ファイルを使用してpypiにアクセスできるようにしてから、再試行してください。

  6. データベースの同期

    OSAとともにインストールされた元のバージョンと私の開発バージョンとのもう1つの考えられる違いは、データベースの移行にあるため、万が一の場合に備えて、常にデータベースを同期します。これを行うコマンドはサービスによってわずかに異なりますが、通常はdb_syncを使用して管理スクリプトを呼び出す必要があります。 オプション。たとえば、Keystoneを使用する場合、データベースを同期するコマンドはkeystone-manage db_syncです。

  7. 必要に応じて、元の構成ファイルに変更を加えます

    プレイブックはすべてのサービスの構成ファイルを作成するため、ほとんどの場合、 / etcに残された構成です。 インストーラーによるディレクトリは、開発のために変更することなく使用できます。自分の作業に関連するカスタム変更を行う必要がある場合は、テキストエディタを使用して手動で変更します。

  8. 手動で実行するか、サービスとしてインストールして実行する

    最後に、開発バージョンを開始できます。これを簡単に行うには、Pythonアプリケーションを直接実行するだけです。たとえば、熱機関サービスに取り組んでいる場合は、bin/heat-engineを実行できます。 プロジェクトのルートディレクトリからフォアグラウンドでサービスを開始し、ログをターミナルに送信します。サービスを停止するには、DevStackで行うのと同じように、Ctrl-Cを押します。

    pdb（コマンドライン）やpudb（インタラクティブ）などのターミナルフレンドリーなデバッガーは、コンテナー内にインストールでき、うまく機能します。 PyCharmなどのより複雑なデバッガーを使用したい場合は、ホストからコンテナーへのsshを介したリモートデバッグも可能です。

    ほとんどのサービスでは、手動で実行するだけで、DevStackと同じように快適に動作します。唯一の例外は、通常Apacheで実行されるKeystoneなど、Pythonscriptを直接実行しないサービスの場合です。イベントApacheは本番環境で使用されますが、開発ではPythonアプリケーションを直接実行するのが完全に安全です。これにより、イベントレットベースのWebサーバーが実行される可能性があります。何らかの理由でApacheを使用する必要がある場合は、python setup.py installを実行して開発バージョンをインストールすることもできます。 次に、インストール済みのApacheサービスをservice apache2 restartで再起動します。 。 python setup.py developを使用してアプリケーションをインストールすることにより、ソースディレクトリからアプリケーションを実行することもできます。 次に、ホームディレクトリをApacheサイト構成ファイルに追加します。

OSA-AIO：長所

DevStackの代わりにOSAを使用することは、ほとんどの場合、楽しい経験でした。 OSAでは、サービスの1つをリベースする必要があり、新しい依存関係が必要な場合、他のサービスは独自のコンテナーで影響を受けないため、依存関係の競合が発生しなくなりました。

また、デプロイメント全体を最初から再作成する必要はめったにないこともわかりました。通常、システム全体をOpenStackの新しいリリースにアップグレードする場合にこれを行いますが、日常業務では、ローカルの更新や修復を簡単に行うことができます。既存のインストールに。コンテナを破棄して、残りのサービスに触れることなくAnsibleに再生成させることができるのが好きです。

最後に、OSAを使用すると、システムのどの部分を開発パッケージとしてインストールするかを選択できる一方で、OpenStackの残りの部分を本番環境で使用するためにインストールおよび構成したままにすることができます。

OSA-AIO：短所

しかしもちろん、すべての場合と同様に、OSAでの作業にはあまり良くない側面もあるので、その側面についても説明したいと思います。

OSAは若いプロジェクトであるため、DevStackが享受しているコミュニティの幅広いサポートはありません。これは、OpenStackのコアではないモジュールで作業する場合に特に重要です。これを書いている時点で、OSAはKeystone、Nova、Neutron、Glance、Cinder、Swift、Heat、Ceilometer、Horizo​​nの展開をサポートしています。このリストに含まれていないモジュールで作業したい場合は、OSAはおそらくそれほど役に立ちません。ただし、反対に、現在サポートされていないモジュールのAnsibleプレイブックを作成する場合は、両手を広げて受け取ります。

一般に、1つの例外を除いて、すべてのモジュールのAnsiblevariablesとして公開されている構成オプションはかなりの数あります。 Neutronに関しては、構成はそれほど柔軟ではありません。コンテナとVM間のネットワークトンネルは、常にLinuxBridgeを使用するように構成されています。たとえば、Open vSwitchを使用する必要がある場合は、プレイブックの実行後に手動で構成を変更する必要がありますが、これは面白くありません。また、現時点ではNeutronプラグインはサポートされていません。

結論

openstackを使用した私のワークフローを見つけていただければ幸いです。 Heatのアップストリーム機能とバグ修正に取り組む時間を節約できました。また、KeystonefederationのデバッグとトラブルシューティングをOSAに大きく依存しています。

OSAの使用に興味がある場合は、少し検索することをお勧めします。これにより、他のOpenStack寄稿者がOSAをどのように組み込んだかを説明する記事やブログ投稿（この記事や他の記事など）がさらに表示されます。 ownworkflows。


  1. 最高のバッテリー寿命を持つトップ5のラップトップ

    すべてのラップトップの最も重要な側面の1つは、他のハードウェア要素とともに、バッテリーの寿命です。日常的にラップトップを使用している場合、バッテリー寿命の長いラップトップが欲しいと何度も思っている可能性があります。現在市場に出回っているノートパソコンのほとんどは、平均バッテリー寿命が5時間ですが、最近のノートパソコンの中には、20時間に近づくなど、印象的な稼働時間を達成しているものもあります。 このガイドで取り上げられているラップトップは、驚くべきバッテリー電力を備えている通常のマシンだけではありません。彼らは獣です–それらすべて。そして、彼らは信じられないほどのバッテリー寿命とともに非常識

  2. DevStackのない生活：OSAを使用したOpenStack開発

    OpenStackの貢献者であれば、ほとんどの作業をDevStackに依存している可能性があります。 DevStackは、貢献者が開発、テスト、およびレビューに使用する事実上のプラットフォームであり、長い間使用されてきました。この記事では、私が貢献しているopenstack-ansibleというプロジェクトを紹介します。過去数か月間、私はこのプロジェクトをDevStackfor OpenStackアップストリーム開発の代替として使用しており、その経験は非常に好意的です。 DevStackの何が問題になっていますか？ openstack-ansibleについて詳しく説明する前に、DevSta