7 ms·

> you end up having to copy all the build dependencies (source code) to the host > disk, i/o exhaustion This is why I mentioned specifically for ecosystems li

> you end up having to copy all the build dependencies (source code) to the host > disk, i/o exhaustion This is why I mentioned specifically for ecosystems like PHP, which are interpreted. I'm specifically asking for that use case. I'm not building binaries, my "build" steps are actually deployment steps (npm build, composer install, etc) that I'd be running in exactly the same way on the host. The image I'm deploying by definition also contains my source code because I'm not deploying anything compiled.

nijave 4mo ago
>I'm specifically asking for that use case. That's what I answered for. >I'm not building binaries If you were, I would have added CPU to the list. >my "build" steps are actually deployment steps (npm build, composer install, etc) No, those are build steps. If you weren't using Docker, you would either run all those and shove in a zip/tarball or package into a deb/rpm, etc >The image I'm deploying by definition also contains my source code It doesn't contain .git or need credentials to your git/SCM >I'm not seeing the benefit of the whole "build image, pull on server" pipeline when I can just ditch the registry and added layers by doing those steps on the server as I would normally in other kinds of scenarios You don't need a registry--you can Docker save/load to push images directly to the server. Images buy you a versioned artifact with all the code-level dependencies baked in. Some maintainer yanks their package from npm? Who cares--you have a copy in your Docker image. Your new app version doesn't work? Edit 1 line to point back to the old image tag and rollback. >> The build process can exhaust resources on the host >Maybe, but I've yet to have a host where that's the case for usual CRUD fare. When the build process completes, it tears down the overlayfs which causes everything to sync which leads to a big I/O spike. Depending on the server and amount of files, it might have no impact. However, I've seen build servers become completely unresponsive for 5+ minutes due to the I/O load when this happens. One place I worked, we had to switch our build servers to NVMe--the Docker container teardown caused spikes over 100k IOPs. Can't remember the exact details--it was React either React web front end or React Native mobile app. >There's more layers involved there than something like provisioning with Ansible and just having a deploy script to run the usual suspects. `docker save myimage:tag | gzip | ssh user@server 'gunzip | docker load'` Not saying creating distributable artifacts is the de-facto answer, but I'd strongly consider whether it's really that much more complicated.
- TheCapeGreek 4mo ago
  > Images buy you a versioned artifact with all the code-level dependencies baked in. Fair enough, that buys a little bit of time to not break deployments I supose. > When the build process completes, it tears down the overlayfs Ah okay, I misunderstood you then - I was referring to Docker-less servers and my build steps running there, not building the images on the machine. Thanks for the info!

nijave 4mo ago

>I'm specifically asking for that use case. That's what I answered for. >I'm not building binaries If you were, I would have added CPU to the list. >my "build" steps are actually deployment steps (npm build, composer install, etc) No, those are build steps. If you weren't using Docker, you would either run all those and shove in a zip/tarball or package into a deb/rpm, etc >The image I'm deploying by definition also contains my source code It doesn't contain .git or need credentials to your git/SCM >I'm not seeing the benefit of the whole "build image, pull on server" pipeline when I can just ditch the registry and added layers by doing those steps on the server as I would normally in other kinds of scenarios You don't need a registry--you can Docker save/load to push images directly to the server. Images buy you a versioned artifact with all the code-level dependencies baked in. Some maintainer yanks their package from npm? Who cares--you have a copy in your Docker image. Your new app version doesn't work? Edit 1 line to point back to the old image tag and rollback. >> The build process can exhaust resources on the host >Maybe, but I've yet to have a host where that's the case for usual CRUD fare. When the build process completes, it tears down the overlayfs which causes everything to sync which leads to a big I/O spike. Depending on the server and amount of files, it might have no impact. However, I've seen build servers become completely unresponsive for 5+ minutes due to the I/O load when this happens. One place I worked, we had to switch our build servers to NVMe--the Docker container teardown caused spikes over 100k IOPs. Can't remember the exact details--it was React either React web front end or React Native mobile app. >There's more layers involved there than something like provisioning with Ansible and just having a deploy script to run the usual suspects. `docker save myimage:tag | gzip | ssh user@server 'gunzip | docker load'` Not saying creating distributable artifacts is the de-facto answer, but I'd strongly consider whether it's really that much more complicated.

TheCapeGreek 4mo ago
> Images buy you a versioned artifact with all the code-level dependencies baked in. Fair enough, that buys a little bit of time to not break deployments I supose. > When the build process completes, it tears down the overlayfs Ah okay, I misunderstood you then - I was referring to Docker-less servers and my build steps running there, not building the images on the machine. Thanks for the info!