Multiple Containers
-
Hi All,
i am just trying to build my custom image to run OSTicket so i will pull the centos image then create multiple containers to host " Nginx , MariaDB , OSticket" and link all the containers with each others so any guide to do that ?.Thanks
-
Why build that with containers? That's a perfect case for a single VM / container.
-
@scottalanmiller since the container is designed to host one process or we can use supervisord to start many processes in that container
-
@scottalanmiller so we need to run one process per container and link all with each other
-
@AlyRagab said in Multiple Containers:
@scottalanmiller since the container is designed to host one process or we can use supervisord to start many processes in that container
Is that useful, though? How does that benefit you? That's no different than the base OS.
-
@AlyRagab said in Multiple Containers:
@scottalanmiller so we need to run one process per container and link all with each other
But... why? Once you do that, you've just made "container = process" and you can treat it all exactly like you do without containers. I'm not sure that the containers offer any benefit here, just complication. And having multiple isn't going to be useful, is it? What's the purpose to multiple containers?
-
Is this because you want to run many osTicket instances on a single host? I would still not do that with containers.
-
Since Docker is designed not to be like the traditional VT so there will be 2 ways :
1- One process per One container.
2- One container with many processes but using superviosrd to do the same task of the systemd inside the container.the below link explains how can we link containers with each other assuming we have a DB Server in a container and Web Server installed in other container and we need to link the two containers :
https://rominirani.com/docker-tutorial-series-part-8-linking-containers-69a4e5bf50fb#.hn73efm1p
-
@AlyRagab said in Multiple Containers:
Since Docker is designed not to be like the traditional VT so there will be 2 ways :
1- One process per One container.
2- One container with many processes but using superviosrd to do the same task of the systemd inside the container.the below link explains how can we link containers with each other assuming we have a DB Server in a container and Web Server installed in other container and we need to link the two containers :
https://rominirani.com/docker-tutorial-series-part-8-linking-containers-69a4e5bf50fb#.hn73efm1p
Yes, basically you are just turning the containers into individual processes. But your OS already does that. That doesn't appear to do you any useful service - it's just complication. What is the purpose of the container, everything you are mentioning we have without containers.
-
Scott - it might be worth mentioning the primary purpose of containers.
-
@scottalanmiller said in Multiple Containers:
@AlyRagab said in Multiple Containers:
Since Docker is designed not to be like the traditional VT so there will be 2 ways :
1- One process per One container.
2- One container with many processes but using superviosrd to do the same task of the systemd inside the container.the below link explains how can we link containers with each other assuming we have a DB Server in a container and Web Server installed in other container and we need to link the two containers :
https://rominirani.com/docker-tutorial-series-part-8-linking-containers-69a4e5bf50fb#.hn73efm1p
Yes, basically you are just turning the containers into individual processes. But your OS already does that. That doesn't appear to do you any useful service - it's just complication. What is the purpose of the container, everything you are mentioning we have without containers.
But we can use the lightweight size of the docker images from using docker other than using traditional VT.
we will save resources. -
@AlyRagab said in Multiple Containers:
@scottalanmiller said in Multiple Containers:
@AlyRagab said in Multiple Containers:
Since Docker is designed not to be like the traditional VT so there will be 2 ways :
1- One process per One container.
2- One container with many processes but using superviosrd to do the same task of the systemd inside the container.the below link explains how can we link containers with each other assuming we have a DB Server in a container and Web Server installed in other container and we need to link the two containers :
https://rominirani.com/docker-tutorial-series-part-8-linking-containers-69a4e5bf50fb#.hn73efm1p
Yes, basically you are just turning the containers into individual processes. But your OS already does that. That doesn't appear to do you any useful service - it's just complication. What is the purpose of the container, everything you are mentioning we have without containers.
But we can use the lightweight size of the docker images from using docker other than using traditional VT.
we will save resources.No, you are missing the point. The way that you are describing it, you don't have any purpose to VMs at all. The containers are totally unnecessary.
-
In many ways, VMs, Containers and Applications are all similar things. A VM is just a series of things converted to run as an application on top of a hypervisor. A Container is a series of applications converted to run as a simple application on an OS. An application is already an application running on an OS.
Once you want to make your containers so lean that they represent a single process, you are just adding overhead to applications that has no purpose. There is nothing for the container to bundle, it's too small. This is when you just deploy applications.
The purpose to containers would only be if you needed to isolate bundles of things as individual units, not one Apache process and one MySQL process or whatever. Just run those processes and you are all set, the OS already keeps them apart from each other using the same underlying mechanism as containers.
-
This is the same question I've been asking since the original post. You just assume that containers would be used, but never explain why. Now we've learned that you believe that you are using containers to replace VMs. But had the original post mentioned using one VM for each little tiny process we'd ask the same question - why do you have VMs?
One VM, no containers, is all that you need. NGinx, Apache, MariaDB, Memchace, Varnish - all on a single VM, each running as an individual process. Any additional VMs or containers would just add overhead that will not benefit you. Complexity without value.
When you would introduce VMs or containers here would be if different parts of this need to be split up, like if you were going to run the NGinx on one hardware platform and the MariaDB on another.
-
And keep in mind that OSTicket is just the code run by Nginx, not a separate thing being run. So you can't put OSTicket is one container and Nginx is another. Those two would be in the same processes regardless. OSTicket doesn't show up in the process list, it is just part of NGinx.
So you'd only likely have two containers, NGinx and MariaBD. Millions of web servers run those two on the same OS all the time, it's standard. You are trying to reinvent the wheel here. There is a standard pattern for this that works really well, unless you have some unbelievably unique need here that hasn't been mentioned, you can safely assume that you are not special and you should just deploy like normal. This isn't even a unique application, it's a standard, well known PHP application so the possibility that your deployment need is so unique as to warrant what you are doing is dramatically unlikely even within the existing realm of dramatically unlikely scenarios that we were already in.
-
@scottalanmiller said in Multiple Containers:
In many ways, VMs, Containers and Applications are all similar things. A VM is just a series of things converted to run as an application on top of a hypervisor. A Container is a series of applications converted to run as a simple application on an OS. An application is already an application running on an OS.
Once you want to make your containers so lean that they represent a single process, you are just adding overhead to applications that has no purpose. There is nothing for the container to bundle, it's too small. This is when you just deploy applications.
The purpose to containers would only be if you needed to isolate bundles of things as individual units, not one Apache process and one MySQL process or whatever. Just run those processes and you are all set, the OS already keeps them apart from each other using the same underlying mechanism as containers.
To be fair this is how a lot of people spreading the information describe containers should work. One service per container. Then using something like CoreOS, etcd, flannel, fleet/Kubernetes the system can move the container to any system in your cluster.
-
@stacksofplates said in Multiple Containers:
To be fair this is how a lot of people spreading the information describe containers should work. One service per container. Then using something like CoreOS, etcd, and flannel the system can move the container to any system in your cluster.
Sure, IF this is about autoscaling and physical load balancing... but I mentioned that
But moving containers around like that for databases doesn't really work. So this is only about the PHP application. And to make that work, each one needs a VM on which to be moved to. So that brings all of the overhead that he thought that he was avoiding back into the picture. So in the only scenario where it would make sense, it defeats that purpose for which it exists. -
This is just like the SAN conversations of yesteryear (and sadly still today). Sure the tech is great - but 9 time outta 10, you just don't need it. It doesn't fit your situation.
-
@scottalanmiller said in Multiple Containers:
@stacksofplates said in Multiple Containers:
To be fair this is how a lot of people spreading the information describe containers should work. One service per container. Then using something like CoreOS, etcd, and flannel the system can move the container to any system in your cluster.
Sure, IF this is about autoscaling and physical load balancing... but I mentioned that
But moving containers around like that for databases doesn't really work. So this is only about the PHP application. And to make that work, each one needs a VM on which to be moved to. So that brings all of the overhead that he thought that he was avoiding back into the picture. So in the only scenario where it would make sense, it defeats that purpose for which it exists.For the DB you'd most likely be using a backing store so you should be able to migrate. But anyway, I'm not arguing with you. Just saying there is a legitimate reason people arrive at this conclusion. Even docker is kind of confusing in their own definitions.
https://valdhaus.co/writings/docker-misconceptions/
There are great theoretical arguments for having a process per container, but in practice, it's a bit of a nightmare to actually manage. Perhaps at extremely large scales that approach makes more sense, but for most systems, you'll want role-based containers (app, db, redis, etc).
The app, db, and redid are all separate processes so I don't know what they're saying here.
-
Unless they are saying all of those are included in the container, which to me seems like a weird way to write that.
