log-viewer/frontend

log-viewer microfrontend (WIP)

This is an experimental microfrontend to view logs coming from camtiler, testing microfrontends concept and developing Javascript/Node application directly on Kubernetes cluster using Skaffold (hot-reloading source files works!)

Currently the application itself is a really minimalistic frontend based on Vue.js 3 framework.

Getting started

0. Have access with kubectl to desired Kubernetes cluster
1. Have local Docker daemon ready along with access to your image registry (building in-cluster with Kaniko is currently not tested)
2. Get Skaffold 2.0.0-beta*: https://github.com/GoogleContainerTools/skaffold/releases
3. Run skaffold dev --namespace {desired K8S namespace}

And you should be good to go. Skaffold would create a deployment, build the container and upload it to your registry and deploy it.

Good to know

Skaffold

All Skaffold configuration is in skaffold.yml. There we have:

1. App/deployment name (metadata)
2. Build artifacts - artifact that Skaffold would build and use, either in case of development or also actual deploy
3. Profiles - similar to npm commands/profiles, you can have many different actions (run skaffold {action}). We only have dev which will build and deploy the log-viewer-frontend container (in manner how it's defined in Kubernetes manifest), and then enable manual sync, which defines which changed files will be copied to the container when it's running - change in everything else will trigger rebuilding the container.

Hot-reload vs rebuilding the container

Currently the files that will be copied are fine-tuned as they are known to work well with Vue.js hot-reload feature (eg actual frontend code). Other files, such as framework configuration files (vite.config.js, vue.config.js) will trigger rebuilding and more importantly, restarting the container, to provide stability. It might not be necessary to restart the container, this is just testing at this point. You can try it by introducing less explicit sync config in skaffold.yml.

Change in packages* files will also trigger rebuilding and restarting the container, with the difference of caching the result of the npm install command - node_modules directory. So in case of changing framework config, the container will be quickly rebuilt and restarted, but when changing packages in package.json, npm install will also be ran when re-building the container.

Dockerfile

This is a really simple Dockerfile based on the official Node Docker image. Only extra stuff it does is:

1. exposing the port for reference
2. changing workdir(?)
3. running npm install on-demand
4. copying other code into the container
5. defining the run command (important!)

We also have the .dockerignore to filter out files that never need to make into the container, such as IDE metadata directories, Git, readme etc.

With the current config, your local Docker daemon will be used to build the image and upload it to your image registry. Building in-cluster with Kaniko should be supported (https://skaffold.dev/docs/pipeline-stages/builders/docker/) but currently not tested.

Kubernetes

The Kubernetes manifest(s) are supposed to be in the k8s/ directory. Skaffold will pick them up automatically from there, apply them (also cleaning up after itself), and match the container images from it's manifest and Kubernetes manifest, so it knows when to make the Kubernetes redeploy the image.

Here we have a simple deployment, where https://playground.k-space.ee/ takes us to the (development) frontend container and https://playground.k-space.ee/events gets data from the camtiler log-backend.

The actual production usage may vary a lot in case of frontend - one would usually not run a Node.js server to serve frontend assets, unless it's a SSR frontend (Nuxt, Next frameworks). But for Node.js backends, it's pretty close to the standard.