One place for hosting & domains

      Variables

      Cómo leer y configurar variables de entorno y de shell en Linux


      Introducción

      Cuando interactúa con su servidor a través una sesión de shell, hay muchos elementos de información que el shell compila para determinar su comportamiento y acceso a los recursos. Algunas de estas opciones se incluyen en las opciones de configuración, y otras las determina la entrada del usuario.

      Una forma en que el shell realiza un seguimiento de todas estas configuraciones y detalles es en un área que se denomina entorno. El entorno es un área que el shell crea cada vez que inicia una sesión que contiene variables que definen las propiedades del sistema.

      En esta guía, analizaremos cómo interactuar con el entorno y leer o configurar variables de entorno y de shell de forma interactiva y mediante archivos de configuración.

      Cómo funcionan el entorno y las variables de entorno

      Cada vez que se genera una sesión de shell, se lleva a cabo un proceso para recopilar y compilar información que debería estar disponible para el proceso de shell y sus procesos secundarios. Los datos para estas configuraciones se obtienen de diversos archivos y configuraciones en el sistema.

      El entorno proporciona un medio a través del que el proceso de shell puede obtener o establecer configuraciones y, a la vez, transmitirlas a sus procesos secundarios.

      El entorno se implementa como cadenas que representan pares clave-valor. Si se transmiten múltiples valores, estos suelen separarse mediante símbolos de dos puntos (:). Normalmente, cada par tendrá un aspecto similar a este:

      KEY=value1:value2:...
      

      Si el valor contiene un espacio en blanco significativo, se utilizan comillas:

      KEY="value with spaces"
      

      Las claves en estos casos son variables. Pueden ser de dos tipos: variables de entorno o variables de shell.

      Las variables de entorno son variables definidas para el shell actual y heredadas por cualquier shell o proceso secundario. Las variables de entorno se utilizan para transmitir información a procesos que se producen desde el shell.

      Las variables de shell son variables que se encuentran exclusivamente dentro del shell en que se configuraron o definieron. A menudo, se utilizan para realizar un seguimiento de datos efímeros, como el directorio actual de trabajo.

      Por costumbre, estos tipos de variables suelen definirse utilizando letras en mayúsculas. Esto ayuda a los usuarios a distinguir las variables de entorno en otros contextos.

      Impresión de variables de entorno y de shell

      Cada sesión de shell hace un seguimiento de sus propias variables de entorno y de shell. Podemos acceder a ellas de diferentes formas.

      Podemos ver una lista de todas nuestras variables de entorno usando los comandos env o printenv. En su estado predeterminado, deben funcionar exactamente igual:

      Output

      SHELL=/bin/bash TERM=xterm USER=demouser LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca:... MAIL=/var/mail/demouser PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games PWD=/home/demouser LANG=en_US.UTF-8 SHLVL=1 HOME=/home/demouser LOGNAME=demouser LESSOPEN=| /usr/bin/lesspipe %s LESSCLOSE=/usr/bin/lesspipe %s %s _=/usr/bin/printenv

      Esto es bastante típico del resultado de printenv y env. La diferencia entre los dos comandos es visible solamente en su funcionalidad más específica. Por ejemplo, con printenv, puede solicitar los valores de variables individuales:

      Output

      /bin/bash

      Por otro lado, env le permite modificar el entorno en que se ejecutan los programas transmitiendo un conjunto de definiciones de variables a un comando como el siguiente:

      • env VAR1="value" command_to_run command_options

      Dado que, como vimos anteriormente, los procesos secundarios suelen heredar las variables de entorno del proceso principal, esto le da la oportunidad de anular valores o agregar otras variables al proceso secundario.

      Como se puede ver en el resultado de nuestro comando printenv, hay algunas variables de entorno configuradas en los archivos y procesos de nuestro sistema sin nuestra intervención.

      Se muestran las variables de entorno, pero ¿cómo vemos las variables de shell?

      El comando set se puede utilizar para esto. Si escribimos set sin ningún otro parámetro, obtendremos una lista de todas las variables de shell, variables de entorno, variables locales y funciones de shell:

      Output

      BASH=/bin/bash BASHOPTS=checkwinsize:cmdhist:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() . . .

      Por lo general, es una lista enorme. Es recomendable canalizarla a un programa de buscapersonas para manejar con mayor facilidad la cantidad de resultados:

      La cantidad de información adicional que recibiremos será un poco abrumadora. Probablemente, no necesitemos saber todas las funciones de bash que se definen, por ejemplo.

      Podemos filtrar el resultado especificando que set debe funcionar en el modo POSIX, lo que no imprimirá las funciones del shell. Podemos ejecutarlo en un subshell para que no cambie nuestro entorno actual:

      Esto enumerará todas las variables de entorno y de shell que están definidas.

      Podemos intentar comparar este resultado con el resultado de los comandos env o printenv para intentar obtener una lista que incluya únicamente variables de shell, pero el resultado no será preciso por las diferentes formas en que estos comandos generan información:

      • comm -23 <(set -o posix; set | sort) <(env | sort)

      Esto probablemente seguirá incluyendo algunas variables de entorno, debido a que el comando set genera valores entre comillas, mientras que los comandos printenv y env no generan los valores de las cadenas entre comillas.

      Aún así, le dará una buena idea de las variables de entorno y de shell que se configuran en su sesión.

      Estas variables se utilizan para toda clase de cosas. Proporcionan una forma alternativa de establecer valores persistentes para la sesión entre procesos, sin realizar cambios en un archivo.

      Variables frecuentes de entorno y de shell

      Algunas variables de entorno y de shell son muy útiles y se utilizan con bastante frecuencia. Aquí hay algunas variables frecuentes de entorno con las que se encontrará:

      • SHELL: Describe el shell que interpretará cualquier comando que ingrese. En la mayoría de los casos, será bash de forma predeterminada, pero se pueden establecer otros valores si prefiere otras opciones.
      • TERM: Especifica el tipo de terminal a emular cuando se ejecuta el shell. Se pueden emular diferentes terminales de hardware para diferentes requisitos de funcionamiento. Sin embargo, generalmente no tendrá que preocuparse por esto.
      • USER: El usuario que inició sesión actualmente.
      • PWD: El directorio actual de trabajo.
      • OLDPWD: El directorio anterior de trabajo. Esto se mantiene en el shell para volver a su directorio anterior ejecutando cd -.
      • LS_COLORS: Define los códigos de color que se utilizan para añadir de forma opcional un resultado de color al comando ls. Esto se utiliza para distinguir diferentes tipos de archivos y proporcionar más información al usuario de forma rápida.
      • MAIL: La ruta al buzón del usuario actual.
      • PATH: Una lista de directorios que el sistema comprobará cuando busque comandos. Cuando un usuario escriba un comando, el sistema comprobará los directorios en este orden para el ejecutable.
      • LANG: Las configuraciones actuales de idioma y localización, incluida la codificación de caracteres.
      • HOME: El directorio principal del usuario actual.
      • _: El comando más reciente ejecutado anteriormente.

      Además de estas variables de entorno, algunas variables de shell que aparecerán a menudo son:

      • BASHOPTS: La lista de opciones que se utilizaron cuando se ejecutó bash. Esto puede ser útil para averiguar si el entorno de shell funcionará de la forma que usted desea.
      • BASH_VERSION: La versión de bash que se está ejecutando, en un formato que los usuarios puedan leer.
      • BASH_VERSINFO: La versión de bash, en un resultado que un equipo pueda leer.
      • COLUMNS: El número de ancho de columnas que se utilizan para generar el resultado en la pantalla.
      • DIRSTACK: La pila de directorios que están disponibles con los comandos pushd y popd.
      • HISTFILESIZE: La cantidad de líneas del historial de comandos que se almancenan en un archivo.
      • HISTSIZE: La cantidad de líneas del historial de comandos que se permiten en la memoria.
      • HOSTNAME: El nombre de host de la computadora en este momento.
      • IFS: El separador de campo interno para separar las entradas en la línea de comandos. De forma predeterminada, es un espacio.
      • PS1: La definición de la entrada del comando principal. Esto se utiliza para definir cómo se ve la entrada de la línea de comandos cuando se inicia una sesión de shell. PS2 se utiliza para declarar las entradas de la línea de comandos secundarias para cuando un comando se extiende a varias líneas.
      • SHELLOPTS: Opciones de shell que se pueden configurar con la opción set.
      • UID: El UID del usuario actual.

      Configuración de variables de entorno y de shell

      Para entender mejor la diferencia entre las variables de entorno y de shell, y para introducir la sintaxis para configurar estas variables, haremos una pequeña demostración.

      Creación de variables de shell

      Empezaremos definiendo una variable de shell en nuestra sesión actual. Esto es fácil de lograr; solo necesitamos especificar un nombre y un valor. Seguiremos la norma de mantener el nombre de la variable en mayúsculas y lo configuraremos en una cadena simple.

      Aquí utilizamos comillas, ya que el valor de nuestra variable contiene un espacio. Además, usamos comillas simples porque el signo de exclamación es un carácter especial en el shell de bash que generalmente se expande al historial de bash si no se escapa o se introduce en comillas simples.

      Ahora, tenemos una variable de shell. Esta variable está disponible en nuestra sesión actual, pero no se transmitirá a los procesos secundarios.

      Podemos ver esto realizando una búsqueda de nuestra nueva variable en el resultado de set:

      Output

      TEST_VAR='Hello World!'

      Podemos verificar que esta no es una variable de entorno intentando lo mismo con printenv:

      No debería aparecer ningún resultado.

      Aprovecharemos esto como una oportunidad para demostrar una forma de acceder al valor de cualquier variable de entorno o de shell.

      Output

      Hello World!

      Como se puede ver, se hace referencia al valor de una variable al precederla con un signo $. El shell interpreta que esto significa que debe sustituir el valor de la variable cuando se encuentre con casos como este.

      Ahora tenemos una variable de shell. No debería transmitirse a ningún proceso secundario. Podemos generar un nuevo shell de bash desde el actual para demostrar:

      Si escribimos bash para generar un shell secundario y, luego, intentamos acceder al contenido de la variable, no se obtendrá ningún resultado. Eso es lo que esperábamos.

      Vuelva a nuestro shell original escribiendo exit:

      Creación de variables de entorno

      Ahora, vamos a convertir nuestra variable de shell en una variable de entorno. Podemos hacer esto exportando la variable. El comando para hacerlo se denomina correctamente:

      Esto convertirá nuestra variable en una variable de entorno. Podemos verificar que el cambio se realizó revisando nuevamente nuestra lista de variables de entorno:

      Output

      TEST_VAR=Hello World!

      Esta vez, aparecerá nuestra variable. Intentemos nuestro experimento de nuevo con nuestro shell secundario:

      Output

      Hello World!

      ¡Genial! Nuestro shell secundario recibió la variable establecida por el shell principal. Antes de salir de este shell secundario, intentemos exportar otra variable. Podemos configurar variables de entorno en un solo paso de esta manera:

      • export NEW_VAR="Testing export"

      Esta es una prueba de que se exportó como variable de entorno:

      Output

      NEW_VAR=Testing export

      Ahora, regresemos a nuestro shell original:

      Veamos si nuestra nueva variable está disponible:

      No se muestra ningún resultado.

      Esto se debe a que las variables de entorno solo se transmiten a procesos secundarios. No hay una forma incorporada de configurar variables de entorno del shell principal. Eso es bueno en la mayoría de casos y evita que los programas afecten al entorno de funcionamiento desde el que fueron invocados.

      La variable NEW_VAR se configuró como una variable de entorno en nuestro shell secundario. Esta variable estaría disponible para sí misma y para cualquiera de sus shells y procesos secundarios. Cuando regresemos a nuestro shell principal, el entorno se eliminará.

      Degradación y anulación de variables

      Todavía tenemos nuestra variable TEST_VAR definida como una variable de entorno. Podemos volver a convertirla en una variable de shell escribiendo:

      Ya no es una variable de entorno:

      Sin embargo, aún es una variable de shell:

      Output

      TEST_VAR='Hello World!'

      Si queremos anular por completo una variable, de shell o de entorno, podemos hacerlo con el comando unset:

      Podemos verificar que ya no está configurada:

      No se genera ningún resultado porque la variable se anuló.

      Configuración de variables de entorno al iniciar sesión

      Ya mencionamos que muchos programas utilizan variables de entorno para decidir los detalles de cómo operar. No queremos tener que configurar variables importantes cada vez que iniciemos una nueva sesión de shell, y ya vimos cuántas variables ya están configuradas al iniciar sesión, entonces ¿cómo creamos y definimos las variables automáticamente?

      En realidad, este es un problema más complejo de lo que parece inicialmente debido a los numerosos archivos de configuración que el shell de bash lee dependiendo de cómo se inicie.

      Diferencia entre las sesiones de shell interactivas, no interactivas, con inicio de sesión y sin inicio de sesión

      El shell de bash lee diferentes archivos de configuración dependiendo de cómo se inicia la sesión.

      Una distinción entre las diferentes sesiones es si el shell se genera como una sesión con inicio de sesión o sin inicio de sesión.

      Un shell con inicio de sesión es una sesión de shell que comienza cuando se autentica al usuario. Si inicia sesión en una sesión de terminal o mediante SSH y realiza una autenticación, la sesión de shell se configurará como un shell con inicio de sesión.

      Si inicia una nueva sesión de shell desde la sesión autenticada, como hicimos invocando al comando bash desde el terminal, se inicia una sesión de shell sin inicio de sesión. No se solicitaron sus detalles de autenticación cuando inició su shell secundario.

      Otra distinción que se puede hacer es si una sesión de shell es interactiva o no interactiva.

      Una sesión de shell interactiva es una sesión de shell que se conecta a un terminal. Una sesión de shell no interactiva es una que no se conecta a una sesión de terminal.

      Cada sesión de shell se clasifica como una sesión con inicio de sesión o sin inicio de sesión y como interactiva o no interactiva.

      Una sesión normal que comienza con SSH suele ser un shell con inicio de sesión interactivo. Normalmente, una secuencia de comandos ejecutada desde la línea de comandos se ejecuta en un shell no interactivo y sin inicio de sesión. Una sesión de terminal puede ser cualquier combinación de estas dos propiedades.

      Si una sesión de shell se clasifica como un shell con inicio de sesión o un shell sin inicio de sesión, tiene repercusiones sobre qué archivos se leen para iniciar la sesión de shell.

      Una sesión iniciada como sesión con inicio de sesión leerá primero los detalles de la configuración del archivo /etc/profile. Luego, buscará el primer archivo de configuración de shell con inicio de sesión en el directorio principal del usuario para obtener detalles de configuración específicos del usuario.

      Lee el primer archivo que puede encontrar con ~/.bash_profile, ~/.bash_login y ~/.profile, y no lee ningún otro archivo.

      Por el contrario, una sesión definida como shell sin inicio de sesión leerá /etc/bash.bashrc y, luego, el archivo ~/.bashrc específico del usuario para crear su entorno.

      Los shells no interactivos leen la variable de entorno llamada BASH_ENV y leen el archivo especificado para definir el nuevo entorno.

      Implementación de variables de entorno

      Como se puede ver, hay diversos archivos que generalmente necesitaríamos revisar para realizar nuestra configuración.

      Eso ofrece gran flexibilidad que puede ser útil en situaciones específicas en que queremos ciertas configuraciones en un shell con inicio de sesión y otras configuraciones en un shell sin inicio de sesión. Sin embargo, la mayoría de las veces preferiremos las mismas configuraciones en ambas situaciones.

      Por suerte, la mayoría de las distribuciones de Linux configura los archivos de configuración con inicio de sesión para obtener los archivos de configuración sin inicio de sesión. Eso significa que puede definir variables de entorno que quiera que sean de ambos tipos de sesión dentro de los archivos de configuración sin inicio de sesión. Luego, se leerán en ambos casos.

      Por lo general, configuraremos variables de entorno específicas de usuario y, normalmente, preferiremos que nuestras configuraciones estén disponibles en shells con inicio de sesión y sin inicio de sesión. Eso significa que el lugar para definir estas variables está en el archivo ~/.bashrc.

      Abra este archivo ahora:

      Lo más probable es que ya contenga bastantes datos. Muchas de las definiciones aquí son para configurar opciones de bash, que no están relacionadas con variables de entorno. Puede configurar variables de entorno de la misma manera en que lo haría en la línea de comandos:

      Cualquier nueva variable de entorno se puede añadir en cualquier lugar del archivo ~/.bashrc, siempre que no se coloque en el medio de otro comando o para crear un bucle. Luego, podemos guardar y cerrar el archivo. La próxima vez que inicie una sesión de shell, su declaración de variable de entorno se leerá y pasará al entorno de shell. Puede forzar su sesión actual a leer el archivo escribiendo lo siguiente:

      Si necesita configurar variables para todo el sistema, es recomendable añadirlas a /etc/profile, /etc/bash.bashrc o /etc/environment.

      Conclusión

      Las variables de entorno y de shell siempre están presentes en las sesiones de shell y pueden ser muy útiles. Son una forma interesante para que un proceso principal establezca los detalles de la configuración para sus procesos secundarios y son una forma de configurar opciones fuera de los archivos.

      Eso tiene muchas ventajas en situaciones específicas. Por ejemplo, algunos mecanismos de implementación utilizan las variables de entorno para configurar la información de autenticación. Eso es útil porque no requiere guardarlos en archivos que terceros puedan ver.

      Hay muchos otros casos más triviales, pero también más frecuentes, en que deberá leer o alterar el entorno de su sistema. Estas herramientas y técnicas le darán una buena base para realizar estos cambios y usarlos correctamente.



      Source link

      Comment lire et configurer les variables d’environnement et de shell sous Linux


      Introduction

      Au cours d’une interaction avec votre serveur via une session shell, shell compile de nombreuses informations pour déterminer son comportement et accéder aux ressources. Certains de ces réglages se font dans les paramètres de configuration, d’autres doivent être saisis par l’utilisateur.

      Le shell assure notamment le suivi de tous ces paramètres et ces détails par le biais d’une zone qu’il gère, appelée environnement. L’environnement est une zone que le shell construit à chaque fois qu’il démarre une session qui contient des variables définissant les propriétés du système.

      Dans ce guide, nous allons voir de quelle manière interagir avec l’environnement, lire ou configurer les variables d’environnement et de shell de manière interactive et via les fichiers de configuration.

      Chaque fois qu’une session shell est lancée, un processus est mis en place pour collecter et rassembler les informations qui devraient être à la disposition du processus shell et de ses processus enfant. Il obtient les données de ces paramètres à partir d’un grand nombre de fichiers et paramètres différents qui se trouvent sur le système.

      L’environnement fournit un moyen par lequel le processus shell peut obtenir ou configurer les paramètres et, à son tour, les transmettre à ses processus enfant.

      L’environnement est implémenté en tant que chaînes qui représentent des paires de valeurs clé. Si la transmission comporte plusieurs valeurs, elles sont généralement séparées par un :. Chaque paire ressemblera généralement à ceci :

      KEY=value1:value2:...
      

      Si la valeur contient un white-space significatif, des guillemets sont utilisés :

      KEY="value with spaces"
      

      Dans ces scénarios, les clés sont des variables. Elles peuvent être de deux types différents : les variables d’environnement ou les variables de shell.

      Les variables d’environnement sont des variables qui sont définies pour le shell en cours d’utilisation et héritées par tous les shells ou processus enfant. Les variables d’environnement servent à transmettre des informations dans les processus qui se déclenchent depuis le shell.

      Les variables de shell sont des variables qui sont exclusivement contenues dans le shell dans lequel elles ont été configurées ou définies. Elles sont couramment utilisées pour garder un suivi des données éphémères, comme le répertoire actuellement utilisé.

      Par convention, ces types de variables sont généralement définis par des majuscules. Cela aide les utilisateurs à distinguer les variables d’environnement dans d’autres contextes.

      Impression des variables de shell et d’environnement

      Chaque session de shell garde une trace de ses propres variables de shell et d’environnement. Nous pouvons y accéder de différentes façons.

      Nous pouvons voir une liste de toutes nos variables d’environnement en utilisant les commandes env ou printenv. Dans leur état par défaut, elles devraient fonctionner exactement de la même manière :

      Output

      SHELL=/bin/bash TERM=xterm USER=demouser LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca:... MAIL=/var/mail/demouser PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games PWD=/home/demouser LANG=en_US.UTF-8 SHLVL=1 HOME=/home/demouser LOGNAME=demouser LESSOPEN=| /usr/bin/lesspipe %s LESSCLOSE=/usr/bin/lesspipe %s %s _=/usr/bin/printenv

      Ceci est assez typique pour la sortie à la fois de printenv et env. La différence entre les deux commandes ne se voit que dans leur fonctionnalité plus spécifique. Par exemple, avec printenv, vous pouvez demander les valeurs de variables individuelles :

      Output

      /bin/bash

      En revanche, env vous permet de modifier l'environnement dans lequel les programmes s'exécutent en transmettant un ensemble de définitions de variables par le biais d'une commande, de la manière suivante :

      • env VAR1="value" command_to_run command_options

      Étant donné que, comme nous l'avons appris précédemment, les processus enfant héritent généralement des variables d'environnement du processus parent, vous pouvez remplacer les valeurs ou ajouter des variables supplémentaires à l'enfant.

      Comme vous pouvez le constater à partir du résultat de notre commande printenv, de nombreuses variables d'environnement sont configurées par les fichiers et les processus de notre système sans rien à saisir.

      Ces dernières montrent les variables d'environnement, mais comment consulter les variables de shell ?

      Pour cela, vous pouvez utiliser la commande set. Si nous saisissons set sans aucun autre paramètre, nous obtiendrons une liste de toutes les variables de shell, variables d'environnement, variables locales et fonctions de shell :

      Output

      BASH=/bin/bash BASHOPTS=checkwinsize:cmdhist:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() . . .

      On se retrouve généralement avec une énorme liste. Il est vivement conseillé de les intégrer dans un programme de pagination afin de pouvoir traiter la quantité de résultats obtenus plus facilement :

      La quantité d'informations supplémentaires que nous recevons est quelque peu déroutante. Nous n'avons probablement pas à connaître toutes les fonctions de bash configurées, par exemple.

      Nous pouvons nettoyer le résultat en spécifiant que set devrait s'exécuter en mode POSIX, ce qui n'imprimera pas les fonctions de shell. Nous pouvons l'exécuter dans un sous-shell pour qu'il ne change pas notre environnement actuel :

      Vous obtiendrez ainsi une liste de toutes les variables d'environnement et de shell configurées.

      Nous pouvons tenter de comparer ce résultat avec celui obtenu avec les commandes env ou printenv afin d'obtenir une liste des variables de shell uniquement, mais cela risque d'être imparfait en raison des différentes façons dont ces commandes renverront les informations :

      • comm -23 <(set -o posix; set | sort) <(env | sort)

      Il est probable que la liste contienne encore quelques variables d'environnement, car la commande set déclenche les valeurs citées, tandis que les commandes printenv et env ne citent pas les valeurs des chaînes de caractères.

      Cela devrait vous donner une bonne idée des variables d'environnement et de shell qui se trouvent dans votre session.

      Ces variables sont utilisées pour toute sorte de choses. Elles vous offrent une alternative pour configurer des valeurs persistantes pour la session entre les processus, sans avoir à écrire les modifications sur un fichier.

      Variables d'environnement et de shell communes

      Certaines variables d'environnement et de shell sont très utiles et souvent référencées. Voici quelques variables d'environnement communes que vous allez rencontrer :

      • SHELL : cette variable décrit le shell qui interprétera les commandes que vous saisissez. Dans la plupart des cas, il s'agira de bash par défaut, mais d'autres valeurs peuvent être configurées si vous préférez utiliser d'autres options.
      • TERM : cette variable spécifie le type de terminal à émuler à l'exécution du shell. Il est possible d'émuler différents terminaux de matériel pour différentes exigences d'exploitation. Cependant, de manière générale, vous n'aurez pas à vous soucier de cela.
      • USER : l'utilisateur actuellement connecté.
      • PWD : le répertoire de travail en cours d'exécution.
      • OLDPWD : le précédent répertoire utilisé. Il est conservé par le shell afin de pouvoir revenir au précédent répertoire en exécutant cd-.
      • LS_COLORS : cette variable définit les codes de couleurs qui vous servent à ajouter une couleur aux résultats obtenus avec la commande ls. Elle vous permet de distinguer les différents types de fichiers et donne de plus amples informations à l'utilisateur en un coup d'œil.
      • MAIL : le chemin vers la boîte de réception de l'utilisateur en cours.
      • PATH : une liste des répertoires que le système vérifiera lorsque vous recherchez des commandes. Lorsqu'un utilisateur saisit une commande, le système vérifiera les répertoires dans cet ordre pour l'exécutable.
      • LANG : les paramètres actuels de langue et de localisation, y compris le codage de caractères.
      • HOME : le répertoire d'accueil de l'utilisateur actuellement connecté.
      • _ : la plus récente des précédentes commandes exécutées.

      En plus de ces variables d'environnement, vous verrez souvent les variables de shell suivantes :

      • BASHOPTS : la liste des options qui ont été utilisées lorsque bash a été exécuté. Cette variable peut s'avérer utile pour savoir si l'environnement de shell fonctionne de la manière dont vous le souhaitez.
      • BASH_VERSION : la version de bash en cours d'exécution, dans un format lisible par l'humain.
      • BASH_VERSINFO : la version de bash en cours d'exécution, dans un format lisible par une machine.
      • COLUMNS : le nombre de colonnes larges qui servent à dessiner le résultat à l'écran.
      • DIRSTACK : la pile des répertoires qui sont disponibles avec les commandes pushd et popd.
      • HISTFILESIZE : le nombre de lignes d'historique de commande enregistrées dans un fichier.
      • HISTSIZE : le nombre de lignes d'historique de commandes autorisées en mémoire.
      • HOSTNAME :le nom d'hôte de l'ordinateur du moment.
      • IFS : le séparateur de champ interne utilisé pour séparer les entrées sur la ligne de commande. Un espace est utilisé par défaut.
      • PS1 : la configuration de l'invite de la commande principale. Cette variable sert à définir à quoi ressemble votre invite lorsque vous commencez une session de shell. La variable PS2 permet de déclarer des invites secondaires lorsqu'une commande s'étend sur plusieurs lignes.
      • SHELLOPTS : les options de shell qui peuvent être configurées avec l'option set.
      • UID : l'IUD de l'utilisateur actuellement connecté.

      Configuration des variables de shell et d'environnement

      Pour vous aider à mieux comprendre la différence entre les variables de shell et les variables d'environnement et vous présenter la syntaxe à utiliser pour ces variables, nous allons faire une petite démonstration.

      Création de variables de shell

      Nous allons commencer par configurer une variable de shell dans notre session en cours. Ceci est facile à réaliser, nous n'avons qu'à spécifier un nom et une valeur. Nous allons adhérer à la convention qui consiste à utiliser uniquement des majuscules pour le nom de la variable et à la configurer sur une chaîne simple.

      Ici, nous avons utilisé des guillemets, car la valeur de notre variable contient un espace. De plus, nous avons utilisé des guillemets simples, car le point d'exclamation est un caractère spécial dans le shell bash qui se développe généralement en historique bash si on n'en sort pas ou s'il n'est pas mis entre des guillemets simples.

      Nous disposons maintenant d'une variable de shell. Cette variable est disponible dans notre session en cours, mais elle ne sera pas transmise aux processus enfant.

      Nous pouvons voir cela en recherchant notre nouvelle variable dans le résultat de set :

      Output

      TEST_VAR='Hello World!'

      Nous pouvons vérifier s'il ne s'agit pas d'une variable d'environnement en essayant la même méthode avec printenv :

      Aucun résultat ne devrait être renvoyé.

      Utilisons cela comme une opportunité de présenter un moyen d'accéder à la valeur de toute variable de shell ou d'environnement.

      Output

      Hello World!

      Comme vous pouvez le voir, vous faites référence à la valeur d'une variable en la faisant précéder d'un signe $. Le shell considère que cela signifie qu'il devrait substituer la valeur de la variable lorsqu'il la rencontre.

      Nous disposons donc maintenant d'une variable de shell. Elle ne devrait être transmise à aucun processus enfant. Nous pouvons générer un shell bash new à partir de notre shell actuel pour le démontrer :

      Si nous saisissons bash pour générer un shell enfant, puis tentons d'accéder ensuite au contenu de la variable, aucun résultat ne sera renvoyé. C'est ce à quoi nous nous attendions.

      Revenont à notre shell d'origine en saisissant exit :

      Création de variables d'environnement

      Maintenant, transformons notre variable de shell en variable d'environnement. Pour se faire, il faut exporter la variable. La commande qui permet de le faire se nomme à juste titre :

      Cela permettra de transformer notre variable en variable d'environnement. Nous pouvons vérifier cela en contrôlant à nouveau notre liste d'environnements :

      Output

      TEST_VAR=Hello World!

      Cette fois, notre variable s'affiche. Recommençons notre expérience avec notre shell enfant :

      Output

      Hello World!

      Super ! Notre shell enfant a reçu la variable définie par son parent. Avant de quitter ce shell enfant, essayons d'exporter une autre variable. Nous pouvons configurer les variables d'environnement en une seule étape, comme suit :

      • export NEW_VAR="Testing export"

      Vérifiez qu'elle est bien exportée en tant que variable d'environnement :

      Output

      NEW_VAR=Testing export

      Maintenant, retournons dans notre shell d'origine :

      Voyons si notre nouvelle variable est disponible :

      Aucun résultat n'est renvoyé.

      En effet, les variables d'environnement ne sont transmises qu'aux processus enfant. Il n'existe pas de moyen intégré de configurer les variables d'environnement du shell parent. Ce qui est une bonne chose dans la plupart des cas. Cela empêche également les programmes de modifier l'environnement d'exploitation à partir duquel ils ont été appelés.

      La variable NEW_VAR a été configurée comme une variable d'environnement dans notre shell enfant. Cette variable serait disponible pour elle-même et tous ses shells et processus enfant. Lorsque nous sommes revenus à notre shell principal, cet environnement a été détruit.

      Rétrogradation et annulation des variables

      Notre variable TEST-VAR est toujours définie comme une variable d'environnement. Nous pouvons la reconvertir en une variable de shell en saisissant :

      Il ne s'agit plus d'une variable d'environnement :

      Cependant, il s'agit toujours d'une variable deshell :

      Output

      TEST_VAR='Hello World!'

      Si nous voulons annuler complètement une variable, qu'elle soit de shell ou d'environnement, nous pouvons le faire avec la commande unset :

      Nous pouvons vérifier qu'elle n'est plus configurée :

      Aucun résultat n'est renvoyé car la variable a été annulée.

      Configuration de variables d'environnement à la connexion

      Nous avons déjà mentionné que de nombreux programmes utilisent des variables d'environnement pour décider des spécificités de l'utilisation de ces variables. Nous ne voulons pas avoir à configurer d'importantes variables à chaque fois que nous lançons une nouvelle session shell. Nous avons d'ailleurs déjà vu combien de variables sont déjà configurées lors de la connexion. Alors, de quelle manière créer et configurer des variables automatiquement ?

      Il s'agit en fait d'un problème plus complexe qu'il n'y paraît initialement, en raison des nombreux fichiers de configuration que le shell bash doit lire en fonction de la manière dont il est démarré.

      La différence entre les sessions de shell Login, Non-Login, Interactive et Non-Interactive

      Le shell bash lit différents fichiers de configuration en fonction de la façon dont la session est lancée.

      Il existe une manière de distinguer les différentes sessions qui consiste à établir si le shell est généré comme une session de login ou non-login.

      Un shell de login est une session de shell qui commence par l'authentification de l'utilisateur. Si vous vous connectez à une session via un terminal ou SSH et que vous vous authentifiez, votre session sera considérée comme un shell de login.

      Si vous démarrez une nouvelle session shell à partir de votre session authentifiée, comme nous l'avons fait en appelant la commande bash à partir du terminal, une session shell de non-login sera lancée. Vos données d'authentification ne vous ont pas été demandées lorsque vous avez démarré votre shell enfant.

      On peut également noter une autre distinction qui consiste à déterminer si une session de shell est interactive ou non-interactive.

      Une session shell interactive est une session shell qui est rattachée à un terminal. Une session shell non-interactive est une session qui n'est pas rattachée à une session de terminal.

      Donc, chaque session shell est classée comme étant de login ou non-login et interactive ou non-interactive.

      Une session normale qui commence par SSH est généralement une session shell de login interactive. Un script exécuté à partir de la ligne de commande est généralement exécuté dans une session shell non-interactive et non-login. Une session de terminal peut être une combinaison de ces deux propriétés.

      Que la session soit classée comme un shell de login ou non-login a des implications sur les fichiers à lire pour initialiser la session de shell.

      Une session lancée par comme une session de login lira les détails de configuration tout d'abord à partir du fichier /etc/profile. Ensuite, elle recherchera le premier fichier de configuration de shell de login qui se trouve dans le répertoire d'accueil de l'utilisateur pour obtenir des détails de configuration spécifiques.

      Elle lit le premier fichier qu'elle peut trouver sur ~/.bash_profile, ~/.bash_login et ~/.profile, et ne lit aucun autre fichier.

      En revanche, une session définie comme un shell de non-login lira le fichier /etc/bash.bashrc puis ~/.bashrc spécifique à l'utilisateur pour créer son environnement.

      Les shells non-interactifs lisent la variable d'environnement appelée BASH_ENV et lisent le fichier spécifié pour définir le nouvel environnement.

      Implémentation de variables d'environnement

      Comme vous pouvez le voir, il existe un grand nombre de fichiers différents que nous devrons généralement consulter pour placer nos paramètres.

      Cela permet une grande flexibilité et nous sera d'une grande utilité dans des situations spécifiques, lorsque nous souhaiterons avoir certains paramètres dans un shell de login et d'autres paramètres dans un shell de non-login. Cependant, la plupart du temps nous voudrons avoir les mêmes paramètres dans les deux situations.

      Heureusement, la plupart des distributions Linux configurent les fichiers de configuration de login pour obtenir les fichiers de configuration de non-login. Cela signifie que vous pouvez configurer les variables d'environnement que vous souhaitez avoir dans les deux à l'intérieur des fichiers de configuration de non-login. Ils seront ensuite lus dans les deux scénarios.

      Nous configurerons généralement des variables d'environnement spécifiques à l'utilisateur et souhaiterons que nos réglages soient disponibles dans les deux shells, de login et de non-login. Cela signifie que l'endroit où configurer ces variables se trouve dans le fichier ~/.bashrc.

      Maintenant, ouvrez ce fichier :

      Il est probable qu'il contienne déjà un certain nombre de données. La plupart des définitions ici servent à la configuration des options bash, qui ne sont pas liées à des variables d'environnement. Vous pouvez configurer les variables d'environnement comme vous le feriez avec la ligne de commande suivante :

      Toute nouvelle variable d'environnement peut être ajoutée n'importe où dans le fichier ~/.bashrc tant qu'elle n'est pas placée au milieu d'une autre commande ou pour une boucle. Ensuite, nous pouvons sauvegarder et fermer le fichier. La prochaine fois que vous lancerez une session de shell, la déclaration de votre variable d'environnement sera lue et transmise à l'environnement shell. Vous pouvez forcer votre session actuelle à lire le fichier en saisissant ce qui suit :

      Si vous devez configurer des variables à l'échelle du système, vous devriez éventuellement envisager de les ajouter à /etc/profile, /etc/bash.bashrc, ou /etc/environment.

      Conclusion

      Les variables d'environnement et de shell sont toujours présentes dans votre session shell et peuvent s'avérer très utiles. Il s'agit d'un moyen intéressant pour un processus parent de paramétrer les détails de configuration de ses processus enfant et de configurer des options en-dehors des fichiers.

      Ce qui peut être très avantageux dans des situations spécifiques. Par exemple, certains mécanismes de déploiement dépendent des variables d'environnement pour configurer les données d'authentification. Ceci est utile, car vous n'avez pas besoin de la conserver dans des fichiers qui pourraient être vus par des tiers.

      Il existe de nombreux autres scénarios, plus banals, mais plus courants, dans lesquels vous devrez lire ou modifier l'environnement de votre système. Avec ces outils et ces techniques, vous disposez d'une bonne base pour apporter ces modifications et les utiliser correctement.



      Source link

      How To Improve Flexibility Using Terraform Variables, Dependencies, and Conditionals


      Introduction

      Hashicorp Configuration Language (HCL), which Terraform uses, provides many useful structures and capabilities that are present in other programming languages. Using loops in your infrastructure code can greatly reduce code duplication and increase readability, allowing for easier future refactoring and greater flexibility. HCL also provides a few common data structures, such as lists and maps (also called arrays and dictionaries respectively in other languages), as well as conditionals for execution path branching.

      Unique to Terraform is the ability to manually specify the resources one depends on. While the execution graph it builds when running your code already contains the detected links (which are correct in most scenarios), you may find yourself in need of forcing a dependency relationship that Terraform was unable to detect.

      In this article, we’ll review the data structures HCL provides, its looping features for resources (the count key, for_each, and for), and writing conditionals to handle known and unknown values, as well as explicitly specifying dependency relationships between resources.

      Prerequisites

      • A DigitalOcean account. If you do not have one, sign up for a new account.

      • A DigitalOcean Personal Access Token, which you can create via the DigitalOcean control panel. Instructions to do that can be found in this link: How to Generate a Personal Access Token.

      • Terraform installed on your local machine and a project set up with the DigitalOcean provider. Complete Step 1 and Step 2 of the How To Use Terraform with DigitalOcean tutorial, and be sure to name the project folder terraform-flexibility, instead of loadbalance. During Step 2, you do not need to include the pvt_key variable and the SSH key resource.

      • A fully registered domain name added to your DigitalOcean account. For instructions on how to do that, visit the official docs.

      Note: This tutorial has specifically been tested with Terraform 0.13.

      Data Types in HCL

      In this section, before you learn more about loops and other features of HCL that make your code more flexible, we’ll first go over the available data types and their uses.

      The Hashicorp Configuration Language supports primitive and complex data types. Primitive data types are strings, numbers, and boolean values, which are the basic types that can not be derived from others. Complex types, on the other hand, group multiple values into a single one. The two types of complex values are structural and collection types.

      Structural types allow values of different types to be grouped together. The main example is the resource definitions you use to specify what your infrastructure will look like. Compared to the structural types, collection types also group values, but only ones of the same type. The three collection types available in HCL that we are interested in are lists, maps, and sets.

      Lists

      Lists are similar to arrays in other programming languages. They contain a known number of elements of the same type, which can be accessed using the array notation ([]) by their whole-number index, starting from 0. Here is an example of a list variable declaration holding names of Droplets you’ll deploy in the next steps:

      variable "droplet_names" {
        type    = list(string)
        default = ["first", "second", "third"]
      }
      

      For the type, you explicitly specify that it’s a list whose element type is string, and then provide its default value. Values enumerated in brackets signify a list in HCL.

      Maps

      Maps are collections of key-value pairs, where each value is accessed using its key of type string. There are two ways of specifying maps inside curly brackets: by using colons (:) or equal signs (=) for specifying values. In both situations, the value must be enclosed with quotes. When using colons, the key must too be enclosed.

      The following map definition containing Droplet names for different environments is written using the equal sign:

      variable "droplet_env_names" {
        type = map(string)
      
        default = {
          development = "dev-droplet"
          staging = "staging-droplet"
          production = "prod-droplet"
        }
      }
      

      If the key starts with a number, you must use the colon syntax:

      variable "droplet_env_names" {
        type = map(string)
      
        default = {
          "1-development": "dev-droplet"
          "2-staging": "staging-droplet"
          "3-production": "prod-droplet"
        }
      }
      

      Sets

      Sets do not support element ordering, meaning that traversing sets is not guaranteed to yield the same order each time and that their elements can not be accessed in a targeted way. They contain unique elements repeated exactly once, and specifying the same element multiple times will result in them being coalesced with only one instance being present in the set.

      Declaring a set is similar to declaring a list, the only difference being the type of the variable:

      variable "droplet_names" {
        type    = set(string)
        default = ["first", "second", "third", "fourth"]
      }
      

      Now that you’ve learned about the types of data structures HCL offers and reviewed the syntax of lists, maps, and sets, which we’ll use throughout this tutorial, you’ll move on to trying some flexible ways of deploying multiple instances of the same resource in Terraform.

      Setting the Number of Resources Using the count Key

      In this section, you’ll create multiple instances of the same resource using the count key. The count key is a parameter available on all resources that specifies how many instances of it to create.

      You’ll see how it works by writing a Droplet resource, which you’ll store in a file named droplets.tf, in the project directory you created as part of the prerequisites. Create and open it for editing by running:

      Add the following lines:

      terraform-flexibility/droplets.tf

      resource "digitalocean_droplet" "test_droplet" {
        count  = 3
        image  = "ubuntu-18-04-x64"
        name   = "web"
        region = "fra1"
        size   = "s-1vcpu-1gb"
      }
      

      This code defines a Droplet resource called test_droplet, running Ubuntu 18.04 with 1GB RAM.

      Note that the value of count is set to 3, which means that Terraform will attempt to create three instances of the same resource. When you are done, save and close the file.

      You can plan the project to see what actions Terraform would take by running:

      • terraform plan -var "do_token=${DO_PAT}"

      The output will be similar to this:

      Output

      ... An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # digitalocean_droplet.test_droplet[0] will be created + resource "digitalocean_droplet" "test_droplet" { ... name = "web" ... } # digitalocean_droplet.test_droplet[1] will be created + resource "digitalocean_droplet" "test_droplet" { ... name = "web" ... } # digitalocean_droplet.test_droplet[2] will be created + resource "digitalocean_droplet" "test_droplet" { ... name = "web" ... } Plan: 3 to add, 0 to change, 0 to destroy. ...

      The output details that Terraform would create three instances of test_droplet, all with the same name web. While possible, it is not preferred, so let’s modify the Droplet definition to make the name of each instance different. Open droplets.tf for editing:

      Modify the highlighted line:

      terraform-flexibility/droplets.tf

      resource "digitalocean_droplet" "test_droplet" {
        count  = 3
        image  = "ubuntu-18-04-x64"
        name   = "web.${count.index}"
        region = "fra1"
        size   = "s-1vcpu-1gb"
      }
      

      Save and close the file.

      The count object provides the index parameter, which contains the index of the current iteration, starting from 0. The current index is substituted into the name of the Droplet using string interpolation, which allows you to dynamically build a string by substituting variables. You can plan the project again to see the changes:

      • terraform plan -var "do_token=${DO_PAT}"

      The output will be similar to this:

      Output

      ... An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # digitalocean_droplet.test_droplet[0] will be created + resource "digitalocean_droplet" "test_droplet" { ... name = "web.0" ... } # digitalocean_droplet.test_droplet[1] will be created + resource "digitalocean_droplet" "test_droplet" { ... name = "web.1" ... } # digitalocean_droplet.test_droplet[2] will be created + resource "digitalocean_droplet" "test_droplet" { ... name = "web.2" ... } Plan: 3 to add, 0 to change, 0 to destroy. ...

      This time, the three instances of test_droplet will have their index in their names, making them easier to track.

      You now know how to create multiple instances of a resource using the count key, as well as fetch and use the index of an instance during provisioning. Next, you’ll learn how to fetch the Droplet’s name from a list.

      Getting Droplet Names From a List

      In situations when multiple instances of the same resource need to have custom names, you can dynamically retrieve them from a list variable you define. During the rest of the tutorial, you’ll see several ways of automating Droplet deployment from a list of names, promoting flexibility and ease of use.

      You’ll first need to define a list containing the Droplet names. Create a file called variables.tf and open it for editing:

      Add the following lines:

      terraform-flexibility/variables.tf

      variable "droplet_names" {
        type    = list(string)
        default = ["first", "second", "third", "fourth"]
      }
      

      Save and close the file. This code defines a list called droplet_names, containing the strings first, second, third, and fourth.

      Open droplets.tf for editing:

      Modify the highlighted lines:

      terraform-flexibility/droplets.tf

      resource "digitalocean_droplet" "test_droplet" {
        count  = length(var.droplet_names)
        image  = "ubuntu-18-04-x64"
        name   =  var.droplet_names[count.index]
        region = "fra1"
        size   = "s-1vcpu-1gb"
      }
      

      To improve flexibility, instead of manually specifying a constant number of elements, you pass in the length of the droplet_names list to the count parameter, which will always return the number of elements in the list. For the name, you fetch the element of the list positioned at count.index, using the array bracket notation. Save and close the file when you’re done.

      Try planning the project again. You’ll receive output similar to this:

      Output

      ... An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # digitalocean_droplet.test_droplet[0] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "first" ... } # digitalocean_droplet.test_droplet[1] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "second" ... } # digitalocean_droplet.test_droplet[2] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "third" ... } # digitalocean_droplet.test_droplet[3] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "fourth" ... Plan: 4 to add, 0 to change, 0 to destroy. ...

      As a result of modifications, four Droplets would be deployed, successively named after the elements of the droplet_names list.

      You’ve learned about count, its features and syntax, and using it together with a list to modify the resource instances. You’ll now see its disadvantages, and how to overcome them.

      Understanding the Disadvantages of count

      Now that you know how count is used, you’ll see its disadvantages when modifying the list it’s used with.

      Let’s try deploying the Droplets to the cloud:

      • terraform apply -var "do_token=${DO_PAT}"

      Enter yes when prompted. The end of your output will be similar to this:

      Output

      Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

      Now let’s create one more Droplet instance by enlarging the droplet_names list. Open variables.tf for editing:

      Add a new element to the beginning of the list:

      terraform-flexibility/variables.tf

      variable "droplet_names" {
        type    = list(string)
        default = ["zero", "first", "second", "third", "fourth"]
      }
      

      When you’re done, save and close the file.

      Plan the project:

      • terraform plan -var "do_token=${DO_PAT}"

      You’ll receive output like this:

      Output

      ... An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create ~ update in-place Terraform will perform the following actions: # digitalocean_droplet.test_droplet[0] will be updated in-place ~ resource "digitalocean_droplet" "test_droplet" { ... ~ name = "first" -> "zero" ... } # digitalocean_droplet.test_droplet[1] will be updated in-place ~ resource "digitalocean_droplet" "test_droplet" { ... ~ name = "second" -> "first" ... } # digitalocean_droplet.test_droplet[2] will be updated in-place ~ resource "digitalocean_droplet" "test_droplet" { ... ~ name = "third" -> "second" ... } # digitalocean_droplet.test_droplet[3] will be updated in-place ~ resource "digitalocean_droplet" "test_droplet" { ... ~ name = "fourth" -> "third" ... } # digitalocean_droplet.test_droplet[4] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "fourth" ... } Plan: 1 to add, 4 to change, 0 to destroy. ...

      The output shows that Terraform would rename the first four Droplets and create a fifth one called fourth, because it considers the instances as an ordered list and identifies the elements (Droplets) by their index number in the list. This is how Terraform initially considers the four Droplets:

      Index Number 0 1 2 3
      Droplet Name first second third fourth

      When the a new Droplet zero is added to the beginning, its internal list representation looks like this:

      Index Number 0 1 2 3 4
      Droplet Name zero first second third fourth

      The four initial Droplets are now shifted one place to the right. Terraform then compares the two states represented in tables: at position 0, the Droplet was called first, and because it’s different in the second table, it plans an update action. This continues until position 4, which does not have a comparable element in the first table, and instead a Droplet provisioning action is planned.

      This means that adding a new element to the list anywhere but to the very end would result in resources being modified when they do not need to be. Similar update actions would be planned if an element of the droplet_names list was removed.

      Incomplete resource tracking is the main downfall of using count for deploying a dynamic number of differing instances of the same resource. For a constant number of constant instances, count is a simple solution that works well. In situations like this, though, when some attributes are being pulled in from a variable, the for_each loop, which you’ll learn about later in this tutorial, is a much better choice.

      Referencing the Current Resource (self)

      Another downside of count is that referencing an arbitrary instance of a resource by its index is not possible in some cases.

      The main example is destroy-time provisioners, which run when the resource is planned to be destroyed. The reason is that the requested instance may not exist (it’s already destroyed) or would create a mutual dependency cycle. In such situations, instead of referring to the object through the list of instances, you can access only the current resource through the self keyword.

      To demonstrate its usage, you’ll now add a destroy-time local provisioner to the test_droplet definition, which will show a message when run. Open droplets.tf for editing:

      Add the following highlighted lines:

      terraform-flexibility/droplets.tf

      resource "digitalocean_droplet" "test_droplet" {
        count  = length(var.droplet_names)
        image  = "ubuntu-18-04-x64"
        name   =  var.droplet_names[count.index]
        region = "fra1"
        size   = "s-1vcpu-1gb"
      
        provisioner "local-exec" {
          when    = destroy
          command = "echo 'Droplet ${self.name} is being destroyed!'"
        }
      }
      

      Save and close the file.

      The local-exec provisioner runs a command on the local machine Terraform is running on. Because the when parameter is set to destroy, it will run only when the resource is going to be destroyed. The command it runs echoes a string to stdout, which substitutes the name of the current resource using self.name.

      Because you’ll be creating the Droplets in a different way in the next section, destroy the currently deployed ones by running the following command:

      • terraform destroy -var "do_token=${DO_PAT}"

      Enter yes when prompted. You’ll receive the local-exec provisioner being run four times:

      Output

      ... digitalocean_droplet.test_droplet["first"] (local-exec): Executing: ["/bin/sh" "-c" "echo 'Droplet first is being destroyed!'"] digitalocean_droplet.test_droplet["second"] (local-exec): Executing: ["/bin/sh" "-c" "echo 'Droplet second is being destroyed!'"] digitalocean_droplet.test_droplet["second"] (local-exec): Droplet second is being destroyed! digitalocean_droplet.test_droplet["third"] (local-exec): Executing: ["/bin/sh" "-c" "echo 'Droplet third is being destroyed!'"] digitalocean_droplet.test_droplet["third"] (local-exec): Droplet third is being destroyed! digitalocean_droplet.test_droplet["fourth"] (local-exec): Executing: ["/bin/sh" "-c" "echo 'Droplet fourth is being destroyed!'"] digitalocean_droplet.test_droplet["fourth"] (local-exec): Droplet fourth is being destroyed! digitalocean_droplet.test_droplet["first"] (local-exec): Droplet first is being destroyed! ...

      In this step, you learned the disadvantages of count. You’ll now learn about the for_each loop construct, which overcomes them and works on a wider array of variable types.

      Looping Using for_each

      In this section, you’ll consider the for_each loop, its syntax, and how it helps flexibility when defining resources with multiple instances.

      for_each is a parameter available on each resource, but unlike count, which requires a number of instances to create, for_each accepts a map or a set. Each element of the provided collection is traversed once and an instance is created for it. for_each makes the key and value available under the each keyword as attributes (the pair’s key and value as each.key and each.value, respectively). When a set is provided, the key and value will be the same.

      Because it provides the current element in the each object, you won’t have to manually access the desired element as you did with lists. In case of sets, that’s not even possible, as it has no observable ordering internally. Lists can also be passed in, but they must first be converted into a set using the toset function.

      The main advantage of using for_each, aside from being able to enumerate all three collection data types, is that only the actually affected elements will be modified, created, or deleted. If you change the order of the elements in the input, no actions will be planned, and if you add, remove, or modify an element from the input, appropriate actions will be planned only for that element.

      Let’s convert the Droplet resource from count to for_each and see how it works in practice. Open droplets.tf for editing by running:

      Modify the highlighted lines:

      terraform-flexibility/droplets.tf

      resource "digitalocean_droplet" "test_droplet" {
        for_each = toset(var.droplet_names)
        image    = "ubuntu-18-04-x64"
        name     = each.value
        region   = "fra1"
        size     = "s-1vcpu-1gb"
      }
      

      You can remove the local-exec provisioner. When you’re done, save and close the file.

      The first line replaces count and invokes for_each, passing in the droplet_names list in the form of a set using the toset function, which automatically converts the given input. For the Droplet name, you specify each.value, which holds the value of the current element from the set of Droplet names.

      Plan the project by running:

      • terraform plan -var "do_token=${DO_PAT}"

      The output will detail steps Terraform would take:

      Output

      ... An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # digitalocean_droplet.test_droplet["first"] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "first" ... } # digitalocean_droplet.test_droplet["fourth"] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "fourth" ... } # digitalocean_droplet.test_droplet["second"] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "second" ... } # digitalocean_droplet.test_droplet["third"] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "third" ... } # digitalocean_droplet.test_droplet["zero"] will be created + resource "digitalocean_droplet" "test_droplet" { ... + name = "zero" ... } Plan: 5 to add, 0 to change, 0 to destroy. ...

      Unlike when using count, Terraform now considers each instance individually, and not as elements of an ordered list. Every instance is linked to an element of the given set, as signified by the shown string element in the brackets next to each resource that will be created.

      Apply the plan to the cloud by running:

      • terraform apply -var "do_token=${DO_PAT}"

      Enter yes when prompted. When it finishes, you’ll remove one element from the droplet_names list to demonstrate that other instances won’t be affected. Open variables.tf for editing:

      Modify the list to look like this:

      terraform-flexibility/variables.tf

      variable "droplet_names" {
        type    = list(string)
        default = ["first", "second", "third", "fourth"]
      }
      

      Save and close the file.

      Plan the project again, and you’ll receive the following output:

      Output

      ... An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: - destroy Terraform will perform the following actions: # digitalocean_droplet.test_droplet["zero"] will be destroyed - resource "digitalocean_droplet" "test_droplet" { ... - name = "zero" -> null ... } Plan: 0 to add, 0 to change, 1 to destroy. ...

      This time, Terraform would destroy only the removed instance (zero), and would not touch any of the other instances, which is the correct behavior.

      In this step, you’ve learned about for_each, how to use it, and its advantages over count. Next, you’ll learn about the for loop, its syntax and usage, and when it can be used to automate certain tasks.

      Looping Using for

      The for loop works on collections, and creates a new collection by applying a transformation to each element of the input. The exact type of the output will depend on whether the loop is surrounded by brackets ([]) or braces ({}), which give a list or a map, respectively. As such, it is suitable for querying resources and forming structured outputs for later processing.

      The general syntax of the for loop is:

      for element in collection:
      transform(element)
      if condition
      

      Similarly to other programming languages, you first name the traversal variable (element) and specify the collection to enumerate. The body of the loop is the transformational step, and the optional if clause can be used for filtering the input collection.

      You’ll now work through a few examples using outputs. You’ll store them in a file named outputs.tf. Create it for editing by running the following command:

      Add the following lines to output pairs of deployed Droplet names and their IP addresses:

      terraform-flexibility/outputs.tf

      output "ip_addresses" {
        value = {
          for instance in digitalocean_droplet.test_droplet:
          instance.name => instance.ipv4_address
        }
      }
      

      This code specifies an output called ip_addresses, and specifies a for loop that iterates over the instances of the test_droplet resource you’ve been customizing in the previous steps. Because the loop is surrounded by curly brackets, its output will be a map. The transformational step for maps is similar to lambda functions in other programming languages, and here it creates a key-value pair by combining the instance name as the key with its private IP as its value.

      Save and close the file, then refresh Terraform state to account for the new output by running:

      • terraform refresh -var "do_token=${DO_PAT}"

      The Terraform refresh command updates the local state with the actual infrastructure state in the cloud.

      Then, check the contents of the outputs:

      Output

      ip_addresses = { "first" = "ip_address" "fourth" = "ip_address" "second" = "ip_address" "third" = "ip_address" }

      Terraform has shown the contents of the ip_addresses output, which is a map constructed by the for loop. (The order of the entries may be different for you.) The loop will work seamlessly for every number of entries—meaning that you can add a new element to the droplet_names list and the new Droplet, which would be created without any further manual input, would also show up in this output automatically.

      By surrounding the for loop in square brackets, you can make the output a list. For example, you could output only Droplet IP addresses, which is useful for external software that may be parsing the data. The code would look like this:

      terraform-flexibility/outputs.tf

      output "ip_addresses" {
        value = [
          for instance in digitalocean_droplet.test_droplet:
          instance.ipv4_address
        ]
      }
      

      Here, the transformational step simply selects the IP address attribute. It would give the following output:

      Output

      ip_addresses = [ "ip_address", "ip_address", "ip_address", "ip_address", ]

      As was noted before, you can also filter the input collection using the if clause. Here is how you would write the loop if you’d filter it by the fra1 region:

      terraform-flexibility/outputs.tf

      output "ip_addresses" {
        value = [
          for instance in digitalocean_droplet.test_droplet:
          instance.ipv4_address
          if instance.region == "fra1"
        ]
      }
      

      In HCL, the == operator checks the equality of the values of the two sides—here it checks if instance.region is equal to fra1. If it is, the check passes and the instance is transformed and added to the output, otherwise it is skipped. The output of this code would be the same as the prior example, because all Droplet instances are in the fra1 region, according to the test_droplet resource definition. The if conditional is also useful when you want to filter the input collection for other values in your project, like the Droplet size or distribution.

      Because you’ll be creating resources differently in the next section, destroy the currently deployed ones by running the following command:

      • terraform destroy -var "do_token=${DO_PAT}"

      Enter yes when prompted to finish the process.

      We’ve gone over the for loop, its syntax, and examples of usage in outputs. You’ll now learn about conditionals and how they can be used together with count.

      Directives and Conditionals

      In one of the previous sections, you’ve seen the count key and how it works. You’ll now learn about ternary conditional operators, which you can use elsewhere in your Terraform code, and how they can be used with count.

      The syntax of the ternary operator is:

      condition ? value_if_true : value_if_false
      

      condition is an expression that computes to a boolean (true or false). If the condition is true, then the expression evaluates to value_if_true. On the other hand, if the condition is false, the result will be value_if_false.

      The main use of ternary operators is to enable or disable single resource creation according to the contents of a variable. This can be achieved by passing in the result of the comparison (either 1 or 0) to the count key on the desired resource.

      Let’s add a variable called create_droplet, which will control if a Droplet will be created. First, open variables.tf for editing:

      Add the highlighted lines:

      terraform-flexibility/variables.tf

      variable "droplet_names" {
        type    = list(string)
        default = ["first", "second", "third", "fourth"]
      }
      
      variable "create_droplet" {
        type = bool
        default = true
      }
      

      This code defines the create_droplet variable of type bool. Save and close the file.

      Then, to modify the Droplet declaration, open droplets.tf for editing by running:

      Modify your file like the following:

      terraform-flexibility/droplets.tf

      resource "digitalocean_droplet" "test_droplet" {
        count  = var.create_droplet ? 1 : 0
        image  = "ubuntu-18-04-x64"
        name   =  "test_droplet"
        region = "fra1"
        size   = "s-1vcpu-1gb"
      }
      

      For count, you use a ternary operator to return either 1 if the create_droplet variable is true, and 0 if false, which will result in no Droplets being provisioned. Save and close the file when you’re done.

      Plan the project execution plan with the variable set to false by running:

      • terraform plan -var "do_token=${DO_PAT}" -var "create_droplet=false"

      You’ll receive the following output:

      Output

      Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. ------------------------------------------------------------------------ No changes. Infrastructure is up-to-date. This means that Terraform did not detect any differences between your configuration and real physical resources that exist. As a result, no actions need to be performed.

      Because create_droplet was passed in the value of false, the count of instances is 0, and no Droplets will be created.

      You’ve reviewed how to use the ternary conditional operator together with the count key to enable a higher level of flexibility in choosing whether to deploy desired resources. Next you’ll learn about explicitly setting resource dependencies for your resources.

      Explicitly Setting Resource Dependencies

      While creating the execution plan for your project, Terraform detects dependency chains between resources and implicitly orders them so that they will be built in the appropriate order. In the majority of cases, it is able to detect relationships by scanning all expressions in resources and building a graph.

      However, when one resource requires access control settings to already be deployed at the cloud provider, in order to be provisioned, there is no clear sign to Terraform that they are related. In turn, Terraform will not know they are dependent on each other behaviorally. In such cases, the dependency must be manually specified using the depends_on argument.

      The depends_on key is available on each resource and used to specify to which resources one has hidden dependency links. Hidden dependency relationships form when a resource depends on another one’s behavior, without using any of its data in its declaration, which would prompt Terraform to connect them one way.

      Here is an example of how depends_on is specified in code:

      resource "digitalocean_droplet" "droplet" {
        image  = "ubuntu-18-04-x64"
        name   = "web"
        region = "fra1"
        size   = "s-1vcpu-1gb"
      
        depends_on = [
          # Resources...
        ]
      }
      

      It accepts a list of references to other resources, and it does not accept arbitrary expressions.

      depends_on should be used sparingly, and only when all other options are exhausted. Its use signifies that what you are trying to declare is stepping outside the boundaries of Terraform’s automated dependency detection system; it may signify that the resource is explicitly depending on more resources than it needs to.

      You’ve now learned about explicitly setting additional dependencies for a resource using the depends_on key, and when it should be used.

      Conclusion

      In this article, we’ve gone over the features of HCL that improve flexibility and scalability of your code, such as count for specifying the number of resource instances to deploy and for_each as an advanced way of looping over collection data types and customizing instances. When used correctly, they greatly reduce code duplication and operational overhead of managing the deployed infrastructure.

      You’ve also learned about conditionals and ternary operators, and how they can be utilized to control if a resource will get deployed. While Terraform’s automated dependency analysis system is quite capable, there may be cases where you need to manually specify resource dependencies using the depends_on key.

      To learn more about Terraform, check out our How To Manage Infrastructure with Terraform series.



      Source link