Terraform - Revision history

Pchero: /* Resource behavior */

2020-06-26T08:44:53Z

Resource behavior

← Older revision		Revision as of 08:44, 26 June 2020
Line 48:		Line 48:

	When Terraform create a new infrastructure object represented by a resource block, the identifier for that real object is saved in Terraform's state, allowing it to be updated and destroyed in response to future changes. For resource blocks that already have an associated infrastructure object in the state, Terraform compares the actual configuration of the object with the arguments given in the configuration and, if necessary, updates the object to match the configuration.		When Terraform create a new infrastructure object represented by a resource block, the identifier for that real object is saved in Terraform's state, allowing it to be updated and destroyed in response to future changes. For resource blocks that already have an associated infrastructure object in the state, Terraform compares the actual configuration of the object with the arguments given in the configuration and, if necessary, updates the object to match the configuration.

			This general behavior applies for all resources, regardless of type. The details of what it means to create, update, or destroy a resource type, but this standard set of verbs is common across them all.

			The meta-arguments within resource blocks, documented in the sections below, allow some details of this standard resource behavior to be customized on a per-resource basis.

	* https://www.terraform.io/docs/configuration/resources.html#resource-behavior		* https://www.terraform.io/docs/configuration/resources.html#resource-behavior

	==== lifecycle ====		==== lifecycle ====

Pchero: /* Provider */

2020-06-25T11:54:14Z

Provider

@@ Line 39: / Line 39: @@
 === Syntax ===
 * https://www.terraform.io/docs/configuration-0-11/syntax.html
 === Provider ===

Pchero: /* Provider */

2020-06-24T11:32:41Z

Provider

@@ Line 47: / Line 47: @@
    region      = "us-central1"
+}
 </pre>

Pchero: /* Standard module structure */

2020-05-20T11:18:23Z

Standard module structure

@@ Line 76: / Line 76: @@
 * README
 : The root module and any nested modules should have README files. This file should be named README or README.md. The latter will be treated as markdown. There should be a description of the module and what it should be used for. If you want to include an example for how this module can be used in combination with other resources, put it in an example directory. Consider including a visual diagram depicting the infrastructure resources the module may create and their relationship.
 === See also ===

Pchero: /* Structure */

2020-05-20T11:16:57Z

Structure

← Older revision		Revision as of 11:16, 20 May 2020
Line 62:		Line 62:

	Modules can also call other modules using a module block, but the recommendation is keeping the module tree relatively flat and using module composition as an alternative to a deelpy-nested tree of modules, because this makes the individual modules easier to re-use in different combinations.		Modules can also call other modules using a module block, but the recommendation is keeping the module tree relatively flat and using module composition as an alternative to a deelpy-nested tree of modules, because this makes the individual modules easier to re-use in different combinations.

			=== When to write a module ===
			In principle any combination of resources and other constructs can be factored out into a module, but over-using modules can make your overall terraform configuration harder to understand and maintain.

			A good module should raise the level of abstraction by describing a new concept in your architecture that is constructed from resource types offered by providers.

			=== Standard module structure ===
			The standard module structure is a file and directory layout we recommend for reusable distributed in separate repositories. Terraform tooling is built to understand the standard module structure and use that structure to generate documentation, index modules for the module registry, and more.

			* Root module
			: This is the only required element for the standard module structure. Terraform files must exist in the root directory of the repository. This should be the primary entrypoint for the module and is expected to be opinionated.

			* README
			: The root module and any nested modules should have README files. This file should be named README or README.md. The latter will be treated as markdown. There should be a description of the module and what it should be used for. If you want to include an example for how this module can be used in combination with other resources, put it in an example directory. Consider including a visual diagram depicting the infrastructure resources the module may create and their relationship.

	=== See also ===		=== See also ===

Pchero: /* Strcuture */

2020-05-20T10:00:58Z

Strcuture

