Package SigNoz as a single binary - Binary based installation process

[pranay01]

Is your feature request related to a problem?

Currently, installing SigNoz requires having/installing docker. This maybe too much of an overhead if someone is just testing out SigNoz. We should make this process much simpler so that more people can try out SigNoz.

Describe the solution you'd like

Providing single binary application could be one way to reduce this friction

Prometheus recommends binary based installations as the recommended method.

It is very easy to run and get started since it doesn't need docker setup - which is many times very heavy. And trying to install docker script is the major reason for drop off in our install.sh script also

Describe alternatives you've considered

Additional context

For reference - https://prometheus.io/docs/prometheus/latest/getting_started/

Thank you for your feature request – we love each and every one!

[meyercm]

Love what I'm seeing so far here! Glad this gap is already identified, as I came here to open an issue about this problem.

My use cases involve environments without a container runtime available - so while I love the idea of a single binary, I would also be satisfied with an application folder / collection of binaries / configs / etc.

For me this isn't

... too much of an overhead if someone is just testing ...

This is stopping me from using it altogether.

As an aside, I'd need to run everything as a regular user, so being able to remap the UI ports above 1024 is a necessity, along with whatever other tacit assumptions are made regarding always being in a docker container.

Thanks, and keep it up!

[pranay01]

thanks for the kind words and detailed note @meyercm :)

Can you give more details on which environments don't provide a container run time?

You are right, our underlying assumption was that you can have a container run time in all type of environments - which also shows our lack of understanding of different environments possible. So any more specific details would be very helpful

[meyercm]

The only irreconcilable technical reason I've been prevented from using containers so far is when working with very old Kernels / distros still in production. One particular stakeholder is still running a 2.X kernel, for example, with the decision already made not to update.

Other systems I work on could have a container runtime, but they don't today, and I'm not the owner or administrator of them - I'm expected to deliver a self-contained application with all my dependencies.

[pranay01]

Got it. Thanks for pointing out the use case @meyercm

We will update in this issue once we take this up or if someone from the community picks this up

[ShivamTyagi12345]

I am looking to get started with this project. May I help with this

[pranay01]

hey @ShivamTyagi12345 sure! Do you have understanding of possible ways to do this? I would suggest first to do a bit of survey on how other tools have done this and then share that here. And based on that we can take one of the options.

Assigning the issue to you for now~

[Mahoo12138]

In my arm64 device, its kernel does not support the docker.

[standardrhyme]

@ShivamTyagi12345 are you still working on this? 241 is a similar issue that is open, so I'd love to collaborate if you're on board.

[ShivamTyagi12345]

Sure

[thangamani-arun]

@ShivamTyagi12345 @pranay01
its been a while, is there a release plan for binary installation for debian based or rpm based servers?

[derrickmehaffy]

Docker is exactly what is preventing from using this. Building binary installs like deb or rpms is exactly what we need.

[yashwason]

Same here @derrickmehaffy . This tool fits the bill perfectly for me, but docker is proving to be a deal-breaker.

[tarunanand-dev]

Same here... Docker runtimes (even podman) are not allowed inside certain restricted environments like Banking and Healthcare. The default root mode of Docker and extra surface area of attack is usually given as the reason. Now the pushback is to use Prometheus!

[gabriel-henriq]

Providing just the binary with the possibilities of linking dependencies trough environments vars could be awesome!

[gedw99]

I am very glad this is being addressed .

the way I do this is to use foreman or overmind. Both Golang. They support using a Procfike to run a many binaries at the same time.

https://github.com/DarthSim/overmind

• work on Linux and Darin , but not windows
• Requires tmux.

https://github.com/mattn/goreman

• works on windows also without tmux.

its a lot like docker compose but without docker.

fhis is how I deploy multiple binaries as a single app to fly.io. I just take all the binaries and inject into docker with the Procfike.

works great and can run on any server or desktop ( without docker ).

Sometime I include caddy also if I need it.

typically each binary should use a “wait for” to ensure that as each binary stars up they wait so that higher order binaries starting up can work.

for desktop I package as a zip , and uppscked using an agent. Then the Procfike is started by goremsn or overnind , which starts up the binary .

for config I use .snv files with each binary using their own . Env that is parsed at startup.

[gedw99]

https://github.com/kelindar/column Can replace Clickhouse btw .

Clickhouse runs ok on Windows ?

https://clickhouse.com/docs/knowledgebase/install-clickhouse-windows10