<p>Terraform from high level is called IaC tool (Infrastructure as code) tool; So it comes in most handy when you use it in its primary function, <strong>providing infrastructure</strong>.</p>
<p>The part of configuration should be handled by <strong>configuration management</strong> tools; as you mentioned like ansible, chef, puppet ect..</p>
<p>By my experience, in one product, we are using terraform and ansible, hand to hand; it works perfectly fine, and not just it does the job, it is easy to read, understand and maintain/change/organize. Mixing IaC and Configuration management tools in general is so good to maintain your whole platform.</p>
<p>However, In some other product I worked on before, when they originally designed the product, they tried to use terraform as you say in every aspect, building and configuring, since you theoretically <strong>can execute whatever script with terraform plugins</strong> like null_resource; so it is doable, but on the contrary of native configuration management tools: it is hard to understand, maintain and change.</p>
<p>Of course all of the above depends on the complexity of each system and its design and components, but my advise, <strong>if you want configuration management, go for configuration management tools</strong>.</p>

CC BY-SA 4.0
2023-06-14T15:48:25.330Z
I don't really want to execute scripts as null resources. I want to have sql records as regular resources, which would be managed by terraform. I.e. you deploy service, and then you keep configuration record in configuration DB to be used by other services.
Shadow
CC BY-SA 4.0
2023-06-13T12:20:07.697Z
2023-06-13T12:20:07.697Z
Abraam Magued
<p>I have complex stack which consists of infrastructure, application and config parts, which are deployed to datacenters around the world. We have custom inhouse configuration system, based on database which is replicated elsewhere.</p>
<p>We have loads of configuration, which depends on our infrastructure - i.e. database connection strings, application specific configuration etc. Right now all this config is managed by hand, and drifts a lot. It's hard to say which config is still required and which can be decommissioned, it's hard to ensure exactly the same changes go from test environment to production, and that all environments were updated.</p>
<p>I wonder how can I improve this situation. I would like to have single source of truth in form of git repository, which can then be deployed to multiple datacenters (with some templating of variable substitution).</p>
<p>When I read this requirements, I think terraform with some kind of sql CRUD provider would be perfect tool:</p>
<ul>
<li>stored in git</li>
<li>infra is already defined there, so pushing stuff like database connection strings is easy</li>
<li>can review changes</li>
<li>no manually configuring data in the system</li>
<li>easy replication across environments</li>
</ul>
<p>System based on database has to stay (too much code depends on that).
Of course there is other data in the database, which changes a lot or is customer specific, and would not be managed by this setup.</p>
<p>Does it make sense to use terraform in such way?</p>
<p>Other tools I've checked:</p>
<ul>
<li>Ansible</li>
<li>Salt</li>
<li>Chef</li>
<li>Puppet</li>
</ul>
<p>All these tools were built with similar setup, however I see following downsides:</p>
<ol>
<li>Would have to push infrastructure identifiers into these tools (which is repetitive and error-prone)</li>
<li>These are complex tools, which would have to be deployed alongside terraform</li>
<li>These tools do not track state and changes, so it's not possible to see what I'm changing (i.e. terraform plan)</li>
<li>When infrastructure is provisioned there is separate bootstrapping process to register in configuration tool</li>
</ol>

<terraform><configuration-management><databases>
Is terraform good option for data management
Shadow
# Is terraform good option for data management

(Asked by: username_0 on 2023-06-11)

I have complex stack which consists of infrastructure, application and config parts, which are deployed to datacenters around the world. We have custom inhouse configuration system, based on database which is replicated elsewhere.

We have loads of configuration, which depends on our infrastructure - i.e. database connection strings, application specific configuration etc. Right now all this config is managed by hand, and drifts a lot. It's hard to say which config is still required and which can be decommissioned, it's hard to ensure exactly the same changes go from test environment to production, and that all environments were updated.

I wonder how can I improve this situation. I would like to have single source of truth in form of git repository, which can then be deployed to multiple datacenters (with some templating of variable substitution).

When I read this requirements, I think terraform with some kind of sql CRUD provider would be perfect tool:

* stored in git
* infra is already defined there, so pushing stuff like database connection strings is easy
* can review changes
* no manually configuring data in the system
* easy replication across environments

System based on database has to stay (too much code depends on that).
Of course there is other data in the database, which changes a lot or is customer specific, and would not be managed by this setup.

Does it make sense to use terraform in such way?

Other tools I've checked:

* Ansible
* Salt
* Chef
* Puppet

All these tools were built with similar setup, however I see following downsides:

1. Would have to push infrastructure identifiers into these tools (which is repetitive and error-prone)
2. These are complex tools, which would have to be deployed alongside terraform
3. These tools do not track state and changes, so it's not possible to see what I'm changing (i.e. terraform plan)
4. When infrastructure is provisioned there is separate bootstrapping process to register in configuration tool

**Tags:** terraform, configuration-management, databases


---

## 1 answers

### Answer by username_1 on 2023-06-13. Score: 2

Terraform from high level is called IaC tool (Infrastructure as code) tool; So it comes in most handy when you use it in its primary function, **providing infrastructure**.

The part of configuration should be handled by **configuration management** tools; as you mentioned like ansible, chef, puppet ect..

By my experience, in one product, we are using terraform and ansible, hand to hand; it works perfectly fine, and not just it does the job, it is easy to read, understand and maintain/change/organize. Mixing IaC and Configuration management tools in general is so good to maintain your whole platform.

However, In some other product I worked on before, when they originally designed the product, they tried to use terraform as you say in every aspect, building and configuring, since you theoretically **can execute whatever script with terraform plugins** like null\_resource; so it is doable, but on the contrary of native configuration management tools: it is hard to understand, maintain and change.

Of course all of the above depends on the complexity of each system and its design and components, but my advise, **if you want configuration management, go for configuration management tools**.

> **Comments:**
> **username_0**: I don't really want to execute scripts as null resources. I want to have sql records as regular resources, which would be managed by terraform. I.e. you deploy service, and then you keep configuration record in configuration DB to be used by other services.  

---

