¿Hay alguna forma de configurar contenedores lxd con la configuración de la nube en el momento de aprovisionamiento?


10

Específicamente, con las herramientas CLI, no OpenStack.

Estoy viendo cómo se vería una configuración de desarrollo local con lxd, pero me encuentro con las manos vacías cuando se trata de configurar nuevos contenedores.

¿Hay alguna forma idiomática (o de otro modo) de configurar contenedores lxd? ¿Debería mirar algo más inmutable como las imágenes acoplables?

Gracias. Cualquier recurso o puntero sería apreciado.

Respuestas:


13

Por lo tanto, hay varias formas de hacerlo, ya sea directamente para un contenedor:

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

O incluso más corto:

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

O a través de un perfil:

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

¿Cómo se pueden usar archivos .sh en lugar de .yml? ¿Ya hay un tutorial disponible sobre este tema?
Greg

Lo anterior es en referencia a esta pregunta: stackoverflow.com/questions/44456522
Greg

3

Un revestimiento con el que fui hoy, este lo establece en el perfil predeterminado para nuevos contenedores:

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

Este lo establece en un contenedor existente, pero tenga en cuenta que no funcionará en contenedores que ya se iniciaron, ya que las cosas de la clave SSH solo se realizan en el primer arranque:

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


3

Tenía una pregunta un poco más específica que el OP, pero me llevó un tiempo averiguar qué estaba haciendo mal. Pensé que lo publicaría aquí para ayudar a cualquier otra persona a quedar igualmente perpleja.

Quería configuraciones de red estáticas para un contenedor LXC / LXD Ubuntu 16.04 alojado en Ubuntu 16.04. Comencé probando lo que escribió Stéphane pero no estaba funcionando. Todo lo que terminé con fue el contenedor predeterminado de intento de DHCP con un enlace IPv6 local, ya que no hay ningún servidor DHCP en mi configuración.

Mi YAML inicial se parecía (algo) al siguiente (tomado de los documentos de inicio de la nube ).

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

Y estaba cargando esto user.user-datacomo se describe anteriormente.

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

No fue hasta que encontré la documentación de Stéphane en la fuente LXC / LXD que me di cuenta de que necesitaba cargar ese valor user.network-config.

Así que mi YAML final se veía (algo) así.

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

Luego cargué esto en su user.network-configlugar.

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

Parece que tendré que mantener dos archivos diferentes por contenedor: uno para cargar la configuración de red user.network-config; y otra para cargar otra configuración a user.user-datamenos que pueda encontrar una manera de usar un solo archivo para todo.


Otro problema que encontré que no era obvio para mí fue intentar configurar los componentes que no son de red automáticamente.

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

El siguiente YAML aplicado con el comando anterior (a pesar de parecer correcto usando lxc config show CONTAINER) no creó nada dentro de mi contenedor.

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

    Foo
    Bar

    path: /etc/foo.bar

La pista enterrada en los Formatos de entrada de datos del usuario, elemento 5: Datos de configuración de la nube se lee:

comienza con "#cloud-config"o "Content-Type: text/cloud-config" Este contenido son datos de "configuración de nube". Vea los ejemplos para un ejemplo comentado de formatos de configuración compatibles.

No creo que esta documentación sea muy clara. No pude hacer que nada funcionara con el formulario "Content-Type: text / cloud-config" pero encontré que si pones #cloud-configen la primera línea, se analiza el YAML. Solo puedo suponer que algo no está del todo bien, ya sea mi comprensión o la programación de alguien. Para mí no tiene sentido que YAML haya cargado explícitamente, ya que el valor de la clave user.user-datadebe usarse como otra cosa que no sean datos de configuración de la nube. ¿Por qué si alguien haría eso si no estaba destinado a ser la configuración de la nube, y por lo tanto ¿por qué un comentario (que ni siquiera utilizar la sintaxis tinglado normal) se requiere ?

Entonces, sin sentido, la sintaxis que funcionó user.user-dataes:

#cloud-config

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

      Foo
      Bar

    path: /etc/foo.bar
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.