Agreed, Docker is a runtime isolation for applications with a fully
containerized approach for things running within them. Networking is
entirely integral to this, so you need to understand ip addressing, nat,
tcp/udp ports, route table isolation (namespaces), things like that if
playing.
That said, port forwarding is something as old as the internet and the
advent of firewalls. In theory you have a full stack of software you
launch in the same container and network namespace, they all communicate
internally, and you only present a web UI or interface layer outside said
namespace to the world despite whatever ports the applications use within
the container openly. Web to app, app to db, like conversations are open,
but only the public web port pokes its head outside via docker nat. Those
ports need to be forwarded accordingly via whatever means, either
internally routable IP space, or port forwarding via firewall/load-balancer
means.
If you've ever had to wrapper a web app on a weird port with apache/nginx
for ssl access via a standard 443 port, or ever done load-balancers,
similar approach. I can draw countless examples, but will fall short
without an understanding of basic tcp/udp sockets and port forwarding.
Portainer, minikube, things like that make docker a bit more manageable for
us layfolk, but you still need to grok the concepts in play. Personally it
helped to deploy and see how it worked, not unlike network VRF's in use for
the past 20 years with firewall/nat layers between, but I also came from a
network background vs. system/app folks working backward.
-mb
On Tue, Jun 13, 2023 at 6:13 PM Stephen Partington <
cryptworks@gmail.com>
wrote:
> Docker is not a true VM. And to Mike's point it has a very tight network
> layer to keep the containers from pooping on each other.
>
> If you want a visual, portainer was a Handy tool for this.
>
> There is some really solid docker documentation out there and walk
> throughs.
>
>
> On Tue, Jun 13, 2023, 8:33 PM Michael Butash via PLUG-discuss <
> plug-discuss@lists.phxlinux.org> wrote:
>
>> As a "network guy", i.e. someone operating at layer 1-4 mostly, I would
>> say you need to understand networking first. So few developers and system
>> folk do, and thus struggle in today's day and age around basic networking
>> functions in a cloud world. It's some basic tradition of "when a packet in
>> a pocket hits a socket" like a childhood rhyme that goes unheard, and
>> really should if you call yourself a self-respecting developer today or the
>> past 20 years.
>>
>> Understanding basic Layer 1-7 of the network OSI model is the key.
>>
>> Docker relies heavily on NAT and IP routing between systems. Even
>> installing a typical web/app/db stack requires local socket interaction
>> between devices using the same networking - perhaps start with this first
>> and understand local socket connections to 127.0.0.1 first. Then move into
>> docker and IProute2 namespace separation with Docker and like
>> technologies. If you understand how a firewall works, this isn't that much
>> more complex.
>>
>> Keeping a consistent control plane between applications (again
>> web/app/db) and basic ip reachability isn't too hard when you understand
>> vlans and networking, maybe extending into overlay tech like Zerotier and
>> Tailscale for apps to talk to each other, securely, and across
>> clouds/networks/domains in general.
>>
>> I could give a whole "In the beginning.." speech, but best you simply
>> learn some networking first.
>>
>> -mb
>>
>>
>> On Tue, Jun 13, 2023 at 3:19 PM David Schwartz via PLUG-discuss <
>> plug-discuss@lists.phxlinux.org> wrote:
>>
>>> Right now I just want to be able to run my web app on my phone and have
>>> it access my back-end service remotely.
>>>
>>> I’m just having a challenge getting that "signal chain” set up and
>>> working. I know what it’s supposed to be in theory; it’s just not as easy
>>> as plugging a wire between a couple of sockets.
>>>
>>> Docker is optional.
>>>
>>> How can I do something like a "signal trace” in Windows?
>>>
>>> -David Schwartz
>>>
>>>
>>>
>>>
>>> On Jun 13, 2023, at 2:19 PM, Michael Butash via PLUG-discuss <
>>> plug-discuss@lists.phxlinux.org> wrote:
>>>
>>> Docker should be an inside to outside port mapping for your
>>> application. The outside port maps needs to reflect your firewall, load
>>> balancer, or whatever forwards traffic to it as the destination.
>>>
>>> [internet]-[firewall]-[host]-[docker] - you want to thread the needle of
>>> ports. This to That.
>>>
>>> If you don't want public facing ports for security reasons, vpn like
>>> openvpn or an overlay like zerotier/tailscale is recommended.
>>>
>>> -mb
>>>
>>>
>>>
>>> On Tue, Jun 13, 2023 at 2:03 PM David Schwartz via PLUG-discuss <
>>> plug-discuss@lists.phxlinux.org> wrote:
>>>
>>>> I’m looking for someone familiar with Docker who can help me out a
>>>> little bit.
>>>>
>>>> I’m working on an app with a REST-based web service that I’ve been
>>>> building inside of a VM (VirtualBox) running Win 10. I’m having trouble
>>>> getting the service part working on a remote server, and someone suggested
>>>> using Docker to isolate it and get it running inside of the VM first, then
>>>> copy it to the remote server. The remote server is also Windows based,
>>>> obviously.
>>>>
>>>> I’m having trouble getting all of the IPs and ports and holes in the
>>>> firewall aligned so I can reach it from outside the server.
>>>>
>>>> Right now I probably don’t _need_ Docker, although it could be helpful
>>>> at some point when I’ll need to scale-up, so I’m not even really committed
>>>> to using it other than it might be easier to set it up inside of the VM and
>>>> make everything work there first.
>>>>
>>>> (As much as I’d like to build the service to run on Linux, one of the
>>>> libraries I’m using is not set up for Linux yet, so it’s not an option at
>>>> this time. The vendor says they might support Linux at some point in the
>>>> future.)
>>>>
>>>> Anyway, I’m just looking to see if anybody might be able to help me get
>>>> my service code running on a remote Windows server that’s accessible from
>>>> elsewhere. (The code itself runs on the server, I just can’t reach it from
>>>> the outside, which is the whole point of having it there.)
>>>>
>>>>
>>>> -David Schwartz
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------
>>>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
---------------------------------------------------
PLUG-discuss mailing list:
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)