Есть ли способ настроить контейнеры lxd с конфигурацией облака во время предоставления?

В частности, с инструментами CLI - не с открытым стеком.

Я смотрю на то, как может выглядеть локальная установка dev с lxd, но я подхожу с пустыми руками, когда дело доходит до настройки новых контейнеров.

Существуют ли идиоматические (или иные) способы настройки контейнеров 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

Один лайнер, с которым я пошел сегодня, устанавливает его в профиль по умолчанию для новых контейнеров:

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 -

У меня был немного более конкретный вопрос, чем у ОП, но мне потребовалось время, чтобы понять, что я делаю неправильно. Я думал, что выложу это здесь, чтобы помочь кому-то еще стать таким же тупым.

Я хотел статические сетевые настройки для контейнера LXC / LXD Ubuntu 16.04, размещенного в Ubuntu 16.04. Я начал с того, что попробовал то, что написал Стефан, но это не сработало. Все, что я закончил, это контейнер по умолчанию для попыток DHCP с локальной ссылкой IPv6, так как в моей конфигурации не обслуживается DHCP.

Мой первоначальный YAML выглядел (как-то) примерно так (взято из документа cloud-init ).

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 , я понял, что мне нужно загрузить это значение 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

Похоже, мне нужно будет хранить два разных файла для каждого контейнера: один для загрузки сетевых настроек 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

Подсказка скрыта в Форматах ввода пользовательских данных, пункт 5: Данные конфигурации облака гласят:

начинается с "#cloud-config"или "Content-Type: text/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