Docker

[Lazybones]

Well as I am digging into my new Synology box Docker has become a thing for me. While our web team uses it for good reasons I had not used it personally for infrastructure or home use.

As it turns out Docker makes installing 3rd Party apps on an x86 Synology NAS much easier and avoids a few pit falls of NATIVE packages.

So far I have my unifi controller, transmission and plexpy running in containers and after the initial head space trip of how storage / users and variables map to a container it began to get easier.

In fact now that I have played with it, it seems like a much better way to run a lot of crufty (random set of SPECIFIC dependency) linux based projects.

Lighter than a full VM but not quite an app. Seems like an OK balance to run on a NAS, ram use is also very reasonable so far for the packages I am running.

[Mr. Analog]

Got any handy links on it?

[Lazybones]

Got any handy links on it?

Docker for Synology ? Or Docker in general?

On Synology I believe it is only available on x86 based units. So far I have been able to set things up completely from the GUI accept for getting the user and group IDs for permission mapping.

I have been following a lot of random forum posts so not just one guide.

[Melbosa]

I've been using Docker for a couple of things on my side.  Its very slick but also has some downfalls.  Take the UniFi Controller - you have to manually work with your units to get them to register properly as autodiscover sometimes doesn't work well.  But yes they are fast to setup and get using right away for the most part.

[Tom]

Docker has its uses. It shines for automated deployments where you setup configuration, and want to re-spin over and over.

Docker also has its quirks. Like its port forwarding. It actually runs a single process/thread per forwarded port to relay packets between the host and docker instance.

It's registry setup is also a bit quirky. It compresses and decompresses pushed/pulled images on the fly in a single thread per push/pull. So a large push can and will take a long time while a single gzip thread chunks away. Best way around that is having your Dockerfile do things in MANY steps, instead of compressing as many as possible into a single step (which seems to be recommended for other reasons).

I and my client use GitLab to host our git repos, and it uses docker to manage it's CI build hosts. It makes total sense to use it for something like that. I've become somewhat familiar with docker now because of that. Oh, and my client is moving to Docker for a lot of its internal and public facing services. Again, makes total sense for how they want to deploy and manage things. You set up some centralised configuration, and can spin up a new instance to either update or scale out a given service.

append: I'm probably going to start centralising my configuration with some centralised config tool, so I can save all my config, and just spin up new vms and docker instances when necessary.

[Lazybones]

I've been using Docker for a couple of things on my side.  Its very slick but also has some downfalls.  Take the UniFi Controller - you have to manually work with your units to get them to register properly as autodiscover sometimes doesn't work well.  But yes they are fast to setup and get using right away for the most part.

For my home environment I set the DHCP scope option to locate the Unifi instance..

I exported my config with the web UI on my old vm, then imported it into the docker, c.. Rebooted each AP by cutting power, they came back up registered to the new docker.

[Melbosa]

I've been using Docker for a couple of things on my side.  Its very slick but also has some downfalls.  Take the UniFi Controller - you have to manually work with your units to get them to register properly as autodiscover sometimes doesn't work well.  But yes they are fast to setup and get using right away for the most part.

For my home environment I set the DHCP scope option to locate the Unifi instance..

I exported my config with the web UI on my old vm, then imported it into the docker, c.. Rebooted each AP by cutting power, they came back up registered to the new docker.

Yeah we tried that at Frag this year but the AC Lites we had required me to execute a command on them through SSH once before they would properly provision - my docker controller would see them but they never would complete until I did so.  It was in the documentation of the docker release the commands I needed.

[Lazybones]

but the AC Lites we had required me to execute a command on them through SSH once before they would properly provision

Where they previously registered to a different controller then you where attempting to register them to a new controller? If so that would make sense as I believe they need to be released.. In my case the DB was backed up and restored from the original controller so it should have had all of the correct keys.
I have have heard of some flakiness however and if they had been in storage a long time who knows what firmware they where running.

[Melbosa]

but the AC Lites we had required me to execute a command on them through SSH once before they would properly provision

Where they previously registered to a different controller then you where attempting to register them to a new controller? If so that would make sense as I believe they need to be released.. In my case the DB was backed up and restored from the original controller so it should have had all of the correct keys.
I have have heard of some flakiness however and if they had been in storage a long time who knows what firmware they where running.

They were factory reset so never registered to anything as far as they were concerned.  So your backup and restored DB probably did the trick as they were already registered and provisioned to your setup.