azukiapp/azk

Kubernetes deployment

Opened this issue · 6 comments

paralin commented

As far as I can tell, azk currently supports only DigitalOcean as a deployment target.

I'm interested in implementing Kubernetes as a deployment target via automation of the API. It's quite easy to generate type-safe API code via swagger-codegen (as I did for dotnet here). The scaling and deployment model in Azk should translate nicely over to how Kubernetes handles things.

Thoughts?

paralin commented

Okay, after a long night of hacking.. It's all but done. Just need to implement image push (there will be some question of where the images should go, though).

Completed:

  • System analyzes Azkfile.js, converts it to basic JSON.
  • JSON from azk2json converted into Kubernetes yaml configurations using reasonable best practices
  • Existing cluster is analyzed for differences from the suggested model. Steps to actuate to target model are generated and printed in a human readable form.
  • Actions are performed to bring cluster up to target state.

Sample output:

First run: http://sprunge.us/PbUa

Second run: http://sprunge.us/ODhf

fearenales commented

@paralin It's awesome you're working on this!

I'd like to explain you couple things about azk deployment, and this will answer the question you've posted at #641 .

There's a base image for deployment, named azukiapp/deploy. This image was designed to provide all tools for deployment (including subcommand handlers, such as azk deploy versions, azk deploy rollback etc.) and communicate to a single box via its IP.

So, if you're deploying to your own server, you can setup your credentials, the server IP and use this very image.

Also, this base image was designed to be extensible for other providers (check it here).

In order to do that, an image for a provider should:

  1. Extends from the base image;
  2. Communicate with the provider's API in order to create a box, and send back the box' IP to the base image so that it would know how to handle it;

All of these provider-specific actions on the top of the deployment base image should be implemented in a file named deploy-<provider-name>.sh, such as deploy-digitalocean.sh;

I'd like to hear from you if this structure fits your needs. Otherwise we still can elaborate a more flexible base image so that you can extend it in order to implement deployment using Kubernetes.

paralin commented

@fearenales Sorry, this doesn't work with Docker Image deployment, only with basic SSH deployment. With Kubernetes I need to generate a set of Kubernetes configuration files (replication controller definitions, service definitions) which then are submitted/applied to an existing kubernetes cluster via an API. It would not work to use ssh or literally anything inside your base image.

It makes more sense to have generic base images derive from that image but still allow any deployment image to be dropped in place for any kind of logic like this. It does not make sense to enforce a specific base image like your azukiapp/deploy image with a preset list of (pretty flawed) commands.

fearenales commented

@paralin Yes, I understand your point. We'll work to improve the deployment base image in order to make it possible to extend it in cases other than basic SSH deployment.

Thank you very much for your feedback!

paralin commented

@fearenales Thanks. I really appreciate this.

I think the key things are:

Thanks!