Closed danwdart closed 8 years ago
Is the docker image going to be maintained? Docker is "OK" for what it is and I'm not knocking it, it's often better than following a install.md which is outdated where half the things don't work. Docker often can have problems that there are solutions out there to fix. Docker images frequently become out of date and can have some serious security problems[1], the images require constant maintenance.
I'm just a bit concerned if this is provided and a recommended way of deploying PC, it could lead to security vulnerabilities.
Could maybe take a look at GNU Guix or the nix project. They offer some pretty good, reliable and reproducible ways of deploying that work on most if not all distributions of GNU Linux.
Docker hub autobuilds when it's pushed :D
However right now the dev version's got a volume bind mounted to $PWD.
I fail to see how, if frequently pulling latest, someone could end up with not the latest. Either that or git pulling on a bind mount.
Tbh a lot of these libraries and practices are terribly out of date.
I have had a look at guix but it makes you effectively learn a new language to configure it.
Not seen nix before, will check it out.
I have had a look at guix but it makes you effectively learn a new language to configure it.
True but it's better than other projects which choose a configuration format like YAML or something and then add features on top they decide they need which eventually makes it a horrible bespoke turing complete language. Scheme is fairly readable to someone who doesn't know it. I don't see it as being a big problem.
I could just as well use a makefile or chef or etc.etc. Who knows? I don't.
A makefile seems a decent route to go down. It's standard enough and well adopted enough to never cause a problem and be easy and allows you to install it on your own system meaning you are maintaining it when you're maintaining the general server, it's not some blackbox which will rot with age.
:+1: makefiles
well I already have a couple debuntu/gentoo install scripts for some of it tbh But what I wanted here was a way of installing everything the same way and not clogging up the system which is why I figured docker... would be the same but more extensible to providing a filesystem/vbox image thou seeth
Well a vbox image has all the same problems. The issue is you're providing an image with a bunch of dependencies pre-installed and there is an expectation the user grabs it and just runs it without really doing any maintenance. The problem is that security wise it's kinda a pain, they frequently succumb to rot over time leaving users insecure.
If you'd like a method where they just have to run a single command and all the dependencies are resolved and PR is configured and ready then the only good way I've seen thus far is GNU Guix and NixPkg stuff. They run on a lot of distros, they're verifiably reproducible and they have virtual environment stuff build in.
Rot problems can be avoided by having an update step in the Dockerfile, which I have. Does that help?
This one is impossible to rot because a) it is updated via auto update on every push and b) it apt upgrades on every build. The thing most likely to rot is its own git code and even then that can be git pulled anyway.
This has now been added and makes it far easier for deployment.
For ease of installation there should be a docker image.
However not sure quite what the best way is to start using environment vars. Converting from ini files to .env files with THING=$THIS_THAT in them? Calling env stuff directly from the config files so if there's no config file then just look for an env?