Proposal: Support native deployment

[Burnus]

Currently, the docs don't seem to describe any way of running Pingoo without Docker. Since Docker relies heavily on Linux internals, the only way to run it on other OS's is emulation or running it within a dedicated Linux VM. Both of those unnecessarily increase resource consumption and attack surface. There are alternative implementations, such as Podman, which do run on other platforms, but Pingoo's Docker manifest still lists Linux as the only supported OS:

sudo podman manifest inspect ghcr.io/pingooio/pingoo
{
    "schemaVersion": 2,
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "manifests": [
        {
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "size": 1990,
            "digest": "sha256:61b89913a336dcb8d9a32c792a560c5fd3cf6340ca3f1c7e9bea797cd5f8a7c7",
            "platform": {
                "architecture": "amd64",
                "os": "linux"
            }
        },
        {
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "size": 1990,
            "digest": "sha256:b702f547401e4a06175f3f72b5de5655ffa645bad92357e1f2592cac755beba2",
            "platform": {
                "architecture": "arm64",
                "os": "linux"
            }
        }
    ]
}

It would be nice to be able to run Pingoo on other platforms, such as FreeBSD (which comes with Jails, so it doesn't really benefit from another containerisation layer), either natively, or at least via Podman.

[notABot101010]

Ease of use is a top priority for Pingoo, so I would definitely like to see this happen.

Running apt install pingoo (or whatever) and then deploying your websites / services in a single command would be great!

Here are a few things on top of my mind preventing it to happen right now:

Stability: The biggest blocker right now is stability of the configuration folder / file. It's currently hard-coded to /etc/pingoo which is not a problem with docker as you can easily mount another folder into the container (e.g. docker run -v myfolder:/etc/pingoo). As a "native" binary, we would certainly need to provide a way for users to change the configuration folder in order, for example, to use configuration / data files from the current directory. What is the interface to change the configuration folder?

CI/CD: we would need to figure out how to setup secure CI/CD for all these platforms. Maybe using cross-compilation, but cross-compiling --release Rust is usually painfully slow.

Packaging: We would need to figure out how to package the binaries for the different OSes / distributions with each one their own format. The priority target would certainly be Debian, Ubuntu, Alpine, RH Linux derivatives and FreeBSD.

Dealing with outdated repositories: Related to above, software repositories provided by OSes / distributions often provide concerningly outdated packages. How do we deal with that? What should be our commitment?

Any idea on how to solve any of these problems is greatly appreciated.

[tkatter]

Hello, I thought I would share my feedback/experience.

I use cargo-dist in CI/CD combined with release-plz for automating Changelog updates and packaging for different platforms for one of my programs. After configuration, it has been working extremely well - packaging for Homebrew, Linux, and Windows (via Powershell install script or MSI installer). It has been a few months since I initially configured cargo-dist but, for example, to build for a FreeBSD system, I believe you would just need a CI/CD job that runs on a FreeBSD system and simply build for the Host.

Maybe using cross-compilation, but cross-compiling --release Rust is usually painfully slow.

This is true, however with cargo-dist you do not need to cross-compile, simply build for the Host of a particular CI/CD job. For development, I just develop on Linux (Mint) and before the final release commit/push to the remote, I simply run cargo check --target x86_64-pc-windows-msvc to make sure my project will at least compile for Windows.

Packaging: We would need to figure out how to package the binaries for the different OSes / distributions with each one their own format.

I think cargo-dist could be the solution for this. It obviously will not catch logic bugs across OSes, but will at least take care of automating the packaging step of a release. For logic bugs, VMs are your best friend (could simply use KVM with virt-manager on Linux) and Docker/LXCs could help here too.

Dealing with outdated repositories: Related to above, software repositories provided by OSes / distributions often provide concerningly outdated packages. How do we deal with that? What should be our commitment?

I have greater respect for those who actually get their binary/package added to the apt repository, because when I was researching how to do this - it seems like a gigantic PITA. It is obviously nice, from a user experience, to simply be able to run apt install pingoo and have everything work - but from a developer perspective this seems to be a complicated process.

Like cargo-dist there is another tool cargo-deb that can build .deb packages. Before I found cargo-dist, I would use cargo-deb to create a .deb package from my project and then simply install like so:

curl -O https://github.com/owner/repo/releases/download/tag/program-name.deb

sudo apt install ./program-name.deb

Personally, since packages in the apt repositories are typically outdated, I go out of my way to download packages for projects (like Ripgrep or Neovim for example) from their Github repository and then manually install them so that I have the latest version. It is nice when they are available as .deb packages because even with manual installation, apt keeps track of them and can uninstall them the same as any other package. Otherwise .tar.gz packages work just just as good, I just extract the binary and move it to /usr/local/bin/package-name.

I do not think it is wrong to avoid the inclusion into OS repositories all together and as an alternative make it clear in Pingoo's online documentation how to install Pingoo and where to find the binaries. For example, take a look at my Release page - this was auto-generated by cargo-dist & release-plz; it includes install instructions by default and can be customized. In Pingoo's documentation there could simply be a link to this page that says to follow the instructions on this page (for non-Docker deployments).

I think from a security perspective this holds benefit because it forces the user to go to this page and grab the most recent release (or any other version) instead of blindly apt install pingoo and receiving whatever release (and bugs if any) happens to be in apts repository.

Stability: The biggest blocker right now is stability of the configuration folder / file.

I have looked at the code to see how intertwined the config is within Pingoo, however I think that this could be solved fairly simply. A list of ideas I have:

• Use Rust's conditional-compilation features to assign the default config directory based on OS or other conditions
• Use environment variables
• Default to /etc/pingoo is a safe default and could create a hierarchy of directories for Pingoo to check for configs

Being a reverse-proxy, I'm pretty sure it is not possible for a user to simply install Pingoo and have it "work", Pingoo needs configuration. So I don't think it matters where the configuration lives, as long as it is clearly explained in the documentation.

As a "native" binary, we would certainly need to provide a way for users to change the configuration folder in order, for example, to use configuration / data files from the current directory. What is the interface to change the configuration folder?

My thoughts: The destination of the actual configuration folder does not need to change. The docs should explain what the user needs to do in order for files to be included/recognized by the configuration. There could be a field in Pingoo's configuration file, such as include: [], that takes a list/array of files or folders to include in the configuration. The list's items would be paths relative to Pingoo's default configuration directory, or absolute. Even without the include: [] field, the user could use symbolic links or simply mv/cp files into the appropriate place.

Last bit, systemd is a powerful tool and can be extremely useful. On my personal machine I have quite a few user-services that automate things. It could be worthwhile to learn how systemd could be utilized improve the Pingoo experience (installation, logging, depends on XX.service, start at boot, etc); then, on systemd systems, Pingoo could install with a systemd service file and install that in the correct location.