Alpine packages

[stefanchrobot]

Hi, great tool! Would you consider providing Alpine packages for vector?

I'm running my app on a PaaS, but I'd like to forward the logs to an external service. My app is running in a Docker container and logs to STDOUT. If I'm not mistaken, the setup that I'm using is the "sidecar" deployment strategy. My Docker CMD is going to be something like run_app_cmd | vector --config vector.toml. My Dockerfile is based on Alpine, but I'm not sure how to install vector (unless I'm mistaken, there's no package available). I plan to work around this by basing my image on the timberio/vector:<version>-alpine image, but that's not ideal (for example, it seems like I cannot pin Alpine to a specific version).

[Hoverbear]

Hi @stefanchrobot ! The official MUSL packages https://packages.timber.io/vector/0.9.2/vector-x86_64-unknown-linux-musl.tar.gz should work for you just fine.

[Hoverbear]

I wonder if we should add Alpine docs to our official guides in https://vector.dev/docs/setup/installation/operating-systems/ ?

[binarylogic]

Is this ever used outside of the Docker context? I'm curious why someone would need these instructions if we offer a Docker alpine image for Vector.

[Hoverbear]

A lot of folks use Alpine as a Docker baseimage, perhaps folks are looking to bundle Vector into their images?

[stefanchrobot]

A lot of folks use Alpine as a Docker baseimage, perhaps folks are looking to bundle Vector into their images?

This is exactly my use case. Being able to just drop RUN apk add --no-cache vector into the Dockerfile would be ideal, but tarball would work too.

[binarylogic]

Makes sense. Then yes @Hoverbear let's add Alpine to our list of supported operating systems.

[Hoverbear]

Great!

[dermotbradley]

Hi Folks

I'm interested in this also. I've tried to package vector for Alpine but I'm hitting a compile problem and I'm not familiar with Rust:

error: failed to run custom build command for `openssl-sys v0.9.58`

Caused by:
  process didn't exit successfully: `/home/builder/package/src/vector-0.10.0/tar
get/release/build/openssl-sys-c56ac2c7eba08275/build-script-main` (exit code: 10
1)
  --- stdout
  cargo:rustc-cfg=const_fn
  cargo:rerun-if-env-changed=X86_64_ALPINE_LINUX_MUSL_OPENSSL_NO_VENDOR
  X86_64_ALPINE_LINUX_MUSL_OPENSSL_NO_VENDOR unset
  cargo:rerun-if-env-changed=OPENSSL_NO_VENDOR
  OPENSSL_NO_VENDOR unset

  --- stderr
  thread 'main' panicked at 'don't know how to configure OpenSSL for x86_64-alpine-linux-musl', /home/builder/package/src/cargo/registry/src/github.com-1ecc6299db9ec823/openssl-src-111.9.0+1.1.1g/src/lib.rs:194:18
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
make: *** [Makefile:156: build] Error 101

I maintain some other unrelated Alpine packages and I'm willing to become the Alpine maintainer for vector.

My reason for wanted to package it is not just for Docker use but also to run on Alpine-based physical machines and VMs as well.

[Hoverbear]

@dermotbradley Yeah! So, right now we basically just use our musl staticly linked packages on alpine.

For a "true" alpine build you'd need dynamicly linked MUSL builds. I think we'll need to investigate our vendor-openssl feature flag and the crt-static flag: https://rust-lang.github.io/rfcs/1721-crt-static.html. Note the musl toolchain (particularly dynamic linking) is not yet fully supported on Rust: https://github.com/rust-lang/rust/issues/59302

We're currently redoing our release process with cross #3657 #3701. So after that this kind of work should be a bit easier. :)

[omnivagant]

Would it be inadvisable for @dermotbradley to set OPENSSL_NO_VENDOR when packaging for Alpine?

[james-stevens]

I use Alpine as the base for all my containers and always prefer to anchor it to specific versions, so I'd prefer to be able to use Alpine as my base image instead of the vector Alpine docker image, as I have no control over what version of Alpine it has been based on.

So I'd really appreciate it if there was a vector package in the community repo - TBH doesn't seen a huge amount of effort required & I was pretty surprised it wasn't there.

Alternatively, if you wanted to run your own Alpine repo, I'd be more than happy to just add it in.

[dermotbradley]

@james-stevens

So I'd really appreciate it if there was a vector package in the community repo

There has been a vector package in the Alpine "testing" repo for just over 1 year, however someone would need to move it to "community" for it to appear in the next Alpine release (3.20, due some time next month).

https://pkgs.alpinelinux.org/package/edge/testing/x86_64/vector

[james-stevens]

yeah - I saw that, thanks ... I would have just pulled it from there, but I just prefer to not have the testing repo used in production !

In an ideal world, having the OEM maintain the package in the repo would be the preferred option.

[dermotbradley]

yeah - I saw that, thanks ... I would have just pulled it from there, but I just prefer to not have the testing repo used in production !

In Alpine it is not supported (and can cause problems) to use the testing repo with any release, the testing repo is part of Alpine Edge which is where the next release is developed (but only packages in main and community appear in a release).

That is why I mentioned that if Vector was moved from Alpine Edge testing to Alpine Edge community in the near future then it would appear in Alpine 3.20 which is due for release around some time in May.

In an ideal world, having the OEM maintain the package in the repo would be the preferred option.

That would require someone from Vector to become an Alpine developer/maintainer and to request that the current Alpine vector package maintainer "hand over" maintainership to that person.