kdevops_vagrant

kdevops_vagrantは、コミュニティで共有されているkdevopsのVagrantファイルをプロジェクトにデプロイするためのAnsibleロールです。このAnsibleロールはVagrantfileをプロジェクトのネームスペースディレクトリにコピーし、必要に応じてVagrantを実行することもできます。

このAnsibleロールの目的は、プロジェクト間で同じスケーラブルなVagrantファイルを簡単に共有できるようにし、Vagrantファイルに居場所を提供して、貢献者がそれを進めたり文書化したりできるようにすることです。

プロジェクトネームスペースディレクトリ

プロジェクトネームスペースディレクトリは、プロジェクトを定義するための最上位ディレクトリです。例えば、「kdevops」という開発プロジェクトがあり、そのファイルが次の場所に保存されているとします。

/home/user/devel/kdevops/

この場合、プロジェクトネームスペースディレクトリは「kdevops」です。デフォルトでは、このAnsibleロールは、プレイブックファイルが保存されているディレクトリのベース名を使って、プロジェクトネームスペースディレクトリを推測します。例えば、プレイブックファイルが次の場所に保存されている場合：

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes.yml

別のファイルでデータを上書きすることもできます：

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

プレイブックファイルが保存されているディレクトリは：

/home/user/devel/kdevops/playbooks/

このディレクトリのベース名は：

/home/user/devel/kdevops/

これがこのプロジェクトの推測されたプロジェクトネームスペースディレクトリになります。これは、以下で説明するforce_project_dirロール変数を使用して上書きすることができます。

プロジェクトネームスペース

プロジェクトネームスペースは、このロールが持つVagrantfile内で使用され、環境変数を通じてVagrantのデフォルトを上書きすることを可能にします。プロジェクトネームスペースは、上記で説明したプロジェクトネームスペースディレクトリから推測されます。例えば、上記の例でプロジェクトディレクトリネームスペースが：

/home/user/devel/kdevops/

の場合、プロジェクトネームスペースは「kdevops」と推測されます。この大文字版が環境変数のプレフィックスとして使われるので、KDEVOPSになります。ダッシュはアンダースコアに置き換えられます。これは、シェル変数がダッシュを含むことができないためです。したがって、プロジェクトディレクトリネームスペースが：

/home/user/devel/some-cool-project/

の場合、プロジェクトネームスペースは：SOME_COOL_PROJECT になります。

要件

Vagrantがインストールされている必要があります。

Vagrantは、非クラウドの仮想マシンを簡単にデプロイするために使用されます。サポートされているプロバイダーのリストは以下の通りです：

• Virtualbox
• libvirt (KVM)

サポートされているオペレーティングシステムは以下の通りです：

• OS X
• Linux

通常ユーザーとしてlibvirtを実行する

私たちはhttps://github.com/mcgrof/libvirt-user Ansibleロールを使用して、通常のユーザーを有効にします。そこのドキュメントを読んで、そのロジックをご確認ください。

別のファイルでノード設定の上書き

Vagrantで使用される変数を上書きするためのより良い方法は、$(project)_node_override.yamlファイルを通じてです。例えば、https://github.com/mcgrof/kdevopsの場合、Gitの外にある別のオプションのファイルでデータを上書きできます：

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

環境変数

上書きファイルの使用が機能しない場合にのみ、環境変数を使用できます。しかし、環境変数を使用するのはケースバイケースであり、新しい変数を追加するためのサポートを実装する必要があります。上書きファイルを使用すれば、新しい機能が追加されるとすぐに、何でも上書きすることができます。

環境変数は、上記で説明したプロジェクトネームスペースの大文字版でプレフィックスされます。これを${PN_U}と呼ぶことにします。このプレフィックスを考慮に入れると、以下の環境変数がVagrantfileの動作を変更します：

• ${PN_U}_VAGRANT_NODE_CONFIG: デフォルトの設定ファイルを上書きします
• ${PN_U}_VAGRANT_PROVIDER: Vagrantによって使用されるプロバイダを上書きします
• ${PN_U}_VAGRANT_LIMIT_BOXES: ボックス制限を有効にします
• ${PN_U}_VAGRANT_LIMIT_NUM_BOXES: 制限するボックスの数
• ${PN_U}_VAGRANT_QEMU_GROUP: 使用するqemuユーザーを上書きします

Vagrantのボックス数を制限する

デフォルトでは、Vagrantはノード設定ファイルに指定されたすべてのノードを作成しようとします。デフォルトでは、これは${PN_L}_nodes.ymlであり、$PN_Lは上記で説明したプロジェクトネームスペースの小文字版です。例えば、kdevopsプロジェクトの場合、これはkdevops_nodes.ymlになります。

例えば、kdevopsプロジェクトでVagrantが1つのボックスのみを作成するように制限したい場合は、次のように使用します：

export KDEVOPS_VAGRANT_LIMIT_BOXES="yes"
export KDEVOPS_VAGRANT_LIMIT_NUM_BOXES=1

異なる名前のプロジェクトには異なるプレフィックスを使用してください。

これにより、例えば最初のホストのみが作成され、プロビジョニングされることが保証されます。これは、例えばノートパソコンで開発中で、リソースの使用量を制限したい場合に便利です。

Ansibleの使用範囲

