Docker/memcached is not referenced by anything in docker-compose.yml

Seafile Server
,
#1

In official docker-compose file, there are 3 services. MariaDB, Seafile and memcached. MariaDB is set up with name of “db” and is later referenced as DB HOST in Seafile block. But memcached is not referenced in docker-compose by neither of the two other services. How is memcached wired up to seafile or database?

#2

Via the config files in the seafile container.

#3

Can you please point me to it? I can’t find it.

#4

Check seahub_settings.py

The path to the file depends on the volume specification of the seafile container. The default path is - I think - /opt/seafile-data/seafile/conf

#5

FWIW - within a docker-compose setup, whatever the container name is - you can use that name to reference from between containers. So as rdb pointed the configs - the name in the config has to match the container name in the docker-compose. If there’s no container name, then there’s a convention for docker. I don’t like the convention; so I have all my container named explicitly…

1 Like
#6

Thanks for the replies. I checked the seahub_settings.py, this is what’s in it:

CACHES = {
‘default’: {
‘BACKEND’: ‘django_pylibmc.memcached.PyLibMCCache’,
‘LOCATION’: ‘memcached:11211’,
},
‘locmem’: {
‘BACKEND’: ‘django.core.cache.backends.locmem.LocMemCache’,
},
}

I see here that the cache instances is identified as “memcached:11211”. However, my docker-compose.yml looks like this:

memcached:
image: memcached:1.6
container_name: seafile-redacted-net-memcached
hostname: seafile-redacted-net-memcached
entrypoint: memcached -m 256
networks:
- pra1-nginx

I belive, I should change the LOCATION value in seahub_settings.py to the HOSTNAME value in docker-compose.yml and that should be the correct way to do it.

I am surprised there are no complaints in the log that the instance for caching hasn’t been found.

#7

Service name is an alias to the container (kind of), no alias is ever hidden by another. See:

docker-compose-yml

services:
  client:
    image: ensignprojects/ubuntu-dnsutils
    command: ["tail", "-f", "/dev/null"]
    deploy:
      mode: replicated
      replicas: 2
    networks:
      - domain
  server:
    image: ensignprojects/ubuntu-dnsutils
    container_name: server_container
    hostname: server_hostname
    command: ["tail", "-f", "/dev/null"]
    networks:
      domain:
        aliases:
          - backend
      data:
        aliases:
          - app
  db:
    image: ensignprojects/ubuntu-dnsutils
    # This won't work
    # container_name: server_container
    command: ["tail", "-f", "/dev/null"]
    networks:
      data:
        aliases:
          # Whoops, those are used somewhere else
          - server_container
          - server_hostname

networks:
  domain:
  data:

Everything you would expect just works fine:

$ docker compose exec client bash -c "host server && host server_container && host server_hostname && host backend && host app; host db"
server has address 172.31.0.2
server_container has address 172.31.0.2
server_hostname has address 172.31.0.2
backend has address 172.31.0.2
# host app - Expected since client does not belong to network data
;; connection timed out; no servers could be reached
# host db - Expected since client does not belong to any common network with db service
;; connection timed out; no servers could be reached

Note that even though a container name is unique, its alias on a network can easily be reused (as all others). See:

$ docker compose exec server bash -c "host client && host server_container && host server_hostname"
client has address 172.31.0.4
client has address 172.31.0.3
server_container has address 192.168.0.3
server_container has address 192.168.0.2
server_hostname has address 192.168.0.2
server_hostname has address 192.168.0.3

Everything resolves to two addresses in a random order because there are two containers by hostname. It’s now a total mess which won’t work as you expect but docker won’t complain in any way, so just be aware of it and deal with it. :slight_smile: