I'm trying to use Pulumi to deploy an instance of ...
# generalc
clean-engineer-75963
12/26/2019, 9:10 PMI'm trying to use Pulumi to deploy an instance of Hashicorp Vault in Kubernetes, then connect to it using the pulumi-vault provider and provision a bunch of resources in it. Is there a good way to handle the chicken-and-egg problem this creates for preview? Pulumi can't preview the changes to be made in Vault because the instance of Vault that it would connect to to preview those changes has not been created yet, and won't be until apply time.
clean-engineer-75963
12/26/2019, 9:11 PMI'm using an instance of the Vault provider, and I've tried setting its
depends_onclean-engineer-75963
12/26/2019, 10:11 PMI'm currently forced to solve this class of problem in Terraform by having completely separate Terraform stages. Run Terraform in this directory, then change to a different directory and run that Terraform, etc.
clean-engineer-75963
12/26/2019, 10:11 PMI guess I'm going to have to do something similar in Pulumi if I want it to work.
h
handsome-actor-1155
12/27/2019, 12:36 AMYa, my thought would be to have a separate project to provision vault apart from the project standing up vault. Seems logical to me as well, one takes care of the infrastructure, one uses the infrastructure.
c
clean-engineer-75963
12/27/2019, 5:23 PMUnfortunately the deployment of the entire application is pretty tied up with Vault. We use its PKI backend to power TLS mutual auth between all of our microservices. So as each microservice is deployed, it needs a Vault token provisioned and stored in a Kubernetes secret. But Vault itself is also one of the microservices deployed in Kubernetes.
clean-engineer-75963
12/27/2019, 5:24 PMI ended up putting a check in place outside of the Pulumi programming model for whether Vault is up. If not, it doesn't try to create any Vault-dependent resources. If so, it goes ahead and tries to create everything.
clean-engineer-75963
12/27/2019, 5:24 PMSo it's broken into two phases where if you're deploying a new instance of the application from scratch, you have to run
pulumi upclean-engineer-75963
12/27/2019, 5:31 PMHeh, that doesn't work, because if you have a fully deployed stack but can't reach Vault, it tries to tear down everything it created after Vault... 😛
clean-engineer-75963
12/27/2019, 5:32 PMI think that's it for Pulumi for us. It can't seem to do what we want it to.
h
handsome-actor-1155
12/27/2019, 5:56 PMIs it JUST the preview that’s hanging you up?
c
clean-engineer-75963
12/27/2019, 6:28 PMAlso destroy. When Vault and its tokens are managed in the same pulumi stack, pulumi has been destroying Vault before the tokens. Then when it tries to destroy the tokens, it can't reach Vault, and the whole stack becomes irreparably wedged.
clean-engineer-75963
12/27/2019, 6:29 PMThis in spite of the fact that the Vault provider has an explicit depends_on for the Vault deployment, which you would think would cause it to destroy in reverse order.
h
handsome-actor-1155
12/27/2019, 6:30 PMYa, for destroy I’m not sure about but maybe try
--skip-preview