chore: introduce dockerfile to containerize VU

[Todai88]

Introduces a local dockerfile (multi-stage) that can be used to build and run a containerized version of VU (still simple).

Due to the container being built by docker, you'll have to share your private ssh_key in the image, or you won't have access to private/internal Snyk repositories.

To try this out:

1. docker build . -t vu --build-arg github_user=Todai88 --build-arg ssh_key="$(cat ~/.ssh/id_rsa)"
2. docker run -p 8080:8080 -e host="0.0.0.0" -p 8080:8080is used to bind port8080on the host's network adapter to8080on the running container.e host="0.0.0.0is used to share the container's address with the network context that Docker runs on. If not provided, you will receiveempty response from server`. 👎

[CLAassistant]

All committers have signed the CLA.

[cmars]

Given that this is an open source project, one should be able to build it without private dependencies.

[Todai88]

Changes that's been made:

• no longer using our private (for now) config library. Instead using a simple JSON decoder.
• Dockerfile updated to no longer use any key material
• server.go using the new, tiny lib/config.go file to decode the config.default.json code.

[cmars]

LGTM with a few thoughts

[cmars]

Package names in Go should be more descriptive. I'd recommend putting this in a package config instead that deals with all matters of VU config.

https://go.dev/blog/package-names for context.

[cmars]

godoc please, maybe something like

// Load reads the config file from configPath and returns it as a new ServerConfig instance.

ServerConfig should also come over to config. Ideally we should drop the lib package in favor of meaningful package names. (If there is other stuff in lib that isn't config-related, let's relocate those bits in followups.)

[genslein]

@cmars @Todai88 maybe a question for a future piece: I would expect env vars to be used instead of a file/mount load for secrets in a container for an app. Is this not the recommended usage going forward in k8s? The registry mechanism of handling secrets seems a bit clunky

[cmars]

@cmars @Todai88 maybe a question for a future piece: I would expect env vars to be used instead of a file/mount load for secrets in a container for an app. Is this not the recommended usage going forward in k8s? The registry mechanism of handling secrets seems a bit clunky

A comma-separated string in an env var for the list of services to scrape would probably suffice for the initial version of this. Later versions will do service discovery from k8s direct. So, we could get rid of the config file... I don't think we need to configure the bind host in a container either.

Secrets I'd agree are best provided as env vars, unless they're large (like PEM-encoded private keys) in which case it makes more sense to mount them. Blending secrets with actual config in a monolithic JSON is an antipattern I think we can avoid here.

We might need a config file for expressing more complex configuration if there's lots of nesting (like a prometheus.yml). Let's see how the block storage and other configuration develops, but maybe YAGNI?