【鍾喬專欄】共同記憶的復甦:一齣戲中的一趟旅程

【鍾喬專欄】共同記憶的復甦:一齣戲中的一趟旅程
Photo Credit: 客家戲劇《范天寒和他的弟兄們》

我們想讓你知道的是

1980年代的社會運動,通常以對抗國民黨的戒嚴統治作為總結。而客家戲劇《范天寒和他的弟兄們》的范天寒也真有其人。本名梁雲漢。1952年,因涉入白色恐怖案,在桃園三洽水的山坳仔家鄉被捕,在牢房中待了20年,兄長與侄子分別被判死刑。

1980年是東亞民主改革變遷的年代。特別是台灣與南韓,因著二戰後共同被編入亞洲反共島鏈的政經元素,以獨裁下的經濟發展,涉越1970年代的石油危機,創造亞洲四小龍的唯發展論奇蹟。當然,彼時中國大陸也邁向當前毀譽參半的改革開放之路。

可以說,整個1980年代東亞的轉化,一定程度訴說了這以後30多年來的裂變。然而,媒體或知識主流會說,拜西方現代化之賜,有了民主化改革,卻甚少會提及——台灣與南韓幾乎類似的依賴性發展模式,在冷戰文化影響下,如何自外於亞洲的自主性,並藉此脫胎出「中國因素」的根源。

這便也是活過1980年代的眾生,在身體裡檢討戒嚴元素時,無法放過卻輕易掠過的國際冷戰因素。這其實與台灣作為美式新殖民文化的隱形駐在所,有著不可脫鉤的密切關聯。

40046975_10156203224974900_6183977329635
Photo Credit:蔡明德攝影

1980年代的社會運動,通常以對抗國民黨的戒嚴統治作為總結,即為當時的「轉型正義」。

30多個寒暑說來不長,在網路瞬息全球傳遞的當代,也不能說短。那麼,且以記憶來聲稱這樣的時間感。畢竟,1980年代顯得那麼關鍵且重要。若說記憶,個體記憶與共同(集體)記憶是交錯的兩條線索。從個體記憶,我們取得了開啟人與自身對話的空間。

通常個體記憶緊守人的主體性,這固然重要;很多時候,姿態或風候形成時,卻失去對以社會為單位的共同體的想像。

我想來說個共同記憶的故事:可以說,我是在這樣的前提下,經歷本島1980變幻不拘的風雲。並在當年,以探索眾生相依歸為標竿的《人間雜誌》,認識一位稱作卡巴(Robert Capa)的國際攝影大師。並開始想像,如何將卡巴虛擬為身旁的攝影家,並在內心裡虛構在地的台灣卡巴;與此同時,我因為涉入1988年的客家「還我母語運動」,並於《人間雜誌》主編「台灣客家專輯」,從真實人物的訪談過程中,虛構了另一個稱作范天寒的人。

40100040_10156203223514900_9347238515714
Photo Credit:鍾喬臉書

關於卡巴(Robert Capa),1930年代,他在西班牙內戰現場,因拍下「倒下的士兵」這禎膾炙人口的傑作,而以「如果,你拍得不夠好,是因為你靠得不夠近」一句名言,名遍天下。現在,我的手邊有兩台1980年代留下的相機,那是向老友蔡明德借來做戲用的道具。這相機的兩顆鏡頭,紀錄了一個孕育新社會的波濤年代。隱藏在這鏡頭背後的,又是多少擺在眼前的未知呢?

Capa,_Death_of_a_Loyalist_Soldier
© Public Domain

攝影師Robert Capa的作品《倒下的士兵》,原題《一位忠誠民兵的死亡瞬間,木里亞諾山,1936年9月5日》。

現實說不盡的,恰好是詩或戲劇最想介入的。我將卡巴邀請進一齣戲中。但我要說的是:戲中的卡巴,僅以「卡巴」為名,卻已不是攝影史上的大師卡巴了!而這位戲中的卡巴,卻經常夢靨似底醒在子夜的床頭,而後噤聲底對著自己說:「真的嗎?但⋯⋯我靠得夠近時,也就是按不下快門時候」。