← Older revision		Revision as of 10:00, 20 May 2020
Line 54:		Line 54:
	The '.tf' files in your working directory when you run 'terraform plan' or 'terraform apply' together form the root module. That module may call other modules and connect them together by passing output values from one to input values of another.		The '.tf' files in your working directory when you run 'terraform plan' or 'terraform apply' together form the root module. That module may call other modules and connect them together by passing output values from one to input values of another.

	=== ~~Strcuture~~ ===		=== Structure ===
	* Input variables to accept values from the calling module.		* Input variables to accept values from the calling module.
	* Output variables to return results to the calling module, which it can then use to populate arguments elsewhere.		* Output variables to return results to the calling module, which it can then use to populate arguments elsewhere.

Pchero: /* Module */

2020-05-20T10:00:33Z

Module

← Older revision		Revision as of 10:00, 20 May 2020
Line 53:		Line 53:

	The '.tf' files in your working directory when you run 'terraform plan' or 'terraform apply' together form the root module. That module may call other modules and connect them together by passing output values from one to input values of another.		The '.tf' files in your working directory when you run 'terraform plan' or 'terraform apply' together form the root module. That module may call other modules and connect them together by passing output values from one to input values of another.

			=== Strcuture ===
			* Input variables to accept values from the calling module.
			* Output variables to return results to the calling module, which it can then use to populate arguments elsewhere.
			* Resources to define one or more infrastructure objects that the module will manage.

			To define a module, create a new directory for it and place one or more .tf files inside just as the user would do for a root module. Terraform can load modules either from local relative paths or from remote repositories; if a module will be re-used by lots of configurations you may wish to place it in its own version control repository.

			Modules can also call other modules using a module block, but the recommendation is keeping the module tree relatively flat and using module composition as an alternative to a deelpy-nested tree of modules, because this makes the individual modules easier to re-use in different combinations.

	=== See also ===		=== See also ===

Pchero at 15:32, 19 May 2020

2020-05-19T15:32:45Z

← Older revision		Revision as of 15:32, 19 May 2020
Line 49:		Line 49:
	</pre>		</pre>

	=== Module ===		== Module ==
	A module is a container for multiple resources that are used together. Modules can be used to create lightweight abstractions, so that you can describe your infrastructure in terms of its architecture, rather than directly in terms of physical objects.		A module is a container for multiple resources that are used together. Modules can be used to create lightweight abstractions, so that you can describe your infrastructure in terms of its architecture, rather than directly in terms of physical objects.

	The '.tf' files in your working directory when you run 'terraform plan' or 'terraform apply' together form the root module. That module may call other modules and connect them together by passing output values from one to input values of another.		The '.tf' files in your working directory when you run 'terraform plan' or 'terraform apply' together form the root module. That module may call other modules and connect them together by passing output values from one to input values of another.

			=== See also ===
			* https://www.terraform.io/docs/modules/index.html

	[[category:system]]		[[category:system]]

Pchero at 15:32, 19 May 2020

2020-05-19T15:32:09Z

← Older revision		Revision as of 15:32, 19 May 2020
Line 35:		Line 35:
	</pre>		</pre>

	== Syntax ==
			== Configurations ==
			=== Syntax ===
	* https://www.terraform.io/docs/configuration-0-11/syntax.html		* https://www.terraform.io/docs/configuration-0-11/syntax.html

	== Provider ==		=== Provider ===
	<pre>		<pre>
	provider "google" {		provider "google" {
Line 46:		Line 48:
	}		}
	</pre>		</pre>

			=== Module ===
			A module is a container for multiple resources that are used together. Modules can be used to create lightweight abstractions, so that you can describe your infrastructure in terms of its architecture, rather than directly in terms of physical objects.

			The '.tf' files in your working directory when you run 'terraform plan' or 'terraform apply' together form the root module. That module may call other modules and connect them together by passing output values from one to input values of another.

	[[category:system]]		[[category:system]]

Pchero at 08:21, 24 January 2020

2020-01-24T08:21:15Z

@@ Line 1: / Line 1: @@
 == Overview ==
 Terraform 내용 정리.
 == Syntax ==