we at croit.io do deliver our software as a ready to run docker container. In the last 2 years, no problem at all. Customers easily understand it and we got no complaints so far. Best decision ever :)
I'm glad to know that you and your customers have no problem with docker. But do they really have none? For example if you do have some close source, how did you convince customers that your image is secure/trust-worthy?
Don't do it. Customers hate it when you don't deliver clean operating system packages for the platform they run and they consider anything less unprofessional. I'm talking about enterprises and governmental institutions, not web companies.
Think of the consequences: while you might find "Docker" cool, by delivering your software as a "Docker" image, you are now forcing your would-be customers to come up with a "Docker" infrastructure just to be able to run your software. You would create an artificial dependency, because for OS packages they need neither additional software nor knowledge to install and run yours.
> you are now forcing your would-be customers to come up with a "Docker" infrastructure ...
The use of Docker in our scenario is more like a VM (system container) than buzzwords like micro-service/service mesh/container cluster (application container). (check [1] for more comparisons) ... so setting up an Docker infrastructure should be as easy as installing the docker package in one of their Linux box. At least that's our plan.
> You would create an artificial dependency ...
Actually we have been delivering the product, which contains many Linux native binaries/libraries, to many different customers for many years. They all have different working environments, ranging from RHEL 5.2 to the latest release of Ubuntu.
The solution we have been relying on is to build all the binaries as static-linked ones. To accomplish this, we have to maintain out-of-tree patches (some of the products are modified FOSS) to build scripts, which is a mess. So from our perspective, containerizing our product IS a direct way to eliminate the difficulty supporting varied environments and maintaining out-of-tree scripts at once.
We do add some dependency about docker, but we can provide a unified environment which removes all legacy dependencies. It should be a plus.
You should not need to build static libraries if you pick the oldest RHEL you can find among your customers: the GNU people claim that their libc is backwards-compatible, so your executables and libraries should work with the latest glibc.
Building static executables, while convenient, opens your customers to security risk: where rebuilding one shared object library would suffice, now they need entire new binaries. There is a reason why for example Solaris and illumos do not deliver static libraries. That's the reason why, to prevent one from doing exactly what you are doing for the reason I described.
I’m thinking about doing this for my optionally self hosted SaaS. I plan to provide docker images, jar files and maybe some OS packages for common distros but I am still undecided on where to host them as the core jar files are closed source.
The ultimate selling point for doing this is to make it as easy as possible to get started using the product. Docker images on docker hub are the lowest friction method to run the app. (I target developers so assuming they know docker is OK)
For a native application, the easiest way I've found is to statically link OpenCV. If you're using vcpkg to build your dependencies then OpenCV is already statically linked in Linux (I assume that's what you're using if you're considering Docker) and on Windows it's just a matter of choosing the static triplet.
Yeah, definitely. Anything with lots of dependencies is a good candidate for simplification of install and running if nothing else. An added benefit is that you don't have to deal with needing different system dependencies on different host OSes.
It doesn't appear that OpenCV would be difficult to dockerize. It looks like a few people have done it on GitHub already.
All the time. Docker containers are such a great distribution format. More specifically, typically a Dockerfile itself or Dockerfile along with the image as opposed to just the image (but sometimes just the image).
13 comments
[ 3.2 ms ] story [ 41.7 ms ] thread> ... no problem at all.
I'm glad to know that you and your customers have no problem with docker. But do they really have none? For example if you do have some close source, how did you convince customers that your image is secure/trust-worthy?
Think of the consequences: while you might find "Docker" cool, by delivering your software as a "Docker" image, you are now forcing your would-be customers to come up with a "Docker" infrastructure just to be able to run your software. You would create an artificial dependency, because for OS packages they need neither additional software nor knowledge to install and run yours.
> you are now forcing your would-be customers to come up with a "Docker" infrastructure ...
The use of Docker in our scenario is more like a VM (system container) than buzzwords like micro-service/service mesh/container cluster (application container). (check [1] for more comparisons) ... so setting up an Docker infrastructure should be as easy as installing the docker package in one of their Linux box. At least that's our plan.
> You would create an artificial dependency ...
Actually we have been delivering the product, which contains many Linux native binaries/libraries, to many different customers for many years. They all have different working environments, ranging from RHEL 5.2 to the latest release of Ubuntu.
The solution we have been relying on is to build all the binaries as static-linked ones. To accomplish this, we have to maintain out-of-tree patches (some of the products are modified FOSS) to build scripts, which is a mess. So from our perspective, containerizing our product IS a direct way to eliminate the difficulty supporting varied environments and maintaining out-of-tree scripts at once.
We do add some dependency about docker, but we can provide a unified environment which removes all legacy dependencies. It should be a plus.
[1] https://containerjournal.com/2016/07/25/system-containers-vs...
Building static executables, while convenient, opens your customers to security risk: where rebuilding one shared object library would suffice, now they need entire new binaries. There is a reason why for example Solaris and illumos do not deliver static libraries. That's the reason why, to prevent one from doing exactly what you are doing for the reason I described.
The ultimate selling point for doing this is to make it as easy as possible to get started using the product. Docker images on docker hub are the lowest friction method to run the app. (I target developers so assuming they know docker is OK)
It doesn't appear that OpenCV would be difficult to dockerize. It looks like a few people have done it on GitHub already.
And convince them of what exactly?