條條大路通曼谷:建造從1950年代展開,4大公路貫穿泰國全境

條條大路通曼谷:建造從1950年代展開,4大公路貫穿泰國全境
Photo credit:Frank

我們想讓你知道的是

泰國公路網的邏輯以曼谷為出發點,向四方發散,而且路名不變,似乎暗示著中央政府的權力要抓緊領土的每一寸。相較於台灣,泰國地廣人稀,開車如果遇上塞車真的是悶死人,車友如果在泰國上路可以四處觀察一下公路編號,或許是個消除無聊的小方法。

文:法蘭克(遊四方

泰國是許多台灣自由行旅客的首選之一,即便泰國車輛為右駕形式,也不減租車自駕的興致,尤其泰國領土面積是台灣14倍,如果不搭車,有些景點確實很難抵達。泰國公路系統尚稱發達,路面品質也可以接受,加上泰國車輛駕駛彬彬有禮,不隨便按喇叭,在泰國開車可說相當自在。本篇簡單介紹一下泰國公路系統和一些發展歷程,讓車友們能在漫長的駕車旅途中,增添一點樂趣。

img_9485
Photo Credit:Frank
泰國公路品質尚稱平坦,駕駛禮儀甚至比台灣還好,但如果要租車自駕,還是要注意跟台灣相反的右駕習慣,以免發生交通意外。

泰國公路(Highway, ทางหลวง)系統基本上是以曼谷為中心向四周輻射,1號公路向北通往清萊(Chiang Rai, เชียงราย)直達緬甸邊境,2號從1號公路北標府段分支通往東北,直達寮國邊境廊開府(Nong Khai, หนองคาย),3號向東經過度假勝地芭達雅後抵達叻府(Trat, ตราด)與柬埔寨公路銜接,4號往南經過合艾府(Hat Yai, หาดใหญ่)後進入馬來西亞,是4大公路中最長的一段,總長1,300多公里。這個運輸系統同時也呈現泰國政經和地理區劃的視角,泰國的政治和經濟都以大曼谷為核心;而地理區劃上,泰國分成北部、東北部、中部和南部,依序由1至4號公路所貫穿。

e6b3b0e59c8be585ace8b7afe7b6b2-1
圖片取自Google Map。
圖中以1號綠色、2號紅色、3號橘色、4號藍色的方式標註泰國公路系統,並依序貫串北、東北、中及南部各府,其中4號公路之間有一段編號37的支線,這是因為碧差汶里府屬於地理區劃上的中部,且又是連接該府與南部巴蜀府的府際主要公路。

泰國境內公路就以這4個編號為基礎開展,一位數代表全國性公路系統,二位數代表府際間最重要公路,三位數代表府際間次要公路,四位數則是府內連結府尹和其他縣城的公路。如下圖在春武里府3號公路上拍攝,3134就是連結春武里市和府內昂席拉區(Ang Sila, อ่างศิลา)的公路。現代化後,泰國也開始建造收費的車輛專用高架特別道路(motorway, ทางหลวงพิเศษ),例如上圖綠色的7號和9號,不過特別道路的編號系統和公路系統不同,不是本文焦點。

c52d39b7-eee4-4ef9-bde3-4ae6355fd227
Photo credit:Frank
右邊招牌上的4位數公路編號,表示是府內連結兩個城鎮的道路。

這種科學化的公路分類系統其實是近期的產物,但其實公路的建造從1950年代就已經展開,泰國境內最早的現代化柏油鋪設公路,是由美國在1955年到1957年資助建設完成,當時適逢越戰初期,美國在泰國東北地區設立大量空軍基地,用來起降前往越南進行轟炸任務的戰機,而這條公路主要也是為了運送軍用物資,不過同時也協助了泰國東北農民運送糧食,因此當年將這條從呵叻府(Nakhon Ratchasima, นครราชสีมา)銜接廊開府的公路命名為「友誼公路」(Mittraphap Road, ถนนมิตรภาพ),也就是今日2號公路。

ece936e1-fe1c-49c0-a09b-80773258703a
Photo credit:Frank
越戰時,美軍利用泰國全境的7個空軍基地,派遣軍機前往北越進行轟炸任務,地圖上可見泰國東北有4個軍用機場,美軍在該處建設的「友誼道路」主要就是為了運輸軍需用品,成為今日的2號公路。

另一條往北的1號公路,它的歷史集諷刺於一身。此路最初於1936年完工時,從今日的勝利紀念碑到廊曼機場總長22公里,原名叫做「民主路」( Prachathipatai Road ,ถนนประชาธิปไตย),1938年披汶( Plaek Phibunsongkhram, แปลก พิบูลสงคราม)總理任內,公路延長工程直達信武里府(Sing Buri, สิงห์บุรี),總長增加為162公里,為了紀念他前一任總理,因此改名為拍鳳裕庭路(Phahonyothin Road, ถนนพหลโยธิน)。諷刺的是,拍鳳裕庭和披汶就是1932年聯手發動政變推翻絕對王權的兩位將軍,披汶把「民主路」改為「政變將軍路」,似乎預言了泰國迄今多達21次軍事政變的近代史。

2ba810e0-571f-45b5-9d63-f1c6a25847fb
Photo credit:Frank
BTS素坤逸線東西向沿著素坤逸路搭建,南北向則沿著拍鳳裕庭路搭建,照片背景為拍鳳裕庭24巷站。

另外,曾讀過夏恩史崔特(Shane Strate)《從暹羅到泰國─失落的土地與被操弄的歷史》的讀者應該記得,此碑是泰國「國恥論」的象徵之一,批汶原本希望用這紀念碑來讓國民記住1941年泰國對法戰爭勝利,並且取得柬埔寨的四個府,不過隨著二戰泰國作為戰敗軸心國,四府必須歸還法國,勝利紀念碑反而成為國民記住「失土國恥」的印記。總結這兩項,1號公路可說是泰國近代史的雙重諷刺集合體。

493f8e87-a874-4e42-9e10-9d385e0b8d21
Photo Credit:Frank
拍鳳裕庭路舊名為「民主路」,起點是勝利紀念碑,路名更迭以及紀念碑的歷史相當耐人尋味。

提到3號公路,應該無人不知,無人不曉,它的本名叫做素坤逸路(Sukhumvit Road, ถนนสุขุมวิท),曼谷市中心最重要的空鐵BTS「素坤逸線」,東西向的部分就是沿著這條路搭建。素坤逸是泰國第五任公路局長,出身於交通工程世家,他的父親曾在八世皇在位期間主理鐵道運輸的內政部長,本人則於1923年畢業於美國麻省理工學院,畢業論文主題是研究美國波士頓交通規畫之優劣,是從MIT畢業的首位泰國人。

img_9905

素坤逸是首位從美國麻省理工學院畢業的泰國人,返國之後擔任泰國第五任公路局長,規劃出本文所說的泰國公路網,奇怪的是,維基百科泰文版竟然沒有任何這位偉人的資訊。
翻拍自《曼谷城地名》第7版
 

素坤逸路最早在1927年就開始鋪設,隨後不斷延伸,1936年時素坤逸路向東可達北欖府(Samut Prakan, สมุทรปราการ),當時名為「曼谷─北欖路」(Bangkok-Samut Prakan Road, ถนนกรุงเทพฯ-สมุทรปราการ)。素坤逸接任當時公路局長後,開始規劃「泰王國國家公路計畫」,把「曼谷─北欖路」納入計畫之中,公路一直延伸到達叻府,路名也因此改成「曼谷─達叻路」。1950年12月10日,為了表彰這位為泰國公路運輸網貢獻良多的工程師,批汶總理決定以「素坤逸」作為路名。

493f8e87-a874-4e42-9e10-9d385e0b8d21
Photo Credit:Frank
地鐵MRT「素坤逸站」出口就是大名鼎鼎的Terminal 21,與BTS「素坤逸線」交會。

照片中的素坤逸相當俊俏,他在二次世界大戰期間,還曾經是「自由泰運動」(Free Thai Movement, เสรีไทย)的成員,戰後參加使團前往美國討論泰國戰後重建的問題。「自由泰運動」約於1942年出現,當時泰國批汶政府為維持政權,決定與日本同一陣線加入軸心國,並且向英美宣戰,當時駐美大使反對批汶的親日政策,拒絕向美國遞交宣戰書,宣布成立「自由泰運動」。其實當年批汶政府也默許政府內官員加入,「自由泰運動」因而成為戰時同盟國情報中心,戰後泰國也因此運動而未遭同盟國追究宣戰行為,加上戰後越南情勢緊張,美國立即展開對泰國的經濟援助以及基礎建設。

5df54566-f0ef-4087-ba84-4af669fa3256
Photo Credit:Frank
碧甲盛路起點位於曼谷艾縣(Bangkok Yai, บางกอกใหญ่),從這裡一直通到馬來西亞邊境,是四條國家公路最長的一條。

猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