Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/blog/deploy-wordpress-aws-pulumi-ansible/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ authors: ["joe-duffy"]
tags: ["aws", "ansible", "configuration", "wordpress"]
---

There are two primary kinds of infrastructure as code tools: *configuration management*, like Ansible, Chef, and Puppet, which configure, patch, or upgrade existing servers, and *provisioning*, like Pulumi, Terraform, and CloudFormation, which create, update, and delete the underlying infrastructure itself. Provisioning has taken over from configuration management as the dominant form of IaC over the past decade as we've shifted to modern immutable infrastructure architectures that use containers, serverless, and managed services. And yet, configuration management still remains important and relevant, especially for heritage, stateful, server-centric, and on-prem or hybrid solutions. The good news is that it doesn't need to be either-or choice: the two approaches are complementary. In this post, you'll see how and why you might combine them by deploying a WordPress Server to AWS by provisioning infrastructure with Pulumi and configuring the server with Ansible.
There are two primary kinds of infrastructure as code tools: *[configuration management](/what-is/what-is-configuration-management/)*, like Ansible, Chef, and Puppet, which configure, patch, or upgrade existing servers, and *provisioning*, like Pulumi, Terraform, and CloudFormation, which create, update, and delete the underlying infrastructure itself. Provisioning has taken over from configuration management as the dominant form of IaC over the past decade as we've shifted to modern immutable infrastructure architectures that use containers, serverless, and managed services. And yet, configuration management still remains important and relevant, especially for heritage, stateful, server-centric, and on-prem or hybrid solutions. The good news is that it doesn't need to be either-or choice: the two approaches are complementary. In this post, you'll see how and why you might combine them by deploying a WordPress Server to AWS by provisioning infrastructure with Pulumi and configuring the server with Ansible.

<!--more-->

Expand Down
11 changes: 11 additions & 0 deletions content/docs/iac/comparisons/chef-puppet-etc.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,3 +35,14 @@ Pulumi works well with modern "immutable infrastructure" architectures, where bo
unnecessary. In such cases, configuration management is not needed in the usual sense. Pulumi also works well with
classical approaches to infrastructure, however, which often entail virtual machines and where continuing to use a
configuration tool in conjunction is easy. In either case, Pulumi will help on your path to cloud native architectures.

## When you might not need a separate configuration management tool

For many modern cloud workloads—especially containers, serverless functions, and immutable infrastructure—traditional configuration management tools may not be necessary. Even for virtual machines with simpler needs, Pulumi's [Command provider](/registry/packages/command/) can handle common [configuration management](/registry/packages/command/) tasks like:

- Running initialization scripts after instance creation
- Installing packages or software
- Copying configuration files to remote hosts
- Executing setup commands via SSH

The Command provider integrates directly into your Pulumi program, providing a unified workflow for both provisioning and configuration. For complex, ongoing configuration management needs, combining Pulumi with Ansible, Chef, or Puppet remains a powerful pattern.
4 changes: 4 additions & 0 deletions content/docs/iac/comparisons/custom.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,3 +43,7 @@ Finally, Pulumi is [open source](https://github.com/pulumi/pulumi) and community
are custom needs, it is possible to make those customizations required, just like it would be with home-grown solutions.
For most customers, Pulumi replaces their custom solutions without any customizations necessary, but knowing that this
is an option should help know that Pulumi will be available in the long-term, and can evolve to meet your growing needs.

## Integrating existing scripts with Pulumi

If you have existing Bash, Python, or other scripts for provisioning or configuration tasks, you don't have to abandon them entirely. Pulumi's [Command provider](/registry/packages/command/) lets you run local or remote commands as part of your Pulumi program. This means you can gradually migrate to Pulumi while still leveraging scripts that work well for your team.
2 changes: 1 addition & 1 deletion content/what-is/what-is-configuration-management.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ Like any practice, there are some potential disadvantages to configuration manag

## How does configuration management relate to infrastructure as code?

Although configuration management (as a process) can apply to managing cloud infrastructure, the implementation of most configuration management tools make them less suitable for use in an [infrastructure as code](/what-is/what-is-infrastructure-as-code/) (IaC) use case than a dedicated infrastructure as code tool like Pulumi. However, configuration management tools are great companions to an infrastructure as code tool like Pulumi, offering the ability to perform fine-grained configuration changes on cloud infrastructure provisioned via Pulumi (for example, ensuring that the operating system on a cloud instance is configured in a specific way or with a specific software package or application). Here's [a great example of using Pulumi and Ansible together](/blog/deploy-wordpress-aws-pulumi-ansible/).
Although configuration management (as a process) can apply to managing cloud infrastructure, the implementation of most configuration management tools make them less suitable for use in an [infrastructure as code](/what-is/what-is-infrastructure-as-code/) (IaC) use case than a dedicated infrastructure as code tool like Pulumi. However, configuration management tools are great companions to an infrastructure as code tool like Pulumi, offering the ability to perform fine-grained configuration changes on cloud infrastructure provisioned via Pulumi (for example, ensuring that the operating system on a cloud instance is configured in a specific way or with a specific software package or application). Here's [a great example of using Pulumi and Ansible together](/blog/deploy-wordpress-aws-pulumi-ansible/). For simpler configuration scenarios—such as installing a package, copying configuration files, or running initialization scripts—Pulumi's [Command provider](/registry/packages/command/) offers a lightweight alternative. The Command provider enables you to run commands locally or on remote hosts as part of your Pulumi deployment, giving you a unified workflow for both provisioning and basic configuration tasks.

## Conclusion

Expand Down
2 changes: 1 addition & 1 deletion content/what-is/what-is-infrastructure-as-code.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ page_title: "What is Infrastructure as Code?"

Infrastructure as code (IaC) is an approach to automating the provisioning and management of infrastructure. At its heart, **infrastructure as code is about bringing software engineering principles, approaches, and tools into the cloud infrastructure space.**

Before infrastructure as code, infrastructure was (and in some cases still is!) provisioned in a variety of ways, such as by pointing and clicking in a user interface (UI), by running commands via a command-line interface (CLI), by running batch scripts, or by using configuration management tools that may not have been designed with cloud infrastructure in mind. Each of these methods falls short in some way; interactive methods involving a UI or a CLI often create problems with repeatability and consistency while batch scripts or configuration management tools may be unable to declaratively manage infrastructure. Today, modern approaches use platforms, such as [Pulumi](/), which embrace and support the full software engineering lifecycle.
Before infrastructure as code, infrastructure was (and in some cases still is!) provisioned in a variety of ways, such as by pointing and clicking in a user interface (UI), by running commands via a command-line interface (CLI), by running batch scripts, or by using [configuration management](/what-is/what-is-configuration-management/) tools that may not have been designed with cloud infrastructure in mind. Each of these methods falls short in some way; interactive methods involving a UI or a CLI often create problems with repeatability and consistency while batch scripts or configuration management tools may be unable to declaratively manage infrastructure. Today, modern approaches use platforms, such as [Pulumi](/), which embrace and support the full software engineering lifecycle.

In this article, we'll touch on four key questions regarding infrastructure as code:

Expand Down
Loading