Hot loaded containers?

[adameichelkraut]

Here's another sneaky idea to think about. The idea of spinning up/down the containers every time adds a non-zero amount of time to any task we plan to do with Batect.

For example, say I have a commit hook that does the following

./batect terraform-lint
./batect typescript-lint

Typically we would want these to run really quickly to encourage our developers to commit often :) However, it adds maybe an extra ~2-3s to spin up the docker containers per batect task.

What if we were able to tell batect "hey, go ahead and preload these containers in daemon mode -- as I'm going to need them for my development environment". Maybe something akin to ./batect --warm-containers. Obviously, the sneaky bit here is forgetting that you've warmed these containers and then having your machine run to a crawl eventually after you've preloaded many times.

That said, I think the gain is worth the goofs: I'd like to literally run commands at the same speed that I would otherwise be running with batect. Also, prerequisite tasks that use the same container and not need to spin down/spin up the same containers.

[XI1998-swapnilmarathe]

Hi @adameichelkraut ,

Instead of delegating container warmup to batect, can you try something like mittens?

And you can use setup commands to run mittens tasks
https://batect.dev/docs/reference/config/containers#setup_commands

I hope it helps.

[adameichelkraut]

Interesting! However I think this goes beyond warming up the container ... moreso wanting batect to orchestrate having the defined containers "ready" for me when I'm ready to use them in a task and then batect would just do docker exec ... under the hood (or something akin to that).

But I may steal this idea for some of my other nefarious optimization needs!

[charleskorn]

Sorry for the slow response to this @adameichelkraut. It's another great idea.

I'm currently working on some changes (including completely replacing the Docker API client that Batect uses) that should improve some of that overhead, so hopefully that will help mitigate some of this pain.

For pre-starting containers, there might be some complications around containers that use images built on the fly - what would you expect Batect to do if you changed the Dockerfile or another file after that image was already built and started for that container? Would you expect it to just ignore it, or restart the containers?

Similarly, what would you expect Batect to do if you changed the configuration for those containers in batect.yml?

(Not challenging the idea, just trying to understand what you'd expect / assume the behaviour to be as a user.)

[adameichelkraut]

I'm also full of slow responses! Yeah this is a challenging one to think about, but just wanted to spark some interesting convo :)

I'm very interested to hear some of your thoughts on replacing the docker api. Are you going full-bore on stripping out the dependency of docker completely? (Given their fancy new licensing agreements?)

Though, given the current state, here's a categorization of some challenges / mayyybe some responses? (including the ones you mentioned)

• What happens if they change a Dockerfile (or any file part of that Dockerfile context) after that image was already built?
  • I would say that we should limit this functionality to prebuilt containers. Since this is purely in the hope of optimziation, I would consider the repo first to utilize a prebuilt container first anyways.
• What happens when I have three different repos and I forget that batect spun up a ton of things in the background?
  • This would be akin to forgetting that you spun stuff up with docker compose up -d. Theoretically, it would on the onus of the user that wants this optimization to go back and clean up these "ready" containers
• Would we try to spin up all defined container entries?
  • Probably not. I would suggest an opt-in approach with some form of keep-warm: true or daemon: true

I personally sometimes have chained two or three tasks that sometimes even use the same container (such as a container with node, or a container with a couple of different tools on it like aws, terraform, and node ... which gets to a different debate about the size of the container, but that's out of scope :) ). It would be super awesome if the container just stayed up across invocations of batect

[charleskorn]

I'm very interested to hear some of your thoughts on replacing the docker api. Are you going full-bore on stripping out the dependency of docker completely? (Given their fancy new licensing agreements?)

This is unrelated to the licensing changes, and won't remove the dependency on having something that speaks the Docker API - Batect will still need something like Docker Desktop, Colima, Rancher Desktop, or Podman's Docker API compatibility shim.

Instead, this is about removing the many thousands of lines of custom Kotlin code that interact with Docker, and instead replacing them with something that (from Kotlin) uses the official Golang Docker client SDK. This has a couple of advantages:

• way less code for me to maintain and test, reducing the maintenance burden and also build and test times
• less effort to ensure compatibility with Docker and any future changes made
• less effort to add new features that rely on Docker features (eg. docker containers labels support #1152, buildkit ssh support #1128)
• potentially slightly better performance, especially for BuildKit where the image context uploading could be far more intelligent