【東南亞週報】泰國擱置加入CPTPP計畫|中國抗疫歌曲引菲網友不滿|新加坡安排郵輪當移工臨時宿舍

【東南亞週報】泰國擱置加入CPTPP計畫|中國抗疫歌曲引菲網友不滿|新加坡安排郵輪當移工臨時宿舍
Photo Credit:AP / 達志影像

我們想讓你知道的是

在國內欠缺共識下,泰國決定擱置加入CPTPP;一首中國推出的中菲抗議歌曲引菲網友不滿,背後原因與南海主權爭議有關;為避免新加坡的移工群體的群聚感染,官方安排他們入住郵輪作為臨時宿舍

編譯:荊柏鈞、鍾依吟、柯昀伶、黎柏君(南洋誌

南洋誌東南亞週報第64期,為讀者挑選2020年4月25日至5月1日期間,有關泰國、菲律賓、新加坡、印尼、柬埔寨、與馬來西亞等國的六則東協區域大事

泰國|反對聲浪高 泰國擱置加入CPTPP計畫

泰國內閣原定於4月28日商討加入跨太平洋夥伴全面進步協定(CPTPP)事宜,然因國內各團體反對聲浪高、朝野欠缺共識,商務部在會前一天決定撤回有關提案,擱置加入CPTPP計畫。

包括反對派政黨、公民團體、及知名人士均以CPTPP將損害泰國經濟為由而表示反對,其中又以智慧財產權有關條文對農業及醫療保健業的衝擊備受各界關切,不僅農民擔憂其收集並使用具植物專利(Plant Patent)作物的種子將受到限制,輿論也質疑藥品的可負擔性及選擇性將連帶受到影響。

對此,泰國內閣意見顯然不同調,副總理兼衛生部長阿努廷(Anutin Charnvirakul)基於糧食安全及公共衛生考量,率先表態反對;商務部貿易談判局局長奧拉蒙(Auramon Supthaweethum)則強調研究顯示,加入CPTPP將可提高國內生產毛額(GDP)0.12%達133億泰銖、投資增加5.14%達1,480億泰銖、出口成長3.47%達2,710億泰銖。

鑒於各方意見分歧,副總理兼商務部長朱林(Jurin Laksanavisit)已決定撤回提案,並表示「只要社會各團體仍存在反對聲浪,便不會將此案送往內閣會議討論。」這也形同宣告泰國政府將擱置加入CPTPP計畫。

CPTPP是全球最大的自由貿易協定(FTA)之一,前身為跨太平洋夥伴協定(TPP),美國2017年宣布退出後,其餘11個會員國包括日本、墨西哥、新加坡、加拿大、紐西蘭、澳洲、越南、汶萊、智利、秘魯及馬來西亞,於2018年3月完成簽署。

CPTPP跨太平洋夥伴全面進步協定
Photo credit: Reuters / 達志影像
圖為日本、馬來西亞、越南等11個CPTPP成員於2018年3月8日在智利聖地牙哥簽署協定並發表部長聲明。

菲律賓|中國抗疫歌曲涉南海爭議 引發菲國網友不滿

中國駐菲律賓使館4月24日在臉書上發佈抗疫歌曲〈海的那邊〉(Iisang Dagat, One Sea),欲表達兩國共同抗疫的友好情誼,不料因歌曲中的海實質上就是兩國主權爭議的南海,引發菲律賓網友強烈不滿

〈海的那邊〉歌詞由中國駐菲大使黃溪連創作,並由兩國官員、歌手等以雙語演唱,試圖展現中菲兩國在對抗「COVID-19」(2019年新型冠狀病毒疾病,以下簡稱武漢肺炎)疫情上的合作與努力。畫面中出現中國捐贈防護衣具、篩檢用品等物資予菲國的畫面,結尾更有菲國總統杜特蒂、外交部長、衛生部長、新聞部長等官員向中國致謝的影片。中國期望以這首歌曲「獻給參與和支持兩國抗疫工作的各界人士」,並展現「中菲休戚與共的命運共同體精神以及新時期夥伴關係」。

就在菲國外交部向中國在南海新設行政區提出抗議的隔天,這首歌曲上架,並且出現主權爭議的南海(菲稱西菲律賓海),MV尾端更寫道「你和我在同一片海」,引發菲國網友不滿。

截至5月1日,上架Youtube的歌曲MV已有超過20萬個網友表示不喜歡,僅3,500按下喜歡。許多網友也在留言區批評該片。請願網站Change.org上在短時間內累積1萬個簽名,要求下架歌曲。菲國眾議員比亞松(Rufino Biazon)指出:「中國大可使用同一個世界、一同奮鬥,偏偏使用同一片海,如果我們說兩個中國呢?」

MV中出現感謝菲律賓環球音樂(Universal Records Philippines),菲國網友怒火持續延燒,環球音樂也於27日發表聲明指出公司並未參與歌曲製作。聲明中表示中方曾找環球音樂協助宣傳,但公司已婉拒,也未同意將公司名稱放上MV。

新加坡|武漢肺炎確診病例破17,000 兩艘郵輪作為已康復移工臨時宿舍

新加坡武漢肺炎疫情仍未趨緩,5月1日再新增932起確診病例,使得總病例達到17,101例,15例死亡。確診者感染源多數為外籍移工宿舍,政府因此安排多處移工臨時住所,包括軍營、政府組屋等,另甚至將雙子星號與寶瓶星號兩艘郵輪作為臨時宿舍。

根據新加坡旅遊局(Singapore Tourism Board)1日發佈的消息,兩艘郵輪預估可以容納已康復的2,000名移工,而第一批移工已於29日搬入暫住雙子星號,寶瓶星號也通過評估待命。郵輪房間有獨立衛浴設備、個人餐點與娛樂系統、無線網路。相關安排都遵從嚴格的防疫措施與社交疏離原則,並規定好戶外活動時間,避免發生感染。此外,空調系統使用外面打入的新鮮空氣,不會在房間與公共空間之間循環。

新加坡4月初病例開始暴增,主要原因為爆發大規模移工群聚感染,24日起每天以三位數成長,政府也宣佈進行「阻斷器」(Circuit Breaker)的軟封城措施,希望控制疫情。

新加坡總理李顯龍30日晚間針對五一勞動節發表演說時表示,受到疫情衝擊星國經濟結構將可能發生「重大變化」,政府將協助企業轉型,並會加強醫療科技、資訊科技、以及食品生產等領域。他呼籲勞資雙方能與政府合作,三方共同努力克服經濟轉型的挑戰。

fjtotbyysv2qvotufkw7uo9tvh55fz
Photo Credit: 中央社
圖為麗星郵輪寶瓶星號

印尼|武漢肺炎逾2,200名死亡未列官方統計 政府期7月恢復正常生活

路透社報導指出,印尼逾2,200名死於武漢肺炎症狀的病患未被計入官方死亡病例,疫情比統計嚴重。另外適逢穆斯林齋戒月,政府除針對齋戒月下交通禁令外,也指出重災區雅加達疫情增長趨緩,希望逐步讓民眾恢復正常生活。

印尼目前有超過9,000個確診病例,在東南亞地區僅次於新加坡;死亡人數已有765例,在東亞僅次於中國。路透社根據全國34省中16省的數據指出,印尼有2,212名病患死於武漢肺炎急性症狀,但並未被正式通報為肺炎死亡病例,實際數字應該比官方公布的765例來的高。


猜你喜歡


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

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


猜你喜歡