【展覽】《浪來了旅遊接待會所》:以劇場手法為經,劃出馬崗的豐富此刻與可能的枯燥未來

【展覽】《浪來了旅遊接待會所》:以劇場手法為經,劃出馬崗的豐富此刻與可能的枯燥未來
石在工作隊成員於展場入口合影|Photo Credit: Cloud Chen

我們想讓你知道的是

《浪來了旅遊接待會所》以劇場手法為經,劃出馬崗的豐富此刻與可能的枯燥未來,再以藝術與社會的曖昧關係為緯,指出官─商─民的長期糾結,並大方呈現策展團隊自身的觀察和困惑,兼顧了許多面向。

文:張又升

《浪來了旅遊接待會所》是空總台灣當代文化實驗場2021年度「CREATORS」系列的展覽,由石在工作隊創作,屬於其計畫「浪來了:馬崗聚落跨界共議行動」的一部分,展期是2021年12月24日到2022年1月9日。整個計畫試圖喚起大眾對馬崗現況──由於土地開發之迫近,自然環境和社會生活都將面臨重大改變的——重視。

策畫這檔展覽之前,團隊已經開發了一套手機應用程式「私人土地,請勿擅入」,讓大家認識馬崗的人文地景和歷史脈絡,內容溫和,主旨犀利。這個有聲導覽系統僅限當地使用,離開後便無法再現其街景和精巧的擴增實境設計。

同樣的,這檔展覽也只發生在空總,展期一過,「極東漁村」的種種符號和意象就跟著消失。因此,不妨把「馬崗的APP」和「台北的展覽」視為同一條線的兩端,後者召喚我們前往目的地,同前者一遊。這裡僅回顧展覽的幾個區域。

椅子和各種日常:馬崗的此刻

這個「旅遊接待會所」的現場,沒有任何隔板,我們在看展的第一時間可能不清楚動線,因此多半只能從最近入口和櫃檯的展區逛起。這裡有許多零散的椅子,風格各異,代表的生活和日常經驗也不同。

故事豐富的「椅子區」
Photo Credit: 石在工作隊
故事豐富的「椅子區」

在類似遊覽車或小巴的絨布椅子邊,我們看到石在工作隊介紹跑遍東北角的麵包車;賣麵包的阿伯不開店,而是自己批貨,以小旅行的方式四處感受人情味。坐在鋪有薄毯的躺椅上,我們靜觀投影螢幕上的三幅側錄畫面,車窗外的風景或急或緩地流過。

塑膠小椅上,大家發現九份和馬崗的異同:兩地都有石頭屋,一者在山邊,一者在岸邊,此間差異怎解?右移坐上赭紅色沙發,另一螢幕不間斷地實時播放馬崗影像,觀展者瞬間變成監控漁村的財團大爺──雖然沙發還不夠氣派,而影像若配上倒數計時,應更能感受開發在即的迫切感。

看似零散無規劃的多張椅子,實際上隨著資訊量多寡一鬆一緊地錯落著。除了前述狀況,這個區域還包括海菜湯及其周圍的矮木椅,馬崗的居家生活和海女工作由此可見。

此外,還能讀到三貂角開發計畫和房屋結構中各式石頭的介紹,如石頭越立體規則,質地就越扎實,既能用於牆角屋底,也能凸顯經濟條件。這個展區還有貓咪攝影集、田調檔案和海邊觀浪用的馳放躺椅,族繁不及備載。

坦白說,遠觀之下頗為凌亂,但只要花時間擇一感受,不只可以細細了解馬崗的故事,還能發現石在工作隊運用的劇場手法:以物件象徵單一時空,多元時空併陳於此,必須花大量時間體察。

墳場上的錄像:未來已成過往

展場另一端是一堆莫名物件覆蓋著如山丘蜿蜒的米色大幡,上方吊著一排排、一塊塊寫有馬崗歷史(包含年代與事件)的長板,乍看之下有如墳場,一個村落的墳場;即便其中一處掛著紅布條,像極了人煙尚存的祠堂,但其上無字,周邊一派荒涼,氣氛更顯詭譎。這裡的物件不再是小而多樣,反而是大而單一,配上鵝黃色燈光,與前一展區的繽紛恰成對比。

荒涼單調的「墳場區」
Photo Credit: Cloud Chen
荒涼單調的「墳場區」

唯一的例外,是一架可能重組、拼裝自嬰兒護欄床的推車。裡頭裝有若干裱框的照片和小物,令人不知該定睛何處。雖然如此,看過一旁重複播放的錄像,一切就明瞭了:馬崗街27號咖啡店的老闆夫婦推著推車,沿路「回收」或「保管」居民的記憶。

因為用陳舊的映像管電視播放,這件作品產生了獨特的有別於今日液晶畫面的色調,霧面拋光卻不失瑰麗。我們看到一對老夫妻踏出家門,緩緩將一張合照置入推車,老闆將它擺好,繼續前往下一站。或許是我的錯覺吧,總覺得畫面中的馬崗人似笑非笑,刻意專注於眼前任務。

