feat: add Docker support.

[AGou-ops]

No description provided.

[mac2000]

Thank you for your addition, appreciate it, the only thing I did not get is - it is an single index.html file repo, do we really need all this?

In my imagination docker is used to avoid installation of software and/or running it in isolation - but here we are not installing anything technically so I am not sure if I understand what problem do we solve

e.g. if you want to run it without installing kubectl itself it may be done something like this

docker run -it --rm -p 8001:8001 \
  -v /Users/mac/Downloads/dev.yml:/.kube/config \
  -v /Users/mac/github.com/mac2000/notlens/index.html:/notlens/index.html \
  -w /notlens \
 bitnami/kubectl:1.25 proxy --address=0.0.0.0 -w .

notes around docker file:

• not sure if that's a good idea to hardcode 1.28
• it won't work with clusters that use kubelogin

even if we decide to keep it, it theoretically may be as simple as:

FROM bitnami/kubectl
WORKDIR /notlens
COPY index.html .
CMD ["proxy", "--address=0.0.0.0", "-w", "."]

but still with coveats mentioned above

and the very last one - not sure if/how someone may benefit from makefile and dockerfile in repo, aka even if we decide to create docker - probably it will be better to publish it so it can be used out of the box

may be we just should have an guide of how this can be run in docker in readme instead? just to see if thats really used by someone?

PS: makefile won't work in some cases, e.g. for example my ~/.kube/conf is "empty" there is only config for docker for mac cluster, also it may become a problem if by incident image will be published - imagine your creds being publicly available somewhere on the internet

[AGou-ops]

l think ur right, I didn't take into account the situation of kubelogin.

There are several reasons why I do this (maybe it's really unnecessary XD):

• bitnami/kubectl image packge is a bit large, so I want to repackage one myself.(I just found out that rancher also has a kubectl image package, which is much smaller)
• By using nginx reverse proxy, you can use basic/digest auth and access notlens directly without append path(like /static/) to the url manually.

PS: makefile won't work in some cases, e.g. for example my ~/.kube/conf is "empty" there is only config for docker for mac cluster, also it may become a problem if by incident image will be published - imagine your creds being publicly available somewhere on the internet

I didn't think too much, haha, its my problem. Indeed, the kubeconfig file should be mounted into docker instead of copying into docker, otherwise it is not safe.

I think it would be more convenient to provide a Docker image, (Although this project is very simple, only one index. html. lamo.) Just a small proposal.

Sorry for my poor English.

[mac2000]

I would extend your idea further: what if notlens can be hosted right inside kubernetes and be covered by some kind of auth (aka oauth2-proxy), with this in place - there is: no need to install anything locally, tool can be used by any engineer and non engineer to observe logs

The only caveat here is that in real clusters it may be unusable because of amount of deployed stuff - ok, in my local kind playground there are 10..20 pods, but in dev cluster there are 1000 for this things we use grafana loki

I am thinking about this - because inside kuberenetes we actually do not need kubectl nor kubelogin at all we may directly talk to kubernetes api to retrieve logs

And exactly to accomplish this - all we need (theoretically) is nginx image, pass nginx.conf with upstream being set to kubernetes api and index.html file and it should work

and for auth there are basic auth annotations built in or oauth2-proxy or dex for something more complex

with this in place will it solve what you have described?

[AGou-ops]

What you said is very comprehensive, vey looking forward to the future development.

But I think it's better to keep it simple. As you said, in the production env, we have ELFK and Loki to collect real-time logs, so we dont need this.

However, it is very useful for small self-host clusters such as k3s/minikube.

Running in the k8s is probably the best way. You can destroy it directly after use, and as you said, there is no need to worry about permission issues, which is very convenient