5 ms·

You don't need to use the service, although it solves a lot of problems. You can use only the Pulumi SDK and then solve the various state management issues that

You don't need to use the service, although it solves a lot of problems. You can use only the Pulumi SDK and then solve the various state management issues that their service provides in another fashion. I think its a reasonable business model. The SDK is completely open and free. The service is how they make money .

delnaught 6y ago
In my quick read, I didn't see a way not to use the service. "If this is your first time running pulumi new or most other pulumi commands, you will be prompted to log in to the Pulumi service. The Pulumi CLI works in tandem with the Pulumi service in order to deliver a reliable experience."[0] [0] https://www.pulumi.com/docs/get-started/kubernetes/create-project/ https://www.pulumi.com/docs/get-started/kubernetes/create-pr...
- spooneybarger 6y ago
  https://www.pulumi.com/docs/intro/cloud-providers/kubernetes/faq/#can-i-use-pulumi-without-the-pulumicom-service https://www.pulumi.com/docs/intro/cloud-providers/kubernetes...
- thearrow 6y ago
  I think Pulimi is similar to terraform in that you can use multiple backends for state management, of which their "service" is one[0]. Meaning you could use the CLI backed by an S3 bucket for free. [0]: https://www.pulumi.com/docs/intro/concepts/state/#backends https://www.pulumi.com/docs/intro/concepts/state/#backends
  - marcinzm 6y ago
    Looks like Pulimi, unlike terraform, doesn't provide a means of locking for concurrent access if you use the self-managed state.
    - delnaught 6y ago
      On its way? [0] Not sure how to tell if / when this PR makes it into 3.0 [0] https://github.com/pulumi/pulumi/pull/2697 https://github.com/pulumi/pulumi/pull/2697
      - thearrow 6y ago
        Looks like this feature may have made it into v2.23.0, behind an env var: https://github.com/pulumi/pulumi/blob/v2.23.0/CHANGELOG.md#improvements https://github.com/pulumi/pulumi/blob/v2.23.0/CHANGELOG.md#i... Nice!
daralthus 6y ago
Just to elaborate: State is a snapshot of what is deployed at a given time, it is used at the next run to compare if there were any drifts since, eg.: "Did anyone delete a server manually?" etc. By default it is stored with Pulumi, but if you are on a budget you can just use S3 with a few tradeoffs (concurrent deployments would need a lock that you implement yourself): https://www.pulumi.com/docs/intro/concepts/state/ https://www.pulumi.com/docs/intro/concepts/state/
- throwaway823882 6y ago
  Side rant: Terraform has somehow convinced people that mandatory state tracking is a good idea, because it is a useful feature sometimes. It's often more harmful than good. These tools are just configuration management for the cloud. No other configuration management tool requires your changes conform to something that was pre-existing in a state file. They simply modify the system state to reach what your intended configuration is, without needing to track state. Orchestration tools that rely entirely on state files to make all changes are poorly designed. State snapshots are a limited view of the past, and do not reflect the actual current state. So you have to grab the state, then see what has changed, and wonder if what has changed was intentional and should be preserved, or if it needs to be overwritten. This is basically distributed change consensus, like merging Git trees, or Paxos. But tools like Terraform basically throw away the current real-world state, like ignoring what's in the mainline branch, because merging is, like, hard, man. State files are useful when your CM tool cannot understand which resources need to exist in what form. Sometimes you may need to maintain certain infrastructure, but your tool doesn't have an easy way to determine what resources it is maintaining versus the resources that are not managed by it. But in most cases, there are various ways to detect that in code, rather than recording it in a state file. Every CM tool in the world does this, because you don't really care about the previous state as much as reaching your desired state! The other way state files are useful is as a log of past actions. But that's not the way tools like Terraform use it; they lean on it like a crutch. Rather than just telling you what has changed since the last Terraform run, they can often cause Terraform to just refuse to apply changes, or fail to detect and import existing resources if they weren't put into the state file manually (terraform import) or during terraform apply*.

delnaught 6y ago

In my quick read, I didn't see a way not to use the service. "If this is your first time running pulumi new or most other pulumi commands, you will be prompted to log in to the Pulumi service. The Pulumi CLI works in tandem with the Pulumi service in order to deliver a reliable experience."[0] [0] https://www.pulumi.com/docs/get-started/kubernetes/create-project/ https://www.pulumi.com/docs/get-started/kubernetes/create-pr...

spooneybarger 6y ago
https://www.pulumi.com/docs/intro/cloud-providers/kubernetes/faq/#can-i-use-pulumi-without-the-pulumicom-service https://www.pulumi.com/docs/intro/cloud-providers/kubernetes...
thearrow 6y ago
I think Pulimi is similar to terraform in that you can use multiple backends for state management, of which their "service" is one[0]. Meaning you could use the CLI backed by an S3 bucket for free. [0]: https://www.pulumi.com/docs/intro/concepts/state/#backends https://www.pulumi.com/docs/intro/concepts/state/#backends
- marcinzm 6y ago
  Looks like Pulimi, unlike terraform, doesn't provide a means of locking for concurrent access if you use the self-managed state.
  - delnaught 6y ago
    On its way? [0] Not sure how to tell if / when this PR makes it into 3.0 [0] https://github.com/pulumi/pulumi/pull/2697 https://github.com/pulumi/pulumi/pull/2697
    - thearrow 6y ago
      Looks like this feature may have made it into v2.23.0, behind an env var: https://github.com/pulumi/pulumi/blob/v2.23.0/CHANGELOG.md#improvements https://github.com/pulumi/pulumi/blob/v2.23.0/CHANGELOG.md#i... Nice!

daralthus 6y ago

Just to elaborate: State is a snapshot of what is deployed at a given time, it is used at the next run to compare if there were any drifts since, eg.: "Did anyone delete a server manually?" etc. By default it is stored with Pulumi, but if you are on a budget you can just use S3 with a few tradeoffs (concurrent deployments would need a lock that you implement yourself): https://www.pulumi.com/docs/intro/concepts/state/ https://www.pulumi.com/docs/intro/concepts/state/

throwaway823882 6y ago
Side rant: Terraform has somehow convinced people that mandatory state tracking is a good idea, because it is a useful feature sometimes. It's often more harmful than good. These tools are just configuration management for the cloud. No other configuration management tool requires your changes conform to something that was pre-existing in a state file. They simply modify the system state to reach what your intended configuration is, without needing to track state. Orchestration tools that rely entirely on state files to make all changes are poorly designed. State snapshots are a limited view of the past, and do not reflect the actual current state. So you have to grab the state, then see what has changed, and wonder if what has changed was intentional and should be preserved, or if it needs to be overwritten. This is basically distributed change consensus, like merging Git trees, or Paxos. But tools like Terraform basically throw away the current real-world state, like ignoring what's in the mainline branch, because merging is, like, hard, man. State files are useful when your CM tool cannot understand which resources need to exist in what form. Sometimes you may need to maintain certain infrastructure, but your tool doesn't have an easy way to determine what resources it is maintaining versus the resources that are not managed by it. But in most cases, there are various ways to detect that in code, rather than recording it in a state file. Every CM tool in the world does this, because you don't really care about the previous state as much as reaching your desired state! The other way state files are useful is as a log of past actions. But that's not the way tools like Terraform use it; they lean on it like a crutch. Rather than just telling you what has changed since the last Terraform run, they can often cause Terraform to just refuse to apply changes, or fail to detect and import existing resources if they weren't put into the state file manually (terraform import) or during terraform apply*.