微服務devops
容器和微服務徹底改變了應用程式開發和基礎架構管理。 他們還提出了新的安全挑戰，而沒有解決舊的挑戰。 有哪些新的安全挑戰，您可以如何應對？
微服務正在改變一切。 不變的基礎架構，無共享架構和容器化應用程式（微服務）是當今大多數企業路線圖的重點。 微服務提供了一種以小型，自治且可自我維持的能力公開業務功能的方法，可以在給定的業務範圍內執行單位任務。 這些通常以在虛擬機器內部執行，在容器內部甚至在裸機上執行的api（應用程式程式設計介面）的形式公開。
儘管容器化優勢是多重的，但這也帶來了一系列新的挑戰。 眼前的挑戰包括監視容器，容器爬網，容器安全，微服務的跟蹤和追蹤以及影象**。
那麼，對微服務領域的安全性有何影響？ 整體應用程式環境中存在的安全挑戰仍然存在，需要照常解決。 此外，我們需要考慮微服務和容器技術帶來的其他安全挑戰。
從安全性的角度來看，與單片應用程式相比，在微服務領域，攻擊的表面積現在已大大增加。 隨著更多可部署單元和端點的暴露，針對這些端點的安全攻擊的可能性以及完整性問題也有所增加。
此外，基本docker映像可能包含安全漏洞，這些漏洞可能會損害微服務。 因此，應管理docker映像的**，以確保基礎docker映像的真實性。 將安全更新和補丁以最少的停機時間傳播到所有現有容器是另乙個挑戰。
為了應對上述挑戰，讓我們看看以下最佳實踐。 作為有效的devops策略的一部分，應將連續的安全性和審核步驟整合到devops管道中。 連續測試應包括各種安全測試功能，並且影象完整性驗證應整合到管道中。 此外，私人登錄檔可以確保映像在企業內部受到信任和管理。
應該使用異常檢測機制來增強監視，以檢測容器的任何虛假資源利用或異常事件，並且應該同時使用基於**的過程和無**的過程來增強所有監視功能。 補丁程式管理應進行更新和改進，以確保用最新更新對容器進行補丁程式，同時確保最少的停機時間。
docker引入了一種稱為notary的影象源機制，該機制基於tuf（用於典型軟體分發和更新的更新框架）。 由於公證人仍處於發展階段，因此目前沒有多少容器協調員支援它。 公證人還需要企業中成熟的金鑰管理流程。
微服務之間的安全性是發生這種情況的另乙個關鍵領域，在這種情況下可以有效利用api閘道器。 傳統的基於pki的訊息安全性不是可擴充套件的選項。 相反，請看一下jwt（json web令牌）方法。 jwt是一種編碼的令牌，具有一組有關請求者的宣告策略。 令牌通常由身份伺服器簽名，可以由收件人系統驗證。 還可以對jwt進行數字加密，以維護斷言的機密性和完整性（然後稱為jwe）。
通常，安全性是（昂貴且困難的）事後才想到的。 使其成為微服務基礎結構的基本功能，以獲得最佳的安全性和效能。
翻譯自:微服務devops
微服務 學習筆記 DevOps
帶無阿潑斯 devops維基百科定義 devops development和operations的組合詞 是一種重視 軟體開發人員 dev 和 it運維技術人員 ops 之間溝通合作的文化 運動或慣例。透過自動化 軟體交付 和 架構變更 的流程，來使得構建 測試 發布軟體能夠更加地快捷 頻繁和可靠。...
微服務 微服務簡介
什麼是微服務 顧名思義，就是粒度較小的服務，不再侷限於系統與系統之間的藉口呼叫，也不侷限於某種具體的服務形式。系統中凡是可被復用的功能模組都可以被 服務化 轉變為 服務 這些服務可以對外暴露，也可能僅限於再系統內部使用。由於服務數量更多，粒度更小，因此管控難度會更大，對效能的要求也更高。微服務的好處...
29 微服務如何實現DevOps
把乙個大的單體應用拆分成多個微服務之後，每個服務都可以獨立進行開發 測試和運維。但當拆分的微服務足夠多時，卻又彷彿陷入乙個新的泥沼，無論是業務 的開發還是測試和運維，工作量都比之前提公升了很多。採單體應用架構時，乙個業務需求只需要修改單體應用的 然後針對這個單體應用進行測試，測試通過後再把單體應用的...