Images and their usage in MLRun¶
Every release of MLRun includes several images for different usages. The build and the infrastructure images are described, and located, in the README. They are also published to dockerhub and quay.io.
In this section
Using images¶
MLRun images and external docker images¶
There is no difference in the usage between the MLRun images and external docker images. However:
MLRun images resolve auto tags: If you specify
image="mlrun/mlrun"the API fills in the tag by the client version, e.g. changes it tomlrun/mlrun:1.0.0. So, if the client gets upgraded you’ll automatically get a new image tag.Where the data node registry exists, MLRun: Appends the registry prefix, so the image loads from the datanode registry. This pulls the image more quickly, and also supports air-gapped sites. When you specify an MLRun image, for example
mlrun/mlrun:1.0.0, the actual image used is similar todatanode-registry.iguazio-platform.app.vm/mlrun/mlrun:1.0.0.
These characteristics are great when you’re working in a POC or development environment. But MLRun typically upgrades packages as part of the image, and therefore the default MLRun images can break your product flow.
Working with images in production¶
For production you should create your own images to ensure that the image is fixed.
Pin the image tag, e.g.
image="mlrun/mlrun:1.0.0". This maintains the image tag at 0.10.0 even when the client is upgraded. Otherwise, an upgrade of the client would also upgrade the image. (If you specify an external (not MLRun images) docker image, like python, the result is the docker/k8s default behavior, which defaults tolatestwhen the tag is not provided.)Pin the versions of requirements, again to avoid breakages, e.g.
pandas==1.4.0. (If you only specify the package name, e.g. pandas, then pip/conda (python’s package managers) just pick up the latest version.)