<p>Yes, there's drawbacks. </p>

<p>With a .deb package you won't be able to have two version of the same application on the same host. You will have to rely on the distribution available packages, if your app rely on nodejs for example, either you'll be stuck with the distribution version or you'll have to install your own.</p>

<p>Now when you want to host multiples applications on the same host, you'll be hitting a wall very quickly when they depend on the same thing (let's keep nodejs here) in two different versions.</p>

<p>The main goal of docker is to isolate each application from the hosting system and others applications on the same host. there's two reason to do this isolation:
 1. to avoid compromission of the app to be able to take over the host or impact another application
 2. to give the application its exact dependencies and prevent it to be impacted by a system update or another application dependency.</p>

CC BY-SA 3.0
2018-03-12T19:29:05.687Z
Uh, no one suggested using the distribution's ruby, node, python, etc. You make packages of those as well and put them in /opt. Your packages will depend on these. You can absolutely have multiple versions of your app installed with deb packages, there are many examples in Debian itself. In fact, it is the best way to manage multiple versions. This answer is completely wrong.
figtrap
CC BY-SA 3.0
2018-03-12T21:39:22.180Z
@figtrap OK try to use official elastic.co repo and install elasticsearch v. 2.3 and v. 5.6 concurrently. What you're describing is installing two different packages and heavy tweaking if you're doing proper .deb packages. That's a nightmare in term of build dependencies as well as maintenance when you need two different versions of libc somewhere deep in the stack.
Tensibai
CC BY-SA 3.0
2017-03-03T12:32:13.863Z
2017-03-03T12:32:13.863Z
Tensibai
<p>A Debian (or RedHat) package to install applications has been a good practice when done correctly. Packages are used for the purpose of deploying applications which are infrequently changed. Debian packages involve some overhead, like version management, dependency management, pre&amp;post-install scripts, etc...</p>

<p>In many cases upgrading from some older version to a new version requires the careful writing of scripts, attention to details in version, etc. Because mutating existing state is difficult. It would be much easier to replace the current state altogether with a new state, without mutating anything.</p>

<p>Once you decide to completely replace your configuration or dependencies or application on each deployment because it is easier and less error prone. Most organizations (used to) switch to a whole new VM or cloud instance. Which means that installing the package would be done on a "clean" server, and mutating the files and configuration on the server is not a problem anymore.</p>

<p>Those developers who created packages and did not understand the fallacy and complexity in mutations suffered quite a lot of difficulties as a result.</p>

<p>Replacing VMs is sub-optimal when all you need is to replace an application, which is why lightweight containers were introduced as an answer. Using Docker (or other LWC) you can replace the userbase, including all the dependencies, without replacing the server itself. You can also host multiple versions of the same application, with different dependencies, on the same server and only switch the incoming network traffic on upgrade. As well as switch network traffic back on rollback (blue-green), something that was remarkably hard in the case of managing deployments via packages.</p>

<p>Containers introduce a way to bundle all the application code, and dependencies, and configuration, into an image. This image has multiple properties that make it much better than traditional operating system packages. For example, it has tags that enable versioning, but it also has layers, which enable to save on space. It allows an easy way to ship these images to servers, and development environments, by using a registry. And these images can be executed as containers in any environment and any server, almost identically. This includes the developer's laptop as well as the production environment. Again, something that was much more difficult to do with VMs and/or with package-based versions of the software. Having the same image tested on the developer's laptop, and staying the same bits and bytes in production removes a lot of "works on my machine" problems.</p>

CC BY-SA 3.0
2017-05-11T07:50:56.573Z
So far I'm finding it replaces "works on my machine" with "works on my machine, but behaves bizarrely in Docker".
Matt Moran
CC BY-SA 3.0
2017-03-02T17:42:01.697Z
2017-03-02T17:42:01.697Z
Evgeny Zislis
<p>Talking specifically about the image packaging piece of Docker, not the container runtime there are a few minor bits. The biggest is that a Docker image is more like a chroot, which means you are prevented from accidentally depending on shared system state since every file in use must be explicitly included in the image while a system package might pick up dynamic links you didn't expect or otherwise get more intertwined with other packages. This can come up with complex C dependencies getting loaded without your knowledge, for example OpenSSL. Additionally using deb packages don't de-duplicate shared bits in the say Docker's storage system does. For some this might be a good thing, better I/O performance and fewer moving pieces, but for others it might be a problem.</p>

