(免責聲明:在resin.io開發佈道者這裏)。
好的一點是,那些不依賴容器的軟件仍然可以打包(儘管它不會以其他方式工作)。 resin.io中的容器被用作將軟件傳送到設備上的手段,並實施有趣,實用和安全的更新策略,否則這些策略將不可能或難以實現。例如:
- 你的應用程序代碼有一個錯誤(發生!)和崩潰。這是否會取消包括網絡在內的整個設備? (在resin.io容器有助於限制損壞,您的應用程序崩潰但該設備處於聯機狀態並且可以更新)
- 您是否必須在應用程序更新時更新整個機器映像? (使用這樣的容器,更新應用程序代碼中的更改內容,這會導致大多數時間內的數據流量非常小,並且在需要時會非常快速地更改)
- 使用這樣的容器可以讓您幾乎實現零宕機升級(啓動新應用程序和舊運行版本將資源移交給新的應用程序)。
這是不是讓你信服的集裝箱高科技,只是強調指出,無論是否自己的應用程序是以貨櫃(最有可能它不併會留這樣的!),不要選擇對使用該技術作爲服務他們的堆棧的一部分。每項服務都會嘗試以任何必要的方式提供您所需的功能。
至於與問候你的清單,以resin.io:
- 推送軟件的服務器 - >設備:檢查,
git push resin master
和你的代碼是越來越部署
- 分階段發佈,推出到設備的百分比這會隨着時間的推移而增加:不是通用功能集的一部分,但使用resin supervisor API可以輕鬆實現:例如鎖定所有設備的更新,並且您可以選擇哪些設備將被解鎖和更新。由於它全部通過API,所以可根據您的首選部署策略進行定製
- 回滾軟件:不屬於通用功能集(尚未),但是使用git可輕鬆重新推送以前的版本。需要注意在設置中固定庫的版本以產生可重複的設置,但在實踐中可行。
- 設備供應:自動設備設置,或配置通過API/SDK/CLI可用
- 沒有容器技術:在實踐中上面提到的,你不需要太在意什麼方式服務交付您的軟件,因爲它不會影響您的應用程序的行爲,在大多數情況下。
另外,你提到的AWS物聯網,有上集成resin.io與AWS,其中包括一個示例項目中的設備做resin.io設備的自動設備配置與AWS物聯網(Plug公司some documentation,並自動獲取證書適用於AWS IoT)。這可能是你感興趣的東西。