Check my 2 min audio theory on Containers
-
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.
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
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.
Well, if IT is trying to use Docker without container orchestration then there's not much benefit to be gained there at all
-
@flaxking said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
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.
Well, if IT is trying to use Docker without container orchestration then there's not much benefit to be gained there at all
Docker became the golden child of IT buzz before orchestration was available. If orchestration is needed to validate it, it seems like a solution looking for a problem.
-
@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.
That's a theory, but in the real world I've seen the opposite. Docker requires too much knowledge and skill on both ends and isn't as portable as people say. Docker requires both the admins and the developers to do more work and if either gets it wrong, Docker is harder to deal with. And since you rarely control both sides, it's a pretty big problem.
Docker doesn't really give the benefits you list. It can do that, but so can more traditional containers, without all of the Docker problems.
So given that moving workloads, and containerizing aren't benefits to Docker (it does them, but it's not unique), what problem do you feel Docker is actually solving over older, simpler solutions?
If there is one thing Docker doesn't do, it's make things easier for non-smart people. It requires all people to be smarter. This is exactly the opposite of the value it is providing.
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
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.No reason for competitors to arise. LXC and OpenVZ cover the spectrum and are free and part of the OS. Not the kind of thing you'd expect a competitor to arise to compete with. Just like there is no competitor for LVM. It's so good, and free, and built in, that replacing it would be completely silly.
