Docker is steaming pile of 💩



  • I've been fighting with docker-for-windows for the last at least an hour.

    First, the kubernetes it creates was in some funky state. Ok, so restart it. Hm, does not start.

    Restart computer, tell docker to reinstall kubernetes, still does not start. Appears to be

    I.e. some weird fuck-up when creating the internal certificates. Anyway, it broke down after upgrade the last time, so down to reinstalling it. So off I go to

    And, um, COULD YOU AT LEAST TELL ME WHICH VERSION IS STABLE AND WHICH IS EDGE. For crying out loud, people, seriously, where are the damned versions?

    And then there is all the confusion between versions from docker.com and those from mobyproject.org and… Fuck, this is unbelievable mess.



  • @bulb said in Docker is steaming pile of 💩:

    docker-for-windows

    0_1521820448257_ac8ef5c1-d024-4f68-8dd3-13b8b0dcd7ee-image.png


  • BINNED

    @bulb said in Docker is steaming pile of 💩:

    Fuck, this is unbelievable mess.

    Tell me about it. Docker should make everything faster and easier to install and get running, no? Last time I messed with it all I wanted was a prepared image with Pritunl (fancy web UI for the OpenVPN server, basically).

    There are images on docker.io or whatever. There are images on Github. Sometimes they are the same, sometimes they are not. Version numbers are non-existent so I was basically looking at the dates (which tended to differ on Github vs. other places). Some of them include storage for mongodb and whateverotherfancyshititneeds in the image. Others tell you to give it a directory on the machine itself and forward it using some arcane commands. Some require you to map ports to docker, others apparently handle it on their own.

    And all this is so poorly explained it's re-goddamned-dicolous. Some include the example command to run but explain nothing about it, so if you need to tweak a parameter it's either hours of reading man pages or changing stuff and hoping. Some just tell you "It's a thing. BUT IN A DOCKER CONTAINER!". Not a single letter about the setup and/or requirements.

    In the end, I concluded that you either have to get lucky with whatever you are installing and just find a well made image (and the only way to distinguish a bad one from a good one is to try them all) that Just Works™, or know so much about Docker already you might just as well make your own.

    I had less stress manually installing dependencies and compiling shit from source than using this new "simple" way of doing things.



  • @timebandit Most of the issue is not really specific to it being the Windows version. That they can't include the version on the download page and the installer names can't be blamed on anybody but the release manager. And since it runs in a Linux image in a Hyper-V—which is quite decent virtualiser—virtual machine, any failures to update it properly are their own fault too. Unless it is Kubernetes (and therefore Google's) problem, but that has even less to do with Windows.



  • @onyx said in Docker is steaming pile of 💩:

    In the end, I concluded that you either have to get lucky with whatever you are installing and just find a well made image (and the only way to distinguish a bad one from a good one is to try them all) that Just Works™, or know so much about Docker already you might just as well make your own.

    And then you don't need just docker images, but the kubernetes service definitions for them, preferably in helm chart format and that's even harder to find. And whoever thought using a text template engine on Yaml is a good idea should burn in hell.



  • When I looked at alternatives for the full VMs that I was running, I tried out Docker. It was such an insane mess that I just said "Fuck it" and started using LXC instead. Definitely a much smarter move.


  • BINNED

    @dragnslcr said in Docker is steaming pile of 💩:

    When I looked at alternatives for the full VMs that I was running, I tried out Docker. It was such an insane mess that I just said "Fuck it" and started using LXC instead. Definitely a much smarter move.

    The sad part is that Docker is (was?) a wrapper for LXC to make it simpler to manage.

    Yeah, that worked out.



  • @dragnslcr said in Docker is steaming pile of 💩:

    When I looked at alternatives for the full VMs that I was running, I tried out Docker.

    Oh, it was never ever meant to be that. It is a software deployment tool for bundling software so that the developer can pack the complete environment it works in and does not have to care about differences between the systems.

    It was not, however, designed with security in mind, so it is not usable as replacement for virtualization. LXC was and is.

    It was also supposed to make system administrator's life easier, but since the images you may download are as inconsistent as the packages always were, it does not, really. There is a reason why Debian has these thick books “Packaging Manual” and “Policy Manual” that describe how to package software so they follow consistent conventions and work well together. Packages provided by upstreams often don't and Docker does nothing to improve it. Especially since it does not even define any useful versioning.

    @onyx said in Docker is steaming pile of 💩:

    The sad part is that Docker is (was?) a wrapper for LXC to make it simpler to manage.

    No, it is not. It uses the same underlying mechanism, control groups, but was designed with different goals in mind.


  • Grade A Premium Asshole

    You all might be interested in this: https://github.com/GoogleCloudPlatform/container-diff

    It gives you at least some idea of :wtf: is inside a Docker image.



  • @bugmenot said in Docker is steaming pile of 💩:

    You all might be interested in this: https://github.com/GoogleCloudPlatform/container-diff

    It gives you at least some idea of :wtf: is inside a Docker image.

    I know perfectly well what is inside a Docker image. And?


  • Notification Spam Recipient

    @bulb said in Docker is steaming pile of 💩:

    @bugmenot said in Docker is steaming pile of 💩:

    You all might be interested in this: https://github.com/GoogleCloudPlatform/container-diff

    It gives you at least some idea of :wtf: is inside a Docker image.

    I know perfectly well what is inside a Docker image. And?

    Can you teach me? All I've been able to figure out is that "it's magic" and I can't figure out how to modify files inside the image in any meaningful way...



  • @bulb said in Docker is steaming pile of 💩:

    I know perfectly well what is inside a Docker image.

    All I know is that :disco:🐎 lives inside a Docker image. And that makes me want to avoid learning about anything else that might live there.



  • @tsaukpaetra said in Docker is steaming pile of 💩:

    @bulb said in Docker is steaming pile of 💩:

    @bugmenot said in Docker is steaming pile of 💩:

    You all might be interested in this: https://github.com/GoogleCloudPlatform/container-diff

    It gives you at least some idea of :wtf: is inside a Docker image.

    I know perfectly well what is inside a Docker image. And?

    Can you teach me? All I've been able to figure out is that "it's magic" and I can't figure out how to modify files inside the image in any meaningful way...

    You can't. It is kinda the point. The images are identified by hash of their content, so the only thing you can do is create a new image that is the previous plus some changes.

    Of course the container can modify it's content. It has a “layer”, a filesystem overlay, in which it writes the modified files. And you can tell docker to create a new image from it—either manually via docker commit, or in the scripted way via a Dockerfile. And you can even re-tag that image with the previous tag. But it's still a new image.

    The resulting image is still stored as reference to the base image and the overlay. This has the benefit that files from common base image are there only once, so the kernel knows it only needs to load their content only once, so you can get the benefit of shared libraries even across containers if you put some care into their building and use the same base image for them.



  • @hardwaregeek said in Docker is steaming pile of 💩:

    All I know is that lives inside a Docker image.

    Yeah, it's a sloppy way of distributing software. You build the image, test it and shove it onto the user and don't have to build a proper package or installer and test with various versions of dependencies etc. The downside is that the user can't apply security patches themselves.

    Of course there is a lot of saner software that has a proper package and that is installed into a docker image, because they are easiest way to deploy to most clouds. But if there is a proper package, the user can rebuild the image against newer base for security updates if the author fails to do so, so it's much less of a problem in such case.


  • Java Dev

    @hardwaregeek said in Docker is steaming pile of 💩:

    @bulb said in Docker is steaming pile of 💩:

    I know perfectly well what is inside a Docker image.

    :disco:🐎 lives inside a Docker image.

    From what I've heard, I'm not sure inside is the correct word there.


  • Banned

    @bulb said in Docker is steaming pile of 💩:

    The resulting image is still stored as reference to the base image and the overlay.

    Doesn't this defeat the whole purpose of containers?


  • Garbage Person

    @dragnslcr said in Docker is steaming pile of 💩:

    When I looked at alternatives for the full VMs that I was running, I tried out Docker. It was such an insane mess that I just said "Fuck it" and started using LXC instead. Definitely a much smarter move.

    Yeah, I've looked at Docker and decided that MOAR VMs are cheaper once you figure in the overhead.



  • @gąska Since the reference is by ID to the immutable image, no, it does not defeat anything. It saves space both on disk and in memory (if you take advantage of it; not everybody does).



  • @weng said in Docker is steaming pile of 💩:

    MOAR VMs are cheaper once you figure in the overhead

    VMs are only the same cost as containers if every single Docker image you have shares no common ancestors and includes the kernel for absolutely no good reason.


  • Garbage Person

    @ben_lubar You clearly don't use the same metrics for cost that I do. Cognitive load, points of failure, transparency, maintenance and staffing are WAY higher up the list than watts of electricity spent powering extra RAM.



  • @weng said in Docker is steaming pile of 💩:

    Cognitive load, points of failure, transparency, maintenance and staffing

    Docker containers and virtual machines are identical in every way except that the kernel is shared between Docker containers and not shared between virtual machines.



  • @ben_lubar They are technically quite similar, but the design and concepts are very different, so neither is usable in place of the other. In fact, the usual approach is to run docker containers in virtual machines.



  • @ben_lubar said in Docker is steaming pile of 💩:

    Docker containers and virtual machines are identical in every way except that the kernel is shared between Docker containers and not shared between virtual machines

    As with any paravirtualized environment you gain performance -- at the cost of easier privilege escalation.

    Docker is just the trendy lovechild of OpenVZ and chroot. There's still definitely a place for VMs.


  • Banned

    @ben_lubar said in Docker is steaming pile of 💩:

    @weng said in Docker is steaming pile of 💩:

    Cognitive load, points of failure, transparency, maintenance and staffing

    Docker containers and virtual machines are identical in every way except that the kernel is shared between Docker containers and not shared between virtual machines.they're impossible to figure out how to work with and require undocumented configuration options to run, as opposed to actual VMs that Just Work™.

    FTFY



  • @gąska DOCKER IS NOT A VIRTUAL MACHINE. No, not even a para-virtualized one.

    If you try to use it as one, you'll get lost in a twisty little maze of options that don't do what you think they do. But that's because you are thinking it's a virtual machine, but it is not.


  • Banned

    @bulb I don't care if it's virtual machine or a circus lion. I just want the software to install easily, run easily, remove easily, and copy between machines easily. VMs achieved all of these, though they're overkill in most situations. Docker promised all of these, but it turned out not to be much improvement over regular packages.



  • @gąska said in Docker is steaming pile of 💩:

    software to install easily […]. VMs achieved all of these […]

    Pardon me, sir, are you kidding?

    Are you really saying that a VM image provided by some random upstream is easier than docker image or package from the same upstream?


  • Banned

    @bulb it significantly reduces number of things that can go wrong. Basically, if an image works at one place, it will work pretty much everywhere.



  • @onyx So glad I went with Vagrant + Salt...

    I just run the Official Ubuntu Vagrant image and have Salt configure every machine I own (regardless of where it exists -- physical hardware, VirtualBox VM on my hardware, VPS on Linode, etc)



  • @gąska said in Docker is steaming pile of 💩:

    @bulb it significantly reduces number of things that can go wrong. Basically, if an image works at one place, it will work pretty much everywhere.

    What's the difference between downloading a VM image and running it and downloading a Docker image and running it, apart from:

    • the Docker image does not contain a kernel
    • the VM image does not share parts of its filesystem with other VM images by default


  • @ben_lubar said in Docker is steaming pile of 💩:

    Docker containers and virtual machines are identical in every way except that the kernel is shared between Docker containers and not shared between virtual machines.

    Except the UI of VM programs is about 40,000 times easier. Even I'm smart enough to set up a VM; Docker just mystified me when I tried to figure it out.



  • @ben_lubar said in Docker is steaming pile of 💩:

    What's the difference between downloading a VM image and running it and downloading a Docker image and running it, apart from:

    The UI for the VM software is 40,000 times better. That's a huge advantage for that option.


  • Banned

    @ben_lubar there seems to be insane amount of people who can't run Docker containers in their environment despite the same image working for other people.


  • Impossible Mission - B

    @bulb said in Docker is steaming pile of 💩:

    Pardon me, sir, are you kidding?

    Are you really saying that a VM image provided by some random upstream is easier than docker image or package from the same upstream?

    Yes



  • @gąska said in Docker is steaming pile of 💩:

    @bulb it significantly reduces number of things that can go wrong. Basically, if an image works at one place, it will work pretty much everywhere.

    That is true for docker images too, though.

    Ok, ok, it is not, actually, because the docker maintainers are idiots and can't maintain compatibility properly. So yes, you are right, it is better when using a well tested full virtualization.

    @ben_lubar said in Docker is steaming pile of 💩:

    @gąska said in Docker is steaming pile of 💩:

    @bulb it significantly reduces number of things that can go wrong. Basically, if an image works at one place, it will work pretty much everywhere.

    What's the difference between downloading a VM image and running it and downloading a Docker image and running it, apart from:

    • the Docker image does not contain a kernel
    • the VM image does not share parts of its filesystem with other VM images by default
    • Docker images also usually don't run init or any services, only the application. Full virtual machines usually do need at least init and management console in them.
    • Docker has quintillion of options for mapping files into and out of the container, injecting environment variables, passing parameters to the command, running in a virtual network or not and more. This gives much more flexibility at the cost of complexity.
    • Docker is not considered a secure containment.

    @blakeyrat said in Docker is steaming pile of 💩:

    UI of VM programs is about 40,000 times easier.

    Because they are about 40,000 times simpler. Virtualizers don't have much of the options Docker has.

    @gąska said in Docker is steaming pile of 💩:

    @ben_lubar there seems to be insane amount of people who can't run Docker containers in their environment despite the same image working for other people.

    Yes. There are two reasons:

    • Docker has a lot more options, so more chances that the author advertises some, but didn't actually ever test it.
    • Docker maintainers are idiots who can't maintain proper compatibility or even detect things are not compatible. I did have to install packages from Docker upstream (which is something you normally want to avoid in Debian), because Japaric's images did not run in the 1.13 from official archive—failing in weird ways instead of anything obvious of course.

    I did start this thread by complaining that Docker maintainers are morons after all.

    @masonwheeler said in Docker is steaming pile of 💩:

    @bulb said in Docker is steaming pile of 💩:

    Pardon me, sir, are you kidding?

    Are you really saying that a VM image provided by some random upstream is easier than docker image or package from the same upstream?

    Yes

    Hm, the software I am using mostly wouldn't work in VMs at all, because it does need to map files and pass options and such that VMs don't do, and not software that would simply run as a separate service on a server.



  • @bulb said in Docker is steaming pile of 💩:

    Hm, the software I am using mostly wouldn't work in VMs at all, because it does need to map files and pass options and such that VMs don't do, and not software that would simply run as a separate service on a server.

    You could just run the software as software.


  • Impossible Mission - B

    @bulb said in Docker is steaming pile of 💩:

    Because they are about 40,000 times simpler. Virtualizers don't have much of the options Docker has.

    Sure they do, they have all of them and more; they're just inside the virtual machine's OS. :P


  • Impossible Mission - B

    @blakeyrat said in Docker is steaming pile of 💩:

    You could just run the software as software.

    Very true.

    The Emperor’s Old Clothes
    by C. A. R. Hoare, from his Turing Award acceptance speech

    Many years ago, there was an Emperor who was so excessively fond of clothes that he spent all his money on dress. He did not trouble himself with soldiers, attend banquets, or give judgement in court. Of any other king or emperor one might say, "He is sitting in council," but it was always said of him, "The emperor is sitting in his wardrobe." And so he was. On one unfortunate occasion, he had been tricked into going forth naked to his chagrin and the glee of his subjects. He resolved never to leave his throne, and to avoid nakedness, he ordered that each of his many new suits of clothes should be simply draped on top of the old.

    Time passed away merrily in the large town that was his capital. Ministers and courtiers, weavers and tailors, visitors and subjects, seamstresses and embroiderers, went in and out of the throne room about their various tasks, and they all exclaimed, "How magnificent is the attire of our Emperor."

    One day the Emperor’s oldest and most faithful Minister heard tell of a most distinguished tailor who taught at an ancient institute of higher stitchcraft, and who had developed a new art of abstract embroidery using stitches so refined that no one could tell whether they were actually there at all. "These must indeed be splendid stitches," thought the Minister. "If we can but engage this tailor to advise us, we will bring the adornment of our Emperor to such heights of ostentation that all the world will acknowledge him as the greatest Emperor there has ever been."

    So the honest old Minister engaged the master tailor at vast expense. The tailor was brought to the throne room where he made obeisance to the heap of fine clothes which now completely covered the throne. All the courtiers waited eagerly for his advice. Imagine their astonishment when his advice was not to add sophistication and more intricate embroidery to that which already existed, but rather to remove layers of the finery, and strive for simplicity and elegance in place of extravagant elaboration.

    "This tailor is not the expert that he claims," they muttered. "His wits have been addled by long contemplation in his ivory tower and he no longer understands the sartorial needs of a modern Emperor." The tailor argued loud and long for the good sense of his advice but could not make himself heard. Finally, he accepted his fee and returned to his ivory tower.

    Never to this very day has the full truth of this story been told: That one fine morning, when the Emperor felt hot and bored, he extricated himself carefully from under his mountain of clothes and is now living happily as a swineherd in another story. The tailor is canonized as the patron saint of all consultants, because in spite of the enormous fees that he extracted, he was never able to convince his clients of his dawning realization that their clothes have no Emperor.



  • @blakeyrat said in Docker is steaming pile of 💩:

    You could just run the software as software.

    I usually try to. Except:

    • On Travis, with its Paleolithic Ubuntu version, it's really pain in the arse. Japaric tried to, gave up and switched to docker. The scripts that use the docker are Insane™, but get the job done in a way the environment provided by Travis otherwise fails to.
    • Orchestrating docker containers in a cluster is not easy, but much, much simpler than orchestrating package installations.

    @masonwheeler said in Docker is steaming pile of 💩:

    Sure they do, they have all of them and more; they're just inside the virtual machine's OS.

    You can usually map files and you can pass options, though propagating them to the right place inside the VM is harder. But I don't think you can do equivalent of docker with ‘host’ network where the dockered process is not isolated.



  • @bulb said in Docker is steaming pile of 💩:

    On Travis, with its Paleolithic Ubuntu version, it's really pain in the arse. Japaric tried to, gave up and switched to docker. The scripts that use the docker are Insane™, but get the job done in a way the environment provided by Travis otherwise fails to.

    You could use an OS that doesn't suck shit. Just puttin' that out there.

    @bulb said in Docker is steaming pile of 💩:

    Orchestrating docker containers in a cluster is not easy, but much, much simpler than orchestrating package installations.

    ... you could use an OS that doesn't suck shit and has something like, say, .msi installer files. Just puttin' that out there.


  • :belt_onion:

    @masonwheeler said in Docker is steaming pile of 💩:

    @bulb said in Docker is steaming pile of 💩:

    Pardon me, sir, are you kidding?

    Are you really saying that a VM image provided by some random upstream is easier than docker image or package from the same upstream?

    Yes

    I feel like I'm the only one lurking in this thread who's really never had a problem with Docker and for whom Docker has been very convenient. 🤷🏼♂



  • @blakeyrat said in Docker is steaming pile of 💩:

    you could use an OS that doesn't suck shit and has something like, say, .msi installer files. Just puttin' that out there

    If Travis devs can't build a proper Deb package, what makes you think they can build an msi ?
    :rolleyes:


  • Banned

    @bulb said in Docker is steaming pile of 💩:

    But I don't think you can do equivalent of docker with ‘host’ network where the dockered process is not isolated.

    I don't know what you're talking about, but you can do whatever network configuration you want - internal NAT, transparent use of host's connection, or even direct exclusive access to network card - and several other configurations I've never used.

    @heterodox said in Docker is steaming pile of 💩:

    @masonwheeler said in Docker is steaming pile of 💩:

    @bulb said in Docker is steaming pile of 💩:

    Pardon me, sir, are you kidding?

    Are you really saying that a VM image provided by some random upstream is easier than docker image or package from the same upstream?

    Yes

    I feel like I'm the only one lurking in this thread who's really never had a problem with Docker and for whom Docker has been very convenient. 🤷🏼♂

    I heard stories of people who never had problems with Git losing their data.


  • :belt_onion:

    @gąska said in Docker is steaming pile of 💩:

    I heard stories of people who never had problems with Git losing their data.

    I also have never had problems with Git losing my data. I would say maybe I'm magic, but I don't want to tempt the wrath of the whatever high atop the thing.



  • @timebandit said in Docker is steaming pile of 💩:

    If Travis devs can't build a proper Deb package, what makes you think they can build an msi ?
    :rolleyes:

    :rolleyes:, Travis is a service. this one. They are not building any packages.



  • @blakeyrat said in Docker is steaming pile of 💩:

    and has something like, say, .msi installer files.

    Orchestrating .msi is a lot more work than orchestrating actually sensible packages. It is still way more work than orchestrating docker images.



  • @bulb said in Docker is steaming pile of 💩:

    @blakeyrat said in Docker is steaming pile of 💩:

    and has something like, say, .msi installer files.

    Orchestrating .msi is a lot more work than orchestrating actually sensible packages. It is still way more work than orchestrating docker images.

    I've been looking into how Debian packages work recently. It's pretty weird - an entire repository of software is signed by a single signature. It's all pretty well-documented. .deb files themselves are weird double- or triple-nested archive files, where the outermost layer is an AR archive that has exactly 3 files, always in the same order.



  • @heterodox said in Docker is steaming pile of 💩:

    @gąska said in Docker is steaming pile of 💩:

    I heard stories of people who never had problems with Git losing their data.

    I also have never had problems with Git losing my data. I would say maybe I'm magic, but I don't want to tempt the wrath of the whatever high atop the thing.

    "I turned. I cursed. I spat. Git crashed." ?



  • I only started doing docker seriously relatively recently and I've spent a significant percentage of that restarting docker, rebuilding it, etc.

    The one thing I would say about it is that the problem is usually a docker problem rather than an OS problem.

    It's just a shame that I can still have different behaviour from somebody else (regardless of OS similarity).


  • BINNED

    @masonwheeler said in Docker is steaming pile of 💩:

    Very true.

    The Emperor’s Old Clothes
    [...]

    Was he, by chance, talking about NodeJS or "desktop" apps which are just a web view of a web app?


Log in to reply