Founder here. Happy to answer any questions and take feature requests.
The API is scheduled to be released in June (only for paid plans).
Providing arguments/dynamic input when executing recipes is coming shortly.
The ability to create/destroy servers from within Commando.io is also in development.
Our mantra is simplicity and empowering everybody in a company to interact with servers via an easy to use web interface, this includes less technical employees such as support, marketing, and contractors. Others in the DevOps space are focused on ever increasing complexity and command line systems. Our approach is a beautiful web interface with no external dependencies (agents). Typical configuration management has a steep learning curve and requires expertise and upfront man hours. Going with Chef, Puppet, Ansible, require a large time investment, and companies have to send developers off to Chef school for two weeks to learn their systems. We don’t ask our users to go to school. They can signup and start managing servers instantly with their existing stack (bash, perl, python, ruby, go, or node.js).
This looks very nice. Is there any plan to add support for Ansible? Not sure I'm a fan of having bash scripts in the UI which are not available locally (is that the case?). I'd much rather have an Ansible repo in git that I develop locally and push to Commando.io.
No plan to support Ansible. However, being able to push/import scripts (we call them recipes) from git into Commando.io is a highly requested feature and on the roadmap. Also, just to clarify, we support recipes in bash, perl, python, ruby, go, or node.js.
That's unfortunate. I understand where you are coming from on making this absolutely as simple as possible for those who are maybe not so admin inclined, but I feel it's limiting to actual administrators/devops engineers, who are more than comfortable with traditional config management systems.
Personally as an administrator I want to be able to continue to use Ansible from the command line, but then grant access to my developers to a UI where they can easily spin up instances for temporary use.
That's just my use case. Otherwise, looks like a cool product. Good work.
Thanks. I agree it is a tricky balance. We want to empower everybody (especially less technical users) to interact with servers, yet be powerful enough for "neck beard" operations engineers. When in doubt, we always side with removing "power" features for simplicity. With that said, is creating recipes in a web interface and editor a deal killer for you?
Yes, I think it would be a deal breaker for me personally. For the one thing, there would be a bit of effort to migrate from any config management system (my background is Chef and Ansible) to straight bash scripts. Also, it doesn't allow for the modularity and reusability of scripts that these services grant you. In fact, if you really want to make this simple, adding support for config management as crucial. I can easily import a Chef cookbook, override a couple attributes and have a MySQL server up and running.
So ya, I think adding support for a config management system (my vote is Ansible) would make this 10x more useful.
it seems from the demo that the script is simply executed on the server. There's no reason you couldn't build a commando.io "recipe" that just wraps ansible-playbook, although you should also look at ansible tower which does basically the same thing.
We are working on Commando.io Enterprise, which is self-hosted and comes bundleded as a virtual appliance that runs on VMWare and VirtualBox just like GitHub enterprise. Send us an e-mail enterprise@ our domain to stay in the loop on it.
Looks like the smallest plan is $18/month for "12 servers and 5 users". I'd love to see a smaller plan for maybe up to 5 servers. This would be neat to quickly deploy servers for weekend projects etc.
Each account on Commando.io is sandboxed (dedicated database). They each have their own set of keys with a randomly generated passphrase on the private key which is then AES encrypted and stored in the database. We take security very seriously, read more aout our practices at: https://commando.io/security.html.
I'm probably misunderstanding, but how is storing a key with an encrypted passphrase different than storing an encrypted key? Shouldn't passphrases be entered by humans?
csshx is great but lacks the audit trail (output stored) we offer. Additionally with standard parallel ssh tools, you don't have centralized user access management, and cloud provider integrations.
Very cool, is there any ETA on parallel execution and background execution (ex: Currently, you have to stay on the page while the recipe executes.)
Additionally, it seems that the more servers you have, the more you pay per server. Our use case would be several sysadmins (less than 5 users) accessing 50+ servers, which would mean we'd be paying ~$3/server/mo, whereas on the lower plan it works out to literally half that, at ~$1.5/server/mo, is pricing already finalized?
Thanks. Parallel execution and background will come at the same time. It is the next highest task in the queue after the API is completed. Additionally execution output (both stdout stderr) will stream via websockets, so no more timeouts.
In regards to pricing, our philosophy is the more servers you add, the more value Commando.io provides. Additionally our lower tier plans are discounted heavily since those are catering to smaller organizations, usually running $5 or $10 a month servers on DigitalOcean. With that said, pricing is still being tweaked and tuned, so absolutely open to suggestions.
Have you thought about adding some features to the group management?
So one could add a new user and then just have checkboxes for all the available groups. This way you could create a user who acts as a DBA and then just give him access to all the servers in the group "DATABASE" without giving him access to all available servers. I'm not sure how feasible that is but I couldn't find anything in the FAQ or the group/users page.
Absolutely, group management in terms of users is something we didn't even think about when initially building Commando.io, however its become highly requested. The idea is, Commando.io becomes the source of truth for user access to servers. When you bring on additional employees or contractors simply add them into Commando.io and select which group of servers they can see and interact with. When the employee or contractor leaves, simply delete them from Commando.io. No more adding, removing keys into servers for each employee.
This looks awesome! I was just thinking of something like this the other day. Can't wait to try it. Any chance of being able to import from Linode in addition to DO, EC2, Rackspace, etc?
You may add Linode servers (we work with most any hosting provider), just you can't use the Linode API to automatically pull servers and details in like we do for DigitalOcean, AWS, and Rackspace.
We were just thinking about this. Currently we send e-mail notifications on each execution to all users in the account with general details. Hipchat/Slack notifications would be nice. We've created a GitHub issue in our internal tracker for this. Thanks.
Not to sound like too much of a jerk but why would someone use this over a real configuration management tool like Ansible, Chef, etc? I see a lot of issues with this:
1. I don't see any templating features
2. There is no idempotentcy
3. Unless you pay for enterprise you have to grant permissions to a cloud service to ssh directly into your nodes. This is a HUGE security issue. Sure I can whitelist your ip but what happens if you guys get hacked?
This doesn't seem all that much better than keeping my shell/python scripts in a git repo and then scp'ing them over to my hosts and executing them with ssh. Prior to proper configuration management tools this was how a lot of unix administration was done. This seems like a giant step backwards, except now I've got a pretty web ui to looks at and I have to grant ssh access over the internet to all my servers.
It looks really nice, but I don't think I could justify putting my keys into a third-party's hands. The focus on security is commendable, but at the end of the day, I'm responsible for the security of my company's infrastructure, and if something were to happen, telling the higher-ups that "yeah, we got 0wned because we gave root to a third party that we don't have any control over" is a fast way to be out of a job.
Leaving the keys to the kingdom in the hands of a third party who you can't directly audit or patch is an enormous liability.
43 comments
[ 6.4 ms ] story [ 102 ms ] threadJust fired up a beta instance as I am quite intrigued by your tool-set. looks very nice on first shine.
Getting some permission errors when trying to get ssh access to an Ubuntu 12.04 server. I'm in touch with y'all via your intercom dashboard.
Can you give me a use case as to when this would be better a better solution than say Chef or Salt?
Our mantra is simplicity and empowering everybody in a company to interact with servers via an easy to use web interface, this includes less technical employees such as support, marketing, and contractors. Others in the DevOps space are focused on ever increasing complexity and command line systems. Our approach is a beautiful web interface with no external dependencies (agents). Typical configuration management has a steep learning curve and requires expertise and upfront man hours. Going with Chef, Puppet, Ansible, require a large time investment, and companies have to send developers off to Chef school for two weeks to learn their systems. We don’t ask our users to go to school. They can signup and start managing servers instantly with their existing stack (bash, perl, python, ruby, go, or node.js).
Personally as an administrator I want to be able to continue to use Ansible from the command line, but then grant access to my developers to a UI where they can easily spin up instances for temporary use.
That's just my use case. Otherwise, looks like a cool product. Good work.
So ya, I think adding support for a config management system (my vote is Ansible) would make this 10x more useful.
Based on the video, can you run any shell/bash script you can think of? And does this have logging built in?
Don't want to invest the time until I know it is something that would match my budget. Is that detailed anywhere?
Looks like the smallest plan is $18/month for "12 servers and 5 users". I'd love to see a smaller plan for maybe up to 5 servers. This would be neat to quickly deploy servers for weekend projects etc.
Additionally, it seems that the more servers you have, the more you pay per server. Our use case would be several sysadmins (less than 5 users) accessing 50+ servers, which would mean we'd be paying ~$3/server/mo, whereas on the lower plan it works out to literally half that, at ~$1.5/server/mo, is pricing already finalized?
Thanks!
In regards to pricing, our philosophy is the more servers you add, the more value Commando.io provides. Additionally our lower tier plans are discounted heavily since those are catering to smaller organizations, usually running $5 or $10 a month servers on DigitalOcean. With that said, pricing is still being tweaked and tuned, so absolutely open to suggestions.
NVM - just saw it's MEAN stack based.
So one could add a new user and then just have checkboxes for all the available groups. This way you could create a user who acts as a DBA and then just give him access to all the servers in the group "DATABASE" without giving him access to all available servers. I'm not sure how feasible that is but I couldn't find anything in the FAQ or the group/users page.
I would like to see notifications for the following events:
1. When a recipe (script) is run on a server.
2. Any user administration updates. (Added user, removed user, etc.)
http://i.imgur.com/VEoGbqH.png
1. I don't see any templating features 2. There is no idempotentcy 3. Unless you pay for enterprise you have to grant permissions to a cloud service to ssh directly into your nodes. This is a HUGE security issue. Sure I can whitelist your ip but what happens if you guys get hacked?
This doesn't seem all that much better than keeping my shell/python scripts in a git repo and then scp'ing them over to my hosts and executing them with ssh. Prior to proper configuration management tools this was how a lot of unix administration was done. This seems like a giant step backwards, except now I've got a pretty web ui to looks at and I have to grant ssh access over the internet to all my servers.
I'm sorry but I just don't see the value in this.
It's command line, but you can set up groups of servers and execute commands against all of the machines in a group at once.
Leaving the keys to the kingdom in the hands of a third party who you can't directly audit or patch is an enormous liability.