-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The provided Docker-compose and helper script do not work on a Windows machine #145
Comments
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
@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? 🤯 |
A question, are static volumes still necessary? 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 👴 If is useful I can make a example pull request, It wouldn't take me long. |
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 |
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:
But again this is just a guess. For my use case either approach is valid and your certanly simply some tasks. |
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 |
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.
The text was updated successfully, but these errors were encountered: