「山手線」的存在目的,是讓台中不再是車的城市,而是人的城市

「山手線」的存在目的,是讓台中不再是車的城市,而是人的城市
Photo Credit: 中央社

我們想讓你知道的是

台中是台灣第二大都市,未來人口老化及資源整合集中,都市規模的將日益巨大,鐵路的行車平穩、時間的穩定準確,是降低私人運具時的較合適選擇,而山手線的建設,是完成此一願景的重要關鍵。

文:梁銘浩

台中盧市長即將上任就打算停止山手線的交通建設,為了中央經費補助問題爭論不休,不知是國民黨過往經營台灣,缺乏遠見的過渡性格發酵,還是為反對而反對的無賴心態,抑或工於心計的政治盤算,不管動機如何,視野短淺,輕忽台中市民福祉的心態令人不敢苟同。

山手線算是林佳龍的核心交通建構,主要將台中兩條各自孤立的山海線鐵路連結,未來搭配藍線,綠線捷運,構成一環狀交通系統,供城市運輸接駁,可將貧脊的海線也囊括在大台中發展幅員之內。其實環形軌道運輸在國外不是什麼新鮮事,主要利用鐵路行駛穩定、時間準確可預估、載運量大等特性,將大城區各點系統性的連結,促進海、山線人力、物力,甚至財力的快速流動,縮短城鄉之間的交通差距,乃至平衡發展城市區域。如覆蓋率再加以提升,北彰化及南苗栗也可納入系統範圍。

雖然山手線建設經費龐大,受人質疑其即時性及經濟效益,但事實上,山手線是具前瞻性之綠色交通的前奏,是以未來式的台中為瞄準目標。

過往台灣重經濟發展忽視環保,崇尚美式汽車本位的交通型態,構織大量公路網,寬直的道路即象徵進步、現代化,蕞爾小島欲仿效廣袤大國的生活模式,公共運輸遠不足,促使許多人在經濟所得提高追求個人機動力,造成今日的汽車大軍帶來的溫室氣體成為氣候變遷的元凶,城市頻繁的交通意外,以及交通擁塞的巨大麻煩,尤其停車空間的緊縮已成為地小人稠的台灣揮之不去的夢魘,加上摩托車毫無底限的馳騁街頭,在台灣,城市道路空間的主體是由車替代人,行人的路權往往是最卑微的底層。

台中沙鹿陸橋改建完工
Photo Credit: 中央社

而山手線即時性的問題,綜觀軌道運輸之先進國度,東京山手線於1920年代即陸續規畫建構,巴黎地鐵1900年即完成通車,紐約地鐵1904年通車,當時各城市人口即便稀少,但估算城市發展規模預先建置,如等人口增加後面對龐大載運需求量,恐怕得花費更多人力、財力來突破都市規模增大後形成的種種障礙,建置這遲來的交通工程,成本將更形可觀。

而目前台中在行車狀況未極度惡劣之前,充分的詮譯著「汽機車的天堂,行人的地獄」之稱號,尤其週邊之人口較繁多的衛星城鎮,已情況惡劣,病入膏肓。因此交通型態的改造,才是對人口增加面積有限,未來台中市的一劑良方。

像山手線如此軌道為主的大眾運輸摸式,是歐洲先進小國的交通主幹,即便遠比台中人口少,土地面積大城市,也有高覆蓋率的鐵路或輕軌運輸,如172萬人口的維也納,公共運輸有68%的市占率,又如哥本哈根120萬人口卻有70%市占率,法蘭克福只有70萬人,高達65%市占率。台灣即便首善之都台北,近300萬人,也只有約58%的市占率,其他城市可說是公共運輸的沙漠,今日私人運具為主的型態,是過往政府眼光短淺,未看清交通本質的後遺症。

台中已是台灣第二大都市,在未來人口老化及資源整合集中的型態之下,都市規模的將日益巨大,鐵路的行車平穩、時間的穩定準確,對於未來面臨不適合私人運具的老人化社會,將是較為合適的選擇。

自然作家劉克襄在《十一元的鐵道旅行》一書中對鐵道的環保意義說了一番箴言:「如今火車沿著鐵道行駛,載著多數人來去,不再噴出濃密的黑煙。相對於汽機車的隨意來去,一二人成行,消秏大量石油。它反而變成較為環保的交通工具。……火車的來去拘限於固定路線,軌道不輕易隨山勢起伏,彷彿減緩了人類破壞土地的面積。」因此較環保的軌道運輸,可接連帶動周邊支援性低碳交通工具的設立發展。

所以,山手線為主幹線的確立後,可打造輕軌錯縱深入,電動公車中短程接駁,公共自行車近距離的接點。繼而可建構更長並較優質的自行車道,行人步行區域或新型態的綠色載具。交通模式的改變,也將影響台中人生活、文化型態的轉換,朝向人本、綠色、慢活、永續漸進,台中將成為人的城市,不再是車的城市。「鐵道不是一把尺,而是圓規。車站為針腳,我是那活動的鉛筆腳。慢吞地畫出半徑或圓圈,丈量著經過的大城大鎮小村小落。」作家之言,意味減少私人運具的數量,才可能打造優質步行環境,將路權回歸行人。

人們的移動方式可致使生活、文化型態的丕變,每一次移動,都可以從永續發展的角度作出對環境更友善的選擇,山手線則是藉由交通建設去營造出一個全新的生活型態的起始,也許未來台中行人路權優先的先進思維付諸實踐,歐式小國攜老扶幼,悠閒在空氣清新、綠葉扶疏的人行步道上,信步優游的美好景象,已成為台中的日常,作為台中市民,我們期待山手線。

延伸閱讀

本文經新公民議會授權轉載,原文發表於此

責任編輯:丁肇九
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!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。

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


猜你喜歡