[英]Running multiple dev projects in docker containers with nginx-proxy
[英]Docker nginx-proxy : proxy between containers
我目前正在我公司使用Docker-Compose運行開發堆棧,為開發人員提供編寫應用程序所需的一切。
它特別包括:
為了通過HTTPS保護服務並將它們暴露給外界,我安裝了優秀的nginx-proxy容器( jwilder / nginx-proxy ),它允許在容器上使用環境變量進行自動nginx代理配置,以及自動HTTP到HTTPS重定向。
DNS配置為將dockerized服務的每個公共URL映射到主機的IP。
最后,使用Docker-Compose,我的docker-compose.yml文件如下所示:
version: '2'
services:
nginx-proxy:
image: jwilder/nginx-proxy
ports:
- "80:80"
- "443:443"
volumes:
- /var/run/docker.sock:/tmp/docker.sock:ro
- /var/config/nginx-proxy/certs:/etc/nginx/certs:ro
postgresql:
# Configuration of postgresql container ...
gitlab:
image: sameersbn/gitlab
ports:
- "10022:22"
volumes:
- /var/data/gitlab:/home/git/data
environment:
# Bunch of environment variables ...
- VIRTUAL_HOST=gitlab.my-domain.com
- VIRTUAL_PORT=80
- CERT_NAME=star.my-domain.com
archiva:
image: ninjaben/archiva-docker
volumes:
- /var/data/archiva:/var/archiva
environment:
- VIRTUAL_HOST=archiva.my-domain.com
- VIRTUAL_PORT=8080
- CERT_NAME=star.my-domain.com
jenkins:
image: jenkins
volumes:
- /var/data/jenkins:/var/jenkins_home
environment:
- VIRTUAL_HOST=jenkins.my-domain.com
- VIRTUAL_PORT=8080
- CERT_NAME=star.my-domain.com
對於開發人員工作站,一切都按預期工作。 可以通過https://gitlab.my-domain.com
: https://repo.my-domain.com
和https://jenkins.my-domain.com
訪問差異服務。
當其中一個dockerized服務訪問另一個dockerized服務時,會發生此問題。 例如,如果我嘗試從jenkins docker訪問https://archiva.my-domain.com
,我將從代理獲得超時錯誤。
似乎即使archiva.my-domain.com
被解析為來自docker容器的公共主機IP, 來自dockerized services的請求也不會被nginx-proxy代理。
據我所知,docker-nginx正在處理來自主機網絡的請求,但不關心來自內部容器網絡的請求(對於Docker-Compose堆棧,_dockerconfig_default_)。
你可以說,為什么我需要使用容器中的代理? 當然,我可以使用來自Jenkins容器的URL http://archiva:8080
,它可以工作。 但是這種配置不具備可擴展性。
例如,使用Gradle構建來編譯一個應用程序,build.gradle需要通過https://archiva.my-domain.com
聲明我的私有存儲庫。 如果從開發人員工作站啟動構建,但不通過jenkins容器啟動,它將起作用...
另一個例子是通過OAuth的GitLab服務,其中相同的URL GitLab認證必須既可以從外部,並且詹金斯容器內部在詹金斯的認證。
我的問題是: 如何配置nginx-proxy來代理從容器到另一個容器的請求?
我沒有看到任何討論這個問題的話題,我對nginx配置構建解決方案的問題不夠了解。
任何幫助將非常感激。
BMitch,賠率很高,這確實是一個iptables規則問題,而不是nginx-proxy的錯誤配置。
表filter
的鏈INPUT的默認策略是DROP
,並且沒有規則來自容器IP(127.20.XX)的ACCEPT
請求。
所以為了記錄,如果其他人面臨同樣的問題,我會提供一些情況的細節。
為了從外部訪問容器,Docker對PREROUTING和FORWARD規則規定了允許外部IP從主機IP到容器IP的DNAT。 這些默認規則允許任何外部IP,這就是為什么限制對容器的訪問需要一些高級iptables自定義。
請參閱此鏈接以獲取示例: http : //rudijs.github.io/2015-07/docker-restricting-container-access-with-iptables/
但是如果你的容器需要訪問主機資源(在主機上運行的服務,或者在我的情況下,一個nginx-proxy容器監聽HTTP / HTTPS主機端口並代理到容器),你需要注意iptables的規則。 INPUT鏈。
實際上,來自容器並發送到主機的請求將由Docker守護程序路由到主機網絡堆棧, 但是然后需要傳遞INPUT鏈(因為請求src
IP是主機端)。 因此,如果您想保護主機資源並讓容器訪問它們,請不要記得添加如下內容:
iptables -A INPUT -s 127.20.X.X/24 -j ACCEPT
127.20.XX / 24是運行容器的虛擬網絡。
非常感謝你的幫助。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.