Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-12T19:29:05.687Z
Answers: 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.
Answers: figtrap
Answers: CC BY-SA 3.0
Answers: 2018-03-12T21:39:22.180Z
Answers: @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.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-03T12:32:13.863Z
Answers: 2017-03-03T12:32:13.863Z
Answers: Tensibai
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-05-11T07:50:56.573Z
Answers: So far I'm finding it replaces "works on my machine" with "works on my machine, but behaves bizarrely in Docker".
Answers: Matt Moran
Answers: CC BY-SA 3.0
Answers: 2017-03-02T17:42:01.697Z
Answers: 2017-03-02T17:42:01.697Z
Answers: Evgeny Zislis
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-02T17:24:50.657Z
Answers: 2017-03-02T17:24:50.657Z
Answers: coderanger
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2024-02-04T20:28:32.283Z
Answers: The second `EOF` isn't at the right place in `apt_setup.sh`, is it?
Answers: Eric Duminil
Answers: CC BY-SA 3.0
Answers: 2017-03-03T10:40:08.113Z
Answers: 2017-03-03T10:40:08.113Z
Answers: Michaël Le Barbier
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-02-28T17:38:55.060Z
Comments: 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?
Comments: Chris
Comments: CC BY-SA 3.0
Comments: 2017-02-28T17:40:51.910Z
Comments: 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.
Comments: avi
Comments: CC BY-SA 3.0
Comments: 2017-02-28T17:53:25.143Z
Comments: "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?
Comments: Assaf Lavie
Tags: <docker><deployment><artifacts>
Title: Are there any drawbacks of using a deb package as if it was a container to deploy an application?
UserDisplayName: avi
ThreadText: # 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
  -----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
  EOF
  
  ```
  
  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](/questions/tagged/immutable-server "show questions tagged '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. 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.
  
  > **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.
  
  
  ---
  
  