Looks like you have to give your root password, which, no offense to Clever Collie, doesn't seem like a good idea. I'd prefer to see a shell script generator, or something like that.
I'm working on adding 'sudo' logic into the script, but that doesn't seem any less risky security wise.
Users are welcome to use something like whowatch or a tty spy to view the progress of the script. What you see in the browser is what is going is happening on the machine.
Users are also welcome to set their passwords to something temporary and then change them when the deployer is complete.
In the end though, the only thing I can offer to put user's minds at ease is my word that I don't store any of their login info.
For the more technically curious I'm not even using a database right now. I just log the job id, the ip address you requested, and whether or not an email was successfully sent to the one you provided. Login information is only held in memory until the bootstrapper successfully connects to the machine. After that its gone.
As for the automated shell script, as of now it would be incredibly tedious to replicate something like this using standard shell scripting (for me at least). I've thought about adding a "copy to clipboard" button above the terminal, that would copy all the executed commands in the textarea. This could be pasted into a script, but it would still need some interaction from the user.
This is all very good feedback and I'm open to anymore that would help improve the project and make a better overall user experience.
Cool! Can you say a little about how you are loading each instance with the chosen packages? For example, are you using Capistrano or Fabric to script the installs? Will you be offering contextualizing functionality, based on some sort of user data (ala EC2 user-data + script execution)? Anyways, nice project.
I've always found Slicehost and other DIY hosting solutions to be difficult to set up and work with. Which is why a solution like Heroku is so tempting (though various limitations have precluded my using it so far).
I'm excited about the potential for something like this.
This is great. I have already setup my couple-page-long capistrano scripts to setup my slices, but this would have definitely prevented me from needing to do that.
I'd also like to see a munin package install (with Rails-specific plugins). Does this use Passenger for Rails installation?
Interesting. I wrote a shell script a couple months ago for our slicehost servers - I can build a machine in about 5 mins with it. It basically does yum installs (centos) and rsync and starts some services. Ready to scale in a hurry if I need it and avoids needing backup for every slice.
If it just displayed the script that it generates instead of asking for password to run the script itself, it will be much simpler. OS installation is anyway just a single step with Slicehost webapp.
Not to take anything away from melito, because really, this is cool as beans, but what I _really_ want out of something like this is a place where I can set my configuration up with variables.
Better than booting a semi-configured server would be booting a fully-configured server. If I could host my app on sliceapp.com, along with changes from a base bootstrapped instance (e.g., apache settings, hostnames, etc) -- and be able to have multiple images to launch (one for db, one for apache/mod-python/django, one for load balancer) -- then this would be the best thing that ever happened, pretty much.
I have plans for that. I released the app, as is, to gauge how much interest there is in something like this.
The app originally started off as kind of a 'cloud management' console that would allow you to create multiple slices on the fly, have packages installed on them, and then have a central place to monitor their health and what was running.
The problem was, I was doing this all on my own.
By the time the original project reached a 'first draft', it was had become really complex and a pain to make progress on easily. The other downside was this complex project was tied to just one hosting provider. Integrating features and support for other platforms would have taken a great deal of work and increased the complexity of the app exponentially.
So I scratched everything and started off with something simple.
I figured at its essence I needed something that would connect to a machine and setup a bunch of software.
So I put together support for a limited number of packages and only one version of Ubuntu.
By doing so I was able to piece together something that is a lot easier for me to expand upon. A pseudo-framework. Something I'm comfortable working in and can change with little effort.
Future goals include:
Adding support for more software
Adding support for more operating systems
Testing against other hosting providers (this is a cloud!)
A management console
The management console will allow you to save 'recipes', so you can have a custom deploy package.
I also have the ability for making the system interactive (ie, a user is prompted for input via the web and their response is relayed to the server). This hasn't been tested as fully as I'd like, and doesn't serve much of a purpose at this point so I left it out of this release.
As for the architecture of the site, NONE of this was built using Capistrano, Vlad, or Fabric. I think all of those projects are great, but they are very cumbersome and don't allow for the flexibility that I get from what I currently have in place.
Judging by the interest this has stirred up over twitter and now Hacker News, I feel it'd be a good idea to move forward.
That being said, once I get a more fleshed out application in place, I plan on extracting the bits I'm using to bootstrap and releasing it as an open source tool for deployment.
[+] [-] superjared|16 years ago|reply
Full disclosure: I'm a developer at Slicehost.
[+] [-] melito|16 years ago|reply
I'm working on adding 'sudo' logic into the script, but that doesn't seem any less risky security wise.
Users are welcome to use something like whowatch or a tty spy to view the progress of the script. What you see in the browser is what is going is happening on the machine.
Users are also welcome to set their passwords to something temporary and then change them when the deployer is complete.
In the end though, the only thing I can offer to put user's minds at ease is my word that I don't store any of their login info.
For the more technically curious I'm not even using a database right now. I just log the job id, the ip address you requested, and whether or not an email was successfully sent to the one you provided. Login information is only held in memory until the bootstrapper successfully connects to the machine. After that its gone.
As for the automated shell script, as of now it would be incredibly tedious to replicate something like this using standard shell scripting (for me at least). I've thought about adding a "copy to clipboard" button above the terminal, that would copy all the executed commands in the textarea. This could be pasted into a script, but it would still need some interaction from the user.
This is all very good feedback and I'm open to anymore that would help improve the project and make a better overall user experience.
[+] [-] melito|16 years ago|reply
[+] [-] clemesha|16 years ago|reply
[+] [-] goodkarma|16 years ago|reply
I've always found Slicehost and other DIY hosting solutions to be difficult to set up and work with. Which is why a solution like Heroku is so tempting (though various limitations have precluded my using it so far).
I'm excited about the potential for something like this.
[+] [-] NoBSWebDesign|16 years ago|reply
I'd also like to see a munin package install (with Rails-specific plugins). Does this use Passenger for Rails installation?
[+] [-] rythie|16 years ago|reply
[+] [-] mindhacker|16 years ago|reply
[+] [-] kirubakaran|16 years ago|reply
[+] [-] dannyr|16 years ago|reply
[+] [-] zmimon|16 years ago|reply
[+] [-] woodsier|16 years ago|reply
[+] [-] bmelton|16 years ago|reply
Better than booting a semi-configured server would be booting a fully-configured server. If I could host my app on sliceapp.com, along with changes from a base bootstrapped instance (e.g., apache settings, hostnames, etc) -- and be able to have multiple images to launch (one for db, one for apache/mod-python/django, one for load balancer) -- then this would be the best thing that ever happened, pretty much.
[+] [-] melito|16 years ago|reply
The app originally started off as kind of a 'cloud management' console that would allow you to create multiple slices on the fly, have packages installed on them, and then have a central place to monitor their health and what was running.
The problem was, I was doing this all on my own.
By the time the original project reached a 'first draft', it was had become really complex and a pain to make progress on easily. The other downside was this complex project was tied to just one hosting provider. Integrating features and support for other platforms would have taken a great deal of work and increased the complexity of the app exponentially.
So I scratched everything and started off with something simple. I figured at its essence I needed something that would connect to a machine and setup a bunch of software.
So I put together support for a limited number of packages and only one version of Ubuntu.
By doing so I was able to piece together something that is a lot easier for me to expand upon. A pseudo-framework. Something I'm comfortable working in and can change with little effort.
Future goals include: Adding support for more software Adding support for more operating systems Testing against other hosting providers (this is a cloud!) A management console
The management console will allow you to save 'recipes', so you can have a custom deploy package.
I also have the ability for making the system interactive (ie, a user is prompted for input via the web and their response is relayed to the server). This hasn't been tested as fully as I'd like, and doesn't serve much of a purpose at this point so I left it out of this release.
As for the architecture of the site, NONE of this was built using Capistrano, Vlad, or Fabric. I think all of those projects are great, but they are very cumbersome and don't allow for the flexibility that I get from what I currently have in place.
Judging by the interest this has stirred up over twitter and now Hacker News, I feel it'd be a good idea to move forward.
That being said, once I get a more fleshed out application in place, I plan on extracting the bits I'm using to bootstrap and releasing it as an open source tool for deployment.