gotta say I'm super excited to start playing with ...
# getting-started
s
gotta say I'm super excited to start playing with the automation API to build simple internal web services (with Python) for various tasks in my org
1
b
would love to see what you've built when you get chance!
👍 1
s
I do wish we could get away from Ansible for on prem stuff eventually. K8s is promising in terms of this universal control plane for infra, but on prem k8s in it's current state... I don't know
b
what does your on prem stuff look like at the moment?
s
vsphere, linux/windows, lot's of old legacy servers 🙂
some cloud goodness 🙂
I don't see Ansible going away anytime soon
ansible provider for pulumi in the works?
one tool to rule them all
h
Does the Terraform vmware vsphere provider work with Pulumi?
s
why stop at all of the cloud, all of machines!
b
there's no ansible provider, we don't support that level of abstraction (ie at the operating system layer) - we do have a libvirt provider now though!
it's in private beta, if you want to try it out, let me know -we need some initial testers
@handsome-napkin-75099 we have a vsphere provider: https://github.com/pulumi/pulumi-vsphere/
h
That was what I understood. @straight-scientist-39468 you may be able to use the vsphere provider. I used Terraform version in a previous position.
s
looking into it now actually. interesting
didn't look at libvirt before
looks a little too low level for my pay grade so to speak 😄
p
@straight-scientist-39468 I'm working on automating a lot of infrastructure in our on-premise vSphere data center as well. Mostly linux, some windows. Before I found Pulumi, I had been using Ansible, but ran into no end of problems (vSpheres Ansible collections are poorly documented and buggy). Now I'm switching to using Pulumi and quickly learned what @billowy-army-68599 said - there's no official support for ansible in Pulumi. Basically you would have to fork out to an ansible process from your pulumi program. At first I found that very odd and surprising. I can only assume that Pulumi lacks a concept of "provisioning" as an intentional way of conceptually separating infrastructure management from configuration management. Assuming this, I'm taking the approach of pre-baking completely ready to go immutable images with Packer and ansible, then (only) deploying them with Pulumi. It would be helpful if someone could chime in as to whether this was best practice or not.
👍 1
b
@purple-nail-36818 you're correct: Pulumi operates at a different abstraction layer than ansible. Pulumi calls APIs on your behalf and drives towards a declarative state. There are no APIs at the operating system layer, so you need to hand off to another process to configure operating systems. A common mechanism is the one you described - building immutable images using something like packer, and deploying them with pulumi. If you're using the Python or TypeScript SDKs, you can do some OS provisioning using dynamic providers, but my personal belief is using immutable images is best practice