《路~台灣EXPRESS~》:台日混血合拍劇, 牽起公視與NHK跨國合作的未來之路

《路~台灣EXPRESS~》:台日混血合拍劇, 牽起公視與NHK跨國合作的未來之路
Photo Credit: 公視提供

我們想讓你知道的是

在一段不算短的時間裡,吉田修一的《路》要翻拍成電視劇的傳言,就像是一個都市傳說一樣,因此去年底,小說《路》終於以電視劇《路~台灣EXPRESS~》的樣貌誕生於世,克服了種種限制,不再是樓梯上的聲響,而是看見下樓的身影時,才會讓人如此激動。

文:卡爬

吉田修一的著作《路》,用溫柔的筆觸,勾勒出了八個身分、背景截然不同的台灣人與日本人,或許他們不過就像是我們在車廂內錯身而過的陌生人,但是他們曾經不知要往何方的人生,卻藉著高鐵興建與奔馳,找到了通往未來的路。

在這本書誕生的第八年,透過台灣的公共電視與日本的NHK共同合作,終於讓這個故事從書上的字裡行間之中,用另一個方式,走進了我們的生活之中,再一次聆聽這個的故事。

從「台日合作」到「台日合拍」 走出一條全新的「路」

在一段不算短的時間裡,《路》要翻拍成電視劇的傳言,就像是一個都市傳說一樣,似乎每個人都好像有聽過,但是實際上要如何執行,卻總是停留在只聞樓梯響的階段。

有這樣的顧慮其實並不難理解,畢竟《路》的故事橫跨了台日兩地,其中也不乏兩國的文化差異與歷史因素;在實際進行海外拍攝作業時,不但牽涉演員的檔期、行程,以及製作單位的人力規劃,當然還有必須申請各式證件的繁複行政程序;此外,日本對於片場自主可控的要求世界知名,要如何確保海外拍攝的影像不會提早走漏,這些都成了這部作品影像化的門檻。

或許正因為如此,即便台灣與日本在影視娛樂層面上的關係看似親近,但過往這類跨國的電視劇作品,大多仍是以「台日合作」,而非「台日合拍」的方式進行,題材的選擇上也鮮少牽涉文化或歷史,若有觸碰往往也是輕輕帶過。

以日本製作的觀點來說,來台拍攝的規模往往不會太大,部份拍攝場景需求,多直接與相關政府部門接洽。由於這些作品並不會在台灣播出,因此也不會在台灣進行任何的宣傳,台灣觀眾也鮮少知道這類作品存在。

春香從日本外派來台,第一次到台灣高鐵辦公室
Photo Credit: 公視提供
春香從日本外派來台,第一次到台灣高鐵辦公室

近期比較有名的例子,大概就屬由日本多家電視台、影音平台共同合作,三浦春馬與池田依來沙共演的《tourist:台北篇》,全劇在台北取景,台灣的相關單位則扮演協力角色。這部作品從外國人的視野出發,將台北拍得很美,只不過由於是純日本製作,因此劇中部份碰觸到台灣傳統文化的劇情,多少可以感受到日方的不理解,反而成了美中不足的地方。

至於台灣製作的作品,大多仍是以在台灣發生的故事為背景,因此多是邀請日本演員來台拍攝,同時,這些作品多數的情況只會在台灣播出,對於日本人而言,要接觸的機會與管道並不多。

最為人所知的大概就算是藍正龍與長澤雅美合作的《流氓蛋糕店》。這部作品除了獲得日本漫畫原著的授權,在日本人氣正旺的長澤雅美也為戲來台灣長住,當時引起話題,也再一次讓長澤雅美在台灣的人氣水漲船高。

因此去年底,小說《路》終於以電視劇《路~台灣EXPRESS~》的樣貌誕生於世,克服了種種限制,不再是樓梯上的聲響,而是看見下樓的身影時,才會讓人如此激動。同時,由兩國的公共電視台共同參與製作,拍攝工作橫跨海的兩端,後續接力宣傳,並同步播出,為台日合作的作品創立了全新的模式,也正說明了這部作品是多不容易。

