5 ms·
> Docker really doesn't help with application packaging It does. You can do crazy shit like this with Docker containers: thinking about the time we create
by heinrichhartman 7y ago
> Docker really doesn't help with application packaging
It does. You can do crazy shit like this with Docker containers:
thinking about the time we created docker at work in 2009:
nobody could remake our centos4 build machine for our C++ code
so we shut it down, imaged the file system into a .tar.gz, and
made our makefiles transparently extract it & build via chroot.
so absolutely fucking cursed -- @stdlib
https://twitter.com/stdlib/status/1192461409549987841 https://twitter.com/stdlib/status/1192461409549987841
It's essentially still exactly what docker allows you to do:
tar-up your whole f'ing disk, and run it in a chroot somewhere else.
Try doing something like this with yum. Good luck.
Of course it's horrible. But now, you can get away with it.
- lstodd 7y agoHow is this different from running the same tarball under lxc or kvm or on whatever cloud provider's vm or just in a chroot? What has Docker to do with this?
- m_mueller 7y agoDockerfiles and docker-compose are IMO decent ways to abstract build and runtime environments. For our current development life cycle I combined it with a Makefile and some common scripts that streamline all life cycle commands across all services. With that, it's straightforward to set up systems where everything is commitable to VCS except docker setup and secrets.
- lstodd 7y agoIt doesn't seem that decent a way if one has to write a bunch of scripts and a Makefile of all things. It, well, I wrote a bunch of perl scripts to "streamline all life cycle commands across all services" back in 2002, where all we had were FreeBSD jails. So, again, what's so special about Docker?
- tuldia 7y agoExcuse me but this is "crazy shit": ".. in 2009: nobody could remake our centos4 build machine for our C++ code ... so absolutely fucking cursed" What lead a computer running a supported operating system[1] in a state like this? Distill that and you have docker :) 1. https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule
- heinrichhartman 7y agoMost likely, custom installed libraries and tools (./configure; make; make install), that were never packaged. And a package manager, that can't even tell you if any of the installed files were changed, after they were installed. Just a guess...
- unilynx 7y agoIf you wanted a RPM that installs on multiple versions of RHEL, you would take the oldest RHEL you could find, build a rpm with all your dependencies except glibc included, and ship that. The resulting rpm would work on all later versions of RHEL Problem is, you still need to update your dependencies, so sooner or later you’re bootstrapping modern GCC and Stdc++, openssl etc all from a Centos 5 base just to get a forwards compatible rpm A that point you start tarring up your chroots so you know how to reconstruct this Frankenstein build enviroment Thank Docker for giving an easily portable environment that’s almost as easily accepted by customers as a RPM
- tuldia 7y agoFirst you should not mix CentOS 5 packages into a CentOS 4 system. That is how you create a problem in the first place. Building software on top of frankenstein build environments is how you end with broken software, and should not be encouraged :) Let alone development environment.
- derefr 7y agoWhat the parent is describing by "Frankenstein build environment" is a bog-standard cross-compilation toolchain/SDK. You don't infect the host with the toolchain's packages; you install the toolchain's packages in the toolchain chroot. (If you've ever developed for an embedded arch, this will be painfully familiar.)