Dockerization

[kogitant]

This adds a Dockerfile adapted from https://github.com/matsuu/docker-pgbadger that allows the latest pgbadger source codes to be built into a docker image. Also included a readme that has brief instructions for use.

[darold]

I still not agree that a docker file is useful for a standalone Perl script without dependency. However if some one is interested I will keep this PR opened.

[bersace]

@kogitant FYI: #394 & #395

[cleverKermit17]

its seems pointless to put docker boohoo into this standalone app. people should learn to release stuff themselfs

[shantanuo]

I had installed 2 versions of pgbadger for testing. (and forgot about it) Recently I was confused when I got different results for ./pgbader and pgbader commands. It took me some time to understand that both of them are pointing to different versions. The people who are not comfortable with Linux will prefer Docker.
Please merge.

The dockerhub version found here does not seem to be up-to-date.
https://hub.docker.com/r/dalibo/pgbadger/

If the docker-hub image is kept in sync with latest version somehow, then I do not think it is necessary to have a Dockerfile in the repo.

[tfactor2]

IMHO.

It's very useful to have the Dockerfile here. Following the logic of not including the Dockerfile because the tool is a standalone Perl script, the Makefile and tar distributions should be removed as well.
Here are ~30 repos that wrap the pgBadger into Docker image - https://hub.docker.com/search?q=pgbadger&type=image. It implicitly proves that the demand is there (50K+ downloads for a first repo). Using non-approved images may lead to unexpected results and tarnish the tool itself not talking about outdated versions.

Docker provides an abstraction of underlying technology - the user may not even know that it's a Perl script and doesn't care about the OS at all.
I think including the Dockerfile into the repo and publishing it officially would be a significant step to make the great tool available for a bigger audience.

[darold]

Again I don't see the interest to use docker to run a Perl script. Maybe the main reason I see is to run pgbadger on operating systems that do not have Perl installed natively. IMHO if it is possible to install and learn how docker works, it is possible to learn how to install and use Perl on this system, the main advantage is that it will use less resources on the host. About pgbadger version upgrade this is as simple as overriding the pgbadger script by the new one it you can not use the Makefile. Otherwise for Linux pgbadger is available as RPM or Debian packages on PostgreSQL repositories and most of Linux distribution.

[shantanuo]

I use pgbadger only once in a month (to analyze the logs). I do not want to "install" and then uninstall anything. I use dockerized versions of almost all packages, for e.g. mysql, elastic, python etc. It would be great if I could just run a single docker command to complete a task and then exit from the container to remove it. The gist of "open source" is that you listen to the community and accept a feature request even if you do not fully agree with it. If you want, I will use crunchy pgbadger that is being frequently updated and pulls are more than 100,000

https://hub.docker.com/r/crunchydata/crunchy-pgbadger

What may be the reason so many people are using docker instead of RPM or Debian packages?
How can you not see the interest to use docker?

[gleu]

According to pgBadger's licence, you have the right "to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies." That's what opensource is about. Nowhere does it say that he has to fulfill every wish users may have. If Gilles doesn't want to add a specific feature, that's totally his right. Your right is to fork the project and add the feature yourself. And actually, if I understood you clearly, there's already a dockerfile (the one that Crunchy does). So use that instead :)

[rjuju]

+1. Especially since it looks properly maintained and is already taking care of serving the generated report.

[darold]

This is the responsibility of the maintainers to accept or not a feature request in an opensource project, docker in itself doesn't add anything to pgBadger this is why I don't want to add it. The other con is that this is a technology external to pgBadger property of Docker Inc. There is tons of virtualization solution, why just Docker? Also if you don't want to install anything on your server you can use pgBadger remotely.

Crunchy Data is an excellent company, you can use their container in complete confidence.

[tfactor2]

I think that the author has full authority to do whatever he wants with the code, indeed, if someone wishes one can just take the repo and evolve it as the license permits it.
My point was is that dockerization may help of making pgbadger available to more people.

Docker containers are isolated from the host environment rather than virtualized, it allows to encapsulate the app from one side and keep it running with extremely low overhead from another one. And basically, it's based on LXC that itself is built around Linux cgroups - so there is no docker-specific magic.

From the app perspective, I'd consider docker as meta- package manager that is supported by every modern linux system (linux kernel > 3) in opposition to the zoo of yum, apt, yast, dnf, zypper, snap, flatpak, etc.
Docker is a de-facto standard for server installations.
An alternative to docker exist like podman and it's compatible with docker images.

