Чи є спосіб налаштувати контейнери lxd з конфігурацією хмари під час надання?

Зокрема, з інструментами CLI - не openstack.

Я дивлюся на те, як може виглядати локальна програма для розробників з 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 виглядав (приблизно) приблизно так (узятий із хмарно-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

Тільки коли я не знайшов документацію Stéphane у джерелі 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