GoogleContainerTools
Unable to add LABELS with forward slash for Elastic Common Schema (ECS) formatting
Environment:
- Jib version: 3.2.1
- Build tool: Maven 3.6.3
- OS: macOS Monterey
Description of the issue: I would like to build an image with filebeat LABELS in order to push Elastic Common Schema (ECS) formatting logs to my Elastic instance. See documentation here. The problem is I am not able to set labels as there is a forward slash in the key:
co.elastic.logs/json.keys_under_root: true
co.elastic.logs/json.overwrite_keys: true
co.elastic.logs/json.add_error_key: true
co.elastic.logs/json.expand_keys: true
Is there any way to deal with that situation? Or Maybe is that possible to integrate the possibility to set labels another way as:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>3.2.1</version>
<configuration>
<from>
<image>gcr.io/distroless/java17-debian11</image>
</from>
<to>
<image>...</image>
</to>
<container>
<ports>
<port>8080</port>
</ports>
<labels>
"co.elastic.logs/json.keys_under_root"=true
"co.elastic.logs/json.overwrite_keys"=true
"co.elastic.logs/json.add_error_key"=true
"co.elastic.logs/json.expand_keys"=true
</labels>
</container>
</configuration>
</plugin>
Expected behavior:
Steps to reproduce:
jib-maven-plugin Configuration:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>3.2.1</version>
<configuration>
<from>
<image>gcr.io/distroless/java17-debian11</image>
</from>
<to>
<image>...</image>
</to>
<container>
<ports>
<port>8080</port>
</ports>
<labels>
<co.elastic.logs/json.keys_under_root>true</co.elastic.logs/json.keys_under_root>
<co.elastic.logs/json.overwrite_keys>true</co.elastic.logs/json.overwrite_keys>
<co.elastic.logs/json.add_error_key>true</co.elastic.logs/json.add_error_key>
<co.elastic.logs/json.expand_keys>true</co.elastic.logs/json.expand_keys>
</labels>
</container>
</configuration>
</plugin>
Log output:
Additional Information:
One workaround is to set Maven properties. System properties (e.g., -Djib.container.labels=... on the command-line) also work. The format is comma-separated key-value pairs:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
...
<jib.container.labels>co.elastic.logs/json.keys_under_root=true,co.elastic.logs/json.overwrite_keys=true</jib.container.labels>
</properties>
Looks like we can use Properties instead of Map for our configuration Mojo, which seems backward-compatible. But I think it would still not be possible to use special characters in key names due to the XML syntax constraint.
I confirm it works fine with:
<properties>
...
<jib.container.labels>
co.elastic.logs/json.keys_under_root=true,
co.elastic.logs/json.overwrite_keys=true,
co.elastic.logs/json.add_error_key=true,
co.elastic.logs/json.expand_keys=true
</jib.container.labels>
</properties>
Thank you guy. 👍
You should verify the actual values by docker inspect. From my testing, some degree of whitespace seems ignored, but in my case, the first label ended up being
\n co.elastic...
You should verify the actual values by
docker inspect. From my testing, some degree of whitespace seems ignored, but in my case, the first label ended up being\n co.elastic...
Effectively. While doing docker inspect I have below data but it works fine as filebeat is able to push correct logs to Elastic:
"Labels": {
"\n co.elastic.logs/json.add_error_key": "true",
"\n co.elastic.logs/json.expand_keys": "true",
"\n co.elastic.logs/json.overwrite_keys": "true",
"co.elastic.logs/json.keys_under_root": "true"
}
<properties>
...
<jib.container.labels>
co.elastic.logs/json.keys_under_root=true,co.elastic.logs/json.overwrite_keys=true,co.elastic.logs/json.add_error_key=true,co.elastic.logs/json.expand_keys=true
</jib.container.labels>
</properties>
results in:
"Labels": {
"co.elastic.logs/json.add_error_key": "true",
"co.elastic.logs/json.expand_keys": "true",
"co.elastic.logs/json.keys_under_root": "true",
"co.elastic.logs/json.overwrite_keys": "true"
}
Thank you so much for the workaround Chanseok! And thanks for verifying @HamedKaramoko! Hopefully this will be helpful for those who come across this issue in the future.
