Raspberry Pi

RPi 4

Ubuntu Server: Sistema operativo

Desde la versión 20.04 podemos instalar Ubuntu Server en Raspberry Pi. En entornos de producción es normal utilizar la versión LTS por tener un mayor tiempo de soporte. En la página de Canonical podemos encontrar un tutorial para la instalación de este sistema operativo. Dependiendo de la Raspberry Pi que tengamos dispondremos de una interfaz de red ethernet solamente o una ethernet y otra wifi. Se recomienda hacer el aprovisionamiento del servidor con conexión ethernet. Para las primeras veces lo más sencillo es tener acceso físico al servidor y tener conectados un monitor, un teclado y un ratón. Posteriormente se darán las nociones necesarias para realizar una instalación desatendida. Para realizar este tipo de aprovisionamientos se suele especificar las configuraciones deseadas en unos archivos en el disco de instalación que el sistema operativo cargará en el primer arranque del sistema. En entornos cloud-computing se utilizan estos mismos procedimientos pero en lugar de crear los archivos en el disco de arranque se les envían a las instancias con las instrucciones de creación.

Instalación básica

RPi Imager

Para la creación del disco de arranque necesitaremos una tarjeta micro-SD de al menos 16GB. Con el software Raspberry Pi Imager seleccionaremos el sistema operativo Ubuntu Server. Conectamos monitor, teclado y ratón. La conexión de red la realizaremos mediante un cable ethernet. Introducimos la tarjeta micro-SD y por último conectamos la fuente de alimentación. El sistema iniciará el arranque y pedirá tus credenciales. Por defecto el usuario es 'ubuntu' y la contraseña también 'ubuntu'. Normalmente lo primero que nos pide es sistema es cambiar la contraseña por una nueva. El comando shell para cambiar la contraseña es passwd.

Instalación desatendida

Si queremos hacer la instalación desatendida, es decir, sin tener interacción durante el proceso de instalación debemos especificarle al sistema operativo toda la información que necesite mediante algunos archivos de configuración. Además el acceso a dicho servidor se realizará en todo momento mediante secure shell (ssh). Por lo que deberemos saber la dirección ip del servidor y tener credenciales de acceso. Es decir un usuario y su contraseña o las importar nuestras claves ssh.

sudo apt update
sudo apt upgrade
sudo reboot

SSH: Acceso remoto

Docker: Gestor de contenedores

Cloud-init: Configurador del Sistema operativo

Cloud-init es la herramienta estándar de facto para la inicialización de instancias en cloud-computing multiplataforma. Es compatible con todos los principales proveedores de nube pública, sistemas de aprovisionamiento para infraestructura de nube privada e instalaciones completas.

Etapas de arranque

Cloud-init debe integrarse en el arranque de una manera bastante controlada. Hay cinco etapas para arrancar:

  • Generator

  • Local

  • Network

  • Config

  • Final

Generator

Al arrancar bajo 'systemd', se ejecutará un generador que determina si 'cloud-init.target' debe incluirse en los objetivos de arranque. De forma predeterminada, este generador habilitará cloud-init. No habilitará cloud-init si:

  • El archivo '/etc/cloud/cloud-init.disabled' existe

  • La línea de comando del kernel que se encuentra en '/proc/cmdline 'contiene 'cloud-init = disabled'. Cuando se ejecuta en un contenedor, la línea de comando del kernel no se respeta, pero cloud-init leerá una variable de entorno llamada 'KERNEL_CMDLINE' en su lugar.

Nuevamente, estos mecanismos para deshabilitar cloud-init en tiempo de ejecución solo existen en 'systemd'.

Local

El propósito de la etapa local es:

  • localizar fuentes de datos "locales".

  • aplicar la configuración de red al sistema.

