#31834: Make obfs4 Docker image more usable -------------------------------+------------------------------- Reporter: phw | Owner: phw Type: defect | Status: needs_review Priority: Medium | Milestone: Component: Circumvention | Version: Severity: Normal | Resolution: Keywords: docker, s30-o24a2 | Actual Points: 1.1 Parent ID: #31281 | Points: 1 Reviewer: cohosh | Sponsor: Sponsor30-can -------------------------------+-------------------------------
Comment (by thymbahutymba): Replying to [comment:15 phw]: > Here's a patch that derives docker's volume name from the two given ports, making it possible to deploy more than one container on a machine: > https://dip.torproject.org/torproject/anti-censorship/docker- obfs4-bridge/compare/master...fix%2F31834 > > I know that thymbahutymba is no fan of this but I find it intuitive that each call to `make deploy` results in a new container being deployed. As for the volume names: I believe that thymbahutymba prefers the volume name to contain the bridge name instead of the ports. I'm fine with this too but I find it a little awkward because we'd be introducing a new constraint (unique bridge names) which don't exist in Tor. Actually my point is not about bridge name but how to identify in a smart way the name of the container and the volume connected with. I thought that having external config file can solve this (and others) problem. In this case the user can keep the configuration file separated by the Makefile, moreover if the user need to re-deploy the container, due to image update or whatever else, this make the process quite easy and faster than run deploy multiple time, which requires to have in mind which are the ports associated to that. After saying that just consider something like what follows. {{{ # env BRIDGE_NAME=DockerObfs4 BRIDGE_LIST=${BRIDGE_NAME}-{1..2} ${BRIDGE_NAME}-1-OR_PORT=993 ${BRIDGE_NAME}-1-PT_PORT=143 ${BRIDGE_NAME}-2-OR_PORT=443 ${BRIDGE_NAME}-2-PT_PORT=25 # Makefile include env deploy: $(shell echo ${BRIDGE_LIST}) ${BRIDGE_NAME}-%: @echo ${BRIDGE_LIST} @[ ${$@-OR_PORT} ] || ( echo "Env var OR_PORT for $@ is not set."; exit 1 ) @[ ${$@-PT_PORT} ] || ( echo "Env var PT_PORT for $@ is not set."; exit 1 ) @docker run \ .... \ --volume $@:/var/lib/tor \ .... }}} Just to summarize what I think are the advantages of that: * Is not required to remember the configuration each time; * Easy to identify at which container is associate one volume; * No need to run multiple times {{{make deploy <SOMETHING>}}} for each instance that we would run that's means speedup on deployment phase. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31834#comment:16> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs