Public Information
This commit is contained in:
1
ai/jsonl/image.jsonl
Normal file
1
ai/jsonl/image.jsonl
Normal file
@@ -0,0 +1 @@
|
||||
{"chapter": "Common Image Configuration", "level": 2, "text": "The `image` configuration consists of\n- the Image Name\n- the Image Repository\n- the Image Tag\n- the Image Pull Policy\nIf the Pull Policy is not set, it is automatically `IfNotPresent`.\nThe `Repository` can be overridden at Instance Level and Environment Level to accomodate multiple stages:\n```\nimage:\nname: test\ntag: 1.0.0\nrepo: cr.nplus.cloud # Prio 3\npullPolicy: Always\nglobal:\nrepo: myrepo_i1 # Prio 4\nrepoOverride: myrepo_i2 # Prio 2\nenvironment:\nrepo: myrepo_e1 # Prio 5\nrepoOverride: myrepo_e2 # Prio 1\n```\nIn this example, finding the repo to use would be:\n```helm\n$repo := global.environment.repoOverride | default global.repoOverride | default image.repo | default global.repo | default global.environment.repo\n```\nOnce you override the repo, you might als want to override the `pullSecrets` globally to allow login to your private registry. Since you do not want to do that per image definition, you - just like the repos - can override that globally:\n```\nglobal:\npullSecretsOverride:\n- myPrivateRegistrySecret\n```\nThe override procedure is identical to the repo example above.\n**The Use Case** is to easily enable you to download the images to a private and secure registry. *nplus* by default uses the official registries, but\nthat is most likely not wanted by enterprise customers. So you can just set your own registry in the environment and keep dev, qa and prod apart and secured.\n"}
|
||||
Reference in New Issue
Block a user