Infraestructure

This is the second part of a series of posts about how I’ll develop an application in Kubernetes (k8s)

first post: Idea (https://jorge.aguilera.soy/blog/prestamos-bibliotecas/k8s-1.html)

second post: Infraestructure (https://jorge.aguilera.soy/blog/prestamos-bibliotecas/k8s-2.html)

The main ot these posts is to document the process of deploying a solution in k8s at the same time I’m writting the application so probably all posts will have a lot of errors and mistakes that I need to correct in the next post.

| | Be aware that I’m a very nobel with Kubernetes and these are my first steps with it. I hope to catch up the attention of people with more knowledge than me and maybe they can review these posts and suggest to us some improvements. |

To develop this application I’ll need some accounts in differents services plus some tools installed locally. Also I use Linux. If you use Windows, probably you’ll need extra tools but with Windows …​ who knows ?

Tools

IntelliJ as IDE (Visual Code is another great option)

kubectl (command line tool to interact with your k8s cluster) Probably there are visual tools but at the end you’ll be more productive from the command line

okteto cli (more info about it bellow)

Services (free account)

Docker Hub (https://hub.docker.com/) a public repository where you can upload your Docker images (the free tier also provide 1 private repository but I’ll work only with public repos). I’ll investigate if I can use the Gitlab repository due I’m a big fan of Gitlab

Okteto (http://okteto.com/) as kubernetes provider due not only because they offer a generous free cluster to play with k8s but as you can develop and test the code directly in it. Instead Okteto you can try to use minikube as local kubernetes provider and after test your application you can deploy it to Google Cloud, AWS, Digital Ocean, etc (most of them with several months to try it)

Github. Worst thing (in my opinion) of Okteto is that you need to have a Github account to identify you in Okteto. I’ll use my Github account but in fact I’ll not use it to publish my application.

Gitlab. I’ll use my account in Gitlab to publish the code of the application. With Gitlab you can implement a CD/CI (continuous deployment) to a k8s cluster. If you use Google Cloud as Kubernetes provider it’s very easy to deploy your application after every commit. I was not able to implement it with Okteto and Gitlab so by the moment the deploy will be done manually or semi-automatic

| |
CD/CI with Okteto

Pablo Chico, @pchico83 , gave me some guides to integrate a CD/CI with Okteto but by the moment I’ll deploy manually.

Basically with the okteto cli installed you can execute following commands:

$> export OKTETO_TOKEN=YOUR_TOKEN

$> okteto create namespace $(CI_COMMIT_TAG)

$> kubectl apply -f src/main/k8s/deployment.yaml

and okteto will create a namespace with the tag into your cluster and configure kubectl to deploy your application.

|

Okteto

Once you have an account in Okteto (using your Github account as login provider) you have up to 3 namespaces. By the moment I’ll have dev and prod so I’ll create a new namespace called dev where I’ll deploy and test the application

| | if you’re thinking you need more than 3 namespaces you’re lucky because it’s seems this number will be increase soon!!! |

| | main idea in k8s is to have all the details of your infraestructure in files so you can replicate the application in every namespace with minimal changes. Typical files are YAML format and you "need" to version them in the same way you version your code |

| | to work with kubectl from command line, you’ll need to download from Okteto the credentials file but DON’T ADD IT TO YOUR REPO |

Database

As we’ll need a database to store the loans we can use the deploy application feature from Okteto to deploy a Postgresql database in only a few seconds

In this screen you can set the user, password and database name. Remember your values because we’ll store them in a secret vault and "inject" them as environment variables into our container

| | As @michael_gallego and @pchico83 advised us, this is not the kubernetes way to implement a database. You can read more about it at:https://twitter.com/micael_gallego/status/1190691281036627970 |

Project

I’ll use Gradle as build tool (you can use maven if you preffer) so I’m thinking to have a multiproject repository similar to:

k8s-bibliomadrid — okteto — k8s — job — service — front

In okteto I’ll store files related with it , for example the credentials files (remember not store them into your git repo)

In k8s I’ll store the yaml files to deploy artifacts as volumes, secrets, etc. By the moment not sure if I’ll store also deployment files for service and front or I’ll use every specific folder (i.e. service/k8s )

By the moment, once initialized the main project with gradle init I’ve created the okteto directory and prepare a secret file per environment with the Postgresql details (as this is a POC project I’ll use plain text but you must use encrypt format for this)

dev/postgre-secrets.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-config
  labels:
    app: postgres
data:
  POSTGRES_DB: okteto
  POSTGRES_USER: okteto
  POSTGRES_PASSWORD: okteto
  POSTGRES_MACHINE: postgresql-headless

and apply the dev/postgre-secrets.yaml into they environment:

export KUBECONFIG=$(pwd)/okteto/okteto-kube.config
kubectl apply -n dev-prestamos-bibliotecas -f k8s/dev/postgre-secrets.yaml
kubectl get secrets -n dev-prestamos-bibliotecas

When we’ll create a container we’ll inject these environment variables into it to avoid hard-code configuration.

Next steps

I think next step will be a more "typical" task as create an application able to read a CSV file and insert into a database. I’m thinking in a "one-shot" application (probably a micronaut cli application with micronaut-data) so I’ll need some way to:

upload files (I want to control what file to process instead to delegate in the application) to a volume

connect the application with the database (I hope will not be very dificult)

consume the application into the cluster as a Job (executed manually by the moment)

so 50% typical development task vs 50% k8s task