first implementation of improved docker

[ChristianSchindler]

Based on: #6303

Improve Docker Image:

1. Run invoke update Automatically on image updates
2. Combine Server and Worker 1 container

[netlify]

✅ Deploy Preview for inventree-web-pui-preview ready!

Name	Link
🔨 Latest commit	e4d2e2f
🔍 Latest deploy log	https://app.netlify.com/sites/inventree-web-pui-preview/deploys/65e64f1db27adb000811f083
😎 Deploy Preview	https://deploy-preview-6305--inventree-web-pui-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 (no change from production) Accessibility: 86 (no change from production) Best Practices: 92 (no change from production) SEO: 70 (no change from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[matmair]

Looks intresting @ChristianSchindler - could you expand the description of the PR a bit more?
Seems like a notable shift in the deployment strategy that would need concesus within @inventree/triage @inventree/maintainer and docs updates + release notes.

[SchrodingersGat]

I have some concerns that this goes against docker best practice

Process Reliability

If one of the processes (web worker, background worker) fails - this may be obscured by this update. The docker container generally manages process state, and allows auto-restart of the process due to an error

Logging

Again, running a background process in the docker container may obscure logs - which are crucial for debugging InvenTree performance.

Scalability

While "simplifying" the docker container setup, this reduces the flexibility of the setup.

---

I'd like to hear your thoughts on the potential advantages. Maybe I am missing something here, but the docker compose file takes care of all of this abstraction anyway...

[ChristianSchindler]

@SchrodingersGat

Process Reliability

If one of the processes (web worker, background worker) fails - this may be obscured by this update. The docker container generally manages process state, and allows auto-restart of the process due to an error

If I can do it so that if one fails, the complete container restarts, is this ok?

Logging

Again, running a background process in the docker container may obscure logs - which are crucial for debugging InvenTree performance.

I know that's why I made it so that both still print out and also add in front Sever or Worker to identify where the problem lays

Scalability

While "simplifying" the docker container setup, this reduces the flexibility of the setup.

If you want to scale, this is still entirely possible. Then you can use it without the script similar to it is now, but most will not need it, and that's a way for it to be as easy as possible.

[ChristianSchindler]

@matmair

Looks intresting @ChristianSchindler - could you expand the description of the PR a bit more?
Seems like a notable shift in the deployment strategy that would need concesus within @inventree/triage @inventree/maintainer and docs updates + release notes.

In gennerla ther are two changes:

1. Automatic updates if there is a new db version or on the first install
2. In general, you can remove the worker, and then it is entirely the same as before.

[matmair]

Please ammend your explaination to the PR description to make it easier to find

[matmair]

@ChristianSchindler We will not merge this with a combined worker and server container in the compose due to the resons listed by @SchrodingersGat above.
If you are open to revert that change we are willing to review and merge the auto-update, which seems valueable.

[ChristianSchindler]

@ChristianSchindler We will not merge this with a combined worker and server container in the compose due to the resons listed by @SchrodingersGat above. If you are open to revert that change we are willing to review and merge the auto-update, which seems valueable.

Sorry had no time will look at it next week