https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
l
You should (usually) group your resources into projects defined by their deployment cycle. The account and region is less important, because you can have multiple providers in the one project, allowing you to deploy to multiple places in the same 
pulumi up
.
Each project should have stacks based on repeated instances of your project. This may be equivalent to account+region for you, or just account, but most likely, you should think about dev, stage, prod, etc.
👍 1
a
When you say 
deploy to multiple places in the same
did you mean, multiple AWS accounts?
l
Yes
a
I was thinking of doing separate deployments so that if something is wrong with the application/resource on STAGE, we will hold off in deploying it to PROD account
l
There's more explanation (and alternative approaches) here: https://www.pulumi.com/docs/guides/organizing-projects-stacks/
a
thank you
l
I was thinking of doing separate deployments so that if something is wrong with the application/resource on STAGE, we will hold off in deploying it to PROD account
Hence, different stacks.
a
got it
l
And in STAGE, you might want to deploy the database once only, and the app once peer week. So, you'd need 2 different projects.
a
got it
we have 2 web teams that build different applications. In our current tooling, they are saved as a separate artifact, totally no relationship with each other. In pulumi, that means there will be 2 or more stacks per team and those stacks won't be related to the other teams. Correct?
l
No, probably not. The two apps probably don't get deployed at the same time or at the same frequency, so different projects would suit. Each project would have its own DEV, STAGE, PROD etc.
a
got it!
l
Assuming that both teams deploy on top of the same shared infrastructure (into the same VPC, using the same Redis and Aurora, etc.) then you'll need a different project for the shared infra, too.
Maybe more than one.
a
I see. I haven't seen that kind of scenario yet at work
but good to know
l
DNS and VPC are rarely maintained the same project as an app.
Well, some DNS is, some isn't 🙂 The problem, as we all know, is usually DNS.
a
for us, dns is always updated especially when a new project is created by our users. Route53 will have a new entry on the private zone specifically an A and CNAME record of the new app deployed
it's automatically updated by our tooling called Foremast, which I'm planning to replace with Pulumi 🙂
l
But for your TLS certs for you main domain, you won't want to update those every time you update an application. And TLS certs need DNS records...
a
yes
l
So that would be in a shared project, not an app project.
a
yep
I just started using Pulumi 4 nights ago. I'm still looking for equivalent process we have now but using pulumi. I was told some doesn't exist yet. Looks like I'll be building our own code for hiding pulumi to our developer teams. That way, we can keep existing configuration files(read by Foremast) in devteams' git repos and have my new code read those configuration files and pass it to Pulumi to build resources
l
You can do that. Automation-api can help with that. Or just hide it within your build system. 
yarn run deploy
hides 
pulumi up
just fine 🙂
Or 
yarn run deploy STAGE
...
a
yep, that's one way
I'm thinking of creating a docker image where I will use it with gitlab-runner. This image will have the pulumi tools installed
l
Also, don't feel you have to hide anything. Coders love new tricks and tools 🙂
Those docker images already exist
👍 1
Pulumi releases many docker images, per language.
a
yeah that's true but i'm worried they will have so much control
l
You can review the Dockerfiles. It's safe
Oh, you mean the coders will have control?
a
yep, I'll definitely use it 🙂
yeah coders wil have control
that's why we hid Foremast from them
l
Coders should have the control. Otherwise your lead times will grow and frustration will rise.
You just need to build the right safety into the system so that control is safe.
a
so far it's working and it's been like this for 5+ years now. They do have some annoyance 😄
especially our team is small now, their feature requests doesn't get created quickly
I'll read about automation-api today
l
Then they're probably too big.. but that's a story for another day.
a
yep
I have a question about resources and state. So I've been playing with pulumi locally on a self managed gitlab(in a docker container). Am I right that the state is being saved locally?
l
That's configured by your backend (in Pulumi.yaml), which is configured by your 
pulumi login
. What backend have you logged into?
a
let me check
Copy code
name: iac-workshop-ec2-webservers
runtime:
  name: python
  options:
    virtualenv: venv
description: A minimal AWS Python Pulumi program
that's my yaml file
l
You're using the Pulumi backend.
It's the default.
a
I have not read about backends yet. Is backend related to storage?
and is Pulumi backend locally saved ?
l
Backend is storage of state. Pulumi state is just a JSON file. The Pulumi service stores state for you on Pulumi infrastructure. You need to log into a local backed if you want to store it locally.
a
got it
let me check if I'll be able to find the json file on the directory
can't find it on the directory, lol
I only found "./venv/lib/python3.10/site-packages/pulumi_aws/pulumi-plugin.json"
looks like I found it
it's in 
vi ~/.pulumi/stacks/dev.json
my stack name is dev
Once pulumi gets implemented in production at work, I'll have to switch the state from local to s3. It's because the machine we use for running CI is terminated after the ci scripts are done
Now I am thinking, looks like backend is the first thing to implement
2 Views
Open in Slack
PreviousNext
Powered by