One place for hosting & domains

      Configuration

      How To Change Redis’s Configuration from the Command Line


      Introduction

      Redis is an open-source, in-memory key-value data store. Redis has several commands that allow you to make changes to the Redis server’s configuration settings on the fly. This tutorial will go over some of these commands, and also explain how to make these configuration changes permanent.

      How To Use This Guide
      This guide is written as a cheat sheet with self-contained examples. We encourage you to jump to any section that is relevant to the task you’re trying to complete.

      The commands shown in this guide were tested on an Ubuntu 18.04 server running Redis version 4.0.9. To set up a similar environment, you can follow Step 1 of our guide on How To Install and Secure Redis on Ubuntu 18.04. We will demonstrate how these commands behave by running them with redis-cli, the Redis command line interface. Note that if you’re using a different Redis interface — Redli, for example — the exact output of certain commands may differ.

      Be aware that managed Redis databases typically do not allow users to alter the configuration file. If you’re working with a Managed Database from DigitalOcean, the commands outlined in this guide will result in errors.

      Changing Redis’s Configuration

      The commands outlined in this section will only alter the Redis server’s behavior for the duration of the current session, or until you run config rewrite which will make them permanent. You can alter the Redis configuration file directly by opening and editing it with your preferred text editor. For example, you can use nano to do so:

      • sudo nano /etc/redis/redis.conf

      Warning: The config set command is considered dangerous. By changing your Redis configuration file, it’s possible that you will cause your Redis server to behave in unexpected or undesirable ways. We recommend that you only run the config set command if you are testing out its behavior or you’re absolutely certain that you want to make changes to your Redis configuration.

      It may be in your interest to rename this command to something with a lower likelihood of being run accidentally.

      config set allows you to reconfigure Redis at runtime without having to restart the service. It uses the following syntax:

      • config set parameter value

      For example, if you wanted to change the name of the database dump file Redis will produce after you run a save command, you might run a command like the following:

      • config set "dbfilename" "new_file.rdb"

      If the configuration change is valid, the command will return OK. Otherwise it will return an error.

      Note: Not every parameter in the redis.conf file can be changed with a config set operation. For example, you cannot change the authentication password defined by the requirepass parameter.

      Making Configuration Changes Permanent

      config set does not permanently alter the Redis instance’s configuration file; it only changes Redis’s behavior at runtime. To edit redis.conf after running a config-set command and make the current session’s configuration permanent, run config rewrite:

      This command does its best to preserve the comments and overall structure of the original redis.conf file, with only minimal changes to match the settings currently used by the server.

      Like config set, if the rewrite is successful config rewrite will return OK.

      Checking Redis’s Configuration

      To read the current configuration parameters of a Redis server, run the config get command. config get takes a single argument, which can be either an exact match of a parameter used in redis.conf or a glob pattern. For example:

      Depending on your Redis configuration, this command might return:

      Output

      1) "repl-ping-slave-period" 2) "10" 3) "repl-timeout" 4) "60" 5) "repl-backlog-size" 6) "1048576" 7) "repl-backlog-ttl" 8) "3600" 9) "repl-diskless-sync-delay" 10) "5" 11) "repl-disable-tcp-nodelay" 12) "no" 13) "repl-diskless-sync" 14) "no"

      You can also return all of the configuration parameters supported by config set by running config get *.

      Conclusion

      This guide details the redis-cli commands used to make changes to a Redis server’s configuration file on the fly. If there are other related commands, arguments, or procedures you’d like to see outlined in this guide, please ask or make suggestions in the comments below.

      For more information on Redis commands, see our tutorial series on How to Manage a Redis Database.



      Source link

      Configuration initiale de serveur avec Ubuntu 18.04


      Introduction

      Lorsque vous installez un nouveau serveur Ubuntu 18.04, il y a quelques étapes de configuration que vous devriez effectuer au sein de votre paramétrage initial. Cela renforcera la sécurité et l’ergonomie de votre serveur et vous procurera une base solide pour vos actions futures.

      Note: Le guide ci-dessous montre comment compléter manuellement les étapes que nous recommandons de suivre pour les nouveaux serveurs Ubuntu 18.04. Suivre cette procédure manuellement peut être pratique afin d’apprendre des techniques d’administration de système de base et pour bien comprendre les actions entreprises sur votre serveur. De manière alternative, si vous désirez être en mesure de débuter plus rapidement, vous pouvez suivre ce guide [run our initial server setup script] (en Anglais) (https://www.digitalocean.com/community/tutorials/automating-initial-server-setup-with-ubuntu-18-04) qui automatise ces étapes.

      Étape 1 — Se connecter en tant que Root

      Afin de vous connecter à votre serveur, vous aurez besoin de connaître votre « adresse IP publique ». Vous aurez également besoin du mot de passe, ou si vous avez installé une clé d’identification SSH, la clé privée de votre compte d’utilisateur root. Si vous ne vous êtes pas encore connecté à votre serveur, vous devriez penser à suivre notre guide [how to connect to your Droplet with SSH] (en anglais) (https://www.digitalocean.com/community/tutorials/how-to-connect-to-your-droplet-with-ssh), qui couvre ce processus en détail.

      Si vous n’êtes pas encore connecté à votre serveur, vous pouvez aller de l’avant et vous connecter en tant qu’utilisateur root à l’aide de la commande suivante : (substituer la partie surlignée de la commande avec l’adresse IP publique de votre serveur)

      Acceptez l’avertissement concernant l’authenticité de l’hôte si elle apparaît. Si vous utilisez l’authentification avec mot de passe, entrez votre mot de passe root afin de vous connecter. Si vous utilisez une clé SSH qui est protégée à l’aide d’une phrase de sécurité, il est possible que vous soyez invité à entrer la phrase de sécurité la première fois que vous utilisez la clé chaque session. S’il s’agit de la première fois que vous vous connectez sur le serveur à l’aide d’un mot de passe, il est possible que vous soyez également invité à changer votre mot de passe root.

      À propos de Root

      L’utilisateur root est l’utilisateur administratif dans un environnement Linux qui bénéficie d’une large gamme de privilèges. Dû aux privilèges accrus du compte root, vous êtes déconseillé de l’utiliser sur une base régulière. Cela est dû au fait qu’une partie du pouvoir propre au compte root est sa capacité à faire des modifications très destructives, même par accident.

      La prochaine étape consiste à configurer un compte d’utilisateur alternatif avec un champ d’influence limité pour le travail de tous les jours. Nous vous enseignerons comment accéder à des privilèges accrus pour les moments où vous en aurez besoin.

      Étape 2 — Créer un nouvel utilisateur

      Une fois connectés en tant que root, nous sommes prêts à ajouter le nouveau compte d’utilisateur que nous utiliserons toujours dorénavant pour nous connecter.

      Cet exemple créer un utilisateur nommé sammy, mais vous devriez le replacer par un nom d’utilisateur que vous aimez :

      On vous posera quelques questions, commençant par le mot de passe de votre compte.

      Entrez un mot de passe robuste et, si vous le désirez, remplissez quelconque information supplémentaire. Ceci n’est pas obligatoire et vous pouvez simplement pesez ENTER au sein de n’importe quel champ que vous désirez sauter.

      Étape 3 — Octroyer les privilèges d’administration

      Présentement, nous avons un nouveau compte d’utilisateur avec des privilèges de compte régulier. Cependant, il se peut que nous ayons besoin d’effectuer des tâches administratives de temps à autre.

      Afin d’éviter de devoir se déconnecter de notre utilisateur normal pour ensuite se reconnecter à notre compte root, nous pouvons régler ce qu’on appelle le "superuser" ou les privilèges root pour notre compte normal. Cela permettra à notre utilisateur normal d’exécuter des commandes avec des privilèges administratifs en inscrivant le mot sudo avant chaque commande.

      Afin d’ajouter ces privilèges à notre nouvel utilisateur, nous devons ajouter le nouvel utilisateur au groupe sudo. Par défaut, sur Ubuntu 18.04, les utilisateurs appartenant au groupe sudo sont autorisés à utiliser la commande sudo.

      En tant que root, effectuez cette commande afin d’ajouter votre nouvel utilisateur au groupe sudo (substituer le mot surligné avec votre nouvel utilisateur) :

      Maintenant, une fois connecté avec votre utilisateur régulier, vous pouvez tapez sudo avant chaque commande pour effectuer des actions avec des privilèges "superuser".

      Étape 4 —Régler un pare-feu de base

      Les serveurs Ubuntu 18.04 peuvent faire appel à un pare-feu UFW afin de s’assurer que seules les connexions à certains services soient autorisées. Nous pouvons régler un pare-feu de base très facilement en utilisant cette application.

      Note: Si vos serveurs fonctionnent avec DigitalOcean, vous pouvez de manière facultative utiliser [DigitalOcean Cloud Firewalls] (en Anglais) (https://www.digitalocean.com/community/tutorials/an-introduction-to-digitalocean-cloud-firewalls) au lieu du pare-feu UFW. Nous vous recommandons d’utiliser seulement un pare-feu à la fois afin d’éviter d’avoir des règles conflictuelles qui pourraient prendre du temps à déboguer.

      Différentes applications peuvent inscrire leurs profils avec UFW au moment de l’installation. Ces profils permettent à UFW de gérer ces applications selon leur nom. OpenSSH, le service nous permettant maintenant de nous connecter à notre serveur possède un profil inscrit avec UFW.

      Vous pouvez voir cela en tapant:

      Output

      Available applications: OpenSSH

      Nous devons s’assurer que le pare-feu permette les connexions SSH afin que nous puissions nous connecter la prochaine fois. Nous pouvons autoriser ces connexions en tapant :

      Ensuite, nous pouvons activer le pare-feu en tapant:

      Tapez "y" et pesez sur ENTER afin de procéder. Vous pouvez voir si les connexions SSH sont toujours autorisées en tapant :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)

      Alors que le pare-feu bloque présentement toutes les connexions mises à part celle SSH, si vous installez et configurez des services additionnels, vous devrez régler les paramètres du pare-feu afin de permettre un trafic entrant acceptable. Vous pouvez lire davantage sur les opérations courantes UFW [this guide] (en Anglais) (https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands).

      Étape 5 — Autoriser l’accès externe à votre utilisateur régulier

      Maintenant que nous possédons un utilisateur régulier pour une utilisation quotidienne, nous devons s’assurer que nous pouvons SSH directement au sein de notre compte.

      Note:Avant d’avoir pu vérifier que vous pouvez bien vous connecté et utilisé sudo avec votre nouvel utilisateur, nous vous recommandons de rester connecté en tant que root. De cette manière, si vous avez des problèmes, vous pourrez diagnostiquer le problème et le résoudre ainsi que faire les modifications nécessaires en tant que root. Si vous utilisez DigitalOcean Droplet et vous rencontrez des problèmes avec votre connexion SSH root, vous pouvez suivre ce guide [log into the Droplet using the DigitalOcean Console] (en Anglais) (https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-console-to-access-your-droplet).

      Le processus pour configurer l’accès SSH pour votre nouvel utilisateur dépendra si le compte root de votre serveur utilise un mot de passe ou des clés SSH pour l’authentification.

      Si le compte Root utilise l’authentification par mot de passe

      Si vous vous êtes connecté à votre compte root à l’aide d’un mot de passe, alors l’authentification par mot de passe est activée pour SSH. Vous pouvez SSH à votre nouveau compte d’utilisateur en ouvrant une nouvelle session terminale et utilisez SSH avec votre nouveau nom d’utilisateur :

      Après avoir entré votre mot de passe d’utilisateur régulier, vous serez connecté. Rappelez-vous, si vous avez besoin d’exécuter une commande avec des privilèges administratifs, tapez sudo avant comme ceci :

      Vous serez invité à entrer votre mot de passe régulier d’utilisateur lorsque vous utilisez sudo pour la première fois chaque session (et de manière périodique par la suite).

      Afin de renforcer la sécurité de votre serveur, nous suggérons fortement de mettre en place des clés SSH plutôt que d’utiliser l’authentification par mot de passe. Suivez notre guide sur [setting up SSH keys on Ubuntu 18.04] (en Anglais) (https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-1804) afin de savoir comment configurer une authentification par clé.

      Si le compte “Root” utilise l’authentification par clé SSH.

      Si vous vous êtes connecté à votre compte root en utilisant des clés SSH, alors l’authentification par mot de passe est désactivée pour SSH. Vous devrez ajouter une copie de votre clé locale publique à votre nouveau fichier d’utilisateur ~/.ssh/authorized_keys afin de vous connecter.

      Étant donné que votre clé publique figure déjà au sein du fichier ~/.ssh/authorized_keys de votre compte root sur le serveur, nous pouvons copier ce fichier et la structure de répertoires au sein de notre nouveau compte d’utilisateur dans notre session préexistante.

      La manière la plus simple de copier les fichiers avec les droits et permissions appropriés est par la commande rsync. Cela copiera le répertoire .ssh de l’utilisateur root, préserver les permissions et modifier les propriétaires de fichier, le tout au sein d’une seule commande. Assurez-vous de modifier les parties surlignées de la commande ci-dessous afin qu’elles concordent avec votre nom d’utilisateur régulier :

      Note: La commande rsync traite différemment les sources et destinations qui terminent avec une barre oblique que celles-ci terminant sans barre oblique. En utilisant la commande rsync ci-dessous, assurez-vous que la source du répertoire (~/.ssh) n’inclut pas de barre oblique (vérifiez pour vous assurer que vous n’utilisez pas ~/.ssh/).

      Si vous ajoutez une barre oblique par mégarde à la commande, rsync copiera le contenu du répertoire ~/.ssh du compte root au répertoire d’origine de l’utilisateur au lieu de copier la structure complète du répertoire ~/.ssh. Les fichiers se situeront à la mauvaise destination et SSH ne serait pas en mesure de les trouver et les utiliser.

      • rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy

      Maintenant, ouvrez une nouvelle session terminale et utilisez SSH avec votre nouveau nom d’utilisateur :

      Vous devriez être connecté avec votre nouveau compte d’utilisateur sans devoir utiliser de mot de passe. N’oubliez pas, si vous devez exécuter une commande avec des privilèges administratifs, tapez sudo avant comme ceci :

      Vous serez invité à entrer votre mot de passe régulier lorsque vous utilisez sudo pour la première fois à chaque session (et de manière périodique par la suite).

      Que pouvons-nous faire ensuite ?

      À ce stade, vous avez une base solide pour votre serveur. Vous pouvez à présent installer quelconque logiciel dont vous avez besoin sur votre serveur.



      Source link

      Introduction to HashiCorp Configuration Language (HCL)


      Updated by Linode Written by Linode

      HCL is a configuration language authored by HashiCorp. HCL is used with HashiCorp’s cloud infrastructure automation tools, like Terraform. The language was created with the goal of being both human and machine friendly. It is JSON compatible, which means it is interoperable with other systems outside of the Terraform product line.

      This guide provides an introduction to HCL syntax and some commonly used HCL terminology.

      HCL Syntax Overview

      HashiCorp’s configuration syntax is easy to read and write. It was created to have a more clearly visible and defined structure when compared with other well known configuration languages, like YAML.

      ~/terraform/main.tf
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      
      # Linode provider block. Installs Linode plugin.
      provider "linode" {
          token = "${var.token}"
      }
      
      variable "region" {
        description = "This is the location where the Linode instance is deployed."
      }
      
      /* A multi
         line comment. */
      resource "linode_instance" "example_linode" {
          image = "linode/ubuntu18.04"
          label = "example-linode"
          region = "${var.region}"
          type = "g6-standard-1"
          authorized_keys = [ "my-key" ]
          root_pass = "example-password"
      }
          

      Note

      Key Elements of HCL

      • HCL syntax is composed of stanzas or blocks that define a variety of configurations available to Terraform. Provider plugins expand on the available base Terraform configurations.

      • Stanzas or blocks are comprised of key = value pairs. Terraform accepts values of type string, number, boolean, map, and list.

      • Single line comments start with #, while multi-line comments use an opening /* and a closing */.

      • Interpolation syntax can be used to reference values stored outside of a configuration block, like in an input variable, or from a Terraform module’s output.

        An interpolated variable reference is constructed with the "${var.region}" syntax. This example references a variable named region, which is prefixed by var.. The opening ${ and closing } indicate the start of interpolation syntax.

      • You can include multi-line strings by using an opening <<EOF, followed by a closing EOF on its own line.

      • Strings are wrapped in double quotes.

      • Lists of primitive types (string, number, and boolean) are wrapped in square brackets: ["Andy", "Leslie", "Nate", "Angel", "Chris"].

      • Maps use curly braces {} and colons :, as follows: { "password" : "my_password", "db_name" : "wordpress" }.

      See Terraform’s Configuration Syntax documentation for more details.

      Providers

      In Terraform, a provider is used to interact with an Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) API, like the Linode APIv4. The provider determines which resources are exposed and available to create, read, update, and delete. A credentials set or token is usually required to interface with your service account. For example, the Linode Terraform provider requires your Linode API access token. A list of all official Terraform providers is available from HashiCorp.

      Configuring a Linode as your provider requires that you include a block which specifies Linode as the provider and sets your Linode API token in one of your .tf files:

      ~/terraform/terraform.tf
      1
      2
      3
      
      provider "linode" {
          token = "my-token"
      }

      Once your provider is declared, you can begin configuring resources available from the provider.

      Note

      Providers are packaged as plugins for Terraform. Whenever declaring a new provider in your Terraform configuration files, the terraform init command should be run. This command will complete several initialization steps that are necessary before you can apply your Terraform configuration, including downloading the plugins for any providers you’ve specified.

      Resources

      A Terraform resource is any component of your infrastructure that can be managed by your provider. Resources available with the Linode provider range from a Linode instance, to a block storage volume, to a DNS record. Terraform’s Linode Provider documentation contains a full listing of all supported resources.

      Resources are declared with a resource block in a .tf configuration file. This example block deploys a 2GB Linode instance located in the US East data center from an Ubuntu 18.04 image. Values are also provided for the Linode’s label, public SSH key, and root password:

      ~/terraform/main.tf
      1
      2
      3
      4
      5
      6
      7
      8
      
      resource "linode_instance" "WordPress" {
          image = "linode/ubuntu18.04"
          label = "WPServer"
          region = "us-east"
          type = "g6-standard-1"
          authorized_keys = [ "example-key" ]
          root_pass = "example-root-pass"
      }

      HCL-specific meta-parameters are available to all resources and are independent of the provider you use. Meta-parameters allow you to do things like customize the lifecycle behavior of the resource, define the number of resources to create, or protect certain resources from being destroyed. See Terraform’s Resource Configuration documentation for more information on meta-parameters.

      Modules

      A module is an encapsulated set of Terraform configurations used to organize the creation of resources in reusable configurations.

      The Terraform Module Registry is a repository of community modules that can help you get started creating resources for various providers. You can also create your own modules to better organize your Terraform configurations and make them available for reuse. Once you have created your modules, you can distribute them via a remote version control repository, like GitHub.

      Using Modules

      A module block instructs Terraform to create an instance of a module. This block instantiates any resources defined within that module.

      The only universally required configuration for all module blocks is the source parameter which indicates the location of the module’s source code. All other required configurations will vary from module to module. If you are using a local module you can use a relative path as the source value. The source path for a Terraform Module Registry module will be available on the module’s registry page.

      This example creates an instance of a module named linode-module-example and provides a relative path as the location of the module’s source code:

      ~/terraform/main.tf
      1
      2
      3
      
      module "linode-module-example" {
          source = "/modules/linode-module-example"
      }

      Authoring modules involves defining resource requirements and parameterizing configurations using input variables, variable files, and outputs. To learn how to write your own Terraform modules, see Create a Terraform Module.

      Input Variables

      You can define input variables to serve as Terraform configuration parameters. By convention, input variables are normally defined within a file named variables.tf. Terraform will load all files ending in .tf, so you can also define variables in files with other names.

      • Terraform accepts variables of type string, number, boolean, map, and list. If a variable type is not explicitly defined, Terraform will default to type = "string".

      • It is good practice to provide a meaningful description for all your input variables.

      • If a variable does not contain a default value, or if you would like to override a variable’s default value, you must provide a value as an environment variable or within a variable values file.

      Variable Declaration Example

      ~/terraform/variables.tf
      1
      2
      3
      4
      5
      6
      7
      8
      
      variable "token" {
        description = "This is your Linode APIv4 Token."
      }
      
      variable "region" {
          description: "This is the location where the Linode instance is deployed."
          default = "us-east"
      }

      Two input variables named token and region are defined, respectively. The region variable defines a default value. Both variables will default to type = "string", since a type is not explicitly declared.

      Supplying Variable Values

      Variable values can be specified in .tfvars files. These files use the same syntax as Terraform configuration files:

      ~/terraform/terraform.tfvars
      1
      2
      
      token = "my-token"
      region = "us-west"

      Terraform will automatically load values from filenames which match terraform.tfvars or *.auto.tfvars. If you store values in a file with another name, you need to specify that file with the -var-file option when running terraform apply. The -var-file option can be invoked multiple times:

      terraform apply 
      -var-file="variable-values-1.tfvars" 
      -var-file="variable-values-2.tfvars"
      

      Values can also be specified in environment variables when running terraform apply. The name of the variable should be prefixed with TF_VAR_:

      TF_VAR_token=my-token-value TF_VAR_region=us-west terraform apply
      

      Note

      Environment variables can only assign values to variables of type = "string"

      Referencing Variables

      You can call existing input variables within your configuration file using Terraform’s interpolation syntax. Observe the value of the region parameter:

      ~/terraform/main.tf
      1
      2
      3
      4
      5
      6
      7
      8
      
      resource "linode_instance" "WordPress" {
          image = "linode/ubuntu18.04"
          label = "WPServer"
          region = "${var.region}"
          type = "g6-standard-1"
          authorized_keys = [ "example-key" ]
          root_pass = "example-root-pass"
      }

      Note

      If a variable value is not provided in any of the ways discussed above, and the variable is called in a resource configuration, Terraform will prompt you for the value when you run terraform apply.

      For more information on variables, see Terraform’s Input Variables documentation.

      Interpolation

      HCL supports the interpolation of values. Interpolations are wrapped in an opening ${ and a closing }. Input variable names are prefixed with var.:

      ~/terraform/terraform.tf
      1
      2
      3
      
      provider "linode" {
          token = "${var.token}"
      }

      Interpolation syntax is powerful and includes the ability to reference attributes of other resources, call built-in functions, and use conditionals and templates.

      This resource’s configuration uses a conditional to provide a value for the tags parameter:

      ~/terraform/terraform.tf
      1
      2
      3
      
      resource "linode_instance" "web" {
          tags = ["${var.env == "production" ? var.prod_subnet : var.dev_subnet}"]
      }

      If the env variable has the value production, then the prod_subnet variable is used. If not, then the variable dev_subent is used.

      Functions

      Terraform has built-in computational functions that perform a variety of operations, including reading files, concatenating lists, encrypting or creating a checksum of an object, and searching and replacing.

      ~/terraform/terraform.tf
      1
      2
      3
      4
      
      resource "linode_sshkey" "main_key" {
          label = "foo"
          ssh_key = "${chomp(file("~/.ssh/id_rsa.pub"))}"
      }

      In this example, ssh_key = "${chomp(file("~/.ssh/id_rsa.pub"))}" uses Terraform’s built-in function file() to provide a local file path to the public SSH key’s location. The chomp() function removes trailing new lines from the SSH key. Observe that the nested functions are wrapped in opening ${ and closing } to indicate that the value should be interpolated.

      Note

      Running terraform console creates an environment where you can test interpolation functions. For example:

      terraform console
      
        
      > list("newark", "atlanta", "dallas")
      [
        "newark",
        "atlanta",
        "dallas",
      ]
      >
      
      

      Terraform’s official documentation includes a complete list of supported built-in functions.

      Templates

      Templates can be used to store large strings of data. The template provider exposes the data sources for other Terraform resources or outputs to consume. The data source can be a file or an inline template.

      The data source can use Terraform’s standard interpolation syntax for variables. The template is then rendered with variable values that you supply in the data block.

      This example template resource substitutes in the value from ${linode_instance.web.ip_address} anywhere ${web_ip} appears inside the template file ips.json:

      1
      2
      3
      4
      5
      6
      7
      
      data "template_file" "web" {
          template = "${file("${path.module}/ips.json")}"
      
          vars {
              web_ip = "${linode_instance.web.ip_address}"
          }
      }

      You could then define an output variable to view the rendered template when you later run terraform apply:

      1
      2
      3
      
      output "ip" {
        value = "${data.template_file.web.rendered}"
      }

      Terraform’s official documentation has a list of all available components of interpolation syntax.

      Next Steps

      Now that you are familiar with HCL, you can begin creating your own Linode instance with Terraform by following the Use Terraform to Provision Linode Environments guide.

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.



      Source link