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

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

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

lxdコンテナーを構成する慣用的な（またはその他の）方法はありますか？私はドッカー画像のようなもっと不変のものを見ているべきですか？

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

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

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

今日使ったライナーの1つです。これは、新しいコンテナのデフォルトプロファイルに設定します。

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 -

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

Ubuntu 16.04でホストされているLXC / LXD Ubuntu 16.04コンテナーの静的ネットワーク設定が必要でした。私はステファンが書いたことを試すことから始めましたが、うまくいきませんでした。私の構成では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つの異なるファイルを保持する必要があるようuser.network-configです。1つはuser.user-data、すべてに単一のファイルを使用する方法が見つからない限り、他の構成をロードするためのものです。

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

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

ユーザーデータ入力形式、項目5：Cloud Config Dataに埋もれた手がかり：

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

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

したがって、ナンセンスはさておき、上手くいった構文user.user-dataは次のとおりです。

#cloud-config

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

      Foo
      Bar

    path: /etc/foo.bar