在小弟先前的演講中 20190218_OpenShift Storage 架構思考，有提到針對每個容器在容器平台 (Kubernetes / OpenShift / …) 上，所儲存的資料會分為三大種架構類型：

1. Data in the Container
2. Data in a Host Volume
3. Data in a Shared Storage

但我那天沒講的事情是，這些 Backend Storage 的類型應該要選擇什麼是比較恰當的？所以下面整理了一下

Red Hat OpenShift v3.11 架構裡網路主要分為三大塊:

1. Hosts subnet
2. Service subnet
3. Pod subnet

雖然 Terraform 及 Ansible 都是非常知名的 IaC (Infrastructure as Code) 的工具，但經常會被拉出來討論說這兩者的差異，所以經歷了一陣奮鬥(?)，Red Hat 及 HashiCorp 發出聯合聲明 HashiCorp Terraform and Red Hat Ansible Automation

最近 VMWare NSX-T 出了一篇跟 Red Hat OpenShift 3.11 的整合文章及影片，下圖的整體技術架構上是十分靠譜的，但有些點是可以另外加入考慮的，但本文不贅述，

2019/2/24 CNCF 宣布發展 CNF Testbed，計畫主要針對在 ONAP (Open Network Automation Platform) 上的 VNF (Virtual Network Function) 及發展中的 CNF (Cloud native Network Function) 進行雙方的功能測試，相互比較優劣勢及性能彈性

前言

對於多數系統硬體資源配置多數就是一個公版 Instance Template 為基準，透過監控來進行效能調整或組件置換。本篇提供大家一個簡單的選擇方向，各大 CSP (Cloud Service Provider) 分別都有提供對應的 VM 實例資源配置參考，可先用使用情境進行初始評估，再依據經驗選擇不同大小的資源 (e.g. medium / large / xlarge / …)，後續如果真心不夠用可以再 resize 資源即可。

NetDevOps = Networking + DevOps

近年來網路管理受到軟體定義網路 (SDN) 及 DevOps 的發展驅動了不小的變革，延伸至 - JUNOS DEVOPS尤便捷 更精彩 - SDNLAB 文中所帶出：快速服務是目的、自動化是手段、DevOps 則是思路或方法論，而 NetDevOps 這詞則是將既有 DevOps 的方法論套用在 Networking 領域中所產生的維運方法論。

OpenAPI Specification, OAS

隨著資訊服務的飛增及複雜，各家廠商所提供的底層服務封裝後提供出來的介面，我們稱做 API (Application Program Interface)，而 OpenAPI 則是將這些 API 依據某些規範公開出來給第三方使用，可包含免費使用、付費使用或限定使用等方式，有一個公開既定的規範可供參考。

前言

先說本文謹代表個人撰寫 Ansible Playbook 及 Ansible Tower 之經驗累積，不定期會更新內容，僅供參考 XD

Ansible 本身具備著幾個很顯著的特性: 好寫, 易讀, Agentless，但說到好寫，也因為寫的花樣特別多，所以 特別撰寫此文留下平時我寫 Ansible Playbook 時會注意的一些地方。當然有些內容會從 Ansible 官方所列的 Best Practices 截錄過來，但多數還是由我個人撰寫經驗的角度為出發點。

Change timeout

• vim isolinux/isolinux.cfg

  1 2 3 4 5

  default vesamenu.c32 #timeout 600 timeout 50 display boot.msg

• Prompt until booting automatically, in units of 1/10 s. In the case, we change the timeout value from 60 secs to 5 secs