
Ask HN: Shipping products to customers in Docker container - qlk1123
Have you ever delivered software products in the form of container?  How did you convince your customer?
======
Annatar
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.

~~~
qlk1123
Thanks for the warning. Really appreciate that.

> 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...](https://containerjournal.com/2016/07/25/system-containers-vs-
application-containers-difference-matter/)

~~~
Annatar
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.

------
vbsteven
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)

------
Mave83
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 :)

~~~
qlk1123
Cool! Just checked your page, it's interesting.

> ... 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?

------
shoo
if you do it, consider releasing the image in a container format that can be
executed by runtimes apart from docker (e.g.
[https://developers.redhat.com/blog/2019/02/21/podman-and-
bui...](https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-
docker-users) )

------
tedmiston
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).

And convince them of what exactly?

~~~
qlk1123
Changing the way both sides used to, the benefit of changing from package to
image release, little downsides, etc.

------
mrfusion
Would this be a good way to ship an opencv based product? I’m really at a loss
how to let the client install it without a lot of technical steps.

~~~
quietbritishjim
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.

------
streetcat1
you might want to create a private registry within the client prem, and
export/import the container.

