Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
---
2023-06-02 21:41:36 -07:00
title_tag: "Resource Providers"
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
meta_desc: A resource provider handles communications with a cloud service to create, read, update, and delete the resources you define in your Pulumi programs.
2023-05-15 15:25:28 -07:00
title: Providers
h1: Resource providers
2023-06-08 16:15:52 -07:00
meta_image: /images/docs/meta-images/docs-meta.png
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
menu:
2023-05-15 15:25:28 -07:00
concepts:
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
parent: resources
weight: 4
2023-05-15 15:25:28 -07:00
aliases:
- /docs/intro/concepts/resources/providers/
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
---
A resource provider handles communications with a cloud service to create, read, update, and delete the resources you define in your Pulumi programs. Pulumi passes your code to a language host such as Node.js, waits to be notified of resource registrations, assembles a model of your desired state, and calls on the resource provider to produce that state. The resource provider translates those requests into API calls to the cloud service.
A resource provider is tied to the language that you use to write your programs. For example, if your cloud provider is AWS, the following providers are available:
- JavaScript/TypeScript: `@pulumi/aws`
- Python: `pulumi-aws`
- Go: `github.com/pulumi/pulumi-aws/sdk/go/aws`
- .NET: `Pulumi.Aws`
Normally, since you declare the language and cloud provider you intend to use when you write a program, Pulumi installs the provider for you as a plugin, using the appropriate package manager, such as NPM for Typescript.
The resource provider for custom resources is determined based on its package name. For example, the `aws` package loads a plugin named `pulumi-resource-aws` , and the `kubernetes` package loads a plugin named `pulumi-resource-kubernetes` .
## Default Provider Configuration
By default, each provider uses its package’ s global configuration settings, which are controlled by your stack’ s configuration. You can set information such as your cloud provider credentials with environment variables and configuration files. If you store this data in standard locations, Pulumi knows how to retrieve them.
For example, suppose you run this CLI command:
```bash
$ pulumi config set aws:region us-west-2
```
Then, suppose you deploy the following Pulumi program:
2022-05-03 21:23:32 -07:00
{{< chooser language " javascript , typescript , python , go , csharp , java " > }}
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{{% choosable language javascript %}}
```javascript
let aws = require("@pulumi/aws ");
let instance = new aws.ec2.Instance("myInstance", {
instanceType: "t2.micro",
ami: "myAMI",
});
```
{{% /choosable %}}
{{% choosable language typescript %}}
```typescript
let aws = require("@pulumi/aws ");
let instance = new aws.ec2.Instance("myInstance", {
instanceType: "t2.micro",
ami: "myAMI",
});
```
{{% /choosable %}}
{{% choosable language python %}}
```python
from pulumi_aws import ec2
instance = ec2.Instance("myInstance", instance_type="t2.micro", ami="myAMI")
```
{{% /choosable %}}
{{% choosable language go %}}
```go
vpc, err := ec2.NewInstance(ctx, "myInstance", & ec2.InstanceArgs{
InstanceType: pulumi.String("t2.micro"),
Ami: pulumi.String("myAMI"),
})
```
{{% /choosable %}}
{{% choosable language csharp %}}
```csharp
var instance = new Aws.Ec2.Instance("myInstance", new Aws.Ec2.InstanceArgs
{
InstanceType = "t2.micro",
Ami = "myAMI",
});
```
2022-05-03 21:23:32 -07:00
{{% /choosable %}}
{{% choosable language java %}}
```java
var instance = new Instance("myInstance",
InstanceArgs.builder()
.instanceType("t2.micro")
.ami("myAMI")
.build());
```
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{{% /choosable %}}
{{< / chooser > }}
It creates a single EC2 instance in the us-west-2 region.
## Explicit Provider Configuration
While the default provider configuration may be appropriate for the majority of Pulumi programs, some programs may have special requirements. One example is a program that needs to deploy to multiple AWS regions simultaneously. Another example is a program that needs to deploy to a Kubernetes cluster, created earlier in the program, which requires explicitly creating, configuring, and referencing providers. This is typically done by instantiating the relevant package’ s `Provider` type and passing in the options for each `Resource` that needs to use it. For example, the following configuration and program creates an ACM certificate in the `us-east-1` region and a load balancer listener in the `us-west-2` region.
2023-08-02 09:51:35 -07:00
{{% notes type="info" %}}
**Note:** This example for AWS does not apply to Azure which provides access to all regions regardless of the default region defined in your Pulumi program. That means you don't need to explicitly create and configure providers for each region when working with Azure. You can simply specify the region in the resource definition itself.
{{% /notes %}}
2022-05-03 21:23:32 -07:00
{{< chooser language " javascript , typescript , python , go , csharp , java " > }}
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{{% choosable language javascript %}}
```javascript
let pulumi = require("@pulumi/pulumi ");
let aws = require("@pulumi/aws ");
// Create an AWS provider for the us-east-1 region.
let useast1 = new aws.Provider("useast1", { region: "us-east-1" });
// Create an ACM certificate in us-east-1.
let cert = new aws.acm.Certificate("cert", {
domainName: "foo.com",
validationMethod: "EMAIL",
}, { provider: useast1 });
// Create an ALB listener in the default region that references the ACM certificate created above.
let listener = new aws.lb.Listener("listener", {
loadBalancerArn: loadBalancerArn,
port: 443,
protocol: "HTTPS",
sslPolicy: "ELBSecurityPolicy-2016-08",
certificateArn: cert.arn,
defaultAction: {
targetGroupArn: targetGroupArn,
type: "forward",
},
})
```
{{% /choosable %}}
{{% choosable language typescript %}}
```typescript
let pulumi = require("@pulumi/pulumi ");
let aws = require("@pulumi/aws ");
// Create an AWS provider for the us-east-1 region.
let useast1 = new aws.Provider("useast1", { region: "us-east-1" });
// Create an ACM certificate in us-east-1.
let cert = new aws.acm.Certificate("cert", {
domainName: "foo.com",
validationMethod: "EMAIL",
}, { provider: useast1 });
// Create an ALB listener in the default region that references the ACM certificate created above.
let listener = new aws.lb.Listener("listener", {
loadBalancerArn: loadBalancerArn,
port: 443,
protocol: "HTTPS",
sslPolicy: "ELBSecurityPolicy-2016-08",
certificateArn: cert.arn,
defaultAction: {
targetGroupArn: targetGroupArn,
type: "forward",
},
});
```
{{% /choosable %}}
{{% choosable language python %}}
```python
import pulumi
import pulumi_aws as aws
# Create an AWS provider for the us-east-1 region.
useast1 = aws.Provider("useast1", region="us-east-1")
# Create an ACM certificate in us-east-1.
cert = aws.acm.Certificate("cert",
domain_name="foo.com",
validation_method="EMAIL",
2023-02-13 05:15:08 -08:00
opts=pulumi.ResourceOptions(provider=useast1))
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
# Create an ALB listener in the default region that references the ACM certificate created above.
listener = aws.lb.Listener("listener",
load_balancer_arn=load_balancer_arn,
port=443,
protocol="HTTPS",
ssl_policy="ELBSecurityPolicy-2016-08",
certificate_arn=cert.arn,
default_action={
"target_group_arn": target_group_arn,
"type": "forward",
})
```
{{% /choosable %}}
{{% choosable language go %}}
```go
// Create an AWS provider for the us-east-1 region.
useast1, err := aws.NewProvider(ctx, "useast1", & aws.ProviderArgs{
Region: pulumi.String("us-east-1"),
})
if err != nil {
return err
}
// Create an ACM certificate in us-east-1.
cert, err := acm.NewCertificate(ctx, "myInstance", & acm.CertificateArgs{
DomainName: pulumi.String("foo.com"),
ValidationMethod: pulumi.String("EMAIL"),
}, pulumi.Provider(useast1))
if err != nil {
return err
}
// Create an ALB listener in the default region that references the ACM certificate created above.
listener, err := lb.NewListener(ctx, "myInstance", & lb.ListenerArgs{
LoadBalancerArn: loadBalancerArn,
Port: pulumi.Int(443),
Protocol: pulumi.String("HTTPS"),
SslPolicy: pulumi.String("ELBSecurityPolicy-2016-08"),
CertificateArn: cert.Arn,
DefaultActions: lb.ListenerDefaultActionArray{
& lb.ListenerDefaultActionArgs{
TargetGroupArn: targetGroupArn,
Type: pulumi.String("forward"),
},
},
})
if err != nil {
return err
}
```
{{% /choosable %}}
{{% choosable language csharp %}}
```csharp
// Create an AWS provider for the us-east-1 region.
var useast1 = new Aws.Provider("useast1", new Aws.ProviderArgs { Region = "us-east-1" });
// Create an ACM certificate in us-east-1.
2022-09-08 15:23:20 -07:00
var cert = new Aws.Acm.Certificate("cert", new Aws.Acm.CertificateArgs
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{
DomainName = "foo.com",
ValidationMethod = "EMAIL",
2022-09-08 15:23:20 -07:00
}, new CustomResourseOptions { Provider = useast1 });
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
// Create an ALB listener in the default region that references the ACM certificate created above.
var listener = new Aws.Lb.Listener("listener", new Aws.Lb.ListenerArgs
{
LoadBalancerArn = loadBalancerArn,
Port = 443,
Protocol = "HTTPS",
SslPolicy = "ELBSecurityPolicy-2016-08",
CertificateArn = cert.arn,
DefaultAction: new Aws.Lb.ListenerDefaultAction
{
TargetGroupArn = targetGroupArn,
Type = "forward",
},
});
```
2022-05-03 21:23:32 -07:00
{{% /choosable %}}
{{% choosable language java %}}
```java
// Create an AWS provider for the us-east-1 region.
var useast1 = new Provider("useast1",
ProviderArgs.builder().region("us-east-1").build());
// Create an ACM certificate in us-east-1.
var cert = new Certificate("cert",
CertificateArgs.builder()
.domainName("foo.com")
.validationMethod("EMAIL")
.build(),
CustomResourceOptions.builder()
.provider(useast1)
.build());
// Create an ALB listener in the default region that references the ACM certificate created above.
var listener = new Listener("listener",
ListenerArgs.builder()
.loadBalancerArn(loadBalancerArn)
.port(443)
.protocol("HTTPS")
.sslPolicy("ELBSecurityPolicy-2016-08")
.certificateArn(cert.arn())
.defaultActions(ListenerDefaultActionArgs.builder()
.targetGroupArn(targetGroupArn)
.type("forward")
.build())
.build());
```
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{{% /choosable %}}
{{< / chooser > }}
```bash
$ pulumi config set aws:region us-west-2
```
Component resources also accept a set of providers to use with their child resources. For example, the EC2 instance parented to `myResource` in the program below is created in `us-east-1` , and the Kubernetes pod parented to myResource is created in the cluster targeted by the `test-ci` context.
2022-05-03 21:23:32 -07:00
{{< chooser language " javascript , typescript , python , go , csharp , java " > }}
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{{% choosable language javascript %}}
```javascript
class MyResource extends pulumi.ComponentResource {
constructor(name, opts) {
let instance = new aws.ec2.Instance("instance", { ... }, { parent: this });
let pod = new kubernetes.core.v1.Pod("pod", { ... }, { parent: this });
}
}
let useast1 = new aws.Provider("useast1", { region: "us-east-1" });
let myk8s = new kubernetes.Provider("myk8s", { context: "test-ci" });
let myResource = new MyResource("myResource", { providers: { aws: useast1, kubernetes: myk8s } });
```
{{% /choosable %}}
{{% choosable language typescript %}}
```typescript
class MyResource extends pulumi.ComponentResource {
constructor(name, opts) {
let instance = new aws.ec2.Instance("instance", { ... }, { parent: this });
let pod = new kubernetes.core.v1.Pod("pod", { ... }, { parent: this });
}
}
let useast1 = new aws.Provider("useast1", { region: "us-east-1" });
let myk8s = new kubernetes.Provider("myk8s", { context: "test-ci" });
let myResource = new MyResource("myResource", { providers: { aws: useast1, kubernetes: myk8s } });
```
{{% /choosable %}}
{{% choosable language python %}}
```python
class MyResource(pulumi.ComponentResource):
def __init__ (self, name, opts):
2023-02-13 05:15:08 -08:00
instance = aws.ec2.Instance("instance", ..., opts=pulumi.ResourceOptions(parent=self))
pod = kubernetes.core.v1.Pod("pod", ..., opts=pulumi.ResourceOptions(parent=self))
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
useast1 = aws.Provider("useast1", region="us-east-1")
myk8s = kubernetes.Provider("myk8s", context="test-ci")
my_resource = MyResource("myResource", pulumi.ResourceOptions(providers={
"aws": useast1,
"kubernetes": myk8s,
})
```
{{% /choosable %}}
{{% choosable language go %}}
```go
useast1, err := aws.NewProvider(ctx, "useast1", & aws.ProviderArgs{
Region: pulumi.String("us-east-1"),
})
if err != nil {
return err
}
myk8s, err := kubernetes.NewProvider(ctx, "myk8s", & kubernetes.ProviderArgs{
Context: pulumi.String("test-ci"),
})
if err != nil {
return err
}
myResource, err := NewMyResource(ctx, "myResource", pulumi.ProviderMap(map[string]pulumi.ProviderResource{
"aws": useast1,
"kubernetes": myk8s,
}))
if err != nil {
return err
}
```
{{% /choosable %}}
{{% choosable language csharp %}}
```csharp
using Pulumi;
using Aws = Pulumi.Aws;
using Kubernetes = Pulumi.Kubernetes;
class MyResource : ComponentResource
{
public MyResource(string name, ComponentResourceOptions opts)
: base(name, opts)
{
var instance = new Aws.Ec2.Instance("instance", new Aws.Ec2.InstanceArgs { ... }, new CustomResourceOptions { Parent = this });
var pod = new Kubernetes.Core.V1.Pod("pod", new Kubernetes.Core.V1.PodArgs { ... }, new CustomResourceOptions { Parent = this });
}
}
class MyStack
{
public MyStack()
{
var useast1 = new Aws.Provider("useast1",
new Aws.ProviderArgs { Region = "us-east-1" });
var myk8s = new Kubernetes.Provider("myk8s",
new Kubernetes.ProviderArgs { Context = "test-ci" });
var myResource = new MyResource("myResource",
new ComponentResourceOptions { Providers = { useast1, myk8s } });
}
}
```
2022-05-03 21:23:32 -07:00
{{% /choosable %}}
{{% choosable language java %}}
```java
final var usEast1 = new com.pulumi.aws.Provider("aws",
com.pulumi.aws.ProviderArgs.builder()
.region("us-east-1")
.build());
final var myk8s = new com.pulumi.kubernetes.Provider("kubernetes",
com.pulumi.kubernetes.ProviderArgs.builder()
.kubeconfig(kubeconfig)
.build());
final var myresource = new MyResource("myResource",
ComponentResourceOptions.builder()
.providers(usEast1, myk8s)
.build());
```
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{{% /choosable %}}
{{< / chooser > }}
2022-02-17 14:07:04 -08:00
## Disabling Default Providers
2023-05-15 15:25:28 -07:00
While default providers are enabled by default, they [can be disabled ](/docs/concepts/config#special-configuration-options ) on a per stack basis. Disabling default
2022-02-17 14:07:04 -08:00
providers is a good idea if you want to ensure that your programs must be explicit about which provider they
will use. For example, to disable the `aws` provider, you can run:
```sh
$ pulumi config set --path 'pulumi:disable-default-providers[0]' aws
```
If you wanted to also disable the `kubernetes` default provider, as well as the `aws` default provider, you could run:
```sh
$ pulumi config set --path 'pulumi:disable-default-providers[1]' kubernetes
```
This adds a new entry to the list `pulumi:disable-default-providers` . To disable all default providers, use `*` as the package name:
```sh
$ pulumi config set --path 'pulumi:disable-default-providers[0]' '*'
```