Some helpful ways to save some cash?

flying-sausages commented 3 years ago

I'm basically testing a deployment of a toolbox which i give an env file to churn through, and an install can take around 20 minutes. However a lot is done so that the installer can fail as early as possible so that end-users don't have to wait for 20 minutes to learn that something can't work, obviously ha.

This means that within one hour, I could easily spin up a machine 10 times for a minute or two which I'll be billed 10 hours worth of VM time.

Do you have any tips on how to possibly re-use a machine within the one hour that Hetzner bills by, and only shut it down if there is no root SSH when the clock would be about to roll?

Thanks in advance for listening to this cheapskate trying to squeeze the most out of the 0.004c per spinpup lol

TimDaub commented 3 years ago

This means that within one hour, I could easily spin up a machine 10 times for a minute or two which I'll be billed 10 hours worth of VM time.

I just looked at my invoice for January and in fact, you're right. Hetzner is billing an instance at 0.004c/h. Slightly off topic but I'm wondering if they also have instances that are billed by e.g. minutes. I think it would immediately solve your problem, right?

Do you have any tips on how to possibly re-use a machine within the one hour that Hetzner bills by, and only shut it down if there is no root SSH when the clock would be about to roll?

You're making an interesting use case in my opinion. For projects that rely on spinning up Hetzner instances to e.g. run integration tests multiple times a day, it may make sense to keep the server online for 59 minutes and 59 seconds as new tests could get run on it. However, the GitHub Action doesn't support it right now.

What I imagine could work, however, is the following setup:

When a new Hetzner instance is spun up, store the creation time somewhere
Set delete-server: false
Somehow create a GitHub Action that uses the cron syntax to delete the server 59mins after creation
For each test that potentially creates a new Hetzner instance, check first if one exists already. If so, use it and reset the cron delete timer to 59mins again.

It's not a workflow that I need myself right now so I won't build it. But I'm happy to merge code that allows this type of workflow. What do you think?

TimDaub commented 3 years ago

@flying-sausages did #15 fix this issue?

flying-sausages commented 3 years ago

Not exactly, I'd like to make an implementation of the setup you describe above and share it here, and then I'll also try add it into a readme or maybe some other logical place.

TimDaub commented 3 years ago

Sounds good! Looking forward to seeing it!

flying-sausages commented 3 years ago

So I'm coming back to this, is there anything here from the clear actions that I could use to manually remove a machine if it is running? otherwise I'll be writing my own bash scripts or something ha

TimDaub commented 3 years ago

That function: https://github.com/TimDaub/hetzner-cloud-deploy-server-action/blob/main/lib.js#L91 allows you to delete a server. Does that help you?

TimDaub / hetzner-cloud-deploy-server-action

Some helpful ways to save some cash? #14