Kinto Compose Proposal

kinto-compose-proposal.md

KintoCompose Proposal

One of the earliest goals of Kinto team was to make every Git repository deployable to the cloud and compatible with any other repository. KintoCompose will aim to do this as an open source initiative.

• Kinto is inspired by the kinto'un which is the magic cloud that Son Goku rides in Dragon Ball Z, or Wu Kong in the journey to the west.
• Compose inspired by docker-compose and go modules through combining git repositories and their configuration to be served into any cloud via kubernetes.

KintoCompose Goals

• Serve any Git repository into a public and private endpoint with ease.
• Developer friendly, anyone that understands Git should be able to pickup KintoCompose easily
• Able to rapidly iterate on new or existing services in a live environment without building artifacts nor committing code.
• Extremely lightweight and cost efficient
• Ability to create modular addons to extend the core functionality of KintoCompose

Challenges we are solving

• 3+ services in k8s and iterating on them with a team ain't easy
• Be able to serve your services (public endpoint) effortelessly and create a real dev enviornment, not just a namespace.
• Package manager for kubernetes without having a registry. Just like go modules, live on the .git repository and go straight into the cloud.
• Zero kubernetes experience required

Most cloud native and open source contributions in the kubernetes community are focused infrastructure layer related services, tools or management. KintoCompose aims to make it dead simple to build, deploy and serve any git repository from a kubernetes namespace. The key component with KintoCompose will be to serve services. This means you should be able to access a service after executing a kinto-compose file without having to setup load balances, ingresses, etc.

Although the target audience is still DevOps who would understand the kubernetes ecosystem, developers should be able to understand the concept without any kubernetes knowledge and develop kubernetes friendly services with ease. Setting up a full dev/staging environment with automation for new projects or environments are not fun. DevOps should focus on infrastructure related tasks and building resilient stateful services such as Databases like MongoDb or Elastic Search and monitoring with tools like Prometheus.

Once serving a service, the final component to Kinto-Compose will be rapid development. A majority of decisions will be governed by dev environment use cases versus production. Being able to easily get logs, develop new services and test them in a real environment prior to committing any code to a git repository.

Composition Proposal

At the beginning, we will use Kubernetes CRD to execute a kinto composition. In the future, we can create a file similar docker-compose which can be picked up by our CLI tool to communicate and completely abstract kubernetes.

We won't care about production grade, infinite scaling, etc just yet. If the community wants it, we can start going that direction. For example, secret password will not be implemented until it's actually important. But the reason why it's like this is because vault is probably gonna become an addon one day ;)

Phase 1

Be able to to create an environment in any k8s cluster

1. Build & Deploy a backend or web service from a .git repository with and without a docker file.
2. Deploy an image from a public docker registry
3. Deploy a helm chart from a .git repository

Phase 2

Be able to publicly serve services an configure it via repo or CRD

1. Be able to pickup repository + image configurations via .kinto file versus defined in the CRD.
2. Build and deploy a job that is repeatable or executable during a build/deployment event
3. Introduce first lets encrypt addon + serve services publicly

Phase 3

Make it dead simple to use everything without knowing k8s

1. Introduce CLI tools
2. Introduce abstraction of advance k8s configuration (scale, distribution settings, liveness probes, health checks, etc)
3. Introduce controlling deployment workflow (mongodb first, then backend service)

Example CRD without .kinto files

apiVersion: "compose.kintohub.com/v1alpha1"
kind: KintoCompose
metadata:
  name: fullstack-example
  namespace: [environment-id]
spec:
  addons:
    - github.com/kinto-compose/core-dns:
        domainName: kintocloud.com
        provider: CLOUDFLARE
        https: true
  deploy:
    # Defaults to master branch
    - github.com/helm/charts:
        type: HELM
        environment:
            auth.enable: true
            auth.username: user
            auth.password: 3ncyp3t3dsecr3t
        source:
          subfolder: stable/mongodb-replicaset
    # Optional @latest, without it, it would default to it too
    - dockerhub.com/todolist-api@latest:
        type: SERVICE
        serverless: true
        # DNS Addon
        isPublic: true
        environment:
          MONGO_CONNECTION_STRING: mongo://user:{3ncyp3t3dsecr3t}@mongodb/todolist?replicaset=rs0
        # Deploy image only
        source:
          image:
          port: 8000
    # Targets github tag v1.0.0
    -  github.com/kintohub/todolist-spa@v1.0.0
        type: SERVICE
        # DNS addon
        domainName: kintohub.com
        # Build + Deploy image (packages repo into image without a Dockerfile)
        source:
          image: nodejs:latest-alpine
          buildCommand: 'npm install'
          startCommand: 'npm run start'
          port: 8080
    # Since source does not exist, it will look for local Dockerfile in root.
    - github.com/kintohub/todolist-db-cleanup@v1.0.0:
      type: JOB
      schedule: '*/1 * * * *'

Example CRD where Git repos or docker images that have .kinto

apiVersion: "compose.kintohub.com/v1alpha1"
kind: KintoCompose
metadata:
  name: fullstack-example
  namespace: [environment-id]
