2016-07-08 27 views
5

Một khách hàng mà tôi đang làm việc có đội tàu BeagleBones/Raspberry PI hoạt động tại các địa điểm của khách hàng. Các thiết bị này được cài đặt trên mạng cục bộ và phía sau tường lửa. Đối với kết nối SSH có một số tùy chọn nhưng chúng tôi vẫn đang đấu tranh với việc triển khai Phần mềm trên các thiết bị này. Hiện tại, chúng tôi không dựa vào công nghệ container, vì vậy Docker Cloud hoặc Resin.io không phải là một lựa chọn, nhưng resin.io trông rất hứa hẹn. Chúng tôi đang sử dụng AWS IoT để thu thập dữ liệu.Làm cách nào để triển khai phần mềm cho các thiết bị IoT (dựa trên Linux)?

Một số yêu cầu liên quan đến việc triển khai: máy chủ phần mềm

  • push -> Thiết bị
  • thiệu theo giai đoạn, triển khai đến một tỷ lệ phần trăm của thiết bị mà tăng theo thời gian
  • phần mềm rollback
  • thiết bị dự phòng
  • không có công nghệ chứa

Một số cách tiếp cận tốt để đạt được điều này là gì?

Trả lời

3

(Disclaimer: phát triển nhà truyền giáo tại resin.io đây).

Điều tốt là phần mềm không dựa vào thùng chứa, vẫn có thể đóng gói (trong khi nó không hoạt động theo cách khác). Các thùng chứa trong resin.io được sử dụng như một phương tiện để cung cấp phần mềm lên thiết bị và thực hiện các chiến lược cập nhật thú vị, hữu ích và an toàn, nếu không sẽ không thể thực hiện được hoặc sẽ khó thực hiện hơn. Ví dụ:

  • mã ứng dụng của bạn có lỗi (xảy ra!) Và sự cố. Điều đó có làm giảm toàn bộ thiết bị bao gồm cả mạng không? (trên các thùng chứa plastic.io giúp hạn chế thiệt hại, ứng dụng của bạn bị lỗi nhưng thiết bị trực tuyến và có thể được cập nhật)
  • bạn có phải cập nhật toàn bộ hình ảnh máy khi bạn có bản cập nhật ứng dụng không? (sử dụng các thùng chứa như thế này, những gì thay đổi trong mã ứng dụng của bạn được cập nhật, điều này dẫn đến rất ít lưu lượng dữ liệu hầu hết thời gian và thay đổi rất nhanh khi cần). ứng dụng mới và phiên bản cũ đang chạy chuyển tài nguyên sang phiên bản mới).

Đây không phải là để thuyết phục bạn về công nghệ container, chỉ cần nhấn mạnh rằng ứng dụng của bạn có được chứa hay không (rất có thể là không và sẽ ở lại như thế!), Không chọn các dịch vụ sử dụng công nghệ đó một phần của ngăn xếp của họ. Mọi dịch vụ đều cố gắng phân phối chức năng bạn cần theo bất kỳ cách nào cần thiết.

Đối với danh sách kiểm tra của bạn liên quan đến resin.io:

  • máy chủ phần mềm push -> Thiết bị: kiểm tra, git push resin master và mã của bạn là nhận được triển khai
  • thiệu theo giai đoạn, triển khai đến một tỷ lệ phần trăm của thiết bị tăng theo thời gian: không phải là một phần của bộ tính năng chung nhưng dễ thực hiện bằng cách sử dụng resin supervisor API: ví dụ như cập nhật khóa cho tất cả các thiết bị và bạn có thể chọn thiết bị nào sẽ được mở khóa và cập nhật. Vì tất cả đều thông qua API, nên tùy chỉnh này phù hợp với chiến lược triển khai ưa thích của bạn
  • phần mềm rollback: không phải là một phần của bộ tính năng chung, nhưng với git thật dễ dàng để đẩy lại các phiên bản trước. Một số chăm sóc cần phải được thực hiện để ghim phiên bản của các thư viện trong thiết lập của bạn để tạo ra một thiết lập có thể tái tạo, nhưng có thể thực hiện được trong thực tế.
  • thiết bị dự phòng: cài đặt thiết bị tự động, hoặc trích lập dự phòng thông qua một API/SDK/CLI có sẵn
  • không có công nghệ chứa: như đã đề cập ở trên, trong thực tế bạn không cần phải quan tâm quá nhiều những gì cách dịch vụ cung cấp phần mềm của bạn, vì nó không ảnh hưởng đến cách ứng dụng của bạn hoạt động, trong hầu hết các trường hợp.

Ngoài ra, bạn đề cập AWS IOT, có some documentation trên tích hợp resin.io với AWS, trong đó có một dự án ví dụ làm dự phòng thiết bị tự động của các thiết bị resin.io với AWS IOT (cắm trong một thiết bị, và nó sẽ tự động nhận được thông tin cho AWS IoT). Nó có thể là thứ mà bạn quan tâm.

Các vấn đề liên quan