CC BY-SA 3.0
2017-03-02T17:24:50.657Z
2017-03-02T17:24:50.657Z
coderanger
<p>First, while <strong>Docker</strong> is sometimes seen and used as a <em>ad hoc</em> packaging system, it actually solves a totally different problem: <strong>Docker</strong> is about <em>running</em> programs. The <strong>Docker</strong> system allows to describe <em>services,</em> that can be <em>scaled</em> at will and to control <em>swarms</em> of containers. <strong>Debian packages</strong> are for installing programs and they are able to handle <em>dependencies</em> between software versions.  <strong>Docker</strong> 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!</p>

<p>A possible answer would be that, if you are willing to write a <strong>Debian package</strong> for your application, you can also use <strong>Docker</strong> to deploy your application.  This can be achieved with a configuration script <code>apt_setup.sh</code> which would look like</p>

<pre><code>apt-key add - &lt;&lt;EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
&lt;YOUR RELEASE OFFICER PGP KEY GOES HERE&gt;
EOF

cat &gt;&gt; /etc/apt/sources.list &lt;&lt;EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF
</code></pre>

<p>and a <code>Dockerfile</code> along the lines of</p>

<pre><code>ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh &amp;&amp; rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package
</code></pre>

<p>(In your specific situation, the <code>apt_setup.sh</code> would be more complicated, adding the <em>nodesource</em> repositories and some helper packages such as <em>apt-transport-https</em>.)</p>

<p>It is therefore really possible to use <strong>Debian packages</strong> and <strong>Docker</strong> simultaneously, however …</p>

<blockquote>
  <p>My gut […] is telling me that if deb packages were a good fit, it would be more common</p>
</blockquote>

<p>This is a correct hitch which leads us to ask ourselves why <strong>Docker</strong> proves to be popular as a <em>ad hoc</em> packaging system, while it is not intended to be one. (See above.)</p>

<p>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 <strong>npm</strong> or <strong>opam,</strong> port trees like <strong>pkgsrc</strong> and plain source code distribution.  From this perspective, it is easy to understand the success of <strong>Docker</strong> as an <em>ad hoc</em> packaging system:</p>

<ul>
<li><p><strong>Docker</strong> specifications are very close from a shell script and whatever source it comes from, we install software using the shell.</p></li>
<li><p><strong>Docker</strong> has a “built-in” (paying) service for hosting artefacts it produces, the <strong>Docker Hub</strong>.</p></li>
</ul>

<p>Now what are the strength of <strong>Debian packages</strong> over <strong>Docker images</strong> 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 <a href="/questions/tagged/immutable-server" class="post-tag" title="show questions tagged &#39;immutable-server&#39;" rel="tag">immutable-server</a> pattern.) This leads to the</p>

<h3>Conclusion</h3>

<p>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 <strong>Docker</strong> as a <em>ad hoc</em> 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 <strong>Debian packages</strong> or some configuration management system if you are mixing software from different origins.</p>

CC BY-SA 4.0
2024-02-04T20:28:32.283Z
The second `EOF` isn't at the right place in `apt_setup.sh`, is it?
Eric Duminil
CC BY-SA 3.0
2017-03-03T10:40:08.113Z
2017-03-03T10:40:08.113Z
Michaël Le Barbier
<p>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.</p>

<p>I got this idea from reading this blog <a href="https://nylas.com/blog/packaging-deploying-python/" rel="noreferrer">here</a> 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.)</p>

<p>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.</p>

<p>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?</p>

CC BY-SA 3.0
2017-02-28T17:38:55.060Z
Those aren't mutually exclusive, you could deploy your deb package in a Docker container.  
Maybe you should be asking about Microservices vs Virtual Machines?
Chris
CC BY-SA 3.0
2017-02-28T17:40:51.910Z
Hmm, no this is specifically about using a deb-package instead of docker container. I'll add more information from the blog into the question.
avi
CC BY-SA 3.0
2017-02-28T17:53:25.143Z
"we felt that upgrading the kernel just to ship code faster was an overkill solution." this just sounds wrong to me. what could be more important than shipping code faster?
Assaf Lavie
<docker><deployment><artifacts>
Are there any drawbacks of using a deb package as if it was a container to deploy an application?
avi
# Are there any drawbacks of using a deb package as if it was a container to deploy an application?

