3 ms·

Does Docker for build environments make a lot of sense? I want to package up an existing environment that predates Docker (by long enough that I don't think the

Does Docker for build environments make a lot of sense? I want to package up an existing environment that predates Docker (by long enough that I don't think there's an old enough base OS image on Docker Hub unless I leverage J. Random Hacker's image that's been tweaked for another project) to make it more portable. Would I be fighting against the design of the tool? Perhaps it would be better to just make a chroot and tar it up? I've tried to educate myself on the tool and make my own judgment, but it's surprisingly hard to find material about Docker that is actually about Docker instead of primarily being a sales pitch for containers and microservices that happens to describe them in Docker terms.

remar 9y ago
This is actually one case I've been thinking of using docker for, that is, having a development image for your project's build environment to provide a consistent base that has all the development libraries installed and doesn't require any fussing around with library versions. I'm sure with certain languages/runtimes you can leverage the package/dependency manager to serve the same purpose, but I imagine having a docker image for this would mean everyone's using the same base OS with the same installed library versions. This way anyone who wants to contribute to your OSS project can clone the repo, run a simple command to initialize the dev environment, and start hacking right away. As an aside, I completely agree with your sentiment about trying to learn about the actual tech rather than just being sold on some sales pitch targeted towards less tech-savvy crowds. The best "solution" I've found for this problem myself is to educate myself as much as I can on the fundamentals of the problem space and try to reason about that decision myself. For example, I haven't done much of a deep dive into docker yet but have spent a lot of time trying to learn as much as I can about the fundamentals/primitives provided by operating systems and kernels. I feel this way I can always reference back to basics and make a better decision of whether something is gimick-y or not. Lately I've been so frustrated with people selling these "solutions" yet not having any understanding of the how things work that I've spent the last 3 years trying to learn as much as I can about infrastructure primitives (TCP/IP + general networking theory, database theory + database engines, and OS/kernel internals). It takes a lot of time but I definitely think it's worth it since it's a lot harder to be "fooled" when you actually understand things from the bottom up, for some definition of "bottom". It also helps that I work in this space professionally, so the investment in learning these things literally pays off. Anyway, that's the end of my rant : )
ealexhudson 9y ago
I think it makes a bunch of sense for both Dev and Build. I wrote a small tool, stowage.org, to make it easier to bundle stuff up into containers and then execute like a local command, and to be honest it works great. A lot of predefined containers don't play easily, but doing custom stuff is very straightforward and it's a nice workflow.
TheDauthi 9y ago
Actually, that's pretty much a perfect use case. "This environment is nothing like where I want it to run, and may even actively conflict with it". It's not really hard to take a chroot and make it an image, either. For building, you can create an image that is ready to build your application, then run it as needed. After each run, unless you've set up some persistence, it goes back to the pristine state. If you create lots of almost-identical environments, you can use layering to save space (but space is cheap, so...) If you want to ship an application that way, you just take that a step further. Create an image ready to run the application. Just remember that storage is, by default, ephemeral. It's a config option away, but annoying if you forget it. I like that I can just ship an image to someone and it'll work on their machine. Great for our OSX developers. The interesting functionality is the use of namespaces, which are ways to create isolation of {IPC,networking,users,filesystems,processes} between the containers. Docker didn't invent them, they've been in the Linux kernel since forever, but Docker has made great use of them. Volume mapping is useful too. Most of what it does is achievable via bind mounts, though, volume mapping is just cleaner, IMO. That said, I've found the most usage out of Docker from the networking side of things, as extraordinarily convoluted as it can be. I have a legacy application that cannot run on any port other than the one that's hardcoded in the application. It tries to connect to itself immediately on startup, too. Obviously it prevents itself from running another instance... by killing the old instance when the new one starts up. Putting it in a Docker container let me run 12 of them, side-by-side, with the ports mapped externally to different ports, invisible to the application. Just an FYI, I'm not one of the converted. I think the current fad of "Dockerize all the things" is a bit silly, especially when I start seeing people doing things like putting ssh access for the host machine in a container. I have no interest in their tools other than Docker itself. I'm not a fan of their whole "one process per container" suggestion, and basically ignore it whenever I want (you should make sure you have something running as the init system in your container if you do this). But it has pretty much replaced chroots for me, no small task. Finally, if you want some good examples of what it can do, look at the images from https://hub.docker.com/u/linuxserver/ https://hub.docker.com/u/linuxserver/
mewse 9y ago
I do exactly this; my build system does its builds for most platforms inside docker containers. (I haven't figured out how to do OSX builds inside a docker container yet, but I'll figure it out eventually!) One of my targets is SteamOS (i.e.: Linux with a particular set of pre-installed shared libraries), and the preferred build environment to target that is inside a chroot. So my SteamOS builds get built inside a chroot inside a docker container. And that was surprisingly tricky to get working! There are some gotchas to overcome around how chroots handle symbolic links inside a docker container. But I've got it all working now. :) The big benefit is that host-OS-upgrades-for-security-purposes no longer upgrade my build's toolchain as a side-effect, potentially breaking or changing the performance of my build artifacts; it's fine to keep running ancient software inside that docker container that's just going to be wiped out in 10 minutes and never gets directly connected to the Internet anyway. And the docker image can be copied around to wherever I need it, if I need extra build workers or whatever. Once you've got the thing set up once, it's fantastic for scaling up your build server if you eventually want to do that.

