web-dev-qa-db-ja.com

プロビジョニング時にクラウド設定でlxdコンテナを設定する方法はありますか？

具体的には、openstackではなくCLIツールを使用します。

私は、lxdを使用したローカル開発者のセットアップがどのように見えるかを調べていますが、新しいコンテナの構成に関しては手ぶらで来ています。

Lxdコンテナを構成する慣用的な（またはその他の）方法はありますか？ Dockerイメージのような、より不変なものを見るべきですか？

ありがとう。リソースまたはポインターをいただければ幸いです。

lxc
10
ben schwartz

そのため、コンテナーに対して直接行う方法がいくつかあります。

lxc init ubuntu: CONTAINER
lxc config set CONTAINER user.user-data - < cloud-init-config.yml
lxc start CONTAINER

またはさらに短く：

lxc launch ubuntu: CONTAINER --config=user.user-data="$(cat cloud-init-config.yml)"

または、プロファイルを介して：

lxc profile create dev
lxc profile set dev user.user-data - < cloud-init-config.yml
lxc launch ubuntu: CONTAINER -p default -p dev
12
stgraber

私が今日行ったあるライナー、これは新しいコンテナのデフォルトプロファイルにそれを設定します：

echo -e "#cloud-config\nssh_authorized_keys:\n - $(cat ~/.ssh/id_rsa.pub)" | lxc profile set default user.user-data -

これは既存のコンテナにそれを設定しますが、SSH鍵のものは最初の起動時にのみ行われるため、すでに起動しているコンテナでは動作しないことに注意してください：

echo -e "#cloud-config\nssh_authorized_keys:\n - $(cat ~/.ssh/id_rsa.pub)" | lxc config set CONTAINER_NAME user.user-data -

3
Trent Lloyd

OPよりも少し具体的な質問がありましたが、間違っていたことを解決するのに時間がかかりました。他の人が同様に困惑するのを助けるために、ここに投稿すると思いました。

Ubuntu 16.04でホストされるLXC/LXD Ubuntu 16.04コンテナーの静的ネットワーク設定が必要でした。ステファン wrote を試してみましたが、うまくいきませんでした。私の設定ではDHCPが提供されていないため、IPv6リンクローカルを備えたデフォルトのDHCP試行コンテナのみになりました。

私の最初のYAMLは次のように（何か）見えました（ cloud-init docsから取得）。

network:
  version: 1
  config:
    - type: physical
      name: eth0
      subnets:
        - type: static
          address: 192.168.23.14/27
          gateway: 192.168.23.1
          dns_nameservers:
            - 192.168.23.2
            - 8.8.8.8
          dns_search:
            - exemplary.maas

そして、これを上記のuser.user-dataにロードしていました。

lxc config set CONTAINER user.user-data - < CONTAINER.cloud-init-config.yml

LXC/LXDソース でStéphaneのドキュメントを見つけるまで、その値をuser.network-configにロードする必要があることに気づきませんでした。

したがって、私の最終的なYAMLは（何か）このように見えました。

version: 1
config:
  - type: physical
    name: eth0
    subnets:
      - type: static
        address: 192.168.23.14/27
        gateway: 192.168.23.1
        dns_nameservers:
          - 192.168.23.2
          - 8.8.8.8
        dns_search:
          - exemplary.maas

次に、これを代わりにuser.network-configにロードしました。

lxc config set CONTAINER user.network-config - < CONTAINER.network-config.yaml

コンテナごとに2つの異なるファイルを保持する必要があるようです。1つはネットワーク設定をuser.network-configにロードするためのものです。そして、すべてに単一のファイルを使用する方法を見つけられない限り、user.user-dataにロードする他の構成用です。

私にとってまったく明らかではなかった別の問題は、非ネットワークコンポーネントを自動的に構成しようとしていたことです。

lxc config set CONTAINER user.user-data - < CONTAINER.user-data.yaml

上記のコマンドで適用された次のYAMLは（lxc config show CONTAINERを使用して正しいように見えても）コンテナ内に何も作成しませんでした。

write_files:
  - content: |
    # My new /etc/foo.bar file

    Foo
    Bar

    path: /etc/foo.bar

ser Data Input Formats、item 5：Cloud Config Data に隠された手がかり：

"#cloud-config"または"Content-Type: text/cloud-config"で始まるこのコンテンツは「クラウド構成」データです。サポートされている構成形式のコメント付きの例については、例を参照してください。

このドキュメントが非常に明確だとは思わない。 「Content-Type：text/cloud-config」フォームを使用しても何も動作しませんでしたが、最初の行に#cloud-configと入力すると、YAMLが解析されます。私の理解であれ、誰かのプログラミングであれ、何かが正しくないと推測することしかできません。キーuser.user-dataの値として明示的にロードしたYAMLをクラウド構成データ以外のものとして使用する必要があることは、私には意味がありません。クラウド構成を意図していなかった場合、他の人がそれを行うのはなぜですか？したがって、コメント（通常のシバン構文さえ使用しない）がrequired？

ナンセンスはさておき、user.user-dataで機能した構文は次のとおりです。

#cloud-config

write_files:
  - content: |
      # My new /etc/foo.bar file

      Foo
      Bar

    path: /etc/foo.bar
3
Styne666