The provided Docker-compose and helper script do not work on a Windows machine

[Zicchio]

The provided docker-compose https://github.com/italia/Satosa-Saml2Spid/blob/master/Docker-compose/docker-compose.yml and the helper script https://github.com/italia/Satosa-Saml2Spid/blob/master/Docker-compose/run-docker-compose.sh currently do not work on a Windows machine. The problem is twofold. In the docker-compose.yml, this docker volume instruction references a location that might not exists on the local machine (and indeed never exists by default on a Windows mahcine) https://github.com/italia/Satosa-Saml2Spid/blob/90f8f66f390700bb77c1a40c466993ace8f9da77/Docker-compose/docker-compose.yml#L13 Second, the helper script copies data on a volume by copying to a docker mountpoint location which might be virtual on a windows machine https://github.com/italia/Satosa-Saml2Spid/blob/90f8f66f390700bb77c1a40c466993ace8f9da77/Docker-compose/run-docker-compose.sh#L12

While this is not an issue per se, in my opinion the documentation should ad least state somewhere that the given tolling is intended to be used on an Ubuntu or similar OS.

[MdreW]

Hi @Zicchio , we can remove the localtime mount in docker-compose.yml because this work is executed in the docker build, dockerfile line 21-25

RUN apk update
RUN apk add --update --no-cache tzdata
RUN cp /usr/share/zoneinfo/Europe/Rome /etc/localtime
RUN echo "Europe/Rome" > /etc/timezone
RUN apk del tzdata

@peppelinux , if we don't remove the tzdata package, we can set the timezone with TZ environment, is an "alpine" feature

...but also is so bad UTC? :exploding_head:

[MdreW]

A question, are static volumes still necessary? I know, for a remote orchestrated container is a necessary choice, but in this case run-docker-compose.sh script is not useful. Otherwise in a local container istance, have a static mount or a local mount is not different.

If manage the static mount is a problemi with WSL, if we should maintain a mixed mount system (some local and some static), we could turn back with the local mount. We can create the requested directory in Docker-compose path (mongodata for the db, satosa for satosa container file and django_sp for django_sp container file)

At this point the script become a simple utility that copy the example file from the repository directory to the container volume path.

All mount are management with same mode, more simplicity for developers and admins. I'm a old poor person and like the simply life :older_man: What do you think?

If is useful I can make a example pull request, It wouldn't take me long.

[MdreW]

I have written a simple example in #152 , this fix local time question and should fix the static volume problem. Is only a simple sample with no deep test

[Zicchio]

Otherwise in a local container istance, have a static mount or a local mount is not different. […] At this point the script become a simple utility that copy the example file from the repository directory to the container volume path.

All mount are management with same mode, more simplicity for developers and admins […] What do you think?

I am not an authority on Docker (not even close...) but I like this approach.

I wonder if the prievious approach was designed to simplify the development/rewirite of a production ready docker compose file. In the previous approach, the docker compose file assumed that the nginx secrets and mongo volume already (somehow) exists and this allowed to decouple and isolate:

• the nginx secrets in a location with proper security boundary
• the mongodb volume in an I/O focued storage area.

But again this is just a guess. For my use case either approach is valid and your certanly simply some tasks.

[peppelinux]

external volumes are required for high scalable deployments, in particular using docker swarm

I support @MdreW 's PR with the deside to keep commented the previous approaches about using external volumes to hint to the deployers that already tested strategy

[MdreW]

external volumes are required for high scalable deployments, in particular using docker swarm

I support @MdreW 's PR with the deside to keep commented the previous approaches about using external volumes to hint to the deployers that already tested strategy

I have added this in b27bbeb35e979d870aaa8f0bb2af0bdf20c6442f

[MdreW]

Hi @Zicchio, have you looked at the merged branch #160? It should fix the reported issues. If everything is ok we close the issue and the pull request.