This message was deleted.
# general
s
This message was deleted.
👍 1
l
I think the only way to have multiple backends per project is to omit it from Pulumi.yaml, and to use
pulumi login <backend>
before
pulumi stack select
.
This is not (afaik) possible with the Pulumi GitHub action; you would need to use a job with the Pulumi Docker image and the appropriate commands, or similar.
b
yes this is correct, you need a single state bucket for every stack in a project, we don’t yet support per stack backends
e
okay thanks for that ... i was thinking that would be a possible solution but been fairly new to pulumi i was not sure if that considered best practise or not. again thank you 👍
e
we don’t yet support per stack backends
Just to set expectations, I don't think we'll ever support this. The backend tells us the stack, its very flipped logic to somehow get a stack to tell us what backend to use.
☝️ 1
l
You could automate it with automation-api. Setting ProjectBackend can be done before referring to any stacks.
e
okay thanks for letting me know @echoing-dinner-19531 i guess it's a matter of perspective and logic i guess :-) what i mean is the pulumi doc i have read give example of having a stack for
dev
and another for
staging
etc. I have been deploying to aws for a while now with diffrent customers and it has always been the case that each of these environments (`dev`|`stage`|`prod`) are in diffrent aws accounts. Coming from a terraform/cloudformation background this pretty standard setup. Your comment "The backend tells us the stack" now makes sense why this would not be supported. I just need to get my head around a bit more on how pulumi works 🙂 very happy to go ahead and try out @little-cartoon-10569 suggestion
b
it’s been a few years since I worked with terraform, but for terraform’s implementation of stacks (workspaces) the same applies. You generally need a third party wrapper like terragrunt to handle a state per account model
e
if this was terraform one way would be to simply have a backend file for each environment which just has the parameters for that environment. For example a file
dev_backend.config
which contains the following:
bucket         = "terraform-backend-eks-hello-dev"
region         = "eu-west-1"
key            = "terraform-backend-eks-hello-dev/eu-west-1/dev/terraform.tfstate"
dynamodb_table = "dynamo-terraform-state-lock"
encrypt        = true
then in github actions you pass this file into terraform to initialise the setup
- name: Terraform Init
run: |
terraform init -input=false -backend=true -backend-config="backend.config"
shell: bash
working-directory: ${{ env.TF_EKS_ENTRY_POINT }}
you can then have a backend end file for called
prod_backend.config
and so on. Terragrunt is a great tool for keeping your code DRY but you don't need it to support multiple backends. again thanks for all the advise on this. Only first week with Pulumi so I have allot to learn
b
right, but the
terraform init
phase is analogous to
pulumi login
1
l
You are not required to use the same account for the backend as for everything else. If you have multiple customers that you deploy for, I recommend having an account / bucket that belongs to you that stores all backends.
The backends belong to you, not your customers
b
In my opition, it would be good and flexible feature if we can specify env variable in Pulumi.yaml file like this:
Copy code
backend:
    url: s3://${AWS_BUCKET}?region=us-east-1
@elegant-dog-76355, another option is to use PULUMI_BACKEND_URL env variable.
Copy code
export PULUMI_BACKEND_URL="<s3://your-bucket?region=us-east-1>"
e
thanks @bitter-carpenter-93554 ... this link was pointed out to me which has that env variable option you suggested. putting it here in case others find it usefull I think the safer option is to use the
pulumi login
cmd because if that fails you can catch and react to the error but thats just my option 1 week in using pulumi :-)