BUG: convert container in provided compose file won't start in swarm mode

[brassy-endomorph]

Describe the bug

When using the provided docker-compose.yml in swarm mode for a prod deployment, the convert container won't start.

[2022-07-29 08:58:50 +0000] [1] [INFO] Unhandled exception in main loop
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/gunicorn/arbiter.py", line 202, in run
    self.manage_workers()
  File "/usr/local/lib/python3.8/dist-packages/gunicorn/arbiter.py", line 551, in manage_workers
    self.spawn_workers()
  File "/usr/local/lib/python3.8/dist-packages/gunicorn/arbiter.py", line 622, in spawn_workers
    self.spawn_worker()
  File "/usr/local/lib/python3.8/dist-packages/gunicorn/arbiter.py", line 569, in spawn_worker
    worker = self.worker_class(self.worker_age, self.pid, self.LISTENERS,
  File "/usr/local/lib/python3.8/dist-packages/gunicorn/workers/base.py", line 64, in __init__
    self.tmp = WorkerTmp(cfg)
  File "/usr/local/lib/python3.8/dist-packages/gunicorn/workers/workertmp.py", line 23, in __init__
    fd, name = tempfile.mkstemp(prefix="wgunicorn-", dir=fdir)
  File "/usr/lib/python3.8/tempfile.py", line 463, in mkstemp
    prefix, suffix, dir, output_type = _sanitize_params(prefix, suffix, dir)
  File "/usr/lib/python3.8/tempfile.py", line 256, in _sanitize_params
    dir = gettempdir()
  File "/usr/lib/python3.8/tempfile.py", line 425, in gettempdir
    tempdir = _get_default_tempdir()
  File "/usr/lib/python3.8/tempfile.py", line 357, in _get_default_tempdir
    raise FileNotFoundError(_errno.ENOENT,
FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/convert']

To Reproduce

Run the default compose file in swarm mode.

Expected behavior

The app starts.

Actual behavior

It does not.

[brassy-endomorph]

This is caused by read_only: true in the configuration and that tmpfs is ignored when a compose file is used as a stack. If read only is desired, it should be done with a volume and not the current configuration.

[Rosencrantz]

@sunu FYI

[stchris]

Hello @brassy-endomorph and thanks for reporting this. Unfortunately deployments to Docker Swarm are not directly supported by us, so I can't consider this a bug at the moment. To me it seems like the issue is that the tmpfs directive is ignored by Docker Swarm deployments and mounting a volume for the /tmp folder might fix this. Since you are deploying to a Docker Swarm might I suggest keeping a docker-compose override file and including that in your deployments? That way you can override this issue (and potentially make other changes to accomodate your deployment).

[brassy-endomorph]

We aren't even using the Compose file to deploy because it's not suitable for a prod deployment. The sheer memory need for the services means we have to have a cluster which means we do need Swarm to even deploy using Docker at all. The amount of overrides needed to make the compose file work make it pointless to even use the compose file at all. We're just looking at the compose file and Helm charts and using that to make our own stack files.

We're also running on bare metal because cops stole our last server, and setting up k8s from scratch is a massive effort whereas installing Swarm is literally just swarm init and swarm join.

I think it is a mistake to support only k8s and Compose but not Swarm.

[stchris]

I think it is a mistake to support only k8s and Compose but not Swarm.

Noted and I agree that diversifying deployment option would help the community. However we have to work with the resources we have and unfortunately that means cutting corners sometimes. Happy to keep the discussion open if you want to contribute Docker Swarm support.

[brassy-endomorph]

If y'all want it, I can paste my complete swarm set up as an example of "bare metal behind cloudflare' or whatever, but it obviously would need tinkering for someone else to use it on their own.

[Rosencrantz]

@brassy-endomorph That'd be a great start. If you're comfortable doing it we'd really appreciate it. Maybe you could put the info into a PR. The contrib folder feels like a good place to put this, then we can update the documentation to reference it. Thoughts?