What the fuck is up with containers?
-
Continuing the discussion from Fork Discourse:
So because I'm a masochist, I'm installing Dicsores on a VM so I can go spelunk around in the DB and see just how bad it is. This is my first time bothering to do anything with fancy newfangled bullshit containerized apps.
Can someone tell me what the fuck containers were supposed to improve?
Previously, installing a complex multipart app ensured you actually had a vague idea how the fuck it worked because you had to install all the pieces. What I now have is a complex multipart app that times out on HTTP requests (despite having religiously followed the installation guide) and I don't even have the faintest idea how to begin debugging the problem.
Oh, and the vendor has explicitly stated that I am not eligible for support on this product.
shrug. My VM probably isn't powerful enough at 8 cores and 16gb of RAM.
-
Can someone tell me what the fuck containers were supposed to improve?
We're keen on them at work. They solve the problems with weird-ass custom apps needing particular combinations of particular versions of software: the user who wants the app running can just get everything right and give us the container to run it for them. Which wouldn't be a problem except we're dealing with an environment where there's thousands of different weird apps (one per PhD student ;)) and all of them need something different.
Theoretically, we ought to put the effort in to make them all run on a common platform. Practically…
http://vignette1.wikia.nocookie.net/starpolar/images/6/6b/Notime.jpg
-
As far as I can piece it together from meta.d Discourse only runs under very specific conditions
You need the right libraries
Those libraries need the right version
Those versions need the right patch
You also need the right configuration (of Discourse and the libraries... or something)Their container is supposed to protect you from using and older / newer / absolutely correct version of software....
It's also a genius way to say "We won't support you because you didn't use your containerFiled Under: Somewhat by @dfk
-
Yeah. I can see how it would make sense at the shared hosting thousands-scale.
But for things like internal apps, I'm struggling to see any benefit beyond cloneable VM's.
Incidentally, my problem was that Whoracle VirtualSocks has insane networking defaults. Why the fuck would you want anything aside from Bridged mode?
-
Why the fuck would you want anything aside from Bridged mode?
We've probably got some examples of why that's useful too. But not why their defaults suck. Probably because like that they can charge more for consulting.
-
I'm installing Dicsores
Why the fuck would you want [...]
Filed Under: If these are not you first thoughts when working with Discourse then what is wrong with you?
-
I like the isolation from the OS and how easy they are to distribute and deploy.
-
Semi-offtopic (dull surprise!)
I can go spelunk around in the DB and see just how bad it is.
No foreign keys. No stored procs. Some indexes strewn about the place. The only good part is probably that it's Postgres, not mongo or some shit.
I have a dump of @riking's instance somewhere around here. I'm sure he'd oblige if you asked, or I can upload this one somewhere if he doesn't mind.
-
The whole thing that Discourse which is fucking FORUM SOFTWARE needs a sodding container and the other shit inside it is just another side effect of JeffCo™'s idiotic over-engineering.
-
The whole thing that Discourse which is fucking FORUM SOFTWARE needs a sodding container and the other shit inside it is just another side effect of JeffCo™'s '
The whole thing that Discourse which is fucking FORUM SOFTWARE needs a sodding container and the other shit inside it is just another side effect of JeffCo™'s petulant idiotic over-engineering.
idiotic over-engineering.
Um wat? Anyway, i felt more petulance was required...
Filed under: crappy forum software is crappy....
-
Docker containers are just more efficient VMs with the caveat that you can only run Linux on them.
-
with the caveat that you can only run Linux on them.
You're just trying to trigger Blakey, aren't you?
-
On the plus side it isn't a complete PITD to install.
-
Neither are any of the others. The others don't quote 30 minutes for install either.
-
"Install the software by downloading a premade VM and starting it up" isn't exactly a fair way to say how long it takes to set up the software. I could do the same thing with Windows and say it takes 0 seconds to install Windows.
-
What do premade VMs have to do with anything? I'm talking about forum software.
-
Discourse is installed by downloading a premade VM and then configuring it after it's already installed.
Edit: unless you were joking, in which case HA HA FUNNY JOKE +1 SATIRE
-
Discourse is installed by downloading a premade VM and then configuring it after it's already installed.
OK cool?
-
-
Uncool.
-
-
-
Discourse is installed by downloading a premade VM and then configuring it after it's already installed.
Incompatible VirtualBox version!
What?
Too new!
sigh... convert
twiddles thumbs
Done!
Yay! Start!
Error!
What?
Vagrant version incompatible!
WHAT?
Too new!
You gotta be... convert?
Need 17 gajillion petabytes of RAM!
killall virutalbox && rm discourse.vbox
More or less. Details might vary.
-
Cool supermini scroll bar.
-
I don't see a scrollbar. Can you take a screenshot?
-
On the right from the
<pre>
block.I think it might be local CSS doing it though.
-
We won't support you because you didn't use our container
Discourse is the special kind of open source - the kind where you can't actually build from source.
-
Discourse is the special kind of open source - the kind where you can't actually build from source.
You might just need to be crazy enough to think that Jeff knows best in order to manage to make the build work…
-
My install of it took all of ~10 minutes, and on an underspecced VPS (512 MB RAM).
-
Cool - having not done it, I could only go with what they quote.
-
It took me about thirty minutes, including installing Debian and figuring out the network derp.
At which point I was thoroughly bored and wandered away to do other things.
And now I'm going to go to the sports bar and watch dudes punch each other while drinking piss-awful beer and eating cheese and bacon and starch.
-
Can someone tell me what the fuck containers were supposed to improve?
They are supposed to make installation easier.
However the system administrator, besides having no idea how the application is put together, will also have no idea how to patch the security holes in the system.
Personally I still consider Debian package to be easier way to install a complex piece of software. And it embraces proper security support.
-
Debian package
Ooooh! So you stick to mainstream software only…
It's the weird custom stuff that really benefits from containers. There's some benefit when not sharing the hardware between two of those things (e.g., because the container at least acts as a record of what you actually need to run the system) but there's much more benefit when you've got to get several of these things going on the one set of hardware. The container encapsulates the fact that WeirdApp A needs library XYZ 12.3.37 and WeirdApp B needs library XYZ 11.9.48 without you having to figure out how to make those two versions cohabit.
Now, if everything was part of a Debian distribution then someone will have gone to the effort of making the code work with a single defined version of the library so that you can share fairly easily, but lots of software (especially custom stuff) isn't in a Debian distro and is never going to make it there…
-
Man, it's almost like the open source community completely ignored everything learned from DLL hell under Windows.
-
open source community
There's not one such community. There are many overlapping ones. Some have learned the lesson very well. Others… well, the distribution makers have good reason to not learn the lesson in the first place, and they're fairly influential. (Sometimes too much so, IMO.)
-
So you stick to mainstream software only…
Not only, but I do consider it a significant bonus. Also there are levels of preference:
- has a package in main archive
- has its own package somewhere (possibly ppa)
- does not have package, but dependencies do
There's some benefit when not sharing the hardware between two of those things (e.g., because the container at least acts as a record of what you actually need to run the system) but there's much more benefit when you've got to get several of these things going on the one set of hardware.
I am definitely all for setting up virtuals for the services so that a bug or vulnerability in one won't affect the other. I just prefer knowing what each actually contains.
but lots of software (especially custom stuff) isn't in a Debian distro and is never going to make it there…
Building a Debian package is not that hard. There is a lot of QA stuff to get it to Debian, but having a ppa goes a long way towards making the package more appealing. Even just being tested against dependencies in Debian does.
Man, it's almost like the open source community completely ignored everything learned from DLL hell under Windows.
DLL hell is still hell, but Debian seems to be dealing with it mostly fine. Though the gcc-5 transition I did just yesterday was a bit complicated. But that was mainly because aptitude forgot some automatically-installed flags when I cancelled the earlier update (when some updates were not yet available), so I had to go through quite a few broken packages and remind it that they are not needed. Once it installed, everything came up fine.
-
does not have package, but dependencies do
Then you have:
- does not have package, dependencies do not have packages, dependencies of dependencies might.
The more complicated the application, the more complex its dependency graph can get. It's particularly complex for languages that do their own package management (and if they're really portable to Windows, they will be doing that…)
Building a Debian package is not that hard.
But it's Just One More Damn Thing. Especially when you've also got to sort out making things work for other distribution formats too.
-
shrug. My VM probably isn't powerful enough at 8 cores and 16gb of RAM.
You use that for the Discourse server? That's barely enough to run a Discourse client!
-
Incidentally, my problem was that Whoracle VirtualSocks has insane networking defaults. Why the fuck would you want anything aside from Bridged mode?
Bridged mode can cause blue screenes and hangups on crappy wireless interfaces. Source: me and my torn out hair.
NAT, on the other hand, works 100% and is good enough for people who don't need to run servers (that is, majority of users).
-
As far as I can piece it together from meta.d Discourse only runs under very specific conditionsYou need the right librariesThose libraries need the right versionThose versions need the right patchYou also need the right configuration (of Discourse and the libraries... or something
This sounds like just about every piece of software I've ever seen...
Why in fucks name did Discourse fuck with you're nice formatting.Docker containers are just more efficient VMs with the caveat that you can only run Linux on them.
I found boxfuse to be better to be honest. Here's a 45mb linux vm image that will run anywhere. Docker is too fiddly for me.
-
-
Get a room you two!
-
-
Why in fucks name did Discourse fuck with you're nice formatting
Newlines are formatting. Quoting formatting is Doing It Wrong