log-viewer/frontend/README.md
2022-10-05 17:44:28 +03:00

68 lines
3.9 KiB
Markdown

# 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
0. Have local Docker daemon ready along with access to your image registry (building in-cluster with Kaniko is currently not tested)
1. Get Skaffold 2.0.0-beta*: https://github.com/GoogleContainerTools/skaffold/releases
2. 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.