軟件初創公司Weaveworks發佈了開源項目Weave Ignite以慶祝成立五週年。該項目被稱爲“帶有容器UX、受GitOps管理的虛擬機（VM）”。這個新穎的軟件使用了Firecracker，Firecracker是支持AWS Lambda的AWS開源項目。InfoQ採訪了項目背後的團隊以瞭解更多信息。
在一篇關於Weave Ignite的博文中，Weaveworks的CEO Alexis Richardson解釋了其工作原理。
通過吸收開發人員來自於容器的經驗，Ignite使Firecracker變得易於使用。藉助Ignite，我們可以選擇希望作爲VM運行、符合OCI標準的鏡像（Docker鏡像），然後，執行ignite run而不是docker run。無需使用特定於VM的工具來構建.vdi、.vmdk或.qcow2鏡像，只需從任何我們所需的基礎鏡像進行docker構建，並添加我們偏愛的內容。
當我們利用ignite run來運行OCI鏡像時，Firecracker使用默認的4.19 Linux內核，在c.125微秒啓動一個新的VM 。
Richardson提出了一些用例，包括爲測試或臨時工作負載快速啓動很多VM、同時啓動完整堆棧和在輕量級VM中運行遺留應用程序。
亞馬遜於去年11月發佈了開源虛擬化技術Firecracker。記者Matt Asay對此評論道，Weaveworks在此以Ignite爲例，展示了開源在理想情況下應該怎樣做。
儘管該技術本身看起來超級酷，但是，其中還有一些非常棒的東西AWS並沒有做。他們構建了Firecracker並把它開源，以便像@weaveworks的其他開發人員可以以此爲基礎構建自己的東西。開源實際上就是這麼幹的。
爲了證明Weave Ignite可以用在任何地方，Walmart Labs的一位工程師寫了一篇博文來演示如何讓Ignite在谷歌雲上工作。
爲了瞭解更多關於Weave Ignite的細節，InfoQ聯繫了Weaveworks並採訪了CEO Alexis Richardson和Ignite的創建者 Lucas Käldström。
InfoQ：Ignite是否創建了一個“真正的”VM，可以存儲持久狀態、託管它自己的容器等等？這個和用傳統的虛擬機管理程序創建的VM看起來不一樣嗎？
Weaveworks：是的，Ignite創建了一個真正的VM。但是，和“傳統的”VM略有不同，比如：
- Firecracker是故意設計成的一個最小的KVM實現
- 我們使用來自OCI鏡像（容器行業標準）的根文件系統，而不是使用像“.iso”文件這樣的“可引導”磁盤以及像Packer這樣的支持工具，它們產生特定於供應商的“.vdi”、“.vmdk”文件。
- Ignite支持聲明性配置，並通過GitOps運維
除此之外，請查看我們的FAQ.md
InfoQ：能否給不熟悉Firecracker的人做個介紹？
Weaveworks：Firecracker是Linux的最小虛擬化實現（使用KVM）。
Firecracker是爲無服務器工作負載的新時代而打造，因此，它的設計針對安全和速度進行了優化。換句話說，Firecracker在給定Linux內核和硬盤的情況下啓動並監控VM 。
來自https://firecracker-microvm.github.io/: Firecracker實現了虛擬機監控器（VMM），利用基於Linux內核的虛擬機（Kernel-based Virtual Machine，簡稱KVM）來創建和管理微虛擬機（microVM）。Firecracker採用簡約設計。 它不包含不必要的設備和遊客功能，以減少每個微VM的內存佔用和攻擊範圍。 這可以提高安全性，縮短啓動時間並提高硬件利用率。
InfoQ：如何吸收“容器開發人員經驗”使Ignite比原始的Firecracker更容易使用？
Weaveworks：Ignite與Firecracker的關係，就像Docker跟OCI容器運行時實現的runC的關係一樣。
與runC一樣，Firecracker旨在作爲低級組件。今天，如果我們運行一個容器，我們不會直接使用runC，而是使用更高級的工具，如Docker、containerd 或者Kubernetes。同樣，除非我們是Linux內核或KVM開發人員，我們很可能難以找到如何有效正確使用Firecracker的方法。通過從容器中獲得DX，並和像Docker和OCI鏡像規範集成，Ignite給用戶提供了運行VM就像運行容器一樣的體驗，這比要求用戶創建虛擬塊設備和以太網接口要簡單幾個數量級。
InfoQ：需要哪些組件纔可以在我們的機器上使用Ignite？
Weaveworks：基本上Linux上的Docker即可，請參看說明。
具體來說：首先，在啓用KVM的情況下運行Linux。這是基本要求，因爲Firecracker是設計實現了KVM，只有Linux有這個功能。其次，安裝一個容器運行時，用於和Ignite集成，像Docker（目前唯一支持的運行時，更多的會很快實現）。下載Ignite二進制文件。就這些！
InfoQ：GitOps是基礎設施即代碼的進化嗎？您能否告訴我們一點關於GitOps是什麼的知識嗎？
Weaveworks：GitOps是一種自動化Kubernetes集羣管理和應用程序交付的方法。很多人理解並使用一些GitOps概念，但是，很少有人能完全發揮它的作用。我們能對運營做到最深刻的改進就是完全意識到它。
在GitOps，我們通過不斷觀察運行時狀態並用期望的狀態（作爲聲明配置存儲的）與之比較來管理整個實時系統。如果觀察到的狀態偏離了期望的狀態，那麼，我們使用如Kubernetes、Flux和Flagger的協調器把系統收斂回正確的狀態，並且如果我們無法收斂，那麼就發出警報。因此，我們可以直接從配置中配置和管理集羣和應用程序，並且，根據策略，可以100%地自動進行配置和管理。藉助Weave Ignite，現在我們也有了第一個可以從配置進行管理的VM技術，就跟Kubernetes一樣。
Weave產品使用GitOps以創建集羣，進行上下擴展、升級和修補，還管理一些D/R。我們可以做集羣的自動化、管理大量集羣、模板和配置。其次，我們可以用自動化的持續應用程序部署來替換部署腳本。我們可以執行漸進式交付，如金絲雀發佈、帶功能開頭的A/B測試，以及控制策略。所有這些都適用任何CI工具、鏡像註冊表和Git存儲庫。
是的，GitOps是DevOps和IaC的進化，但是有重要的改進。有哪些改變？GitOps無疑把基於配置的管理最初設想發揮到了極致：
- 我們管理整個運行軟件棧，包括應用程序、服務、網格、金絲雀發佈，……和盒子，而不是供應已安裝軟件的“盒子”。
- 我們部署不可變容器和配置文件。CI和Dev從不直接觸及運行時，它們通過不變性防火牆進行。
- 我們不斷地檢查系統是否偏移。我們有一個完整的描述來進行比較。
- 所有對運行系統的改變，無論有多麼細小，都是由配置更改驅動的。
- 相反，我們不使用多個接口，即kubectl、ssh、UIs、CLIs或者像OpenShift這樣的外觀聚合。
- GitOps必須使用Git+編排，不能是Git+CI腳本。我們不把CI腳本用於CD，因爲這些會讓我們處於不確定狀態。我們手動或用基於CI的變化更新Git，但是，我們不讓CI協調部署，因爲只有Kubernetes和其他運行時協調器可以強制實現收斂性和原子性。
- 我們還用這種方式管理漸進式交付和功能開關，請點擊這裏參看YAML。
- 整個環境包括：非程序化的資源，即playbooks和控制面板。當我們更新應用程序時，也希望在單一版本控制機制下更新監控、警報和運維文檔。
- 但是，我們不希望開發人員編寫配置文件，我們使用高級編程語言（如Typescript）從代碼安全地生成YAML，併爲集羣、管道和基於策略的運維行動管理模板。與基於CI的腳本模式不同，這個可以擴展。
InfoQ：您是否需要向Firecracker項目提交任何上游更改以讓Ignite工作？
Weaveworks：不，不需要：）
InfoQ：您提出一些可能的用例，包括Weaveworks如何將其用於自己的集羣管理產品。哪個開發人員用例對你最有吸引力？
Weavework：要選一個的話，是測試。想象一下，我們是否可以以零成本爲k8s集羣啓動測試、CI和其他版本的開發。也就是說，在Ignite上快速啓動安全的Kubernetes集羣，讓一些案例變得簡單。可以參看我們的入門博文。我們只需要運行幾次“ignite run”，然後在那些機器上用我們首選的Kubernetes安裝程序安裝Kubernetes，例如事實上的社區構建工具kubeadm（Weaveworks從一開始就一直以開源的方式開發它），還有供企業使用的Weaveworks Kubernetes平臺。最終：整個GitOps數據中心能夠使用現代雲原生工具在任何地方運行。
原文鏈接：
Weaveworks Releases Ignite, AWS Firecracker-Powered Software for Running Containers as VMs