RUN REPEATABLE
Restores state from previous runs
Sometimes it’s not sufficient to just cache directories (CACHE
), it’d be best
to cache complex state such as running processes or mounted files.
Webapp.io provides this powerful but dangerous caching mechanism via
RUN REPEATABLE
. It’s particularly useful for complicated declarative cluster
state like docker
, docker-compose
and kubectl
.
It’s recommended to combine RUN REPEATABLE with multi-stage builds for large performance improvements.
RUN REPEATABLE for Docker
In this Layerfile, the docker cache from previous runs will be reused because RUN REPEATABLE uses the cache from after the last time this step ran.
If you had three pipelines at 9am, 10am, and 11am, the effective steps run would look like this:
- 9am pipeline: cp (9am files) . && docker build -t myimage
- 10am pipeline: cp -a (9am files) . && docker build -t myimage && cp -a (10am files) . && docker build -t myimage
- 11am pipeline: cp -a (9am files) . && docker build -t myimage && cp -a (10am files) . && docker build -t myimage && cp -a (11am files) . && docker build -t myimage
In particular, docker would see that it had been used multiple times, and would be able to re-use the docker cache from previous invocations to greatly improve build speed.
RUN REPEATABLE for docker-compose
In this Layerfile, all of these things are reused from the moment immediately after the previous invocation:
- The docker layer cache (e.g., pulled images)
- Any created networks or volumes
RUN REPEATABLE for kubernetes (kubectl, k8s, k3s)
RUN REPEATABLE gives 50-95% speedups here.
In this Layerfile, we’d set up a kubernetes cluster for you and then snapshot it after you’d started all of your services.
The next time you push, kubernetes’ own declarative logic would figure out which pods to delete/restart given the manifests created. This means that if you had 20 microservices and only changed one, it’d be the only one that is re-deployed with this Layerfile.