#pulumi — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #pulumi, aggregated by home.social.
-
[Перевод] Лучшие практики по Kubernetes. Жаль, я не знала о них раньше
Недавно попался очень внятный материал от Pulumi про ключевые Kubernetes‑практики, которые начинаешь ценить, к сожалению, только после первых инцидентов и неприятных сюрпризов. Решила перевести для себя и коллег, а заодно положить на Хабр, добавив к переводу своих мыслей. В материале — ключевые практики для 2026 года: задавать requests и limits для каждого контейнера, изолировать нагрузки через namespaces и NetworkPolicy, автоматизировать health checks и еще много всего. Приглашаю под кат.
https://habr.com/ru/companies/cloud_ru/articles/1060100/
#kubernetes #gitopsпрактики #rbac #prometheus #helm #kustomize #pulumi #sbom #finops #kyverno
-
[Перевод] Лучшие практики по Kubernetes. Жаль, я не знала о них раньше
Недавно попался очень внятный материал от Pulumi про ключевые Kubernetes‑практики, которые начинаешь ценить, к сожалению, только после первых инцидентов и неприятных сюрпризов. Решила перевести для себя и коллег, а заодно положить на Хабр, добавив к переводу своих мыслей. В материале — ключевые практики для 2026 года: задавать requests и limits для каждого контейнера, изолировать нагрузки через namespaces и NetworkPolicy, автоматизировать health checks и еще много всего. Приглашаю под кат.
https://habr.com/ru/companies/cloud_ru/articles/1060100/
#kubernetes #gitopsпрактики #rbac #prometheus #helm #kustomize #pulumi #sbom #finops #kyverno
-
[Перевод] Лучшие практики по Kubernetes. Жаль, я не знала о них раньше
Недавно попался очень внятный материал от Pulumi про ключевые Kubernetes‑практики, которые начинаешь ценить, к сожалению, только после первых инцидентов и неприятных сюрпризов. Решила перевести для себя и коллег, а заодно положить на Хабр, добавив к переводу своих мыслей. В материале — ключевые практики для 2026 года: задавать requests и limits для каждого контейнера, изолировать нагрузки через namespaces и NetworkPolicy, автоматизировать health checks и еще много всего. Приглашаю под кат.
https://habr.com/ru/companies/cloud_ru/articles/1060100/
#kubernetes #gitopsпрактики #rbac #prometheus #helm #kustomize #pulumi #sbom #finops #kyverno
-
IaC в разрозненной среде: сравнение Terraform и Pulumi
Привет, Хабр! Это первая статья из цикла материалов о построении инженерной платформы в гетерогенной среде. Мы будем разбирать инструменты, антипаттерны и ограничения при эксплуатации. В этом выпуске сравним подходы Terraform и Pulumi, а также рассмотрим управление состоянием, детекцию дрейфа инфраструктуры и практику управления инфраструктурой как кодом (IaC).
-
IaC в разрозненной среде: сравнение Terraform и Pulumi
Привет, Хабр! Это первая статья из цикла материалов о построении инженерной платформы в гетерогенной среде. Мы будем разбирать инструменты, антипаттерны и ограничения при эксплуатации. В этом выпуске сравним подходы Terraform и Pulumi, а также рассмотрим управление состоянием, детекцию дрейфа инфраструктуры и практику управления инфраструктурой как кодом (IaC).
-
IaC в разрозненной среде: сравнение Terraform и Pulumi
Привет, Хабр! Это первая статья из цикла материалов о построении инженерной платформы в гетерогенной среде. Мы будем разбирать инструменты, антипаттерны и ограничения при эксплуатации. В этом выпуске сравним подходы Terraform и Pulumi, а также рассмотрим управление состоянием, детекцию дрейфа инфраструктуры и практику управления инфраструктурой как кодом (IaC).
-
Stop debugging broken YAML deployments at 2am. Wladi Mitzel shows how Java teams can define, test & deploy cloud infrastructure with real #Java code instead of YAML chaos — with #JUnit, refactoring, #CI/CD & type safety: https://javapro.io/2026/05/12/stop-writing-yaml-how-to-define-test-and-deploy-your-cloud-in-pure-java/
-
Stop debugging broken YAML deployments at 2am. Wladi Mitzel shows how Java teams can define, test & deploy cloud infrastructure with real #Java code instead of YAML chaos — with #JUnit, refactoring, #CI/CD & type safety: https://javapro.io/2026/05/12/stop-writing-yaml-how-to-define-test-and-deploy-your-cloud-in-pure-java/
-
currently investigating a good directory structure for my #IaC with #pulumi
there will be my "www stuff", but i also want to leave some space for silly side projects. so maybe some sort of multi-project setup ?not sure yet! but reading through this as a start https://www.pulumi.com/docs/iac/guides/basics/organizing-projects-stacks/
-
currently investigating a good directory structure for my #IaC with #pulumi
there will be my "www stuff", but i also want to leave some space for silly side projects. so maybe some sort of multi-project setup ?not sure yet! but reading through this as a start https://www.pulumi.com/docs/iac/guides/basics/organizing-projects-stacks/
-
currently investigating a good directory structure for my #IaC with #pulumi
there will be my "www stuff", but i also want to leave some space for silly side projects. so maybe some sort of multi-project setup ?not sure yet! but reading through this as a start https://www.pulumi.com/docs/iac/guides/basics/organizing-projects-stacks/
-
currently investigating a good directory structure for my #IaC with #pulumi
there will be my "www stuff", but i also want to leave some space for silly side projects. so maybe some sort of multi-project setup ?not sure yet! but reading through this as a start https://www.pulumi.com/docs/iac/guides/basics/organizing-projects-stacks/
-
currently investigating a good directory structure for my #IaC with #pulumi
there will be my "www stuff", but i also want to leave some space for silly side projects. so maybe some sort of multi-project setup ?not sure yet! but reading through this as a start https://www.pulumi.com/docs/iac/guides/basics/organizing-projects-stacks/
-
I think I actually figured the sweet spot:
1. Author #routeros config in #nix.It just makes sense. It's declarative but with good options, and I can model all of my routers and cross-reference the configuration with Nix modules support. The options hierarchy loosely follows Mikrotik, the modules offer logical slicing.
2. Nix outputs JSON.
As JSON is a valid YAML, this can be fed straight into Pulumi’s YAML SDK. Even better, #pulumi calls Nix itself!
3. Pulumi actuates the state.
This solves the problem of secrets in Nix (no secrets), the diff calculation (3-way sync between plan, state, live), and tolerance to manual router config changes that I might forget about.
4. A script runs Pulumi up and does a real diff.
Everything above is vibecoded, so this is the guardrail: even if Pulumi provider fucks up, the script will show the real diff between the live config export before and after. It's not a state diff, it's a semantic diff of routeros export, and it's 100% reliable in telling what did actually change.
-
I think I actually figured the sweet spot:
1. Author #routeros config in #nix.It just makes sense. It's declarative but with good options, and I can model all of my routers and cross-reference the configuration with Nix modules support. The options hierarchy loosely follows Mikrotik, the modules offer logical slicing.
2. Nix outputs JSON.
As JSON is a valid YAML, this can be fed straight into Pulumi’s YAML SDK. Even better, #pulumi calls Nix itself!
3. Pulumi actuates the state.
This solves the problem of secrets in Nix (no secrets), the diff calculation (3-way sync between plan, state, live), and tolerance to manual router config changes that I might forget about.
4. A script runs Pulumi up and does a real diff.
Everything above is vibecoded, so this is the guardrail: even if Pulumi provider fucks up, the script will show the real diff between the live config export before and after. It's not a state diff, it's a semantic diff of routeros export, and it's 100% reliable in telling what did actually change.
-
I think I actually figured the sweet spot:
1. Author #routeros config in #nix.It just makes sense. It's declarative but with good options, and I can model all of my routers and cross-reference the configuration with Nix modules support. The options hierarchy loosely follows Mikrotik, the modules offer logical slicing.
2. Nix outputs JSON.
As JSON is a valid YAML, this can be fed straight into Pulumi’s YAML SDK. Even better, #pulumi calls Nix itself!
3. Pulumi actuates the state.
This solves the problem of secrets in Nix (no secrets), the diff calculation (3-way sync between plan, state, live), and tolerance to manual router config changes that I might forget about.
4. A script runs Pulumi up and does a real diff.
Everything above is vibecoded, so this is the guardrail: even if Pulumi provider fucks up, the script will show the real diff between the live config export before and after. It's not a state diff, it's a semantic diff of routeros export, and it's 100% reliable in telling what did actually change.
-
I think I actually figured the sweet spot:
1. Author #routeros config in #nix.It just makes sense. It's declarative but with good options, and I can model all of my routers and cross-reference the configuration with Nix modules support. The options hierarchy loosely follows Mikrotik, the modules offer logical slicing.
2. Nix outputs JSON.
As JSON is a valid YAML, this can be fed straight into Pulumi’s YAML SDK. Even better, #pulumi calls Nix itself!
3. Pulumi actuates the state.
This solves the problem of secrets in Nix (no secrets), the diff calculation (3-way sync between plan, state, live), and tolerance to manual router config changes that I might forget about.
4. A script runs Pulumi up and does a real diff.
Everything above is vibecoded, so this is the guardrail: even if Pulumi provider fucks up, the script will show the real diff between the live config export before and after. It's not a state diff, it's a semantic diff of routeros export, and it's 100% reliable in telling what did actually change.
-
I think I actually figured the sweet spot:
1. Author #routeros config in #nix.It just makes sense. It's declarative but with good options, and I can model all of my routers and cross-reference the configuration with Nix modules support. The options hierarchy loosely follows Mikrotik, the modules offer logical slicing.
2. Nix outputs JSON.
As JSON is a valid YAML, this can be fed straight into Pulumi’s YAML SDK. Even better, #pulumi calls Nix itself!
3. Pulumi actuates the state.
This solves the problem of secrets in Nix (no secrets), the diff calculation (3-way sync between plan, state, live), and tolerance to manual router config changes that I might forget about.
4. A script runs Pulumi up and does a real diff.
Everything above is vibecoded, so this is the guardrail: even if Pulumi provider fucks up, the script will show the real diff between the live config export before and after. It's not a state diff, it's a semantic diff of routeros export, and it's 100% reliable in telling what did actually change.
-
Most Infrastructure-as-Code breaks once complexity appears: copy-pasted #YAML, hidden dependencies & untestable configs. @wlami shows how #Java replaces fragile cloud configs with reusable, testable infrastructure components: https://javapro.io/2026/05/12/stop-writing-yaml-how-to-define-test-and-deploy-your-cloud-in-pure-java/
-
Most Infrastructure-as-Code breaks once complexity appears: copy-pasted #YAML, hidden dependencies & untestable configs. @wlami shows how #Java replaces fragile cloud configs with reusable, testable infrastructure components: https://javapro.io/2026/05/12/stop-writing-yaml-how-to-define-test-and-deploy-your-cloud-in-pure-java/
-
Stop debugging broken YAML deployments at 2am. Wladi Mitzel shows how Java teams can define, test & deploy cloud infrastructure with real #Java code instead of YAML chaos — with #JUnit, refactoring, #CI/CD & type safety: https://javapro.io/2026/05/12/stop-writing-yaml-how-to-define-test-and-deploy-your-cloud-in-pure-java/
-
@markstos heh, yeah 😂 #Pulumi doesn't do that. I do use it exclusively for creating cloud resources, or occasionally things of a similar nature like Docker containers running on a host which had the Docker runtime installed and configured separately.
In order to get things installed on the servers after I provision them, I've historically mostly used shell scripts, although for new stuff I'm transitioning to cloud-init. Or in some cases I might separately (manually) prepare an image containing everything I want to wind up on the new server and use that.
For management of existing infrastructure I've been using #Pyinfra, which I like, although it doesn't have the wealth of predefined tasks/roles/playbooks that Ansible does. Someday I would like to integrate Pyinfra into my Pulumi usage.
-
It seems like a tool like #Pulumi or TerraForm that focuses on provisioning via Cloud APIs often paired with something these that's focused on server definitions like Ansible or NixOS. 🧵
-
Alright #DevOps tonight I'm starting a thread about trying out #Pulumi for the first time. This is an Infrastructure as Code tool with the pitch that you can write the code in the language of your choice ( https://www.pulumi.com/ ). I'll be comparing it to #Ansible which I have more experience with. I'll try porting a server I've defined with Ansible to Pulumi and see what my first impression is. First, I need to get installed and choose a language to code in. 🧵
-
https://www.pulumi.com/blog/cdktf-is-deprecated-whats-next-for-your-team/ - Now that #Terraform CDKTF is deprecated, what's next? #Pulumi is right there, and #HCL was never bad anyway. Or ... Great discussion Adam Gordon Bell and Christian Nunciato.
-
The list might grow over the year too😁:
1) Rust
2) Jujutsu VCS
3) Nushell
4) helix motions
5) Nix - much more deeper
6) Pulumi
7) GCP
8) Zellij
9) Tailscale / Netbird (or anything wireguard based)
etcAnd more importantly I want to share
my learning journey, findings etcIf u are a fellow learner too of any of these, let's connect😁
Matrix:
https://matrix.to/#/#vivekanandan_ks:matrix.org#rust #jj #jujutsu #vcs #nushell #vim #vimmotions #helix #nix #pulumi #gcp #cloud #learning #passion #life #newyear2026
-
Seattle startup Pulumi bets big on AI with Neo, an agent that automates cloud infrastructure tasks - Pulumi CEO Joe Duffy. (GeekWire File Photo / Kevin Lisota)
Seattle startup Pul... - https://www.geekwire.com/2025/seattle-startup-pulumi-bets-big-on-ai-with-neo-an-agent-that-automates-cloud-infrastructure-tasks/ #infrastructure #startups #joeduffy #pulumi #neo #ai
-
I really liked Pulimi, despite it not working for me due to poor support for Digital Ocean.
EDIT: The rest of this post appears untrue.
Sadly the poor support for non-meta platforms is still an issue though, and OpenTofu still seems more viable.
----
The thing that makes me pessimistic about it as a project is that as I understand it, when you develop a plugin for a new service, you have to develop it for each language separately. In other words, since Pulumi supports Javascript, and Go, and Python, you need to write the plugin, or at least parts of the plugin, for each of those and ensure they all work.
That means developing a plugin goes beyond scratching your own itch and into scratching many other itches in languages you may not even know, placing the barrier to entry very high.
If I'm wrong and that's not how Pulumi works, please let me know, because this seems like a huge problem.
-
@tom I don't... Enjoy working with Ansible.
I feel like it's a baller orchestration engine - need to make 150 AWS EC2 instances dance the Irish jig? Ansible's got you covered.
But when you start building complex cookbooks to build ana manage infrastructure, I feel like its abstractions are not well suited to that task at all and it tends to fall down hard.
#Pulumi or #Terraform are much better choices for that IMO.
Also, just so I'm not ignoring your suffering, sorry you're having to deal with this! Never fun when IaC goes awry :)
-
Credit where credit is due, #pulumi worked super hard on fixing this bug, and it seems like it was a non trivial one to boot.
Something ugly wriggling around deep in the bowels of their #golang code apparently :)
https://github.com/pulumi/pulumi-aws/issues/5652#issuecomment-3137348441
I sincerely appreciate the hard work that went into this solve. Can't ask anything more of anyone than that!
And I do love working with #pulumi, it's a first class way to build infrastructure with real code and not some made up #DSL that you'll bang your head on in an infinite loop when you hit an edge case!
