Make it possible to run Zammad stateless

[monotek]

When running Zammad in container environments, with single container for railsserver, websocket and scheduler, we need shared storage as tmp dir needs to be written and read by all containers. This is a problem when using Zammad in Kubernetes as only one container can mount a shared directory writeable, if PV is ReadWriteOnce.

As discussed earlier with @martini it would be possible to use memcached to store all tmp files. Rails already supports writing the cache to memcached ( http://guides.rubyonrails.org/v3.2/caching_with_rails.html#activesupport-cache-memcachestore ).

At least the websockets server would need some modification to also use memcached.
Check also if scheduler needs modifications.

With this option one would not need to create shared storage solution like NFS, Ceph, GlusterFS and so on inside Kubernetes and it would be possible to just spin up an additional memcached container, which would be much easier.

Infos:

• Used Zammad version: 2.2
• Used Zammad installation source: deb
• Operating system: ubuntu 16.04
• Browser + version: all

Expected behavior:

• Its possible to use memcached as cache
• Processes do not create extra files, like in:
  • public/assests/images

Actual behavior:

• Zammad uses tmp dir to store temporary files
• its not possible to change that at the moment
• some ner files are created in public/assests/images

Steps to reproduce the behavior:

• run zammad

[mgruner]

Running Zammad in a clustered environment will be much easier with Zammad 5:

• Redis is now supported as web socket session store
• Memcached can now be configured as Rails cache back end

The following areas are also relevant for this topic, but don't require changes at present:

• Zammad caches the logo as an asset in public/. This can happen on every note separately and requires no shared file system.
• The store for uploads and attachments can be configured to use the database to be shared between the nodes. Adding other store options could be a future optimization, but is not required for stateless operation per se.
• Unprocessed / oversized emails are stored in a folder on the node that does this processing. At this point we believe that this is not mission-critical data that needs special treatment.
• The package manager should either not be used (only vanilla Zammad), or alternatively package installations should be performed as part of the deployment process, distributing the same codebase to all nodes.

Therefore we believe Zammad is now "stateless" enough for smooth operation in cluster/swarm environments. 🚀

Please feel free to reopen this issue with more information, in case we have overlooked something.

[monotek]

Thanks! :)

Stuff like upload store was what i had in mind too.

Where are gravatar avatars stored by the way?

Would be cool one could disable the possibility to change the storage option in the frontend, via some rails command in the init step of the container, so the enduser can't change it via the frontend, because he might not even now, that his instance runs clustered at all.

[thorsteneckel]

Where are gravatar avatars stored by the way?

The avatars are handled by the Store backend and therefore are stored in the DB as well ✅

Would be cool one could disable the possibility to change the storage option in the frontend, via some rails command in the init step of the container, so the enduser can't change it via the frontend, because he might not even now, that his instance runs clustered at all.

Unfortunately the storage configuration is hard coded at the moment:

zammad/app/assets/javascripts/app/controllers/_manage/system.coffee

Lines 12 to 13 in fe93104

	if !App.Config.get('system_online_service')
	@tabs.push { name: 'Storage', 'target': 'storage', controller: App.SettingsArea, params: { area: 'System::Storage' } }

I think a dedicated Setting for storing if cluster mode is active or not would be great, like Setting.set('cluster_mode', true). That way we can react to the state in the whole WebApp and API application.

What do you think @mgruner @martini ?

[martini]

I think a dedicated Setting for storing if cluster mode is active or not would be great, like Setting.set('cluster_mode', true). That way we can react to the state in the whole WebApp and API application.

What do you think @mgruner @martini ?

What would be the goal of the setting? Only to not allow to changes certain settings? And what if certain setting are already changed before enable cluster_mode?

IMO we need two things:

1. One method to disable certain settings (incl. identifying what settings this will be in docker env. - I guess storage_provider is only one of more settings).

2. Another magic script which is complaining about wrong used settings.

What do you thing?

IMO it is also another issue.

[mgruner]

@monotek @martini @thorsteneckel new issue created, please let me know if something needs to be improved there.

[lucacri]

Still nothing, right? V6 didn't include anything for this and/or to allow kubernetes to scale stateless, right?

[MrGeneration]

See the state of this in issue
#3656

Please don't bump issues as it won't speed up things.

[mgruner]

@lucacri Zammad 6 does have some improvements in this regard, for example a changed location of unprocessable/oversized emails. Also, the docker image no longer uses rsync to transfer the Zammad files to their final directory. Note that zammad-docker-compose was not yet released for 6.0. You can expect more improvements in this direction.