91–100 of 134 posts
Earlier quoted context omitted.
From the perspective of the developer there is no difference. They just configure kubernetes or docker to use a different Container runtime and keep using the same compose files, etc.
I think the point the OPs was making is that yes, as you say, developers can use containers without knowing these differences, but that there are actually real and important differences and maybe it would be better if more devs were aware of them.
Earlier quoted context omitted.
People love to bring this up, but if Linux did have first-class containers, how would the developer's experience be different?
All system programs could operate and manage the containers running on the system, meaning you can use your existing knowledge to manage a bunch of containers. For instance, you could run your package manager across all containers to see if they have packages with known CVEs. Or manage the filesystems of all containers on the system (the usefulness of this is only clear with filesystems like ZFS and btrfs). This is e…
You can also do this on Linux with NixOS, where you can define the system and all containers it runs declaratively. Updating the system will update everything, including the containers (of course, you can also pin the containers or packages in the containers to specific versions).
> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…
Wow.
I have always wondered in which cases one would use "containers". I have asked so many Docker enthusiasts, "Why would I use containers instead of the strong process separation functionality that's built into the operating system, like users, cgroups, SELinux, etc?"
The answer has freakishly invariably been "Containers are lighter than virtual machines. Virtual machines use up all your resources. Containers can run just a single application, where virtual machines must emulate a whole operating system."
Now you're probably going, "How is that an answer to the question?"
And I know! It's not. These Docker enthusiasts have been impossible to get an answer out of. They have appeared like they're just parroting whatever they've heard from someone else as long as it seemed vaguely related to the question.
Now that I finally have an answer to my original question, it all makes sense again. And I'm inclined to agree that if you're stuck in the wrong bubble, we're both stuck in the same bubble.
Earlier quoted context omitted.
This isn't an accurate statement. I work on behalf of a federal government agency, and no one has write access in development, let alone production. Everything is required to run thru our ci/cd pipeline. Times are changing.
For the better? I’m not asking out of preference, I’m asking out of actual conclusion: is trading the operational overhead of running LDAP for a usually homegrown, usually wobbly automated scripting soufflé that turns Make into a distributed system objectively better? Has nobody stopped to ask, is DevOps and CI/CD the best framework we can achieve? Did nobody think to ask before they told your agency it was the ‘righ…
Earlier quoted context omitted.
An experienced software engineer (yeah, developer) has experience engineering software. It’s been less than 10yrs since the advent of containerized deployments, and the space has been fraught with change nearly on par with the front end JavaScript ecosystem. Might as well just stick to writing code. OK, that’s the perception of my own peers, but I assume it scales. DevOps is a recent advent, too, and sounds to me lik…
SRE was born of putting software engineers to work building operational software and automation tailored to an organization and application. In contrast, no matter what anyone says, DevOps was objectively born of replacing the operations discipline and career track with a poorly-understood tool economy and ongoing opex to a cloud provider. As you say, typical JavaScript engineers can’t be bothered to understand netwo…
What I think is as close as we get to a canonical meaning is the meaning in which it is used by The State of DevOps reports, based on very good science and research by Nicole Forsgren et al.
They characterise "DevOps" as a transition into faster deployments, shorter feedback cycles, less warehousing of unexecuted code, and having developers have generally more insight into what's going on in the production environment.
This, of course, can (and arguably should) be done in cooperation with proper system administrators, network engineers, etc.
In other words, DevOps is not in opposition of having the right people people operate the systems.
In particular, it has nothing to do with cloudifying things. You can run a product with a DevOps approach right onto bare metal servers – in fact, there are a lot of companies doing that, for simple economical and reliability reasons.
I'm all for ranting against the cloud and the little experience people have when trying to operate systems, but blaming "DevOps" for it seems like a mischaracterisation. There's a lot of value to be had by getting more feedback from production, whether production means bare metal or virtualised environments.
> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…
> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Wow. I have always wondered in which cases one would use "containers". I have asked so many Docker enthusiasts, "Why would I use containers instead of the strong process separation functionality that's built into the operating system, like users, cg…
Earlier quoted context omitted.
Exactly. Containers were around for at least a decade before Docker, just like mp3's were around for decades before the iPod. Docker's simple, efficient way to package containers were the key to their explosion.
> , just like mp3's were around for decades before the iPod That sounded wrong intuitively, so I decided to look it up: Wikipedia claims that mp3 was initially released in 1993, and the iPod was initially released in 2001, so not decades and not even a full decade.
The point stands though, that Docker didn't invent containers by a long shot; but they did make them massively more useful.
> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…
> To this day, I've heard CGroups being mentioned only once. See https://www.kernel.org/doc/Documentation/cgroup-v2.txt > "cgroup" stands for "control group" and is never capitalized. The singular form is used to designate the whole feature and also as a qualifier as in "cgroup controllers". When explicitly referring to multiple individual control groups, the plural form "cgroups" is used. To this day, I've heard cgr…
I hope you meant have not peeked under, so far. Any obscure problem will you down the rabbit hole. If you just stop looking then how can you solve problems?
Earlier quoted context omitted.
This isn't an accurate statement. I work on behalf of a federal government agency, and no one has write access in development, let alone production. Everything is required to run thru our ci/cd pipeline. Times are changing.
For the better? I’m not asking out of preference, I’m asking out of actual conclusion: is trading the operational overhead of running LDAP for a usually homegrown, usually wobbly automated scripting soufflé that turns Make into a distributed system objectively better? Has nobody stopped to ask, is DevOps and CI/CD the best framework we can achieve? Did nobody think to ask before they told your agency it was the ‘righ…
Earlier quoted context omitted.
Please don't propagate this. Running in a hypervisor with a possible different kernel vs running on the same kernel in the same ring as the host are two very different things. Implications of these are very different.
From the perspective of the developer there is no difference. They just configure kubernetes or docker to use a different Container runtime and keep using the same compose files, etc.