Mark StosbergAlright #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. 🧵
I quickly checked out pulumictl but looks like I don't need it to get started with#pulumi
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. 🧵
The key philosophical difference between Pulumi and Terraform is the language: Terraform uses HCL (a declarative DSL), while Pulumi uses actual general-purpose languages (Python, TypeScript, Go, etc.). That gives Pulumi real loops, conditionals, functions, and type systems — so that's appealing. 🧵
Raito Bezarius@markstos you could imagine Kubernetes + Nix though
viq
Zło To 🏴☠️ ᵗʰʳᵉᵉᶠᶦᵈᵈʸ@markstos
For a server as cattle approach you have cloud-init;
For a pet approach there's @pulumi/command , but it's a bit outside pulumi philosophy.
If only nixos used a normal programming language
@markstos yeah, pulumi works with APIs. Also, pulumi is more declarative than ansible, which is quite step/task/action oriented.
Also, pulumi and terraform like to keep somewhere a state of what they've seen/done, which needs to be kept somewhere, whereas ansible just dives in and does things.
Also, pulumi and terraform like to keep somewhere a state of what they've seen/done, which needs to be kept somewhere, whereas ansible just dives in and does things.
Scott Lowe@markstos (Disclaimer: former Pulumian here, still a user.) You’re right—Pulumi is far more targeted at cloud provisioning and not server/host configuration.
@scottslowe And is Pulumi usually used in a purely cloud-native way with managed k8s and containers or is often paired with a tool like Ansible to define servers?
@markstos @scottslowe in cloud environment there's also the idea of "golden image", which is not unlike containers in that you don't start with a bare Linux that you then do things to, but a ready platform that you just pass secrets to. And you don't reconfigure or upgrade it, but replace the whole VM with a fresh, updated image.
@viq @scottslowe I've used a couple variations of the golden image idea:
1. Creating Amazon AMIs to quickly duplicate a particular server profile
2. Creating our own Ansible "base" role with standardized hardening and configuration and then on top of that other Ansible roles for other kinds of standard server definitions.
The AMI approach would constantly get stale as security updates and standard maintenance was done, so we prefer #Ansible for now, while studying NixOS.
@markstos @scottslowe yeah, you'd need CI constantly building images, and keep rolling them out to your infra. Which is one of ways to do it 🤷
NixOS is kinda similar concept, but it does that to itself without replacing the whole instance.
I somewhat dislike Ansible. It's a pretty decent orchestration system, but not great for configuration management 🤷
NixOS is kinda similar concept, but it does that to itself without replacing the whole instance.
I somewhat dislike Ansible. It's a pretty decent orchestration system, but not great for configuration management 🤷
@viq @scottslowe What are your preferred tool(s) to replace Ansible?
@markstos
I'm a salt fanboi. Mgmt has potential. I think Choria has now configuration management, I need to go look at it One Day™.
And, yes, parts of my personal infra are NixOS. Maybe some Talos in a while.
@scottslowe
I'm a salt fanboi. Mgmt has potential. I think Choria has now configuration management, I need to go look at it One Day™.
And, yes, parts of my personal infra are NixOS. Maybe some Talos in a while.
@scottslowe
@viq @scottslowe I believe I looked at Salt when I was evaluating Ansible and preferred Ansible for being stateless (no server), but looks like Salt performs better.
That's the first I've heard of Choria.
@markstos
Salt performs better, has more capabilities, is much more pleasant and flexible to work with, and having a constantly connected communications channel allows for very interesting things.
@scottslowe
Salt performs better, has more capabilities, is much more pleasant and flexible to work with, and having a constantly connected communications channel allows for very interesting things.
@scottslowe
@markstos
If you heard of MCollective, Choria is done by the guy whom Puppetlabs bought it from, and then did nothing with.
@scottslowe
If you heard of MCollective, Choria is done by the guy whom Puppetlabs bought it from, and then did nothing with.
@scottslowe
@markstos
In theory, both ansible and salt are "yaml+jinja". In practice, after working with salt, I keep hitting "what do you mean I cannot do that in ansible???"
@scottslowe
In theory, both ansible and salt are "yaml+jinja". In practice, after working with salt, I keep hitting "what do you mean I cannot do that in ansible???"
@scottslowe
@viq @scottslowe #Ansible was great:for single-purpose servers easily defined in YAML.
But as I got into Real World™️ cases where I needed the same role multiplied by X environments and Y customers on the same server, then Ansible started to feel like the wrong tool for the job. I needed variable scoping, loops, config merging... I figured out in Ansible, but efficiency slowed down as I pushed it to the limit. Made see the appeal of Pulumi, Nix or PyInfra-- using real coding languages.
@markstos
So, salt works on *data*, and yaml+jinja is only the default way of passing it. You can also use different templating languages like mako, or various abstractions on python... Or write it in pure python, and if it strikes your fancy grab data from a spreadsheet and process it into format that salt expects, and it will do the things
@scottslowe
So, salt works on *data*, and yaml+jinja is only the default way of passing it. You can also use different templating languages like mako, or various abstractions on python... Or write it in pure python, and if it strikes your fancy grab data from a spreadsheet and process it into format that salt expects, and it will do the things
@scottslowe
@viq @scottslowe That's interesting. The Jinja templating language I like just fine.
@markstos
But also, in ansible you can use jinja only to template the files. In salt, you can use it in "playbooks". That changes *a lot*.
@scottslowe
But also, in ansible you can use jinja only to template the files. In salt, you can use it in "playbooks". That changes *a lot*.
@scottslowe
@markstos
Also salt can work directly with git. You can set it up so all the policy files need to be committed for salt to see them. It can also work with branches, though that's not as flexible as puppet's r10k
@scottslowe
Also salt can work directly with git. You can set it up so all the policy files need to be committed for salt to see them. It can also work with branches, though that's not as flexible as puppet's r10k
@scottslowe
@markstos
Puppet gets an honourable mention, for one reason, and one reason only: PuppetBoard, which you get basically for free in terms of effort and infrastructure if you're using PuppetDB, and you are going to need to use PuppetDB.
@scottslowe
Puppet gets an honourable mention, for one reason, and one reason only: PuppetBoard, which you get basically for free in terms of effort and infrastructure if you're using PuppetDB, and you are going to need to use PuppetDB.
@scottslowe
@viq @scottslowe Looks like PuppetBoard is a web interface for Puppet. https://github.com/voxpupuli/puppetboard
@markstos
Web based *reporting*. Which machines had errors applying manifests, which didn't talk to master in expected time, what changes were applied.
@scottslowe
Web based *reporting*. Which machines had errors applying manifests, which didn't talk to master in expected time, what changes were applied.
@scottslowe
@markstos
For ansible, at least in theory there's ARA. There are several projects for salt with varying degree of success.
@scottslowe
For ansible, at least in theory there's ARA. There are several projects for salt with varying degree of success.
@scottslowe
@viq @scottslowe Lol, well it can certainly can be unfriendly at times. I've probably gotten too used it. 🙈
@markstos
So, we have an ansible job that runs against four digits of machines. Have fun figuring out the status.
@scottslowe
So, we have an ansible job that runs against four digits of machines. Have fun figuring out the status.
@scottslowe
@viq @scottslowe Ansible's ARA-- a storage system for Ansible results-- is new to me. Seems useful!
@scottslowe @markstos yeah. You can use it to set up cloud-init to connect the created VMs to your configuration management (salt, puppet, mgmt, the like), but those are mostly different categories of tools.
Ringo De Smet