spec:
  addons:
    - github.com/kinto-compose/core-dns:
        domainName: kintocloud.com
        provider: CLOUDFLARE
        https: true
  deploy:
    - github.com/helm/charts:
        # Picks up .kinto file from subfolder (public repository)
        source:
          subfolder: stable/mongodb-replicaset
      # Picks up .kinto file in root of docker image /.kinto
    - dockerhub.com/todolist@latest
    - github.com/kintohub/todolist-spa@v1.0.0
    - github.com/kintohub/todolist-db-cleanup@v1.0.0:
      # Overrides .kinto file schedule value
      schedule: '*/1 * * * *'

Example .kinto file in todolist-spa

type: SERVICE
# DNS addon
domainName: kintohub.com
# Build + Deploy image (packages repo into image without a Dockerfile)
source:
  image: nodejs:latest-alpine
  buildCommand: 'npm install'
  startCommand: 'npm run start'
  port: 8080

Example async and sync deployment control (inspired by argo workflows multi-dimensional array flow)

apiVersion: "compose.kintohub.com/v1alpha1"
kind: KintoCompose
metadata:
  name: fullstack-example
  namespace: [environment-id]
spec:
  addons:
    - github.com/kinto-compose/core-dns:
        domainName: kintocloud.com
        provider: CLOUDFLARE
        https: true
  deploy:
    # Synchronously deploy this first
    - - github.com/helm/charts:
        # Picks up .kinto file from subfolder (public repository)
        source:
          subfolder: stable/mongodb-replicaset
    # Asynchronously deploy the following
    - - dockerhub.com/todolist@latest
      - github.com/kintohub/todolist-spa@v1.0.0
      - github.com/kintohub/todolist-db-cleanup@v1.0.0

Kinto CLI examples

1. brew install kinto
2. kinto init
   • Using kubectl context docker-desktop and installing kinto services.... {loading}
   • Installation complete!
3. kinto environment create test-env
   • Creating environment test-env
   • test-env successfully created
   • Active environment is now set to test-env
4. kinto environment switch dev-env
   • Active environment is now set to dev-env
5. kinto deploy
   • Addon github.com/kinto-compose/core-dns not found. Installing...
   • Deploying 4 services... from kinto-compose.yaml
   • GitHub's kintohub/mongodb online! Internal hostname mongodb [67.21s]
   • DockerHub's todolist-api online! Public hostname: todolist-api.dev-env.kintohub.com | Internal hostname todolist-api [6.12s]
   • GitHub's kintohub/todolist-spa onelin! Public hostname kintocloud.com. Internal ... [7.21s]
6. kinto logs test-env todolist-api
   • log messages....
7. `kinto port-forward todolist-api 8080:8080
   • Port 8080 actively tunneling traffic to todolist-api:8080

Pending Questions

• Do we like the array of git repositories, or should we introduce aliases?
• We do not have dependsOn inspired by docker because it would work in the .kinto file. Better to control the composition/depenencies via composition file only versus running into dependency hell?
• Do we like async/sync of Argo Workflow style array control?
• Are addons clear? And should they be API services :)
• Is ingress/dns /w let's encrypt the most imporant first addon?
• Is the file simple and readable?

Request

1. how to link my private repository
2. secrets are quite important to me

Answers

• Do we like the array of git repositories, or should we introduce aliases?
  -> alias please. I would want to know how to access my deployed repo
• We do not have dependsOn inspired by docker because it would work in the .kinto file. Better to control the composition/depenencies via composition file only versus running into dependency hell?
  -> I think now it is fine. but how to avoid dependency cycle?
  Do we like async/sync of Argo Workflow style array control?
  -> it is clear and simple
  Are addons clear? And should they be API services :)
  -> maybe a separate section about addons? yeah I think so
  Is ingress/dns /w let's encrypt the most imporant first addon?
  -> registry adapters?
  Is the file simple and readable?
  -> yes

This means you should be able to access a service after executing a kinto-compose file without having to setup load balances, ingresses, etc.

Meaning it's only internal. Reason for that is that exposing your services externally should come with addon. For example, addon for nginx ingress controller, addon for istio, etc.

Although the target audience is still DevOps who would understand the kubernetes ecosystem

If the target of KintoCompose is to abstract the k8s layer, then developer should easily be able to use it. That does not mean they have to know how to deploy a k8s cluster but if they have access to one cluster, they must be able to use KintoCompose.
Basically, KintoCompose has to be as simple as possible.

At the beginning, we will use Kubernetes CRD to execute a kinto composition. In the future, we can create a file similar docker-compose which can be picked up by our CLI tool to communicate and completely abstract kubernetes.

I actually thought more about that. I think we can use configmap (like helm that use secrets) and our cli would just call the KintoCompose api. That would mean less work for us and probably less limitation.

Phase 1

I think Phase 1 should be focus on Deploy and Combine only.
Use Cli. Use configmap.

Phase 2

Add the build part.

Phase 3

First addon for nginx ingress controller + certmanager in option for let's encrypt cert.

Phase 4

The rest.

.kinto file

I don't think KintoCompose should focus on that at all.

Kinto CLI examples

2. Use helm to install KintoCompose Backend (services running on kubernetes).
3. Don't think it's needed.
4. Why not.
5. kinto apply [file] to be similar to the kubectl.
   6.7. Ok. not much value.
6. kinto rollback [namespace] [version]
7. kinto promote [namespacefrom] [namespaceto]
8. kinto top [service] -> provide metrics of all your pod for a service service (RAM, CPU)
9. kinto plugin -> adding addon

Any thoughts on cutting helm out of the Kinto toolchain? I feel that Argo(CD) and kustomize are cleaner solutions with less dependencies installed on cluster.