一千萬個為什麽

搜索

處理分發給客戶的硬件上的操作系統和軟件維護/更新



在過去的幾周裏,我試圖找到一個解決方案,假設其他人有類似的需求並記錄他的解決方案,但我所有的搜索都不成功。 所以現在我只想問一個問題,希望有足夠的經驗在這個領域能夠給我指導,這樣我就不會錯過太多次。

簡化的情況:

比方說,我已經為我的客戶編寫了一個帶有Web界面和REST API的軟件,這些軟件絕對必須在客戶的本地網絡中運行,並將作為“黑匣子”硬件設備提供給他們。除此之外,我基本上將它作為“服務”提供給他們,這意味著維護和更新是我的責任。我帶著一個小型無頭預裝和預配置的PC來到他們身邊,將它連接到他們的網絡,只進行網絡配置,然後我就完成了。該設備已準備好與客戶網絡中運行的任何其他軟件組件進行通信。

為了更精確一些,我的軟件產品可以在Linux(也可以是Windows)下運行,也應該可以將其構建為Docker容器(如果這對於所提議的解決方案有任何意義,盡管我的Docker專有技術仍然存在有限)。我希望在這些設備上設置CentOS 7。

現在我面臨兩個挑戰:

  • 保持CentOS軟件包最新
  • 使我的軟件包保持最新狀態

為了防止所有客戶同時遇到同樣的問題,我希望完全控制哪些客戶在設備上的哪個時間點更新哪些包(基本上是分階段展示)。 關於我自己的軟件包,這可能會以不同的更新渠道(測試版,穩定版等)形式出現。 理想情況下,我也能夠從設備獲取配置文件和將其他文件推送到設備。 如果我能夠使用現有的解決方案而不是滾動我自己的機制,那將是非常好的。

此外,該解決方案應擴展到數百甚至數千客戶。

我到現在為止的想法:

太空行Puppet 等。

用於管理CentOS系統。但是,我不知道是否有人擅長管理沒有在單個公司網絡中運行的機器。

RPM packaging my software component or My software as a Docker container

我不知道哪個更新更好。 Docker可能是過度殺傷性的,它只是單個機器上的每個客戶的單個軟件應用程序,我只認為它會緩解應用程序更新。也許一個RPM軟件包會更可取,這樣我可以將更新頻道作為不同的RPM存儲庫處理,並使用Spacewalk/Puppet自行控制更新。

OpenELEC/LibreELEC JeOS 方法

我不知道這叫做什麽,或者是否有預先構建的解決方案,但我首次遇到了OpenELEC。必要的是,整個操作系統和應用程序都打包在一個安裝在目標機器上的不可修改和可更新的(內核)映像中,並且有一個用於用戶和本地配置數據的獨立分區。

我知道這是一個相當大的問題,但任何指針都會非常感激。

轉載註明原文: 處理分發給客戶的硬件上的操作系統和軟件維護/更新

一共有 2 個回答:

紅帽曾將品牌Spacewalk列為“紅帽衛星5”,並且決定取消它,從頭開始構建一個新的工具集。然後,紅帽在 Katello插件上將他們現在的品牌標識為“Red Hat Satellite 6”。用於工頭

另外,Foreman也有Docker,Puppet和其他幾個相關系統的插件。

但說實話,這個系統有點粗糙,需要一些拋光。我常常碰到蟲子,不得不花費相當多的時間使所有的部分一起工作 - 盡管它仍然非常酷且強大。

但是,您可能會遇到任何嚴格安全要求的客戶端網絡問題。在我的雇主,我們不允許直接連接到互聯網,幾乎無法使用需要嚴格安全審查的代理,然後我們仍然非常有限,因此可能需要考慮更新模型 - 您將對這些類型的客戶來說是不可行的。另一方面,這是“As-a-service”模式的優勢的一部分。您不必擔心或維護它,因此您將以客戶身份揀選更多中小型企業。

我可以在這裏提供一些個人經驗。我曾在一家有相同需求的公司工作。該產品是BeagleBone(如Arduino或Raspberry Pi),運行我們的軟件並將數據發回給我們的SaaS。它必須安裝在客戶網絡中,並成為一個他們沒有碰到的小黑盒子。

當我走進這家公司時,系統的管理是一場噩夢。網絡是一場噩夢。操作系統更新,保持在線狀態,發布新版本的軟件等......這是一場噩夢。

我們最終選擇的路徑最終運行得非常好:整個應用程序和支持包都作為Docker容器提供。這使我們能夠輕松地發布應用程序代碼變更和任何支持軟件(ffmpg,gcc等)的控制版本。

在抽象應用程序的情況下,這只會使操作系統盡可能少。我們需要的只是一個可以運行碼頭工人的簡單操作系統。我們的一位低級工程師實際上制作了我們自己的Debian內部分支(如果我記得的話),並且我們將其直接嵌入到設備中。

我們已與所有客戶簽訂了服務合同,每年為這些機器提供服務,因此當我們的現場技術人員到現場時,程序是使用最新嵌入式操作系統附帶的新硬件更換整個設備。我們不必為了運行Docker而進行許多操作系統更改,因此通常不需要更換時間。但是,在程序之外,無論是緊急服務呼叫還是年度維護,我們總是交換硬件。

我不能說這是否是一種標準方法,但是它確實對我們有用,並且是一種拯救生命的方法。這聽起來像你將操作系統作為不可變圖像發布的想法是一致的。

Edit: When I left, we were still using home grown bash scripts to automate the Docker container deployments, but the idea was to move toward a config management tool (Like Chef, Salt, or Ansible). The basic premise is that you have a private Docker registry somewhere, then on the devices you would simply run a couple commands:

docker pull my-private-registry/my-custom-image:latest
docker run my-custom-image:latest

如果您打算始終使用“最新”標簽,則可以讓您的設備隨附一個cronjob,然後始終關閉其本地運行的Docker容器,並在計劃期間每周重新提取“最新”標簽維護窗口。