kdevops全体は、libvirt / Virtualboxで仮想化されたローカルシステム、ベアメタルシステムを使用する場合、またはクラウド環境を使用する場合に関係なく、システムの設定方法に依存しないように設計されています。

そのため、次の3つのステージがあります：

• 起動：仮想 / クラウド / ベアメタル
• 構成と依存関係のインストール：~/.ssh/configにシステムを追加し、ユーザーの好みのbashスクリプト、.gitconfig、および選択した一般的な開発パッケージをインストールします。これはhttp://github.com/mcgrof/update_ssh_config_vagrantとhttp://github.com/mcgrof/devconfigのAnsibleロールを通じて処理されます。
• 作業を開始：作業を行います。これは通常、Ansibleによって推奨されます。

私たちのVagrantとAnsibleの使い方は、上記で言及した最初の2つの部分に制限されます。そのため、Ansibleは2つのAnsibleロールを使用するためだけに使用します：

• http://github.com/mcgrof/update_ssh_config_vagrant
• http://github.com/mcgrof/devconfig

私たちはこの実践を拡張するつもりはなく、その理由はユーザーが後の目的のためにAnsibleを直接使用することを望んでいるからです。起動および構成、開発者の依存関係のインストールに関する作業は、Vagrant、Terraform、または手動でベアメタルシステムを設定したユーザーによって扱われる必要があります。

そのため、Vagrantの使用のためにより多くのAnsibleロールを追加することを推奨していません。これら2つのロールは一般的なセットアップには十分であり、Ansibleの残りの使用は手動で行う必要があります。

AnsibleのPythonインタプリタ

AnsibleはリモートシステムのPythonに依存しています。どのバージョンのPythonが使用されるべきかは異なりますが、デフォルトではAnsibleは古いバージョンのPythonインタプリタを使用しようとします。これは古いシステムをサポートするための決定です。この決定は新しいシステムには最適ではなく、インタプリタを指定することを推奨します。これはインベントリファイルに最適です。Vagrantfileは、../hostsというインベントリファイルがあることを前提としていますが、Ansibleの設定でこれを上書きすることもできます：

ansible_playbooks:
  # このファイルが存在すれば、そこで任意のAnsible変数を上書きできます。
  # このファイルはオプションです。
  extra_vars: "../extra_vars.yml"
  inventory: "../hosts"
  playbooks:
    - name: "../playbooks/update_ssh_config_vagrant.yml"
    - name: "../playbooks/devconfig.yml"

あなたのホストファイルは次のようになります：

[all]
newsystem1
oldsystem1
[all:vars]
ansible_python_interpreter = "/usr/bin/python3"

[new]
newsystem1
[new:vars]
ansible_python_interpreter = "/usr/bin/python3"

[old]
oldsystem1
[dev:vars]
ansible_python_interpreter = "/usr/bin/python2"

この場合、すべてのシステムは[all]グループのPythonインタプリタをpython3に設定しますが、最後のエントリは古いシステムがpython2を使用することを保証します。

VagrantでのAnsibleのエクストラ変数の使用

Ansibleには、コマンドラインやロールファイルなどを通じて変数の優先順位を決定する独自の階層があります。このことは、https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.htmlに記載されています。

これがほとんどの使用に適しているかもしれませんが、版管理に存在しないファイルでユーザーがデフォルトのバリエーションを指定できるようにしたいプロジェクトにはあまり役立ちません。

kdevopsは、Ansibleロールの統一されたセットで構成されているため、Ansibleに対する上書きを定義する統一された方法をサポートします。これを実現するために、ユーザーはプロジェクトのルートディレクトリにextra_vars.ymlというファイルでAnsible変数を上書きすることができます。

したがって、kdevopsプロジェクトの例では、これは次のようになります：

/home/user/devel/kdevops/extra_vars.yml

このファイルが設定されると、VagrantのAnsibleプラグインは、そのファイルを--extra-vars=@fileを介してAnsibleに直接渡すことを保証します。ファイルを指定する際にはプレフィックスの@が必要です。@を提供する必要はありません。私たちがそれを行います。

kdevopsで使用されるすべてのAnsibleロールは、このextra_varsファイルを探すことをサポートしています。

Ansibleロールの変数

• run_vagrant: デフォルトではFalseです。Trueに設定すると、Vagrantを自動的に実行します。
• force_project_dir: 設定されている場合、Vagrantディレクトリを探す場所として使用されます。デフォルトでは空に設定され、プレイブックファイルが保存されている親ディレクトリがプロジェクトディレクトリであると推測します。

依存関係

なし。

例プレイブック

以下は例プレイブックで、kdevopsプロジェクトで使用されます。kdevops/playbooks/kdevops_vagrant.ymlファイルです：

---
- hosts: localhost
  roles:
    - role: kdevops_vagrant

この特定のケースでは、localhostが使用されていることに注意してください。これは、Vagrantfileをkdevops/vagrant/ディレクトリにローカルにプロビジョニングしているからです。異なるホストを使用することも明らかに可能です。

さらなる情報

さらなる例については、このロールのユーザーの一つ、https://github.com/mcgrof/kdevopsプロジェクトや、元々このコードが来たhttps://github.com/mcgrof/oscheckプロジェクトを参照してください。

ライセンス

GPLv2