Warning: Attempt to read property "comment_date" on null in /var/www/wptbox/wp-includes/comment-template.php on line 1043
Warning: Attempt to read property "comment_date" on null in /var/www/wptbox/wp-includes/comment-template.php on line 1043
Warning: Attempt to read property "comment_date" on null in /var/www/wptbox/wp-includes/comment-template.php on line 1043
When is this stupid fad going to die? Why do I need to download an entire bloated VM image just to run one server binary, which drags its entire dependency chain along?
I hate this shit so much.
I too
It is so that you don't have to deal with with somewhere else where it will run? Why are you using it?
protip: he's not. he just likes to make shitty comments on something he got filtered by
>he fell for le qubeOS experience meme
sandbox anons deserve a cat litter
>an entire bloated VM image
T. Didn't understand docker
FROM ubuntu:latest
See
or I could just chroot and not run any other OS
container images != vm images
it's not a VM, it's just process isolation
uname -r in the container and you'll see your host kernel
again, it's not an OS. you're isolating your app so that it has all the dependencies configured
freeing ops teams from trying to set up environments for apps they know nothing about, running your app consistently anywhere and with orchestration tools can scale your up or down on demand, self heal, allocate resources effectively between thousands of microservices, save massive amounts of money instead of using entire VMs, etc
containerization isn't intended to provide security and is less secure than VMs since many containers can share the same host, might be running as root containers, might be in the same network namespace and generally people know or care fuckall about security.
No VMs, OP.
>running vms with literally same kernel as host
Yeah, big yikes
Yes, they aren't exactly secure, and that is why they usually run on top of VMs.
Use alpine sweetie
If you are so smart.
Answer this.
Actually you won't because you are corporate slave probably sucking Sergey brin's dick day and night.
this. If you think a Docker container is a VM you're probably too retarded to understand why it's useful.
While true, container bloat is real and you have to be pretty retarded to claim otherwise.
>runs 5 different mysql for their bloat vms instead of 1 superior postgresql (or even 1 mysql if you're a queer)
When something goes wrong you need to use systemd to find out what's wrong with it
Don't use bloated imagens then, retard.
How do I create image of my own OS and not have to rely on pulling images from their glow nagger repositories?
FROM scratch
Still haven't told correctly.
Look at your linux system. Can you create image of your system and use it as base file system in docker?
>there are literally docker images of distros
>?
No, anon. That would be impossible. You can't run your distro in a docker container, sorry. Are you feeling ok?
>Sorry this is not allowed.
Lmao. The brain of wagie.
That was sarcasm, anon. It is my bot/braindead detector.
>Here
https://codeburst.io/docker-from-scratch-2a84552470c8
the irony of doing this though is a lot of the duplicate image contents will not be deduped, like if you used ubuntu:latest.
in generally I see docker as solving a problem of shitty programming languages not having good build systems and dependency resolving.
I think it is worth it if you run arch or something like me and feel like messing around with a ton of different languages. I don't have to learn the dependency management tool of <every single language that I feel like doing things>. If it works, it works. It is that simple.
sure, sure, but things like nix, as broken as it is, at least tries to solve building and dependency resolution. guix seems to do it better but a subset of the packages and slower resolver.
also there is supposed to be a retard friendly nix flakes thing now: https://devenv.sh/
https://docs.docker.com/develop/develop-images/baseimages/
If you're running into dependency hell in a way that docker will solve it, you're probably in danger of the following:
1) Using untrustworthy 3rd party code that doesn't get enough "many eyeballs" treatment and so will be a bug riddled security problem
2) Relying on outdated versions of stuff that has since been upgraded past the point your code will run without modification meaning the docker image as a whole is a bug riddled security problem
3) You're deploying masses of them on VM hosts in lieu of actually figuring out why they are dying all the time, relying on having lots of restartable docker instances instead of just having code that doesn't lock up and is safe to run on the bare metal
4) You don't actually have any problems that docker "solves" you just are using docker because you've been memed into it.
+insightful
I still don't understand whats it for.
I hate how graphical design naggers just get lazier and lazier with time.
It's just to make icons easier to recognize on tiny phone screens.
Let me guess, in other threads, you are seething about how shipping dependencies with your binaries is le bloat
when are retarded boomers that cant keep up like you going to get fired and shut up with their worthless opinions
>download an entire bloated VM image
You clearly have no clue what you are talking about
It beats running an entire VM for your server.
unfortunately never. personally I can understand why you'd use containers on a desktop os or your own infra, but if you're cloud-only, paying cloud cucks to run VMs to run your containers is possibly the stupidest shit I ever seen.
>containerization is only for web development
get a job and get back to me
If you thought distributed system is not webs shit then kys.
You can use it to build/test binaries, what are you even talking about?
>what is devops
>suggesting to become wagie
kys
>neet
Your parents are disappointed in you anon
You don't need to. You can compile the binary yourself and deploy it however you want. Just that the maintainer won't package it for your distro.
harder than it sounds. It's very annoying rebuilding their build system to not be total shit and make them reproducible. I basically got paid last year taking some multi million LoC C++ shitware and making it self-bootstrapping and CMake'd.
I hate shitware so much it's unreal. docker is faux security and cope for the above.
OP is running docker in Linux within a custom windows 11 iso he found on Google.
Fuckers ten pages deep sweating bullets as to why each new tutorial ducks his shit up worse.
>all for a project to tinker with well beyond his scope of abilities
And we keep this shit alive... For us to enjoy. Godspeed op.
>You can compile the binary yourself and deploy it however you want
Lmfao where? What kind of binary? On what? All these questions are no issues if you use docker.
> You can compile the binary yourself
Was never easy. Will never be easy. Most project maintainers aren't great, the entire C/C++/derived build process is under-specified, dependency hell is real, and Microsoft did not support makefiles until 2019.
Docker, containers, VMs, Frameworks, CMake, etc are all efforts to end run around the hard problem of actually opening up, writing, and caring about your makefiles. And every single one of them without exception ends up partially implementing make, duplicating and magnifying all of its problems, and solving none of its underlying issues. Python and CPAN like systems try to get around things with scripting and internet repositories, but the costs always boomerang back. In the end, after all the pain, all the frustration, all the head-bashing, you were always better off just crafting a proper makefile, by hand, and taking care of it so it could take care of the build.
Yeah Makefiles are good. Even a "run.sh" script can do the job too if its a small enough project.
>hey anon i can't get your code running
>oh it was just a dependency error
>hey anon your code won't deploy
>oh it was just a wrong path
>hey anon my winblows machine doesn't has this standard cli tool installed
>oh just go kms
if you ever worked in a small(ish) dev environment without years of experience and infrastructure in CI/CD you're gonna love docker
every day i work is a day I am thankful for the existence of Docker
yeah of course sometimes it's bloated, e.g. someone dockerizing a golang application
but most of time docker is preferable to no docker
>>oh it was just a dependency error
>>oh it was just a wrong path
>>hey anon my winblows machine doesn't has this standard cli tool installed
Not my problem. Works on my machine.
docker sucks but it's a symptom of how retarded linux and its statically linked dependency system is.
So glad I stuck with freebsd + jails.
Docker is awesome for dev environments. No need to worry about packages, databases, environments. Docker compose up sets up database, mocks, server and frontend. Then just edit files as needed. Making tests tolerable needs some separate config but can be similar still.
>use Go
>compile to a single statically-linked executable
>FROM scratch
>COPY a.out a.out
>ENTRYPOINT ["./a.out"]
>just werks
>image in the size of megabytes
Join us, write in Go
go.dev/tour
or just run the go binary without docker
it's only one of the few languages that don't need docker
go modules and pkg system are already really well made
>implying dependency management is the only purpose of docker
sweaty, what about filesystem isolation, network isolation, port mapping, auto-restarting, healthchecks, redundancy?
Anti docker neets/boomers are too cerebrally limited to understand the benefits. Half of them think its just a VM written in le sõy javascript
b-but that's not docker (mostly)
that's docker compose or kubernetes or any other orchestration tool
but you're right as soon as you're not deploying a simple independent app, dockerizing go can makes sense too
>docker compose
It's part of docker now:
https://docs.docker.com/compose/compose-v2/
> filesystem isolation
needed because docker runs as root and gives you root on the container
> network isolation, port mapping, auto-restarting, healthchecks, redundancy?
Jesus fuck, I can't imagine how fucking brainwashed someone has to be to think that all those things are somehow docker-specific (even including compose and pubernetes).
A retarded meme that just means "organized system administration."
Scientific computing /HPC is not webs. Though they tend to prefer Singularity/Apptainer for containers as it's designed with more appropriate assumptions for that kind of work. It's built to be usable by unprivileged users in shared environments, defaults to a batch-style processing, it doesn't do any pointless network isolation so you can run MPI jobs with it, and so on.
Very good post, but still miss the main class of dependency conflict with inter-team conflicts. For a simple example:
- Operations wants RHEL for specific hardware driver support.
- Developers want Ubuntu for better userland packages.
Ops can run Ubuntu containers on RHEL and everyone is happy.
I prefer crabbing.
Docker is nice because I am not re-writing old janky code and will just bundle the dependencies. Simple as.
it's not going away unless something comes along to do the exact same thing but better
How do I properly divide things that I'm going to test using docker-compose?
I'm making a web app, running express and react. The express is solely running an API. Unit testing would be with jest. But how would I run integration testing? I was thinking about running another separate container with puppeteer or something and running tests from there. Should I put this container on my docker-compose?
I should, right? To leave it in the same network as my front end. Yes, that makes sense.
It's illogical to hate software, dumbfuck. Simply don't use it. Problem solved.
SOUL, soul and soulless
I am planning to use gnu guix. Linux kernel has a container feature. Guix is using that. So I guess it will be lightweight. And the package manager is sovl.
When will the vm meme die finally? Why would you want to manage complex dependency chains and resolve version conflicts each fucking time you bring up a box with more than one payload image in it because the devs are too fucking lazy to upgrade their deps? Also try to run the same shit on ubuntu boxen for the devs, sles on staging and rhel in the customer env. Because that's what theybought 10 years ago, sorry. With docker you can be more prodlike and remove dependency headaches for the low, low cost of a few gb of storage and a couple hundred mb in ram (per container, equivalent to a vm in production). Also daily reminder that docker = chroups + chroot
Are there any significant advantages of using Podman instead of Docker? Will my applications be happier when they live in ze pods?
Podman is more like Singularity but aimed at desktop users instead of HPC clusters. Docker runs a daemon and by default does a whole bunch of isolation that is typically of no use whatsoever to a normal desktop user.
In general, I would say your applications will be happier not in any container at all, but if it's a desktop app, odds are good that you'll be happier with podman.
Get a real job, you dumb homosexual.
Blame modern developers, docker literally only exists because troons can’t decide on what stays and goes from packages every other week.
>Hmm I think I’ll remove this function
>Oh wait I actually needed that let me change it’s name to something even more abstract that no one complained about
>wait but now I also want it to do something else, I want it to take this argument first now I’ll change that
>3 weeks later
>okay guys so when you update to version 3.1.3 you’re going to have go through 1 million LOC and fix every error for this library update
>what did we gain from this? Uhhhhhhhhh
I recently learned how to use it and I like it.
Cope and seethe
yep I think it's hilarious. Especially Go programs with docker.. you literally embed every file in the go executable yet they still say to use docker what the fuck
It's more useful for big deployments with tens or even hundreds of containers. I have no idea why webnaggers keep telling everyone to install it despite them only having like 2-3 containers
It's how devs are taught now.
They pull in a huge pile of technologies like redis and celery and node and an RDMS and then cram the whole thing into a cocker compose file, hoist the whole thing over the wall to DevOps.
It's the Unix philosophy. If your computer is not a PDP-11 with a VT100, bring the PDP-11 and VT100 to your computer.
You can have pretty pictures with docker desktop.
>download an entire bloated VM image
it's not a VM, it's just GNU executables. the kernel is on the host
>they don't know
Docker sometimes launches containers as qemu VMs. You won't know until your machine slows to a crawl.
well if you configure it to run qemu then maybe, otherwise why the fuck would docker run qemu
>otherwise why the fuck would docker run qemu
You tell me
https://stackoverflow.com/questions/70116861/how-do-i-detect-qemu-emulation-from-within-a-docker-container
>ARM Macs
found the issue
jokes aside stackoverflow user is retarded and runs amd64 image instead of aarch64 on a arm machine
>SOVL VS soulless
Why isn't chroot enough?
Why are boomers scared of containers, it literally took me months to teach "senior" c++ dev that docker will save time and add like 10-50mb overhead in the worst case?
Because you are unable to sell the solution to a real problem you actually have.
I use containers all the time but for every legit use case I've had some soijack tell me that I can solve some problem with containers where the containerization is a totally incidental/irrelevant part of the solution. They just want to jump on the bandwagon.
The other reason is that people with experience tend to be more sensitive to the long-term consequences of unnecessary complexity. Kids who have never had responsibility for a production service are more impressed by memetech.
kek all this container orchestrated microservice bullshit is just a fancy reacharound back to application servers from 20 years ago
At a certain point you're going to have to test/build integrations with whatever you're reverse proxying and serving static assets with. You might want to authenticate requests before/without hitting the application server, modify responses, do some caching, etc. and there's not really any point to having something like nginx installed and running on your dev OS especially when permissions, case sensitivity and consistent behavior across the same or different releases aren't guaranteed. Docker is the better solution in this case, and this is a very common situation
Docking is when two gay men 'dock' their foreskins together.
Docker is fine
I hate kubernetes