Category: Networking

A Checklist for When “The Website Just Doesn’t Work”

We’ve all come across this frustrating moment, that nothing more than a simple “it doesn’t work” is provided.

And you have 1 hour to fix it.

Does it really not work?

It might be a good idea to figure out if the claim truly holds.

  • Can the website be accessed on your laptop?
  • Can the website be accessed on your phone, with cellular data?
  • Can your friends in another timezone access it?
  • Does the browser show any useful information?

It kinda works, but in a whacky way

Or, you only get a white screen.

  • Are any of the external resources your front-end references working? (Open your developer console and check the network tab)
  • Does clearing the local cache help it?

When nobody can access it

It’s a good sign for you to become worried. But you don’t need to panic yet.

  • Is the web server running?
  • Is the edge router/reverse proxy/load balancer running?
  • Is your service running?
  • Is your DNS record correct?
  • Is your SSL certificate valid?

When the above checks all pass without issues, you can now panic a little. And check the following:

  • Does the server still exist?
  • Is the server connected to the internet, and is listening on the correct ports?
  • Can you at least ping the server?

To be honest, at this point there’s not a whole lot you can do. The problem is probably beyond what you can fix. (Maybe the datacenter went offline, for example.)

When only some of us can access it

If this is the conclusion, then you can probably pinpoint the problem along the way as the request travels from the client to your server. Something went wrong during that time.

  • Did you recently updated your DNS record?
  • Are the people who cannot access the website at least getting the correct IP address resolved?
  • Can the people who cannot access the website at least ping your server?
  • Does it only fail when it’s over a certain ISP?

Things to watch out for when creating a swarm-wide network

Relying on Docker’s network documentation we know that there are the following types of networks offered by Docker.

NameDescription
bridgeFor standalone containers to talk to each other.
hostOnly for swarm services. No isolation between host and container, and the container uses host’s network directly.
overlayAllows swarm services on different nodes to talk with each other.
Allows swarm services to talk to standalone containers.
Allows standalone containers on different nodes to talk with each other.
macvlanAllows containers to have their own MAC address, and the docker daemon routes traffic using MAC addresses.
Used to provide compatibility to legacy applications that expects direct connection to a physical network.
noneContainers attached to it have no networking.
Docker network types.

The Exercise

To put theory into practice, let’s suppose we have a legitimate situation at hand that requires the use of an overlay network for our swarm cluster.

Inside the cluster, we have two nodes, A and B, where A is the swarm manager. Let’s say we want all ingress network traffic to go to A, on which a Traefik instance runs to distribute the traffic to B, on which our application runs.

To make this happen, we have to solve the following problems when it comes to networking:

ProblemSolution
Make sure incoming traffic from clients goes to A.We can configure our DNS records to point our domain to A.

This can be done with a simple A record. And in the case of IPV6, an AAAA record. (I know, the name is silly.)
Make sure traffic arriving at A is correctly forwarded to B.We can make use of Traefik.

To make it work, we have to make sure B is discoverable by Traefik. This means that we need to put A and B on the same network so they have the possibility to talk to each other. We also need to make sure B comes with the correct docker flags to tell Traefik that it’s providing a service and requires Traefik to provide routing support.
Make sure B correctly advertise it to Traefik as providing services.We can add the following lines to B’s docker-compose.yml:

- "traefik.enable=true" tells Traefik this is a service.
- "traefik.http.routers.api.rule=Host(`yourdomain.com`)" tells Traefik how to route the incoming requests. In this case, we instruct Traefik to forward all requests with a host value yourdomian.com to B.
Make sure A and B are on the same network.This is the point at which I’m stuck. ๐Ÿ˜•

The Theory

With Traefik running on A, and applications running on B, it seems natural that we need to have an overlay network for Traefik and applications to attach to, such that they can talk to each other.

We can easily create a new network on the swarm manager node (you cannot create a new network on a regular swarm node).

$ docker network create --driver overlay --attachable swarm-net

Here we used the --driver option to specify that we want an overlay network, otherwise it will defaults to a bridged network. And the --attachable option informs Docker that we intend to attach containers to this network. Without the explicit --attachable option, you cannot attach containers. Finally we name the network swarm-net.

Then to make use of the newly created network, we modify the docker-compose.yml files for our services to point network to swarm-net.

All seem good. We created an overlay network, which in theory should allow services on different swarm nodes to talk to each other.

And launching the services indeed went smoothly. But there is only one minor problem: our Traefik instance is not discovering any of the applications on B.

๐Ÿ˜•