Global network

[roschaefer]

• use docker-compose version 3.5
• configure name of network, such that webapp service can join with another docker-compose up

[ionphractal]

@roschaefer I think it's a great idea to use shared networks between API and WebApp and it worked on my machine (Linux) like you described the procedure.

1. API: git checkout global-network
2. docker-compose up
3. WebApp: git checkout fix-docker-setup
4. docker-compose up
5. access localhost:3000

Still I have some points on this to consider:

• You have to trust that software because all DNS resolution will be redirected through it (yes, it's open source and runs locally, so this is not so bad).
• It is not very intuitive that the app starts up printing out webapp_1 | WEBAPP_BASE_URL http://webapp:3000 but you have to access http://localhost:3000 instead (fixed by adding hostname: webapp to the WebApp docker-compose.yml .
• Using the DNS proxy could bring also some complications.
  • It does not work on Mac OS (https://github.com/mageddo/dns-proxy-server#mac-support).
  • You (have to...) reference an absolute path for /etc/resolv.conf which might not work under Windows.
  • When the proxy or PC crashes, it might not write back the previous resolv.conf or whatever it does on Windows. This might leave unexperienced users out in the wild without any internet access (because DNS resolution doesn't work) unless they start the proxy again.

After some testing I found a way to remove the DNS proxy without sacrificing usability and this is by using xip.io for DNS resolution.

1. Remove the dns-proxy-server part completely from the API
2. Change the environment in WebApi to

      - WEBAPP_BASE_URL=http://webapp.127.0.0.1.xip.io:3000
      - API_HOST=api.127.0.0.1.xip.io

3. Change the container_name of the API to api.127.0.0.1.xip.io
4. Point your browser to http://webapp.127.0.0.1.xip.io:3000

Caveats:

• xip.io might not be responding. At work we were using it heavily in local dev setups. But as our use case was at certain stages very fragile, the slightest hickup in DNS resolution cost us hours, so we moved to a different testing style. For this kind of setup I don't think it's critical to have 100% availablity. But as it is open source (https://github.com/basecamp/xip-pdns) one could mitigate that by deploying one's own DNS infrastructure.

Other than that, it works on Mac OS and it should also work on Windows as well (@mimicc83 would you please confirm that?).

Note that I removed the network details in the following examples as they are the defaults anyway.

WebAPI docker-compose.yml:

version: '3.5'

services:
  webapp:
    image: humanconnection/frontend-nuxt:edge
    ports:
      - "3000:3000"
    build:
      context: .
      args:
        BUILD_COMMIT: ${BUILD_COMMIT}
    networks:
      - hc-network
    environment:
      - WEBAPP_HOST=webapp
      - WEBAPP_BASE_URL=http://webapp.127.0.0.1.xip.io:3000
      - API_HOST=api.127.0.0.1.xip.io
      - WEBAPP_PORT=3000
      - API_PORT=3030
      - MAPBOX_TOKEN=

networks:
  hc-network:
    name: hc-network

API docker-compose.yml:

version: '3.5'

services:
  api:
    container_name: api.127.0.0.1.xip.io
    build: .
    depends_on:
      - mongo
    networks:
      - hc-network

  mongo:
    image: mongo
    networks:
      - hc-network
    command: "--smallfiles --logpath=/dev/null"

networks:
  hc-network:
    name: hc-network

[ionphractal]

see my comment in the conversation (#169 (comment))

[ionphractal]

remove this and below (ipam), it's the default

[ionphractal]

remove when you remove the DNS proxy

[ionphractal]

remove the DNS Proxy and use xip.io

[ionphractal]

change to api.127.0.0.1.xip.io

[ionphractal]

remove lines below, they are the default

[roschaefer]

@ionphractal thanks a lot! I did what you suggested and mentioned you in the commits