Added support to run dnsproxy server/client in docker

[coolquasar]

I have created a docker image to run dnsproxy as server or client as required. I thought of sharing with rest of the community. Thankyou!

[codecov-io]

Codecov Report

Merging #110 (cb38dbe) into master (2f7a50c) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #110   +/-   ##
=======================================
  Coverage   66.04%   66.04%           
=======================================
  Files          37       37           
  Lines        2194     2194           
=======================================
  Hits         1449     1449           
  Misses        543      543           
  Partials      202      202           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 2f7a50c...69e6046. Read the comment docs.

[ameshkov]

@coolquasar since we have not yet decided on what exact Docker image for dnsproxy, would you consider creating a separate repo for this? We could link it from dnsproxy README then.

[awrcdhj]

我创建了一个docker映像，运行dnsproxy作为服务器或客户端。我想分享其他人。谢谢！

[awrcdhj]

#的重复 #的重复

[ameshkov]

@awrcdhj 那个映像，你在Docker Hub出版了吗？我们能在这儿的 README 提到。

[yknx4]

Alpine is a terrible base image for DNS servers. It has issues with TCP resolvers as described here. Pretty much musl implementation of DNS is incomplete.

Also it seems it is broken on purpose

[priceaj]

Alpine is a terrible base image for DNS servers. It has issues with TCP resolvers as described here. Pretty much musl implementation of DNS is incomplete.

Also it seems it is broken on purpose

Any suggestions on what to use instead?

[pataquets]

On a cursory review, this image is too much opinionated about how to run/deploy dnsproxy, IMO. Using supervisord generally is a red flag about the image perhaps having too much responsability, if not a bad practice (ie. >1 service/process running in a container). I would go with a simpler image containing just the binary, and let everyone use it as they see fit (supervisord can be later added in a derived image). Using as client or server should be left as a decision at deploy time. Maybe providing different Docker Compose manifests for each scenario as deployment examples would do. Also, git pull'ing the code instead of copying it from the local checkout would disable the "local hack/build/run" development workflow, which is also an antipattern in Docker usage. Also, if publishing an official public Docker image later is desired, this would hamper it.