/tech/ - Tech

Technology.

catalog
Mode: Reply
Name
E-mail
Subject
Message

Max message length: 8192

Files

Max file size: 20.00 MB

Max files: 3

Password

(used to delete files and postings)

Misc

Remember to follow the rules


(12.42 KB 730x389 Kubernetes_New.png)
kubernetes Comrade 08/11/2019 (Sun) 05:35:58 No. 2530
can someone for the love of god explain to me what this thing actually does?
AFAICT at least half the fancy "dev ops" tools are just workarounds for the fact that websites are being written in shitty scripting languages that have insane amounts of runtime errors, have to bring all their dependencies with them, and can't compile to a target arch for deployment. Oh yeah, and because they're slow as fuck (most are even single-threaded), you need to start spinning up clusters way sooner than you do when you use compiled langs, increasing demand for fancy deployment mojo.
It's the natural result of the capitalist software mottos, "Worse is better," and "Move 'fast,' break things."
Not saying Kubernetes, Docker, etc have no use, but projects written in compiled langs like Go or Rust have extremely simple deployment that obviates a lot of the ritual. Containers are really optional for them, maybe as an added security measure.
>>372
i thought the point of containers was to fix the 'it works on localhost but not on the server' problem. i.e. containers (docker) are just lightweight VM's, they have their own filesystem etc. but they arent a full VM in that they dont have a separate operating system/kernel.

i think kubernetes is some tool used to manage it or something?
>>378
>i thought the point of containers was to fix the 'it works on localhost but not on the server' problem
Yeah, but the source of that problem is usually either just configs or dependencies. Binary deployment cuts out a huge swathe of things that cause that problem. To deploy a Go app to AWS for example, you just upload a .zip with the binary and static files. Archs can cause problems too, but there are modern langs with easy cross-compilation.
>>381
yeah if your program is just one binary. The whole point of docker is to fix having to replicate dependencies on the server.

t. enterprise java dev

alot of times there would be weird issues where the report-generation software for example would have a different version on the local ide than on the server to where the fonts would turn out different or cause it to error out when ran (the report server software was a separate program) theres countless little configuration issues with just compiling on the server or even dropping a compiled binary on there (mysteriously 1/4 app servers jenkins build would fail occasionally for no reason even though they were supposed to be identical at which point the deployment manager would have to comb through the server logs to find out wtf happened.

Even w

its not just different config files, sometimes the app servers are at different versions/stages of being upgraded (OS, app server like TomcatEE etc.)

its fine to say in theory it should be the same but in practice any system running long enough in production is going to have these slight incompatibility/configuration issues pop up, why leave it to chance, its easy enough to containerize the app that way all that dependency shit is sorted once you get it working on local
>>387
Yes, configs (as well as security and other things) can still be a PITA and a reason to use a simple docker image. Though there are experimental package managers/OSes (Nix, Guix) that solve it in a different way.
>>387
I'd just like to point out the insanity of this though. You are running a Java app (with awful dependency management, hello jar files) on the Java Virtual Machine (for portability and security reasons of course) inside a thin VM Docker container (also for portability and security! and dependency management!) in a container management system, which is probably RUNNING IN A VM!.. in a cluster, in a cloud service...
Like no, it doesn't have to be this way.
>>390
i laughed out loud. i mean you're not wrong, yeah it is weird to compiler a program then run it then build the container... but i mean yeah its a layer of abstraction to make the programmers life easier at the expensive of some additional resources.

Java's promise of write once run anywhere turned out to be a lie, i guess thats inefficient, but id like to point out that this is still alot more efficient than it used to be as docker images are way more lightweight than a VM, and before container management systems you did have similar management systems for VM's which were much more complicated and crappier, and proprietary to boot (VMWare's VSphere for example - which you could only automate in perl and bash if i remember).

At least kubernetes is floss and written in GO. At least modern java apps are self hosting and dont require even further configuration of a java app server (Oracle Websphere, JBoss, TomCatEE, etc.)

So overall its still at least a 50% improvement from like 10 years ago
[code]Do code tags work on /hobby/?[/code]
test
>make every program live in its own folder, store all data and configs there <nah that's boring let's rather mix all programs' file together in a single hierarchy, first it'll require package managers to manage this mess, there will be hundreds of those, and most of them won't be compatible, and later we'll move on to distributing whole package-manager-produced "mixtures" of program files, and we'll call these mixtures "containers" and we'll also create container managers and yes we fucking will overcomplicate them too, and there will literally be jobs devoted entirely to configuring this garbage
>>2540 Containers also enforce process isolation. Yes, this is only necessary because the unix security model is shit and if there was a God GNU/HURD would have killed it in the 90s.
>>2540 fuuuuck. that, plus this insanity >>2536 Docker should've just been a way to configure linux builds, plus a way to vm it locally. What's the point of spinning up a machine only to spin a new machine inside it. Makes no sense. Kubernetes might be useful, but it seems like container software's fetish is BDSM, it likes to torture users with shit documentation, so I wouldn't fucking know. Talking about shit documentation, FUCK aws, especially all that terraforming bullshit. Mix it all together and you get a bullet to your brain. untyped dynamic made-in-two-weeks javascript using 3 libraries which somehow made your node_modules folder be 1.6GB non-deterministic npm builds because fuck you. good luck trying to debug why docker isn't caching your npm build and having to rebuild a huge dependency you don't even use (why does this accent parser library depend on ChartJS???). oof, then find through the billion articles how to deploy a container on aws. There must be a pre built solution or at least a good tutotial, right? no, fuck you. oh but now you need a worker (or you bought into the microservices bullshit). motherfucking good luck making your containers talk. how sure are you about your topology now? are they in the same server or are they in a LAN? how many servers are deployed at the moment? can you ssh in or retrieve logs somehow? fuck kubernetes, don't even want to know what it does.
>aws Don't use proprietary shit.

Delete
Report

no cookies?