reverse-proxy-ripcord:

This repository is meant as a companion repository to kobo-docker-ripcord. However, it can be used on its own to set up a reverse-proxy environment for other docker containers. The docker-compose files are structured to provide WEB (https) or LAN (http) network connectivity to services running in docker containers. reverse-proxy-ripcord can be used in the following ways with little in the way of configuration on the part of the end user.

Note: Command line instructions must be executed inside the reverse-proxy-ripcord directory.

Prerequisite knowledge base:

Docker Command Line

Docker Compose Command Line

Server Side Firewall

Public DNS Configuration -- for Option 1 below

Local DNS Configuration -- for Option 2 below

Router Configuration -- specifically port forwarding

ping -- a method to test network connectivity

nslookup -- a method to test DNS resolution

ipconfig -- a method to see the ipconfig of a given computer

DNS settings Windows

DNS settings Mac

Running the following command will give linux manual page specifics about a command that is giving you trouble:

$ man [command]

Option 1 - Reverse Proxy with SSL support:

This repository can be used as a stand alone repository to set up a jwilder reverse proxy server with companion SSL support. This option would be taken by doing something like the following at the command line:

$ ln -s docker-compose.web.yml docker-compose.yml
$ docker-compose up -d

The first line above forms a symlink allowing the user to run docker-compose commands against docker-compose.web.yml as shown in the second line above. If there is a need to remove the symlink do the following:

$ rm docker-compose.yml

Option 2 - Reverse Proxy without SSL support:

This repository can be used as a stand alone repository to set up a jwilder reverse proxy server. This option would be taken by doing something like the following at the command line:

$ ln -s docker-compose.lan.yml docker-compose.yml
$ docker-compose up -d

The first line above forms a symlink so that the user can use docker-compose commands against docker-compose.lan.yml as shown in the second line above. If there is a need to remove the symlink it would be done with the following:

$ rm docker-compose.yml

Usage

1. Clone this repository onto a server equipped with Docker Engine and Docker Compose.

2. Decide which option is appropriate for your use case. Option 1 is meant for WEB deployment where there is a need to provide secure https communication between clients and servers with SSL. However, it also maintains the ability to serve http traffic depending on the configuration of containers added to the Docker host. Option 2 is meant for LAN deployment where there is NO need to provide secure https communications between clients and servers with SSL. Both Option 1 and Option 2 are configured with a test web server that will display the following image if deployed successfully.

3. Make the appropriate symlink according to the option chosen.

4. Make the appropriate entires in webserver.config.

5. Make the appropriate entires in your public or local DNS system. See DNS Records + Router Settings for guidance on settings. Option 1 requires public DNS configuration. Option 2 requires local DNS configuration.

An example of an Option 1 public DNS setup from FreeDNS.afraid.org is shown below.

6. ping the test address that was set in webserver.config. Adjust DNS settings until a successful ping response is returned. See below for what a successful ping from a command line looks like.

7. Option 1 Only: Forward ports 80 (http) and 443 (https). Ports should be forwarded to the IP address of the Docker host on which the instance of reverse-proxy-ripcord is deployed. See DNS Records + Router Settings for guidance on settings.

An example port forwarding setup from an ASUS router is shown below.

8. Disable any server side firewalls for testing.

9. Start an instance with:

   $ docker-compose up -d

10. Watch the logs with:

    $ docker-compose logs -f

11. With clean logs, browse to the test address entered in webserver.conf. The test page included above proves a successful deployment.

12. Stop an instance with:

    $ docker-compose stop

13. Remove all containers associated with the instance with:

    $ docker-compose down

No Worky!

An unsuccessful test is usually the result of network configuration problems.

1. Did you use the Docker host local IP address for local network configuration and your public IP address for public DNS configuration?

2. For Option 1 deployments: Can you successfully ping your test web server address that was set in webserver.conf? A representation of a good ping check is included above. A represenation of a bad ping check is included below.

If you got a good ping check your router port forwarding. An example of the logs output for bad port forwarding is included below.

If the router port forwarding looks good double check that you disabled the firewall on the Docker host. If you did not get a good ping check your public DNS settings to include the IP address. If you have a dynamic IP address your need to forward IP address changes to your DNS provider to ensure long term connectivity.

3. For Option 2 deployments: Can you ping the local test web server address set in webserver.conf? If not, you may need to change the DNS server your computer is using. This presumes that you have already correctly set up a local DNS server on your network.

4. And so much more. Networking can be a grinding challenge. Remember the fundamentals and use simple tools like ping to narrow down where the problem lies.