README change only: Clarify why merging into another container is a bad idea

[timbavtbc]

Description

Just a change to the README - I tend to read 'YMMV' as 'might need some jiggling', but it's a bit more serious than jiggling. :) I think being explicit about the particular implementation details is more useful here.

While I'm writing, it may be relevant to mention my particular use-case:

We're wanting to run our Teamcity CI agents in GKE/Autopilot. To build our application, the agents need more than just the plain agent, so we want to customise the image with that additional tooling. We want that customisation-build to happen in Autopilot too.

We're going to launch the debug version of kaniko as a second container in the deployment, alongside the TC agent, and make its entrypoint wait for a trival script file to be placed in a shared volume, to execute the command we need.

Here's a proof of concept faking that out in Docker:

docker run -it --rm -v $PWD:$PWD -w $PWD --entrypoint /bin/sh dockerio.company.com/mre/kaniko-debug -c \
   "while ! [ -f runme ] ; do sleep 1 ; done ; rm -f running; mv runme running ; sh running ; rm running" 

Triggering that from the client script:

rm -f runlog ; \
  echo  "/kaniko/executor --dockerfile Dockerfile --context . --no-push >runlog 2>&1" > runme  ; \
  tail --retry -f runlog & RL_PID=$! ; while [ -f runme ] || [ -f running ] ; do sleep 1 ; done ; sleep 1 ; kill $RL_PID

Maybe it's worth adding a pretty version of that to the README too.

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• [n/a] Includes unit tests
• [n/a] Adds integration tests if needed.

See the contribution guide for more details.

Reviewer Notes

• The code flow looks good.
• Unit tests and or integration tests added.

Release Notes

Describe any changes here so maintainer can include it in the release notes, or delete this block.

Examples of user facing changes:
- Made explicit in the README the main reasons for not merging into a different container.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[QuanZhang-William]

hi @timbavtbc. Thanks for the PR, please sign the CLA and we should be able to merge this!

[timbavtbc]

Should add a section about the file-based script semaphore I mention above?

[timbavtbc]

FWIW, the 'two containers one pod' solution above needed tweaking because we only had standard-rwo volumes, so I needed a second one that the kaniko script could write into to signal back to the Teamcity agent. Also used that one to store the command output and stuff.

Would you be interested in my contributing the two shell scripts for that?

[QuanZhang-William]

Hi @timbavtbc. I see. I'd personally prefer to merge the PR as it is. I feel adding the script would be "too much details" for a README file 🤔 ? But definitely open to other opinions @aaron-prindle

[timbavtbc]

@QuanZhang-William That's fine - the scripts aren't vital to these suggestions, nor are they particularly genius-level coding, so I can cook another pull request for those, in which I'll propose a 'but see xxxx.txt for a workaround' change to the readme.

I probably have to get permission before contributing the scripts anyway, given how... uh, careful companies are these days about stuff that used to be causally unregulated and easy.