alauda

5 ms·

1.
by alauda 9y ago
Check https://github.com/hyperhq/hykins
2.
by alauda 9y ago
It's an OSS, so guess the first step is to build the technology, then licensing.
3.
by alauda 9y ago
Video is here: https://www.youtube.com/watch?v=JCldsRNuGkc&feature=youtu.be
4.
by alauda 10y ago
Having a CLI doesn't mean they are close. In Google cloud, you still work with VMs, cluster, schedulers. In Hyper, you work only with Docker, everything is container native! Per-second is perfect for Serverless, Data mining, CI/C
5.
by alauda 10y ago
Why "low traffic sites"?
6.
by alauda 10y ago
The bigger sizes? Yes, but the small ones work pretty sweet. And the per-second billing!
7.
by alauda 10y ago
Had you tried hyper.sh? All you need is the compose file, no more terraform and ansible.
8.
by alauda 10y ago
Checkout https://github.com/jenkinsci/hyper-slaves-plugin . This plugin will launch your buildjobs as on-demand containers in Hyper.sh, then you don't even need the long-running huge VM!
9.
by alauda 10y ago
Guys, you really want to give a look to hyper.sh, if you are frustrated with running containers in production.
10.
by alauda 10y ago
Take a look at hyper.sh, if you are using docker.
11.
by alauda 10y ago
The idea of Swarm is the cluster works like one single virtual host. In that case, checkout hyper.sh. You don't care about the cluster thing at all in it, because their entire cloud works like one host.
12.
by alauda 10y ago
What do you mean "configure Docker"? Check out hyper.sh. They allow to launch a Docker image in ~3-5s, without the need to maintain a VM cluster. You can use an API service to automate the provisioning, and then forget about the i
13.
by alauda 10y ago
I don't think rkt is a valid candidate. People are already used to the basic of Docker command. There is no reason to change to something else. If rkt decides to reproduce the feature set, how is that different from a fork?