fearenales

Hi! I'm part of Azuki, the startup that created azk.

azk (http://github.com/azukiapp/azk) is a lightweight open source development environment orchestration tool. It runs on top of Docker containers, but we tried to make it super simple to use.

We liken it to YouTube whereas Docker is more like Adobe Flash Video.

azk is versatile, but right now we're focused on the simplest use cases hence our focus on DigitalOcean as deployment option.

Accordingly, we created the "Run Project" button. You can add it to your public repos on GitHub and any visitor can easily and safely run your code locally in very few steps.

The only thing you'll have to add to your code is an Azkfile, a simple manifest file listing the required elements for the code's environment (OS, language, database etc.).

We even created this demo gallery with forks from GitHub to prove that http://run.azk.io . We'll be continuously adding new projects to it.

In this tutorial published by DigitalOcean, we demonstrate how easy it is to run code "in natura" straight from GitHub with the "Run Project" button and then deploy it to DigitalOcean with azk.

We know there are several options to deploy code from GitHub to the cloud or even to your local machine, however none of them allow you to deal with the original code unmodified like this which can be very useful for hacking/experimenting purposes.

How many times have you stumbled upon some code on GitHub you'd like to check out but it was so complicated to run it locally you ended up just giving up? How many projects do you have that could be going through that?

There you go. :)

I'll be glad to answer to any comments and doubts about it.

Thanks!

azk is a higher level environment orchestrator than both Vagrant and Docker Compose.

Instead of dealing with individual virtual machines one by one as you'd do with Vagrant, you'll just write a simple system-level manifest file (Azkfile) listing the environment's elements and the relationships between them and "hit play".

azk builds the environment for you with little intervention, in a short amount of time and you can easily replicate the results in other machines using that same Azkfile.

With azk, automation does NOT come at the cost of opacity. You can always look "under the hood" and see what's going on.

Today, azk employs Docker, but frankly, we could use any other equivalent solution (as we are currently testing).

Compared to Docker Compose, we can list the following advantages:

- Its manifest file (a DSL in Javascript) is more verbose and has a greater toolset [0];

- You can persist content from inside the container way better than simply mounting volumes using docker compose [1];

- For now, it relies on VirtualBox (usign debian2docker) but it has a built-in function [2] to sync folders into the container using rsync (significantly increasing performance for file sharing). You can still use VirtualBox Shared Folders if you want to;

- Its built-in DNS server makes you don't worry about port mapping and docker IP issues. You can access your local app running with azk by simply accessing a custom address, like: my-app.dev.azk.io.

We like to think of azk as the YouTube to Docker's Adobe Flash Video.

We've built a gallery [3] with some projects where you can have a first experience with azk by running them. If you get interest, you can learn how to write Azkfiles to your projects by accessing [0].

This three and half minutes video shows azk in use [4].

[0] http://docs.azk.io/en/azkfilejs

[1] http://docs.azk.io/en/reference/azkfilejs/mounts.html#persis...

[2] http://docs.azk.io/en/reference/azkfilejs/mounts.html#sync

[3] http://run.azk.io/

[4] https://www.youtube.com/watch?v=J2i8qug99Kw

That's neat. It reminds me of Bitnami (http://bitnami.com/).

When we created azk, we had developers in mind.

Solutions such as those or the `Deploy with Heroku` button are cool, but they don't give developers the opportunity to just fiddle with the code or even just check how the application looks like running locally before deployment.

So we tried to expand on those solutions by adding this capability on it (and you can always easily deploy to DigitalOcean with azk).

Hi,

I'm a software engineer at a small startup that makes this open source engine that automates environments orchestration using containers.

http://azk.io

We created a super easy way to quickly (and safely) run applications such as Huginn from source code locally on your own workstation.

It takes little more than just a click.

Go to this fork of the project and click the "Run Project" button:

https://github.com/run-project/huginn#running-locally

The only addition made to the original project is a manifest file about the OS, languages, databases etc. required by the project.

Afterwards, if you want to deploy to DigitalOcean from your desktop, you can do it in very few steps following these instructions:

https://github.com/run-project/huginn#deploying-to-digitaloc...

It would be great to get some feedback about it. Hope it helps!

Thanks.

Do you know http://hyper.sh/? Maybe it's an alternative to be considered.

I strongly recommend you to use azk [0]. It's an alternative to docker compose but instead of being a container manager, it provides the whole environment orchestration. When compared to docker compose, azk has several advantages, such as:

  - Its manifest file is more verbose and has a greater toolset [1];

  - You can persist content from inside the container way better than simply mounting volumes using docker compose [2];

  - Fow now, it relies on VirtualBox (usign debian2docker) but it has a built-in function [3] to sync folders into the container using rsync (significantly increasing performance for file sharing). You can still use VirtualBox Shared Folders if you want to;

  - Its built-in DNS server makes you don't worry about port mapping and docker IP issues. You can access your local app running with azk by simply accessing a custom address, like: my-app.dev.azk.io.

[0] http://azk.io

[1] http://docs.azk.io/en/azkfilejs/README.html

[2] http://docs.azk.io/en/reference/azkfilejs/mounts.html#persis...

[3] http://docs.azk.io/en/reference/azkfilejs/mounts.html#sync