News for hackers. Stuff that matters.

A comment on Mirantis acquires Docker Enterprise and Docker raises $35M. Parent comment

Re:Mirantis acquires Docker Enterprise and Docker raises $35M by heinrichhartman on Wednesday November 13, 2019 @05:37PM (#21530480)
> 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

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.

[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by lstodd on Wednesday November 13, 2019 @06:02PM (#21530724)
How 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?

[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by m_mueller on Thursday November 14, 2019 @04:33PM (#21539677)
Dockerfiles 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.
[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by lstodd on Saturday November 16, 2019 @10:10AM (#21552981)
It 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?

[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by tuldia on Wednesday November 13, 2019 @06:16PM (#21530844)
Excuse 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

[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by heinrichhartman on Wednesday November 13, 2019 @06:48PM (#21531135)
Most 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...

[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by unilynx on Wednesday November 13, 2019 @07:11PM (#21531306)
If 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

[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by tuldia on Wednesday November 13, 2019 @07:34PM (#21531483)
First 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.

[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by derefr on Wednesday November 13, 2019 @08:13PM (#21531777)
What 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.)
[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by tuldia on Wednesday November 13, 2019 @08:35PM (#21531924)
> You don't infect the host with the toolchain's packages; you install the toolchain's packages in the toolchain chroot.

Infect is a too strong word, because normally the cross compiler will coexist well with your system. But you are right about the chroot, throw it away and start again, repeat. That is great!

I normally install gcc-arm-linux-gnueabihf + qemu-user-static and enable binfmt. It works well for building armhf, but I can imagine for things like ESP32 where you don't have the toolchain sources and etc.

[ Parent | on HN ]
Re:Mirantis acquires Docker Enterprise and Docker raises $35M by tuldia on Wednesday November 13, 2019 @07:21PM (#21531374)
> Most 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.

Software has to be read or at least installed in a safe place (before installing on a live server) so then one can be sure it does nothing silly.

Packaging is not hard, but there are some rules, including placing binaries in /usr/bin, configuration files in /etc and /etc/default (deb) or /etc/sysconfig (rpm), general package files in /usr/share. If you place files in the standard locations probably the package manager will detect changes in config files.

[ Parent | on HN ]