Deploying Zammad to container orchestrators (ie Nomad / k8s)

Hi there,

I just did my first deployment of nomad into a container orchestrator and it was a rather bumpy ride :slight_smile: I follow the zammad-docker-compose project to get this set up.

Along the way I ran into a few hurdles and I thought I’d ask if you can supply some background. Currently most containers mount a volume to /opt/zammad. Given that this volume is shared (at least in the compose examples) I cannot easily deploy the individual services over multiple nodes.

This brings me to the main question: Which services actually need /opt/zammad and for what? I can think of the following examples:

  • All containers currently need it for configuration which is written by zammad-init. It would be possible that all containers do this on their own, this way there would be no need to share the config (they all do have the environment variables after all)

  • zammad-nginx needs zammad-init which to get the assets to serve, so far so good

  • I guess zammad-railsserver might store files on the filesystem?

  • Do the scheduler & websocket server need anything besides the config?

In an ideal world I think that a nicer behavior would be to have two volumes (static & uploads or so) that are shared by the containers as needed and every container should apply the environment configuration in it’s own…

What do you think? Would anyone be willing to work with me on this?

checkout; Overview's and notifications not pushed/updated via websocket - #10 by olafbuitelaar

Thank you @olafbuitelaar – that is an unfortunate design decision but probably something I have to deal with.

Out of curiosity, did you get your glusterfs option working in a stable manner? I am asking, because with the defaults that I have on my glusterfs (+ exposed via nfs-ganesha) it seems to complain about flock problem etc. In the end it seems easier to keep those containers inside a pod :confused:

I just wish the rails-server would also serve the static assets, this way I could get rid of nginx at least. (I already have traefik in front which dispatches accordingly). The load on the railsserver would not really increase either, since a client basically requests the assets once per version…

well it seemed to run stable for a while, but right now i’ve some issues but i suspect it has something todo with gluster it self rather than zammad. I’m now trying to make sure the full IO path is direct IO, without any caching for the websocket_production directory. Early tests it seems to work. But i’m still also not 100% sure if it has todo with our recent update’s of zammad, since it seemed to run better before at least this commit;Scheduler dies if Trigger, Ticket or Article of a Webhook job got deleted before job got executed · Issue #3416 · zammad/zammad · GitHub (somewhere before 3.6.0.50). But also glusterfs is a tricky beast, so your results may vary…

I’m not 100% sure, but while traefik doesn’t support serving static files directly, you could bypass the nginx instance for the railsserver and websocket containers, and directly configure them in traefik.
which respectively go to uri: / and /ws.
Only add an exception rule for the files hosted by nginx (consult the nginx config); assets/|robots.txt|humans.txt|favicon.ico|apple-touch-icon.png
and host them in some other way.

just as side note; zammad it self runs stable on gluster. The main issues i have(/had) are with updating state (as said in the reference link), without refreshing the browser. And sometimes with restarting a container, in which case i’ve the clear the tmp/cache* directories.

Ha true that, the docs are also somewhat unhelpful. Also exposing that over NFS (via nfs-ganesha since I need mounts via a kernel driver) does not help.

Yes this is what I am doing already, works well enough.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.