Live data from Hacker News

Show HN: A simple Go utility to ease deployments via SSH and SCP

github.com

1–10 of 26 posts

Re: Show HN: A simple Go utility to ease deployments via SSH and SCP

#3
post #2

A comparison to Ansible might be helpful to help clarify why you would choose this instead.

This. I think Go Templates can be nearly or equally as powerful as Jinja2, but there may need to be additional filters and shortcodes added like Hugo.

Re: Show HN: A simple Go utility to ease deployments via SSH and SCP

#4
post #2

A comparison to Ansible might be helpful to help clarify why you would choose this instead.

That's a good point. Ansible is robust, well-known, well-supported, and has support for doing anything and everything from creating users, to setting cron-jobs, MySQL users, and more.

This application only allows two things:

* Uploading a file, or series of files. * Running a command, or series of commands.

In short I'm very simple. But because of that it avoids some of the horrors of trying to be overly-complex in the way that Ansible is. It avoids cryptic failures, and the horrible "language" for looping constructs, etc.

I could imagine adding support for cron, mysql, etc, but I think as soon as you allow real conditional actions to such utilities it becomes a mess to use.

Re: Show HN: A simple Go utility to ease deployments via SSH and SCP

#5
post #2

A comparison to Ansible might be helpful to help clarify why you would choose this instead.

This. I think Go Templates can be nearly or equally as powerful as Jinja2, but there may need to be additional filters and shortcodes added like Hugo.

To make this useful I guess you'd probably want more filters in the "language", to allow conditionals, looping, etc.

Those are things I deliberately left out, but I could be open to persuasion if the expression was natural.

Re: Show HN: A simple Go utility to ease deployments via SSH and SCP

#7
Heh, I made a similar thing (mostly unreleased/undocumented at [0], original idea at [1]) that would take your Go code, build a binary wrapper for it using the target OS arch, SSH to the target, SCP the file over, run the binary, connect stdout/stderr/stdin with the remote, allow the remotely running binary to request files from the home binary, and delete itself once complete. One thing I found is SCP/SFTP is a really slow transfer protocol and an alternative should be made available as an option (but leave SSH as the default).

I believe that we are getting to a point where config management might as well be in a programming language instead of a bunch of ad-hoc scripts in templates that defer to dynamic language scripts and become a mess.

0 - https://github.com/cretz/systrument 1 - https://github.com/cretz/software-ideas/issues/1

Re: Show HN: A simple Go utility to ease deployments via SSH and SCP

#8
post #6

This definitely looks interesting, have you considered an option to use rsync instead of scp?

No, I had not. Interesting idea. Presumably over the existing SSH, rather than using the rsynd-deamon?

Not a bad idea, but I guess I'd need to think about it. Mostly the "large" files I pull from github, or distribution sites. I tend to only upload some simple config-files, and systemd-service units. So the extra overhead of SCP isn't so significant.

Re: Show HN: A simple Go utility to ease deployments via SSH and SCP

#9
post #7

Heh, I made a similar thing (mostly unreleased/undocumented at [0], original idea at [1]) that would take your Go code, build a binary wrapper for it using the target OS arch, SSH to the target, SCP the file over, run the binary, connect stdout/stderr/stdin with the remote, allow the remotely running binary to request files from the home binary, and delete itself once complete. One thing I found is SCP/SFTP is a real…

Is the purpose to use a faster machine for a particular compute job?

Re: Show HN: A simple Go utility to ease deployments via SSH and SCP

#10
post #7

Heh, I made a similar thing (mostly unreleased/undocumented at [0], original idea at [1]) that would take your Go code, build a binary wrapper for it using the target OS arch, SSH to the target, SCP the file over, run the binary, connect stdout/stderr/stdin with the remote, allow the remotely running binary to request files from the home binary, and delete itself once complete. One thing I found is SCP/SFTP is a real…

Is the purpose to use a faster machine for a particular compute job?

Nope, just to deploy to or configure a remote machine. So you write some Go code as though it's running locally that may run some apt commands, or may extract a tarball, or may setup a systemd script or whatever. Then the tool builds that binary and runs it on that remote machine (fetching resources lazily from the home computer such as the tarball you might need), then it deletes itself. I've used it for multiple server things that require more of an upgrade approach than a ephemeral container approach...I welcome anyone to take the idea and run with it.
Post reply on HN