《路》的故事以台灣高鐵建設過程為背景
Photo Credit: 公視提供
《路》的故事以台灣高鐵建設過程為背景

用日本的筆種出台灣的花

眾所周知,吉田修一是個台灣通,他在這部作品中創造的四組人物,恰好劃出了四種存在於台灣的軸線。不論是因為旅行而邂逅的愛戀、感到寂寞而相互依偎的都會男女、在殖民時代下日人與台人的矛盾、住在鄉間,面對未知變動的青梅竹馬。四個故事雖然各自發展,卻又互相交錯,豐富卻又不凌亂,總是能從字裡行間感受到作者希望好好看照這一群受傷的人,陪著他們走過這一條顛頗的路。

如果將作者的名字遮住,很難想像,一個日本人的文字,為什麼可以對於台灣這塊土地上長出的故事與情緒,給予了這麼深刻的剖析,他到底多愛台灣,才能做到如此的地步。

四個篇章各有令人印象深刻之處,但或許是自己過往的學習與成長背景,對於葉山勝一郎與呂燿宗這對因為歷史因素與誤會而離別的摯友,特別有共鳴。因為深刻的知道,這不只是一段故事,而是終戰之時,這片土地上生存的人們,面對的真實。

做為《路~台灣EXPRESS~》的故事主軸,多田春香多次來到台灣的原因,是為了那個只見過一次面的台灣男性,然而,當她在人海中尋覓的對象終於出現在眼前時,她該如何邁出那一步,掙扎與迷惘,大概也將是整部作品吸引著觀眾目光的關鍵。

多田春香_波瑠飾
Photo Credit: 公視提供
多田春香,波瑠飾

關於這個故事的關鍵字:Taiwan Original

「Taiwan Original」是貫穿整部作品的關鍵字,它原先指的是台灣高鐵是在吸取了日本、歐洲的經驗技術,並揉合了台灣的驕傲,成為了專屬於台灣的模式。然而透過鏡頭敘事,劇中滿滿的台灣元素,不論是劇情、場景或是演員、食物,成為了另一種Taiwan Original的實踐:對於身在台灣的每個人而言,如此熟悉,甚至引起共鳴。

同一個故事,透過文字書寫與影像呈現,會有截然不同的味道,《路~台灣EXPRESS~》以一些小巧思,化身為了一台時光機,帶著觀眾回到即將跨入21世紀的台灣,不論是正在興建中的台北101,或是現在幾乎絕跡的卡式公共電話,甚至,已經成為歷史記憶的國光號,對於曾經經歷過那樣時代的觀眾而言,倍感親切,同時也喚醒了眷戀。

劉人豪Eric_炎亞綸飾
Photo Credit: 公視提供
劉人豪Eric,炎亞綸飾

同時,Taiwan Original也暗示著故事中的八個人,他們的挫折、迷惘、遺憾與救贖,全部源於台灣,而他們所追尋的答案,也在台灣這塊土地上,或許是一段應該延續的感情、過去沒能化解的遺憾,或是能夠走下去的動力。

或許,我們終究沒有辦法穿越時空,但是《路~台灣EXPRESS~》卻帶領著觀眾穿越長長的隧道,回到20年前,一切原點,經歷那群這條路連起來的台灣人與日本人,在台灣這塊土地上留下的點滴。

梁正群在戲中飾演日方與高鐵的協調者
Photo Credit: 公視提供
梁正群在戲中飾演日方與高鐵的協調者

《路~台灣Express~》資訊

  • 全劇共3集
  • 於5月16日(六)晚間9點在公視頻道、公視+首播
  • CATCHPLAY +、LINE TV、遠傳friDay影音於當天播出後上架;MOD(含HamiVideo)、myVideo則於全劇播畢後上架

責任編輯:王祖鵬
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