diff --git a/content/blog/deploy-wordpress-aws-pulumi-ansible/index.md b/content/blog/deploy-wordpress-aws-pulumi-ansible/index.md index a8b518449873..785c2188ebb0 100644 --- a/content/blog/deploy-wordpress-aws-pulumi-ansible/index.md +++ b/content/blog/deploy-wordpress-aws-pulumi-ansible/index.md @@ -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. diff --git a/content/docs/iac/comparisons/chef-puppet-etc.md b/content/docs/iac/comparisons/chef-puppet-etc.md index bfdf7da191df..b4907195db66 100644 --- a/content/docs/iac/comparisons/chef-puppet-etc.md +++ b/content/docs/iac/comparisons/chef-puppet-etc.md @@ -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. diff --git a/content/docs/iac/comparisons/custom.md b/content/docs/iac/comparisons/custom.md index 9dd3982337fa..42d20ec3263a 100644 --- a/content/docs/iac/comparisons/custom.md +++ b/content/docs/iac/comparisons/custom.md @@ -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. diff --git a/content/what-is/what-is-configuration-management.md b/content/what-is/what-is-configuration-management.md index 1d486c160400..6308c4e4a749 100644 --- a/content/what-is/what-is-configuration-management.md +++ b/content/what-is/what-is-configuration-management.md @@ -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 diff --git a/content/what-is/what-is-infrastructure-as-code.md b/content/what-is/what-is-infrastructure-as-code.md index e51ce0720b93..5417ef250bde 100644 --- a/content/what-is/what-is-infrastructure-as-code.md +++ b/content/what-is/what-is-infrastructure-as-code.md @@ -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: