Kubernetes deployment

[paralin]

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]

I'm working on this here: http://github.com/paralin/docker-deploy-kubernetes

[paralin]

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]

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

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

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

@fearenales Thanks. I really appreciate this.

I think the key things are:

• Add some way of building a Docker image for a service, tagging it, and a mechanism to push it somewhere.
• Export azkfile.js to something more machine readable. See https://github.com/paralin/docker-deploy-kubernetes/blob/master/latest/azk2json/azk2json.js

Thanks!