Server4You Review
-
@johnhooks Good idea!
I need to spend some time with NginX and see how it fares with my OwnCloud instance.
-
@scottalanmiller you can link the containers together via a port and then nginx to the front facing container. Everything else you just link the containers with a throwaway container to control it and the delete that extra one.
-
@johnhooks said:
@scottalanmiller you can link the containers together via a port and then nginx to the front facing container. Everything else you just link the containers with a throwaway container to control it and the delete that extra one.
Not sure that I understand what you are saying. The individual containers act like individual VMs. But nGinx just does web not "any" traffic.
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller you can link the containers together via a port and then nginx to the front facing container. Everything else you just link the containers with a throwaway container to control it and the delete that extra one.
Not sure that I understand what you are saying. The individual containers act like individual VMs. But nGinx just does web not "any" traffic.
Right but you don't really access them via IP unless they're web facing containers. Like MySQL for example. You would create a MySQL container and then create another MySQL container to attach to it with the MySQL prompt. Then create your database, and then delete the second mysql container. Then you link your web app to the original MySQL container and that's how it accesses the database. All of that is done from the host. The only thing you would really be accessing via IP would be something over http. The containers don't even really need a public facing port number, you can link them behind nginx and then use an upstream block to access each http site or app.
-
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.
