Znuny in containers (experience?)

[finalbeta2]

We are currently moving to containerize part of our environment.
I see no official images exist and soms post of OTRS and older Znuny containers exist.

Anyone knows what the current state of Zuny in docker is please?
Someone has relevant repositories/info to share?

[hkais]

We are using and migrating our old setups to docker containers.
Maybe I require to ask our org to publish the approach, how we use the docker to setup znuny. Where are some pitfalls, you need to consider.

My last state from Znuny itself was, they are not interested in containers. (about 12-18months ago)

[finalbeta2]

Thanks for your response hkais.

That's clear.

I do fear to take on containerizing OTRS myself because of those pitfalls (and that we have limited experience with it at the moment).
I understand you cannot post anything your company spend resources on without approval.

If you where able to post on the approach or pitfalls, I would (and I'm sure the community here would ) appreciate it.

[bschmalhofer]

I dabbled in containerizing an OTRS clone some years ago. One obstacle was that there is no clear separation between the software and the runtime data. I ended up with keeping the sources in an install directory of the container. Then there is a directory in /opt which is mounted into the container. The code from the install directory is then copied into the opt directory. During the runtime the mounted directory can then be modified by e.g. installing packages.

[root]

My last state from Znuny itself was, they are not interested in containers. (about 12-18months ago)

Hi,

The existing approaches do not fulfill our requirements, based on the use-cases we handle. TBH, for a experienced teams is does not matter if Znuny runs as a classic application or from a container.

- Roy

[finalbeta2]

Thank you for your input Roy,

In itself, we have no issue managing OTRS inside a VM.

However, it does matter to us from the infra side of things.
Getting everything to work in a similar way has effect on all sorts of things. Security, tooling, backup and recovery etc, procedures.

One of the reasons we are doing this is to have "better" configuration management. Moving away from clickops to devops.

Without trying to start a discussion, it would be interesting to know about "The existing approaches do not fulfill our requirements, based on the use-cases we handle".
As those reasons might also be of interest to us.
What is the reason (if you can share) why containers are not a valid way to distribute OTRS?

[root]

What is the reason (if you can share) why containers are not a valid way to distribute OTRS?

Hi,

We require that the most common customization methods be available. This includes installing and upgrading add-ons, using SAML SSO, and performing patch-level updates. Also, the necessary debugging methods often fail or must be adopted. And there is the support we need to provide enterprise customers from the moment we provide a container.

Besides this, right now we're checking one pull request that looks promising.

- Roy

[bschmalhofer]

These issues do not look like big hurdles. Rebuilding containers is not a big thing. Deriving Containers, with additional packages installed, can easily be done from existing containers.

[finalbeta2]

This is the pull referenced by Roy https://github.com/znuny/Znuny/pull/680

The issues mentioned don't seem big hurdles indeed.
Obviously, once you need to provide support, I understand you need to have your internal procedures/knowledge/people set for containers.