.. | ||
public | ||
src | ||
.dockerignore | ||
.gitignore | ||
Dockerfile | ||
index.html | ||
package-lock.json | ||
package.json | ||
README.md | ||
vite.config.js | ||
vue.config.js |
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
- Have access with kubectl to desired Kubernetes cluster
- Have local Docker daemon ready along with access to your image registry (building in-cluster with Kaniko is currently not tested)
- Get Skaffold 2.0.0-beta*: https://github.com/GoogleContainerTools/skaffold/releases
- 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:
- App/deployment name (metadata)
- Build artifacts - artifact that Skaffold would build and use, either in case of development or also actual deploy
- Profiles - similar to
npm
commands/profiles, you can have many different actions (runskaffold {action}
). We only havedev
which will build and deploy thelog-viewer-frontend
container (in manner how it's defined in Kubernetes manifest), and then enablemanual 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:
- exposing the port for reference
- changing workdir(?)
- running
npm install
on-demand - copying other code into the container
- 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.