教宗堅信中梵關係「艱困對談好過毫無對談」,前樞機主教陳日君嘆:對中共的認知大錯特錯

教宗堅信中梵關係「艱困對談好過毫無對談」,前樞機主教陳日君嘆:對中共的認知大錯特錯
Photo Credit: AP / 達志影像

我們想讓你知道的是

教宗坦承,臨時協議賦予中國政府指派主教權力,並能藉此向當地神職人員施加壓力、迫使他們對共產黨扶植的教會宣布效忠。他表示會概括承受「出自善意的」批評指教,並對其他意見持開放態度。

文:王國仲

教宗方濟各(Pope Francis)9月1日接受西班牙主教團(Radio Cope)網路電台採訪時,罕見針對梵蒂岡-中國關係發表評論。他為天主教會與中國共產黨政權間具爭議性的外交政策辯護,但同時坦承此舉會產生「有問題的」後果。

教宗提到的外交政策,係指梵蒂岡和北京在2018年簽署,讓教宗擁有中國主教最終任命權,同時也代表雙方建立正式對話管道的協議。2020年9月,雙方同意將協議再延長兩年(至2022年)。

前美國總統川普(Donald Trump)、史上在聖座擔任過最高職務的華人韓大輝總主教、香港教區前樞機主教陳日君等政要,皆曾試圖說服方濟各放棄協議(憂心將損及教宗的道德權威),教宗則仍堅信「艱困的對談,好過毫無對談。」

教宗舉過去和蘇聯互動為例:「我們必須持續向前邁進」

方濟各表示:「和中國對話不容易,但我堅信我們不應該放棄對談。在對話中,或許期待會落空、我們會犯下錯誤……儘管這些都有可能發生,但這至少是解決問題的方法、是應走之路。封閉的心態並非解決問題之道。」

不過,教宗亦坦承該協議賦予中國政府指派主教權力,並能藉此向當地神職人員施加壓力、迫使他們對共產黨扶植的教會宣布效忠。他表示會概括承受「出自善意的」批評指教,並對其他意見持開放態度。

方濟各並舉前教廷國務卿,「教宗的季辛吉」卡薩羅利(Agostino Casaroli)樞機主教和東歐共產政權互動的成功經驗為例,說明和中國持續進行對談是必經途徑。

卡薩羅利是教廷史上最成功的外交官之一,曾在三位教宗座下服務。他在任職期間想方設法,維繫東歐各蘇聯加盟國與教廷關係,並致力改善冷戰鐵幕下共產國家內神職人員的傳教條件。

1971年,卡薩羅利成為蘇聯成立近50年來,第一位到訪的梵蒂岡官方代表。三年後,他也是首位出使卡斯楚(Fidel Castro)領導下共產古巴的教廷官員。在其職涯巔峰的1989年,他更成功安排蘇聯總書記戈巴契夫(Mikhail Gorbachev)與教宗若望保祿二世(Pope John Paul II)在梵蒂岡的歷史性會面。

卡薩羅利的成功,便源自於和共產國家政權的密切合作——教會選擇隱忍共產政權對民眾權利的侵害,更將主教任命權下放給各地政府,藉此換取天主教會的喘息空間——傳教與活動自由都不致遭受太多迫害。

雖然此種向共產政權妥協,甚至任由其侵害人權的作法在當時招致不少批評,但正是這樣的策略,讓鐵幕之下的天主教會仍具備一定自主性與發展空間。部分歷史研究者更認為,天主教會對自由、民主風氣的推波助瀾,在某種程度上扮演了冷戰結束、共產主義垮台的催化劑之一。

方濟各在訪問中提到卡薩羅利著作《耐心的殉道》(The Martyrdom of Patience,教宗稱其為「非常美好的書」):「卡薩羅利一步一腳印、緩步努力前行,最終成功搭起聯繫中歐的橋樑。慢慢地、慢慢地,他了維繫外交關係,更得以顧全所有天主忠貞的子民……現在,我們也必須在最矛盾的情況下,持續一步步向前邁進。」

AP_18108342830675
Photo Credit: AP / 達志影像

政界、自家人齊聲反對,認為教廷對中國共產黨的認知「大錯特錯」

儘管教宗堅信變革必須透過對話,並與北京當局建立互信而來,仍有不少公眾人物,甚至包括自家神職人員,皆認為中國難被信任,並屢次籲請教宗放棄協議,甚至採取更強硬立場。

美國前國務卿蓬佩奧(Mike Pompeo)便曾在2020年9月,教宗續簽任命協議之前公開呼籲教廷,應對中國對宗教自由的限制採取更嚴肅立場,並與美國一同譴責中國對少數民族與人權的侵犯。

梵蒂岡並未公開回應其發言,但據知情高層人士表示,教廷對蓬佩奧公開施壓、下指導棋的行為感到「震驚且不滿」。或許是肇因於此,蓬佩奧在同年9月底造訪教廷時並未獲教宗接見(官方說法為避免影響11月的總統大選)。

除蓬佩奧外,前樞機主教陳日君,長久以來也一直是梵蒂岡-中國協定的堅決反對者。他接受《德國之聲》採訪時表示:「糟糕的協議真比沒有協議來得更好嗎?我無法理解。若這項協議已經違背了我們的理念與初衷,又怎麼能說它比沒有協議更好呢?」

在2020年9月至教廷求見教宗未果後,失望的陳日君更直言,方濟各似乎正讓政治凌駕於宗教之上:「這一切大錯特錯。地下教會持續遭受打壓,更覺得自己遭到背叛。各區主教現在都由中國官方指派,對北京唯命是從。」

陳日君認為,教宗對中國共產黨的認知大錯特錯:「教宗來自南美洲。那邊的共產政權確實為了人民福祉而戰,因此他對共黨心懷理想與同情,是可以理解的。但在中國,共產政權才是壓迫人民的一方。」

合法宗教必須宣布效忠北京,地下社群持續遭到迫害

蓬佩奧的警告和陳日君的擔憂並非毫無道理。自2021年7月開始,中國各地皆盛大舉辦一系列共產黨成立100週年的紀念活動:「每個(天主教)社群、教區都舉辦過慶祝活動、戲劇表演,甚至到與共產黨歷史相關的地點參觀。」身兼傳教士、記者,持續追蹤並報導中國天主教會長達20餘年的賽維勒拉(Bernardo Cervellera)表示,「但教徒連想前往佘山聖母大殿(中國著名聖母朝聖地)朝聖都不被允許。」

賽維勒拉表示,合法的天主教神父皆必須簽署相關文件,承諾支持中國共產黨,且僅能在官方承認的教堂內進行禮拜、傳教;未成年的孩童也被禁止進入教堂:「我們觀察到部分修道院被拆除、教堂被關閉;神父被逐出自己的教區,神學院中也不准教授神學。對地下天主教社群來說,生活確實非常艱苦。」

延伸閱讀

新聞來源

責任編輯:羅元祺
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