So for me, it's a way to make the audience broader, and I was wondering why only apt and yum based distros were chosen.

But for sure, it's your decision, the packaging is a nice side feature indeed.

Best regards

[darold]

Yes but it will not have escaped you that Apt and RPM packages are maintained by the PGDG or any Linux distribution that want to include the badger. Perhaps one day the PGDG will also maintain docker files, I don't know, but for the moment the cp command is enough to install and use pgbadger for those who don't want to use packaging.

Again pgbadger is a standalone Perl script that don't need anything else than Perl and don't tell me you don't have Perl on your host. I understand that docker can be useful when there is more to do like running an http server or other complex installation, but for pgbadger there is nothing to do. On my side I'm maintaining a Makefile which is enough work.

I don't think it is a way to have a broader audience for pgbadger but it is clear that this is a way to promote the deployment of docker in all system.

[rjuju]

One point to consider is that a docker image shouldn't "only" bring pgbadger script, as it would be entirely pointless (as @darold mention it's a standalone scripts, there's absolutely no value in doing that). A reasonable use case for pgbadger + docker would be to have a bit more infrastructure added. Maybe have tooling for daily analysis + aggregation, serving the reports via a webserver and so on. But there are so many ways to use pgbadger (should it be local log files, on a distinct volume, using ssh connection, specific log_line_prefix, specific top-N values and so on) that providing a container that would be useful for just the main use cases would probably result in so many options that it would be simpler to just create one that suits your specific need from scratch.

[wsdookadr]

Reading the comments in this PR, but also #657 I wanted to check if I understand, and summarize the arguments against merging this:

1. the vast majority of distributions have Perl installed natively
2. pgbadger is a standalone self-contained script with no other dependencies
3. pgbadger works on a wide variety of Perl versions
4. if the system where pgbadger is required does not have Perl installed natively, the user can always learn how to install Perl on the system (via perlbrew installed from packages)

While [1] and [2] are true, we're finding that [3] is almost true (in #657 we learn about an environment with Perl 5.26 with a buggy Storable module which alters the pgbadger user experience), and [4] actually requires root privileges (to install perlbrew from packages, even though okay it can be installed in the user homedir too), and a compiler and the GNU toolchain available, plus the time spent on compiling and building a certain Perl version. The need to compile Perl means [2] is no longer true.

Now I see the following benefits if this PR were to be carried out and merged:

• less time spent on building the right version of Perl on the user's side
• less time spent on documenting the exact versions of everything required in pgbadger (we learned above that Perl version and Storable module versions were required)
• no need for root privileges and compiler and GNU toolchains installed on the system (docker allows non-root users)
• it's easier to communicate reproducibility information through the docker image version used (so if a user says "I have version X of pgbadger docker image" , that also describes whichever version of Perl, or builtin Perl modules were being used)
• the availability of docker images actually broadens the audience for pgbadger (at the very least end-users with less privileges and less time will be able to run it)
• shortens the time between the user learning of pgbadger and the moment they see the reports generated by pgbadger

One way to view the dockerization is the user gets an alternative installation method that is easy to deal with.

Note: I see the slim perl base images are around 40MB in size so maybe this won't create a big overhead.

[rjuju]

[4] does not require root privilege as you can get a local user installation, while installing docker definitely requires root privileges (same for allowing non root users to use it). More importantly I don't think that it's sane to rely on the fact that some people won't be able to run any perl script at all because they can't or don't want to install perl but will gladly install docker (despite the numerous bugs that existed, and yes I've been bitten by that a lot in the past) and will pull random docker images from the web (because pgbadger isn't the only software written in perl).

Note also that it's still unclear (at least to me) if #657 is due to some weirdness in aws environment or not.

Note: I see the slim perl base images are around 40MB in size so maybe this won't create a big overhead.

That's a 26x overhead!

Finally, in my opinion providing a docker image will actually reduce user experience as if you have any issue with pgbadger what you will want is to use the latest commit and/or a custom branch to test a patch which will be a pain to do with docker. Also I'm assuming that most of users get pgbadger installed from the PGDG packages, so get updates when the rest of the system is updated. I'm afraid that users relying on docker images will tend to get stuck with a single (and old) version.

[dopegame936]

This adds a Dockerfile adapted from https://github.com/matsuu/docker-pgbadger that allows the latest pgbadger source codes to be built into a docker image. Also included a readme that has brief instructions for use.