https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
l
You are looking for automation API: https://github.com/pulumi/pulumi/issues/3901 There is a PR out for an alpha release of our Go support https://github.com/pulumi/pulumi/pull/4977
b
@quaint-egg-65511 can you talk a little bit about the workflow you have with terraform?
q
Nope I'm not looking for automation API, I'm talking about having pulumi running entirely on CI and not having a "setup phase" where an "admin" must run 
pulumi stack init
and commit. With terraform and terragrunt we don't interact with the state manually, we just commit and the CI runs. There is no distinction between first run and any other runs
Maybe there's a way with pulumi and I've just not understood how to do it
e
Here's what I'm doing in my CI pipelines: • Install pulumi • Run 
pulumi login
• Run 
pulumi stack select --create "$ORGANIZATION/$PROJECT_NAME/$STACK_NAME"
• Create a config file `Pulumi.$STACK_NAME.yaml``, and edit it with 
yq
• Run 
pulumi preview --config-file "Pulumi.$STACK_NAME.yaml"
q
Our terragrunt CI is like:
Copy code
cd environments/dev
terragrunt apply-all
And all modules are applied recursively with dependency resolution
e
The 
pulumi stack select --create <stackname>
part handles creation, and 
yq
handles setting up the config. Pulumi has a command for setting config values but there's some reason I didn't use it when I set things up, can't remember now what it was
q
@echoing-breakfast-73834 how do you save the encryption key that is inserted into Pulumi.<stack>.yml? That key is supposed to be saved into git. I don't know why pulumi can't save it into the backend
e
Sorry which encryption key? Are you referring to the Pulumi API key or provider credentials or something else? There are no keys by default stored in the config
For example here's my config from a testing project:
Copy code
config:
  aws:region: us-east-2
The only reason why aws:region is in there is because IIRC I put it there - no other values i.e. encryption keys
f
So for my CI we use GitLab. The project code is developed in a branch (then merged to master) and the stack (environment) is already created during development but never ran a up on it yet. In GitLab we have the pulumi key provided as an environment variable (PULUMI_ACCESS_TOKEN) so it isn't saved anywhere in the git projects. In the CI pipeline is does essentially the below (not all in the same job though [preview/up])
Copy code
pulumi login
pulumi plugin install
pulumi stack select ${STACK_NAME}
pulumi preview --diff
pulumi up --yes --skip-preview
q
@fast-dinner-32080 we use gitlab too and your code is really similar to our but my issue is having to run stack init out of CI, that's horrible
e
Sorry yes I should have specified that - I'm doing something similar, but with Azure DevOps. I have the pulumi access token stored in a secrets vault and I pull it into an environment variable at runtime.
f
We never run stack init in gitlab ci. That is done outside during development.
If we need a new stack (env) we run stack init and setup the config as needed
q
@echoing-breakfast-73834 I'm talking about pulumi secrets encryption provider, we use kms
@fast-dinner-32080 so all your devs have access to the state backend
f
Well only a few people have access to creating a new stack.
q
With terraform there's not "init"
f
Then all development is done and only ran by gitlab
after mr approval
q
@fast-dinner-32080 that's the point, you have a part that is done out of git and versioning
f
I see what you are saying. You want a stack and its config to be dynamically setup if it doesn't exist yet.
h
In my CI environment, I always run 
pulumi -s <stack name> init
and ignore the error if the stack exists. As for the pulum.*.yaml file, you can actually set all configuration values via command line options (
pulumi up -c key=value
).
So you don't have to have the specific Pulumi.<stack>.yaml file available ahead of time.
it would be nicve if 
pulumi up
had a 
create-stack
flag but it doesn't 🤷
f
Ah yea and you could already have the config file ready before hand
that would be nice
the only issue is the encryption secret when using a different secret provider
i guess the ci could also set that config on each run too
e
Just to clarify what you're looking for so that I can give a complete answer: • All from a CI pipeline • Create a new stack • Use AWS KMS as the stack secret provider And one other thing to clarify - are you looking to create the KMS key that's being used for the secrets provider for the stack, in the stack?
@quaint-egg-65511
q
This is our CI pipeline atm:
Copy code
before_script:
  - python -V
  - poetry -V
  - pulumi version
  - pulumi login --cloud-url <s3://my-pulumi-state>
  - poetry install

preview.nprd:
  tags:
    - pulumi
  image: $PULUMI_IMAGE
  stage: preview
  script:
    - pulumi stack select -c my-service.common -C ./my-service --secrets-provider=$PULUMI_SECRETS_KMS
    - pulumi preview --non-interactive -C ./my-service --diff
  rules:
    ...
and this is just 1 stack, if we add more the CI will grow and grow and we will have to keep it ordered by dependency
this is our terragrunt CI:
Copy code
plan.nprd:
  tags:
    - terragrunt
  stage: plan
  variables:
    <<: *nprd-variables
  script:
    - cd workspaces/nprd
    - terragrunt plan-all --terragrunt-non-interactive
  rules:
    ....
simple, easy, devs just code new modules and config
@echoing-breakfast-73834 to answer your question, i don’t know how pulumi works and why it works like this but if i use default, passphrase or kms as 
--secrets-provider
during 
pulumi stack init
it will add some kind of 
encryption(salt|key)
to the 
Pulumi.<stack>.yml
file. If this happens during CI (as you can see I use 
stack select --create
) I will lose that edit and I don’t know if it is important or not because is not documented
b
so just catching up here, but it seems like we're comparing apples and oranges right? terragrunt was created to wrap around terraform and create reference stacks. with regards to the 
stack init
component, if you have a 
Pulumi.<stack>.yaml
in your repo you can do 
pulumi stack up -s <stack>
there's no need to run init
q
@billowy-army-68599 the part about terragrunt was just another thing we thought pulumi would have solved vs terraform+terragrunt
About the 
Pulumi.<stack>.yaml
i have it before the CI runs! but we just put our stack configs
what about the 
encryptedkey
added to it when you run 
stack init
or 
stack select -c
?
b
i can appreciate that. Terragrunt is very opinionated, it seems like you're wanting a monorepo and something to traverse subdirectories with nested stacks/folders and shared config between them, we don't really have an off-the-shelf solution for that right now Re: the encryption key, even with terragrunt (if I recall, been a while) someone has to locally bootstrap some configuration when you add a new environment right? with terragrunt you'd have to do (locally, before checking into CI)
Copy code
mkdir -p prod/{app,vpc,mysql}
touch prod/{app,vpc,mysql}/terragrunt.hcl
with pulumi all you have to do is 
pulumi stack init  --secretes-provider=foo
q
yes but with terraform/terragrunt, if you are a developer, you don’t need access to KMS or worse to the state storage to create a PR, that’s what I don’t understand. IMHO is not gitops friendly having to manually do operations on the state storage out of version control. I’m talking about state storage edits because when you init a stack you MUST be logged to a backend and it will do some bootstrap write to the state storage.
something like:
Copy code
{
    "version": 3,
    "checkpoint": {
        "stack": "my-service.common"
    }
b
if you are a developer, you don’t need access to KMS
this is because terraform stores all values in its state in plaintext, which we don't. If you're doing a stack init, you need access to do 
encrypt
on the key, you don't need access to 
decrypt
though, which should be acceptable?
or worse to the state storage to create a PR,
the native terraform way of working (ie with workspaces) does need this, your point is valid with regards to terragrunt though. Is the main reason you're restricting access to the pulumi state because you don't want your devs to be able to edit things?
I’m talking about state storage edits because when you init a stack you MUST be logged to a backend and it will do some bootstrap write to the state storage
a stack init is very similar to a 
terraform init
- our stacks have different state storage, terraform stores all its configuration in one big state file unless you're using workspaces
depending on your backend, if you really don't want to allow your devs access to the state you should be able to give them 
kms:Encrypt
permissions for the KMS key and write permission to the state and it should functionally do the same thing
I'm happy to schedule some time on a zoom call to chat through your use case though
we want to make sure everyone is supported and happy with their workflow
q
I think pulumi is really near to what I would like, it's just missing some refinements to be more CI friendly. As you say, under the hood pulumi is similar to terraform but the CLI promotes more an interactive usage than a CI automation usage.
38 Views
Open in Slack
PreviousNext
Powered by