I agree this looks very cool. As far as http://deis.io/ is concerned, we're focused more on the "operate your own PaaS" capability, whereas this seems to be a pure hosted service -- which is great for lots of use cases.
"Docker-as-a-Service", simple, easy-to-understand pricing. Love it.
This is my favourite Docker offer so far. I've been looking for something to replace dotCloud's deprecated sandbox tier for just playing around, and it looks like this fits the bill.
The big point of Docker for me is that I can build the container on my machine, run automated tests on it, play with it and then ship it to the production machines when I'm confident that it is working.
If you build the container on a service like this testing it is hard or in some cases even impossible. For example acceptance tests with Selenium.
Gemfile.lock and similar version binding tools help, but prebuild containers bring the deployment stability to whole new level and is the reason why I'm exited about Docker and containers in general.
Sounds like you took the best parts of digital ocean and are trying to push it as a platform with docker baked in. I like. It seems like you're also trying to simplify using docker. I like even more.
I love the fact that you keep trying to define your own vocubulary 'Deck' etc, but always have to explain it. Best to stick with the more eaily understood term, rather than invent your own, I think.
Unless you're going to try and trademark them all.
I think that even if [deck drop instance] is clearer than [dockerfile image container] it would be better to use [dockerfile image container] it's the standard set forth from docker, sticking to the standard makes interoperating easier for everyone.
I'd have to agree that the standard Docker terminology would be much preferred. Your business covers what is a pretty cutting edge, advanced concept right now. Your customers are likely to be at least somewhat understanding of the standard terminology. Your custom terminology tripped me up as well, despite having a reasonable grasp of the higher level Docker terminology.
Other than that, this looks great! I'm excited for you guys.
I'm in a similar problem space to you. After a year of defining my own 'simpler' terminology, decided to abandon it in favour of being consistent with the more popular albeit complex terminology.
While I agree with your comment, I hope it isn't used as a measure or justification for doing so. I've had the same cognitive problem with Heroku as the parent describes.
God this drives my absolutely insane. Elvish marketing speak is such a stupid waste of time. Why can't we stick to commonly accepted terms instead of trying to bake up new "Cloud"esque replacement terms.
This looks awesome! I currently have an AWS box for the same purpose, running a few of my docker containers. Will this support the ADD directive, or the ability to add custom files (config files) into containers?
Great initiative! One thing to be aware is that Docker is using LXC for containers and LXC relies on kernel isolation and cgroup limits. The concern is about the vulnerabilities.
It is comforting that Heroku is also using LXC for dynos. Would be interesting to know how much in-house adjustments to the kernel and LXC has been made to ensure the hardening.
I work at ActiveState on Stackato, which is a private Platform as a service. Similar to Heroku, only for private hosting (e.g. you host it on your own hardware or hypervisor). We use Docker as of our v3 beta release today (http://beta.stackato.com/). Our use of docker in 3.0+ means that we bring their tuned security along with us (they integrate with apparmor really well, in fact they require it to start up a container). Here's a really good overview of LXC (and docker) security in general: http://blog.docker.io/2013/08/containers-docker-how-secure-a...
What would be even better is to decouple the idea of a drop from the containers running it. What I like about container approaches is having "machines" I can run them on. So let's say I make a "www" drop or several. I should then be able to fire up my containers into particular types of drops and have them started on those without having to think about the specifics. The benefit of this I'd that I only care about my container running and having some basic resource requirements and not so much the specific machine instance it is running on. I could even co-mingle different containers on types of "machines". Also separating out disk resources from CPU and ram would be good. Maybe you do this already buy it wasn't clear to me.
IMO Labels/tooltips should be added to the icons for the cards. Some of them, including the leaf (nodejs?) and the tree (nfi what that is) aren't especially obvious.
But if you host your site on your infrastructure, and it goes down, you can't post status updates to tell people what's going on/ when you will be back online.
Its quite reasonable to not host your own homepage or mechanism of updating your customers IMO.
I disagree. Your website should run on your own infrastructure and a separate status page, under a different (sub)-domain should be operated from another AS (autonomous system) e.g. statuspage.io or whatever you like/prefer.
Probably the differences are your Docker instances run on dedicated server instead, and you have all the setup and preparation and maintaince made for you.
I configured and launched a machine with redis and node in less than 5 minutes. Very cool.
How will you isolate instances from each other? My instance appears to have 24 GB of RAM and 12 cores, and it looks like I can use all of it in my instance.
You can limit Docker to have CPU weight shares, and also a memory limit. The file storage limits are due to Docker 0.7, and for now you can ulimit them.
I love this idea, and want to try it but I have no experience with Docker (on the todo list).
I wanted to spin up an instance of Sphinx Search but no idea how to go about doing it.
Maybe creating a set of tutorials will help with this. I can think of two advantages. The first being customers like myself will love it. Second, similar to Linode and their tutorials it will drives a lot of traffic and establishes your reputation as docker experts. Will probably build a lot of back-links too as people link to your tutorials.
Absolutely. Along similar lines, DigitalOcean has done a great job of encouraging the community to write tutorial and articles, and as a result there are tons of resources to get you started with all kinds of ways to use a VPS. Doing the same would be tremendously beneficial for Stackdock.
Hackernews traffic spike! You can signup and create a Dockerfile - we've just paused instance deployment for a couple of hours as we add more servers. Sorry for the inconvenience.
Looks cool. Here's what I'd love to see: built-in git deployment (ie. take a Dockerfile, build an image from it, and then after a push add the latest source code to /app and start new instances), and some kind of orchestration so you could run a number of app containers behind a load balancer container.
132 comments
[ 27.0 ms ] story [ 5606 ms ] threadBest of luck guys!
This is my favourite Docker offer so far. I've been looking for something to replace dotCloud's deprecated sandbox tier for just playing around, and it looks like this fits the bill.
If you build the container on a service like this testing it is hard or in some cases even impossible. For example acceptance tests with Selenium.
Gemfile.lock and similar version binding tools help, but prebuild containers bring the deployment stability to whole new level and is the reason why I'm exited about Docker and containers in general.
Do they support prebuild containers?
Sounds like a yes.
Unless you're going to try and trademark them all.
Feel free to innovate - you're a startup, and it's what we love about you.
Other than that, this looks great! I'm excited for you guys.
I hope that saves you some time.
The simplicity of the service is an opportunity to attract people without a lot of webdev chops, so why not make it super simple?
For rake/rails apps at least, you just run `heroku run 'command'` and you're done.
It is comforting that Heroku is also using LXC for dynos. Would be interesting to know how much in-house adjustments to the kernel and LXC has been made to ensure the hardening.
Otherwise, cool!
Does anyone know where DO servers are located?
From here: http://www.enterprisenetworkingplanet.com/datacenter/digital...
but a traceroute points to AWS…
If you offer infrastructure services and don't tell people where and how you provide it, you can't be serious, too.
What could possibly go wrong?
I configured and launched a machine with redis and node in less than 5 minutes. Very cool.
How will you isolate instances from each other? My instance appears to have 24 GB of RAM and 12 cores, and it looks like I can use all of it in my instance.
I wanted to spin up an instance of Sphinx Search but no idea how to go about doing it.
Maybe creating a set of tutorials will help with this. I can think of two advantages. The first being customers like myself will love it. Second, similar to Linode and their tutorials it will drives a lot of traffic and establishes your reputation as docker experts. Will probably build a lot of back-links too as people link to your tutorials.