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. 🧵
Looks like my language choices for #Pulumi are limited to TypeScript, Python, Go, C#, or Java. I know TypeScript better, but I'm interested in learning more #Python so I'll choose that. Time to get Pulumi installed! 🧵
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
David Zaslavsky@markstos I've been using Pulumi for personal infrastructure for some time but I'm always looking for perspectives on it, so I will be following your experience with interest!
@diazona You mean using Pulumi provision personal cloud infra. How are you defining what's inside your servers?
I don't really have any infra besides a Mac Mini in my basement running Linux, which I think is probably a poor fit for Pulumi. 😂
@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.
@diazona Yeah, there's like 10 pyinfra packages on PyPI https://pypi.org/search/?q=pyinfra&page=1 vs like 37,000 roles published for Ansible... https://galaxy.ansible.com/ui/standalone/roles/
@markstos Yeah, exactly. It's a pretty flexible framework and it does well at the basic stuff, but it's lacking in depth. (In my experience that's a mild inconvenience but not generally hard to work around if you care to put in the effort.)
One thing to bear in mind is that the Pyinfra devs favor building new functionality into Pyinfra itself rather than publishing it as separate plugins, at least if it's generic enough to be potentially useful to other people. So there may be things that Pyinfra includes but where the equivalent in Ansible is a separate package. Of course this doesn't change the fact that Ansible has a much larger ecosystem.
Marcos Dione@diazona @markstos I saw a talk in FOSDEM and the guy was all "you need to talk to AWS, no problem, install boto3 and voilà". It seemed like there is no integration.
I mean, one of the good things I see about Ansible is that it is very consistent, and if the module is well written, you get things like support for diff mode. PyInfra looked more like "we give you easy ssh and support for a few things and the rest is up to you", at least the way they talked about it.
@mdione @markstos I suppose that's true. Ansible is consistent, but my experience has been that it's consistently very frustrating; modules often don't do what I want them to, and figuring out why is very difficult because the modules poorly documented and the code is extremely complex to debug. Whereas Pyinfra reduces pretty much everything to simple shell commands through a thin translation layer. If a Pyinfra command isn't doing what I want, it's usually pretty easy to figure out why and to either fix how I'm using it or make something new that does the right thing for me. So for me, having to do a bit more of the work to use Pyinfra is a very beneficial trade-off.