patterndockerModerate
Are there any drawbacks of using a deb package as if it was a container to deploy an application?
Viewed 0 times
debpackagecontainerapplicationareanydeployusingwasthere
Problem
My team is currently trying to decide if we should deploy our Nodejs app as a deb package instead of trying to run it in a container such as Docker.
I got this idea from reading this blog here which makes some good arguments for using a deb package for a pre-existing python application. The main point from this blog which is appealing to us is the issue of maintaining the Docker ecosystem (port sharing, permissions, hosting of Docker Images, etc.)
It seems like "dep-packages as the original containers" makes a lot of sense for small services where there is no concern of port conflicts and where all the dependencies are maintained within a virtual environment.
My gut, however, is telling me that if deb packages were a good fit, it would be more common and docker would be advertised as a more language specific solution. Are there any drawbacks of using something like deb packages to deploy our services, instead of using a full system such as docker?
I got this idea from reading this blog here which makes some good arguments for using a deb package for a pre-existing python application. The main point from this blog which is appealing to us is the issue of maintaining the Docker ecosystem (port sharing, permissions, hosting of Docker Images, etc.)
It seems like "dep-packages as the original containers" makes a lot of sense for small services where there is no concern of port conflicts and where all the dependencies are maintained within a virtual environment.
My gut, however, is telling me that if deb packages were a good fit, it would be more common and docker would be advertised as a more language specific solution. Are there any drawbacks of using something like deb packages to deploy our services, instead of using a full system such as docker?
Solution
First, while Docker is sometimes seen and used as a ad hoc packaging system, it actually solves a totally different problem: Docker is about running programs. The Docker system allows to describe services, that can be scaled at will and to control swarms of containers. Debian packages are for installing programs and they are able to handle dependencies between software versions. Docker certainly don't qualify as a descent packaging system: each “package” can only have one dependency, the system has no “recursive build” option and does not support complex version constraints!
A possible answer would be that, if you are willing to write a Debian package for your application, you can also use Docker to deploy your application. This can be achieved with a configuration script
and a
(In your specific situation, the
It is therefore really possible to use Debian packages and Docker simultaneously, however …
My gut […] is telling me that if deb packages were a good fit, it would be more common
This is a correct hitch which leads us to ask ourselves why Docker proves to be popular as a ad hoc packaging system, while it is not intended to be one. (See above.)
The “official” packaging system from a given distribution is just a possibility among many others to install software in some computing environment. There are many other sources available, like community-specific package managers such as npm or opam, port trees like pkgsrc and plain source code distribution. From this perspective, it is easy to understand the success of Docker as an ad hoc packaging system:
-
Docker specifications are very close from a shell script and whatever source it comes from, we install software using the shell.
-
Docker has a “built-in” (paying) service for hosting artefacts it produces, the Docker Hub.
Now what are the strength of Debian packages over Docker images as a package system? The tight control over dependencies at installation. (The possibility to upgrade and downgrade also exists but has no practical importance if we are implementing the immutable-server pattern.) This leads to the
Conclusion
If you only have a single product deployed in a single version (which is typical for SaaS), your version management needs are very simple and using Docker as a ad hoc package manager should not have any hard drawbacks. As soon as you work with several versions of a single product or several products, the complexity of the version constraints problem you need to solve increases and you need an appropriate tool for this, which might be Debian packages or some configuration management system if you are mixing software from different origins.
A possible answer would be that, if you are willing to write a Debian package for your application, you can also use Docker to deploy your application. This can be achieved with a configuration script
apt_setup.sh which would look likeapt-key add -
EOF
cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOFand a
Dockerfile along the lines ofADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package(In your specific situation, the
apt_setup.sh would be more complicated, adding the nodesource repositories and some helper packages such as apt-transport-https.)It is therefore really possible to use Debian packages and Docker simultaneously, however …
My gut […] is telling me that if deb packages were a good fit, it would be more common
This is a correct hitch which leads us to ask ourselves why Docker proves to be popular as a ad hoc packaging system, while it is not intended to be one. (See above.)
The “official” packaging system from a given distribution is just a possibility among many others to install software in some computing environment. There are many other sources available, like community-specific package managers such as npm or opam, port trees like pkgsrc and plain source code distribution. From this perspective, it is easy to understand the success of Docker as an ad hoc packaging system:
-
Docker specifications are very close from a shell script and whatever source it comes from, we install software using the shell.
-
Docker has a “built-in” (paying) service for hosting artefacts it produces, the Docker Hub.
Now what are the strength of Debian packages over Docker images as a package system? The tight control over dependencies at installation. (The possibility to upgrade and downgrade also exists but has no practical importance if we are implementing the immutable-server pattern.) This leads to the
Conclusion
If you only have a single product deployed in a single version (which is typical for SaaS), your version management needs are very simple and using Docker as a ad hoc package manager should not have any hard drawbacks. As soon as you work with several versions of a single product or several products, the complexity of the version constraints problem you need to solve increases and you need an appropriate tool for this, which might be Debian packages or some configuration management system if you are mixing software from different origins.
Code Snippets
apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF
cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOFADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-packageContext
StackExchange DevOps Q#54, answer score: 17
Revisions (0)
No revisions yet.