Skip to main content

Traefik Docker Swarm Demo

In a previous post I demonstrated a proper installation of traefik with docker. Now I want to expand that demo with docker swarm. Docker Swarm has a similar ingress function to kubernetes and so that makes deployment and high availability easier. Kubernetes is a standard, however, docker swarm is very simple to operate. You are still on your own for the nitty gritty.

Bring the traefik container down:

# docker-compose down

I'm taking the previous example and expanding it to deploy a docker swarm and so the first thing to do is deploy single node swarm. In my case I deployed the VMs on digital ocean and did not deploy a private network and there is no point in setting up a non-encrypted virtual network in public space.)

$ export manager=myhost
$ docker-machine ssh ${manager} "docker swarm init \
    --listen-addr $(docker-machine ip ${manager}) \
    --advertise-addr $(docker-machine ip ${manager})"

WARNING WARNING -- while this example is simple and demonstrates a docker-machine version of the docker swarm command the listen-addr and advertise-addr parameters are seriously dangerous because in this use-case they are public and not private IP addresses.

I previously indicated that this installation was going to be on top of the plain version and that was essentially wrong. Plain docker and docker swarm may be compatible but there are differences. For example in the plain version I created a network:

# docker network create --driver=overlay web

When I tried to create a docker stack (swarm instance) I got an error that the network was a local and not a swam. So I had to delete the network and recreate it as the scope was different. Since the current running apps were running I had to stop them too.

# docker-compose down
# docker network rm web
# docker network create --driver=overlay web --attachable

UPDATE: I thought redeploying the network was a thing until I realized when the network is created after already in swarm mode then it's ok without the scope option.

UPDATE: However while debugging I determined that I needed the attachable parameter.

In the traefik.toml file I commented this line and added these two in the docker section:

endpoint = "tcp://"       
swarmMode = true                         
#endpoint = "unix:///var/run/docker.sock"

Although I commented out the 'sock' volume I'm not sure whether or not it's in use so I probably will not remove that from the docker-compose.yml file. A few other changes were required so here is the file:

version: '3'

    image: traefik
    command: --api --docker --docker.swarmMode
      - 80:80
      - 443:443
      #- 8080:8080
      - web
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/traefik/traefik.toml:/traefik.toml
      - /opt/traefik/acme.json:/acme.json
        - ""
        - "traefik.port=8080"
        - ""

    external: true

Then start traefik as a stack:

docker stack deploy -c /opt/traefik/docker-compose.yml traefik

Here is the docker compose of one of my basic services ("hello"):

version: "3.4"

    image: myregistry/transient/hello-web:latest
      - web
      - default
        - ""
        - "traefik.enable=true"
        - ""
        - "traefik.basic.port=80"
        - "traefik.basic.protocol=http"

    external: true

I had to make some changes...

  • change the version
  • remove the expose
  • remove the container name
  • remove restart always
My hello container is in my private registry so I needed to login first then start the stack:

docker stack deploy \
     --with-registry-auth \
     -c /root/hello/docker-compose.yml hello


So there was a lot of learning going on here and here are the key takeaways. There are few differences between the raw docker and docker swarm. The configs are pretty simple. A reasonably deployed swarm give you some options for scaling some services even though not demonstrated here. Adding a stack does not require taking down the system. And you get the benefir of let's encrypt without interruptions except for rate limits. And the goodness continues.


Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).


I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…