3 ms·

Generally accepted practice is no - they aren't worth having. Containers should only contain a single process. That process shouldn't be writing logs to disk (h

by jarito 11y ago

Generally accepted practice is no - they aren't worth having. Containers should only contain a single process. That process shouldn't be writing logs to disk (hence no logrotate) and timed tasks would generally be done outside the container rather than in it (though there are a lot of ways to skin that cat). Single process containers generally don't need all the baggage of a full init system or other dependencies - hence this project.

rvense 11y ago
At my current job, we're basically using Docker as a sort of package manager and deployment script runner. Our containers are very fat, things are installed with apt. One of them has GCC in it but I'm not sure why. One installs Node and runs a few js scripts during the build process, then never runs it again but keeps it around. It's obviously wrong, but I think it's just a new set of bad ideas that this software has allowed people to have.
- XorNot 11y ago
  Under a time crunch I've not found a way to use language-package managers and not wind up with gcc in the container. The problem is apt does a poor job of letting you setup something like build-essential and then remove it and leave just the runtime shared libraries you need for the other things you build to actually work.
  - justinsaccount 11y ago
    I kinda solve that by doing something like this: # install runtime deps dpkg -l | awk '{print $2}' | sort > old.txt # install build deps # build software dpkg -l | awk '{print $2}' | sort > new.txt apt-get -y remove --purge $(comm -13 old.txt new.txt) Probably a better way to accomplish that, but it was the easiest way I could see to implement an 'undo'
    - zenlikethat 11y ago
      If doing this sort of thing, make sure to accomplish it in a single step (image layer) in the Dockerfile. Otherwise you won't be doing any good as the "removed" files actually persist behind a layer which specifies them as removed.
      - justinsaccount 11y ago
        I've been using docker-squash for that. This way I can take advantage of layer caching during development, and still have a small image for uploading.
  - yrro 11y ago
    If you installed build-essential, then removed it, then apt-get --purge autoremove should remove the packages that build-essential pulled in that were not already installed.
    - XorNot 11y ago
      The problem is by default this will remove runtimes like libtool as well. Sure, I could figure out what these are and keep them around, but the problem is the time-crunch aspect - it takes time, and if the program changes then you still need to take the time.
  - myhf 11y ago
    You can use the "dockerception" method: build in a container with devtools, then import the resulting binaries into a container with no devtools. https://github.com/jamiemccrindle/dockerception https://github.com/jamiemccrindle/dockerception The resulting images can be very small: https://hub.docker.com/r/jjclark/nethack/tags/ https://hub.docker.com/r/jjclark/nethack/tags/ It's currently a little difficult because of a bug with building from a tarball: https://github.com/docker/docker/issues/15785 https://github.com/docker/docker/issues/15785
- vacri 11y ago
  > One of them has GCC in it but I'm not sure why. 'npm install' needs 'make' half the time. Sometimes it's easier on debian-based setups to install build-essential than make, as it will pull in a few other things that help as well. GCC is one of those things - might it be that that container has build-essential installed? I used to run docker with fat containers, and have now just finished getting rid of docker in favour of .debs. We were basically using it as a package manager, and it is terrible at the job. Docker has its use-cases, but package management isn't one of them. The docker tagging system is particularly bad at the job.

by jarito 11y ago

rvense 11y ago

At my current job, we're basically using Docker as a sort of package manager and deployment script runner. Our containers are very fat, things are installed with apt. One of them has GCC in it but I'm not sure why. One installs Node and runs a few js scripts during the build process, then never runs it again but keeps it around. It's obviously wrong, but I think it's just a new set of bad ideas that this software has allowed people to have.

XorNot 11y ago
Under a time crunch I've not found a way to use language-package managers and not wind up with gcc in the container. The problem is apt does a poor job of letting you setup something like build-essential and then remove it and leave just the runtime shared libraries you need for the other things you build to actually work.
- justinsaccount 11y ago
  I kinda solve that by doing something like this: # install runtime deps dpkg -l | awk '{print $2}' | sort > old.txt # install build deps # build software dpkg -l | awk '{print $2}' | sort > new.txt apt-get -y remove --purge $(comm -13 old.txt new.txt) Probably a better way to accomplish that, but it was the easiest way I could see to implement an 'undo'
  - zenlikethat 11y ago
    If doing this sort of thing, make sure to accomplish it in a single step (image layer) in the Dockerfile. Otherwise you won't be doing any good as the "removed" files actually persist behind a layer which specifies them as removed.
    - justinsaccount 11y ago
      I've been using docker-squash for that. This way I can take advantage of layer caching during development, and still have a small image for uploading.
- yrro 11y ago
  If you installed build-essential, then removed it, then apt-get --purge autoremove should remove the packages that build-essential pulled in that were not already installed.
  - XorNot 11y ago
    The problem is by default this will remove runtimes like libtool as well. Sure, I could figure out what these are and keep them around, but the problem is the time-crunch aspect - it takes time, and if the program changes then you still need to take the time.
- myhf 11y ago
  You can use the "dockerception" method: build in a container with devtools, then import the resulting binaries into a container with no devtools. https://github.com/jamiemccrindle/dockerception https://github.com/jamiemccrindle/dockerception The resulting images can be very small: https://hub.docker.com/r/jjclark/nethack/tags/ https://hub.docker.com/r/jjclark/nethack/tags/ It's currently a little difficult because of a bug with building from a tarball: https://github.com/docker/docker/issues/15785 https://github.com/docker/docker/issues/15785
vacri 11y ago
> One of them has GCC in it but I'm not sure why. 'npm install' needs 'make' half the time. Sometimes it's easier on debian-based setups to install build-essential than make, as it will pull in a few other things that help as well. GCC is one of those things - might it be that that container has build-essential installed? I used to run docker with fat containers, and have now just finished getting rid of docker in favour of .debs. We were basically using it as a package manager, and it is terrible at the job. Docker has its use-cases, but package management isn't one of them. The docker tagging system is particularly bad at the job.