這句話的背後,有其背景。也就是在1980年代,當我與蔡明德前往報導的現場時,常掙扎於報導見證與參與運動的界線之間;最後,總以邊拾著相機與紙筆,邊投身到民眾抗爭的現場為總結。現在回顧,既是共同記憶的一部分;也可以說是,個體記憶的全身丈量吧。

話說回頭,記憶無論是共同或個體,都以一種流動的狀態,進入到日常生活的場域中。也就在這樣的流動中,戲中的卡巴與一位稱作范天寒的長者見了面。范天寒,一個消失於真實世界,卻出入於虛構世界的名子。或許他只是一張徘迴於光與暗中間的影。但他隱入黑暗中的前一刻,一整個1950年代白色恐怖的肅殺,像在時空中突而失蹤的一部紀錄影片一般,又在我們「轉身」(客家回首的意思)時,一吋吋穿梭在我們的視線中間,卡巴於是在這影像的流動中,與范天寒從相識而握手,在虛構的這部戲劇中。

40139983_10156203223714900_4732030207492
Photo Credit:蔡明德攝影

范天寒的背後,真有其人。本名梁雲漢。1952年,因涉入白色恐怖案,在桃園三洽水的山坳仔家鄉被捕,在牢房中待了20年,兄長與侄子分別被判死刑。一頁刑殺的判決書,歷歷在目。

「我們是手綁著手,牽著 一條麻繩,被帶上車,送進軍法局的。」梁雲漢生前,這樣對前去採訪的我說。而後,接著又說:「這是我生平第一次,向外人說我們家族的故事,內心壓力很大!」那是1988年,解嚴後的一年,文化冷戰仍在島嶼上空盤旋。為了免於讓梁先生及其的家族,再次驚心。我幫他取了一個稱作「范天寒」的名子。

一個真實的名子,消失在日光下;一個虛構的名子,卻誕生於迷霧中。這是現在回首1980年代踏訪1950年代肅殺事件,從內心深處浮現的一句話。《范天寒和他的弟兄們》就這樣以一齣客家戲碼的身世,將與眾人謀面。而此刻,我不免再次憶起,希臘導演安哲羅普洛斯的電影《尤里西斯的凝視》(Gaze Of Ulysis)。

片中那位穿越整個東歐,只為尋回消失在戰亂中的一部紀錄片的主角——他是一位導演。他說:「戰亂讓一整個世代幾近消失,只有找回紀錄片,才能找回眾生的面目。」他說的,雖與范天寒及一整個1950年代的撲殺在情境上有所差別,卻道盡殺戮與滅絕的過程,一如以壓迫者的殘酷行動,用一鏟鏟泥濘中的血土,無聲埋葬反抗者。

那麼,從這樣的范天寒,我們也得以連結到電影中,那場霧中的屠殺。來得何其突兀,卻又真實得令人生畏。電影中的父親說著「霧是人們最好的朋友」,因為霧終止了戰爭。於是和女兒邀導演至河邊散步。女兒哀求導演帶她離開戰亂的家鄉,導演答應了。沒想這時,河邊來了軍人,老人和女兒在軍人的槍擊聲中,倒落於霧滿的河畔。

這有如范天寒的家人與親族,仆倒於馬場町刑場,在1952年,天剛亮時的某一天。是的,也恰是在另一個電影的場景中,歷經1989年的東歐社會主義解體的鄉民們,帶著錯愕的臉孔,在一條大河的河畔,目睹激流中的 一條貨船,載走在河上游的碼頭,被支解下來的、巨大的列寧石雕頭像。

一切都像一趟旅程。凝視著戲劇中范天寒,或者電影中的尤里西斯。而這旅程,只為穿梭無盡的邊界,來到時間的這頭,與我們再度謀面,如此而已!這便是《范天寒和他的弟兄們》的故事。

責任編輯:游千慧
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