一加Ace2 Pro真機揭曉 鈦空灰配色質感拉滿
終于，在經過了幾波預熱之后，一加Ace2 Pro的外觀真機圖在網上出現了。還是博主數碼閑聊站曝光的，這次的外觀設計還是延續了一加11的方案，只是細節上有了調整，例如新加入了鈦空灰
1.容器提供標準化開發
當解決方案提供商專注于提供價值而不是目標環境的復雜性時，每個人都會贏。這就是容器大放異 彩的地方。
隨著容器技術產品（如 Docker）的廣泛采用和標準容器運行時平臺（如 Kubernetes）的持續普及 ，開發人員需要考慮的兼容性問題越來越少。雖然熟悉目標環境仍然很重要，但只要我們在開發過程中可以使用相同的平臺，具體的操作系統、安裝的實用程序和服務就不是那么重要了。我們認為這是越來越多的新容器運行時選項的原因之一。
對于針對本地環境的工作負載，可以根據所需的編排級別選擇運行時平臺。一些團隊決定通過Docker-Compose 運行他們的少數服務，這對于開發和測試環境來說是典型的，對于生產安裝來說并非聞所未聞。對于需要成熟的容器編排器的用例，Kubernetes（以及 OpenShift 等衍生產品）仍然??占主導地位。
那些為云開發的人可以從眾多選項中進行選擇。Kubernetes 存在于所有主要的云平臺中，但也有針對那些具有整體工作負載的選項，從半托管服務到完全托管服務，以獲取那些簡單的 Web 應用程序（如 Azure App Services 或 Google Cloud Platform 的 App Engine）。
對于那些冒險進入無服務器的人來說，部署單元通常是容器鏡像或源代碼，然后平臺變成容器。
通過所有這些選項，關注我們的客戶如何采用容器技術是一件很有趣的事情。較小公司的 IT 戰略似乎對使用像我們這樣的解決方案提供商反應更快。
但更大的公司也在迎頭趕上。我們歡迎企業客戶認識到使用容器和其他云原生技術構建和交付軟件的好處的趨勢。
總的來說，我們可以說作為集裝箱的運輸解決方案正在成為常態。我們在 Adnovum 使用 Docker，
我們已經看到了對開發人員的具體好處。讓我們更多地看看這些好處。
2. 有限的曝光意味著更多的安全
針對容器平臺（與傳統操作系統包相對）也會帶來安全后果。例如，假設我們有一個完全托管的 Kubernetes 平臺。這意味著客戶的 IT 團隊負責以安全的方式配置和操作集群。在這些情況下，我們的開發人員可以將注意力集中在我們交付的應用程序上。得益于容器技術，我們可以進一步限制對各種攻擊和漏洞的暴露。
這與容器的基本理念相關：通過僅打包應用程序絕對必要的內容，您還可以減少可能的攻擊面。這可以通過從頭構建鏡像或選擇安全基礎鏡像來封裝您的可交付成果來實現。在Docker Hub上選擇安全基礎鏡像時，我們建議過濾由經過驗證的各方生成的容器鏡像：
也有完整的打包過程由您的開發工具處理的情況。我們在許多 Web 應用程序項目中使用 Spring Boot。Spring Boot 包含buildpacks，它可以以高效可靠的方式從您的 Web 應用程序構建 Docker OCI 映像。這減輕了開發人員尋找基本圖像的負擔，并減少了（但并未完全消除）進行各種優化的需要。
3. 容器支持多樣化的開發者環境
雖然 Adnovum 專門從事網絡和移動應用程序開發，但在這些范圍內，我們利用了廣泛的技術。支持此類異構環境可能很棘手。
想象一下，我們有一個在 Linux 上工作的 spring boot 開發人員，另一個在 Mac 上開發 Angular 前端。他們都依賴一組工具和依賴項在他們的機器上開發項目：
本地數據庫實例
第三方服務的測試替身（模擬等）
瀏覽器——有時有多個版本
開發人員工具，包括運行時和構建工具
根據我們的經驗，如果這些工具是本機安裝的，則很難跨多個操作系統支持這些工具。相反，我們嘗試將盡可能多的這些推送到容器中。這有助于我們調整開發人員的體驗并降低跨平臺的維護成本。
我們在 Windows 或 Mac 上工作的開發人員可以使用Docker Desktop，這不僅允許他們運行容器，還帶來了一些額外的功能（Docker Desktop 在 Linux 上也可用，或者您可以選擇直接使用 docker-engine）。例如，我們可以開箱即用地使用docker-compose，這意味著我們無需擔心確保人們可以在各種操作系統上安裝它。在許多此類工具上執行此操作可以為您的支持團隊顯著降低認知和成本。
如果您的開發人員需要同時跨多個項目工作，以這種方式外包您的依賴項也很有用。畢竟，沒有人喜歡安裝多個版本的數據庫、瀏覽器和工具。
我們通常可以將此技術應用于我們最近的項目，而對于技術早于 Docker 大規模采用的舊項目，我們仍有功課要做。
4. 容器有助于再現性
作為專業的軟件制造商，我們希望確保我們不僅為客戶提供出色的解決方案，而且如果有任何問題（功能或安全性），我們可以將問題追溯到產生工件的確切代碼更改——通常Web 應用程序的容器映像。最終，我們可能還需要重建所述工件的固定版本，這被證明是具有挑戰性的。這是因為構建環境也會隨著時間的推移而發展，不斷改變它們提供的兼容性窗口。
根據我們的經驗，自動化（特別是基礎架構即代碼）是為開發人員提供可靠且可擴展的構建基礎架構的關鍵。我們希望能夠在軟件或硬件出現故障時迅速重建環境，或者根據舊的配置參數提供基礎設施組件以進行調查。我們的策略是通過 Ansible 或 Terraform 等工具管理所有基礎設施，我們強烈建議工程師避免手動管理服務。我們的數據中心和云環境也是如此。
只要有可能，我們也更喜歡將服務作為容器運行，而不是將它們安裝為傳統的包。您會在Docker Hub上找到許多流行的基礎設施服務，例如NGINX和PostgreSQL。
我們嘗試推動密封構建，因為它們可以引導自己的依賴項，這大大減少了它們對特定 CI/CD 平臺提供的構建上下文中安裝的內容的依賴。從歷史上看，我們在支持依賴于機器上安裝的瀏覽器的自動化 UI 測試方面遇到了挑戰。隨著我們項目數量的增加，他們對瀏覽器版本的期望也有所不同。即使我們致力于自動化，這很快就變得難以支持。后來，我們在使用 Node.js 和 Java JDK 等工具時遇到了類似的挑戰，幾乎無法滿足需求。
最終，我們決定在我們的自動化構建中采用引導和容器，允許團隊定義他們的項目需要的 Chrome 或 Java 版本。在 CI/CD 管道期間，將在構建之前下載所需的版本依賴項，以防它尚未緩存。
不變性意味著我們的依賴關系和我們的產品，就此而言，在構建之后永遠不會改變。不幸的是，這并不是 Docker 標簽的工作方式。事實上，Docker 標簽在設計上是可變的，如果您習慣了SemVer ，一開始可能會感到困惑。
合乎邏輯的假設是，每當您（重新）構建自己的圖像時，都會使用相同的基礎圖像。實際上，標簽可以指向不同的圖像，以防有人決定在同一標簽下發布新圖像。他們這樣做可能出于多種原因：有時是出于必要，但也可能是出于惡意。
如果您想確保您將使用與以前完全相同的圖像，您可以開始通過它們的摘要來引用圖像。這同時是可用性和安全性的權衡。雖然使用摘要使您更接近真正可重現的構建，但這也意味著如果基礎鏡像的作者在同一標簽下發布新的鏡像版本，那么您的構建將不會使用最新版本。無論您傾向于哪一方，您都應該使用來自可信來源的基礎圖像，并將漏洞掃描引入您的管道。
結合不變性（及其所有挑戰）、自動化和密封構建，我們將能夠重建我們代碼的舊版本。您可能需要這樣做來重現錯誤——或者在發布修復的工件之前解決漏洞。
雖然我們仍然看到自己在實現可重復性的過程中有改進的機會，但在此過程中使用容器是我們將再次做出的決定。
本文鏈接：http://www.tebozhan.com/showinfo-119-2485-0.htmlDocker 促進企業軟件開發的四種方式
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號