錄像無聲,居民的獨白──提到自己怎麼來到馬崗,以及若離開村子時只能攜帶一個東西,自己又想帶走什麼──從另外的喇叭流出。影音分家、刻意奔忙和笑中別有深意等訊息在象徵性的物件襯托下,為錄像撒上一點神祕的戲份,頗有六七零年代日本實驗電影的味道(尤其是寺山修寺的作品,他本身即出自劇場)。

回望來時的椅子區,在色調、物件大小/數量和訴求等面向上,相反的程度可謂非常工整,可以說:那裡還是生機勃勃的此刻,此處已是垂死的或淪為過往的未來;那頭還有各種議題和故事值得關心,改變和扭轉都還有可能,這頭卻一切塵埃落定,徒留物化的回憶,我們只能默默承受──墳場,不就是這個意思嗎?

黑盒子:逃無可逃的社會過程

那麼,事情是怎麼走到這一步的?據說有人看展時,直接繞過上述兩個展區的中間地帶,好像它不存在。的確,這「第三個展區」只是一個偌大的黑盒子,走過路過,隨時可能錯過。如果發現了它,也只能透過黑盒邊上的孔洞窺看其內裏,那些糾纏多年的事件這才一一浮現。

在黑盒長側的一面,貼滿了政府和財團力圖興修馬崗的新聞,裡頭載明這樣做多麼必要、可以帶來多大效益;另一面,則是居民和運動者抗議的過程。這些資料包含圖表和報章雜誌的剪影,甚至刻意保留了一點排版印刷的墨跡,顯見時空距今已有一段距離。黑盒短側的一面,是居民提出的需求;另一面,則是政府認為「對馬崗好」的種種作為。兩造對反又遙遠,幾無調和的可能。

管窺黑盒子中的社會過程
Photo Credit: Cloud Chen
管窺黑盒子中的社會過程

黑盒子連結了前後兩個展區,為整場展覽起著畫龍點睛之效,具有多重深意。

第一,在觀念層次,黑盒子中介了活的此刻和死的未來,說明馬崗歷經了怎麼樣的過程而邁入被迫開發之境。我們管窺內裏的動作,則說明官民溝通的過程耗神費時,不受一般人關注;就算關注,獲得的理解也是片面的。

第二,跟椅子區輕鬆坐下和推車區凝視畫面等慣常動作相比,管窺黑盒子的欠身動作更耗體力,也較少見,同時提醒了我們身體對作品意義的形塑,以及社會大眾認識這起事件的困難。

第三,在藝術和社會(運動)的關係上,黑盒子更意味著官─商─民的協商和鬥爭被包裹起來,與藝術存在重大隔閡,大眾願意在其他展區逗留,卻未必想多花心力認識這個社會過程。偏偏黑盒子橫亙在兩大展區之間,抹不除、剔不掉,就算忽視它,也只能繞道而行;換句話說,它的存在證明社會(運動)必然如影隨形於藝術,既是後者的中介,更是其不可迴避的前提。

在打開黑盒子之前

我們需要打開這個黑盒子嗎?當然需要,關心馬崗的行動者從事這項工作已經好多年了。但現況是,由於主流媒體的報導方式和無數私人因素,各方力量對其內裏的探索一直淺嘗即止。

這個淺薄或侷限的事實──亦即黑盒子的持存和封閉,以及大眾對此模糊、懶散和隨意的認識──本身就需要被指認,因為它也是社會現象的一環。唯有如此,我們才能正視需要改變的事實;如果這麼做最終有助於打開它,藝術改變社會的能力也就不容否認。

石在工作隊的成員除了設計APP的阿良外,奎妙本身從事社運多年,力主文化和日常經驗在運動中的重要性,睦芸則出身劇場設計,認為藝術的範圍遠遠超過學院,甚至在社運的場域中也不只有「服務」的性質。

由此看來,《浪來了旅遊接待會所》一方面是石在工作隊關心馬崗的暫時成果,另一方面也是成員檢視藝術和社會互動、反思自身長年困惑的方式。考量這層反身性因素,展覽的意義又更深刻了。

總的來說,《浪來了旅遊接待會所》以劇場手法為經,劃出馬崗的豐富此刻與可能的枯燥未來,再以藝術與社會的曖昧關係為緯,指出官─商─民的長期糾結,並大方呈現策展團隊自身的觀察和困惑,兼顧了許多面向。雖然展區略顯紛雜,展覽的整體形象也頗素樸,卻值得細細玩味,若能親至馬崗搭配有聲導覽,肯定還有另一番感動!

【加入關鍵評論網會員】每天精彩好文直送你的信箱,每週獨享編輯精選、時事精選、藝文週報等特製電子報。還可留言與作者、記者、編輯討論文章內容。立刻點擊免費加入會員!

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


猜你喜歡


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

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


猜你喜歡