Tugboat: A command line client for DigitalOcean | Hacker News Reader

Tugboat: A command line client for DigitalOcean

github.com

91 pointspearkes15 comments

This looks like another great tool.

Like many people considering using DigitalOcean, I did some research over the weekend on "droplet" management. My results came up with the following resources (many already shared on hacker news):

1) Tugboat (today)

2) Fog - https://github.com/fog/fog - digital ocean support just recently added (https://github.com/fog/fog/pull/1525)

3) Vagrant DigitalOcean - https://github.com/smdahlen/vagrant-digitalocean

Both #2 and #3 are well established technologies that are allowing DigitalOcean plugins whereas TugBoat seems to be a specific tool for DigitalOcean.

Could someone with more extensive sysops experience comment on when/why you'd use one of these tools over another? (particularly relating to system provisioning options/interplay after droplet management...)

There is also a Knife plugin with Solo support: https://github.com/rmoriz/knife-digital_ocean

There's also dodo, another simple CLI client: https://github.com/adamw523/dodo

Awesome. Does DO not yet have a comprehensive command line tool?

I'm curious if any Hacker News readers have successfully migrated from Engineyard/Heroku to Digital Ocean. If so, I'd love to hear about your experiences. I am specifically curious about:

1) How complex/big was your Heroku/EY deployment 2) Time invested for migration 3) Stability since migration 4) Ongoing maintenance commitment 5) If you could turn back time and invest this investment elsewhere, would you?

I love Heroku, but I'm a bit concerned that we're becoming too interwoven/dependent on them. We currently have an issue with the stability of one of the Heroku 3rd-party redis tools timing out and feel a bit trapped... I would love to hear an analysis of others' migration experiences.

There was write-up from another customer who migrated from Heroku to DigitalOcean

http://matteodepalo.github.io/blog/2013/03/07/how-i-migrated...

This is very helpful from a technical angle. I'm interested in the full cost-benefit analysis. Any thoughts there?

I generally use Heroku for an alpha deployment, but then migrate to DigitalOcean for stable production deployment. I feel Heroku can get too expensive as the application scales up.

When you say "too expensive," I'm curious what you mean... Are you including time/labor in your cost-benefit analysis? For me, Heroku allows me to buy more engineering time (and less sys ops complexity) to devote to other problems. From this perspective, do you still consider DO cheaper? If so, at what ~number of dynos, does it become cheaper... (I realize this is an impossible number to pinpoint...)

I actually just finished my migration from Heroku to DO. I am using salt to manage the servers on DO and also setup zabbix for monitoring.

I have a draft blog post coming about zero downtime deploys that came from having to leave Heroku. So there is a plus side to it as well.

Very cool. It would be super useful if you could disable fuzzy matching, disable confirmations, and return proper exit codes like a standard CLI utility.

(author here)

Thank you. Yes, agree on all points. In the issue tracker.

Nice simple toolset. It's nice to see a script that knows what it is and does that well. Great name for the tool as well.

This is really great! However, I really wish it had support for allowing you to specify arbitrary droplet sizes and custom images without having to somehow look up the numeric ID of both.

I agree. I think that's an improvement that needs to be made on DO's side, though. I could certainly "map" them to human names on my side, but that's not going to be consistent, IMO.

I've sent them this feedback. :)

Simple Ruby onefile Digital Ocean CLI for ~/bin dir https://gist.github.com/shtirlic/5390788

Reply on news.ycombinator.com