.deb install (just like Unifi and Unifi-Video) without Docker. Maybe someday a repo

Submitted by -
Status: New

I'd like to see a .deb install and maybe someday a repo just like Unifi and Unifi-Video have.

 

I am not an expert on Docker and its pros and cons but there seems to be a lot of call for this type of install, the forum thread had 51 replies before it was locked, and there is some activity on github as well.  With all the activity I am surprised it isn't in Feature Requests so I thought I would add it.

 

https://community.ubnt.com/t5/UNMS-Ubiquiti-Network-Management/Non-Docker-Install/m-p/1810921#M25

https://github.com/Ubiquiti-App/UNMS/issues/40#issuecomment-311919234

 

For my personal feelings, part of it is just resistance to change, I am used to using .debs and the repos for Unifi and Unifi-Video and just don't want to change.  I also don't understand Docker well enough to feel comfortable deploying it.  I spent some time reading up on it and it is really simple in a lot of ways but some of the concerns people have are quite complicated.

Comments
by
on ‎01-09-2018 12:41 PM

I'm not sure that I agree with this idea. The whole point of Docker is having consistent, repeatable builds. This is possible because all of the underlying dependencies are included in the docker images; makes it much easier to control what version of various libraries, etc are used.

 

It's possible to specify dependency versions in DEB packages and the like, but what happens when it's not possible to fulfill that dependency because it's not available anymore, or is too up-to-date? You'd have to compile from source.

 

Additionally, using Docker lets them leverage the built-in clustering features, almost "for free". Application is split up into it's various functions and can be distributed over the cluster quite easily. Scaling functions becomes almost trivial: spin up a new instance and put it some place else. Need more capacity? Keep spinning up instances until capacity requirements are met. Need less capacity? Spin down instances.

 

We are hoping that UNMS will be more scalable. UBNT is working hard on that. Putting it into a single package is antithesis to how they are addressing the scaling problem (Docker).

 

Hopefully all that makes sense. Now that I have a few Docker deployments under my belt, I'm happy to answer a few questions to help my fellow UBNT-ers get started. PM me.

 

I appreciate that change is hard; but that's the name of the game in the IT industry: learn or die.

by
on ‎01-09-2018 02:02 PM

The problem isnt change... the problem is Docker is not compatible with our specific chosen primary virtualization technology along with 1000s of other people out there.

 

Sure Docker is the current buzz word, along with micro services and the cloud. But that does not mean its the right technology for everyone out there.

 

What about people with large ESXi infrastructures out there already? Do they now have to run 2 different virtualization technologies? 'well you can just spin a vm to run docker inside of that'  just listen to what you are saying.

 

by
on ‎01-14-2018 07:45 PM

One of the issues with relying on docker is using VPS servers that are on OpenVZ instead of KVM. OpenKVM is not (currently) running the 3+ linux kernel, with the exception of testing, which most VPS providers will not install.

 

Docker is great for many things, however there are many, many systems that will not run docker at all.

by
on ‎01-14-2018 11:08 PM

@Taubin LXC replaced OpenVZ when it was selected for inclusion to the main line kernel. KVM have been in the mainline kernel since 2.6.something.

 

While both offer ways to run ‘virtual machines’ on linux, they operate vasty differently. OpenVZ and LXC are containers. This to simplify things is a super chroot’ed environment running with the same kernel as the host (dom0). KVM on the other hand is full virtualization more akin to VMWare or VirtualBox. 

 

Docker itself is a form of LXC. The reason it cant run under LXC or OpenVZ is it can not (and should not) have full access to the kernel in ways that are required for doxker to work. While docker can run under KVM thats like say yes, I know, lets run a linux kernel inside a linux kernel so i can run Docker Containers. its a waste of system resources.

 

Now while Docker can have some compelling use cases, its not the one size fits all solution a lot of people would have you believe.

 

Something as simple as hey here’s the binaries and you require postgresql v.x and redis v.y would be much better. and its not like Ubnt doesnt understand debian/ubuntu packaging, they’ve been packaging unifi this way for how long now?

by
on ‎03-13-2018 12:48 PM

+1 ..rpm  (.deb at worst)

+1 managed repos

by
a month ago
Another vote for a .deb package!
by
a month ago
+1 deb install would be awesome, some manual installation would be even more awesome (seperate webserver, background service and/or sql storage
by
4 weeks ago
@SwK I see where you are coming from, but those with big ESXi virtualization infrastructure (like myself) are quite fine to spool up a VM and and Unifi, Unifi-Video, UNMS, UCRM all Dockerised under a single VM. Docker is not virtualization ,it's containerization, so it's not another virtualization technology -> https://i.stack.imgur.com/pG94I.png But, I think both should be made available, deb's for the traditionalists (one machine/vm per task) and larger support base. Docker for those that are happy to use it. and happy to run multiple applications that are containerized and running the exact version of underlying systems to support that application. So you'll get an upvote from me, even though docker support is more to my own taste.