diff --git a/README.md b/README.md index 8f8f97a..99b9884 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ 1. create a .md file with a meaningful name in blog/source folder 2. write post in the .md file with the format which **same as other posts** -# Preview in local +# Preview on local 1. ./ink preview 2. open http://localhost:8000/ @@ -23,4 +23,9 @@ git push origin master # How to configure the post? -[http://www.inkpaper.io/blog/ink-blog-tool-en.html](http://www.inkpaper.io/blog/ink-blog-tool-en.html) +[https://github.com/InkProject/ink](https://github.com/InkProject/ink) + +# Troubleshoot + +`Invalid format`: Try to use double quotes to wrap the string which contained some special char. + diff --git a/blog/config.yml b/blog/config.yml index 564ac5f..2f9e20e 100755 --- a/blog/config.yml +++ b/blog/config.yml @@ -1,7 +1,7 @@ site: - title: HYPER_ - subtitle: Container-Native Cloud. - logo: -/images/logo-large.svg + title: Hyper.sh + subtitle: On-demand Container, Per-Second Billing + logo: https://www.hyper.sh/logo/logo_dark.svg limit: 10 theme: theme lang: en @@ -12,9 +12,9 @@ site: authors: hyper: - name: Hyper_ Crew - intro: Container-Native Cloud - avatar: -/images/logo.svg + name: The Hyper.sh Team + intro: On-demand Container, Per-Second Billing + avatar: https://www.hyper.sh/logo/logo_single_dark.svg xu: name: Xu Wang intro: Founder diff --git a/blog/source/2016-container-gif-competition.md b/blog/source/2016-container-gif-competition.md new file mode 100644 index 0000000..84792ae --- /dev/null +++ b/blog/source/2016-container-gif-competition.md @@ -0,0 +1,33 @@ +title: Hyper.sh 2016 Container GIF Competition! +date: 2016-11-09 16:30:00 +0800 +author: hyper +tags: + - Docker + - Container + - CaaS + - Hyper + - GIF + +preview: We're very pleased to announce the Hyper.sh 2016 container GIF competition! + +--- + +# Hyper 2016 Container GIF competition! + +Hello! + +We've all been through some successes and failures with containers. We know all of you have a lot of say, and we know all of you want to say it. So this is for you! + +We're very pleased to announce the [Hyper.sh 2016 Container GIF Competition!](https://gif.hyper.sh/) This competition is nothing but a bit of fun for all of us to share our container experiences; whether they be good or bad! + +![](http://i.giphy.com/l0ErPaz7aAN3s5aus.gif) + +To enter all you have to do is submit a container related GIF via the [competition website.](https://gif.hyper.sh/) and you'll have the chance to win one of three [GoPro Hero Sessions.](http://shop.gopro.com/EMEA/cameras/hero-session/CHDHS-102-master.html) + +![](https://cdn2.pcadvisor.co.uk/cmsdata/reviews/3642875/gopro-session-review_thumb800.jpg) + +The three submissions with the highest number of likes will win, and the winners will be announced on December 24th 2016. + +That's it. What are you waiting for? + +[https://gif.hyper.sh/](https://gif.hyper.sh/) diff --git a/blog/source/4-steps-to-deploy-a-containerized-cassandra-cluster-on-hyper.md b/blog/source/4-steps-to-deploy-a-containerized-cassandra-cluster-on-hyper.md index 8dcd9da..a5c5033 100644 --- a/blog/source/4-steps-to-deploy-a-containerized-cassandra-cluster-on-hyper.md +++ b/blog/source/4-steps-to-deploy-a-containerized-cassandra-cluster-on-hyper.md @@ -1,28 +1,28 @@ -title: "4 Steps to deploy a containerized Cassandra cluster on Hyper_" +title: "4 Steps to deploy a containerized Cassandra cluster on Hyper.sh" date: 2016-05-26 11:00:00 +0800 author: hyper -preview: Containers provide an amazingly smooth experience when distributing single applications but there is still significant overhead when deploying a multi-node container cluster. Hyper_ is a secure public container cloud, which leverages virtualized container technology to dramatically reduce the operation overhead when running containers in production. +preview: Containers provide an amazingly smooth experience when distributing single applications but there is still significant overhead when deploying a multi-node container cluster. Hyper.sh is a secure public container cloud, which leverages virtualized container technology to dramatically reduce the operation overhead when running containers in production. --- ### Intro -Containers provide an amazingly smooth experience when distributing single applications but there is still significant overhead when deploying a multi-node container cluster. [Hyper_](https://hyper.sh/) is a secure public container cloud, which leverages [virtualized container](http://hypercontainer.io/) technology to dramatically reduce the operation overhead when running containers in production. +Containers provide an amazingly smooth experience when distributing single applications but there is still significant overhead when deploying a multi-node container cluster. [Hyper.sh](https://hyper.sh/) is a secure public container cloud, which leverages [virtualized container](http://hypercontainer.io/) technology to dramatically reduce the operation overhead when running containers in production. In this tutorial, we will show how in 4 steps you can bring up: -- A five-node [Cassandra](http://cassandra.apache.org/) cluster in Hyper_DataStax OpsCenter 5.0.0 +- A five-node [Cassandra](http://cassandra.apache.org/) cluster in Hyper.shDataStax OpsCenter 5.0.0 - All the necessary wiring - Each node runs in its own container with the Cassandra process + DataStax Agent while OpsCenter runs in its own container separate from the cluster. ### Prerequisites Before beginning this tutorial please make sure you complete the following steps: -- [Open a Hyper_ account](https://console.hyper.sh/register) +- [Open a Hyper.sh account](https://console.hyper.sh/register) - [Generate API credential](https://docs.hyper.sh/GettingStarted/generate_api_credential.html) - [Setup `hyper` CLI on your local computer](https://docs.hyper.sh/GettingStarted/install.html) -### Step 1. Pull the Cassandra image to your Hyper_ account +### Step 1. Pull the Cassandra image to your Hyper.sh account ``` bash [root@localhost]$ hyper pull abh1nav/cassandra @@ -154,6 +154,6 @@ exit ``` -[Hyper_ ](https://hyper.sh/) is currently in public beta, you can sign up here: https://console.hyper.sh/register +[Hyper.sh ](https://hyper.sh/) is currently in public beta, you can sign up here: https://console.hyper.sh/register Questions? [contact@hyper.sh](mailto:contact@hyper.sh) diff --git a/blog/source/announcing-eu-region.md b/blog/source/announcing-eu-region.md new file mode 100644 index 0000000..46a79e8 --- /dev/null +++ b/blog/source/announcing-eu-region.md @@ -0,0 +1,30 @@ +title: Introducing Hyper.sh Frankfurt! +date: 2017-09-20 21:00:00 +0800 +update: 2017-09-20 21:00:00 +0800 +author: hyper +tags: + - Datacenter + - Europe + - Container + - Docker + - Containerization + +preview: Introducing Hyper.sh Frankfurt! + +--- + +We know you guys have been waiting for this for a loooong time. So, without further ado, today we are excited to announce our expansion into Europe with the opening of our Frankfurt region. + +The expansion is to accommodate the significant growth in our developer user base and requests from both EU and US based customers for a region in Europe to better serve them and their clients. + +The Frankfurt region will provide the same exceptionally easy to use, highly efficient, and incredibly cost effective container cloud service that our users know and love. As with all our services, we make selecting which region your containers are deployed to as simple as possible: add a tag to your Docker command and you're in a different region! Users will also be able to monitor their resources across multiple regions from the web console. + +The expansion into EU signifies a great milestone for us, and validates our approach in offering one of the most powerful and versatile yet simple Container-as-a-Service offerings in the market. + +We encourage you to learn more about the new region [here](https://docs.hyper.sh/Introduction/region.html). + +As always, Happy Hacking! + +The Hyper Crew + + diff --git a/blog/source/arm_and_hyper.md b/blog/source/arm_and_hyper.md new file mode 100644 index 0000000..5adf199 --- /dev/null +++ b/blog/source/arm_and_hyper.md @@ -0,0 +1,39 @@ +title: "ARM and Hyper Team to Bring Secure Container for IoT, Edge and 5G" +date: 2017-07-03 09:44:00 +0800 +author: hyper +tags: + - ARM + - Hyper + - Container + - IoT + - Edge +preview: ARM and Hyper announced a joint engineering effort in runV project, to bring secure container, for IoT, Edge and 5G. + +--- + +> Working to demonstrate benefits of runV technologies for container applications + +New York, July 03, 2017 - Today, Hyper (HyperHQ Inc.) announced through the [runV](https://github.com/hyperhq/runv) project plans to bring to bring multi-tenancy to container, for IoT, edge compute, and 5G. + +The momentum around containers is gaining traction as to package, distributed, and run applications increases. However, as containers share the host kernel, they are not considered as secure as virtual machines (VM) in a multi-tenant environment. To address this problem, a new open-source project, [runV](https://github.com/hyperhq/runv), has been created by Hyper and will feature hypervisor-based runtimes that are equivalent to the already available [runC](https://runc.io/). runV leverages typical hypervisor technology (KVM, Xen, etc.) to launch container images, instead of Linux Container (Cgroup, Namespace). + +runV will be able to launch a Docker (or OCI) image into a micro VM in 100ms, and still keeps the hardware-enforced isolation in traditional virtualization. The unique combination of virtualization and containerization allows runV to bring the best of both worlds: + +| - | Container| VM | Hyper | +|---|---|---|---| +| Isolation | Weak, shared kernel | Strong, HW-enforced | Strong, HW-enforced | +| Portable | Yes | No, hypervisor dependent | Yes, hypervisor agnostic and portable image | +| Boot | Fast, sub-second | Slow, tens of seconds | Fast, sub-second | +| Performance | Great | OK| Good, minimal resource footprint and overhead | +| Density (instance) | 10k+ | ~500 | ~5k | +| Immutable | Yes, cattle | No, pet | Yes, cattle | +| Image Size| Small, MBs | Big, GBs | Small, MBs | +| Heterogeneous Workload | No, kernel depency | Yes | Yes, Linux/Windows, BYOK | +| Device Emulationb | No | Yes | Yes | + +Currently, runV has preliminary support on ARM servers, however with container multi-tenancy developers can expect to see performance optimizations and density improvements. In working together on the runV project, Hyper and ARM aim to demonstrate the benefits of runV and how well suited it is to ARM-based platforms for the next generation of IoT, 5G, and edge computing. + +## About Hyper + +Hyper (HyperHQ Inc.) builds innovative, open source technology that makes it easy to deploy and manage secure containers in multi-tenant environment. We enable organizations to accelerate all aspects of their software pipeline with container-native public infrastructure. + diff --git a/blog/source/close_hyper_sh.md b/blog/source/close_hyper_sh.md new file mode 100644 index 0000000..4aa5ba4 --- /dev/null +++ b/blog/source/close_hyper_sh.md @@ -0,0 +1,22 @@ +title: "Farewell from Hyper Crew" +date: 2019-01-16 13:00:00 +0800 +author: Hyper Crew +tags: + - Hyper +preview: As of Jan 16, 2019, we have officially shut down the Hyper.sh platform. + +--- + +As of Jan 16, 2019, we have officially shut down the Hyper.sh platform. + +Over three years ago, we set out to create an open secure container-native platform. We believed that containers represented a sea change in how software would be developed, deployed, and maintained. + +Along the way, we created one of the first container-native cloud offerings, the [Hyper.sh](http://hyper.sh/) platform, which utilized our open source technology, called runV, which last year was merged with Intel’s Clear Containers project to become [Kata Containers](http://www.katacontainers.io/). We’re proud of the platform we built, and the influence we have had on the overall container industry. We are even more grateful to you, our customers, who have deployed hundreds of thousands of containers and built out new businesses on our platform. + +The [Hyper.sh](http://hyper.sh/) platform, while trailblazing, is not where Hyper’s future efforts lie. Moving forward, Hyper is focusing all our attention and efforts towards the upstream Kata Containers project. + +Thank you for your business and support of our platform. It has been a privilege to serve you. + +Sincerely, + +The Hyper Crew diff --git a/blog/source/cloud-release-june-2017.md b/blog/source/cloud-release-june-2017.md new file mode 100755 index 0000000..6347509 --- /dev/null +++ b/blog/source/cloud-release-june-2017.md @@ -0,0 +1,46 @@ +title: "New Hyper.sh Features: June 2017" +date: 2017-06-09 17:00:00 +0800 +author: Hyper Crew +tags: + - Docker + - Local Load + - Invoicing + - Hyper +preview: Two new heavily requested features are out today! + +--- + +# Two heavily requested features released + +## Load local images onto Hyper.sh + +A lot of users have been asking about how they can 'pull' images from their local machine directly to Hyper.sh. + +To solve this issue we have extended the functionality of ```hyper load``` so you can now load from STDIN, a local tar or a local image. + +**Load image from STDIN: (similar with push, only upload the diff)** + +```$ cat helloworld.tar | hyper load``` + + +**Load image from local tar archive file: (similar with push, only upload the diff)** + + +```$ hyper load -i helloworld.tar``` + +**Load a local image: (similar with push, only upload the diff)** + +```$ hyper load -l helloworld:latest``` + + +Check the full docs here: [https://docs.hyper.sh/Reference/CLI/load.html](https://docs.hyper.sh/Reference/CLI/load.html) + +## Print view for invoices + +Slightly less spectacular but still very important, many users wanted a specific print view for invoices, so we made one. :-) + +Check it out in the console: [https://console.hyper.sh/](https://console.hyper.sh/) + +As always, Happy Hacking! + +The Hyper Crew diff --git a/blog/source/deploy-a-private-shadowsocks-container-in-3-steps.md b/blog/source/deploy-a-private-shadowsocks-container-in-3-steps.md index a2f7552..b21dbf8 100644 --- a/blog/source/deploy-a-private-shadowsocks-container-in-3-steps.md +++ b/blog/source/deploy-a-private-shadowsocks-container-in-3-steps.md @@ -19,11 +19,11 @@ In this tutorial we will explain in detail how to deploy a private shadowsocks c # Prerequisites Please make sure you complete the following prerequisites: -- [Open a Hyper_ account](https://console.hyper.sh/register) +- [Open a Hyper.sh account](https://console.hyper.sh/register) - [Generate API credential](https://docs.hyper.sh/GettingStarted/generate_api_credential.html) - [Setup `hyper` CLI on your local computer](https://docs.hyper.sh/GettingStarted/install.html) -### Step 1. Pull the shadowsocks image to your Hyper_ account +### Step 1. Pull the shadowsocks image to your Hyper.sh account Open the terminal on your local computer: @@ -44,7 +44,7 @@ Status: Image is up to date for oddrationale/docker-shadowsocks:latest ### Step 2. Launch the container ``` bash -$ hyper run -d --name shadowsocks oddrationale/docker-shadowsocks -s 0.0.0.0 -p 1989 -k MyPassWord -m aes-256-cfb +$ hyper run -d --name shadowsocks -p 1989 oddrationale/docker-shadowsocks -s 0.0.0.0 -p 1989 -k MyPassWord -m aes-256-cfb b6cae93b056ddb123dcb754e785c557bee9b080e4a3a4731f3e1cd97798fe058 ``` @@ -57,12 +57,12 @@ b6cae93b056d oddrationale/docker-shadowsocks "/usr/local/bin/ssser" 2 ``` -### Step 3. Associate Floating IP +### Step 3. Attach Floating IP ``` bash $ hyper fip allocate 1 162.221.195.201 -$ hyper fip associate 162.221.195.201 shadowsocks +$ hyper fip attach 162.221.195.201 shadowsocks $ ``` diff --git a/blog/source/highlevel_overview.md b/blog/source/highlevel_overview.md new file mode 100755 index 0000000..29c61c6 --- /dev/null +++ b/blog/source/highlevel_overview.md @@ -0,0 +1,21 @@ +title: "Hyper High Level Overview" +date: 2016-10-28 18:00:00 +0100 +author: hyper +tags: + - Docker + - Containers + - Meetup + - Hyper +preview: Some users asked us if we had standard Hyper slides available to help them with their meetup talks. We didn't, but now we do and we've created a video to go along with the slides too. + +--- + +Some users asked us if we had standard Hyper slides available to help them with their meetup talks. We didn't but now we do and we've created a video to go along with the slides too. (Full screen + 1080p recommended for the demos) + +Google Sheets link [here](https://docs.google.com/presentation/d/1nrfEcCITAofSDPFTIkiASLa4UvmCOUmgPE6ayFZBR0c/edit?usp=sharing) and PDF [here.](images/hyper_highlevel_overview.pdf) + + + +Happy Halloween! + +The Hyper.sh Crew diff --git a/blog/source/how-to-run-stateful-container-in-hyper-container-cloud.md b/blog/source/how-to-run-stateful-container-in-hyper-container-cloud.md index 80755a7..c91a52d 100644 --- a/blog/source/how-to-run-stateful-container-in-hyper-container-cloud.md +++ b/blog/source/how-to-run-stateful-container-in-hyper-container-cloud.md @@ -1,21 +1,21 @@ -title: How to run stateful container in Hyper_ container cloud? +title: How to run stateful container in Hyper.sh container cloud? date: 2016-04-27 00:00:00 author: hyper -preview: Hyper_ is a secure container cloud service. It allows you to deploy your containers in seconds, directly without hosting VMs to an infinite cloud, straight from your laptop. +preview: Hyper.sh is a secure container cloud service. It allows you to deploy your containers in seconds, directly without hosting VMs to an infinite cloud, straight from your laptop. --- -[Hyper_](https://www.hyper.sh/) is a secure container cloud service. It allows you to deploy your containers in seconds, directly without hosting VMs to an infinite cloud, straight from your laptop. +[Hyper.sh](https://www.hyper.sh/) is a secure container cloud service. It allows you to deploy your containers in seconds, directly without hosting VMs to an infinite cloud, straight from your laptop. -Hyper_ also provides persistent volume service, which can been seen as "**The container-version of AWS EBS**". You can: +Hyper.sh also provides persistent volume service, which can been seen as "**The container-version of AWS EBS**". You can: - hyper run -v to launch a container with additional volumes - failover the volumes to a new container - create snapshots from volumes for data backup - restore snapshots to new volume -The following is an example to use Hyper_'s volume feature with a Rocket.chat app. +The following is an example to use Hyper.sh's volume feature with a Rocket.chat app. ### Pull the images @@ -84,12 +84,12 @@ CONTAINER ID IMAGE COMMAND CREATED a03bddd9770e mongo "/entrypoint.sh mongo" Up 2 minutes Up 5 seconds 0.0.0.0:27017->27017/tcp db ``` -### Associate Floating IP to Rocket.chat container +### Attach Floating IP to Rocket.chat container ``` shell [root@localhost ~]# hyper fip allocate 1 162.221.195.91 -[root@localhost ~]# hyper fip associate 162.221.195.91 app +[root@localhost ~]# hyper fip attach 162.221.195.91 app [root@localhost ~]# ``` diff --git a/blog/source/hyper-best-value.md b/blog/source/hyper-best-value.md new file mode 100755 index 0000000..800a024 --- /dev/null +++ b/blog/source/hyper-best-value.md @@ -0,0 +1,108 @@ +title: "Guest Blog Post: Hyper.sh comes out best value in Cloud Computing Shootout" +date: 2017-05-17 17:00:00 +0200 +author: Andy Chase +tags: + - Docker + - Value + - Container + - Hyper +preview: One of my professors at my alma mater thought that Amazon's or Google's container service would run fastest (and be the best value) because they use container technology. Why didn't that turn out to be true? + +--- + +*This is a guest blog post by Andy Chase. Contact details below* + + + +The chart above is a box plot showing cloud providers and how well they performed when scaled by cost per hour. *Hyper.sh turned out the best!* (It's lowest on the chart because it's the cheapest essentially). + +Figuring out how much using the cloud costs is not simple. As a project I wanted to look at different Cloud Providers and independently measure the performance of running several different test programs to see which one performs the best. + +**Hypothesis:** One of my professors at my alma mater thought that Amazon's or Google's container service would run fastest (and be the best value) because they use container technology. Why didn't that turn out to be true? +Who am I? + +My name is Andy Chase and I'm a freelance programmer working on building and advising startups to make the world a better place. + +My website: [https://andychase.me/](https://andychase.me/) + +Github: [https://github.com/andychase](https://github.com/andychase) + +Upwork: [https://www.upwork.com/freelancers/~01dbdbcc5a2c375fda](https://www.upwork.com/freelancers/~01dbdbcc5a2c375fda) + +# What is Hyper.sh? + +Basically Hyper.sh is a cloud provider - they have a warehouse of computers and they rent them out cheap. No matter who you are, it's always great when you can use someone else's warehouse instead of buying your own. + +Hyper.sh sets themselves apart from their huge competitors by being focused completely on containers. If you know how to use docker on your local machine then you already know how to use Hyper.sh. + +## So why aren't AWS-Container and GCE faster since they also use containers? + +My professor figured the cloud providers that use containers should be faster because containers split computing resources using the Kernel so there's no virtualization overhead. In reality, I found out that AWS and GCE run their container engines on top of a virtualized kernel so there's no real performance benefit there. + +It might be confusing but containers are really used more for convenience than as a performance tool. + +Hyper.sh is an exception here since they blur the lines between containerisation and virtualisation by using an optimized stack and they did end up being the best value (barely). So my professor was right after all in a way. + +Venn diagram for fun: + +![Virtualization vs Containerization Venn Diagram](./images/best-value-venn-diagram.png) + +## More details about that performance chart above + +### The tests I ran + +I set up a script to run and time a bunch of different programs: + +* [ffmpeg](https://ffmpeg.org/) -- time to decode/encode 30 seconds of a media file +* [sorting](https://en.wikipedia.org/wiki/Sort_(Unix)) -- time to sort the lines of a ~100mb book, “War and Peace” 32 times +* [sysbench](https://github.com/akopytov/sysbench)/cpu -- time to calculate all prime numbers up to 20,000 +* sysbench/memory -- time to run memory mutex benchmark on sysbench +* sha256sum -- time to hash ~100mb book, “War and Peace” 32 times +* [nginx](https://www.nginx.com/) -- time to process 10,000 static http requests + +I ran the tests on [Amazon Web Services](https://aws.amazon.com/) micro, medium, and large instances, [Google Container Engine](https://cloud.google.com/container-engine/), [DigitalOcean](https://www.digitalocean.com/), [Hyper.sh](https://hyper.sh/), and a few runs locally on my machine. + +Then I left the scripts running for a few days and came back to see the results! + +![Number of trials](./images/best-value-results-graph.png) + +![Individual Results](./images/best-value-individual.png) + +After that I scaled the costs according to this handy table: + +| Cloud Provider | Cost per hour | +|---|---| +| digital-ocean-512m | $0.0070 | +| hyper-sh-s4 | $0.0072 | +| aws-container-micro | $0.0120 | +| aws-ec2-micro | $0.0120 | +| aws-ec2-medium | $0.0470 | +| gce-1vcpu | $0.0475 | +| macbook-native | $0.0494 | +| macbook-vm | $0.0494 | + +Here are the overall averages split up by the actual test. I used [Student's T](https://en.wikipedia.org/wiki/Normalization_(statistics)#Examples) score normalization so the different tests could be compared. + + + +More charts can be found in my [project's slideshow.](https://docs.google.com/presentation/d/1pUvdRFIY5TF_1sXisPqB0K3vdHwVgmtk5HmMS70_X5c/edit?usp=sharing) + +# Conclusion: Does any of this really matter? + +The first chart shows how actually very close all cloud service providers are in terms of value. A few standard deviations of performance will probably not make or break your project or business. + +The real cost of cloud computing is staffing costs. Cloud providers can either save you a lot of time or cost you dearly if setting one up becomes too complex and things keeps breaking. + +If your organization lives and breathes containers, Hyper.sh does stand out as a provider that focuses purely around that paradigm and ends up being a good value. But what if you need specialized services like managed databases, managed dns, managed email, etc? In that case would need to look at combining Hyper.sh with other mananged services. (**NOTE: Be on the look out for said services coming soon!**) + +## More Information & Acknowledgements + +Thanks to Brian James ([hensonb@oregonstate.edu](mailto:hensonb@oregonstate.edu)) and Samuel Jacobs ([jacobssa@oregonstate.edu](mailto:jacobssa@oregonstate.edu)) for their contributions to the project. The project was completed for ECE/CS 476 Winter 2017 taught by Dr. Bechir Hamdaoui ([hamdaoui@eecs.oregonstate.edu](mailto:hamdaoui@eecs.oregonstate.edu)). + +Project Slideshow here: [ECE/CS 476 Project Presentation](https://docs.google.com/presentation/d/1pUvdRFIY5TF_1sXisPqB0K3vdHwVgmtk5HmMS70_X5c/edit) + +Project Report here: [ECE/CS 476 Project Report](https://drive.google.com/file/d/0B6FTBa9iYPrnd1FHelVZc3UzbndwVTBNeFRlS3BydFBuUjJZ/view) + +Data here: [ECE/CS 476 Project Data](https://docs.google.com/spreadsheets/d/1HliNBW7mMWA8q1zb4pXa_PtbftxHv2PAo31puax4pm4/edit?usp=sharing) + +R Script: [ECE/CS 476 Project R Script](https://gist.github.com/andychase/8d64812b75fa1489eccc34edd9cf6a73) diff --git a/blog/source/hyper-commit.md b/blog/source/hyper-commit.md new file mode 100644 index 0000000..4d03cb0 --- /dev/null +++ b/blog/source/hyper-commit.md @@ -0,0 +1,56 @@ +title: "Hyper commit/push, Hyper Func Sync mode, and more!" +date: 2017-05-16 21:40:00 +0800 +author: hyper +tags: + - Container + - Image + - Hyper.sh + - Commit +preview: Here comes our latest upgrade on Hyper.sh! + +--- +Here comes our latest upgrade on Hyper.sh! + +### Hyper Commit / Push +In many cases, our users told us that they want to `commit` a container to create a new image (version) and `push` it back to the registry, so here it is! + +``` +$ hyper commit --change "ENV DEBUG true" 50d6ab76a13a user/testimage:v1 +sha256:8a0cb365e21b94328e0fe8727ff347051e8bc0292fa8c5d1450a9b1d272bbaa4 +$ hyper inspect -f "{{ .Config.Env }}" 8a0cb365e21b +[DEBUG=true PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] +$ hyper images +REPOSITORY TAG IMAGE ID CREATED SIZE +user/testimage v1 8a0cb365e21b 30 seconds ago 1.126 MB +$ hyper push user/testimage:v1 +``` +Please check out the documentation here for more information: +- [hyper commit](https://docs.hyper.sh/Reference/CLI/commit.html) +- [hyper push](https://docs.hyper.sh/Reference/CLI/push.html) + +If you have any feedback, no matter how small, we'd love to hear from you! + +### Hyper Func Sync Call +We also make an enhancement [***Hyper Func***](https://docs.hyper.sh/Feature/container/func.html) by adding the `--sync` flag to block the API until the function call completes (or failed). + +``` +$ hyper func create --name helloworld ubuntu echo HelloWorld +helloworld is created with the address of https://us-west-1.hyperfunc.io/call/helloworld/e62c014e-386c-42ea-8d07-41d44e98cc3d +$ hyper func call --sync helloworld +Hello World +``` + +Please check out the documentation here for more information: +- [hyper func call](https://docs.hyper.sh/Reference/CLI/Func/call.html) + + +### API Credential Name +Now, you can name your API crendentials in the web console. + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/591a8497b174282efb28b815/409ce1b5d8ab7e90620cb73882408d9e/upload_5_16_2017_at_12_48_20_PM.png) + +---------------------------------------------- +That's it for now, and as always, happy hacking! +The Hyper.sh Crew + +[Twitter](https://twitter.com/hyper_sh), [Slack](https://slack.hyper.sh/), [Forum](https://forum.hyper.sh/), [Mail](mailto:talk@hyper.sh) diff --git a/blog/source/hyper-cron-beta.md b/blog/source/hyper-cron-beta.md new file mode 100755 index 0000000..b784548 --- /dev/null +++ b/blog/source/hyper-cron-beta.md @@ -0,0 +1,66 @@ +title: "Hyper Cron (Beta) Release" +date: 2016-11-23 21:40:00 +0800 +author: hyper +tags: + - Docker + - Container + - Cron + - Hyper.sh + - Serverless +preview: We are happy to announce the beta release of Hyper.sh Cron functionality. There was a lot of interest in Hyper Cron from the community and we're looking forward to getting feedback to keep improving the implementation. + +--- + +Today we are happy to announce the beta release of Hyper.sh Cron functionality. There has been a lot of interest in Hyper Cron from the community and we're looking forward to getting feedback to continue improving the implementation. + +## How does it work? + +As you would expect Hyper Cron is a system service that runs scheduled jobs at given intervals or times, just like the cron unix service. + +With Hyper Cron however, you can run any command in a container at given intervals or times and you only pay (per second!) when the cron job is running, just as with any other container on Hyper.sh. + +Some members of the community have been calling this **'Serverless Cron'**. The full documentation is linked below, but first let's look at some examples: + +### Create a cron job which will ping an address every 5 minutes: + +``` +$hyper cron create --minute=*/5 --hour=* --name test-cron-job1 busybox ping -c 3 8.8.8.8 +``` + +### Check cron job list: +``` +$ hyper cron ls +Name Schedule Image Command +test-cron-job1 */5 * * * * busybox ping -c 3 8.8.8.8 +``` + +### Check cron job execution history: +``` +$ hyper cron history test-cron-job1 +Container Start End Status Message +test-cron-job1-1479265800 2016-11-16 03:10:00 +0000 UTC 2016-11-16 03:11:24 +0000 UTC done Job[test-cron-job1] is success to run +test-cron-job1-1479266100 2016-11-16 03:15:00 +0000 UTC 2016-11-16 03:15:25 +0000 UTC done Job[test-cron-job1] is success to run +test-cron-job1-1479266400 2016-11-16 03:20:00 +0000 UTC 2016-11-16 03:20:25 +0000 UTC done Job[test-cron-job1] is success to run +test-cron-job1-1479266700 2016-11-16 03:25:00 +0000 UTC 2016-11-16 03:25:25 +0000 UTC done Job[test-cron-job1] is success to run +test-cron-job1-1479267000 2016-11-16 03:30:00 +0000 UTC - - Job[test-cron-job1] is running at 2016-11-16 03:30:00 +0000 UTC +``` + +### Remove a cron job: +``` +$ hyper cron rm test-cron-job1 +test-cron-job1 +``` + +### Documentation + +You can also specify an email for each cron job to receive live status updates. All of the above and more is covered in the documentation [here](https://docs.hyper.sh/Feature/container/cron.html). + +### Feedback + +We're releasing Hyper Cron as Beta specifically to garner feedback from the community on how this feature should grow. If you have any feedback, you can contact us in any of the following ways. + +[Twitter](https://twitter.com/hyper_sh), [Slack](https://slack.hyper.sh/), [Forum](https://forum.hyper.sh/), [Mail](mailto:talk@hyper.sh) + +Happy Hacking! + +The Hyper.sh Crew diff --git a/blog/source/hyper-is-generally-available.md b/blog/source/hyper-is-generally-available.md new file mode 100755 index 0000000..bb27e57 --- /dev/null +++ b/blog/source/hyper-is-generally-available.md @@ -0,0 +1,59 @@ +title: "Hyper.sh now generally available with incredible new features!" +date: 2016-08-15 22:45:00 +0800 +author: hyper +tags: + - Docker + - Container + - Container-native cloud + - Hyper +preview: Docker is a revolutionary idea. Being application-centric, it disrupts our imagination of IT infrastructure, and Hyper.sh is started with the idea of container-native cloud. Now, we are now very happy to announce that Hyper.sh has come out of beta and is now generally available! + +--- + +Hi, + +First of all, we'd like to thank all our beta users for taking part in the Hyper.sh public beta. Over the past few months, we have received tremendous feedback from you, and we are really grateful! + +Docker is a revolutionary idea. Being application-centric, it disrupts our imagination of IT infrastructure, and Hyper.sh is started with the idea of container-native cloud. Now, we are now very happy to announce that Hyper.sh has come out of beta and is now generally available! + +Below are the incredible new features that we’ve been working on. + +### Port Mapping + +You can now specify which ports your containers should expose to the outside world. + +[Roadmap](https://trello.com/c/2k99dJW1/1-port-mapping), [Documentation](https://docs.hyper.sh/Reference/CLI/run.html) + +### Compose + +Deploy your Docker compose files in Hyper.sh! + +[Roadmap](https://trello.com/c/tLlnMaP6/19-hyper-compose), [Documentation](https://docs.hyper.sh/Feature/compose.html) + +### Container Preload + +Preload data from your local machine or remote git repository to running containers in Hyper.sh. + +[Roadmap](https://trello.com/c/nrSxLzRC/20-copy-data-to-volume), [Documentation](https://docs.hyper.sh/Feature/volume.html) + +### 64MB Container Size + +Combine the new 64MB container size with our per-second billing to open up entirely new possibilities for your applications! + +[Roadmap](https://trello.com/c/J9InK02A/22-nano-container-size), [Documentation](https://docs.hyper.sh/FAQ/pricing.html) + +### Load Docker Images from archive file (on S3) + +If you prefer not to use the Docker Hub, you can now load from archive files. + +[Roadmap](https://trello.com/c/vkbtPCKS/18-hyper-load-s3), [Documentation](https://docs.hyper.sh/Reference/CLI/load.html) + +--------------------- + +We’d like to thank our beta users for the continuing support and we hope that you will enjoy these new features in the new Hyper.sh. It is our mission to make running containers in production effortless. + +Please stay tuned on Twitter as we continue to add more exciting features and if you have any questions you can always contact us through the Hyper.sh console, Hyper.sh forum, or on support@hyper.sh. + +Thanks, + +The Hyper.sh Crew diff --git a/blog/source/hyper-logs.md b/blog/source/hyper-logs.md new file mode 100644 index 0000000..a0e4e1d --- /dev/null +++ b/blog/source/hyper-logs.md @@ -0,0 +1,23 @@ +title: "Improved Container Log" +date: 2016-12-12 23:00:00 +0800 +author: hyper +tags: + - Docker + - Container + - Log + - Hyper.sh +preview: We are excited today to release the new version of container log feature. + +--- + +Hi All, + +We are excited today to release the new version of container log feature. + +In the improved feature, every container includes 50MB of free log space (with rotation). The logs are persistent through the container's lifespan. You can access the log messages at anytime with the `hyper logs` (or `logs` API) commands, except if the container had previously been removed. Also, if the container has been restarted (or stop/start), the previous logs will still be available, but with the new log messages appended. + +We hope the new improvements will help you in troubleshooting and debugging. Also, we are planning to add support for third-party logging systems, allowing you to forward your logs to an external service. Please stay tuned! + +Enjoy, + +The Hyper.sh Crew diff --git a/blog/source/hyper-use-case-week-part-1-web-app-with-a-database.md b/blog/source/hyper-use-case-week-part-1-web-app-with-a-database.md index 4c27edf..85241c1 100644 --- a/blog/source/hyper-use-case-week-part-1-web-app-with-a-database.md +++ b/blog/source/hyper-use-case-week-part-1-web-app-with-a-database.md @@ -1,11 +1,11 @@ title: "Hyper Use Case Week - Part 1: Web app with a database" date: 2016-05-03 20:00:00 +0800 author: hyper -preview: The Hyper_ public beta opened it arms to the world on April 4th 2016. The thing about public betas is that you really want to know what your users are doing on the platform. We see all sorts of actions occurring, but the patterns take a while to emerge. Now, a month into the public beta we've decided to share some of the most common patterns as part of Hyper Use Case Week. +preview: The Hyper.sh public beta opened it arms to the world on April 4th 2016. The thing about public betas is that you really want to know what your users are doing on the platform. We see all sorts of actions occurring, but the patterns take a while to emerge. Now, a month into the public beta we've decided to share some of the most common patterns as part of Hyper Use Case Week. --- -The [Hyper_ public beta](https://console.hyper.sh/register) opened it arms to the world on April 4th 2016. +The [Hyper.sh public beta](https://console.hyper.sh/register) opened it arms to the world on April 4th 2016. The thing about public betas is that you really want to know what your users are doing on the platform. We see all sorts of actions occurring, but the patterns take a while to emerge. Now, a month into the public beta we've decided to share some of the most common patterns as part of Hyper Use Case Week. @@ -19,18 +19,18 @@ The bread and butter of web development. Deploy your web app, attach it to a dat #### How do I do it? -It's not rocket science but registered Hyper_ users are achieving this deployment in under 10 seconds! Here's how: +It's not rocket science but registered Hyper.sh users are achieving this deployment in under 10 seconds! Here's how: ``` shell hyper run -d --name db hyperhq/postgres hyper run -d --name web --link db hyperhq/webapp python app.py FIP=$(hyper fip allocate 1) -hyper fip associate $FIP web +hyper fip attach $FIP web curl $FIP:80 > Hello: linked database is "tcp://" ``` -Obviously this is a Python web app, but if your application runs in a container, it will run on Hyper_. +Obviously this is a Python web app, but if your application runs in a container, it will run on Hyper.sh. #### Deploying 2 containers in under 10 seconds, so what? @@ -38,7 +38,7 @@ Deploying 2 containers in under 10 seconds in production may be no biggy for you After all that, sure, you can go ahead and deploy 2 containers in way less than 10 seconds, but you first had to do all that **and now you have to maintain it all**. -With Hyper_ the longest part of the use case is signing up for the public beta. +With Hyper.sh the longest part of the use case is signing up for the public beta. Why not get started now? [https://console.hyper.sh/register](https://console.hyper.sh/register) diff --git a/blog/source/hyper-use-case-week-part-2-load-balancer-with-two-web-servers.md b/blog/source/hyper-use-case-week-part-2-load-balancer-with-two-web-servers.md index 235a554..a5cf36e 100644 --- a/blog/source/hyper-use-case-week-part-2-load-balancer-with-two-web-servers.md +++ b/blog/source/hyper-use-case-week-part-2-load-balancer-with-two-web-servers.md @@ -25,14 +25,14 @@ Simple enough; deploy two web servers, deploy the load balancer, point the load #### How do I do it? -It's not rocket science but [registered](https://console.hyper.sh/register) Hyper_ users are achieving this deployment in record time. Here's how: +It's not rocket science but [registered](https://console.hyper.sh/register) Hyper.sh users are achieving this deployment in record time. Here's how: ``` shell hyper run -d --name web-1 hyperhq/webapp:host python app.py hyper run -d --name web-2 hyperhq/webapp:host python app.py hyper run -d --name lb --link web-1 --link web-2 dockercloud/haproxy FIP=$(hyper fip allocate 1) -hyper fip associate $FIP lb +hyper fip attach $FIP lb curl $FIP:80 > Hello my host name is: de380811142a curl $FIP:80 @@ -40,7 +40,7 @@ curl $FIP:80 > Hello: linked database is "tcp://" ``` -Obviously this is a Python web app, but if your application runs in a container, it will run on Hyper_. +Obviously this is a Python web app, but if your application runs in a container, it will run on Hyper.sh. #### So what? @@ -48,7 +48,7 @@ This may be no biggy for you anyway. You already provisioned your virtual machin Sure, then you can go ahead and deploy this in the same time, but you first had to do all that **and now you have to maintain it all**. -With Hyper_ the longest part of the use case is signing up for the public beta. Why not get started now? [https://console.hyper.sh/register](https://console.hyper.sh/register) +With Hyper.sh the longest part of the use case is signing up for the public beta. Why not get started now? [https://console.hyper.sh/register](https://console.hyper.sh/register) **Next** check out part 3 of this series; [persisting state between redeploys using a volume.](https://blog.hyper.sh/hyper-use-case-week-part-3-volume-snapshot-and-restore.html) diff --git a/blog/source/hyper-use-case-week-part-3-volume-snapshot-and-restore.md b/blog/source/hyper-use-case-week-part-3-volume-snapshot-and-restore.md index 1da37f0..e0ed7f7 100644 --- a/blog/source/hyper-use-case-week-part-3-volume-snapshot-and-restore.md +++ b/blog/source/hyper-use-case-week-part-3-volume-snapshot-and-restore.md @@ -35,7 +35,7 @@ hyper volume create --name vol2 --snapshot mybackup hyper run -it --name db-2 -v vol2:/tmp hyperhq/postgres cat /tmp/test.txt ``` -Obviously this is a Postgres example, but if your application runs in a container, it will run on Hyper_. +Obviously this is a Postgres example, but if your application runs in a container, it will run on Hyper.sh. #### What's next? diff --git a/blog/source/hyper-use-case-week-part-4-floating-IP-failover.md b/blog/source/hyper-use-case-week-part-4-floating-IP-failover.md index c3a5a8e..1edf810 100644 --- a/blog/source/hyper-use-case-week-part-4-floating-IP-failover.md +++ b/blog/source/hyper-use-case-week-part-4-floating-IP-failover.md @@ -19,7 +19,7 @@ So let's get started! So you'd like to gracefully fail over to another backend when something goes wrong? No problem. -![Associate a floating IP with one web server and failover to a second](images/hyper-use-case-week-part-4-floating-IP-failover/1.png) +![Attach a floating IP with one web server and failover to a second](images/hyper-use-case-week-part-4-floating-IP-failover/1.png) #### How do I do it? @@ -28,22 +28,22 @@ Users on the [Hyper public beta](https://console.hyper.sh/register) are achievin ``` shell hyper run -d --name web-1 hyperhq/webapp:host python app.py FIP=$(hyper fip allocate 1) -hyper fip associate $FIP web-1 +hyper fip attach $FIP web-1 curl $FIP:5000 > Hello my host name is: 51924e0494f3 hyper rm -f web-1 hyper run -d --name web-2 hyperhq/webapp:host python app.py -hyper fip associate $FIP web-2 +hyper fip attach $FIP web-2 curl $FIP:5000 > Hello my host name is: 8568c6bbf2f793 ``` -Obviously this is a Python example, but if your application runs in a container, it will run on Hyper_. +Obviously this is a Python example, but if your application runs in a container, it will run on Hyper.sh. #### What's next? **That's it** for this series. Coming up next, running your own Cassandra cluster on Hyper. Keep an eye on our [twitter](https://twitter.com/hyper_sh). -Why not get started with Hyper_ now? [https://console.hyper.sh/register](https://console.hyper.sh/register) +Why not get started with Hyper.sh now? [https://console.hyper.sh/register](https://console.hyper.sh/register) Questions? Drop us a mail at [contact@hyper.sh](mailto:contact@hyper.sh). diff --git a/blog/source/hyper_enables_jd_com_hummingbird_container_native_cloud.md b/blog/source/hyper_enables_jd_com_hummingbird_container_native_cloud.md new file mode 100644 index 0000000..8a89af9 --- /dev/null +++ b/blog/source/hyper_enables_jd_com_hummingbird_container_native_cloud.md @@ -0,0 +1,38 @@ +title: How Hyper’s technology enables JD.com to build "Hummingbird", a Container-native Cloud +date: 2017-04-14 21:00:00 +0800 +author: hyper +tags: + - Docker + - JD.com + - Container + - Container hosting + +preview: JD.com, China's second largest online retailer have chosen to use Hyper tech for their Docker cloud offering JCloud Hummingbird! + +--- + +[JD.com](https://jd.com) is a Chinese e-commerce giant. It is one of the largest online B2C retailers in China by transaction volume and revenue, second only to Alibaba. Since 2015, JD.com has offered a public cloud service, called JCloud. Similar to other public clouds, JCloud offers both traditional IaaS and PaaS. + +### Container-native Cloud +In 2017, JCloud's goal is to provide greater value to its customers, as well as differentiate itself from other competitors. In the e-commerce market, a single discount event or holiday program will bring in unimaginable traffic and transactions to merchants. As an example, during the ***2016 JD.com 6.18 Carnival Day*** annual sales event, over 100 million orders were placed. Such volume spikes lead to huge cloud resource needs, and as such, the provisioning speed becomes a significant bottleneck and pain point. + +To **speed up resource provisioning** and **reduce deployment overhead**, JCloud decided to work with Hyper to build a new container-native IaaS product: JCloud Hummingbird. Put simply, Hummingbird is a Docker hosting service, in which the container replaces the VM as the base compute instance, just like [Hyper.sh](https://hyper.sh/) itself. While that might sound similar to other Container-as-a-Service (CaaS) offerings in the market, the platform's uniqueness is that the containers are completely isolated from one another, meaning that multiple tenants' containers are safe to run over shared infrastructure, without worrying about having to add a secure boundary. + +The major side benefit of the strong container isolation is that developers don't have to provision VM instances before deploying containers. Instead, they simply launch containers as they normally would launch VMs. In other words, **(isolated) containers become the new infrastructure**. This change brings very significant benefits: + +- **5-second Provisioning**: Compared with the slow boot performance of VMs, containers are provisioned in seconds. Resulting in an improved developer experience and higher productivity. +- **Super Elastic**: Fast provisioning speeds enables auto-scaling to take place “just-in-time”. No more over-provisioning. +- **Cost Effective**: The combination of per-second billing and super fast provisioning, makes Hummingbird extremely cost effective. +- **Docker Image Workflow**: Containers replace VMs as the infrastructure building block and deliverable artefact meaning that developers who are used to Docker can get started quickly. +- **Cattle vs Pets**: Without a long-running VM cluster, there are no ‘pets’ in infrastructure that need nursing. Everything can be treated like cattle! Disposable, and easy to reproduce. +- **Immutable Infrastructure**: Container infrastructure is inherently immutable, eliminating the headache of VM configuration drift. + +### Under the hood +The secret sauce behind Hummingbird is Hyper's secure Docker runtime technology called [runV](https://github.com/hyperhq/runv). Different from runC, which is based on Linux containers, runV containers are powered by virtualization. It creates a VM instance that boots a minimized Linux kernel, and loads Docker images as "rootfs", then the kernel launches [HyperStart](https://github.com/hyperhq/hyperstart), a tiny init service, which runs applications specified in `CMD` and `ENTRYPOINT` flags. That entire process takes less than 100ms to complete, which is orders of magnitude faster than traditional VMs and almost as fast as regular Linux containers. Combined with other techniques, runV is able to match runC, in both features and boot-performance. All of this makes runV operate like a container, but with the benefits of [hardware-enforced](https://en.wikipedia.org/wiki/X86_virtualization) VM security. + +Combining the best of VMs and Containers opens up interesting new opportunities. The base of the Hummingbird stack is bare metal, outfitted with the Hyper container engine for provisioning and container management, and using Kubernetes for container orchestration. Other cloud functions are controlled by components taken from OpenStack, including Keystone, for identity management and authentication; Neutron, for network management; and Cinder/Ceph, for storage volume management. + +### Summary +Since the beta release in January, Hummingbird has seen 300% month on month growth and the service is being continually expanded to meet the needs of [JD.com’s](http://www.jd.com/) developers and customers. Lijing Guo, Head of Product Management of JCloud, told us: "With Hummingbird, we are able to provide a way for our customers to provision containers in a simple, fast, secure, and cost-effective manner. Development speed is 3x to traditional IaaS, but with 50% cost reduction. The project is a great success!" + +We’re thrilled to see a company the size of JD.com taking advantage of the same ease of use that Hyper.sh customers have been enjoying since August 2016 and look forward to working with them further as they expand. diff --git a/blog/source/hyper_vs_digitalocean_round_1_wordpress_mysql_phpmyadmin.md b/blog/source/hyper_vs_digitalocean_round_1_wordpress_mysql_phpmyadmin.md index 161a32b..7c60cd7 100644 --- a/blog/source/hyper_vs_digitalocean_round_1_wordpress_mysql_phpmyadmin.md +++ b/blog/source/hyper_vs_digitalocean_round_1_wordpress_mysql_phpmyadmin.md @@ -1,4 +1,4 @@ -title: "Hyper_ vs DigitalOcean Smackdown - Round 1: WordPress with MySQL and PHPMyAdmin" +title: "Hyper.sh vs DigitalOcean Smackdown - Round 1: WordPress with MySQL and PHPMyAdmin" date: 2016-07-29 10:00:00 +0800 author: hyper preview: Hyper is all about making things easier. Easier to use, easier to maintain and easier to understand. We see a lot of people wasting a lot of time installing and patching Docker, maintaining clusters, figuring out whether to use Mesos or Kubernetes. @@ -34,7 +34,7 @@ The Hyper commands to achieve the same effect can be found below. //add public ip to phpmyadmin container $ hyper fip allocate 1 23.236.114.79 - $ hyper fip associate 23.236.114.79 myadmin + $ hyper fip attach 23.236.114.79 myadmin //view all containers $ hyper ps @@ -52,7 +52,7 @@ The Hyper commands to achieve the same effect can be found below. //add public ip to wordpress container $ hyper fip allocate 1 162.221.195.188 - $ hyper fip associate 162.221.195.188 mywordpress + $ hyper fip attach 162.221.195.188 mywordpress //view all containers $ hyper ps @@ -66,7 +66,7 @@ The Hyper commands to achieve the same effect can be found below. Summary ---- -By using Hyper to re-use Docker images that are already available online, you can be up and running with 20% of the effort and don’t forget, with Hyper you don’t need to manage a server or patch a an OS anymore. You also get cool stuff like volume based persistence for Wordpress upgrades for free. That’s so much better! +By using Hyper to re-use Docker images that are already available online, you can be up and running with 20% of the effort and don’t forget, with Hyper you don’t need to manage a server or patch an OS anymore. You also get cool stuff like volume based persistence for Wordpress upgrades for free. That’s so much better! Sign up for Hyper now: [https://hyper.sh/](https://hyper.sh/) Follow us on Twitter for all the latest information: [https://twitter.com/hyper_sh](https://twitter.com/hyper_sh) diff --git a/blog/source/hyper_vs_digitalocean_round_2_vpn_server.md b/blog/source/hyper_vs_digitalocean_round_2_vpn_server.md new file mode 100644 index 0000000..18aff09 --- /dev/null +++ b/blog/source/hyper_vs_digitalocean_round_2_vpn_server.md @@ -0,0 +1,83 @@ +title: "Hyper.sh vs DigitalOcean Smackdown - Round 2: Set Up an OpenVPN Server on Hyper.sh" +date: 2016-08-14 00:00:00 +0800 +author: hyper +preview: A Virtual Private Network (VPN) is necessary when you want to traverse untrusted networks privately and securely to your Hyper.sh cloud. In this tutorial, we'll set up a VPN server on a container in Hyper.sh and then configure it to access from any place we like. + +--- + +A VPN server is normally a full-featured Secure Socket Layer (SSL) VPN solution that provides a private path to access network resources and services securely. In this tutorial, we'll set up a SoftEther VPN server on Hyper.sh and configure its access. + +> Why not OpenVPN? Because OpenVPN project has been stalled for years, and SoftEther VPN is the defacto replacement as far as we know. + +This blog post will also show the simplicity brought by Hyper.sh cloud to the installation and configuration steps comparing to Digital Ocean, which thanks to the magic of "container cloud". + +While on DigitalOcean, the tutorial of setting up SoftEther VPN is quite long if you'd like to check it out [here](https://www.digitalocean.com/community/tutorials/how-to-setup-a-multi-protocol-vpn-server-using-softether), so do the OpenVPN version [here](https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14-04). That's mainly because the configuration steps of VPN server as well as its dependency management have to be all taken cared by the user. + +But on Hyper.sh cloud, again, we just need several commands to achieve the same effect. + +### Step 1: Run SoftEther VPN container on Hyper.sh cloud. +```shell +$ hyper run -d --name mysoftethervpn \ + -p 500:500/udp -p 4500:4500/udp -p 1701:1701/tcp \ + -p 5555:5555/tcp \ + -p 1194:1194/udp \ + -e PSK=12345678 -e USERNAME=demo -e PASSWORD=12345678 siomiz/softethervpn +``` +Let's check our container running. +``` +$ hyper ps +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES PUBLIC IP +9af31f0ab09e siomiz/softethervpn "/entrypoint.sh /usr/" 2 minutes ago Up 2 minutes 0.0.0.0:500->500/udp, 0.0.0.0:1194->1194/udp, 0.0.0.0:1701->1701/tcp, 0.0.0.0:4500->4500/udp, 0.0.0.0:5555->5555/tcp mysoftethervpn +``` + +As you can see, shipping a SoftEther VPN server with Docker Image is always quite simple, we also told Hyper.sh to expose some useful ports to the public just for remote access and administration usage. Please remember to note your username and password somewhere safely. + +### Step 2: Get configuration from the log of VPN container. +```shell +$ hyper logs mysoftethervpn +# ======================== +# demo +# +# ======================== +# Version 4.21 Build 9613 (English) +dev tun +proto udp +remote vpn213493288.v4.softether.net 1194 +... +``` +By using `hyper logs` command, we can get the configuration of our VPN server easily. Please note the `remote` host name generated by VPN server is essential for later usage, and it should be accessible. + +```shell +$ ping vpn213493288.v4.softether.net +PING vpn213493288.v4.softether.net (162.221.195.64) 56(84) bytes of data. +64 bytes from 162.221.195.64: icmp_seq=1 ttl=50 time=282 ms +``` + +Great! For now, our VPN server has been running on the Hyper.sh cloud, and the secure tunnel is ready to be established to `vpn213493288.v4.softether.net`. + +### Step 3: Configure a client to connect your VPN server on Hyper.sh cloud. + +This time, we will use a VPN client installed on my Windows computer in China as example. + +- Add the configuration of VPN server to the client. + + ![](-/images/hyper_vs_digitalocean_round_2_vpn_server/vpnconfig.png) + +- Use the client to connect our VPN server. + + ![](-/images/hyper_vs_digitalocean_round_2_vpn_server/vpnclient.png) + +- Let's visit [dnsleaktest](https://www.dnsleaktest.com) to check if all traffic originating from my computer is routed through the VPN server. + + ![](-/images/hyper_vs_digitalocean_round_2_vpn_server/verify.png) + +Done! + +Summary +---- +The magic of Hyper.sh is that it allows you ship Docker image to the cloud by one command, and run that image in a much more secure container. Users of Hyper.sh should not care about infrastructure layer (actually there's no such layer in Hyper.sh) and the only thing they need is operating those containers. + +That’s so much better! + +Sign up for Hyper now: [https://hyper.sh/](https://hyper.sh/) +Follow us on Twitter for all the latest information: [https://twitter.com/hyper_sh](https://twitter.com/hyper_sh) diff --git a/blog/source/images/best-value-individual.png b/blog/source/images/best-value-individual.png new file mode 100644 index 0000000..0c1d067 Binary files /dev/null and b/blog/source/images/best-value-individual.png differ diff --git a/blog/source/images/best-value-results-graph.png b/blog/source/images/best-value-results-graph.png new file mode 100644 index 0000000..89a0314 Binary files /dev/null and b/blog/source/images/best-value-results-graph.png differ diff --git a/blog/source/images/best-value-venn-diagram.png b/blog/source/images/best-value-venn-diagram.png new file mode 100644 index 0000000..7f911cd Binary files /dev/null and b/blog/source/images/best-value-venn-diagram.png differ diff --git a/blog/source/images/hyper_highlevel_overview.pdf b/blog/source/images/hyper_highlevel_overview.pdf new file mode 100755 index 0000000..df90445 Binary files /dev/null and b/blog/source/images/hyper_highlevel_overview.pdf differ diff --git a/blog/source/images/hyper_vs_digitalocean_round_2_vpn_server/verify.png b/blog/source/images/hyper_vs_digitalocean_round_2_vpn_server/verify.png new file mode 100644 index 0000000..1e7dda4 Binary files /dev/null and b/blog/source/images/hyper_vs_digitalocean_round_2_vpn_server/verify.png differ diff --git a/blog/source/images/hyper_vs_digitalocean_round_2_vpn_server/vpnclient.png b/blog/source/images/hyper_vs_digitalocean_round_2_vpn_server/vpnclient.png new file mode 100644 index 0000000..412d356 Binary files /dev/null and b/blog/source/images/hyper_vs_digitalocean_round_2_vpn_server/vpnclient.png differ diff --git a/blog/source/images/hyper_vs_digitalocean_round_2_vpn_server/vpnconfig.png b/blog/source/images/hyper_vs_digitalocean_round_2_vpn_server/vpnconfig.png new file mode 100644 index 0000000..7f810fd Binary files /dev/null and b/blog/source/images/hyper_vs_digitalocean_round_2_vpn_server/vpnconfig.png differ diff --git a/blog/source/images/jenkins-build-results.png b/blog/source/images/jenkins-build-results.png new file mode 100644 index 0000000..6fd2007 Binary files /dev/null and b/blog/source/images/jenkins-build-results.png differ diff --git a/blog/source/images/logo-large.svg b/blog/source/images/logo-large.svg index 2c90af1..458e729 100644 --- a/blog/source/images/logo-large.svg +++ b/blog/source/images/logo-large.svg @@ -1,54 +1,54 @@ - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + diff --git a/blog/source/images/logo.svg b/blog/source/images/logo.svg index 37dc7f6..96a0325 100644 --- a/blog/source/images/logo.svg +++ b/blog/source/images/logo.svg @@ -1,14 +1,14 @@ - - - - - - + + + + + + diff --git a/blog/source/images/run-build-on-hyper.png b/blog/source/images/run-build-on-hyper.png new file mode 100644 index 0000000..ba17e42 Binary files /dev/null and b/blog/source/images/run-build-on-hyper.png differ diff --git a/blog/source/images/serverless-ci-hyper-docker-integration-for-buildbot/checks-page.png b/blog/source/images/serverless-ci-hyper-docker-integration-for-buildbot/checks-page.png new file mode 100644 index 0000000..1044b64 Binary files /dev/null and b/blog/source/images/serverless-ci-hyper-docker-integration-for-buildbot/checks-page.png differ diff --git a/blog/source/images/serverless-ci-hyper-docker-integration-for-buildbot/comparison.png b/blog/source/images/serverless-ci-hyper-docker-integration-for-buildbot/comparison.png new file mode 100644 index 0000000..2113d63 Binary files /dev/null and b/blog/source/images/serverless-ci-hyper-docker-integration-for-buildbot/comparison.png differ diff --git a/blog/source/images/trigger-jenkins-build.png b/blog/source/images/trigger-jenkins-build.png new file mode 100644 index 0000000..3ed734d Binary files /dev/null and b/blog/source/images/trigger-jenkins-build.png differ diff --git a/blog/source/introduce-hyper-security-group.md b/blog/source/introduce-hyper-security-group.md new file mode 100755 index 0000000..692f4a1 --- /dev/null +++ b/blog/source/introduce-hyper-security-group.md @@ -0,0 +1,61 @@ +title: "Introducing Hyper.sh Security Group (and more)" +date: 2016-09-19 14:24:00 +0800 +author: hyper +tags: + - Docker + - Container + - Container-native cloud + - Hyper +preview: We are excited to introduce you the new Hyper.sh Security Group, CLI Auto Upgrade, and more! + +--- +At Hyper.sh, our mission has always been **Make running containers in production effortless**. In the past few weeks, we keep collecting feature requests from our community to prioritize [our roadmap](https://trello.com/b/7fEwaPRd/roadmap). Today, we have some really exciting news for you. + +> **Please [install the new CLI](https://docs.hyper.sh/GettingStarted/install.html)**. + +### Security Group + +Since [our GA](https://blog.hyper.sh/hyper-is-generally-available.html), one of the top feature requests is **Security Group**. By controlling the traffic for containers, it provides developers greater security and manageability: + +> - `hyper sg create web-sg -f web_sg.yaml`: create a security group by adding rules that allow traffic to or from its associated containers +> - `hyper run -d --sg=web-sg --name web nginx`: specify one or more security groups with the container; when we decide whether to allow traffic to reach a container, we evaluate all the rules from all the security groups that are associated with the container +> - `hyper update nginx --sg_add=new-sg`: add/remove the security groups associated with containers +> - `hyper sg update web-sg -f web_sg2.yaml`: modify the rules for a security group on the fly; the new rules are automatically applied to all containers that are associated with the security group + +More details can be found at [Roadmap](https://trello.com/c/ZbGtfwZt/37-security-group), [Documentation](https://docs.hyper.sh/Reference/sg_ref.html). + +### CLI Auto Upgrade + +Everyone loves command line tools! It is the enormously powerful to be able to control everything at fingertips. However, the trade-off is manual update. With this release, the built-in functionality will upgrade `hyper` CLI whenever there is a newer version. It helps you to automatically keep your local utility up to date. + +### Faster Container Deployment +If a Docker image is built with the `VOLUME` instruction, it creates a mount point with the specified name and marks it as holding externally mounted volumes, which will be initialized upon `run` or `create` commands. The initialization process could take tens of seconds or even minutes to complete, depending on the data size. + +The new `--noauto-volume` option allows faster container deployment, by skipping `VOLUME` flag in the Docker image. +``` bash +$ hyper run --noauto-volume`. +``` + +### Multiple Mountpoints +You can mount a volume at multiple different paths of a container. +``` bash +$ hyper run -v vol1:/opt/data -v vol1:/opt/log --name=mycontainer ubuntu +``` + +### Large Local Data Support +`hyper run -v /local:/container` allows you to load local data to remote containers upon launching. Previously the data size limit is a few hundreds MBs. The new release supports up to 10GB! + +### Enhanced Container Resource Limits +The new performance patch improves the container resource limits: + +- Max open files: 1000000 +- Max processes: 30604 +- Max pending signals: 30604:30604 + +--------------------- + +We hope that you will enjoy these new features in the new Hyper.sh. Please stay tuned on [our roadmap](https://trello.com/b/7fEwaPRd/roadmap) as we continue to add more exciting features and if you have any questions you can always contact us through the Hyper.sh console, Hyper.sh forum, or on support@hyper.sh. + +Thanks, + +The Hyper.sh Crew diff --git a/blog/source/introducing-clusterless-kubernetes-job.md b/blog/source/introducing-clusterless-kubernetes-job.md new file mode 100755 index 0000000..1f133e2 --- /dev/null +++ b/blog/source/introducing-clusterless-kubernetes-job.md @@ -0,0 +1,93 @@ +title: Introduce Clusterless Kubernetes Job and Large Pod Size +date: 2018-07-13 9:48:12 +author: Peng Zhao +preview: Today, we are excited to announce to support Kuberentes Job feature in Pi. Also, we add more large pod size for bigger workload requirements. +--- + +> NOTE: Please download the latest CLI build. See [here](https://docs.hyper.sh/pi/Quickstart/install_cli.html) for details. + +# Clusterless Kubernetes Job + +Today we are happy to announce the release of [Kubernetes Job](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) support in [Pi](https://hyper.sh/pi). + +The same as in Kubernetes, a job creates one or more pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the job tracks the successful completions. When a specified number of successful completions is reached, the job itself is complete. + +With Pi however, you can run any job without the need of Kubernetes cluster. Also you only pay (per second!) when the job is running, just as with any other resource on __Pi__. + +### Create a job which computes π to 2000 places and prints it out: + +``` +$ pi create job pi --image=perl --restart=Never --backoff-limit=4 -- perl -Mbignum=bpi -wle "print bpi(2000)" +job "pi" created +``` + +Remember, although the commands looks just like `kubectl`, there is no Kubernetes cluster nor node in Pi. Simply use our CLI to launch jobs. + +### Check on the status of the job using this command: + +```shell +$ pi describe jobs/pi +Name: pi +Namespace: default +Selector: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 +Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 + job-name=pi +Annotations: +Parallelism: 1 +Completions: 1 +Start Time: Tue, 03 Jul 2018 15:02:53 +0800 +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 + job-name=pi + Containers: + pi: + Image: perl + Port: + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {job-controller } Normal SuccessfulCreate Created pod: pi-dtn4q +``` + +To view completed pods of a job, use `pi get pods`. + +### List all the pods that belong to a job in a machine readable form: + +```shell +$ pods=$(pi get pods --selector=job-name=pi --output=jsonpath={.items..metadata.name}) +$ echo $pods +pi-aiw0a +``` + +Here, the selector is the same as the selector for the job. The `--output=jsonpath` option specifies an expression that just gets the name from each pod in the returned list. + +### View the standard output of one of the pods: + +```shell +$ pi logs $pods +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` + +# More Large Pod Size + +There has been a lot of interest from our customers to use large pod size to both CPU and memory intenive workload. Now, we add the support of the following new pod sizes: + +| Size | vCPU | RAM (GB) | +|---|---|---| +| L3 | 8 | 30 | +| L4 | 16 | 50 | +| L5 | 32 | 110 | +| L6 | 64 | 230 | + +If you need even larger spec, please feel free to [let us know](contact@hyper.sh)! + +Want to try _Pi_ now? Enjoy your access here: https://hyper.sh diff --git a/blog/source/introducing-hyper-beta-the-native-container-cloud.md b/blog/source/introducing-hyper-beta-the-native-container-cloud.md index dfecb2e..c124c67 100644 --- a/blog/source/introducing-hyper-beta-the-native-container-cloud.md +++ b/blog/source/introducing-hyper-beta-the-native-container-cloud.md @@ -1,16 +1,16 @@ -title: Introducing Hyper_ (Free Beta) - The Simple And Secure Container Cloud +title: Introducing Hyper.sh (Free Beta) - The Simple And Secure Container Cloud date: 2016-04-04 00:00:00 author: hyper -preview: Today, we are very happy to announce Hyper_ (beta), which you can try out for free. We’ve been working on Hyper_ for a long time and we’re now ready to unleash it on the world!. Different from traditional container services, Hyper_ is a native container cloud, in which multi-tenant containers can inherently be run safely side by side on bare metal, instead of being nested in VMs. +preview: Today, we are very happy to announce Hyper.sh (beta), which you can try out for free. We’ve been working on Hyper.sh for a long time and we’re now ready to unleash it on the world!. Different from traditional container services, Hyper.sh is a native container cloud, in which multi-tenant containers can inherently be run safely side by side on bare metal, instead of being nested in VMs. --- -Today, we are very happy to announce Hyper_ (beta), which you can try out for free. We’ve been working on Hyper_ for a long time and we’re now ready to unleash it on the world!. Different from traditional container services, Hyper_ is a native container cloud, in which **multi-tenant containers can inherently be run safely side by side on bare metal**, instead of being nested in VMs. +Today, we are very happy to announce Hyper.sh (beta), which you can try out for free. We’ve been working on Hyper.sh for a long time and we’re now ready to unleash it on the world!. Different from traditional container services, Hyper.sh is a native container cloud, in which **multi-tenant containers can inherently be run safely side by side on bare metal**, instead of being nested in VMs. You can sign up get your free access by following this link: https://hyper.sh/ . We are bringing new users on to the platform as quickly as possible and you’ll be updated by email as we proceed. ### Secure Container -Hyper_ is built on [HyperContainer](https://github.com/hyperhq/hyper) , a virtualized container technology we open-sourced. HyperContainer addresses the security problem in Linux Containers by replacing: +Hyper.sh is built on [HyperContainer](https://github.com/hyperhq/hyper) , a virtualized container technology we open-sourced. HyperContainer addresses the security problem in Linux Containers by replacing: - `Cgroup + Namespace` ---> `Hypervisor (KVM, Xen, etc)` - `Host Kernel` ---> `Guest Kernel` @@ -23,40 +23,40 @@ As for performance, **a HyperContainer is able to boot in less than a second (~1 ![](https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/879x320/5471e40d4a519c3d31f455bdccc978ca/upload_2_3_2016_at_3_50_31_PM.png) -Thanks to the built-in isolation, HyperContainer replaces VMs as the building block of Hyper_. More importantly, without the underlying VM hosts, the need for a cluster is gone, along with things like capacity planning, VM configuration, COE, and cluster utilization rates. Thus, **Hyper\_ works like one single remote Docker host with unlimited capacity**. +Thanks to the built-in isolation, HyperContainer replaces VMs as the building block of Hyper.sh. More importantly, without the underlying VM hosts, the need for a cluster is gone, along with things like capacity planning, VM configuration, COE, and cluster utilization rates. Thus, **Hyper\_ works like one single remote Docker host with unlimited capacity**. -There is no need to learn a new set of commands. The Docker native workflow makes working with HYPER_ as simple as running containers on your own laptop: +There is no need to learn a new set of commands. The Docker native workflow makes working with Hyper.sh as simple as running containers on your own laptop: -- `hyper pull`: pull images from Docker hub to your Hyper_ account +- `hyper pull`: pull images from Docker hub to your Hyper.sh account - `hyper run`: launch a HyperContainer without VM or scheduling - `hyper run --link`: link multiple containers as they run on one machine - `hyper exec`: login your container or execute commands -- `hyper fip associate`: associate floating public IPs to enable Internet access and mask application failures +- `hyper fip attach`: attach floating public IPs to enable Internet access and mask application failures ### Pay Per Second We charge by the Container and We charge by the Second. -We charge you for the individual container, NOT a long running VM typically used to run your containers. Unlike AWS and Google, Hyper_ is capable of directly launching a secure container without a VM, providing true agility and cost optimization. +We charge you for the individual container, NOT a long running VM typically used to run your containers. Unlike AWS and Google, Hyper.sh is capable of directly launching a secure container without a VM, providing true agility and cost optimization. -We charge you by the second. You can spin up a container in 3 seconds, crunch some data or run parallel builds on the latest commit for 10s, destroy the container in 1s, and Hyper_ will only charge for 3+10+1=14s. +We charge you by the second. You can spin up a container in 3 seconds, crunch some data or run parallel builds on the latest commit for 10s, destroy the container in 1s, and Hyper.sh will only charge for 3+10+1=14s. This Per Second model not only promises cost saving, also advocates event-driven patterns such [AWS Lambda](https://aws.amazon.com/lambda), [Spark Streaming](http://spark.apache.org/streaming/), and [CD/CI](https://10second.build/). ![](https://trello-attachments.s3.amazonaws.com/56b19c6e5bb4a89f92d0e71f/903x472/2ccb5880a4286dd6d4c14eb19b3dab99/upload_2_3_2016_at_2_21_34_PM.png) ### Persistent Storage -We've built a distributed, replicated, reliable block storage system in Hyper_ to offer you the persistent volume/snapshot features you need to run your stateful workloads. And it is powered by full high-performance SSD! +We've built a distributed, replicated, reliable block storage system in Hyper.sh to offer you the persistent volume/snapshot features you need to run your stateful workloads. And it is powered by full high-performance SSD! ### 10Gbps Network for FREE! We use the latest 10Gbps network to run your container. The best part is that all traffic (in, out, inter-container) is FREE! ### Make the cloud run like your laptop -We’re extremely excited to make Hyper_ available to the world via this public beta and we’re looking forward to learning how people use the platform and where we can improve. +We’re extremely excited to make Hyper.sh available to the world via this public beta and we’re looking forward to learning how people use the platform and where we can improve. By repurposing the hypervisor from traditional full-blown VMs to the application-centric container, we think we’ve brought much-needed isolation to multi-tenancy, while keeping the signature tune of a Linux container: sub-second boot, with upgraded immutability and portability. We believe that this is the nirvana for Cloud Native Applications. Developers can finally concentrate on the code, not being distracted by the server, because there is simply no such thing. -Want to try Hyper_ now? Get your free access here: https://hyper.sh +Want to try Hyper.sh now? Get your free access here: https://hyper.sh diff --git a/blog/source/introducing-minio.md b/blog/source/introducing-minio.md new file mode 100644 index 0000000..87e1b2d --- /dev/null +++ b/blog/source/introducing-minio.md @@ -0,0 +1,69 @@ +title: "Introducing Minio: Run you own S3 compatible cloud storage on Hyper.sh" +date: 2017-02-17 22:00:00 +0100 +author: hyper +tags: + - Docker + - Container + - Minio + - S3 + - Storage +preview: "We've been working with the lovely people over at Minio to bring you S3 compatible storage on Hyper.sh!" + +--- + +# Introducing Minio: Run your own S3 compatible cloud storage on Hyper.sh! + +Storage has been long thought of as complex and difficult. The ephemeral nature of containers has further complicated the situation as it often seems counter-intuitive to store mission critical data on something that itself is supposed to be disposable. + +[Minio](https://www.minio.io/) is an open source, S3 compatible, cloud-native object storage server, that makes storage as easy as launching a Docker container. On Hyper.sh, Minio servers are backed by Hyper.sh volumes that make sure, even if a container running Minio server goes down, the data is safe in the volume. As a true cloud-native application, Minio scales very well in a multi-tenant cloud environment. + +-- + +Some of our users have been using Minio for a while. But, we've had other users asking for something similar, unaware that Minio existed. + +To address this problem we joined forces with the Minio team to officialize the Minio deployment template. + +## Why use Minio? + +There are three main reasons why people have been using Minio on Hyper.sh: + +1. Total control over object store configuration. +2. True cloud-native scalability. +3. Easy to setup and deploy. + +## How to use Minio? + +The Minio team helped us create these three reference Hyper Compose files for small, medium and large configurations*. + +Small - [link](https://gist.github.com/harshavardhana/14b2a472d661446fe5b0f602bc61ac82#file-s4-compose-yml) + +Medium - [link](https://gist.github.com/harshavardhana/14b2a472d661446fe5b0f602bc61ac82#file-m3-compose-yml) + +Large - [link](https://gist.github.com/harshavardhana/14b2a472d661446fe5b0f602bc61ac82#file-l3-compose-yml) + +Note that, you'll first you need to create the storage volumes that Minio will uses as backend storage. + +For example, + +``` +hyper volume create --name minio-disk-1 --size=50 +hyper volume create --name minio-disk-2 --size=50 +hyper volume create --name minio-disk-3 --size=50 +hyper volume create --name minio-disk-4 --size=50 +``` + +This will create 4 volumes which in this case are each 50GB in size and will be treated as a storage pool for Minio to use. After that it is as simple as saving one of the above three compose files locally and running: + +```hyper compose up -f ``` + +## That's it! + +With Minio it really is that simple, and we're very pleased to be working with them to bring this functionality to the Hyper.sh platform. + +We are always looking for feedback. + +- Does this solve a problem for you? +- Are there any tools that you think we should be working more closely with? +- Are there any features that you think are currently missing from Hyper.sh? + +To let us know you can always contact us on the in-console support chat, or on [the forum](https://forum.hyper.sh/) and for Minio specific questions please feel free to reach out to them or check their docs on [the Minio website.](https://www.minio.io/) diff --git a/blog/source/introducing-nfs-shared-volumes.md b/blog/source/introducing-nfs-shared-volumes.md new file mode 100644 index 0000000..4138135 --- /dev/null +++ b/blog/source/introducing-nfs-shared-volumes.md @@ -0,0 +1,61 @@ +title: "Introducing (NFS) Shared Volumes" +date: 2017-01-24 16:00:00 +0800 +author: hyper +tags: + - Docker + - Container + - Container-native cloud + - Hyper +preview: At the beginning of 2017, nothing is more exciting than delivering one of the most requested features in Hyper's history, shared volumes! + +--- + +# Introducing (NFS) Shared Volumes! + +Going from open source technology to offering a public service in 2016 was a major shift for Hyper.sh, and at the beginning of 2017, nothing is more exciting than delivering one of the most requested features in Hyper's history: **Shared Volumes**! + +## A quick review of volumes in Hyper +Since day one, Hyper.sh has supported [block volumes](https://docs.hyper.sh/Feature/storage/volume.html) that are comparable to [AWS EBS](https://aws.amazon.com/ebs/): inherently distributed, replicated, and persistent through failures. We also support [Snapshots](https://docs.hyper.sh/Feature/storage/snapshot.html), providing point-in-time snapshots for backup and recovery. + +Previously in Hyper.sh, like AWS EBS, a block volume could only be attached to one container at a time. + +However, because Docker has supported shared volumes across multiple containers, our users have consistently requested that Hyper.sh be able to do the same, and today we're very excited to announce that feature! + +## Introducing (NFS) Shared Volumes +To support shared volumes, the first idea that popped up was to provide a scalable NFS service, in which you could create shares and mount them to any container. + +Though the idea sounded cool, making an NFS service scalable, reliable and performant would require an enormous engineering effort. When we looked at the use cases, most users only required a small number of containers to to share volumes which gave us some more options. + +We decided to look for a way that fit 90% of use cases while at the same time being quick and easy for everyone to understand and use. + +This is what we came up with: + +First you need to create a container using the `hyperhq/nfs-server` image which runs an optimized [nfs-ganesha](https://github.com/nfs-ganesha/nfs-ganesha) server and automatically exports all attached volumes via the NFS protocol. Once ready, you can mount the exposed volumes on the NFS container in other containers using the `--volumes-from` option. + +For example,the following commands exposes two volumes (`/data1` and `/data2`) and mounts them in two `busybox` containers (`test1` and `test2`). `test1` and `test2` will each have these two volumes mounted at the path `/data` and `/data2`. + + $ hyper run --name mycontainer -d -v /data1 -v /data2 hyperhq/nfs-server + $ hyper run -d --name test1 --volumes-from mycontainer busybox + $ hyper run -d --name test2 --volumes-from mycontainer busybox + +> NOTE: Recursive mounting is not allowed, e.g. you cannot re-mount the NFS volumes from containers `test1` and `test2` to a third one `test3`: + + $ hyper run -d --name test3 --volumes-from test1 busybox + hyper: Error response from daemon: Cannot recursively import volumes from test1. + See 'hyper run --help'. + +> NOTE: `--volumes-from` source container must be created with the Hyper official image (`hyperhq/nfs-server`). Trying to import volumes from containers of other images will fail, e.g., + + $ hyper run -d --name foo busybox + $ hyper run -d --volumes-from foo busybox + hyper: Error response from daemon: volumes-from source container is created from busybox rather than the official image hyperhq/nfs-server. + See 'hyper run --help'. + +## Your feedback Matters + +Do you have feedback on this feature? Do you have ideas about what we should do next? Then please do share your thoughts with us in the [roadmap](https://trello.com/b/7fEwaPRd/roadmap)!! + +-------------------------------------- + +Happy hacking, +The Hyper.sh Crew diff --git a/blog/source/introducing-pi-on-gcp.md b/blog/source/introducing-pi-on-gcp.md new file mode 100755 index 0000000..a3bbb5d --- /dev/null +++ b/blog/source/introducing-pi-on-gcp.md @@ -0,0 +1,22 @@ +title: Introduce Pi - Expanding Serverless Container Platform to Google Cloud +date: 2018-05-10 17:25:00 +author: Peng Zhao +preview: Today, we are excited to announce Pi, our new serverless container platform on Google Cloud. Pi provides the Kubernetes interface (pod). You will now be able to take advantage of advanced features of Kubernetes right from Pi. + +--- + +We are very excited to announce Hyper [Pi](https://hyper.sh/pi) platform! Our new serverless container offering with a native Kubernetes API interface. You will now be able to take advantage of advanced features of Kubernetes right from Pi. + +Since we launched our serverless container offering 2 years ago, a lot has developed within the industry. We have seen the dramatic rise of containerized workloads taking over the cloud ecosystem, and at the forefront of this seachange has been Kubernetes, the open source container orchestration platform. + +While our customers love the simplicity and ease of use that our current Docker-native platform brought in getting their containers up and running quickly and efficiently, there has been a growing number of our customers asking for more advanced micro-service capabilities provided by Kubernetes. Our Pi platform delivers these advanced capabilities along with the same great features our customers love like: + +- Serverless Container +- 5-second Provisioning +- Persistent Volumes +- Built-in Load-balancer +- Per-second Billing + +Also, Pi platform is a strategic step closer to our goal of a multi-cloud serverless container solution. We are initially launching Pi on Google Cloud, with the intent over the next year to expand the platform to AWS, Azure and other major cloud providers. Our customers will enjoy the ease of serverless containers, with the single standard workflow of Kubernetes, and the breadth of deploying containers to any region on any cloud! + +Want to try _Pi_ now? Enjoy your access here: https://hyper.sh diff --git a/blog/source/introducing-service.md b/blog/source/introducing-service.md new file mode 100644 index 0000000..2caa786 --- /dev/null +++ b/blog/source/introducing-service.md @@ -0,0 +1,76 @@ +title: "Introducing Hyper Service" +date: 2016-10-21 16:44:00 +0800 +author: hyper +tags: + - Docker + - Container + - Container-native cloud + - Hyper + - Docker Hosting +preview: Hyper Service automatically handles the load balancing across your containers, and provisions new replicas to replace failed containers. + +--- +At Hyper.sh, our mission has always been to **make running containers in production effortless**. In the past few weeks, we've been collecting feature requests from our community to help prioritize [our roadmap](https://trello.com/b/7fEwaPRd/roadmap). Today, we can announce some exciting new features. + +### Hyper Service = Load Balancer + Self Healing + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/5809d9232d9f8cb9ef140303/9a1617d9613314f654def7cad0eddc55/service_small.png) + +Hyper Service is an abstraction which defines a logical set of containers in a single (private) network and a policy by which to access them. As an example, consider an image-processing backend which is running with 3 instances. Those instances are fungible - the frontend does not care which backend it uses. While the actual containers that compose the backend set may change, the frontend clients should not need to be aware of that or keep track of the list of backends themselves. + +Hyper Service also monitors the replicas. If a container exits (crashes), the service will automatically provision new a new instance to replace the failed one. By doing this, Hyper Service helps to ensure the that the desired number of instances are present at all times. + +Hyper Service supports both `tcp`, `http` and `https` protocols, allowing you to easily offload the entire SSL termination process. Your containers can benefit from encrypted communication with very little operational overhead or administrative complexity. + +More details can be found at +- [Roadmap](https://trello.com/c/7qb0MCCL/23-service) +- [Documentation](https://docs.hyper.sh/Feature/container/service.html) + +### Container Event API (Websocket) + +In many cases, developers want to track container events. They want to know when a (new) container is launched, when a container exits (stops), etc. The container event API provides this functionality. + +The new API is implemented using websockets, which provides easy, realtime notifications to the clients. `start` and `stop` events are currently supprted, with more in the roadmap to follow. + +More details can be found at: +- [Roadmap](https://trello.com/c/QkavyD7R/33-container-event-api-websocket) +- [Documentation](https://docs.hyper.sh/Reference/API/2016-04-04%20[Ver.%201.23]/Event/ws.html) +- [Example (in Go)](https://github.com/hyperhq/websocket-client/blob/master/go/wsclient.go) + +### Container Termination Protection + +For long-running containers, a little extra care doesn't hurt. The new protection flag helps you to prevent accidental termination: + + $ hyper run --protection=true busybox + $ hyper update --protection=false mycontainer + + More details can be found at: +- [Roadmap](https://trello.com/c/HcidVhFz/62-termination-protection-for-container) +- [Documentation](https://docs.hyper.sh/Reference/CLI/run.html) + +### Enhancements to Hyper Compose + +This release supports the following extra commands: + +- `compose pull`: pull the Docker images specified in the compose file +- `noauto_volume`: ignore `VOLUME` flags in the Docker images +- `security_groups`: specify security groups to containers + +More details can be found at: +- [Roadmap](https://trello.com/c/TcNvHXMH/57-support-security-group-and-noautovol-options-in-compose) +- [Documentation](https://docs.hyper.sh/Reference/compose_file_ref.html) + +### CLI Enhancements + +This release allows the Hyper CLI to load API credentials from environmental variables: `HYPER_ACCESS` and `HYPER_SECRET`: + + More details can be found at: +- [Roadmap](https://trello.com/c/78OaPMiC/49-make-the-cli-read-access-and-secret-of-envs) + +--------------------- + +We hope that you will enjoy these new features in the new Hyper.sh. Please stay tuned on [our roadmap](https://trello.com/b/7fEwaPRd/roadmap) as we continue to add more exciting features and if you have any questions you can always contact us through the Hyper.sh console, Hyper.sh forum, or on [support@hyper.sh.](mailto:support@hyper.sh) + +Thanks, + +The Hyper Team diff --git a/blog/source/launch-your-jenkins-server-on-hyper.md b/blog/source/launch-your-jenkins-server-on-hyper.md index 973ca4d..98bfb8c 100644 --- a/blog/source/launch-your-jenkins-server-on-hyper.md +++ b/blog/source/launch-your-jenkins-server-on-hyper.md @@ -1,21 +1,21 @@ -title: "Launch your Jenkins server on Hyper_ in 60s" +title: "Launch your Jenkins server on Hyper.sh in 60s" date: 2016-06-01 21:00:00 +0800 author: hyper tags: - Container - Hyper - Jenkins -preview: This guide shows how you can launch a full functioning Jenkins server in Hyper_ cloud in one minute And then configure this Jenkins works with you Github account. +preview: This guide shows how you can launch a full functioning Jenkins server in Hyper.sh cloud in one minute And then configure this Jenkins works with you Github account. --- -[Hyper_](https://www.hyper.sh/) is a secure container cloud service. It allows you to deploy your containers in seconds from your laptop to the cloud. +[Hyper.sh](https://www.hyper.sh/) is a secure container cloud service. It allows you to deploy your containers in seconds from your laptop to the cloud. [Jenkins](https://jenkins.io/) is the leading open source automation server, Jenkins provides hundreds of plugins to support building, deploying and automating any project. -This blog will show you how to deploy Jenkins server in Hyper_ cloud and integrate it with your Github repo in minutes. Note that we assume that you have installed `hyper` command line tool and had basic knowledge about how to play with Hyper_. If not, just checkout the [hello world blog](learn-hyper_-by-examples-hello-world-in-a-container.md). +This blog will show you how to deploy Jenkins server in Hyper.sh cloud and integrate it with your Github repo in minutes. Note that we assume that you have installed `hyper` command line tool and had basic knowledge about how to play with Hyper.sh. If not, just checkout the [hello world blog](learn-hyper_-by-examples-hello-world-in-a-container.md). -## Run Jenkins server on Hyper_ cloud +## Run Jenkins server on Hyper.sh cloud This is the easiest part, let's move on! @@ -48,7 +48,7 @@ $ hyper run -d --name myjenkins -v /var/jenkins_home jenkins 94241df88c8bcf49f916cc8968a3b27ab4ca0fea55a40d405038409b0e643b79 ``` -If you have read our previous blogs, you may noticed that we told Hyper_ to attach a persistent volume to this Jenkins container. This volume will persist the workspace in `/var/jenkins_home`, since all Jenkins data lives in there - including plugins and configurations. It is highly recommended to treat the `jenkins_home` directory as you would a database, and thanks to Hyper_ volume, you already achieved that. +If you have read our previous blogs, you may noticed that we told Hyper.sh to attach a persistent volume to this Jenkins container. This volume will persist the workspace in `/var/jenkins_home`, since all Jenkins data lives in there - including plugins and configurations. It is highly recommended to treat the `jenkins_home` directory as you would a database, and thanks to Hyper.sh volume, you already achieved that. ### Allocate public network Finally, allocate a `fip` and bind it with our Jenkins container. @@ -57,7 +57,7 @@ Finally, allocate a `fip` and bind it with our Jenkins container. $ hyper fip allocate 1 162.221.195.48 -$ hyper fip associate 162.221.195.48 myjenkins +$ hyper fip attach 162.221.195.48 myjenkins ``` Great! Now we should be able to visit the URL `http://162.221.195.48:8080` of the Jenkins server to see if it works. @@ -65,7 +65,7 @@ Great! Now we should be able to visit the URL `http://162.221.195.48:8080` of t ## Conclusion -In the traditional IT environment, deploying and configuring Jenkins is never an easy task. But with Hyper_ cloud and a pre-built Jenkins container image, you can have it up and running within seconds. With Hyper_ cloud, you can easily standup a production ready Jenkins CI/CD pipeline on the Internet, in under a minute! +In the traditional IT environment, deploying and configuring Jenkins is never an easy task. But with Hyper.sh cloud and a pre-built Jenkins container image, you can have it up and running within seconds. With Hyper.sh cloud, you can easily standup a production ready Jenkins CI/CD pipeline on the Internet, in under a minute! ## (Additional) Configure the Jenkins to work with your Github account diff --git a/blog/source/learn-hyper_-by-examples-data-volume.md b/blog/source/learn-hyper_-by-examples-data-volume.md index b09d18c..988d73a 100644 --- a/blog/source/learn-hyper_-by-examples-data-volume.md +++ b/blog/source/learn-hyper_-by-examples-data-volume.md @@ -1,27 +1,27 @@ -title: "Learn Hyper_ By Examples: Manage Data Volume" +title: "Learn Hyper.sh By Examples: Manage Data Volume" date: 2016-05-12 20:00:00 +0800 author: hyper tags: - Container - Hyper - Volume -preview: This guide teaches you how to manage persistent data in the Hyper_ cloud. +preview: This guide teaches you how to manage persistent data in the Hyper.sh cloud. --- -[Hyper_](https://www.hyper.sh/) is a secure container cloud service. It allows you to deploy your containers in seconds from your laptop to the cloud. +[Hyper.sh](https://www.hyper.sh/) is a secure container cloud service. It allows you to deploy your containers in seconds from your laptop to the cloud. -This is the last article of "Learn Hyper_ by Examples" series. So far you’ve been introduced to basic Hyper_ concepts, seen how to work with real applications as well as learned about networking and links between containers. In this section you’re going to learn how to manage the persistent data volumes in Hyper_ cloud. +This is the last article of "Learn Hyper.sh by Examples" series. So far you’ve been introduced to basic Hyper.sh concepts, seen how to work with real applications as well as learned about networking and links between containers. In this section you’re going to learn how to manage the persistent data volumes in Hyper.sh cloud. > **Prerequisites:** > Please make sure you complete the following prerequisites: -> - [Open a Hyper_ account](https://console.hyper.sh/register) +> - [Open a Hyper.sh account](https://console.hyper.sh/register) > - [Generate API credential](https://docs.hyper.sh/GettingStarted/generate_api_credential.html) > - [Setup `hyper` CLI on your local computer](https://docs.hyper.sh/GettingStarted/install.html) ## Data volume -A data volume in Hyper_ is a persistent storage system for container. It is a specially-designated directory within one container that does not belong to the container image file system. Data volumes provide several useful features for persistent or shared data: +A data volume in Hyper.sh is a persistent storage system for container. It is a specially-designated directory within one container that does not belong to the container image file system. Data volumes provide several useful features for persistent or shared data: - Volumes are initialized when a container is created. If the container's base image contains data at the specified mount point, that data is hidden. @@ -32,7 +32,7 @@ A data volume in Hyper_ is a persistent storage system for container. It is a sp - Data volumes is stored in high available distributed system. - Snapshot can be taken from data volume. -Data volumes are designed to persist data, independent of the container's life cycle. Hyper_ therefore *never* automatically deletes volumes when you remove a container, nor will it "garbage collect" volumes that are no longer +Data volumes are designed to persist data, independent of the container's life cycle. Hyper.sh therefore *never* automatically deletes volumes when you remove a container, nor will it "garbage collect" volumes that are no longer referenced by a container. @@ -82,7 +82,7 @@ $ hyper volume --help Usage: hyper volume [OPTIONS] [COMMAND] -Manage Hyper_ volumes +Manage Hyper.sh volumes Commands: create Create a volume @@ -105,7 +105,7 @@ Now we run a database container which claims `vol1` as volume, and then writes " $ hyper run -it --name db-1 -v vol1:/tmp hyperhq/postgres /bin/shell root@ba047872509b:/# echo hello >> /tmp/test.txt ``` -* `-v :` creates a volume using given name and mounts it into the target directory inside the container. Hyper_ cloud uses industry proven distribution file system to persist data in the target directory until the volume is destroyed. +* `-v :` creates a volume using given name and mounts it into the target directory inside the container. Hyper.sh cloud uses industry proven distribution file system to persist data in the target directory until the volume is destroyed. Then we stop the database container and create a snapshot of this volume. ```shell @@ -128,12 +128,12 @@ hello ``` > **NOTE:** -> For full usage of `hyper volume create` command, please check the [Hyper_ official cli guide](https://docs.hyper.sh/Reference/CLI/volume_create.html). +> For full usage of `hyper volume create` command, please check the [Hyper.sh official cli guide](https://docs.hyper.sh/Reference/CLI/volume_create.html). ## Conclusion -Persistent volume storage is important for container clouds since traditional OS level container volumes tend to be bound to the local directory of their hosts. But in Hyper_ cloud, volumes are implemented with a mature distributed file system directly since there are no shared hosts. We strongly recommend that you preserve valuable data in a Hyper_ volume and maintain them carefully with the help of Hyper_ cloud. +Persistent volume storage is important for container clouds since traditional OS level container volumes tend to be bound to the local directory of their hosts. But in Hyper.sh cloud, volumes are implemented with a mature distributed file system directly since there are no shared hosts. We strongly recommend that you preserve valuable data in a Hyper.sh volume and maintain them carefully with the help of Hyper.sh cloud. -Thanks for following along in this "Learn Hyper By Examples" blog series. You should now be familiar with some of the most important features of Hyper_ cloud, including: "How to use hyper cli", "How to deploy applications to Hyper_ cloud", "How to link containers", and "How to manage container's persistent data". -We hope you have enjoyed this blog series and please continue to explore more of the Hyper_ cloud features on [Hyper_](https://console.hyper.sh/register)! +Thanks for following along in this "Learn Hyper By Examples" blog series. You should now be familiar with some of the most important features of Hyper.sh cloud, including: "How to use hyper cli", "How to deploy applications to Hyper.sh cloud", "How to link containers", and "How to manage container's persistent data". +We hope you have enjoyed this blog series and please continue to explore more of the Hyper.sh cloud features on [Hyper.sh](https://console.hyper.sh/register)! diff --git a/blog/source/learn-hyper_-by-examples-hello-world-in-a-container.md b/blog/source/learn-hyper_-by-examples-hello-world-in-a-container.md index 0275c68..4dc0a08 100644 --- a/blog/source/learn-hyper_-by-examples-hello-world-in-a-container.md +++ b/blog/source/learn-hyper_-by-examples-hello-world-in-a-container.md @@ -1,20 +1,20 @@ -title: "Learn Hyper_ By Examples: A Hello World Container in Hyper_" +title: "Learn Hyper.sh By Examples: A Hello World Container in Hyper.sh" date: 2016-05-09 21:00:00 +0800 author: hyper tags: - Container - Hyper -preview: This guide takes you through the fundamentals of using Hyper_ to containerize user applications and explain some technical facts behind them. +preview: This guide takes you through the fundamentals of using Hyper.sh to containerize user applications and explain some technical facts behind them. --- -[Hyper_](https://www.hyper.sh/) is a secure container cloud service. It allows you to deploy your containers in seconds from your laptop to the cloud. +[Hyper.sh](https://www.hyper.sh/) is a secure container cloud service. It allows you to deploy your containers in seconds from your laptop to the cloud. Running an application inside a container takes a single command: `hyper run`. > **Prerequisites:** > Please make sure you complete the following prerequisites: -> - [Open a Hyper_ account](https://console.hyper.sh/register) +> - [Open a Hyper.sh account](https://console.hyper.sh/register) > - [Generate API credential](https://docs.hyper.sh/GettingStarted/generate_api_credential.html) > - [Setup `hyper` CLI on your local computer](https://docs.hyper.sh/GettingStarted/install.html) @@ -29,13 +29,13 @@ Hello world Great, you just launched your first container on the cloud! > **NOTE:** -> This `hello world` container runs on the [Hyper_](https://hyper.sh) cloud! So don't expect to find the container or image on your local machine. +> This `hello world` container runs on the [Hyper.sh](https://hyper.sh) cloud! So don't expect to find the container or image on your local machine. In this example: * `hyper run` launches your container. -* `ubuntu` is the name of the Docker image to launch, the command will check if this image is already pulled into your account at Hyper_. If not, this image will be automatically fetched from [Docker hub](https://hub.docker.com/). +* `ubuntu` is the name of the Docker image to launch, the command will check if this image is already pulled into your account at Hyper.sh. If not, this image will be automatically fetched from [Docker hub](https://hub.docker.com/). * `/bin/echo` is executed in the container, and the output is redirected to your local terminal: ``` @@ -86,7 +86,7 @@ KiB Swap: 0 total, 0 used, 0 free. 9232 cached Mem * `top`displays the cpu memory usage and processes information. > **NOTE:** -> In Hyper_ your containers are fully isolated and do not share kernel with other containers. So > `top` and `/procs` are all expected to be accurate. +> In Hyper.sh your containers are fully isolated and do not share kernel with other containers. So > `top` and `/procs` are all expected to be accurate. To quit, type `exit` or press `Ctrl-D` to exit the interactive shell. @@ -114,7 +114,7 @@ In the output, we do not see hello world but a long string: ```shell 9c68cb7512266c41b23f4e0e92ac8a4d9425e1ee7d9df7530fcfd0ec05312053 ``` -This long string is called a container ID, which is also listed in Hyper_'s console. It uniquely identifies a container so we can work with it. +This long string is called a container ID, which is also listed in Hyper.sh's console. It uniquely identifies a container so we can work with it. We can use this container ID to see what’s happening there. First, let’s make sure our container is running. Run the `hyper ps` command, which returns the information of active containers in your account. @@ -142,7 +142,7 @@ hello world Great! The daemon is working and you have just created your first containerised server! -#### Tips: Use the Hyper_ console +#### Tips: Use the Hyper.sh console Besides `hyper` command line tool, we also provided a simple web console for you to get more information, especially when you need to get the overall status. @@ -165,4 +165,4 @@ So far, you launched your first container using the `hyper run` command. You ran * `hyper ps` - Lists containers. * `hyper logs` - Shows us the standard output of a container. -In the next blog, we will show you how to use Hyper_ to deploy real world applications and work with these containers. +In the next blog, we will show you how to use Hyper.sh to deploy real world applications and work with these containers. diff --git a/blog/source/learn-hyper_-by-examples-network-container.md b/blog/source/learn-hyper_-by-examples-network-container.md index 2798aa2..a9ae03e 100644 --- a/blog/source/learn-hyper_-by-examples-network-container.md +++ b/blog/source/learn-hyper_-by-examples-network-container.md @@ -1,17 +1,17 @@ -title: "Learn Hyper_ By Examples: How to network Hyper_ containers" +title: "Learn Hyper.sh By Examples: How to network Hyper.sh containers" date: 2016-05-11 21:00:00 +0800 author: hyper tags: - Container - Hyper - Network -preview: This guide takes you through the fundamentals of using Hyper_ to containerize user applications and explain some technical facts behind them. +preview: This guide takes you through the fundamentals of using Hyper.sh to containerize user applications and explain some technical facts behind them. --- -# Container Networking on Hyper_ cloud +# Container Networking on Hyper.sh cloud -You just previously succeeded in building and running a simple web application in the last blog of this series, but that's not enough for real web service on the Internet. So, in this section we will teach you how to network your containers on Hyper_ to set up your microservices. +You just previously succeeded in building and running a simple web application in the last blog of this series, but that's not enough for real web service on the Internet. So, in this section we will teach you how to network your containers on Hyper.sh to set up your microservices. ## Name your container @@ -36,7 +36,7 @@ d54e6f546795 training/webapp "python app.py" 11 seconds ago Container names must be unique. That means you can only call one container `web`. If you want to re-use a container name you must delete the old container. -Note that container name is not its hostname, Hyper_ container uses container ID as default hostname, and you can also configure your own by using `hyper run --hostname`: +Note that container name is not its hostname, Hyper.sh container uses container ID as default hostname, and you can also configure your own by using `hyper run --hostname`: ``` -h, --hostname Container host name @@ -45,9 +45,9 @@ Note that container name is not its hostname, Hyper_ container uses container ID ## Manage the public network of your container -You may have noticed that containers in Hyper_ have their own private IP as long as they are created. Hyper_ cloud makes the networking transparent for the end user, by using mature SDN component to build VLAN based tenants. +You may have noticed that containers in Hyper.sh have their own private IP as long as they are created. Hyper.sh cloud makes the networking transparent for the end user, by using mature SDN component to build VLAN based tenants. -Hyper_ also provides a public network solution, named floating IP, for you to connect containers from outside world., in which the basic usage of `hyper fip allocate` was showcased in the ["Run web application"](https://blog.hyper.sh/learn-hyper_-by-examples-run-your-application.html) blog. +Hyper.sh also provides a public network solution, named floating IP, for you to connect containers from outside world., in which the basic usage of `hyper fip allocate` was showcased in the ["Run web application"](https://blog.hyper.sh/learn-hyper_-by-examples-run-your-application.html) blog. ``` $ hyper fip --help @@ -56,13 +56,13 @@ Usage: hyper fip [OPTIONS] COMMAND [OPTIONS] Commands: allocate Allocate a or some IPs - associate Associate floating IP to container - disassociate Disassociate floating IP from container + attach Attach floating IP to container + detach Detach floating IP from conainer ls List all floating IPs release Release a floating IP ``` -In Hyper_, floating IP is a top level resource, that means you can manage it independently from the containers and other resources. +In Hyper.sh, floating IP is a top level resource, that means you can manage it independently from the containers and other resources. Let's create and list them: ``` @@ -75,10 +75,10 @@ Floating IP Container * `2` is the number of floating IPs you want to create, we created two IP addresses in this example -Then you can associate the IP address with a container. +Then you can attach the IP address with a container. ``` -$ hyper fip associate 162.221.195.205 web +$ hyper fip attach 162.221.195.205 web ``` Done! Now you can reach you app through `162.221.195.205:5000`. ``` @@ -89,7 +89,7 @@ Floating IP Container You can disconnect a container by disassociating the floating IP. To do this, you just need to supply the container name or container id. - $ hyper fip disassociate web + $ hyper fip detach web 162.221.195.205 As you can disconnect a container from a public network, you can also delete the floating IP to free this network resource. @@ -98,10 +98,10 @@ As you can disconnect a container from a public network, you can also delete the $ hyper fip release 162.221.195.205 ``` -## Link containers in Hyper_ cloud -The Docker style link in Hyper_ allow containers to discover each other and securely transfer information about one container to another container. When containers are linked, information about a source container can be sent to a recipient container. This allows the recipient to see selected data describing aspects of the source container. +## Link containers in Hyper.sh cloud +The Docker style link in Hyper.sh allow containers to discover each other and securely transfer information about one container to another container. When containers are linked, information about a source container can be sent to a recipient container. This allows the recipient to see selected data describing aspects of the source container. -To establish links, Hyper_ relies on the names of your containers. We have emphasized the importance of naming in previous article, and we'll soon see the reason. +To establish links, Hyper.sh relies on the names of your containers. We have emphasized the importance of naming in previous article, and we'll soon see the reason. To create a link, we use the `--link` flag. First, let's create a new container, this time one containing a database. ``` @@ -144,13 +144,13 @@ $ hyper inspect -f "{{ .HostConfig.Links }}" web You can see that the web container is now linked to the db container `db`. Which allows it to access information about the `db` container. -Then how to consume the `link`? Hyper_ exposes connectivity information for the source container to the recipient container in two ways: +Then how to consume the `link`? Hyper.sh exposes connectivity information for the source container to the recipient container in two ways: * Environment variables, * Names in the `/etc/hosts` file. ### Environment variables -Containers in Hyper_ creates several environment variables when you link containers. These environment variables in the target container (`web` container) are created based on the `--link` parameters. It will also expose all environment variables originating from the source container (`db` container) including: +Containers in Hyper.sh creates several environment variables when you link containers. These environment variables in the target container (`web` container) are created based on the `--link` parameters. It will also expose all environment variables originating from the source container (`db` container) including: * the `ENV` commands in the source container’s Dockerfile * the `-e` or `--env` options on the `hyper run` command when the source container is started @@ -158,11 +158,11 @@ Containers in Hyper_ creates several environment variables when you link contain These environment variables enable programmatic discovery from within the target container of information related to the source container. > **WARNING:** -> Don't abuse environments! All environment variables originating from Hyper_ within a container are made available to any container that links to it. This could have serious security implications if sensitive data is stored in them. +> Don't abuse environments! All environment variables originating from Hyper.sh within a container are made available to any container that links to it. This could have serious security implications if sensitive data is stored in them. -Hyper_ sets an `_NAME` environment variable for each target container listed in the `--link` parameter. This is a Docker compatible environment system. For example, if a new container called `web` is linked to a database container called `db` via `--link db:webdb`, then Hyper_ creates a `WEBDB_NAME=webdb` variable in the `web` container. +Hyper.sh sets an `_NAME` environment variable for each target container listed in the `--link` parameter. This is a Docker compatible environment system. For example, if a new container called `web` is linked to a database container called `db` via `--link db:webdb`, then Hyper.sh creates a `WEBDB_NAME=webdb` variable in the `web` container. -Hyper_ also defines a set of environment variables for each port exposed by the source container. Each variable has a unique prefix in the form: +Hyper.sh also defines a set of environment variables for each port exposed by the source container. Each variable has a unique prefix in the form: `_PORT__` @@ -172,19 +172,19 @@ The components in this prefix are: * the `` number exposed * a `` which is either TCP or UDP -Hyper_ uses this prefix format to define three distinct environment variables: +Hyper.sh uses this prefix format to define three distinct environment variables: * The `prefix_ADDR` variable contains the IP Address from the URL, for example `WEBDB_PORT_5432_TCP_ADDR=172.16.0.142`. * The `prefix_PORT` variable contains just the port number from the URL for example `WEBDB_PORT_5432_TCP_PORT=5432`. * The `prefix_PROTO` variable contains just the protocol from the URL for example `WEBDB_PORT_5432_TCP_PROTO=tcp`. -If the container exposes multiple ports, an environment variable set is defined for each one. For example, if a container exposes 4 ports that Hyper_ creates 12 environment variables, 3 for each port. +If the container exposes multiple ports, an environment variable set is defined for each one. For example, if a container exposes 4 ports that Hyper.sh creates 12 environment variables, 3 for each port. -Additionally, Hyper_ creates an environment variable called `_PORT`. This variable contains the URL of the source container’s **first exposed port**. The ‘first’ port is defined as the exposed port with the lowest number. +Additionally, Hyper.sh creates an environment variable called `_PORT`. This variable contains the URL of the source container’s **first exposed port**. The ‘first’ port is defined as the exposed port with the lowest number. For example, consider the `WEBDB_PORT=tcp://172.16.0.1422:5432` variable. If that port is used for both tcp and udp, then the tcp one is specified. -Finally, as we mentioned before, Hyper_ also exposes each originated environment variable from the source container as an environment variable in the target. For each variable Hyper creates an `_ENV_` variable in the target container. The variable’s value is set to the value Hyper_ used when it started the source container. +Finally, as we mentioned before, Hyper.sh also exposes each originated environment variable from the source container as an environment variable in the target. For each variable Hyper creates an `_ENV_` variable in the target container. The variable’s value is set to the value Hyper.sh used when it started the source container. Back to our database example, you can run the env command to list the specified container’s environment variables. ```shell @@ -203,14 +203,14 @@ DB_PORT_5432_TCP=tcp://172.16.0.137:5432 Each variable coming from the source container is prefixed with `DB_`, which is populated from the alias you specified above. You can use these environment variables to configure your applications to connect to the database on the db container. > **NOTE:** -> `--link` works everywhere in Hyper_ cloud. Unlike Docker legacy `--link`, software defined network in Hyper_ guarantee the container connectivity within the same tenant. Users should never need to care things like cross-host or customized network. +> `--link` works everywhere in Hyper.sh cloud. Unlike Docker legacy `--link`, software defined network in Hyper.sh guarantee the container connectivity within the same tenant. Users should never need to care things like cross-host or customized network. However, IP addresses stored in the environment variables are not automatically updated if the source container is restarted. And these environment variables are only set for the first process in the container. Some daemons, such as `sshd`, will scrub them when spawning shells for connection. We recommend using the host entries in `/etc/hosts` to resolve the IP address of linked containers in production. ##Updating the `/etc/hosts` file -In addition to the environment variables, Hyper_ adds a host entry for the source container to the `/etc/hosts` file. Here’s an entry for the web container: +In addition to the environment variables, Hyper.sh adds a host entry for the source container to the `/etc/hosts` file. Here’s an entry for the web container: ```shell $ hyper run -t -i --rm --link db:webdb training/webapp /bin/bash @@ -235,16 +235,16 @@ Here, you used the ping command to ping the `db` container using its host entry, > **Note:** > You can link multiple recipient containers to a single source. For example, you could have multiple (differently named) web containers attached to your `db` container. -When you restart the source container (`db` container), Hyper_ will make sure it's **IP address will not change**, allowing linked communication to continue. +When you restart the source container (`db` container), Hyper.sh will make sure it's **IP address will not change**, allowing linked communication to continue. ## Best Practice -As you can see above, Hyper_ cloud networking is simple but useful, it avoids boring users and tries to free their creativity to compose micro-services as they wish. For better usage of this networking model, some best practices are recommended here. +As you can see above, Hyper.sh cloud networking is simple but useful, it avoids boring users and tries to free their creativity to compose micro-services as they wish. For better usage of this networking model, some best practices are recommended here. -* Always naming your containers. Hyper_ `--link` uses names to identify related containers, and renaming containers afterward is costly. +* Always naming your containers. Hyper.sh `--link` uses names to identify related containers, and renaming containers afterward is costly. * Do not abuse floating IP. For security reason, and for resource saving reason. -* Expose service ports in your Dockerfile. This is not required by Hyper_, but this will bring you more automation, since only exposed ports will be added to target containers' ENV. +* Expose service ports in your Dockerfile. This is not required by Hyper.sh, but this will bring you more automation, since only exposed ports will be added to target containers' ENV. A nice example to show these best practice is [`dockercloud/haproxy`](https://github.com/docker/dockercloud-haproxy) image from Docker Inc. @@ -253,7 +253,7 @@ $ hyper run -d --name web-1 hyperhq/webapp:host python app.py $ hyper run -d --name web-2 hyperhq/webapp:host python app.py $ hyper run -d --name lb --link web-1 --link web-2 dockercloud/haproxy $ FIP=$(hyper fip allocate 1) -$ hyper fip associate $FIP lb +$ hyper fip attach $FIP lb $ curl $FIP:80 > Hello my host name is: de380811142a $ curl $FIP:80 diff --git a/blog/source/learn-hyper_-by-examples-run-your-application.md b/blog/source/learn-hyper_-by-examples-run-your-application.md index 69d2b59..dcadc4a 100644 --- a/blog/source/learn-hyper_-by-examples-run-your-application.md +++ b/blog/source/learn-hyper_-by-examples-run-your-application.md @@ -1,17 +1,17 @@ -title: "Learn Hyper_ By Examples: Run Your application" +title: "Learn Hyper.sh By Examples: Run Your application" date: 2016-05-10 22:00:00 +0800 author: hyper tags: - Container - Hyper - Network -preview: This article shows how to use Hyper_ to deploy a real-world application and play with it. +preview: This article shows how to use Hyper.sh to deploy a real-world application and play with it. --- # Run Your application -In the previous ["*Run a Hello world*"](https://blog.hyper.sh/learn-hyper_-by-examples-hello-world-in-a-container.html) the first container in Hyper_ has been launched using the `hyper run` command. In this article, let's go further. +In the previous ["*Run a Hello world*"](https://blog.hyper.sh/learn-hyper_-by-examples-hello-world-in-a-container.html) the first container in Hyper.sh has been launched using the `hyper run` command. In this article, let's go further. ## More about the hyper command line tool @@ -59,10 +59,10 @@ Fetch the logs of a container > For full details and examples of each command, please checkout the > [hyper command reference](https://docs.hyper.sh/Reference/CLI/index.html) on the official [hyper.sh](https://hyper.sh) site. -## Running a web application in Hyper_ +## Running a web application in Hyper.sh So now you've learned a bit more about the `hyper` client you can move onto the important stuff: running real-world applications. We -start this by running an example web application in Hyper_. +start this by running an example web application in Hyper.sh. This web application is a popular Python Flask application image from docker hub. @@ -70,7 +70,7 @@ Again, we start with a `hyper run` command. ```shell $ hyper run -d training/webapp python app.py ``` -You've already seen the `-d` flag which tells Hyper_ to run the +You've already seen the `-d` flag which tells Hyper.sh to run the container in the background. You've specified an image: `training/webapp`. This image is a @@ -112,9 +112,9 @@ CMD ["python", "app.py"] ``` > **Note:** -> Since Docker image is the only image specification Hyper_ support for now, you can learn more about how to expose ports in Docker images in [its official doc](https://docs.docker.com/engine/userguide/containers/dockerimages/). +> Since Docker image is the only image specification Hyper.sh support for now, you can learn more about how to expose ports in Docker images in [its official doc](https://docs.docker.com/engine/userguide/containers/dockerimages/). -Note that in Hyper_ , **there's no need to do port mapping**, because hypervisor based containers uses SDN to ensure network connectivity in the same tenant (and isolation between different tenants). So any ports exposed in your image can be reached directly, for example if we know the IP address of this container: +Note that in Hyper.sh , **there's no need to do port mapping**, because hypervisor based containers uses SDN to ensure network connectivity in the same tenant (and isolation between different tenants). So any ports exposed in your image can be reached directly, for example if we know the IP address of this container: ``` $ hyper inspect --format '{{ .NetworkSettings.IPAddress }}' berserk_yalow 172.16.0.132 @@ -125,11 +125,11 @@ And even if your containerised application works on ports that are not exposed i ## Reach your application from outside world -The previous section described that containers in Hyper_ can be reached through IP, but after all, those are still private IP addresses. How can we visit our application from outside world? +The previous section described that containers in Hyper.sh can be reached through IP, but after all, those are still private IP addresses. How can we visit our application from outside world? It's quite simple: using a floating IP. -Floating IP (or fip) is a real **public IP** allocated by SDN component in Hyper_ and can be associated with specific container. That's a standard workflow in many mature cloud platforms like AWS, GCE or OpenStack. We allow you to do this in a container cloud. +Floating IP (or fip) is a real **public IP** allocated by SDN component in Hyper.sh and can be attached with specific container. That's a standard workflow in many mature cloud platforms like AWS, GCE or OpenStack. We allow you to do this in a container cloud. ``` $ hyper fip allocate 1 @@ -145,9 +145,9 @@ Creates some new floating IPs by the user ``` * `COUNT` is the number of floating IPs you want to create. In this example, we created only one. -Then we can associate this IP to your application. +Then we can attach this IP to your application. ``` -$ hyper fip associate 162.221.195.205 berserk_yalow +$ hyper fip attach 162.221.195.205 berserk_yalow ``` Try to visit it from laptop: @@ -183,7 +183,7 @@ the application running on port `5000` and the access log entries. You may have noticed in previous section, we got the IP address of container using `hyper inspect` command. -This command is a low-level request into your Hyper_ container and returns a JSON document containing useful configuration and status information for the specified container. +This command is a low-level request into your Hyper.sh container and returns a JSON document containing useful configuration and status information for the specified container. ```shell $ hyper inspect nostalgic_morse ``` @@ -277,4 +277,4 @@ Otherwise, you should use `hyper rm -f` to delete the container forcefully. # Next steps -Congratulations, you have run through a full application life-cycle workflow! In next article, we'll dive into another exciting part of containers on Hyper_ cloud: Networking! +Congratulations, you have run through a full application life-cycle workflow! In next article, we'll dive into another exciting part of containers on Hyper.sh cloud: Networking! diff --git a/blog/source/performance_runv_gce.md.bak b/blog/source/performance_runv_gce.md.bak new file mode 100644 index 0000000..82e36e4 --- /dev/null +++ b/blog/source/performance_runv_gce.md.bak @@ -0,0 +1,140 @@ +title: Performance test of running virtualized container on Google GCE +date: 2017-09-22 21:00:00 +0800 +update: 2017-09-22 21:00:00 +0800 +author: hyper +tags: + - runV + - Google GCE + - Google Compute Engine + - Google Cloud + - Container + - Docker + +preview: Performance test of running virtualized container on Google GCE + +--- + +Different from Linux Container, [runV](github.com/hyperhq/runv) is a virtualized container technology that uses hypervisor (KVM/QEMU, Xen) as the underlying runtime. It provides the hardware-enforced secure isolation to the existing container framework. Last week, we tagged 1.00 version of runV. The new release includes several major upgrades, including a Xen PV driver, which allows runV to be deployed on public IaaS, i.e. Google GCE. + +Following the new release, we did some performance test this week. This post includes the result and preliminary analysis. + +## Case 1: single container per instance + +First, we launched a `g1-small` instance on GCE, and setup runV in the instance using Xen PV mode (which involves a Dom0 as the host), and launch a single virtual container to run the test. + +#### Setup +- GCE instance: + - Instance Size: g1-small + - vCPU: 1 + - Memory: 1.7GB + - Disk: 40GB SSD persistent disk + - GCE limits: 1200 IOPS (READ, WRITE), 19.20MB/s throughput (READ, WRITE) +- runV: + - Xen Dom0 Memory: 1GB + - Container (DomU) vCPU: 1 + - Container Memory: 512MB + +#### Result +Raw test results, fio config files and test scripts can be found at: + +- [Single Container Disk IO](https://gist.github.com/bergwolf/a405f40f23d15f198bafd263bf0fe4dd) +- [Single Container CPU/Memory/Network](https://gist.github.com/bergwolf/49a248e019780168109d7861c3350a0d) + +#### CPU +|-|-|-|-|-| avg| +|---|---|---|---|---|---| +|runV XenPV| 21s 221ms| 21s 205ms| 21s 151ms| 21s 100ms| 21s 169ms| +|native GCE| 20s 940ms| 20s 981ms| 21s 90ms| 20s 917ms| 20s 982ms| + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/59c48e61ab0ab52efb8cc781/5218358ef15e1016772e6de85ebcb66a/Single_Container_-_CPU.png) + +#### Memory + +|-| runV XenPV| GCE native| +|---|---|---| +|avg seq write (MB/s)| 7237| 7297| +|avg rand write (MB/s)| 3263| 3240| + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/59c48e61ab0ab52efb8cc781/9f773b26fe5e0e1586cacf247b6f39ff/Single_Container_-_Memory.png) + +#### Disk I/O +| IO type (KB/s) |runV XenPV (raw device) |runV XenPV (ext4)|Instnace (raw device) |Instance (ext4)| +|---|---|---|---|---| +|128k randread| 24669.75| 24621.75| 24716.25 |24612.25| +|128k randwrite| 24675.75 |24621.5| 24700.5| 24616.75| +|4k randread| 6040.75| 6010.75| 6029.75| 6011.75| +|4k randwrite| 6017.25| 6010.5| 6016| 6011.25| + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/59c48e61ab0ab52efb8cc781/fc483fcb78906ea266dd4f89d811a657/Single_Container_-_Disk_IO.png) + +#### Network +|||||| Gbits/sec| +|---|---|---|---|---|---| +|runV XenPV| 8.40| 8.44| 8.56| 8.34| 8.435| +|Docker on GCE| 6.24| 6.25| 6.11| 6.21| 6.2025| + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/59c48e61ab0ab52efb8cc781/9f6f0e494511b156518999e7cba71ad7/Single_Container_-_Network.png) + +## Case 2: 100 containers per instance + +Another case we did is to launch a customized instance with bigger CPU/Mem size, and launch 100 virtual containers simultaneously in the instance. + +#### Setup +- GCE instance: + - Instance Size: customized + - vCPU: 24 + - Memory: 128GB + - Disk: 4 * 100GB SSD persistent disk + - GCE limits: 3000 IOPS (READ, WRITE), 48MB/s throughput (READ, WRITE) + - We create 25 partitions (4GB each) on every disk. In total, there are 25 * 4 = 100 paritions. And we assign 100 partitions to 100 container with passthrough mode + +- runV: + - Xen Dom0 Memory: 10GB + - Container (DomU) vCPU: 1 + - Container Memory: 1GB + + +#### Result +Raw test results, fio config files and test scripts can be found at: +- [100 runV containers vs. docker containers cpu/memory/network test](https://gist.github.com/bergwolf/4e1b951f49f1087c9155abde5afdee65) +- [runV 100 containers disk IO](https://gist.github.com/bergwolf/4e38649193394367ef19dece73837374) +- [host 100 fs IO test](https://gist.github.com/bergwolf/6a91a22c2cf594eeba8cb2e9ec4244ba) + +#### CPU +|| sysbench runtime (seconds)| +|---|---| +|runV(XenPV)|51.460241| +|docker|49.809762| + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/59c48e61ab0ab52efb8cc781/cffba97cef9a7e49cc28cd1345daaa94/100_Containers_-_CPU.png) + +#### Memory +||seq read(MB/s)| random read(MB/s)| seq write(MB/s)| random write(MB/s)| +|---|---|---|---|---| +|runV(XenPV)|276960| 184310| 176670| 95210| +|docker|273570| 183570| 166460| 91180| + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/59c48e61ab0ab52efb8cc781/1dcfad4c19862d1a05082755a9239dd7/100_Containers_-_Memory.png) + +#### Disk I/O +|KB/s| XenPV| XenPV| XenPV| XepPV| XenPV avg| GCE native avg| +|---|---|---|---|---|---|---| +|128k randread| 216601| 216629| 216614| 216604| 216612| 224867| +|128k randwrite| 216417| 216382| 216340| 216414| 216388.25| 224653| +|4k randread| 52829| 52840| 52836| 52845| 52837.5| 55266| +|4k randwrite| 52680| 52668| 52685| 52684| 52679.25| 53442| + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/59c48e61ab0ab52efb8cc781/76809231f60cce4bffef7fd2f54facf8/100_Containers_-_Disk_IO.png) + +#### Network +||Gbits/s| +|---|---| +|runV(XenPV)|3.89| +|docker|1.03| + +![](https://trello-attachments.s3.amazonaws.com/5700ea0da7030dcf7485ed70/59c48e61ab0ab52efb8cc781/8960d2ccd6599e8a6786a1a9ae5ee399/100_Containers_-_Network.png) + +## Result Analysis +- The performance of runV (with Xen PV mode) on GCE is almost identical with native GCE instance in terms of CPU, memory and Disk I/O. +- GCE block device has read/write cache, and its IO throttling method is slow to start. This leads to very high performance at the very beginning of each test run, which we chose to ignore. +- Network performance is faster than docker container on GCE. diff --git a/blog/source/release-runv-0.7.md b/blog/source/release-runv-0.7.md new file mode 100644 index 0000000..ab3993d --- /dev/null +++ b/blog/source/release-runv-0.7.md @@ -0,0 +1,55 @@ +title: "Release runV 0.7" +date: 2016-10-29 00:00:00 +0800 +author: hyper +tags: + - Docker + - Containers + - runV + - HyperContainer +preview: "Today, we are happy to announce the new v0.7 release of runV and HyperContainer, bringing them to more platforms: ARM64, Power and Mainframe (s390x)." + +--- + +For those who have been following us since the early days, you may know that Hyper started as two open source projects: [HyperContainer](http://www.hypercontainer.io), which pioneered the territory of virtual containers, and [runV](https://github.com/hyperhq/runv), the hypervisor-based equivalent of [runC](https://github.com/opencontainers/runc). The combination of sub-second boot performance and VM-level isolation enables a new wave of container native cloud infrastructure, such as [Hyper.sh](https://hyper.sh). + +Since day one, these projects have aimed to be **vendor neutral**, supporting multiple hypervisors (**KVM**, **Xen**, **VirtualBox**). Today, we are happy to announce the new v0.7 release of runV and HyperContainer, bringing them to more platforms: + +- x86 +- ARM64 +- Power +- Mainframe (s390x) + +## HyperContainer + +- More platform supports: s390x, ppc64le, and arm64 +- VM Template: faster boot performance (130ms) and less memory consumption (save 80MB per pod/VM, #415) +- Improve gRPC APIs. +- Improve streaming IO (attach & exec) for containers. +- Many other fixes and improvements + +## runV + +- Support system arch s390x and ppc64le (#312) +- Support system arch ARM64 (#360) +- Enable VM template for runV and runV-containerd, which improves the boot performance to 130ms and reduces 80MB memory consumption per container. (#303, #304) +- Enable CNI, OVS and improve the networking configurations. (#286, #307) +- Add QoS Control for network interface. (#331) +- Allow one volume to be mounted to multiple mount points of one container. (#329) +- Improve streaming IO for containers +- Move dependencies from Godep to vendors +- Many other fixes and improvements + +## Furthure Information +- Code + - https://github.com/hyperhq/runv + - https://github.com/hyperhq/hyperd/ +- Download + - https://github.com/hyperhq/runv/releases + - https://github.com/hyperhq/hyperd/releases +- Docs: http://docs.hypercontainer.io + +-------------------- + +Thanks, + +The Hyper Team diff --git a/blog/source/run-desktop-applications-in-hyper_.md b/blog/source/run-desktop-applications-in-hyper_.md index be32d7a..42b2491 100644 --- a/blog/source/run-desktop-applications-in-hyper_.md +++ b/blog/source/run-desktop-applications-in-hyper_.md @@ -1,27 +1,27 @@ -title: "Run Desktop Applications in Hyper_" +title: "Run Desktop Applications in Hyper.sh" date: 2016-07-26 14:00:00 +0800 author: hyper -preview: Hyper_ cloud is designed to work well with many kinds of applications. That's why most people use it to deploy their applications in a cloud environment. This is great, and saves people huge headaches, but this article will show you a not-so-typical way. +preview: Hyper.sh cloud is designed to work well with many kinds of applications. That's why most people use it to deploy their applications in a cloud environment. This is great, and saves people huge headaches, but this article will show you a not-so-typical way. --- -In this article, we will show how to use Hyper_ to help run desktop applications on the cloud. The basic idea is that we will launch a Linux desktop version OS on Hyper_ cloud and then we can launch Chrome, Firefox etc in that container by using VNC. +In this article, we will show how to use Hyper.sh to help run desktop applications on the cloud. The basic idea is that we will launch a Linux desktop version OS on Hyper.sh cloud and then we can launch Chrome, Firefox etc in that container by using VNC. > More about VNC: VNC is a great client/server tool to access your computers remotely. Please check [tigervnc](http://tigervnc.org/) for example if you are not familiar with it. -Wait, why would we even want to run all these applications in Hyper_? +Wait, why would we even want to run all these applications in Hyper.sh? The most common case is that users may not want to install all the things on their PCs. They may also want the ability to delete an application and know it is gone without some random file hanging around. Or, they may just want a machine lives in the cloud! -Obviously, running those applications in Hyper_ cloud will help a lot. What's more, now users can control how much CPU and Memory the application uses, and visit this application anywhere as long as they have Internet. +Obviously, running those applications in Hyper.sh cloud will help a lot. What's more, now users can control how much CPU and Memory the application uses, and visit this application anywhere as long as they have Internet. Let's see how to do! -### Run desktop CentOS in Hyper_ cloud +### Run desktop CentOS in Hyper.sh cloud -The first use case will show how to run a desktop version CentOS 6 container in Hyper_. +The first use case will show how to run a desktop version CentOS 6 container in Hyper.sh. #### Launch a CentOS 6 container in cloud @@ -57,34 +57,34 @@ $ vncserver ``` This command will ask you for a remote access password, feel free to choose your favorite one here, let's say `PASSWORD`. -Exit your Hyper_ container, a desktop CentOS 6 is ready in the cloud. +Exit your Hyper.sh container, a desktop CentOS 6 is ready in the cloud. #### Use `fip` to connect your desktop container -The floating IP or `fip` feature in Hyper_ cloud makes it so easy to connect to your cloud application from anywhere: +The floating IP or `fip` feature in Hyper.sh cloud makes it so easy to connect to your cloud application from anywhere: ```shell $ fip=`hyper fip allocate 1` -$ hyper fip associate ${fip} ${containerId} +$ hyper fip attach ${fip} ${containerId} ``` Done! Now you can use VNC client to connect your CentOS container at `fip:1`. ### Try to experience more -The most exciting part of "container revolution" is finally we can ship applications to cloud in an elegant way. Thanks to container images! In Hyper_, you can experience more desktop applications by deploying them in one shell, and connect them using `fip` from VPN client. +The most exciting part of "container revolution" is finally we can ship applications to cloud in an elegant way. Thanks to container images! In Hyper.sh, you can experience more desktop applications by deploying them in one shell, and connect them using `fip` from VPN client. -For example, `kaixhin/vnc` is a image which provide you with `Ubuntu Core 14.04 + LXDE desktop + Firefox browser + TightVNC server`. You can deploy it to Hyper_ easily: +For example, `kaixhin/vnc` is a image which provide you with `Ubuntu Core 14.04 + LXDE desktop + Firefox browser + TightVNC server`. You can deploy it to Hyper.sh easily: ```shell $ hyper run -d kaixhin/vnc -$ hyper fip associate 162.221.195.27 0649e517b002 +$ hyper fip attach 162.221.195.27 0649e517b002 ``` -Then you can use this Ubuntu workstation on Hyper_ cloud by connecting to `162.221.195.27:1` with password "password", and browser Internet with FireFox. +Then you can use this Ubuntu workstation on Hyper.sh cloud by connecting to `162.221.195.27:1` with password "password", and browser Internet with FireFox. Another similar example is for LXDE desktop users: ```shell $ hyper run -d dorowu/ubuntu-desktop-lxde-vnc -$ hyper fip associate 162.221.195.28 c8a584dcbb9b +$ hyper fip attach 162.221.195.28 c8a584dcbb9b ``` Visit your Ubuntu through `http://162.221.195.28:6080/vnc.html`, and use `ubuntu` as password. diff --git a/blog/source/serverless-ci-hyper-docker-integration-for-buildbot.md b/blog/source/serverless-ci-hyper-docker-integration-for-buildbot.md new file mode 100644 index 0000000..402357a --- /dev/null +++ b/blog/source/serverless-ci-hyper-docker-integration-for-buildbot.md @@ -0,0 +1,69 @@ +title: "Serverless CI - Hyper.sh integration for Buildbot" +date: 2016-10-20 20:00:00 +0800 +author: hyper +tags: + - Container + - Docker Hosting + - Buildbot + - Continious Integration + - Serverless +preview: Via an integration with Hyper.sh, version 0.9.1 of BuildBot, the open source Continuous Integration (CI) framework, will include support for ‘serverless CI’. Buildbot is used for CI by many large open source projects including OpenVPN, the Python language and the Perl language, mostly because the tool caters very well to teams who have ‘outgrown’ Drone, Travis, AppVeyor or similar entry-level hosted CI tools. + +--- + +![Waiting for the build...](images/serverless-ci-hyper-docker-integration-for-buildbot/checks-page.png) + +Via an integration with Hyper.sh, version 0.9.1 of BuildBot, the open source Continuous Integration (CI) framework, will include support for ‘serverless CI’. + +Buildbot is used for CI by many large open source projects including OpenVPN, the Python language and the Perl language, mostly because the tool caters very well to teams who have ‘outgrown’ Drone, Travis, AppVeyor or similar entry-level hosted CI tools. + +If you just want to jump straight in, you can follow the tutorial [here.](https://hyper.sh/howto/how-to-use-hyper.sh-to-deploy-your-buildbot.html) + +## CI headaches + +Many teams find themselves facing a few recurring challenges with CI; cost, maintenance and security. + +“Buildbot is a Continuous Integration Framework that lets you implement the exact process you need unlike the generic processes supported by hosted CI. But this is at the price of building and maintaining your own infrastructure for the build cluster. It takes your attention off the main goal of developing software.”, says Pierre Tardy, Tech Lead on Buildbot. + +“Furthermore”, Pierre explains “we can’t just go ahead and build every pull request in our own infrastructure as that would make us vulnerable to attackers.” Indeed, as the CI’s job is to test the code of open-source contributors, this basically leaves the machine running that code completely open. + +“That leaves us with a tricky choice.”, he continues, “Either we manually sanity check the pull requests before we build them which is time consuming, or we spin up a new VM for every build job, which is prohibitively expensive and slow.” + +Buildbot’s integration with Hyper.sh addresses all of the above. + +## Serverless CI with Hyper.sh + +Hyper.sh is a container-native docker hosting service. + +Different from traditional IaaS and CaaS hosting providers, Hyper.sh does not employ VM clusters. Instead Docker containers are the only object that users work with. + +Hyper.sh's secret sauce is its docker container runtime technology, which combines VM-level isolation with the speed and immutability of a container, allowing multi-tenant containers to run safely on the same physical host. + +Whenever a new build job is started in Buildbot the Hyper.sh plugin takes care of spinning up a Hyper.sh container in a matter of seconds. The build job runs in a container, which takes advantage of Hyper.sh hypervisor level isolation, and delivers the build results back to the Buildbot server. + +The new integration also supports parallelisation which massively reduces build times when building against multiple targets. Buildbot themselves saw a 300% speed increase in their own builds. + +What you get is fast, parallelised, secure builds that due to Hyper.sh’s tiny image sizes also provide massive cost reductions. + +“We estimated costs for builds” says Pierre “and thanks to the per second billing Hyper came in around 10 times cheaper than expected!” + +Buildbot's findings are illustrated in the diagram below and that’s why we’re calling this ‘Serverless CI’. Apart from the Buildbot master itself you only pay when you’re building and the integration with Buildbot is seamless. After configuring some global settings, the rest works out of the box. + +__The Hyper_ integration with Buildbot is available Buildbot 0.9.1.__ + +Want to get started now? Check the 'Getting Started' section at the bottom of the post. + +![Resource Comparison](images/serverless-ci-hyper-docker-integration-for-buildbot/comparison.png) + +> ## Serverless CI with Jenkins? +>We're also working on a Hyper.sh plugin to provide serverless Jenkins CI. Keep an eye on [twitter](https://twitter.com/hyper_sh) for more news coming soon. + +## Getting Started + +If you'd like to get started straight away [sign-up for Hyper.sh here](https://hyper.sh/), check out [Buildbot here](http://buildbot.net/), and follow the full Hyper.sh + Buildbot tutorial [here](https://hyper.sh/howto/how-to-use-hyper.sh-to-deploy-your-buildbot.html). + +Any questions? Get in touch on [talk@hyper.sh](mailto:talk@hyper.sh) + + + + diff --git a/blog/source/serverless-ci-with-hyper-and-jenkins.md b/blog/source/serverless-ci-with-hyper-and-jenkins.md new file mode 100644 index 0000000..8ca7815 --- /dev/null +++ b/blog/source/serverless-ci-with-hyper-and-jenkins.md @@ -0,0 +1,121 @@ +title: Serverless CI - The Hyper.sh plugin for Jenkins +date: 2017-02-23 19:00:00 +0100 +author: hyper +tags: + - Docker + - Jenkins + - Container + - Serverless + - Continuous Integration + - Continuous Delivery + +preview: Jenkins is the market leader for CI/CD workloads and uses a master/slave configuration for builds. Now you can use the Hyper.sh plugin to get per-second billed 'serverless' build slaves. + +--- + +## What is Hyper.sh? + +[Hyper.sh](https://hyper.sh/docker-hosting) is a container-native cloud service. With Hyper.sh you do not have to maintain a VM cluster and you can still use the same Docker tools, like Docker Compose, that you're used to using locally. + +Hyper.sh’s secret sauce is its container runtime technology, which combines VM-level isolation with the speed and immutability of a container, making using and deploying containers to production as simple as using Docker on your laptop. + +## Why run Jenkins builds on Hyper.sh? + +Jenkins is the market leader for CI/CD workloads and uses a master/slave configuration for builds. Sometimes this means that you end up with a lot of VMs that you need to manage, patch and generally worry about. There are some plugins for auto-scaling (EC2 Plugin, Digital Ocean plugin) but they are VM based and therefore slow. Do you want to wait 1-2 minutes for a VM that then runs a 3 minute build job and then be billed for a full hour? Probably not. + +The Hyper.sh plugin allows users to launch containerized on-demand Jenkins build slaves. This presents a number of benefits: + + * Faster start times: 3~10 seconds vs. 1-2 minutes elsewhere + * Lower Cost: per second billing vs. hourly pricing + * Easy to use: no changes to your existing workflow + + Convinced? Great, let's get started. + +## Getting Started + +We're going to assume that you've already signed up to Hyper.sh but if not check out the quick start guide right [here](https://docs.hyper.sh/GettingStarted/index.html). + +### Deploy the Jenkins master + +> Please note that we're using a pre-built version of Jenkins that we call Hykins. This is just a vanilla Jenkins master with some plugins and configuration installed for you. If you'd like to start from a vanilla Jenkins image please see the Dockerfile for Hykins [here.](https://github.com/hyperhq/hykins/blob/master/Dockerfile) + +> Lastly, in this example we're running the Jenkins master on Hyper.sh, but you could also run the master elsewhere and just use Hyper.sh to supply build slaves. + +Now we need to deploy the Jenkins master, which requires only 3 commands in Hyper.sh: + + +``` +// launch a jenkins server container +$ hyper run --name hykins -d -P \ + --size=m1 \ + -e ADMIN_USERNAME=xxxxx \ + -e ADMIN_PASSWORD=xxxxx \ + -e ACCESS_KEY= \ + -e SECRET_KEY= \ + hyperhq/hykins + +// attach a public ip to the container +$ hyper fip allocate 1 + +$ hyper fip attach hykins +``` +> You can find your ACCESS KEY and SECRET KEY in ~/.hyper/config.json after installing the CLI + +You can now connect to the Jenkins master on `:8080` + +### Create a new build job + +* Create a "Freestyle project" + +* Check "Run the build inside Hyper.sh container" + * Docker Image: jenkinsci/slave + * Container Size: S4 + +![Run the build inside Hyper.sh container](images/run-build-on-hyper.png) + + +* Add build step "Execute shell" + * Command: + +``` +set +x +echo ------------------------------------------------ +cat /etc/os-release +echo ------------------------------------------------ +cat /proc/cpuinfo | grep -E '(processor|model name|cpu cores)' +echo ------------------------------------------------ +cat /proc/meminfo | grep ^Mem +echo ------------------------------------------------ +``` +### Trigger build + +In this tutorial we’ll trigger the build manually by clicking on 'Build Now' on the project page, but normally you’d configure an SCM to trigger the build. + +Build Now + +### View results + +![Jenkins build results](images/jenkins-build-results.png) + +## Summary + +And that's it! You just ran a build on a per-second billed container that cleaned up after itself leaving you with zero maintenance overhead. + +**You may have noticed** that the build was a bit slow the first time round. That's because Hyper.sh needed to pull the slave image. Try again and you'll see that it's significantly faster! + +### Final note on build workspaces + +It’s common with some teams using long running Jenkins slaves to use the ‘Workspace’ tab in the GUI to debug the results of a build. With Serverless CI this is not possible because the build container is destroyed after each build. + +Therefore if you would like inspect the post-build state (or keep actual build artifacts of course) we recommend that you use the ‘Archive the artifacts’ options in the ‘Post-build Actions’ section of the build page. + +### Where can I learn more or get help? + +That’s all for now. For more info, please visit [https://github.com/hyperhq/hykins.](https://github.com/hyperhq/hykins) + +If you have any feedback, you can contact us in any of the following ways. + +[Twitter](https://twitter.com/hyper_sh), [Slack](https://slack.hyper.sh/), [Forum](https://forum.hyper.sh/), [Mail](mailto:talk@hyper.sh) + +Happy Hacking! +The Hyper Crew diff --git a/blog/source/user-interview-charlie-offenbacher.md b/blog/source/user-interview-charlie-offenbacher.md new file mode 100755 index 0000000..12b18ed --- /dev/null +++ b/blog/source/user-interview-charlie-offenbacher.md @@ -0,0 +1,28 @@ +title: "User Interviews - Charlie Offenbacher - CTO @ thebookrocket.com" +date: 2016-11-16 21:50:00 +0800 +author: hyper +tags: + - Docker + - Container + - Joyent + - Tutum + - Docker Cloud + - Docker Hosting + - Hyper +preview: In the first of a new series of user interviews, Charlie Offenbacher from [thebookrocket.com](http://thebookrocket.com/), tells us why he chose Hyper.sh over the other Docker hosting options currently in the market. + +--- + +In the first of a new series of user interviews, Charlie Offenbacher CTO of [thebookrocket.com](http://thebookrocket.com/) tells us why he chose [Hyper.sh](https://hyper.sh/) over first running his own Docker hosts, then Tutum (now Docker Cloud) and then Joyent. + +[thebookrocket.com](http://thebookrocket.com/) is an amazing idea. Remember all those old college text books that you have stashed in the attic? You can now sell them easily and for a reasonable price. Or as they put it: _"It's like Kayak, but for books."_ + + + +We'd like to thank Charlie for spreading the word about Hyper.sh and you can look forward to another user interview in the coming days. + +Would you like to share your Hyper.sh experiences with our community? Drop us a mail on [talk@hyper.sh](mailto:talk@hyper.sh) + +Happy Hacking, + +The Hyper.sh Crew diff --git a/blog/source/user-interview-conor-nash.md b/blog/source/user-interview-conor-nash.md new file mode 100755 index 0000000..eb30044 --- /dev/null +++ b/blog/source/user-interview-conor-nash.md @@ -0,0 +1,28 @@ +title: "User Interviews - Conor Nash - conornash.com" +date: 2016-12-09 21:30:00 +0800 +author: hyper +tags: + - Docker + - Container + - Apache Airflow + - Data Science + - NoOps + - Docker Hosting + - Serverless +preview: "In the second of our new series of user interviews, Conor Nash from [conornash.com](http://conornash.com/), tells us how Hyper.sh helps him to scale his St.Louis based data science consultancy. Hint: It's because Hyper.sh does the operations for him." + +--- + +In the second of a new series of user interviews, Conor Nash from [conornash.com](http://conornash.com/), tells us how Hyper.sh helps him to scale his St.Louis based data science consultancy. + +Conor explains that by handing over the operations work to Hyper.sh he can concentrate on running more value adding workloads for his clients: more than he could ever have achieved if his team were wrangling server clusters. + + + +We'd like to thank Conor for spreading the word about Hyper.sh and his valuable feedback. If you're in the St. Louis area and need data science consulting, we suggest you get in touch. He really knows his stuff! + +Would you like to share your Hyper.sh experiences with our community? Drop us a mail on [talk@hyper.sh](mailto:talk@hyper.sh) + +Happy Hacking, + +The Hyper.sh Crew diff --git a/blog/source/user-interview-gareth-rushgrove.md b/blog/source/user-interview-gareth-rushgrove.md new file mode 100755 index 0000000..2f54526 --- /dev/null +++ b/blog/source/user-interview-gareth-rushgrove.md @@ -0,0 +1,29 @@ +title: "User Interviews - Gareth Rushgrove - Puppet & DevopsWeekly" +date: 2017-02-01 16:00:00 +0100 +author: hyper +tags: + - Docker + - Container + - Batch Workloads + - Configuration Management + - Puppet + - NoOps + - Docker Hosting + - Serverless +preview: "In this user interview Gareth Rushgrove of [Puppet](https://puppet.com/) & [Devops Weekly](http://www.devopsweekly.com/) tells us how Hyper.sh makes it simple for him to quickly develop and share Puppet configurations, amongst a few other things!" + +--- + +In this user interview Gareth Rushgrove of [Puppet](https://puppet.com/) & [Devops Weekly](http://www.devopsweekly.com/) tells us how Hyper.sh makes it simple for him to quickly develop and share Puppet configurations, amongst a few other things! + +We also touch on why Hyper.sh is ideal for batch workloads and discuss a couple of ideas about how [Hyper Cron](https://docs.hyper.sh/Feature/container/cron.html) could be extend to support batch work flows too. + + + +We'd like to thank Gareth for spreading the word about Hyper.sh and his valuable feedback. If you want to run Puppet on Hyper.sh, check out Gareth's repository here: [https://github.com/puppetlabs/puppet-in-docker-examples/tree/master/hyper_](https://github.com/puppetlabs/puppet-in-docker-examples/tree/master/hyper_) + +Would you like to share your Hyper.sh experiences with our community? Drop us a mail on [talk@hyper.sh](mailto:talk@hyper.sh) + +Happy Hacking, + +The Hyper.sh Crew diff --git a/blog/source/user-interview-tom-maiaroto.md b/blog/source/user-interview-tom-maiaroto.md new file mode 100755 index 0000000..53ab6f5 --- /dev/null +++ b/blog/source/user-interview-tom-maiaroto.md @@ -0,0 +1,25 @@ +title: "User Interviews - Tom Maiaroto - serifandsemaphore.io" +date: 2017-02-01 16:00:00 +0100 +author: hyper +tags: + - Docker + - Container + - Data Science + - NoOps + - Docker Hosting + - Serverless +preview: "In this interview user Tom Maiaroto explains how Hyper.sh is removing the ops overhead so he can concentrate on his clients. He talks about running ETL tasks with Hyper.sh, how [Hyper Cron](https://docs.hyper.sh/Feature/container/cron.html) has helped him to get further with this, and last we touch on how some sort of queue in Hyper.sh would be useful." + +--- + +In this interview user Tom Maiaroto from [serifandsemaphore.io](https://serifandsemaphore.io/) explains how Hyper.sh is removing the ops overhead so he can concentrate on his clients. He talks about running ETL tasks with Hyper.sh, how [Hyper Cron](https://docs.hyper.sh/Feature/container/cron.html) has helped him to get further with this, and last we touch on how some sort of queue in Hyper.sh would be useful. + + + +We'd like to thank Tom for spreading the word about Hyper.sh and his valuable feedback. + +Would you like to share your Hyper.sh experiences with our community? Drop us a mail on [talk@hyper.sh](mailto:talk@hyper.sh) + +Happy Hacking, + +The Hyper.sh Crew diff --git a/blog/source/windows-cli-beta-release.md b/blog/source/windows-cli-beta-release.md new file mode 100755 index 0000000..8e0af34 --- /dev/null +++ b/blog/source/windows-cli-beta-release.md @@ -0,0 +1,21 @@ +title: "Windows CLI (Beta) Release" +date: 2016-08-24 17:20:00 +0800 +author: hyper +tags: + - Docker + - Container + - Windows + - Hyper +preview: We are happy to announce the beta release of Hyper.sh CLI on Windows. It shares the same code base and feature set of other platforms, allowing you to easily deploy containers in Hyper.sh cloud. + +--- + +Hi, + +We are happy to announce the beta release of Hyper.sh CLI on Windows. It shares the same code base and feature set of other platforms, allowing you to easily deploy containers in Hyper.sh cloud. + +The installation instruction can be found [here](https://docs.hyper.sh/GettingStarted/install.html). Please note that this package on Windows is beta version, you can file a bug at [here](https://github.com/hyperhq/hypercli/issues) if you find any issue. + +Happy Hacking, + +The Hyper.sh Crew diff --git a/blog/theme/_footer.html b/blog/theme/_footer.html index 27801c0..328fa58 100755 --- a/blog/theme/_footer.html +++ b/blog/theme/_footer.html @@ -5,13 +5,10 @@ document.write(new Date().getFullYear()); - Powered by Ink + Powered by Ink - + + + + diff --git a/blog/theme/_header.html b/blog/theme/_header.html index d1b455d..ad2a39c 100755 --- a/blog/theme/_header.html +++ b/blog/theme/_header.html @@ -1,3 +1,4 @@ +