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].
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