Hello, thanks for such a great platform.
I’ve got Mender up and running, however the next step is to move it to production.
Various places I’m intending to deploy this do not allow Docker because of enterprise policies, so I’m wondering if there are instructions anywhere on how to deploy Mender without running it in Docker containers?
Thanks in advance.
I would be interested in this also, as I prefer not to use docker.
Unfortunately this not something that we provide, and the maintenance burden alone of something like this would be hard to justify without getting something in return 
Though this is something that we could help out with trough our Mender Enterprise offering.
ok, so if a group of us were to write up the documentation and work on packaging where needed, you’d support that?
Community contributions are always welcome, and we are always interested in enabling people interested in contributing to the project.
OK, cool, thanks!
So I’m not going to commit to timelines here, but it’s definitely something I’m interested in doing, and if anyone else wants to join me then they’d be more than welcome!
I am curious, can you elaborate on why one would not use Docker? I can understand that some companies have enterprise policies why might disallow that, but are there other reasons?
I’ve been using Docker in production for nearly 6 years now, and I’m still not convinced it’s production ready!
The spats within the community that lead to the name/rename change, instability and breaking changes between minor releases, and the fact that I can do everything that Docker does with other tools mean that I’m fairly prejudiced against it (see my personal blog post from a few years ago at https://doics.co/2015/06/23/containers-are-the-new-norton-ghost/ ).
I fully understand why it’s loved by developers, and I get why so many people want to run it as their production environment, but as the issue is usually that the Operations team are either non-existent or set in their ways (14 days to spin up a virtual machine at one place I worked!), my focus for the past 10 years as a DevOps Consultant/Engineer has been to get the Ops teams to work along side the developers rather than adopting shiny new tooling.
My particular case at the moment is the enterprise policy issue, but where I can, I still try and avoid Docker, preferring to provide developers with CI/CD pipelines that can be run on their workstations as well or have such a short return time on testing that they could write a java application on a budget chromebook… 
(oh, and if I do have to run Docker, I’m going to use Hashicorp’s Nomad to orchestrate it, because then I get secrets management from Vault and service discovery from Consul without having to do anything at all!)
Thanks for the detailed response.
This is not really my area, as I focus mostly on embedded stuff but always nice to learn new things and get insights from people in different areas.
No worries, I’m the opposite - my entire career so far has been Systems Administration/DevOps Consultancy, IoT has come into it in the past couple of years.
We now run an IoT Managed Service Provider for Farming, and we’re looking to use Mender to manage our LoRaWAN gateways (which are mainly Pi-based but some run OpenWRT) so I’m learning loads about embedded systems and development at the moment.
My hope is that I can get to a point where we go to a website, put in some details about the gateway, and it talks to Mender, spits out an image to flash to the Gateway and registers it with our LoRaWAN infrastructure at the same time. At that point it will be as simple as flashing the image, taking the gateway to site, powering it on, and watch the data stream in!
I would have to totally agree with these comments. As our experiences also with Docker in enterprise production has been far from satisfactory and hence scrapped as an enterprise policy in favour of other containerized solutions.
Just my 2 cents: maybe this project can be interested for you lora-gateway-os
Yup, that’s exactly the plan - our entire infrastructure runs on Brocaar’s code, including the LoRa Gateways, but we want to add more things to that image such as a monitoring client and VPN connectivity.
It was Brocaar that pointed us in the direction of Mender, and we’re really glad he did!
Seems a timely topic with RHEL 8 dropping docker from their repos in favour of Buildah and Podman
[https://www.redhat.com/en/blog/red-hat-enterprise-linux-8-beta-new-set-container-tools](https://www.redhat.com/en/blog/red-hat-enterprise-linux-8-beta-new-set-container-tools
As podman can use docker images, and has comparable functionality as docker-compose, maybe we could add instructions/configs to support this alternative to docker
Interesting, if you try out let us know.
I mean according to the blog post you posted it should be alias docker=podman and then it should work
I’ll be looking into this at some point in the future when I re-setup a production server
This is a blocker for one of my clients and for all internal projects.
On our internal projects, Docker is banned from everything inside the edge firewall due to ongoing major security issues. Docker itself is ok, but images pulled from hub.docker.com are completely unverifiable, often out-of-date and missing security patches and based on inappropriate Linux distributions.
Let’s take for example mender-api-gateway-docker with the Dockerfile defined at https://github.com/mendersoftware/mender-api-gateway-docker/blob/master/Dockerfile. As you’re pulling a very specific version of the openresty image (1.13.6.2-0-alpine) you’re getting something that was built over a year ago. That’s no security patches on the front-end nginx for a full year - that really worries me and is why hub.docker.io images of all forms are banned from inside our firewall.
My ideal deployment case is all microservices within Mender Server running on Ubuntu Server LTS containers within either Docker (if built from Dockerfiles locally, regularly and with no use of any upstream images from hub.docker.com) or LXD with automatic updates enabled on a nightly basis so that security updates are applied within 24 hours of release.
Due to the tight integration with docker here, and specifically with the way DNS works within Docker, we’re really not left with any other options than using Docker and docker-compose as provided in the integration repository. The hostnames seem to be hardcoded in the various microservices implemented in golang and nodejs so this isn’t something I’m in a position to pull apart. So we’ll be restricted to deploying Mender on third-party cloud services outside of our normal infrastructure at greatly increased administrative burden.
Handling certificates within the mender-api-gateway openresty instance also breaks our policies - we have a system in place using letsencrypt with automated certificate renewals and isolated nginx proxies handling SSL termination. At the very least we need the option to deploy mender-api-gateway in a HTTP-only mode with SSL termination handled in a separate proxy.
Had a quick play with this. if i uninstall docker and alias docker to podman then docker-compose fails detecting the docker engine is not running. Had a quick play with podman-compose which is currently in development and designed to be a drop in replacement for docker-compose. But hit a couple of bugs when used with the mender run script which has been reported upstream to them. Looks promising. https://github.com/containers/podman-compose
Theres also the option to use Kompose to convert docker-compose yaml files to files compatible to use with kubernetes, but that’s an adventure for another day as a bit more involved. https://github.com/kubernetes/kompose/blob/master/docs/getting-started.md