How many Linux servers do I really need?
-
@anonymous said:
@DustinB3403 said:
Docker doesn't add more to what you need, unless you want to go that route, and split the services with it... But virtualization would do this just as well in your case.
What about all the processing, memory, and space I save only having 1 OS?
It's trivial. For the same reasons that VDI is sometimes better than Terminal Servers - because the hypervisors do such an amazing job of this that the memory, disk, etc. does not expand like you would expect and the overhead of multiple VMs is very small. So small that unless you have a hugely saturated server, I can't imagine that you would notice. Containers are lighter than VMs, no doubt. But way more work and less flexible.
-
@anonymous said:
@DustinB3403 said:
Docker is meant to be running a bunch of identical processes side by side.
Hmmmmm..... I didn't know that. This course makes it seems like a container is a super lightweight VM.
Docker's purpose is to support extreme DevOps workflows where machines are never (literally, never) logged into and are built through tooling and in large numbers and never updated but destroyed and replaced instead. Can you do other things? Sure. Will it be fun? Heck no. Docker's design is around something so completely alien to the SMB market than the effort to use it well would be enormous.
-
@anonymous said:
@johnhooks said:
Traditional containers are (LXC, OpenVZ, jails, zones) docker is a different animal.
What one would be recommend in my use case?
LXC is the last traditional container technology on Linux. It ate OpenVZ. Docker and LXC completely own the market now. Rocket is an up and coming player. Jails requires FreeBSD. Zones requires Solaris.
-
@johnhooks said:
@anonymous said:
@johnhooks said:
If you're on Linux, I would recommend LXC. Ubuntu is making some interesting things with LXC and it's called LXD. One big feature is it will have live migration.
It's going to be Linux for sure. I am confused because this class has you to believe that Docker is better then LXC - there was a full 10 minute video comparing the two if I remember correctly. It seems that docker will some day support windows, where I don't think LXC ever will?
Wait, are they saying you can run Windows in a container or that you can run containers on Windows? I've heard something similar the latter, but not the former.
Microsoft is working hard to get Windows Containers ready because they've been left in the dust, again, and it is massively impacting their market.
-
@Dashrender said:
maintaining all of these micro VMs seems like such a pain in the ass. But I'm guessing there are tools, or at least scripts that can be written that will take care of all of them at once?
Yup, once you go DevOps containers are zero effort.
-
@Dashrender said:
LOL - I was wondering what benefit you'd get from running Windows inside a Linux container? (though I suppose one could say we already do that with XenServer - lol
Same benefits of containers anywhere. Lighter than virtualization.
-
@scottalanmiller said:
@anonymous said:
@DustinB3403 said:
Docker is meant to be running a bunch of identical processes side by side.
Hmmmmm..... I didn't know that. This course makes it seems like a container is a super lightweight VM.
Docker's purpose is to support extreme DevOps workflows where machines are never (literally, never) logged into and are built through tooling and in large numbers and never updated but destroyed and replaced instead. Can you do other things? Sure. Will it be fun? Heck no. Docker's design is around something so completely alien to the SMB market than the effort to use it well would be enormous.
With that being the case - then why do we hear so much about it? OK maybe not actually hear real information - but everywhere I turn - Docker docker docker docker docker this, docker that - and MS will support docker soon too - etc... it seems odd that even places like SpiceWorks at times seems overrun by it - is it simply that SMB IT personal don't want to be left in the dust so we glom onto anything we can?
Personally I felt like I missed the beginning of virtualization because to me it felt like it was for enterprise only - of course now it's being touted as the absolute starting point for any project unless you can show specific reasons why it doesn't/can't/won't work for your project (unlike SAN, which should still primarily live in the enterprise)
-
@anonymous said:
@johnhooks said:
If you're on Linux, I would recommend LXC. Ubuntu is making some interesting things with LXC and it's called LXD. One big feature is it will have live migration.
It's going to be Linux for sure. I am confused because this class has you to believe that Docker is better then LXC - there was a full 10 minute video comparing the two if I remember correctly. It seems that docker will some day support windows, where I don't think LXC ever will?
Ah, a class. That explains a lot.
Docker is good technology, to be sure. But the focus is completely different. If you are running a huge DevOps shop and every container is disposable and stateless and created through automation tools like Chef or Ansible and you have tons of identical ones, yes, Docker is pretty awesome (although LXC is too.)
If you are not doing DevOps and your entire infrastructure is not designed in code and you ever want to log into a VM or use its operating system or have multiple operating systems or are an SMB then Docker is pretty much useless. LXC is for containers as we've been using them for over a decade - lightweight virtualization in a traditional way (which can be done as DevOps too, if you want.)
So if they are telling you Docker is great but not explaining the ideas, concepts or goals they have missed the boat. Sounds like your instructor is a buzz word manager, most likely, and not too aware of the technology itself.
-
@scottalanmiller said:
@Dashrender said:
LOL - I was wondering what benefit you'd get from running Windows inside a Linux container? (though I suppose one could say we already do that with XenServer - lol
Same benefits of containers anywhere. Lighter than virtualization.
Running Windows inside a container would be lighter than virtualization?
So you're saying that you see a day when Linux would be installed on the hardware and Windows would be installed inside a container?
Aren't we already doing that with XenServer - is a VM inside XenServer a container? lol - I'm confusing myself.
-
@Dashrender said:
With that being the case - then why do we hear so much about it? OK maybe not actually hear real information - but everywhere I turn - Docker docker docker docker docker this, docker that - and MS will support docker soon too - etc... it seems odd that even places like SpiceWorks at times seems overrun by it - is it simply that SMB IT personal don't want to be left in the dust so we glom onto anything we can?
We hear about cloud computing non-stop there too, yet it applies as a need to no one in the SMB. Sure they can leverage it but not in a cloud way. That it is cloud computing doesn't matter to SMB users, they only care that it is a VPS. Docker is super important - to DevOps shops. The SMB market, especially certain communities, are full of people lacking a lot of tech skills and run off of buzz words and marketing and "what they think the enterprise is doing." Ever wonder how anyone in the SMB even knows about SAN let alone buys one? Same thing. Hear what's cool from the "big boys" and assume that they will sound cool if they talk about it, too.
There are lots of technologies that have little place in normal SMB yet are the major foci of conversation there. I'd call it "enterprise envy."
-
@Dashrender said:
Running Windows inside a container would be lighter than virtualization?
Containerization is lighter than virtualization. That is its sole purpose.
-
@Dashrender said:
Aren't we already doing that with XenServer - is a VM inside XenServer a container? lol - I'm confusing myself.
XenServer is a hypervisor. Windows is virtualized there, not containerized. Don't start applying the word container to things that are not container platforms. VMs run on hypervisors, containers do not.
-
@Dashrender said:
Personally I felt like I missed the beginning of virtualization because to me it felt like it was for enterprise only - of course now it's being touted as the absolute starting point for any project unless you can show specific reasons why it doesn't/can't/won't work for your project (unlike SAN, which should still primarily live in the enterprise)
Virtualization has been for the SMB since the day it was released. It's never been about size or scale. Containers too. SMBs that run Linux have used containers for a decade, it's standard, old hat, so old no one talks about it.
What is interesting today is that three new container players; Docker, Rocket and LXC, have emerged and have a lot of great technology behind them, big communities and are finally being used on a large scale. DevOps has made containers important in a way that it has not been before. In the same ways that cloud and DevOps have made VMs not just important but necessary, containers take this to another level by making things lighter still.
-
@Dashrender said:
maintaining all of these micro VMs seems like such a pain in the ass.
You'll confuse yourself less if you always call them containers and always call the others VMs. Don't mix the terms, it will just be confusing. Only two resulting object terms, VMs and containers.
A container takes no more effort to maintain than a VM, they are identical to a systems admin. Just as a VM takes no more effort to maintain than a physical box, less actually. There is nothing that creates "more" work.
-
@scottalanmiller said:
A container takes no more effort to maintain than a VM, they are identical to a systems admin. Just as a VM takes no more effort to maintain than a physical box, less actually. There is nothing that creates "more" work.
Right that I understand, but putting each and every service, when possible, in it's own VM or container is what I meant by the micro VMs - instead of maintaining one system that has AD/File/Print/small DB, now your maintaining 4 boxes. Granted with tools, managing them is easier today, but not the same as managing one. that's all I was getting at.
-
@Dashrender said:
@scottalanmiller said:
A container takes no more effort to maintain than a VM, they are identical to a systems admin. Just as a VM takes no more effort to maintain than a physical box, less actually. There is nothing that creates "more" work.
Right that I understand, but putting each and every service, when possible, in it's own VM or container is what I meant by the micro VMs - instead of maintaining one system that has AD/File/Print/small DB, now your maintaining 4 boxes. Granted with tools, managing them is easier today, but not the same as managing one. that's all I was getting at.
It's not the same as managing a single one, but it should be just as easy.
-
@Dashrender said:
@scottalanmiller said:
A container takes no more effort to maintain than a VM, they are identical to a systems admin. Just as a VM takes no more effort to maintain than a physical box, less actually. There is nothing that creates "more" work.
Right that I understand, but putting each and every service, when possible, in it's own VM or container is what I meant by the micro VMs - instead of maintaining one system that has AD/File/Print/small DB, now your maintaining 4 boxes. Granted with tools, managing them is easier today, but not the same as managing one. that's all I was getting at.
Ah, I see. I would argue that it is easier to manage, not harder, especially with Linux. The management of the OS is so trivial itself and so repeatable that there is nearly zero overhead from that - remember this isn't Windows. You can easily manage ten Linux boxes for every one of Windows before talking DevOps (these are real numbers from enterprise environments) so keep that in mind. Then consider how much easier it is to manage applications when you have no fear of interaction issues and can isolate the OS/Application for troubleshooting, repair, updates, etc.
For example, you need to do a reboot on the database server but the email server can't go down at the same time - no problem, you can reboot by application.
-
I really think LXD will be a nice addition. The one bad thing about LXC is it's not standard across distros. Each one seems to make it's bridge a different name, and if you try to create a container with a release of Ubuntu with systemd on a host without systemd it causes some issues.
The live migration in LXD will be a killer feature.
-
@johnhooks said:
I really think LXD will be a nice addition. The one bad thing about LXC is it's not standard across distros. Each one seems to make it's bridge a different name, and if you try to create a container with a release of Ubuntu with systemd on a host without systemd it causes some issues.
The live migration in LXD will be a killer feature.
Same issue you will always have with containers.
-
@scottalanmiller said:
@johnhooks said:
I really think LXD will be a nice addition. The one bad thing about LXC is it's not standard across distros. Each one seems to make it's bridge a different name, and if you try to create a container with a release of Ubuntu with systemd on a host without systemd it causes some issues.
The live migration in LXD will be a killer feature.
Same issue you will always have with containers.
Just throwing it out there as a reference