En la mayoría de los casos, esta etapa no hace mucho más que eso. Encuentra la fuente de datos y determina la configuración de red que se utilizará. Esa configuración de red puede provenir de:

  • datasource: configuración de red proporcionada por la nube a través de metadatos

  • fallback: la red de respaldo de cloud-init consiste en representar el equivalente a "dhcp en eth0", que históricamente fue el mecanismo más popular para la configuración de red de un invitado

  • none: la configuración de red se puede desactivar escribiendo el archivo '/etc/cloud/cloud.cfg' con el contenido: `network: {config: disabled}’

Si este es el primer arranque de una instancia, se procesa la configuración de red seleccionada. Esto incluye la eliminación de toda la configuración anterior (obsoleta), incluida la asignación de nombres de dispositivos persistentes con direcciones mac antiguas.

Network

Esta etapa requiere que todas las redes configuradas estén en línea, ya que procesará completamente cualquier dato de usuario que se encuentre. Aquí, procesamiento significa:

  • recuperar cualquier #include o # include-once (recursivamente) incluyendo http

  • descomprimir cualquier contenido comprimido

  • ejecute cualquier gestor de piezas que encuentre.

Esta etapa ejecuta 'disk_setup' y 'mounts' módulos que pueden particionar y formatear discos y configurar puntos de montaje (como en '/etc/fstab'). Esos módulos no pueden ejecutarse antes ya que pueden recibir entradas de configuración de fuentes solo disponibles a través de la red. Por ejemplo, un usuario puede haber proporcionado datos de usuario en un recurso de red que describe cómo se deben realizar los montajes locales. Como tal, las entradas '/etc/fstab' que no sean las necesarias para que se ejecute cloud-init no deben realizarse hasta después de esta etapa.

Config

Esta etapa solo ejecuta módulos de configuración. Aquí se ejecutan los módulos que realmente no tienen efecto en otras etapas del arranque, incluido 'runcmd'.

Final

Esta etapa se ejecuta lo más tarde posible en el arranque. Cualquier script que un usuario esté acostumbrado a ejecutar después de iniciar sesión en un sistema debe ejecutarse correctamente aquí. Las cosas que se ejecutan aquí incluyen

  • instalaciones de paquetes

  • complementos de gestión de la configuración (marioneta, chef, salt-minion)

  • scripts de usuario (es decir, scripts de shell pasados ​​como datos de usuario)

Para scripts externos a cloud-init que buscan esperar hasta que finalice cloud-init, el subcomando 'cloud-init status' puede ayudar a bloquear scripts externos hasta que cloud-init finalice sin tener que escribir sus propias cadenas de dependencia de unidades systemd.

Determinación del primer arranque

Cloud-init tiene que determinar si el arranque actual es el primer arranque de una nueva instancia o no, para que aplique la configuración adecuada. En el primer arranque de una instancia, debería ejecutar toda la configuración "por instancia", mientras que en un arranque posterior sólo debería ejecutar la configuración "por arranque". Cloud-init tiene la opción de configuración manual_cache_clean. Cuando es false (el valor predeterminado), cloud-init realizará un check y limpiará la caché si los ID de la instancia no coinciden (este es el valor predeterminado, como se discutió anteriormente). Cuando es true, cloud-init estará en trust con el caché existente (y por lo tanto no lo limpiará).

Línea de comandos

cloud-init --help 
  $ cloud-init --help
  usage: /usr/bin/cloud-init [-h] [--version] [--file FILES] [--debug] [--force]
                          {init,modules,single,query,dhclient-hook,features,
                          analyze,devel, collect-logs,clean,status}

  optional arguments:
  -h, --help              show this help message and exit
  --version, -v           show program's version number and exit
  --file FILES, -f FILES
                          additional yaml configuration files to use
  --debug, -d             show additional pre-action logging (default: False)
  --force                 force running even if no datasource is found (use at
                          your own risk)

  Subcommands:
  {init,modules,single,query,dhclient-hook,features,analyze,devel,collect-logs,clean,status}
      init                initializes cloud-init and performs initial modules
      modules             activates modules using a given configuration key
      single              run a single module
      query               Query standardized instance metadata from the command
                          line.
      dhclient-hook       Run the dhclient hook to record network info.
      features            list defined features
      analyze             Devel tool: Analyze cloud-init logs and data
      devel               Run development tools
      collect-logs        Collect and tar all cloud-init debug info
      clean               Remove logs and artifacts so cloud-init can re-run.
      status              Report cloud-init status or wait on completion.

Algunos comandos útiles:

clean

Elimine las configuraciones cloud-init de '/var/lib/' cloud para simular una instancia limpia. Al reiniciar, cloud-init volverá a ejecutar todas las etapas como lo hizo en el primer arranque.

  • --logs: opcionalmente elimine todos los archivos de registro de inicio en la nube en '/var/log/'

  • --reboot: reinicia el sistema después de eliminar artefactos

analyze

Genera informes detallados del proceso de arranque de cloud-init.

Los posibles subcomandos incluyen:

  • blame: informe ordenado por las operaciones más costosas

  • dump: volcado JSON legible por máquina de todos los eventos rastreados de inicio en la nube

  • show: muestra un informe ordenado por tiempo del costo de las operaciones durante cada etapa de arranque

  • boot: muestra las marcas de tiempo de la inicialización del kernel, la inicialización de finalización del kernel y el inicio de cloud-init

Más información

¿Dónde están los logs?

Cloud-init usa los siguientes archivos para logs:

  • '/var/log/cloud-init-output.log': captura la salida de cada etapa de cloud-init cuando se ejecuta

  • '/var/log/cloud-init.log': registro muy detallado con salida de depuración, detallando cada acción realizada

  • '/run/cloud-init': contiene registros sobre cómo cloud-init decidió habilitarse o deshabilitarse, así como qué plataformas / fuentes de datos se detectaron. Estos registros son más útiles cuando se trata de determinar qué cloud-init se ejecutó o no.

Tenga en cuenta que cada vez que se inicia un sistema, se agregan nuevos registros a los archivos en /var/log. Por lo tanto, los archivos pueden tener más de un valor de arranque de información presente.

Al revisar estos registros, busque errores o rastreos de Python para verificar si hay errores.

¿Dónde están los archivos de configuración?

La configuración de Cloud-init se proporciona en dos lugares:

  • '/etc/cloud/cloud.cfg'

  • '/etc/cloud/cloud.cfg.d/*.cfg'

Estos archivos pueden definir los módulos que se ejecutan durante la inicialización de la instancia, las fuentes de datos para evaluar en el arranque y otras configuraciones.

¿Dónde están los archivos de datos?

Dentro del directorio '/var/lib/cloud/' hay dos subdirectorios importantes:

instancias

El directorio '/var/lib/cloud/instance' es un enlace simbólico que apunta al directorio de id. De instancia utilizado más recientemente. Esta carpeta contiene la información cloud-init recibida de las fuentes de datos, incluidos los datos del proveedor y del usuario. Esto puede ser útil para revisar para asegurarse de que se pasaron los datos correctos.

También contiene el archivo datasource que contiene la información completa sobre la fuente de datos que se identificó y usó para configurar el sistema.

Finalmente, el archivo de inicio finalizado es lo último que hace cloud-init.

datos

El directorio '/var/lib/cloud/data' contiene información relacionada con el arranque anterior:

  • id-instancia: id de la instancia descubierta por cloud-init. Cambiar este archivo no tiene ningún efecto.

  • result.json: el archivo json mostrará tanto la fuente de datos utilizada para configurar la instancia como si se produjo algún error

  • status.json: el archivo json muestra la fuente de datos utilizada y un desglose de los cuatro módulos si se produjo algún error y las horas de inicio y finalización.

¿Qué fuente de datos estoy usando?

Para configurar correctamente una instancia, cloud-init debe identificar correctamente la nube en la que se encuentra. Por lo tanto, saber qué fuente de datos se utiliza en el lanzamiento de una instancia puede ayudar en la depuración.

Para encontrar qué fuente de datos se está utilizando, ejecute el comando cloud-id:

$ cloud-id
nocloud

Si el ID de la nube no es el esperado, entonces ejecutar el script ds -identify en modo de depuración y proporcionarlo en un error puede ayudar a resolver cualquier problema:

  $ sudo DEBUG_LEVEL=2 DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force

El parámetro force permite que el comando se ejecute nuevamente ya que la instancia ya se ha lanzado. Las otras opciones aumentan la verbosidad del registro y colocan los registros en STDERR.

¿Cómo puedo volver a ejecutar la detección del datasource y el cloud-init?

Si un usuario está desarrollando una nueva fuente de datos o trabajando en la depuración de un problema, puede ser útil volver a ejecutar la detección de la fuente de datos y la configuración inicial de cloud-init.

Para hacer esto, fuerce a ds-identify para que se vuelva a ejecutar, limpie los registros y vuelva a ejecutar cloud-init:

$ sudo DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force
$ sudo cloud-init clean --logs
$ sudo cloud-init init --local
$ sudo cloud-init init

¿Cómo puedo depurar mis datos de usuario?

Dos de los problemas más comunes con los datos del usuario, que también son la configuración de la nube, son:

  • YAML con formato incorrecto

  • La primera línea no contiene # cloud-config

Para verificar su YAML, tenemos un breve script llamado validate-yaml.py que puede validar sus datos de usuario sin conexión.

Otra opción es ejecutar lo siguiente en una instancia para depurar los datos de usuario proporcionados al sistema:

$ cloud-init devel esquema --system --annotate

Dado que el lanzamiento de instancias en la nube puede costar dinero y demorar un poco más, a veces es más fácil lanzar instancias localmente usando Multipass o LXD:

User Data

Se pueden utilizar distintos formatos dependiendo de lo que se quiera realizar. Algunos formatos son: Contenidos comprimido con Gzip. Archivos con múltiples partes MIME, User-data script, archivos Include, Cloud Config Data, trabajos de inicio.

Línea de comandos del kernel

Cuando se utiliza la fuente de datos NoCloud, los usuarios pueden pasar datos de usuario a través de los parámetros de la línea de comandos del kernel.

Desactivación de datos de usuario

Cloud-init se puede configurar para ignorar cualquier dato de usuario proporcionado a la instancia. Esto permite que las imágenes personalizadas eviten que los usuarios rompan accidentalmente electrodomésticos cerrados. Establecer allow_userdata: false en la configuración deshabilitará cloud-init para que no procese datos de usuario.

Ejemplo del archivo user-data

#cloud-config

# This is the user-data configuration file for cloud-init. By default this sets
# up an initial user called "ubuntu" with password "ubuntu", which must be
# changed at first login. However, many additional actions can be initiated on
# first boot from this file. The cloud-init documentation has more details:
#
# https://cloudinit.readthedocs.io/
#
# Some additional examples are provided in comments below the default
# configuration.

# On first boot, set the (default) ubuntu user's password to "ubuntu" and
# expire user passwords
chpasswd:
  expire: true
  list:
  - ubuntu:ubuntu

# Enable password authentication with the SSH daemon
ssh_pwauth: true

## On first boot, use ssh-import-id to give the specific users SSH access to
## the default user
#ssh_import_id:
#- lp:my_launchpad_username
#- gh:my_github_username

## Add users and groups to the system, and import keys with the ssh-import-id
## utility
#groups:
#- robot: [robot]
#- robotics: [robot]
#- pi
#
#users:
#- default
#- name: robot
#  gecos: Mr. Robot
#  primary_group: robot
#  groups: users
#  ssh_import_id: foobar
#  lock_passwd: false
#  passwd: $5$hkui88$nvZgIle31cNpryjRfO9uArF7DYiBcWEnjqq7L1AQNN3

## Update apt database and upgrade packages on first boot
#package_update: true
#package_upgrade: true

## Install additional packages on first boot
#packages:
#- pwgen
#- pastebinit
#- [libpython2.7, 2.7.3-0ubuntu3.1]

## Write arbitrary files to the file-system (including binaries!)
#write_files:
#- path: /etc/default/keyboard
#  content: |
#    # KEYBOARD configuration file
#    # Consult the keyboard(5) manual page.
#    XKBMODEL="pc105"
#    XKBLAYOUT="gb"
#    XKBVARIANT=""
#    XKBOPTIONS="ctrl: nocaps"
#  permissions: '0644'
#  owner: root:root
#- encoding: gzip
#  path: /usr/bin/hello
#  content: !!binary |
#    H4sIAIDb/U8C/1NW1E/KzNMvzuBKTc7IV8hIzcnJVyjPL8pJ4QIA6N+MVxsAAAA=
#  owner: root:root
#  permissions: '0755'

## Run arbitrary commands at rc.local like time
#runcmd:
#- [ ls, -l, / ]
#- [ sh, -xc, "echo $(date) ': hello world!'" ]
#- [ wget, "http://ubuntu.com", -O, /run/mydir/index.html ]

Puedes ver más ejemplos de archivos de configuración user-data en la documentación de cloud-init.

Módulos

La lista completa de módulos la puedes ver en la documentación de cloud-init. Los módulos son las acciones que podemos llamar desde el archivo user-data. Por ejemplo el módulo ssh tiene la siguiente información:

SSH

Resumen: configure las claves SSH y SSH (host y autorizadas)

Este módulo maneja la mayor parte de la configuración para SSH y las claves SSH autorizadas y de host.

Llaves autorizadas Las claves autorizadas son una lista de claves SSH públicas que pueden conectarse a una cuenta de usuario en un sistema. Se almacenan en .ssh/allowed_keys en el directorio de inicio de esa cuenta. Las claves autorizadas para el usuario predeterminado definido en users se pueden especificar mediante ssh_authorized_keys. Las claves deben especificarse como una lista de claves públicas.

Consulte la documentación del módulo cc_set_passwords para habilitar/deshabilitar la autenticación de contraseña SSH

El inicio de sesión de root se puede habilitar/deshabilitar usando la clave de configuración disable_root. Las opciones de inicio de sesión de root se pueden especificar manualmente con disable_root_opts. Si se especifica disable_root_opts y contiene la cadena $USER, se reemplazará con el nombre de usuario del usuario predeterminado. De forma predeterminada, el inicio de sesión de root está deshabilitado y las opciones de inicio de sesión de root están configuradas en:

no-port-forwarding,no-agent-forwarding,no-X11-forwarding

Los tipos de claves públicas admitidas para ssh_authorized_keys son: dsa, rsa, ecdsa, ssh-rsa, …​

Usuarios y grupos

Resumen: configurar usuarios y grupos

Este módulo configura usuarios y grupos.

Los grupos para agregar al sistema se pueden especificar como una lista debajo de la clave de groups. Cada entrada de la lista debe contener un nombre del grupo como una cadena o un diccionario con el nombre del grupo como clave y una lista de usuarios que deben ser miembros del grupo como valor. Nota: Los grupos se agregan antes que los usuarios, por lo que los usuarios de una lista de grupos ya deben existir en el sistema.

La clave de configuración users toma una lista de usuarios para configurar. La primera entrada de esta lista se utiliza como usuario predeterminado para el sistema. Para preservar el usuario predeterminado estándar para la distribución, la cadena default puede usarse como la primera entrada de la lista de 'users'. Cada entrada en la lista de usuarios, que no sea una default, debe ser un diccionario de opciones para el usuario. Las claves de configuración admitidas para una entrada en usuarios son las siguientes:

  • name: el nombre de inicio de sesión del usuario expiredate: opcional. Fecha en la que se inhabilitará la cuenta del usuario. Por defecto: ninguno

  • gecos: Opcional. Comente sobre el usuario, generalmente una cadena separada por comas de nombre real e información de contacto. Por defecto: ninguno

  • groups: Opcional. Grupos adicionales para agregar al usuario. Por defecto: ninguno

  • homedir: Opcional. Directorio de inicio para el usuario. El valor predeterminado es / home / <nombre de usuario> inactive: opcional. Número de días desde que caduca una contraseña hasta que la cuenta se deshabilita permanentemente. Por defecto: ninguno

  • lock_passwd: opcional. Desactivar el inicio de sesión con contraseña. Predeterminado: verdadero

  • no_create_home: opcional. No cree el directorio de inicio. Predeterminado: falso

  • no_log_init: opcional. No inicialice lastlog y faillog para el usuario. Predeterminado: falso

  • no_user_group: opcional. No cree un grupo con el nombre del usuario. Predeterminado: falso

  • passwd: hash de la contraseña del usuario

  • primary_group: opcional. Grupo principal para usuario. Por defecto al nuevo grupo con el nombre del usuario.

  • selinux_user: Opcional. Usuario de SELinux para el inicio de sesión del usuario. Por defecto al usuario de SELinux por defecto.

  • shell: opcional. Shell de inicio de sesión del usuario. El valor predeterminado es no establecer shell, lo que da como resultado que se utilice un valor predeterminado específico del sistema.

  • snapuser: Opcional. Especifique una dirección de correo electrónico para crear el usuario como usuario Snappy a través de snap create-user. Si una cuenta de SSO de Ubuntu está asociada con la dirección, se solicitará el nombre de usuario y las claves SSH desde allí. Por defecto: ninguno

  • ssh_authorized_keys: opcional. Lista de claves SSH para agregar al archivo de claves de autenticación del usuario. Predeterminado: ninguno. Esta clave no se puede combinar con ssh_redirect_user.

  • ssh_import_id: opcional. ID SSH para importar para el usuario. Predeterminado: ninguno. Esta clave no se puede combinar con ssh_redirect_user.

  • ssh_redirect_user: opcional. Booleano establecido en verdadero para deshabilitar los inicios de sesión SSH para este usuario. Cuando se especifique, todas las claves SSH públicas de metadatos en la nube se configurarán en un estado deshabilitado para este nombre de usuario. Cualquier inicio de sesión SSH como este nombre de usuario expirará y aparecerá un mensaje para iniciar sesión en su lugar como el <default_username> configurado para esta instancia. Predeterminado: falso. Esta clave no se puede combinar con ssh_import_id o ssh_authorized_keys.

  • sudo: opcional. Regla sudo para usar, lista de reglas sudo para usar o Falso. Predeterminado: ninguno. La ausencia de la clave sudo, o un valor de none o false resultará en que no se escriban reglas sudo para el usuario.

  • system: Opcional. Cree usuario como usuario del sistema sin directorio de inicio. Predeterminado: falso

  • uid: opcional. La identificación del usuario. Predeterminado: el siguiente valor disponible.

Especificar un hash de la contraseña de un usuario con passwd es un riesgo de seguridad si se puede interceptar la configuración de la nube. Se prefiere la autenticación SSH.
Si especifica una regla sudo para un usuario, asegúrese de que la sintaxis de la regla sea válida, ya que cloud-init no la verifica.
La mayoría de estas opciones de configuración no se respetarán si el usuario ya existe. Las siguientes opciones son las excepciones; se aplican a usuarios ya existentes: plain_text_passwd, hashed_passwd, lock_passwd, sudo, ssh_authorized_keys, ssh_redirect_user. 
groups:
    - <group>: [<user>, <user>]
    - <group>

users:
    - default
    # User explicitly omitted from sudo permission; also default behavior.
    - name: <some_restricted_user>
      sudo: false
    - name: <username>
      expiredate: '<date>'
      gecos: <comment>
      groups: <additional groups>
      homedir: <home directory>
      inactive: '<number of days>'
      lock_passwd: <true/false>
      no_create_home: <true/false>
      no_log_init: <true/false>
      no_user_group: <true/false>
      passwd: <password>
      primary_group: <primary group>
      selinux_user: <selinux username>
      shell: <shell path>
      snapuser: <email>
      ssh_redirect_user: <true/false>
      ssh_authorized_keys:
          - <key>
          - <key>
      ssh_import_id: <id>
      sudo: <sudo config>
      system: <true/false>
      uid: <user id>

Instance Data

¿Qué son los datos de instancia?

Los datos de la instancia son la recopilación de todos los datos de configuración que procesa cloud-init para configurar la instancia. Esta configuración generalmente proviene de varias fuentes:

  • cloud-provided: servicios de metadatos proporcionados en la nube (también conocidos como metadata)

  • config-drive personalizado adjunto a la instancia

  • cloud-config seed file: archivos semilla de cloud-config de arranque en la cloud image o distribución

  • vendordata: proveedores proporcionados a partir de archivos o servicios de metadatos en la nube

  • userdata: datos de usuario proporcionados en la creación de la instancia

Cada proveedor de nube presenta metadatos de configuración únicos en diferentes formatos para la instancia. Cloud-init proporciona un caché de cualquier metadato rastreado, así como un conjunto versionado de claves de datos de instancia estandarizadas que pone a disposición en todas las plataformas.

Cloud-init produce un objeto json simple en /run/cloud-init/instance-data.json que representa una representación estandarizada y versionada de los metadatos que consume durante el arranque inicial. La intención es brindar los siguientes beneficios a los usuarios o scripts en cualquier sistema implementado con cloud-init: - objeto estático simple para consultar para obtener los metadatos de una instancia - velocidad: evite transacciones de red costosas para los metadatos que ya están almacenados en caché en el sistema de archivos - reducir la necesidad de volver a rastrear los servicios de metadatos para los metadatos estáticos que ya están almacenados en caché - aprovechar las mejores prácticas de cloud-init para rastrear servicios de metadatos en la nube - Evite implementar rastreadores de metadatos únicos en cada plataforma en la nube para obtener valores de configuración de metadatos.

Datasources

Las fuentes de datos son fuentes de datos de configuración para cloud-init que normalmente provienen del usuario (por ejemplo, datos de usuario) o provienen de la nube que creó la unidad de configuración (por ejemplo, metadatos). Los datos de usuario típicos incluirían archivos, yaml y scripts de shell, mientras que los metadatos típicos incluirían el nombre del servidor, la identificación de la instancia, el nombre para mostrar y otros detalles específicos de la nube.

Dado que hay varias formas de proporcionar estos datos (cada solución en la nube parece preferir su propia forma) internamente, se creó una clase abstracta de fuente de datos para permitir una única forma de acceder a los diferentes métodos de los sistemas en la nube para proporcionar estos datos a través del uso típico de subclases. .

Todos los metadatos procesados por las fuentes de datos de cloud-init se conservan como /run/cloud-init/instance-data.json. Cloud-init proporciona herramientas para introspectar rápidamente algunos de esos datos. Consulte Metadatos de instancia para obtener más información.

API

La interfaz actual que debe proporcionar un objeto de fuente de datos es la siguiente:

# returns a mime multipart message that contains
# all the various fully-expanded components that
# were found from processing the raw user data string
# - when filtering only the mime messages targeting
#   this instance id will be returned (or messages with
#   no instance id)
def get_userdata(self, apply_filter=False)

# returns the raw userdata string (or none)
def get_userdata_raw(self)

# returns a integer (or none) which can be used to identify
# this instance in a group of instances which are typically
# created from a single command, thus allowing programmatic
# filtering on this launch index (or other selective actions)
@property
def launch_index(self)

# the data sources' config_obj is a cloud-config formatted
# object that came to it from ways other than cloud-config
# because cloud-config content would be handled elsewhere
def get_config_obj(self)

# returns a list of public SSH keys
def get_public_ssh_keys(self)

# translates a device 'short' name into the actual physical device
# fully qualified name (or none if said physical device is not attached
# or does not exist)
def device_name_to_device(self, name)

# gets the locale string this instance should be applying
# which typically used to adjust the instances locale settings files
def get_locale(self)

@property
def availability_zone(self)

# gets the instance id that was assigned to this instance by the
# cloud provider or when said instance id does not exist in the backing
# metadata this will return 'iid-datasource'
def get_instance_id(self)

# gets the fully qualified domain name that this host should  be using
# when configuring network or hostname related settings, typically
# assigned either by the cloud provider or the user creating the vm
def get_hostname(self, fqdn=False)

def get_package_mirror_info(self)
NoCloud

La fuente de datos NoCloud permite al usuario proporcionar datos de usuario y metadatos a la instancia sin ejecutar un servicio de red (o incluso sin tener ninguna red).

Puede proporcionar metadatos y datos de usuario a un arranque vm local a través de archivos en un sistema de archivos vfat o iso9660. La etiqueta del volumen del sistema de archivos debe ser cidata o CIDATA.

Alternativamente, puede proporcionar metadatos a través de la línea de comandos del kernel o la opción "número de serie" SMBIOS. Los datos deben pasarse en forma de cadena:

ds = nocloud [; clave = val; clave = val]

o

ds = nocloud-net [; clave = val; clave = val]

Las claves permitidas son:

  • h o localhostnama

  • y o id-instancia

  • s o seedfrom

Con ds=nocloud, el valor de seedfrom debe comenzar con ' ' o file://. Con ds=nocloud-net, el valor de seedfrom debe comenzar con http:// o https://.

p.ej. puede pasar esta opción a QEMU:

-smbios tipo=1,serial=ds=nocloud-net;s=http://10.10.0.1:8000/

para hacer que NoCloud obtenga los metadatos completos de http://10.10.0.1:8000/meta-data después de que se complete la inicialización de la red.

Se espera que estos archivos de datos de usuario y metadatos tengan el siguiente formato.

/user-data
/meta-datos

Básicamente, los datos de usuario son simplemente datos de usuario y los metadatos son un archivo con formato yaml que representa lo que encontrará en el servicio de metadatos de EC2.

También puede proporcionar opcionalmente un archivo de datos del proveedor en el siguiente formato.

/vendor-data

Dada una imagen de nube de ubuntu 12.04 de disco en "disk.img", puede crear un disco suficiente siguiendo el ejemplo siguiente.

## create user-data and meta-data files that will be used
## to modify image on first boot
$ { echo instance-id: iid-local01; echo local-hostname: cloudimg; } > meta-data

$ printf "#cloud-config\npassword: passw0rd\nchpasswd: { expire: False }\nssh_pwauth: True\n" > user-data

## create a disk to attach with some user-data and meta-data
$ genisoimage  -output seed.iso -volid cidata -joliet -rock user-data meta-data

## alternatively, create a vfat filesystem with same files
## $ truncate --size 2M seed.img
## $ mkfs.vfat -n cidata seed.img
## $ mcopy -oi seed.img user-data meta-data ::

## create a new qcow image to boot, backed by your original image
$ qemu-img create -f qcow2 -b disk.img boot-disk.img

## boot the image and login as 'ubuntu' with password 'passw0rd'
## note, passw0rd was set as password through the user-data above,
## there is no password set on these images.
$ kvm -m 256 \
   -net nic -net user,hostfwd=tcp::2222-:22 \
   -drive file=boot-disk.img,if=virtio \
   -drive file=seed.iso,if=virtio

Nota: que el ID de instancia proporcionado (iid-local01 arriba) es lo que se usa para determinar si se trata de un "primer arranque". Entonces, si está realizando actualizaciones a los datos del usuario, también tendrá que cambiar eso o iniciar el disco de nuevo.

Además, puede inyectar un archivo /etc/network/interfaces proporcionando el contenido de ese archivo en el campo de metadatos de network-interfaces.

Ejemplo de metadatos:

instance-id: iid-abcdefg
network-interfaces: |
  iface eth0 inet static
  address 192.168.1.10
  network 192.168.1.0
  netmask 255.255.255.0
  broadcast 192.168.1.255
  gateway 192.168.1.254
hostname: myhost

La configuración de red también se puede proporcionar a cloud-init en Networking Config versión 1 o Networking Config versión 2 proporcionando esos datos formateados yaml en un archivo llamado network-config. Si se encuentra, este archivo anulará un archivo de network-interfaces.

Vea un ejemplo a continuación. Tenga en cuenta específicamente que este archivo no tiene una clave de red de nivel superior ya que ya se supone que es una configuración de red basada en el nombre del archivo.

version: 1
config:
   - type: physical
     name: interface0
     mac_address: "52:54:00:12:34:00"
     subnets:
        - type: static
          address: 192.168.1.10
          netmask: 255.255.255.0
          gateway: 192.168.1.254
version: 2
ethernets:
  interface0:
    match:
      mac_address: "52:54:00:12:34:00"
    set-name: interface0
    addresses:
      - 192.168.1.10/255.255.255.0
    gateway4: 192.168.1.254

Configuración de red

Para tener más información consultar la documentación de cloud-init.

Comportamiento por defecto

Cloud-init busca la configuración de la red en orden de precedencia creciente; cada elemento anula el anterior.

Fuente de datos: Por ejemplo, OpenStack puede proporcionar una configuración de red en el servicio de metadatos.

Configuración del sistema: Una entrada network: en los archivos de configuración /etc/cloud/cloud.cfg.d/*.

Línea de comandos del kernel: ip= o network-config=<Cadena de configuración YAML codificada en Base64>

Los datos de usuario no pueden cambiar la configuración de red de una instancia. En ausencia de configuración de red en cualquiera de las fuentes anteriores, Cloud-init escribirá una configuración de red que emitirá una solicitud de DHCP en una "primera" interfaz de red.

Se espera que el valor network-config sea una cadena YAML codificada en Base64 en formato Networking Config versión 1 o Networking Config versión 2. Opcionalmente, se puede comprimir con gzip antes de la codificación Base64.
Desactivación de la configuración de red

Los usuarios pueden deshabilitar la capacidad de configuración de red de Cloud-init y confiar en otros métodos, como la configuración integrada u otras personalizaciones. Cloud-init admite los siguientes métodos para deshabilitar cloud-init.

Línea de comandos del kernel: Cloud-init comprobará adicionalmente el parámetro network-config=disabled que desactivará automáticamente cualquier configuración de red.

Ejemplo de deshabilitación de la entrada de la línea de comandos del kernel:

network-config=disabled

Configuración cloud: En el diccionario de configuración combinado cloud-init, combinado de /etc/cloud/cloud.cfg y /etc/cloud/cloud.cfg.d/*:

network:
  config: disabled

Si la configuración de red de Cloud-init no se ha desactivado y no se encuentra otra información de red, se procederá a generar una configuración de red alternativa.

Fuentes de configuración de red

Cloud-init acepta varios formatos de configuración de red diferentes para admitir diferentes sustratos de nube. La fuente de datos para estas nubes en Cloud-init detectará y consumirá formatos de configuración de red específicos de la fuente de datos para usarlos al escribir la configuración de red de una instancia.

Salidas de configuración de red

Cloud-init convierte varias formas de configuración suministrada por el usuario o generada automáticamente en un estado de configuración de red interna. Desde este estado, Cloud-init delega la representación de la configuración a los formatos compatibles con Distro. Los siguientes renderizadores son compatibles con cloud-init:

  • ENI /etc/network/interfaces o ENI es compatible con el paquete ifupdown que se encuentra en Alpine Linux, Debian y Ubuntu.

  • Netplan Introducido en Ubuntu 16.10 (Yakkety Yak), netplan ha sido la herramienta de configuración de red predeterminada en Ubuntu desde 17.10 (Artful Aardvark). netplan consume la entrada de la versión 2 de Networking Config y muestra la configuración de red para los backends compatibles, como systemd-networkd y NetworkManager.

  • Sysconfig El formato Sysconfig es utilizado por RHEL, CentOS, Fedora y otros derivados.

Política de salida de red

La política predeterminada para seleccionar un renderizador de red en orden de preferencia es la siguiente:

  1. ENI

  2. Sysconfig

  3. Netplan

Al aplicar la política, Cloud-init comprueba si la instancia actual tiene los binarios y las rutas correctas para admitir el renderizador. Se selecciona el primer renderizador que se puede utilizar. Los usuarios pueden anular la política del renderizador de red proporcionando una configuración actualizada en cloud-config.

system_info:
  network:
    renderers: ['netplan', 'eni', 'sysconfig', 'freebsd', 'netbsd', 'openbsd']

Configuración de red ENI (Legacy)

Cloud-init admite la lectura y escritura de la configuración de red en el formato ENI(/etc/network/interfaces) que consume la herramienta ifupdown para analizar y aplicar la configuración de red.

Como formato de entrada, es obsoleto. En los casos en los que el formato ENI esté disponible y también esté disponible otro formato, preferirá utilizar el otro formato. Esto puede suceder en fuentes de datos NoCloud u OpenStack.

Más infomación en la documentación del formato /etc/network/interfaces.

Networking Config Version 1

Este formato de configuración de red permite a los usuarios personalizar las interfaces de red de su instancia mediante la asignación de configuración de subred, rutas de creación de dispositivos virtuales (enlaces, puentes, vlans) y configuración de DNS.

Los elementos necesarios de una configuración de red versión 1 son config y version.

Cloud-init leerá este formato de la configuración del sistema. Por ejemplo, lo siguiente podría estar presente en /etc/cloud/cloud.cfg.d/custom-networking.cfg:

network:
  version: 1
  config:
  - type: physical
    name: eth0
    subnets:
      - type: dhcp

El datacource de NoCloud también puede proporcionar una configuración de red de inicio en la nube en este formato.

Tipos de configuración

Dentro de la parte de config, los usuarios incluyen una lista de tipos de configuración. La lista actual de type de soporte es la siguiente:

-Físico (physical) -Enlace (bond) -Puente (bridge) -VLAN (vlan) -Servidor de nombres (nameserver) -Enrutador (route)

Los tipos físicos, de enlace, puente y VLAN también pueden incluir la configuración de IP en las subredes clave (subnets).

Más infomación en la documentación de cloud-init.

Networking Config Version 2

El soporte de Cloud-init para la configuración de red de la versión 2 es un subconjunto del formato de la versión 2 definido para la herramienta netplan. Cloud-init admite tanto la lectura como la escritura de la Versión 2; el último soporte requiere una distribución con netplan presente.

Passthrough de Netplan

En un sistema con netplan presente, cloud-init pasará la configuración de la Versión 2 a netplan sin modificaciones. En tales sistemas, no es necesario que se limite al subconjunto siguiente del formato de configuración de netplan.

Si está escribiendo o generando una configuración de red que puede usarse en sistemas que no son de netplan, debe limitarse al subconjunto descrito en este documento, o verá fallas de configuración de red en sistemas que no son de netplan.
Formato de configuración de la versión 2

La clave network tiene al menos dos elementos obligatorios. Primero debe incluir la versión: 2 y uno o más de los posibles types tipos de dispositivos.

Cloud-init leerá este formato de la configuración del sistema. Por ejemplo, lo siguiente podría estar presente en /etc/cloud/cloud.cfg.d/custom-networking.cfg:

network:
  version: 2
  ethernets: []

También se puede proporcionar en otras ubicaciones, incluido NoCloud.

Los valores de los tipos de dispositivos admitidos son los siguientes:

  • Ethernets (ethernets) -Bonos (bonds) -Puentes (bridges) -VLAN (vlans)

Cada bloque de tipo contiene definiciones de dispositivo como un mapa donde se encuentran las claves (llamadas "ID de configuración"). Cada entrada bajo los tipos puede incluir IP y / o configuración de dispositivo.

ID de configuración de dispositivo

Los nombres de las claves debajo de los mapas de definición por tipo de dispositivo (como ethernets:) se denominan “ID”. Deben ser únicos en todo el conjunto de archivos de configuración. Su propósito principal es servir como nombres de anclaje para dispositivos compuestos, por ejemplo, para enumerar los miembros de un puente que se está definiendo actualmente.

Hay dos clases de definiciones de dispositivo física / estructuralmente diferentes, y el campo ID tiene una interpretación diferente para cada una:

  • Dispositivos físicos (ejemplos: ethernet, wifi): Estos pueden aparecer y desaparecer dinámicamente entre reinicios e incluso durante el tiempo de ejecución (conexión en caliente). En el caso genérico, se pueden seleccionar por match: reglas sobre las propiedades deseadas, como nombre / patrón de nombre, dirección MAC, controlador o rutas de dispositivo. En general, estos coincidirán con cualquier número de dispositivos (a menos que se refieran a propiedades que sean únicas, como la ruta completa o la dirección MAC), por lo que sin más conocimientos sobre el hardware, estos siempre se considerarán un grupo.

Es válido especificar ninguna regla de coincidencia, en cuyo caso el campo ID es simplemente el nombre de la interfaz que debe coincidir. Esto es principalmente útil si desea que los casos simples sean simples, y así es como se ha realizado la configuración de dispositivos de red durante mucho tiempo.

Si hay reglas match:, entonces el campo ID es un nombre puramente opaco que solo se usa para referencias de definiciones de dispositivos compuestos en la configuración.

  • Dispositivos virtuales (ejemplos: veth, bridge, bond): Estos están completamente bajo el control de los archivos de configuración y la pila de red. Es decir. estos dispositivos se crean en lugar de combinarlos. Por lo tanto, match: y set-name: no son aplicables para estos, y el campo ID es el nombre del dispositivo virtual creado.

Ejemplo
  version: 2
  ethernets:
    # opaque ID for physical interfaces, only referred to by other stanzas
    id0:
      match:
        macaddress: '00:11:22:33:44:55'
      wakeonlan: true
      dhcp4: true
      addresses:
        - 192.168.14.2/24
        - 2001:1::1/64
      gateway4: 192.168.14.1
      gateway6: 2001:1::2
      nameservers:
        search: [foo.local, bar.local]
        addresses: [8.8.8.8]
      # static routes
      routes:
        - to: 192.0.2.0/24
          via: 11.0.0.1
          metric: 3
    lom:
      match:
        driver: ixgbe
      # you are responsible for setting tight enough match rules
      # that only match one device if you use set-name
      set-name: lom1
      dhcp6: true
    switchports:
      # all cards on second PCI bus; unconfigured by themselves, will be added
      # to br0 below
      match:
        name: enp2*
      mtu: 1280
  bonds:
    bond0:
      interfaces: [id0, lom]
  bridges:
    # the key name is the name for virtual (created) interfaces; no match: and
    # set-name: allowed
    br0:
      # IDs of the components; switchports expands into multiple interfaces
      interfaces: [wlp1s0, switchports]
      dhcp4: true
  vlans:
    en-intra:
      id: 1
      link: id0
      dhcp4: yes

Netplan: Configurador de red

Autor

Este material ha sido desarrollado por José Antonio Molina.

Licencia

El contenido de esta web está bajo una licencia de Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional.

Referencias

Instalar Ubuntu en raspberry Pi

SSH

Cloud-init y netplan

Docker

Configuración inicial de servidores

Rsync