Server4You Review
-
Are you just pointing out that you can create a private, inaccessible network? Of course, you can build your own private addressing.
-
@scottalanmiller said:
Are you just pointing out that you can create a private, inaccessible network? Of course, you can build your own private addressing.
What would you be accessing container wise via IP that's not over http?
-
@johnhooks said:
What would you be accessing container wise via IP that's not over http?
Tons of things. Storage servers, VPN servers, Remote Desktop, SSH, databases, etc. Anything that isn't a web page. HTTP is popular but hardly the only application protocol out there.
-
Why does it being a container make HTTP assumed?
-
@scottalanmiller said:
Why does it being a container make HTTP assumed?
It's not but all of those things are done from the host. Not the public facing IP address.
-
You would SSH into the host and do a docker exec -it <container name or Id> /bin/bash
-
@johnhooks said:
@scottalanmiller said:
Why does it being a container make HTTP assumed?
It's not but all of those things are done from the host. Not the public facing IP address.
Why would those things be from the host? Why run Docker if you bypass it and run services elsewhere?
-
Or if its an SSH container you give it a -P 8022:22 and access it that way.
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
Why does it being a container make HTTP assumed?
It's not but all of those things are done from the host. Not the public facing IP address.
Why would those things be from the host? Why run Docker if you bypass it and run services elsewhere?
Like the example above. To make changes in a MySQL database. You would ssh into he host, create a throwaway container to give you the MySQL prompt then delete the container.
-
@johnhooks said:
Like the example above. To make changes in a MySQL database. You would ssh into he host, create a throwaway container to give you the MySQL prompt then delete the container.
That doesn't make sense if MySQL is the service itself. You are exclusively thinking about modifying the service but not about consuming it.
-
Let's take a real world example.... you have Redis running in a Docker container. It needs to talk to Redis instances around the world. As well as its Sentinel services need to do this. How do you expose them?
-
Most of the data that changes would be stored on a volume on the host also. Just for a quick example the /etc/nginx/conf.d folder would be stored in say /var/lib/nginx or whatever folder you create. That way you just add a conf file there and the container reads it. This keeps you from needing to access containers via SSH and keeping them light.
-
@johnhooks said:
Most of the data that changes would be stored on a volume on the host also. Just for a quick example the /etc/nginx/conf.d folder would be stored in say /var/lib/nginx or whatever folder you create. That way you just add a conf file there and the container reads it. This keeps you from needing to access containers via SSH and keeping them light.
Why are you talking about SSH? You don't consume any services normally over SSH other than SSH Itself. But in that case, say you are making SSH Proxies, how are you going to do this without exposing SSH?
-
Then you just attach the ports. That was the whole point of the original post. You dont have multiple ip addresses, either you use something like nginx to reverse proxy or use hardcoded ports.
-
@scottalanmiller You could expose those services via simple port forwarding.
ie: MyServerHost.My.Domain:5539 could point to my Redis instance running inside of a docker instance on port 5678(port numbers pulled from magic hat).
-
@johnhooks said:
Then you just attach the ports. That was the whole point of the original post. You dont have multiple ip addresses, either you use something like nginx to reverse proxy or use hardcoded ports.
Okay, so you are adding PAT in front of it and doing something really messy. Yes, that will work and something like HA-Proxy is probably best. But doing odd ports is sloppy and having to have PAT in front of your hosted Docker instances is messy and how do you handle graceful scaling? You can but it becomes much more complicated.
-
@johnhooks said:
Then you just attach the ports.
You can do that without NGinx too, but in the case of HTTP we can sense how messy that is.
-
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.
