templating language for k8s + vscode extension 🙌

[Mahieddine Cherif]

Hi everyone, 

As a k8s user/developer everyone knows that writing easy to read and maintainable YAML files is hard, this is why we've developed 3 things : 

- An easy to read "templating" language called ICL https://github.com/archipaorg/icl , everything that you write in JSON/YAML can be expressed in ICL.

- Then we've generated a set of k8s-icl templates based on k8s JSON schemas, those templates can be used to write your k8s manifest in ICL like this https://github.com/archipaorg/k8s-icl, and finally using a tool that we've also developed called Archipa to compile them to YAML file https://github.com/archipaorg/archipa 

Of course a vscode extension is also available, it will enable you to live preview your ICL code in YAML https://marketplace.visualstudio.com/items/archipa.icl

We are strong believers in the power of a community, this is why this project is very open to everyone for contributions, we can gather around, discuss and figure out how to achieve what we need to do.

Any feedback is very welcomed ?

[Keith Burdis]

How does this compare to ksonnet [1]? This is based on jsonnet [2] which has a good comparison [3] with other approaches.

[1] http://ksonnet.heptio.com
[2] http://jsonnet.org
[3] http://jsonnet.org/language/comparisons.html

[Mahieddine Cherif]

Hi Keith

ksonnet like you already know is just a bunch of generated mixins on top of jsonnet, this makes its templates hard to read and write, moreover the design choices made for jsonnet didn't attract us. I mean we all know what happens when you put a programming language inside a configuration file.

This is why we created ICL (https://github.com/archipaorg/icl), it's a declarative configuration language inspired from nginx config file syntax and written primarily for docker orchestrators' YAML file, it has the concept of inheritance, class, mixins and libraries. 

This is what it looks like if i write my "hello world app" manifest file in ICL for k8s:

take github.com/k8s-icl/latest/v1beta1/deployment,

github.com/k8s-icl/latest/v1/containerport,

github.com/k8s-icl/latest/v1/container

::variable "container-port" apply ContainerPort @@name="nginx", @@containerPort="8080"

::variable "container-ports" [variable.container-port]

::variable "container" apply Container @@image="nginx:1.13.0", @@name="nginx", @@ports=variable.container-ports

::variable "container-list" [variable.container]

::variable "pod-spec" apply PodSpec @@containers=variable.container-list

::variable "labels" table "app" = "nginx"

::variable "pod-metadata" apply ObjectMeta @@labels=variable.labels

::variable "template" apply PodTemplateSpec @@spec=variable.pod-spec, @@metadata=variable.pod-metadata

::variable "spec" apply DeploymentSpec @@replicas=5, @@template=variable.template

::variable "metadata" apply ObjectMeta @@name = "nginx"

_ "_" apply Deployment @@metadata=variable.metadata, @@spec=variable.spec

Of course i could wrote a mixin to shorten the creation of a specific section in my case, but the point is that even if no one knows what ICL is, everyone can read and understand what's happening here.  

How does it compare to other approaches ? ICL is a JSON/YAML extension, it has some OO concepts such as inheritance (multiple inheritance actually), mixins, and class, but remember ICL's purpose is to make config files modular, and easy to read. so there are no conditional, loop...instructions. the point is that when a developer checks a config file he must be able to see what he gets.

e.g. (:: in ICL means its a settings block library => no rendered)

::vegetable "fruit" as Fruit {

type = "fruit"

}

::color "green" as Green {

name = "apple"

}

apple "green" from Fruit, Green {

}

Output in YAML =>

apple:
  green:
    name: apple
    type: fruit

Whatever you write in JSON/YAML can be written in ICL and vice-versa.

Hope it's clear for you 

Regards,

Mahieddine

[al...@heptio.com]

I think what you're doing is super neat, but I'm curious to hear in more detail about your complaints with Jsonnet. I find it to be quite elegant, myself. (Though, as you know, I'm quite biased at this point.)

[2t.an...@gmail.com]

I would like also understand better how it compares to jsonnet and/or what was the blocking point to use it?