Memcached or Redis in docker compose

[rehanone]

In the docker compose example, there is a mention of both memcached and redis but the example compose file none of them in as services. My question is which one can be used and is there an example compose file that shows how? Would really appreciate if someone could share how they use these cache services.

[rehanone]

Here is what I ended up setting which appears to be working but I am not sure if redis is being used:

compose.yaml

---
version: '3.8'

networks:
  inner-net:
    driver: bridge
  backplain:
    external: true

services:
  redis:
    image: redis:alpine
    container_name: '2fauth-redis'
    networks:
      - inner-net
    environment:
      TZ: Etc/UTC
    volumes:
      - type: bind
        source: /docker-data/2fauth/redis
        target: /data
        read_only: false
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      interval: 1s
      timeout: 3s
      retries: 10
      start_period: 2s
    restart: 'unless-stopped'

  app:
    image: 2fauth/2fauth:latest
    container_name: '2fauth-app'
    networks:
      - inner-net
      - backplain
    volumes:
      - type: bind
        source: /docker-data/2fauth/app-data
        target: /2fauth
        read_only: false
    env_file:
      - ./2fauth.env
    depends_on:
      redis:
        condition: service_healthy
    restart: 'unless-stopped'

---

2fauth.env

# You can change the name of the app

APP_NAME=2FAuth


# You can leave this on "local". If you change it to production most console commands will ask for extra confirmation.
# Never set it to "testing".

APP_ENV=local


# Set to true if you want to see debug information in error screens.

APP_DEBUG=false


# This should be your email address

[email protected]


# The encryption key for your database and sessions. Keep this very secure.
# If you generate a new one all existing data must be considered LOST.
# Change it to a string of exactly 32 chars or use command `php artisan key:generate` to generate it
# Key can be generated at https://generate-random.org/laravel-key-generator

APP_KEY=base64:aWhpbXpwbjA3NmZtcnBveTBscGFpcXh5N2ZxcWVuYTI=


# This variable must match your installation's external address but keep in mind that
# it's only used on the command line as a fallback value.

APP_URL=https://2fa.example.com


# Turn this to true if you want your app to react like a demo.
# The Demo mode reset the app content every hours and set a generic demo user.

IS_DEMO_APP=false


# The log channel defines where your log entries go to.
# 'daily' is the default logging mode giving you 7 daily rotated log files in /storage/logs/.
# Several other options exist. You can use 'single' for one big fat error log (not recommended).
# Also available are 'syslog', 'errorlog' and 'stdout' which will log to the system itself.

LOG_CHANNEL=daily


# Log level. You can set this from least severe to most severe:
# debug, info, notice, warning, error, critical, alert, emergency
# If you set it to debug your logs will grow large, and fast. If you set it to emergency probably
# nothing will get logged, ever.

LOG_LEVEL=notice


# If you're looking for performance improvements, you could install memcached.

CACHE_DRIVER=file
SESSION_DRIVER=file
FILESYSTEM_DRIVER=local


#### Database config & credentials ####

DB_CONNECTION=sqlite
DB_DATABASE="/2fauth/database.sqlite"

# or if you want to use SQL (uncomment lines)

# DB_CONNECTION=mysql
# DB_HOST=127.0.0.1
# DB_PORT=3306
# DB_DATABASE=homestead
# DB_USERNAME=homestead
# DB_PASSWORD=secret


#### Mail settings ####

# Refer your email provider documentation to configure your mail settings
# Set a value for every available setting to avoid issue

MAIL_DRIVER=log
MAIL_HOST=smtp.mailtrap.io
MAIL_PORT=2525
[email protected]
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null
MAIL_FROM_NAME=null
MAIL_FROM_ADDRESS=null


#### Authentication settings ####

# The default authentication guard
#
# Supported:
#   'web-guard' : The Laravel built-in auth system (default if nulled)
#   'reverse-proxy-guard' : When 2FAuth is deployed behind a reverse-proxy that handle authentication
#
# WARNING
# When using 'reverse-proxy-guard' 2FAuth only look for the dedicated headers and skip all other built-in
# authentication checks. That means your proxy is fully responsible of the authentication process, 2FAuth will
# trust him as long as headers are presents.

AUTHENTICATION_GUARD=web-guard

# Name of the HTTP headers sent by the reverse proxy that identifies the authenticated user at proxy level.
# Check your proxy documentation to find out how these headers are named (i.e 'REMOTE_USER', 'REMOTE_EMAIL', etc...)
# (only relevant when AUTHENTICATION_GUARD is set to 'reverse-proxy-guard')

AUTH_PROXY_HEADER_FOR_USER=Remote-User
AUTH_PROXY_HEADER_FOR_EMAIL=Remote-Email

# Custom logout URL to open when using an auth proxy.

PROXY_LOGOUT_URL=null

#### WebAuthn settings ####

# Relying Party name, aka the name of the application.
# If blank, defaults to APP_NAME. Do not set to null.

WEBAUTHN_NAME=2FAuth

# Relying Party ID. If null, the device will fill it internally.
# See https://webauthn-doc.spomky-labs.com/pre-requisites/the-relying-party#how-to-determine-the-relying-party-id

WEBAUTHN_ID=null

# Optional image data in BASE64 (128 bytes maximum) or an image url
# See https://webauthn-doc.spomky-labs.com/pre-requisites/the-relying-party#relying-party-icon

WEBAUTHN_ICON=null

# Use this setting to control how user verification behave during the
# WebAuthn authentication flow.
#
# Most authenticators and smartphones will ask the user to actively verify
# themselves for log in. For example, through a touch plus pin code,
# password entry, or biometric recognition (e.g., presenting a fingerprint).
# The intent is to distinguish one user from any other.
#
# Supported:
#   'required': Will ALWAYS ask for user verification
#   'preferred' (default) : Will ask for user verification IF POSSIBLE
#   'discouraged' : Will NOT ask for user verification (for example, to minimize disruption to the user interaction flow)

WEBAUTHN_USER_VERIFICATION=preferred

# Use this setting to declare trusted proxied.
# Supported:
#   '*': to trust any proxy
#   A comma separated IP list: The list of proxies IP to trust

TRUSTED_PROXIES="10.0.0.0/8,172.16.0.0/12,192.168.0.0/18"

# Leave the following configuration vars as is.
# Unless you like to tinker and know what you're doing.

BROADCAST_DRIVER=log
QUEUE_DRIVER=sync

REDIS_HOST=redis
REDIS_PASSWORD=null
REDIS_PORT=6379

PUSHER_APP_ID=
PUSHER_APP_KEY=
PUSHER_APP_SECRET=
PUSHER_APP_CLUSTER=mt1

MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"

MIX_ENV=local

I did not find any documentation on how to use memcached as well. I am guessing that redis and memcached are used for same purpose in this case.

[SimonWoidig]

I'd love to know about this aswell. I saw the redis config but I don't have redis running in a pod (running on Kubernetes, same deal).

[stepanov1975]

I would like to see an example with Redis as well.