#pulumi — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #pulumi, aggregated by home.social.
-
Publicado el provider de #pulumi para crear maquinas virtuales Ubuntu con multípass
La idea es facilitar la creación de clústers "locales" de nomad desde línea de comando y poder ejecutar pipelines de #nextflow como un pro
Presentada la propuesta de charla al grupo de usuarios de Cape Town para poder hacer una demo, 🤞🤞
https://github.com/incsteps/pulumi-provider-multipass -
[Перевод] Лучшие практики по 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).
-
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/
-
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.