STOP USING THIS SHIT

Thank you.

Other urls found in this thread:

github.com/blablacar/dgr
twitter.com/SFWRedditVideos

Y

why ppl use it?

pls I need to know

You're welcome.

No. It is really good way to deliver your sowtware. You don't need to care about all the dependencies, and it just works. And it runs pretty well sandboxed.

Comfy af. Distribute an environment with one file, why not?

so I can deploy java or c# asp.net core app with it?

> He can't manage dependencies
> So, he throw more bloat

Ok.

try k8s and then come back

Yes. Jre alpine is a pretty good docker environment for java deployment.

>Running isolated container not polluting the os
>Muh bloat

I prefer rkt but whatever, docker is fine.

Either way, this is the present and will remain the future, no reason to go with anything else other than maybe an improved version of it.

I forgot to remove my tripcode i used for this thread But whatever, you are welcome to check it out

On one hand you're right. On the other, consider the situation that has led to the development of such memes.

Come back and tell us that Docker sucks after a few years in a real job.

> He can't manage dependencies
Dependency management also will happen in most container tools, for now you manage between-containers dependencies manually if you're on docker.

Doesn't really have to result in more bloat, though.

good job proving u have autism kid

How is he right?

The container approach is actually correct - we need to isolate applications in this way or VMs if we actually want to be able to throw them at a cloud. Which we definitely want to do, since optimizing resource usage in a heterogenous pile of servers with possibly partly different configuration manually is silly and way too labour intensive.

There's nothing wrong with it

But why? It's good.

...

> Running a striped linux kernel to deliver portability into another platforms
> Not bloat.

I'm going to guess winbabby with hyper-v trash.

Considering how small and lightweight the kernel is, no, it's not bloat.

I'm 99% sure containers exist because most tools, their deployment and their configuration are pure trash and they do stuff like rigging environment variables.

VMs are another matter.

> Babby obviously runs Windows on his "server"
Nobody but a few backward burgers in a MS ecosystem do that anymore on servers.

And don't understand docker. There is no requirement for including a Linux kernel, even though you can dockerize full VMs including a Linux OS. You can just include a c binary that emits "hello world" if you want.

You've never been responsible for a service that has 10's or 100's of thousands of users accessing it at once have you? Container technology, specifically Kubernetes is amazing for scaling up and down as needed. One of the key components to this scaling is the fact that every VM does not have to be this perfectly configured system just for the app, just needs to be able to run docker and that's it. Gone are the days of having a bunch of unused resources laying around waiting on a spike in traffic. We just provision exactly what we need depending on the time of day and users on the service. Saves the company a ton of money.

Pretty sure I can get this with a classical VM as well.

You're basically wrong. These tools are still ~the same. Docker doesn't really fix THAT much for the situation where people run VMs inside docker containers, or other situations. People still tend to use puppet, chef, salt, ansible [...]

But it's great regardless since it allows for simpler setups than whole VMs to run and migrate around on a cloud setup more automatically and a lot more easily.

Make been around since 1976 and is also portable.

kek

You'll have that one huge server that hosts that one VM that peaks at 10k users, and then 10 huge servers for the VMs that peak at 100k users.

These servers cannot be used by anything else other than VMs that can be completely suspended while peak load hits the important VMs. And even that shit already tends to use way too much VMWare trash tooling so IT can deal with it.

Meanwhile your containers actually can often react in under one second (maybe a bit more, depends). Nobody notices anything really, probably not even the entities with the less important containers.

You're right, as long as make is alive it's probably justified using Docker.

Typical Sup Forums

It's popular and used in production by major companies so they hate it.

>And even that shit already tends to use way too much VMWare trash tooling so IT can deal with it.
Actually VMWare tooling isn't that bad. It just werks.
Can't say that for HP server remote consoles.

>used in production companies
not that most of Sup Forums would know this, because they're unemployed NEETs larping as Torvalds.

I blame the Winbabby front on Sup Forums.

Because Docker really isn't native to Windows, unlike their VMWare trash and shit like that, so you get this reaction.

Figures the Linux users are the ones that like containers because frankly, you can use them as you want; they don't really get in the way of the older way of doing things on bare metal either.

It pisses me off when it's used unnecessarily. There's this work in a community I frequent on mesa drivers, which is nice work nonetheless BUT, they insist on making an installer for it based on docker.

Motherfucker, mesa is just a simplistic "./configure; make; make install" thing, and even if it has a couple of extra configuration and launching caveats it doesn't justify docker bloat.

>Actually VMWare tooling isn't that bad. It just werks.
spotted the windows cuck

You know it works on Linux as well, right?

wtf is dis shit and why should I google it?

> Actually VMWare tooling isn't that bad. It just werks.
It's expensive and (functionally) somewhat bad overall, regardless of having a clicky GUI user interface.

It "just werks" for poorly qualified IT, true, but it doesn't do that much if you wanted to automate more. Rather, that is the job of the new software package that they bring out every two-three years that again increases the cost of using VMWare tooling. Not that it generally actually succeeds in not having one or more IT guys constantly look into that UI to diagnose, tweak and fix shit.

It's pretty bad, really.

>my pajeet company uses therefore it's good
wew lad

>t. security brainlet

Biggest problem i've encountered running docker swarm is the lack of a out-of-the-box replicated storage solution for shared swarm volumes.

What not out-of-the-box thing do you use?

I've been trying Ceph at home but I'm somewhat concerned with its current lack of robustness (didn't survive most of my tests where I fucked with it and checked how it'd recover either automatically or at least with admin intervention).

Also not 100% as simple as I'd like to use this as either shared or per-container-instance storage.

Docker is awesome, what pisses me off is people making shit dockerfiles.

Durrr.... what is a client?

Sounds like someone has never had the term "stakeholder" defined for them.

Dockerfiles definitely have the problem that they aren't actually describing a whole build, and also that nobody structured them (same as with ansible, it'd be so much simpler if people started with a structured thing like a Gentoo ebuild and went from there - even if not all situations call for the same thing, at least you'd know by the additional "eclasses" or whatever that it's not the normal thing that runs a command as function or a command with side-effects on storage).

Basically, I wished something like github.com/blablacar/dgr was provided as a standard.