It’s really simple, it’s a container containing a virtual os, which runs a browser and a webserver to run the app. The app connects to several external api services to do it’s thing.
Nah, a container isn’t running nearly as much as an entire OS. Not by a long shot. The Kernel isn’t there at all and the entire device stack is gone. Most don’t even have an init system running like systemd. They’re closer to a chroot in a single terminal than running an entire OS.
The OS flavor in a container is mostly about what flavor of supporting tools are available inside the container. Almost everything else is a thin wrapper making calls in to your host OS or container services.
Hmmm! Interesting! I knew the container shares the kernel with the host OS but I thought most of the rest would be there. I did never really have time to go through every detail tbh. Running 60 docker containers is too time consuming :) thanks for elaborating though.
I try to do both study and practice. So many things either don’t exactly work as advertised, or have really obscure catches that are really difficult to tease appart yourself. So the only way to get a clear picture is to both study and practice. Then, you get to know all of form, intent, and function and not just what you can working.
I mean, isn’t the entire point of a container largely non-functional compared to good deploy/install scripts? Both are perfectly capable of guaranteeing a predictable functional environment for the app. The container is just easier to use, harder to accidentally render insecure, and easier to clean up.
Harder to accidently render insecure? My experience is the opposite, that docker style containers frequently fail to update vulnerable dependencies.
Also depending on context, I can say often the container is harder to use. Snap is probably the easiest to use of the solutions, flatpak makes cli invocation a pain, and docker style sucks entirely for interaction, but is fine if your primary interaction is via Web service once you set it up (but oh boy, adding a webui package means you get to mess with nginx or apache proxypass by hand, and each app may require subtly different parameters in proxypass).
The person said “containers” so I was responding to both.
However, docker containers could stand to learn a thing or two with how flatpak and snap compose a runtime. Applications can say “allow x, y, and z dependency layers to update independent of the application container”, versus the docker style of the app developer must own maintenance of the entire image.
There may be reasonable differences with respect to how much of a users “real” files and environment are presented to a container in those scenarios, and functional differences like gui and networking suggesting different defaults, but image composition does not need differentiation for their use cases.
I get to witness to enterprise services flavor of that. Where the company pays software architects that aren’t actually coding and coders not allowed to make architectural decisions.
You have software that takes http? You need to rewrite it so that you only speak rabbitmq, and use it for every http request or Web socket message, don’t worry, we have a team that specializes in making http translate to rabbit mq, so you only have to rewrite the server code, another team will handle the http listener that translates to you.
What’s that, you have a non http protocol? Well, the other team isn’t scoped to handle that, so you’ll need to convert your listener to rabbitmq and create a whole separate container to actually receive the packets in udp and then translate to rabbitmq. No “processing” software is allowed to speak anything but rabbitmq, and network listener containers are only allowed to dumb receive and Forward.
It’s really simple, it’s a container containing a virtual os, which runs a browser and a webserver to run the app. The app connects to several external api services to do it’s thing.
It’s like, really simple!
I‘m very scared that this might actually be the case in some apps out there.
If they’re running a virtual OS in a container, they’re doing it very wrong. Containers and VMs are quite different, even on a Windows host.
I‘m not sure I understand. At least docker containers have their own os, mostly alpine linux. Dunno if that applies to other apllications.
Nah, a container isn’t running nearly as much as an entire OS. Not by a long shot. The Kernel isn’t there at all and the entire device stack is gone. Most don’t even have an init system running like systemd. They’re closer to a chroot in a single terminal than running an entire OS.
The OS flavor in a container is mostly about what flavor of supporting tools are available inside the container. Almost everything else is a thin wrapper making calls in to your host OS or container services.
Hmmm! Interesting! I knew the container shares the kernel with the host OS but I thought most of the rest would be there. I did never really have time to go through every detail tbh. Running 60 docker containers is too time consuming :) thanks for elaborating though.
Yea, I still need to learn a lot myself. Heck, I still have https://optimizedbyotto.com/post/linux-containers-docker/ open in a tab waiting to be read… For a couple weeks now. Sigh.
Dont worry. Learn as you go. I rather make projects to learn things in a practical way.
I try to do both study and practice. So many things either don’t exactly work as advertised, or have really obscure catches that are really difficult to tease appart yourself. So the only way to get a clear picture is to both study and practice. Then, you get to know all of form, intent, and function and not just what you can working.
It probably was very simple for the kid who wrote it, just import everything and write a couple of lines to use all this stuff that already exists!
Gotta love using a base container image that is far too overkill for what you’re trying to run.
I mean, isn’t the entire point of a container largely non-functional compared to good deploy/install scripts? Both are perfectly capable of guaranteeing a predictable functional environment for the app. The container is just easier to use, harder to accidentally render insecure, and easier to clean up.
All of their benefits are NOT for the app itself.
Harder to accidently render insecure? My experience is the opposite, that docker style containers frequently fail to update vulnerable dependencies.
Also depending on context, I can say often the container is harder to use. Snap is probably the easiest to use of the solutions, flatpak makes cli invocation a pain, and docker style sucks entirely for interaction, but is fine if your primary interaction is via Web service once you set it up (but oh boy, adding a webui package means you get to mess with nginx or apache proxypass by hand, and each app may require subtly different parameters in proxypass).
Docker is not in a competitor for snap and flatpak. They are tackling very differend kinds of installations.
The person said “containers” so I was responding to both.
However, docker containers could stand to learn a thing or two with how flatpak and snap compose a runtime. Applications can say “allow x, y, and z dependency layers to update independent of the application container”, versus the docker style of the app developer must own maintenance of the entire image.
There may be reasonable differences with respect to how much of a users “real” files and environment are presented to a container in those scenarios, and functional differences like gui and networking suggesting different defaults, but image composition does not need differentiation for their use cases.
It also sends your IP and location to Firebase, because the response comes as a push.
Every third time it outputs an ad text and plays an audio ad in the background.
I get to witness to enterprise services flavor of that. Where the company pays software architects that aren’t actually coding and coders not allowed to make architectural decisions.
You have software that takes http? You need to rewrite it so that you only speak rabbitmq, and use it for every http request or Web socket message, don’t worry, we have a team that specializes in making http translate to rabbit mq, so you only have to rewrite the server code, another team will handle the http listener that translates to you.
What’s that, you have a non http protocol? Well, the other team isn’t scoped to handle that, so you’ll need to convert your listener to rabbitmq and create a whole separate container to actually receive the packets in udp and then translate to rabbitmq. No “processing” software is allowed to speak anything but rabbitmq, and network listener containers are only allowed to dumb receive and Forward.
Tech hipsters be like: you had me at container!