Sup: Simple Ansible-like deployment tool for multiple SSH hosts(pressly.github.io)
pressly.github.io
Sup: Simple Ansible-like deployment tool for multiple SSH hosts
https://pressly.github.io/sup/
4 comments
Very similar to what I wrote about a year ago.
https://github.com/Nessphoro/DeliveryTruck
https://github.com/Nessphoro/DeliveryTruck
So how does it compare to Ansible?
I built one of these too -- and using ansible and salt has sorta taught me how it actually wasn't that bad of an idea. I got exactly what I wanted and knew exactly what it was doing.
Like, if you're coming from it as a developer, it's not hard to write this sorta thing, and you understand it -- where as with ansible and salt you have to wade through the docs to figure out how things are done and then some things just don't really work that great all the time.
That being said, I wouldn't write another one, but IMO, if it's fun, why not?
Like, if you're coming from it as a developer, it's not hard to write this sorta thing, and you understand it -- where as with ansible and salt you have to wade through the docs to figure out how things are done and then some things just don't really work that great all the time.
That being said, I wouldn't write another one, but IMO, if it's fun, why not?
Hi all, I'm one of the designers of the sup project.
Interestingly, we only looked at Ansible, or later heard of salt, after we already wrote the first version of sup. Later our friends told us it reminded them of Ansible. We believe sup is much simpler, because its more DIY from the perspective of the user.
It's written in Go and currently the master cloc's in at 890 lines of code. Sup is just a small utility and personally I view it as complete, other than any refinements that come through its life. Thanks to Go, it's also pretty nice that the sup binary doesn't require the install of any external runtime.
When designing it, our high-level goals were to have a very fast and simple deployment tool that anyone on our development team (including frontend devs), could deploy their applications to our network. It's been working really well for us for over a year now.
To be honest, I've still never tried Ansible or salt, and I'm sure there is a lot of capabilities they have, but, whatever they are, we've been fine without them. For example, sup doesn't have 1000s of community playbooks, but you can reference local programs/scripts that are piped and executed remotely on a network - we use this often for deploying docker containers.
Finally here's something I love, and maybe possible with Ansible (I don't see why not):
https://gist.github.com/pkieltyka/4ab679a692db47e0b410f66b3a...
then run.. `sup staging tail-logs` to tail live server output. Or even filter it with, `sup staging tail-logs | grep WARN`.
Interestingly, we only looked at Ansible, or later heard of salt, after we already wrote the first version of sup. Later our friends told us it reminded them of Ansible. We believe sup is much simpler, because its more DIY from the perspective of the user.
It's written in Go and currently the master cloc's in at 890 lines of code. Sup is just a small utility and personally I view it as complete, other than any refinements that come through its life. Thanks to Go, it's also pretty nice that the sup binary doesn't require the install of any external runtime.
When designing it, our high-level goals were to have a very fast and simple deployment tool that anyone on our development team (including frontend devs), could deploy their applications to our network. It's been working really well for us for over a year now.
To be honest, I've still never tried Ansible or salt, and I'm sure there is a lot of capabilities they have, but, whatever they are, we've been fine without them. For example, sup doesn't have 1000s of community playbooks, but you can reference local programs/scripts that are piped and executed remotely on a network - we use this often for deploying docker containers.
Finally here's something I love, and maybe possible with Ansible (I don't see why not):
https://gist.github.com/pkieltyka/4ab679a692db47e0b410f66b3a...
then run.. `sup staging tail-logs` to tail live server output. Or even filter it with, `sup staging tail-logs | grep WARN`.
Or more important - why use it over Ansible? Ansible has some warts, but it also has 1000s of plays you can reuse for free.
Speed. Zero learning curve. DYI rather then searching for thousands of playbooks. Sup is meant for developers and plays very well with Docker.
[deleted]
Or Salt? All that and simple YAML flavor by default. I mean, nice work, but I don't see any holes in the ops space that this fills, and there's already a proliferation of tools solving the same problem. I like that the MIT license has fewer words than Apache 2.0, but otherwise I see nothing to buy into here.
Scanning this site I feel déjà vu like I am looking at an incipient, less mature version of Salt with fewer features.
Scanning this site I feel déjà vu like I am looking at an incipient, less mature version of Salt with fewer features.
Sup is simpler, much faster and doesn't have any dependencies (since it's written in Golang). It doesn't come with any Playbooks and doesn't have large community. Writing Supfile is much more DYI thing where you exactly know what happens, when and why.
From Devops perspective, it's a step back. From developer's perspective, it's a very handy tool without any learning curve.
From Devops perspective, it's a step back. From developer's perspective, it's a very handy tool without any learning curve.
Neat.
So does it have SUPDUP support? ;)
So does it have SUPDUP support? ;)
I presume the linked article is the Sup Doc.
Sup doesn't support SUPDUP. It uses SSH in RAW or TTY mode.
I think I should reconsider :)
I think I should reconsider :)
Well, if it was ever rewritten to support multiple transports, and it DID support SUPDUP, it would instantly become the most popular deployment and system management tool on systems that run supdup :). But even supporting those systems may require quite a bit of work...
I'm convinced now :)
https://wiki.archlinux.org/index.php/sup