web-dev-qa-db-fra.com

Existe-t-il un moyen de configurer les conteneurs lxd avec une configuration en cloud au moment de la mise en service?

Plus précisément, avec les outils CLI, pas openstack.

Je regarde ce à quoi une configuration de développeur locale avec Lxd pourrait ressembler, mais j'arrive les mains vides lorsqu'il s'agit de configurer de nouveaux conteneurs.

Existe-t-il des moyens idiomatiques (ou autres) de configurer les conteneurs lxd? Devrais-je regarder quelque chose de plus immuable, comme des images de docker?

Merci. Toute ressource ou pointeur serait apprécié.

lxc
10
ben schwartz

Il y a donc plusieurs façons de le faire, soit directement pour un conteneur:

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

Ou même plus court:

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

Ou à travers un profil:

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

Un paquebot avec lequel je suis allé aujourd'hui, celui-ci le définit dans le profil par défaut pour les nouveaux conteneurs:

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

Celui-ci le place dans un conteneur existant, mais attention, il ne fonctionnera pas sur les conteneurs qui ont déjà démarré, car les éléments de clé SSH ne sont exécutés qu'au premier démarrage:

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

3
Trent Lloyd

J'avais une question un peu plus précise que celle du PO mais cela m'a pris un certain temps pour comprendre ce que je faisais de travers. Je pensais que je le posterais ici pour aider quiconque à se faire prendre la même chose.

Je voulais des paramètres de réseau statiques pour un conteneur LXC/LXD Ubuntu 16.04 hébergé sur Ubuntu 16.04. J'ai commencé par essayer ce que Stéphane a écrit mais ça ne marchait pas. Tout ce que je me suis retrouvé, c’est le conteneur par défaut qui tente DHCP avec une liaison IPv6 locale, puisqu’il n’ya aucun serveur DHCP dans ma configuration.

Mon YAML initial ressemblait (à quelque chose) à ce qui suit (tiré du 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

Et je chargeais ceci dans user.user-data comme décrit ci-dessus.

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

Ce n’est que lorsque j’ai trouvé la documentation de Stéphane dans le source LXC/LXD que je me suis rendu compte que je devais charger cette valeur dans user.network-config.

Donc, mon YAML final (quelque chose) ressemblait à ça.

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

Ensuite, j'ai chargé ceci dans user.network-config à la place.

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

Il semble que je devrai conserver deux fichiers différents par conteneur: un pour le chargement des paramètres réseau sur user.network-config; et un pour les autres config à charger dans user.user-data à moins que je ne trouve un moyen d'utiliser un seul fichier pour tout.

Un autre problème que j’ai constaté et qui n’était pas du tout évident pour moi était la tentative de configuration automatique de composants non-réseau.

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

Le YAML suivant appliqué avec la commande ci-dessus (malgré l'apparence correcte avec lxc config show CONTAINER) ne créait rien dans mon conteneur.

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

    Foo
    Bar

    path: /etc/foo.bar

L’indice enfoui dans Formats de saisie des données utilisateur, élément 5: données de configuration du cloud se lit comme suit:

commence par "#cloud-config" ou "Content-Type: text/cloud-config" Ce contenu est une donnée "cloud-config". Voir les exemples pour un exemple commenté des formats de configuration pris en charge.

Je ne crois pas que cette documentation est très claire. Je ne pouvais rien obtenir en utilisant le formulaire "Content-Type: text/cloud-config" mais je trouvais que si vous mettez #cloud-config sur la première ligne, le YAML est analysé. Je ne peux que supposer que quelque chose ne va pas, que ce soit ma compréhension ou la programmation de quelqu'un. Cela n'a aucun sens pour moi que YAML que vous avez explicitement chargé en tant que valeur de la clé user.user-data doive être utilisé autrement que comme données de configuration en nuage. Pourquoi quelqu'un d'autre ferait-il cela s'il ne s'agissait pas d'une configuration en nuage, et donc pourquoi un commentaire (qui n'utilise même pas la syntaxe Shebang normale) serait-il obligatoire ?

Donc, mis à part le non-sens, la syntaxe qui a fonctionné pour user.user-data est la suivante:

#cloud-config

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

      Foo
      Bar

    path: /etc/foo.bar
3
Styne666