ARM64 Support

[vansari]

Hi @leepeuker

I have forked your repository because I find your Idea and the code very interesting even if I have no usage for this app at the moment.

As I tried to run your docker config I ran in an error because I work with an Apple M2 MacBook and the webdevops team did not have any images which were build for arm.

Is it possible that you change to a more common config which supports amd and arm?

[leepeuker]

Hey @vansari, thank you for bringing this to my attention. I used the webdevops base image in the beginning for a quick starting setup to focus on the app itself, my long term plan was to replace it with a more tailor made (and smaller) alpine/fpm/nginx image. I was not aware of the missing ARM support and will prioritize this more 👍

[vansari]

Hi @leepeuker

thanks. I will try to minimize the Images and split the Services to web and php container (SoC).

If it works as expected I will open a PR for you.

Nice work at this time!

[leepeuker]

Thank you for the nice words and support, looking forward to the possible PR.

I did break with the rule "one container one process" on purpose. I wanted php and nginx combined in one container to make the deployment easier (getting the app to run with with just one simple docker run command). The advantages of splitting these processes into separate containers did not seem so relevant to me with this in mind. What is your opinion on this?

[vansari]

Hi @leepeuker

In my opinion it is better to maintain if you have a separate container for each service. Also the user have the possibility to change the web server Container without to touch the php container and the other way around.

[leepeuker]

I agree with you completely from a developers perspective, but it seems unnecessary complicated for the user to me. If the user wants more control of the web server, the container can be served behind a reverse proxy. To just have to run one container which can serve the app directly is much more convenient for most people I think, vs having to rely on an additional webserver container to handle the fpm connections. As far as I see this is a common approach if you look at bigger self-hosted php projects like nextcloud (default docker image contains apache) or linuxserver.io images like bookstack (all images contain a webserver).

I like how nextcloud provides both possibilities, I think we could try that too. Offering a fpm base image (tagged fpm) which we extend to create another one with nginx (which would be the default image and set to latest).

[leepeuker]

Created dedicated ticket for the docker rework https://github.com/leepeuker/movary/issues/206