Server4You Review
-
Right. I'm only planning to use NGinX for the Web interfaces in each of my docklets (Is that even the right term? lol).
so my NGinX will reverse proxy for those.
In the event that I need to communicate between docklets, then I will simply attach the services to various ports and connect that way. IE: MySQL could be on port 3306 for my main instance, and 5306 for a Wordpress Docklet, and 9958 for a PGSQL Docklet... or whatever else I decide to set up.
-
@dafyre said:
Right. I'm only planning to use NGinX for the Web interfaces in each of my docklets (Is that even the right term? lol).
so my NGinX will reverse proxy for those.
In the event that I need to communicate between docklets, then I will simply attach the services to various ports and connect that way. IE: MySQL could be on port 3306 for my main instance, and 5306 for a Wordpress Docklet, and 9958 for a PGSQL Docklet... or whatever else I decide to set up.
Ya its cool. You don't even needto manage any of that. Just type
docker run --name some-app --link some-mysql:mysql -dand it links them together. -
I didn't mean to make this into a giant discussion. I agree that PAT is kind of clumsy, but it's how they have it documented. So if you need a specific service from a container to the outside world you do it with ports. Inter-container communication is either done by linking the containers together. Controlling a container is either done by connecting to the container from the host and giving commands directly, by creating a throwaway container which links to the original container, or by using a shared volume on the host. This is all done behind 1 ip address.
With CoreOS you can link multiple hosts together with etcd and then have certain containers on certain hosts, but that's a whole different conversation.
-
@johnhooks said:
I didn't mean to make this into a giant discussion. I agree that PAT is kind of clumsy, but it's how they have it documented. So if you need a specific service from a container to the outside world you do it with ports.
All communication is with ports
It's ports sharing a single IP that I've not seen done anywhere. Not that you can't, but it is very clumsy having to manage ports in that way for all systems. -
@scottalanmiller said:
@johnhooks said:
I didn't mean to make this into a giant discussion. I agree that PAT is kind of clumsy, but it's how they have it documented. So if you need a specific service from a container to the outside world you do it with ports.
All communication is with ports
It's ports sharing a single IP that I've not seen done anywhere. Not that you can't, but it is very clumsy having to manage ports in that way for all systems.I could be 100% wrong, but I think that's why it's been more of a dev tool and not exploded in the production area. However, with CoreOS and etcd that might be different.
-
@johnhooks said:
I could be 100% wrong, but I think that's why it's been more of a dev tool and not exploded in the production area. However, with CoreOS and etcd that might be different.
Docker is very much a production tool. I just left Change.org where it is being used for production. Lots of devs use it, of course, but Docker is not being produced for development, it is for production.
-
@scottalanmiller said:
@johnhooks said:
I could be 100% wrong, but I think that's why it's been more of a dev tool and not exploded in the production area. However, with CoreOS and etcd that might be different.
Docker is very much a production tool. I just left Change.org where it is being used for production. Lots of devs use it, of course, but Docker is not being produced for development, it is for production.
So how do they handle the port issue?
-
Containerization was developed by Sun (not Oracle) and has been the only way for deploying Solaris for a decade now. Linux has had product containers for almost as long.
-
@johnhooks said:
So how do they handle the port issue?
They don't run Docker on a single IP address VM
No different than how you host any VM, you get one IP per machine. -
Oh ok, makes sense.
-
I think that the average business using Docker is doing so on private IP ranges. And anything exposed to the outside world is going through load balancers or connecting to a proxy service like CloudFlare Enterprise.
-
@scottalanmiller said:
I think that the average business using Docker is doing so on private IP ranges. Any anything exposed to the outside world is going through load balancers or connecting to a proxy service like CloudFlare Enterprise.
Oh ok that makes sense.
-
@johnhooks said:
I didn't mean to make this into a giant discussion.
Sure, sure, I believe you!
But without giant discussions nobody learns anything.If I were to use docker, on my home network, then I would use my own DHCP server and let each docklet (please... somebody correct me if I'm wrong... or tell me if I just created a new buzzaord, lol) get it's own IP address.
However, in the sense that I am running this from a VPS provider, I will have only a single IP address (right now) to run things from.
This does bring me to another question though... are Docker containers migratable like VMs? ie: Can I move this docklet from Server A to Server B ?
-
@dafyre said:
@johnhooks said:
I didn't mean to make this into a giant discussion.
Sure, sure, I believe you!
But without giant discussions nobody learns anything.If I were to use docker, on my home network, then I would use my own DHCP server and let each docklet (please... somebody correct me if I'm wrong... or tell me if I just created a new buzzaord, lol) get it's own IP address.
However, in the sense that I am running this from a VPS provider, I will have only a single IP address (right now) to run things from.
This does bring me to another question though... are Docker containers migratable like VMs? ie: Can I move this docklet from Server A to Server B ?
Ya that's a big upside to them. If you develop one on your laptop, it's the same when you put it on a production server. You can commit the container and then move it to a new host. There are some ways that will keep the data in volumes and some that won't though.
-
Yup, the movement of containers is one of the reasons that ZFS was built like it was. ZFS was designed to be the storage for Solaris Zones.
-
This is cool information to have.
Sadly, it looks like S4U does not support Docker... Off to bug their support team I go. -
@dafyre said:
This is cool information to have.
Sadly, it looks like S4U does not support Docker... Off to bug their support team I go.In what way does it not support it? How did they go about breaking it?
-
That is what I'm going to ask, lol.
The system that I am operating from (CentOS 7) does not have any of the files in /boot that I need to modify grub. Nor does it have the current config of the Kernel anywhere that I can find on the system. (/boot folder is empty, except for grub folder. And grub folder is empty except for a splash image). It's not in /proc/config or /proc/config.gz
Any other places I am mising?
The problem is that I cannot use NAT (nf_nat modules are missing). Docker appears to error out with something about nf_nat. I can't even create dummy interfaces using ip link add...
For example:
[root@mycentos7 ~]# ip link add name test0 type dummy
RTNETLINK answers: Operation not supportedor
INFO[0000] API listen on /var/run/docker.sock
ERRO[0000] 'overlay' not found as a supported filesystem on this host. Please ensure kernel is new enough and has overlay support loaded.
WARN[0000] Running modprobe nf_nat failed with message: ``, error: exit status 1
INFO[0000] Firewalld running: false
FATA[0000] Error starting daemon: Error initializing network controller: Error creating default "bridge" network: inappropriate ioctl for deviceI just emailed their support guys, I'll see what they say. SELinux is disabled at the moment.
-
Sadly, one of their support reps tells me that They do not support docker right now, so I told him that his competitors do and asked where I could submit a feature request, lol.
-
That is pretty crappy. That is how people use these systems these days. That seems to put a lot of extra constraints on this.
