10 March 2018 / Last updated: 12 Mar 2018

Multicontainer on resin.io is here!

Execution time:
On behalf of everyone on the resin.io team, I couldn’t be more excited to announce that resin.io now supports running multiple containers. This has been the #1 requested feature over the last year, by resin.io users of every shape and size. Makers, startups, industrials and global enterprises agree: multicontainer multiplies the value of the resin.io platform.
Thinking back to the earliest days of resin.io, when we had to explain the need for containers on connected devices at all, we felt that the ability to have user code in a container was a huge step forward, bringing a totally new paradigm for virtualization. Even we, however, struggled to think far enough ahead to the day when people would be expecting to build microservice architectures on devices that can fit in the palm of our hands.
Now, beginning with resinOS v2.12.0, we're able to support a whole new set of application structures and development workflows, providing a more modular and secure approach to application management. Developers can split applications into multiple services, packaging each with the operating environment and tools it needs to run, while simultaneously ensuring access to system resources is limited to the minimum necessary. Because each service can be updated independently, larger applications can be developed and maintained by separate teams, each free to work in a way that best supports their service.
Starting today, resinOS v2.12.0 is available for the Raspberry Pi 3 and the Intel NUC. More device support will be rolled out in the coming weeks.
The changes we've made to support this amount to much more than a feature release—we've completely revamped the product, from UI to server to device. To say we’re incredibly excited would be a vast understatement!
In the most basic terms, here is what has changed: for supported devices (those running resinOS v2.12.0 and provisioned to a microservices or starter application), you can push a project with a docker-compose.yml file instead of just a Dockerfile. The resin.io builder will recognize the file and build multiple containers, store those builds appropriately, and inform the devices of the set of containers they should download. Then, the devices will download and run the containers, setting up volumes, bind mounts, and virtualized networks as specified in the docker-compose.yml file.
While this is happening, you can follow the progress from our all-new dashboard, which includes a number of features to help you visualize and manage the containers on your devices:
  • Each release in the release logs now has its own page, with detailed per-service logs and the top-level docker-compose.yml used to define the build.
  • Device logs now have filtering and views, making it easy to separate logs by service. The retention period of logs has also been increased.
  • The fleet and device configuration pages have been redesigned, with default values pre-populated and toggles for enabling some features.
  • The fleet and device environment variable pages have been redesigned, making it easier to override fleet-wide settings.
While we're eagerly anticipating your multicontainer applications, we've also invested a lot of effort to ensure that if you want to ignore this capability, you can continue to do exactly what you were doing yesterday. Any code that ran on resin.io before this release will still seamlessly build and run on the multicontainer instance—the only changes you'll notice are in the new and improved dashboard interface. Even the old versions of our API will continue working, utilizing our internal translation layers that convert legacy API requests to the new data model and the new model’s responses to the legacy structure.

Getting Started with Multicontainer

To help you get started, we've put together together a simple multicontainer application, composed of a static site server, a websocket server, and a proxy. When you push this application to our build servers, you'll notice a slight change:
The build logs now show the status of each service defined in your docker-compose.yml file, as well as how long each took to build. Build logs for all releases are also available in the dashboard, so you don't have to worry about saving any information from your terminal. To see a list of your releases, click the Releases tab to the left of the application summary page:
Clicking on an individual release will bring up a page full of information about that build, including build times, the docker-compose.yml file used, and individual build logs for each service:
If you go to the device summary page, you'll notice a few more big changes:
You can now see a list of the services running on your device, with the option to start, stop, and restart each one individually. The Logs window now supports filters and views, allowing you to easily separate logs by service. The web terminal is also multicontainer flavored, giving you the option to SSH into any running service or the host OS.
With this basic example and our detailed documentation, you should have everything you need to build your own multicontainer applications. But before you get started, there are a few things worth noting:
  • Resin.io multicontainer functionality only supports a subset of the Docker Compose v2.1 fields. A full list of supported and unsupported fields can be found in our device supervisor documentation.
  • Prior to multicontainer support, environment variables were set at the application and device level. Now, environment variables are set per service, with the option to apply the variable for that service on a single device or across the fleet. Even for single container applications, when you add a service variable it will need to be associated with a service name.
  • At the moment, resin local push will not work for multicontainer applications. The recommended development workflow is to put the device in local mode and use the Docker Compose remote API.

Application Types and Pricing

With the release of multicontainer, we've also introduced the concept of application types and updated our pricing plans accordingly. An application's type defines the capabilities and per-device pricing for that application. For supported devices, new applications can be created as three different types:
  • Microservices: full-featured, allowing you to run multiple containers and set up a public URL for each of your devices. This application type is only available for paid plans.
  • Starter: all the features of microservices applications, but you are limited to 10 total devices across all starter applications. Starter applications are free of charge and available to all users.
  • Essentials: allows you to run a single container and with no public device URLs. These applications are only an option on paid plans.
The Prototype plan includes up to 20 devices, in addition to your 10 free starter devices. Pilot and Production plans include 50 and 100 devices, respectively, with additional devices available for $1.50 if a microservices type, and $1 if an essentials type. Devices included in the various plans can be either microservices or essentials type devices, depending on your use case. Applications already running on resin.io will continue to be billed as they are today, with access to all the same features they had yesterday, and with the option to upgrade to one of the new application types at any time.
We can’t wait to see what you’ll build with multicontainer applications on resin.io. If you have any questions or feedback, please let us know in the forums!
by Alexandros MarinosFounder/CEO, balena

Share this post