https://pulumi.com logo
Join Slack
Powered by
Hi all, :wave: I am going to be working through s...
# general
r
Hi all, šŸ‘‹ I am going to be working through switching from CDKTF to Pulumi and I wanted to see if anyone had experience doing so. I know the docs recommend generating HCL out of synth, but i found that the HCL generated isn't actually valid, so I was going to do a state first migration, and then use claude/neo to convert the terraform typescript to pulumi. Does anyone have experience with this/any guidance on issues they have run into with this approach? Want to make sure the approach is sane before I start sinking time into it, or any common gotchas that would just prevent this from working. We are strictly in AWS.
s
I thought the synthesized HCL has to be valid. Isn't that a part of how it works? (Synth to HCL -> run TF normally)
r
I really thought so too, but if I recall correctly, when I used terraform to parse it out it threw a bunch of errors
This was a few weeks ago, but in Terraform cloud, I actually have it using the cdktf.out.json directly, not hcl.
I can try to reproduce the error I got and share. I am pulled into a bunch of product oriented tasks, but getting us off of CDKTF and onto pulumi is on my list of things to do for the business since I see the deprecation of CDKTF as a clear reason to get away from it asap.
So I see two clear errors. one is that we actually loop and treat our staging vs prod as two separate stacks, but 
cdktf synth --hcl
outputs our prod and staging stacks to both the staging and prod cdk.tf files. The next error I see is an "Invalid Character" in various constructs. Without sharing the full thing, it doesn't like that there is a 
$
when using vars like:
Copy code
ā”‚ Error: Invalid character
ā”‚ 
... " SOME_VAR_JSON_FIELD ":" $ { var.SOME_VAR_VALUE } "}"
This is why I was thinking we would just pull the tf state for each, convert it to pulumi state, then update the code.
s
Are you using the Neo skill for this? https://www.pulumi.com/docs/ai/skills/#terraform-to-pulumi-migration Curious how it's working for you if you got that far.
r
I have not gotten that far, but am happy to use it with Claude Code, which I was going to use for this anyways. I just wanted to confirm if, given the errors above, doing the tf state migration approach makes the most sense.
s
Here's an idea that I think would work really well with Neo: Migrate the state to Pulumi and tell tell Neo "generate the code so that there's no diff", and maybe give it the CDKTF code as context. It should do that in an unattended way that should be fairly time-efficient.
r
Yeah, I actually was going to use claude code in the repo that is currently CDKTF, and have it update the code in place to be pulumi.
Does pulumi have a 1:1 replacement for terraform variables?
s
Regular ol' variables since it's regular ol' programming languages. Config if they come from outside the codebase.
r
Yeah these are secrets and were being stored in sensitive TF Variables on terraform cloud, so I am assuming in pulumi cloud I can set them there and reference them similarly? (The team did this and I really hate they did, so maybe this is just the time to say manage those secrets contents directly in our secret manager, while letting infra manage the creation of the secret itself)
s
Have you looked at ESC yet?
r
I am looking at it now.
s
Are any of those secrets TF outputs?
r
No, thankfully.
They just land in AWS Secrets Manager.
s
Perfect! Here's what I think you should do for the secrets: ā€¢ Set up OIDC with AWS to the secrets account(s): https://github.com/pulumi/examples/tree/master/aws-ts-oidc-provider-pulumi-cloud ā€¢ Set up the Secrets Manager integration: https://www.pulumi.com/docs/esc/integrations/dynamic-secrets/aws-secrets/ ā€¢ Create an ESC environment and make sure it can pull the secrets ā€¢ Import the environments into your Pulumi stacks
3 Views
Open in Slack
PreviousNext
Powered by