It is possible to exclude several types of data from the migration: whole dogus, files within dogus, and configuration\nvalues.
\nTo use one or several of these possibilities, the CES-importer needs to be configured on the target instance. To do that,\nedit the CES-Component custom resource (\"Component-CR\") of the CES-Importer. This is possible by following these steps:
\nEdit the “Component-CR” of the CES-Importer:
\nkubectl edit component ces-importer -n ecosystemvaluesYamlOverwrite fieldExample:
\napiVersion: k8s.cloudogu.com/v1\nkind: Component\nmetadata:\nname: ces-importer\nnamespace: ecosystem\nspec:\nname: ces-importer\nnamespace: k8s\nversion: 1.0.0\nvaluesYamlOverwrite: |\n config:\n job:\n excludedGlobalConfiguration:\n - \"default_dogu\"\n excludedDoguConfigurations:\n - dogu: \"postfix\"\n keys:\n - \"relayhost\"\n exclude:\n - dogu: \"official/jenkins\"\n pattern: \n - \"subdir/*.groovy\"\n - \"*.tmp\"\n - dogu: \"official/nexus\"\n pattern: \n - \"/tmp/\"Restart the CES-Importer:
\nkubectl rollout restart deployment/ces-importer -n ecosystemTo exclude whole dogus from the import, add the names of these dogus as a list under config/job/excludedDogus. It is\nnot necessary to specify the namespace of the dogu. For example, jenkins can be used instead of official/jenkins.
To exclude the jenkins and the redmine dogu from the import, use the following configuration:
\n...\n valuesYamlOverwrite: |\n config:\n job:\n excludedDogus:\n - \"jenkins\"\n - \"redmine\"\n...In certain constellations, it may make sense to exclude manually created files from the migration, as they are\nunnecessary for CES-MN instances. This can be, for example, self-created scripts or other data in the volumes of the\nDogus that should not be migrated.
\nFor each dogu, files that are not to be migrated can be specified as patterns.
\n\n\nNote:\nMultiple exclude patterns can be specified for each dogu.\nThe extended Dogu name with the namespace must be specified.\nFor example
\nofficial/jenkins, orofficial/nexus.
The pattern for excluding files can contain wildcards in order to be used as flexibly as possible:\nThe following examples show the various possibilities:
\n/tmp/Excludes the directory /tmp/. All files and subdirectories in /tmp/ are not migrated.
*.logExcludes all files with the extension .log, regardless of the directory in which they are located.
/logs/error.logExcludes only the file error.log in the directory logs, but not files with the same name in other directories.
**/node_modules/Excludes every node_modules directory - recursively and regardless of how deep it is in the path.
To exclude all files with the extension .tmp and all files within the directory subdir that have the ending .groovy\nfor the jenkins dou, as well as the directory /tmp within the nexus dogu, the configuration would look like this:
...\n valuesYamlOverwrite: |\n config:\n job:\n exclude:\n - dogu: \"official/jenkins\"\n pattern: \n - \"subdir/*.groovy\"\n - \"*.tmp\"\n - dogu: \"official/nexus\"\n pattern: \n - \"/tmp/\"\n...Configuration values can also be excluded from the import. This can be a good idea for the relayhost value of the\npostfix dogu. Excluding configuration values can lead to an unstable or inconsistent state of the target system and\nis done at one's own risk.
It is possible to exclude global as well as dogu-specific configuration values. By default, the values for\nfqdn, alternativeFQDNs, maintenance, as well as configuration starting with proxy/, k8s/ oder certificate/\nare excluded from the import. Any custom exclusions are added to this list.
In order to not overwrite the global configuration default_dogu as well as the postfix-specific relayhost on the\nimporting system with the values from the exporting system, use the following configuration:
...\n valuesYamlOverwrite: |\n config:\n job:\n excludedGlobalConfigurationKeys:\n - \"default_dogu\"\n excludedDoguConfigurations:\n - dogu: \"postfix\"\n keys:\n - \"relayhost\"\n...