Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Bjorn S
    @Bjeaurn
    am I making a mistake in my mental mindmap?
    I mean, when I look at my networks topology now in swarmpit; I have test_default, test2_default (being appA and appB)
    and I would expect, they can both have their port 80 assignment in there.
    instead, they seem to give up their private network and influence the entire swarm, instead of just their own personal little stack
    am I making any sense at all? :-P
    Mike Holloway
    @mh720
    I don’t have any experience there. My experience is that you need to join other stacks into the SAME network in order for them to be able to route to each other. See ‘attachable: true’ within https://github.com/swarmstack/swarmstack/blob/master/docker-compose.yml and then maybe https://github.com/swarmstack/errbot-docker/blob/master/docker-compose-swarmstack.yml for example of a second stack connecting to the first one’s network
    Bjorn S
    @Bjeaurn
    hmmm ok, my main point being that I think stacks shouldn't (by default) be connecting to eachother
    Surely they need to expose something to the entire swarm, and that's up to a reverse proxy to figure out then
    which is a different situation in which I have a bit more experience myself using nginx
    It's just that I can't wrap my head around separating my stacks and containers into their own isolated areas and then having a main manager handle the routing to the correct stack/container
    Mike Holloway
    @mh720
    Seperate stack named networks will only be able to connect to each other if they ‘expose’ something to the world, otherwise they would be isolated from each other.
    Bjorn S
    @Bjeaurn
    hmm ok let's flip this around
    Ah ok that makes a bit more sense to me
    but that would mean you wouldn't expose port 80:80, but have it randomize instead so your proxy can take port 80:80
    or have a fixed port per application basically
    if you were running a docker swarm, and you wanted to deploy 2 or more separate apps that have no reason to communicate to eachother
    how would you go about separating and assigning networks and ports?
    Mike Holloway
    @mh720
    yup. or use reverse proxy. those I believe are your only options. Only 1 thing can ‘expose’ a given port per swarm (or non-swarm host)
    Bjorn S
    @Bjeaurn
    hmmm ok, then that's where my mental image is wrong
    I wasn't expecting an exposed port to be "Swarm wide"
    Mike Holloway
    @mh720
    Yup, they are.
    Bjorn S
    @Bjeaurn
    as I've noticed.
    But how would you organize like 3 apps in a swarm, all needing to expose port 80 cause it's the web.
    you would reverse proxy and give them fixed ports, 9001, 9002, 9003 etc?
    Mike Holloway
    @mh720
    Swarm will accept that exposed port’s traffic on ANY swarm host member, and transparently proxy that traffic for you to the correct host that the container (or containers) that the service is running on.
    Bjorn S
    @Bjeaurn
    Oooooh ok
    That does make a bit more sense
    Alright, and you connect by container name, so http://my-container:80
    Mike Holloway
    @mh720
    meaning that you could set up a DNS RR against all your swarm members to achieve a poor person’s HA, although in practice you’d instead want to use some sort of upstream load-balancer (HA proxy, etc) that is aware of the health of the hosts it’s sending traffic towards and not send it potentially to a dead swarm host
    Bjorn S
    @Bjeaurn
    is there a way, if you have like replicated containers, to connect to a "service" name or whatever the proper terminology is?
    Ah yeah, good point.
    Mike Holloway
    @mh720
    http://my-container:80 exactly
    Bjorn S
    @Bjeaurn
    hmmm
    I gotta test this
    cause now I'm wondering if my-container:80 will have docker swarm loadbalance across all available containers under that name
    if it does. then I may have been going at this the wrong way entirely
    Thanks so much for your time and insights @mh720
    Mike Holloway
    @mh720
    Yes, in your docker compose, set the service to ‘deploy: mode: global’ and it would run the service on all your hosts, then you could connect to a specific instance of the service directly by pointing at http(s)://swarmnode.fqdn:port .. if you set the service to only replicate X copies that are less than the number of nodes, they will bounce around nodes and you will never know where they are. You could also use a trick of running individual copies of the service and ‘pin’ them to a specific known node using ‘placement: constraints’.
    Bjorn S
    @Bjeaurn
    yeah I read about that. But the http://container-name:80 should work wherever it ends up right?
    Mike Holloway
    @mh720
    Yes exactly, swarm will proxy the traffic transparently to some swarm host that can handle that traffic for you
    back in a bit
    Bjorn S
    @Bjeaurn
    Sure thing!
    Bjorn S
    @Bjeaurn
    hmmm okay I gotta lookup how to connect to containers like this from the swarm. I think this way of connecting is for inside the stacks, not the entire swarm
    or from outside of the swarm for that sense.
    Bjorn S
    @Bjeaurn
    Like I was trying things like http://stack_container:80 but that didn't work
    and the container name doesn't work at all in docker swarm/stack mode
    Bjorn S
    @Bjeaurn
    Alright I'm severly misunderstanding something or I am just not doing it right @mh720
    Mike Holloway
    @mh720
    Bjorn you’re correct, dns names are available only on the inside of docker networks, and you could have same service names in different stacks with same service name (different stack name) and they won’t collide or resolve each other. If for instance nginx is in a stack with appA and appB, you could bind nginx to 80 external:80 internal then in nginx reverse proxy config :80{ proxy http://fqdn/appA/ appA:80, http://fqdn/appB/ appB:80} and in the stack appA and appB will each have their own (internal) IP, and they can bind to whatever ports they each want (80 above), and only things inside that stack can access/ping them since you aren’t exposing those services directly to the outside (only nginx service is exposed)
    You could have 100 containers in the stack, in that stack network, all bound to their own port 80, not exposed; and then make 100 stanzas in your exposed reverse proxy to get traffic to them from the outside world.
    Mike Holloway
    @mh720
    Only one stack can “expose” 80 though, over the entire swarm (because all swarm hosts will accept traffic on that exposed port and will transparently get the traffic to the right place.