亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

        基于Nginx反向代理解決公網(wǎng)上服務(wù)跨域問題的研究

        2023-06-25 13:46:17崔娟王偉民馮繼虎李懷堂王林柱
        現(xiàn)代信息科技 2023年8期
        關(guān)鍵詞:跨域安全

        崔娟 王偉民 馮繼虎 李懷堂 王林柱

        摘? 要:對軟件開發(fā)人員來說,除了日常在本地的開發(fā)工作之外,最終的目的是要將項(xiàng)目部署到公網(wǎng)上,供用戶使用。但是基于系統(tǒng)安全的考慮,一般不能將內(nèi)網(wǎng)服務(wù)器上所有服務(wù)全部暴露在外網(wǎng)上,這個(gè)時(shí)候選擇通過Nginx的反向代理來解決這個(gè)問題。通過實(shí)現(xiàn)前端后分離部署,修改Nginx配置文件,解決了公網(wǎng)上瀏覽、下載內(nèi)網(wǎng)服務(wù)器上圖片等問題。

        關(guān)鍵詞:安全;Nginx;docker容器化部署;反向代理;跨域

        中圖分類號(hào):TP393? ? 文獻(xiàn)標(biāo)識(shí)碼:A? 文章編號(hào):2096-4706(2023)08-0079-05

        Abstract: For software developers, in addition to daily local development work, the ultimate goal is to deploy the project to the public network for users to use. However, based on the consideration of system security, it is generally not possible to expose all services on the intranet server to the outer internet. At this time, this paper chooses the nginx reverse proxy to solve this problem. By implementing front end separate deployment and modifying nginx configuration files, the problems of browsing and downloading pictures on the intranet server by public network are solved.

        Keywords: security; Nginx; docker container deployment; reverse proxy; cross domain

        0? 引? 言

        軟件開發(fā)采用前后端分離的模式開發(fā),前端使用vue框架。根據(jù)業(yè)務(wù)需要,項(xiàng)目中需要有上傳圖片,顯示圖片的功能。我們選擇將圖片上傳到對象存儲(chǔ)服務(wù)minio上,而minio通過docker安裝在內(nèi)網(wǎng)服務(wù)器上。上傳后的圖片我們通過后臺(tái)接口返回的圖片URL來訪問。而這個(gè)圖片的地址是攜帶了內(nèi)網(wǎng)IP和端口號(hào)的地址,同時(shí)我們也是存儲(chǔ)到數(shù)據(jù)庫中,這樣下次顯示圖片的時(shí)候就直接讀取圖片字段的URL。問題是圖片的URL由內(nèi)網(wǎng)IP+端口號(hào)+其他路徑+圖片名稱組成,那么在公網(wǎng)上是直接訪問不到這個(gè)內(nèi)網(wǎng)的IP或者這個(gè)端口號(hào)的地址的,這個(gè)時(shí)候就會(huì)出現(xiàn)圖片打不開的問題。所以我們的解決思路是:外網(wǎng)要能訪問服務(wù)器上的前端項(xiàng)目,我們必須要將一個(gè)IP地址+端口號(hào)映射在公網(wǎng)上,那么我們可以選擇將前端項(xiàng)目放在一個(gè)服務(wù)器上,后端項(xiàng)目放在另一臺(tái)服務(wù)器上,映射前端服務(wù)器上的IP到公網(wǎng)上,通過配置Nginx訪問后端內(nèi)網(wǎng)服務(wù)器。或者我們將前端項(xiàng)目和后端項(xiàng)目部署在同一個(gè)臺(tái)服務(wù)器的不同端口下。本文按照第二種方式部署,部署到同一臺(tái)服務(wù)器上的不同端口下。

        1? 部署后端項(xiàng)目到服務(wù)器上

        1.1? 部署后端項(xiàng)目

        將后端項(xiàng)目部署到linux服務(wù)器上,我們可以選擇傳統(tǒng)的部署方式:上傳jar包到服務(wù)器上,運(yùn)行命令“nohup? Java? -jar? xxx.jar --server.port=8011 ”。這種部署方式的弊端是只要我們代碼有修改,就必須重新打包,然后再上傳jar包到服務(wù)器上,重新運(yùn)行命令,效率低下。所以我們也可以采用docker容器的部署方式。

        1.1.1? 第一種方式

        采用dockerFile文件+jar包的方式部署,根據(jù)自己的項(xiàng)目編寫對應(yīng)的dockerFile文件,同時(shí)上傳dockerFile文件和jar包在同一個(gè)父目錄下。通過運(yùn)行命令“docker build -t? imageName? ?.”構(gòu)建我們的項(xiàng)目鏡像。然后我們就可以通過命令“docker run -d? -P? --name 容器名稱 鏡像名稱 ”運(yùn)行基于這個(gè)鏡像的容器,如圖3所示,這樣我們的后端服務(wù)就可以正常啟動(dòng)了。當(dāng)然這種方式和傳統(tǒng)的部署方式本質(zhì)上并沒有幫我們開發(fā)人員解決運(yùn)維時(shí)間,只是使用了當(dāng)下流行的docker容器而已。

        1.1.2? 第二種方式

        配置pom文件,讓其打包的時(shí)候就直接構(gòu)建對應(yīng)的鏡像。首先配置docker的服務(wù)地址和IP例如

        http://192.168.60.192:2375

        這樣打包的時(shí)候才能找到對應(yīng)的服務(wù)器上的docker,接下來就是配置打包時(shí)自動(dòng)構(gòu)建鏡像的命令:

        build-image

        package

        build

        最后配置如何根據(jù)相應(yīng)的jar構(gòu)建什么樣名稱,什么樣版本號(hào)的鏡像:

        repository/${project.artifactId}:${project.version}

        ${docker.host}

        java:8

        ["java", "-jar","/${project.build.finalName}.jar"]

        /

        ${project.build.directory}

        ${project.build.finalName}.jar

        打包成功之后我們就可以在Linux服務(wù)器上能看到對應(yīng)的鏡像,如圖1所示。

        最后就是通過docker run的命令啟動(dòng)容器,我們的服務(wù)也就起來了。相對于第一種方式我們少了自己打包jar,然后又上傳到服務(wù)器上的過程,更加節(jié)約時(shí)間。但是有一個(gè)缺點(diǎn)是我們重新打包,構(gòu)建鏡像的時(shí)候要手動(dòng)刪除原先的容器和鏡像,不然會(huì)因?yàn)殓R像名沖突的問題而構(gòu)建不知名的鏡像none,如圖2所示。

        1.1.3? 第三種方式

        基于Jenkins+shell腳本的部署方式,這是一種半自動(dòng)化的部署,只需要上傳shell腳本到服務(wù)器上,結(jié)合我們的gitee或者其他的版本控制工具,將項(xiàng)目上傳到對應(yīng)的版本控制工具上,再配置我們的Jenkins,就可以完成鏡像、容器一起的構(gòu)建。不需要再手動(dòng)輸入docker run的命令,當(dāng)然這一步是因?yàn)槲覀冊趕hell腳本提前寫入了運(yùn)行容器的命令。在shell腳本中如果我們寫了構(gòu)建鏡像的命令

        “docker build -t ${group_name}/${app_name}:${app_version}? .”我們就可以在配置文件pom文件中不寫自動(dòng)構(gòu)建鏡像的配置。這種方式我們每次只需要上傳我們修改的代碼到版本控制工具中,然后在Jenkins中點(diǎn)擊構(gòu)建對應(yīng)的項(xiàng)目,我們的后端項(xiàng)目就可以啟動(dòng)起來了。不需要再手動(dòng)上傳文件到Linux服務(wù)上。根據(jù)shell腳本,每次構(gòu)建的時(shí)候都會(huì)刪除原先的容器和鏡像,所以也不會(huì)出現(xiàn)第二種方式的問題了。

        上述的幾種方式實(shí)現(xiàn)原理都是通過構(gòu)建鏡像和運(yùn)行容器的方式來部署項(xiàng)目,部署過程不重要,最終目的是將后端項(xiàng)目部署到內(nèi)網(wǎng)服務(wù)器上,最后的容器運(yùn)行截圖如圖3所示,表示后端項(xiàng)目正式運(yùn)行起來了。部署后的后端訪問地址比如說是:192.168.60.192:8011。(這個(gè)地址在Nginx配置反向代理的時(shí)候用)

        1.2? 測試后端項(xiàng)目正常運(yùn)行

        確保通過postman或其他工具測試接口上傳圖片到minio是成功的,如圖4所示。url中的“http:192.168.60.192:9090/”就是minio內(nèi)網(wǎng)ip+端口號(hào),這個(gè)地址就是我們返回給前端,前端用來展示圖片的地址,當(dāng)我們在內(nèi)網(wǎng)的瀏覽器上輸入這個(gè)url就會(huì)顯示圖片了,但是我們外網(wǎng)訪問的時(shí)候就打不開這個(gè)圖片。

        2? 部署前端項(xiàng)目

        2.1? 上傳代碼到Linux服務(wù)器

        將我們的前端項(xiàng)目通過命令npm? build打包到dist目錄下,上傳dist文件夾到linux服務(wù)器上,如圖5所示,dist文件夾所在的目錄是“/usr/local/sti/minjian”如果我們的前端代碼在本地啟動(dòng)的時(shí)候加上了前綴/admin,例如:http://localhost:8022/admin/,如圖6所示,那么我們配置Nginx的時(shí)候記得也是要多寫這個(gè)/admin。

        2.2? 配置Nginx啟動(dòng)前端項(xiàng)目

        Nginx代理監(jiān)聽的時(shí)候是根據(jù)配置文件中Nginx所在服務(wù)器的IP地址和端口號(hào)來的,當(dāng)它監(jiān)聽到這個(gè)端口號(hào)之后,依據(jù)請求的路徑,根據(jù)配置文件轉(zhuǎn)發(fā)不同的代理。在服務(wù)器上啟動(dòng)的項(xiàng)目的端口號(hào)和前端代碼啟動(dòng)時(shí)本地寫的端口號(hào)沒有關(guān)系,比如2.1中本地項(xiàng)目前端地址的端口號(hào)是8022,但是我們Nginx中配置的可以是其他端口號(hào)如8024。這兒修改Nginx的配置文件如圖7所示,代表我們的前端項(xiàng)目在公網(wǎng)上就會(huì)是8024的端口號(hào)。

        因?yàn)楸镜厍岸隧?xiàng)目的啟動(dòng)地址里端口號(hào)后面加入了/admin,如圖6所示。所以我們在這兒配置location的時(shí)候需要加上/admin,server_name可以寫成localhost或者這臺(tái)服務(wù)器的IP地址,當(dāng)然后續(xù)我們的IP地址有相應(yīng)的域名,就可以寫成域名了,如baidu.com。此時(shí)我們訪問http://192.168.60.192:8024/admin/,就可以正常啟動(dòng)我們的前端項(xiàng)目,如圖8所示。如果我們訪問的路徑是“http://192.168.60.192:8024”,那么在這個(gè)端口下就匹配不到轉(zhuǎn)發(fā)規(guī)則,就默認(rèn)走Nginx的默認(rèn)80端口的路徑,如圖9所示。

        2.3? 配置Nginx連接后端項(xiàng)目

        基于前面的步驟,我們只是將前端項(xiàng)目和后端項(xiàng)目分別部署到了服務(wù)器上,各自都能啟動(dòng)起來,但是前端項(xiàng)目訪問不到后端的接口。獲取驗(yàn)證碼的時(shí)候,提示系統(tǒng)接口異常404,如圖8所示。原因是我們本地項(xiàng)目本來就是前后端分離的,跨越進(jìn)行訪問的。所以本地訪問后端接口的時(shí)候需要進(jìn)行代理,我們在前端中配置的請求的地址如圖10所示。加上路徑/dev-api就說明要去請求后端接口了。

        所以Nginx還需要再配置個(gè)location,當(dāng)在服務(wù)器上訪問到路徑/prod-api時(shí)就去轉(zhuǎn)發(fā),去訪問后端8011端口上的請求,配置文件如圖11所示,這樣前端就能正常訪問到后端的接口了,如圖12所示,就不會(huì)報(bào)跟圖8一樣的錯(cuò)誤。同時(shí)后端的IP和端口也沒有暴露在外網(wǎng)上,增加被攻擊的危險(xiǎn)性。

        2.4? 配置nginx訪問內(nèi)網(wǎng)服務(wù)器minio上的圖片

        圖片上傳到內(nèi)網(wǎng)服務(wù)器上的minio中,接口返回給前端的是一個(gè)內(nèi)網(wǎng)圖片地址例如“http://192.168.60.192:9090/minjian/20200405/re34.png”,外網(wǎng)訪問不到,此時(shí)我們需要將前端拿到的圖片地址進(jìn)行轉(zhuǎn)化,將內(nèi)網(wǎng)的IP和端口號(hào)修改為nginx所在服務(wù)器的IP和端口號(hào),再根據(jù)業(yè)務(wù)需求加上一個(gè)前綴。比如/pic,再加圖片本來的地址。轉(zhuǎn)化后的地址是:http://ngnix服務(wù)器的IP:端口號(hào)/pic/minjian/20200405/re34.png,然后配置nginx中的localtion,如圖13所示。

        如果監(jiān)聽到了這個(gè)端口號(hào)下的/pic路徑下的請求時(shí),就進(jìn)行轉(zhuǎn)發(fā)。轉(zhuǎn)發(fā)到圖片真正所在的服務(wù)器地址上。實(shí)現(xiàn)邏輯同上一個(gè)過程,這樣公網(wǎng)上就能訪問到內(nèi)網(wǎng)的圖片了。具體實(shí)現(xiàn)有以下兩種方式。

        2.4.1? 第一種方式

        前端拿到后端返回的圖片地址時(shí),需要給圖片屬性src賦值,可以不寫IP和端口號(hào),直接加前綴/pic,src的屬性值就是“/pic/minjian/20200405/re34.png“,如圖14所示,因?yàn)闆]有對應(yīng)的IP和端口號(hào),所以一般情況下Nginx時(shí)間聽不到的,這里可以正常訪問的,原因是image標(biāo)簽的src屬性問題,本地代碼里面寫的是相對路徑,實(shí)際點(diǎn)擊訪問的時(shí)候會(huì)自動(dòng)補(bǔ)充當(dāng)前服務(wù)器的IP和端口號(hào),如圖15所示,這樣nginx代理服務(wù)器才能監(jiān)聽到請求了該端口下的/pic路徑,然后根據(jù)轉(zhuǎn)發(fā)邏輯請求真正的圖片所在的地址。

        2.4.2? 第二種方式

        第二種方式就是將圖片地址中的IP和端口號(hào)改為nginx所在的服務(wù)器的端口號(hào),然后再加入請求路徑/pic,賦值給image標(biāo)簽的src 屬性,如src屬性值等于“http://192.168.60.192:8024/pic/minjian/20200405/re34.png ”。但是這種方式的壞處是寫死了IP和端口號(hào),將來若是將前端項(xiàng)目部署在其他服務(wù)器上,需要重新修改前端代碼。而第一種方式就不會(huì)出現(xiàn)這種問題。

        3? 結(jié)? 論

        至此,我們的系統(tǒng)就能正式運(yùn)行。我們選擇將前后端分離開發(fā)的項(xiàng)目分別部署到Linux服務(wù)器上,相對window系統(tǒng)而言,具有穩(wěn)定性好,不易受到攻擊,硬件維護(hù)成本低的特點(diǎn)。同時(shí)使用nginx的反向代理,我們很好的保護(hù)了我們內(nèi)網(wǎng)服務(wù)器的安全性,暴露在公網(wǎng)上的IP和端口越少,我們的系統(tǒng)更加的安全,更好的解決了公網(wǎng)IP或者端口號(hào)如何跨域訪問我們的內(nèi)網(wǎng)服務(wù)器上的服務(wù),同時(shí)使用docker容器化的部署,也大大提升了部署的效率。

        參考文獻(xiàn):

        [1] 李彬,朱亞興.Nginx在實(shí)現(xiàn)網(wǎng)站負(fù)載均衡方面的研究 [J].信息與電腦:理論版,2013(22):49-50.

        [2] 伍春生.Nginx負(fù)載均衡技術(shù)在高速公路視頻云聯(lián)網(wǎng)平臺(tái)中的應(yīng)用 [J].上海船舶運(yùn)輸科學(xué)研究所學(xué)報(bào),2021,44(1):60-64.

        [3] 譚暢,譚歆,胡磊,等.云中心基于Nginx的動(dòng)態(tài)權(quán)重負(fù)載均衡算法 [J].重慶郵電大學(xué)學(xué)報(bào):自然科學(xué)版,2021,33(6):991-998.

        [4] 郝淑惠.基于Nginx的Web服務(wù)器負(fù)載均衡策略改進(jìn)與實(shí)現(xiàn) [J].電子技術(shù)與軟件工程,2019(2):23.

        [5] 黎宇.Nginx在不同網(wǎng)絡(luò)域名訪問中的應(yīng)用 [J].通訊世界,2019,26(2):88-89.

        [6] 張文新.基于Linux的“數(shù)據(jù)保護(hù)+備份”架構(gòu)——文件防篡改 [J].內(nèi)蒙古科技與經(jīng)濟(jì),2021(20):90-91+122.

        作者簡介:崔娟(1995—),女,漢族,甘肅白銀人,研究實(shí)習(xí)員,本科,研究方向:大數(shù)據(jù)、軟件工程;王偉民(1970—),男,漢族,甘肅蘭州人,高級工程師,本科,研究方向:信息化、農(nóng)業(yè)工程;馮繼虎(1982—),男,漢族,甘肅隴南人,工程師,本科,研究方向:科技管理與服務(wù);李懷堂(2000—),男,漢族,甘肅民勤人,本科,研究實(shí)習(xí)員,研究方向:數(shù)據(jù)庫加密;王林柱(1997—),男,漢族,甘肅靜寧人,研究實(shí)習(xí)員,本科,研究方向:高性能計(jì)算。

        猜你喜歡
        跨域安全
        跨域異構(gòu)體系對抗聯(lián)合仿真試驗(yàn)平臺(tái)
        基于多標(biāo)簽協(xié)同學(xué)習(xí)的跨域行人重識(shí)別
        為群眾辦實(shí)事,嶗山區(qū)打出“跨域通辦”組合拳
        G-SRv6 Policy在跨域端到端組網(wǎng)中的應(yīng)用
        物聯(lián)網(wǎng)環(huán)境下的跨域信任評價(jià)研究
        基于崗位映射的應(yīng)急組織間跨域訪問控制研究
        国产成人无码av| 日韩一区二区三区无码影院| 一本大道久久精品一本大道久久| 欧美freesex黑人又粗又大| 亚洲av无码一区二区三区天堂 | 蜜桃视频一区二区三区在线观看 | 精品国产午夜福利在线观看| 亚洲欧美中文字幕5发布| 亚洲女同av在线观看| Jizz国产一区二区| 国产一品道av在线一二三区| 亚洲 卡通 欧美 制服 中文| 国产精品国产三级国产av18| 日韩人妻av不卡一区二区三区 | 欧美人与禽z0zo牲伦交| 日韩有码在线观看视频| 蜜桃一区二区免费视频观看| 国产一国产一级新婚之夜| 精品免费看国产一区二区| 伊人久久大香线蕉午夜av| 一本色道久久88加勒比—综合| 国产超碰人人一区二区三区| 国内少妇偷人精品视频免费| 色一情一区二区三区四区| www国产亚洲精品| 日本中文字幕乱码中文乱码| 亚洲国产免费公开在线视频| 国产欧美精品一区二区三区–老狼| 狠狠色成人综合网| 日本在线 | 中文| 亚洲精品视频中文字幕| 国产一区二区三区特黄| 久久99亚洲网美利坚合众国| 久久久男人天堂| 欧美性开放bbw| 亚洲精品无码久久久影院相关影片| 国产亚洲精品久久午夜玫瑰园| 国产免费操美女逼视频| 亚洲国产成人精品一区刚刚| 亚洲欧美日韩高清一区二区三区| 狠狠色狠狠色综合久久第一次|