68 lines
3.9 KiB
Markdown
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.
|
||
|
|