記錄DCOS中SSL證書的配置和除錯過程
阿新 • • 發佈:2018-12-19
mesosphere
已經基本搭建完成,安裝了marathon-lb
做請求分發,最後需要將所有的請求轉為https
處理。由於不準備做全域性的證書,所以只能針對每個應用單獨進行證書配置。
- 起初沒在意
marathon-lb
,認為他只是簡單的請求分發,SSL
跟他無關,就在 應用的nginx
中配置了80
和443
兩種訪問方式,注意有個誤打誤撞的操作:在完整配置SSL
的情況下,比如listen 443 ssl;
或者ssl on;
的情況下會導致400
錯誤:“The plain HTTP request was sent to HTTPS port”
。修改方法:遮蔽ssl on
,另外只要寫listen 443
就好了,不需要完整配置。這樣配置之後發現通過瀏覽器訪問時一直說連線不安全。。
- 在理清整個請求的處理流程後越發覺得證書應該是在
lb
的HAProxy
中進行配置,所以在此進行嘗試,但是無果。。具體做法是在marathon-lb
中添加了volume
對映試著將證書放進去,想辦法讓證書生效。反覆修改了marathon-lb
中的HAPROXY_SSL_CERT
引數,但是無論是指定路徑,或是按照網上說的用sed
輸出檔案內容之類的,都不行。。
- 在網上找了完整的單獨的
HAProxy
配置之後對HAProxy
有了一個初步的概念(雖然多年以前將LVS
,HAProxy
和Nginx
摸得爛熟,但是多年不用還是忘記了)。
- 同時發現一個奇怪的現象:在
marathon-lb
啟動之後,有的時候/marathon-lb/haproxy.cfg
是存在的,有的時候又不存在。多嘗試幾次並結合marathon-lb
的日誌發現這裡存在這樣一種機制:marathon
裡的應用在啟動(或更新重啟)之後,marathon-lb
會自動檢測應用的新配置,並與老配置進行對比,如果有變化就會更新/marathon-lb/haproxy.cfg
並重啟。當應用中有錯誤的配置時候,就無法生成/marathon-lb/haproxy.cfg
。比如我一開始設定label
中的HAPROXY_0_MODE
為https
(一開始是http
,我以為修改成https
就會從443
埠走了),日誌中就報錯,說https
這個模式是錯誤的。查詢官方文件後發現http
這個模式可以處理http
和https
的請求,那麼問題還不在這裡。同時發現另一個問題,我在label
中配置了"HAPROXY_0_SSL_CERT": "/data/nginx/certs/214997784440115.pem"
,但是marathon-lb
說這個檔案不存在,心裡咯噔一下,有戲。。檔案不存在那讓它存在就好了。之前已經在marathon-lb
中配置了volume
的對映,將幾個證書的檔案對映到了marathon-lb
的內部(我使用了相同的路徑名稱),檢查後發現早上在測試時候我將21xxx.pem
命名為了cert.pem
(HAProxy
預設會去找/etc/ssl/cert.pem
,我將pem
改了檔名並拷貝了過去),於是乎將pem
檔名字改回來,重啟marathon-lb
發現檔案是找到了,但是有新的報錯,如下:
- 可以看到說是
priveate key
找不到,但是我記得這是在key
檔案裡頭的,於是又在應用的HAPROXY_0_SSL_CERT
中將檔案改為21xxx.key
,這下又有了新的報錯:
- 這下說明他丫的公私兩個檔案都要,那麼整個證書的配置確實是在這邊處理就好了,想辦法把兩個檔案都配置進去,寫成了
“21xxx.pem,21xxx.key”
,但是這個格式還是有點問題:
- 沒辦法,只能放大招。。將
key
檔案裡頭的東西拷貝貼上到pem
檔案後頭,啟動成功!
- 到這裡為止,
HAProxy
的證書算是配置完成了,但是發現還是有點問題,生成的haproxy.cfg
中一直監聽10101
埠,檢查應用的配置後發現portDefinitions
段中ports
埠設定成了10101
,於是將它改為0
,重啟後訪問還是有問題。。
- 回想到
haproxy.cfg
中的listen
欄位,再細想一下瀏覽器的請求,瀏覽器的https
協議預設的是443
埠,那麼只要HAProxy
沒有指定443
埠,證書就依舊無法生效。所以將ports
改為443
,重啟後發現一切OK了。。
- 接下來還可以做一個測試,將應用的
Nginx
修改為只監聽80
的普通http
,然後應用對外對映80
埠,我估計這樣也是可行的(還未測試)。。