(Asked by: username_0 on 2017-02-28)

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](https://nylas.com/blog/packaging-deploying-python/) 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?

**Tags:** docker, deployment, artifacts

> **Comments:**
> **username_1**: Those aren't mutually exclusive, you could deploy your deb package in a Docker container.   Maybe you should be asking about Microservices vs Virtual Machines?  
> **username_0**: Hmm, no this is specifically about using a deb-package instead of docker container. I'll add more information from the blog into the question.  
> **username_2**: "we felt that upgrading the kernel just to ship code faster was an overkill solution." this just sounds wrong to me. what could be more important than shipping code faster?  

---

## 4 answers

### Answer by username_8 on 2017-03-03. Score: 17 | Accepted answer

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 apt_setup.sh which would look like
apt-key add - <
EOF

cat >> /etc/apt/sources.list <
and a Dockerfile along the lines of
ADD 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.

> **Comments:**
> **username_9**: The second `EOF` isn't at the right place in `apt_setup.sh`, is it?  

---

### Answer by username_3 on 2017-03-03. Score: 7

Yes, there's drawbacks.

With a .deb package you won't be able to have two version of the same application on the same host. You will have to rely on the distribution available packages, if your app rely on nodejs for example, either you'll be stuck with the distribution version or you'll have to install your own.

Now when you want to host multiples applications on the same host, you'll be hitting a wall very quickly when they depend on the same thing (let's keep nodejs here) in two different versions.

The main goal of docker is to isolate each application from the hosting system and others applications on the same host. there's two reason to do this isolation:
1. to avoid compromission of the app to be able to take over the host or impact another application
2. to give the application its exact dependencies and prevent it to be impacted by a system update or another application dependency.

> **Comments:**
> **username_4**: Uh, no one suggested using the distribution's ruby, node, python, etc. You make packages of those as well and put them in /opt. Your packages will depend on these. You can absolutely have multiple versions of your app installed with deb packages, there are many examples in Debian itself. In fact, it is the best way to manage multiple versions. This answer is completely wrong.  
> **username_3**: @username_4 OK try to use official elastic.co repo and install elasticsearch v. 2.3 and v. 5.6 concurrently. What you're describing is installing two different packages and heavy tweaking if you're doing proper .deb packages. That's a nightmare in term of build dependencies as well as maintenance when you need two different versions of libc somewhere deep in the stack.  

---

### Answer by username_5 on 2017-03-02. Score: 7

A Debian (or RedHat) package to install applications has been a good practice when done correctly. Packages are used for the purpose of deploying applications which are infrequently changed. Debian packages involve some overhead, like version management, dependency management, pre&post-install scripts, etc...

In many cases upgrading from some older version to a new version requires the careful writing of scripts, attention to details in version, etc. Because mutating existing state is difficult. It would be much easier to replace the current state altogether with a new state, without mutating anything.

Once you decide to completely replace your configuration or dependencies or application on each deployment because it is easier and less error prone. Most organizations (used to) switch to a whole new VM or cloud instance. Which means that installing the package would be done on a "clean" server, and mutating the files and configuration on the server is not a problem anymore.

Those developers who created packages and did not understand the fallacy and complexity in mutations suffered quite a lot of difficulties as a result.

Replacing VMs is sub-optimal when all you need is to replace an application, which is why lightweight containers were introduced as an answer. Using Docker (or other LWC) you can replace the userbase, including all the dependencies, without replacing the server itself. You can also host multiple versions of the same application, with different dependencies, on the same server and only switch the incoming network traffic on upgrade. As well as switch network traffic back on rollback (blue-green), something that was remarkably hard in the case of managing deployments via packages.

Containers introduce a way to bundle all the application code, and dependencies, and configuration, into an image. This image has multiple properties that make it much better than traditional operating system packages. For example, it has tags that enable versioning, but it also has layers, which enable to save on space. It allows an easy way to ship these images to servers, and development environments, by using a registry. And these images can be executed as containers in any environment and any server, almost identically. This includes the developer's laptop as well as the production environment. Again, something that was much more difficult to do with VMs and/or with package-based versions of the software. Husername_0ng the same image tested on the developer's laptop, and staying the same bits and bytes in production removes a lot of "works on my machine" problems.

> **Comments:**
> **username_6**: So far I'm finding it replaces "works on my machine" with "works on my machine, but behaves bizarrely in Docker".  

---

### Answer by username_7 on 2017-03-02. Score: 1

Talking specifically about the image packaging piece of Docker, not the container runtime there are a few minor bits. The biggest is that a Docker image is more like a chroot, which means you are prevented from accidentally depending on shared system state since every file in use must be explicitly included in the image while a system package might pick up dynamic links you didn't expect or otherwise get more intertwined with other packages. This can come up with complex C dependencies getting loaded without your knowledge, for example OpenSSL. Additionally using deb packages don't de-duplicate shared bits in the say Docker's storage system does. For some this might be a good thing, better I/O performance and fewer moving pieces, but for others it might be a problem.


---