remar 9y ago

This is actually one case I've been thinking of using docker for, that is, having a development image for your project's build environment to provide a consistent base that has all the development libraries installed and doesn't require any fussing around with library versions. I'm sure with certain languages/runtimes you can leverage the package/dependency manager to serve the same purpose, but I imagine having a docker image for this would mean everyone's using the same base OS with the same installed library versions. This way anyone who wants to contribute to your OSS project can clone the repo, run a simple command to initialize the dev environment, and start hacking right away. As an aside, I completely agree with your sentiment about trying to learn about the actual tech rather than just being sold on some sales pitch targeted towards less tech-savvy crowds. The best "solution" I've found for this problem myself is to educate myself as much as I can on the fundamentals of the problem space and try to reason about that decision myself. For example, I haven't done much of a deep dive into docker yet but have spent a lot of time trying to learn as much as I can about the fundamentals/primitives provided by operating systems and kernels. I feel this way I can always reference back to basics and make a better decision of whether something is gimick-y or not. Lately I've been so frustrated with people selling these "solutions" yet not having any understanding of the how things work that I've spent the last 3 years trying to learn as much as I can about infrastructure primitives (TCP/IP + general networking theory, database theory + database engines, and OS/kernel internals). It takes a lot of time but I definitely think it's worth it since it's a lot harder to be "fooled" when you actually understand things from the bottom up, for some definition of "bottom". It also helps that I work in this space professionally, so the investment in learning these things literally pays off. Anyway, that's the end of my rant : )

ealexhudson 9y ago

I think it makes a bunch of sense for both Dev and Build. I wrote a small tool, stowage.org, to make it easier to bundle stuff up into containers and then execute like a local command, and to be honest it works great. A lot of predefined containers don't play easily, but doing custom stuff is very straightforward and it's a nice workflow.

TheDauthi 9y ago

Actually, that's pretty much a perfect use case. "This environment is nothing like where I want it to run, and may even actively conflict with it". It's not really hard to take a chroot and make it an image, either. For building, you can create an image that is ready to build your application, then run it as needed. After each run, unless you've set up some persistence, it goes back to the pristine state. If you create lots of almost-identical environments, you can use layering to save space (but space is cheap, so...) If you want to ship an application that way, you just take that a step further. Create an image ready to run the application. Just remember that storage is, by default, ephemeral. It's a config option away, but annoying if you forget it. I like that I can just ship an image to someone and it'll work on their machine. Great for our OSX developers. The interesting functionality is the use of namespaces, which are ways to create isolation of {IPC,networking,users,filesystems,processes} between the containers. Docker didn't invent them, they've been in the Linux kernel since forever, but Docker has made great use of them. Volume mapping is useful too. Most of what it does is achievable via bind mounts, though, volume mapping is just cleaner, IMO. That said, I've found the most usage out of Docker from the networking side of things, as extraordinarily convoluted as it can be. I have a legacy application that cannot run on any port other than the one that's hardcoded in the application. It tries to connect to itself immediately on startup, too. Obviously it prevents itself from running another instance... by killing the old instance when the new one starts up. Putting it in a Docker container let me run 12 of them, side-by-side, with the ports mapped externally to different ports, invisible to the application. Just an FYI, I'm not one of the converted. I think the current fad of "Dockerize all the things" is a bit silly, especially when I start seeing people doing things like putting ssh access for the host machine in a container. I have no interest in their tools other than Docker itself. I'm not a fan of their whole "one process per container" suggestion, and basically ignore it whenever I want (you should make sure you have something running as the init system in your container if you do this). But it has pretty much replaced chroots for me, no small task. Finally, if you want some good examples of what it can do, look at the images from https://hub.docker.com/u/linuxserver/ https://hub.docker.com/u/linuxserver/

mewse 9y ago

I do exactly this; my build system does its builds for most platforms inside docker containers. (I haven't figured out how to do OSX builds inside a docker container yet, but I'll figure it out eventually!) One of my targets is SteamOS (i.e.: Linux with a particular set of pre-installed shared libraries), and the preferred build environment to target that is inside a chroot. So my SteamOS builds get built inside a chroot inside a docker container. And that was surprisingly tricky to get working! There are some gotchas to overcome around how chroots handle symbolic links inside a docker container. But I've got it all working now. :) The big benefit is that host-OS-upgrades-for-security-purposes no longer upgrade my build's toolchain as a side-effect, potentially breaking or changing the performance of my build artifacts; it's fine to keep running ancient software inside that docker container that's just going to be wiped out in 10 minutes and never gets directly connected to the Internet anyway. And the docker image can be copied around to wherever I need it, if I need extra build workers or whatever. Once you've got the thing set up once, it's fantastic for scaling up your build server if you eventually want to do that.