Check my 2 min audio theory on Containers
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
Also containers should be os agnostic (as long as compatible docker versions are used).
"Should be" is subjective. Containers are OS agnostic, but not kernel agnostic. Docker is subject to this like everything else, leading to it often making software harder to deploy rather than less.
Should be refers to the fact that focker containers still fail for assuming too much. Yhis is related to your previous comment
Yeah, every time I try Docker, it ends up failing due to so many requirements. Simpler to just install the apps directly. If we put each app into Docker (or anything similar), we end up right back to where we were without Docker.
Basically... if everything goes in Docker, nothing goes in Docker.
-
Containers on Windows can boot Ubuntu, but it does so by remove Linux from Ubuntu and replacing it with NTKernel. So instead of Ubuntu/linux, you run Ubuntu/WindowsNT which is relatively different.
Afaik docker on windows runs linux vm as containers node
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
Containers on Windows can boot Ubuntu, but it does so by remove Linux from Ubuntu and replacing it with NTKernel. So instead of Ubuntu/linux, you run Ubuntu/WindowsNT which is relatively different.
Afaik docker on windows runs linux vm as containers node
Last I knew, it can't. It actually runs Windows. Just like other containers on Windows. People call it Linux because they get BASH, but there is no Linux.
-
What would it even mean to run Linux in a container on Windows? Containers use shared kernels by definition, that's what makes it a container. So if you put the Linux kernel "in" a container, it can't be a container, right? Because if it isn't sharing the Windows kernel, it's not a container and therefore has all that overhead.
-
Here you go, Linux Containers on Windows.... it uses Hyper-V, rather than Containerization, to do a full virtualization of Linux, then you get Linux containers... on Linux, of course.
https://blog.docker.com/2017/09/preview-linux-containers-on-windows/
-
You could do the "same thing" by just running KVM, Xen, Hyper-V or whatever, and making a Windows VM and a Linux VM. Then installing Docker on the Linux VM. Exactly how we already do Docker containers on Linux. All Windows is doing special is making it more complicated, more confusing, more fragile, and harder.
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r actually The main benefit of containers is to disconnect sysadmin and devel work.
Not really. Containers are virtualization like any other, they've been around for decades and the idea that they were anything for developers is an extremely recent use case of only a very specific subset of containers. Most containers, and most of the history of containers, don't do anything like that, no more than any other kind of virtualization.
Yes but I think here we are talking docker. Docker is like python virtual envs for anything and not just for python. This is their main meaning to me.
Sure, if we are talking Docker and not talking Containerization, then Docker just seems like a sloppy, error prone way to do that.
My biggest issue with Docker is that it seems to make things worse rather than better. More complexity, more things to break, more dependencies. It introduces the very problems it claims to solve, problems that we weren't experiencing previously.
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r actually The main benefit of containers is to disconnect sysadmin and devel work.
Docker has a very mature environment where a lot of stuff can be easily rebuilt with a few hooks in github or similar.
Sys admin installs and manages the underlying os and the developer can upgrade the runtime as he needs in a disconnected way without minding about sysadmin and viceversa.
Also containers should be os agnostic (as long as compatible docker versions are used).
Just remind that docker is live a live distro. Persistent data are not moved with the container: you need SAN like storsge between 2 docker nodes to reload the same data. And this SAN like storage must be mounted in the same path.Why not create volumes for this data, that should be there when we import/export I assume ?
For me I am using Underlying = Ubuntu Server 18.04 it might bigger than what people use, but I like it. Alpine Linux also works with me but Ubuntu is just there in any VPS.
I am reading more about a few hooks in github I created docker repo, but still the line blurs where my work as sys admin stops and I cross to developers which I am not very smart in.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r actually The main benefit of containers is to disconnect sysadmin and devel work.
Not really. Containers are virtualization like any other, they've been around for decades and the idea that they were anything for developers is an extremely recent use case of only a very specific subset of containers. Most containers, and most of the history of containers, don't do anything like that, no more than any other kind of virtualization.
Yes but I think here we are talking docker. Docker is like python virtual envs for anything and not just for python. This is their main meaning to me.
Sure, if we are talking Docker and not talking Containerization, then Docker just seems like a sloppy, error prone way to do that.
My biggest issue with Docker is that it seems to make things worse rather than better. More complexity, more things to break, more dependencies. It introduces the very problems it claims to solve, problems that we weren't experiencing previously.
It does that, it does create more complexity at first.
Installing an app for us is much easier, like PHP-FPM + apache, it is only 10 commands or something, however if you did in docker/container in VPS you get the extra benefit of having clean environment in the host OS always + the container can be moved around easily to another VPS + it is much easier for non smart people to get your app and its updates + Docker provides free accout to publish one app.
Also the performance aspect is very good, but the storing this is bad abit.
The key idea here it is not currently hyper visor replacement, it is complementary tool that is good when you have service/server that does not need to store data.
-
The only linux technology which involves containers and acts as a proper virtualization layer afaik is lxd. I don't know if there is anything similar, aka, another frontend to lxc, the actual userspace driver for kernel isolation technologies.
Of course there is the long standing openvz, but I'm considering some in-tree technology which doens't require a custom kernel.@Emad-R if you focus on docker just condider it as a way for developers for packaging their apps and runtimes. No other usage is actually envisionable imho.
LXD or similar is a different topic: they are "real" containers.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r actually The main benefit of containers is to disconnect sysadmin and devel work.
Not really. Containers are virtualization like any other, they've been around for decades and the idea that they were anything for developers is an extremely recent use case of only a very specific subset of containers. Most containers, and most of the history of containers, don't do anything like that, no more than any other kind of virtualization.
Yes but I think here we are talking docker. Docker is like python virtual envs for anything and not just for python. This is their main meaning to me.
Sure, if we are talking Docker and not talking Containerization, then Docker just seems like a sloppy, error prone way to do that.
My biggest issue with Docker is that it seems to make things worse rather than better. More complexity, more things to break, more dependencies. It introduces the very problems it claims to solve, problems that we weren't experiencing previously.
100% agree. It makes sense only in a developers world no sysadmin usefulness here.
-
@emad-r said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r actually The main benefit of containers is to disconnect sysadmin and devel work.
Not really. Containers are virtualization like any other, they've been around for decades and the idea that they were anything for developers is an extremely recent use case of only a very specific subset of containers. Most containers, and most of the history of containers, don't do anything like that, no more than any other kind of virtualization.
Yes but I think here we are talking docker. Docker is like python virtual envs for anything and not just for python. This is their main meaning to me.
Sure, if we are talking Docker and not talking Containerization, then Docker just seems like a sloppy, error prone way to do that.
My biggest issue with Docker is that it seems to make things worse rather than better. More complexity, more things to break, more dependencies. It introduces the very problems it claims to solve, problems that we weren't experiencing previously.
It does that, it does create more complexity at first.
Installing an app for us is much easier, like PHP-FPM + apache, it is only 10 commands or something, however if you did in docker/container in VPS you get the extra benefit of having clean environment in the host OS always + the container can be moved around easily to another VPS + it is much easier for non smart people to get your app and its updates + Docker provides free accout to publish one app.
Also the performance aspect is very good, but the storing this is bad abit.
The key idea here it is not currently hyper visor replacement, it is complementary tool that is good when you have service/server that does not need to store data.
While I find useful to have a package+config easily moveable I would syggest to manage staless services with ansible/salt and their playbooks if you want automation at sysadmin level.
The only pro of docker as a sysadmin tool is you have a good ecosystem with a lot of automation already done. With ansible/salt I don't know if you can pick from repos or you need to write everything from scratch.
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r actually The main benefit of containers is to disconnect sysadmin and devel work.
Not really. Containers are virtualization like any other, they've been around for decades and the idea that they were anything for developers is an extremely recent use case of only a very specific subset of containers. Most containers, and most of the history of containers, don't do anything like that, no more than any other kind of virtualization.
Yes but I think here we are talking docker. Docker is like python virtual envs for anything and not just for python. This is their main meaning to me.
Sure, if we are talking Docker and not talking Containerization, then Docker just seems like a sloppy, error prone way to do that.
My biggest issue with Docker is that it seems to make things worse rather than better. More complexity, more things to break, more dependencies. It introduces the very problems it claims to solve, problems that we weren't experiencing previously.
It does that, it does create more complexity at first.
Installing an app for us is much easier, like PHP-FPM + apache, it is only 10 commands or something, however if you did in docker/container in VPS you get the extra benefit of having clean environment in the host OS always + the container can be moved around easily to another VPS + it is much easier for non smart people to get your app and its updates + Docker provides free accout to publish one app.
Also the performance aspect is very good, but the storing this is bad abit.
The key idea here it is not currently hyper visor replacement, it is complementary tool that is good when you have service/server that does not need to store data.
While I find useful to have a package+config easily moveable I would syggest to manage staless services with ansible/salt and their playbooks if you want automation at sysadmin level.
The only pro of docker as a sysadmin tool is you have a good ecosystem with a lot of automation already done. With ansible/salt I don't know if you can pick from repos or you need to write everything from scratch.
The semi-equivalent of the docker pattern with ansible/salt is if you killed the server each time it you were going to do a configuration change or update, and redeployed it with your configuration. Then your CM has to bootstrap it before it is ready. Or you let your CM configure it, then image it and deploy the image... but you're just reinventing the wheel here, because that's what you do with Docker and you get smaller sized images.
So if the server doesn't make sense to use Docker for, maybe it's because it won't fit neatly into an immutable pattern?
Though your configuration as code being dockerfiles is not as nice.
-
Spped is mostly about local cache. Even docker requires you to bootstrap the host and usually you do it with ansible like tools. Then you download the docker images and so...
What is attractive about stuff like docker is the automation-by-default approach which has created a really good ecosystem with a lot of premade automation already done.
Doker images on kubernates are awesome but if you have to manage your data center doing ansible + docker over just ansible is not gaining a lot imho.
If docker works out of the box it saves the initial time required to write ansible scripts and design them
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
Well go requires the kernel too. But yes for the most is the "from scratch" part which allows more abstraction
-
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
To simplify what you are saying.
Write software that doesn't really on the kennel and Docker just worksI actually agree with you on this.My actual experience is that developers don't know when their code actually uses things from the kennel, thus 90+% of all Docker images I try to run are just broken.
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
Well go requires the kernel too. But yes for the most is the "from scratch" part which allows more abstraction
Well I mean you have to have a kernel for anything to run. My point was it is technically possible to run a Go app in Docker natively on Windows with no Linux anywhere.
-
@travisdh1 said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
To simplify what you are saying.
Write software that doesn't really on the kennel and Docker just worksI actually agree with you on this.My actual experience is that developers don't know when their code actually uses things from the kennel, thus 90+% of all Docker images I try to run are just broken.
Right. A lot of the containers use FROM everypackageinadistro because they don't know what their dependencies actually are.
-
@travisdh1 said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
To simplify what you are saying.
Write software that doesn't really on the kennel and Docker just worksI actually agree with you on this.My actual experience is that developers don't know when their code actually uses things from the kennel, thus 90+% of all Docker images I try to run are just broken.
And another plus with this is you can use Docker/K8s or something else like Nomad. You have multiple tools at your disposal this way.
