5 ms·

Tugboat: A command line client for DigitalOcean

91 points by pearkes 13y ago

liquidise 13y ago
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.
dsl 13y ago
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.
- pearkes 13y ago
  (author here) Thank you. Yes, agree on all points. In the issue tracker.
freshfruit 13y ago
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.
- raiyu 13y ago
  There was write-up from another customer who migrated from Heroku to DigitalOcean http://matteodepalo.github.io/blog/2013/03/07/how-i-migrated-from-heroku-to-digital-ocean-with-chef-and-capistrano/ http://matteodepalo.github.io/blog/2013/03/07/how-i-migrated...
  - freshfruit 13y ago
    This is very helpful from a technical angle. I'm interested in the full cost-benefit analysis. Any thoughts there?
- slaxman 13y ago
  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.
  - freshfruit 13y ago
    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...)
- mathrawka 13y ago
  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.
kleinishere 13y ago
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 https://github.com/fog/fog - digital ocean support just recently added (https://github.com/fog/fog/pull/1525 https://github.com/fog/fog/pull/1525) 3) Vagrant DigitalOcean - https://github.com/smdahlen/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...)
- cwb71 13y ago
  There is also a Knife plugin with Solo support: https://github.com/rmoriz/knife-digital_ocean https://github.com/rmoriz/knife-digital_ocean
- gcr 13y ago
  There's also dodo, another simple CLI client: https://github.com/adamw523/dodo https://github.com/adamw523/dodo
Shtirlic 13y ago
Simple Ruby onefile Digital Ocean CLI for ~/bin dir https://gist.github.com/shtirlic/5390788 https://gist.github.com/shtirlic/5390788
gcr 13y ago
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.
- pearkes 13y ago
  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. :)

91 points by pearkes 13y ago

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.

dsl 13y ago

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.

pearkes 13y ago
(author here) Thank you. Yes, agree on all points. In the issue tracker.

freshfruit 13y ago

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.

raiyu 13y ago
There was write-up from another customer who migrated from Heroku to DigitalOcean http://matteodepalo.github.io/blog/2013/03/07/how-i-migrated-from-heroku-to-digital-ocean-with-chef-and-capistrano/ http://matteodepalo.github.io/blog/2013/03/07/how-i-migrated...
- freshfruit 13y ago
  This is very helpful from a technical angle. I'm interested in the full cost-benefit analysis. Any thoughts there?
slaxman 13y ago
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.
- freshfruit 13y ago
  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...)
mathrawka 13y ago
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.

kleinishere 13y ago

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 https://github.com/fog/fog - digital ocean support just recently added (https://github.com/fog/fog/pull/1525 https://github.com/fog/fog/pull/1525) 3) Vagrant DigitalOcean - https://github.com/smdahlen/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...)

cwb71 13y ago
There is also a Knife plugin with Solo support: https://github.com/rmoriz/knife-digital_ocean https://github.com/rmoriz/knife-digital_ocean
gcr 13y ago
There's also dodo, another simple CLI client: https://github.com/adamw523/dodo https://github.com/adamw523/dodo

Shtirlic 13y ago

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

gcr 13y ago

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.

pearkes 13y ago
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. :)