This message was deleted.
# general
s
This message was deleted.
s
I don't know if this is exactly what you're asking, but we published a blog post (and there is some associated code in a GH repo) about using Pulumi for local development with Docker. That post is here: https://www.pulumi.com/blog/local-testing-with-pulumi/ The associated GH repo has Pulumi code for local development w/ Docker (see the
develop/pulumi
folder) as well as Pulumi code for deploying to EKS (see the
infra
folder). Here's the repo link: https://github.com/pulumi-zephyr/zephyr-app/ I hope this helps!
👀 1
i
thanks Scott! I'm working through this now. I still see a lot of repetition, and my main goal is to avoid this if possible for example: https://github.com/search?q=repo%3Apulumi-zephyr%2Fzephyr-app%20retail-store-sample-cart&type=code this is an image name that i'd think should only be present in 2 locations: • build site • consume site (stack definition) with the consume site being customized per environment without repetition
s
There are certainly ways you could reduce potential duplication; for example, the local development program could be modified with a configuration flag to push built images to ECR, and the infrastructure program could be modified to always/only use the specified image from ECR (or whatever registry you choose to use).
🙌 1
i
ok, besides the duplication (can certainly see a lot of opportunity for abstractions!) there are some really great ideas here. I also use nx to run tasks, so I could even potentially use
nx affected
to determine which services to build locally vs which to pull from the registry -- instead of manually setting the
serviceFlag
config value
s
Yep, there's lots of ways to "slice and dice" it!
i
i'm getting the sense that i don't need AtomicJar's testcontainers and I can just use the pulumi Docker provider?
s
I'm not super familiar with TestContainers (sorry), but you can get quite far with just the Pulumi Docker provider.
🙌 1
d
For many cases, you can also deploy to a local k8s cluster in the same style of that blog post. If you have Docker Desktop, this is probably the easiest way, but you can use other clusters like k3s, kind, or microk8s. You might need to make certain pieces conditional, like using Service NodePort instead of LoadBalancer
i
I'm definitely all-in on using Pulumi to converge my env-specific stacks into a single program, especially after looking into Helm and Kustomize. the last things im trying to solve now are • cache invalidation - e.g. how does the Image resource know it needs to be rebuilt • launching & running containers, usually i would use
docker compose up --build
in forefront while developing. Not sure if I need to wrap
pulumi up
in an nx task and then use nx after that to control the running phase • something similar to "profiles" in docker compose, or say "run service X and all its dependencies only" • having an option to not run the service under dev inside a container, e.g. run it outside docker and configure it to talk to the containers, which then means I can implement some type of live reloading when code changes for faster feedback loops
s
I'm curious if anyone has any pulumi and kustomize examples they have to share.
s
Back in 2020 I did a demo that included
kustomize
functionality as part of the Kubernetes provider. Here’s a link to the repo: https://github.com/scottslowe/2020-ces-iac-capi (look in the
templated-kustomize/k8s
directory). There’s not much there, TBH, but it might help a little.
🙌 1