[jira] [Commented] (IGNITE-17032) Apache Ignite Docker container does not run correctly if image is run in read only file system mode
[
https://issues.apache.org/jira/browse/IGNITE-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563331#comment-17563331
]
Petar Tonkovic commented on IGNITE-17032:
-
Hi [~slukyanov],
Thanks for your comment. Indeed, we have already discovered the workaround with
mounting the tmp folder in the yaml definition:
{code:java}
volumeMounts:
- name: temp-vol
mountPath: /tmp
readOnly: false{code}
However, it might be a nice improvement to have everything working out of the
box as we lost quite some time finding the workaround ourselves and it was not
quite obvious.
Regarding the writable disk, sure Ignite needs to write on disk, but again
usually you provide it the mount which is able to be written to do so, which is
hopefully not in the installation folder. :)
In many cases Kubernetes clusters provided by company infrastructure teams
enforce that the images are run with this read only file system flag as part of
their security requirements and it makes total sense:
# You prepare your installation file system pre-deployment with your Docker
file by building it in the required image;
# After said image is ran, there is no room for any kind of malicious software
doing any kind of injections in your pods.
My company has exactly this security policy enforced and I have struggled a lot
with various software that tries to write some temp files in the installation
folder or something similar when trying to deploy it in a container. They
either forget to let you set the log path somehow (usually via environment
variable) and then connect it to a volume mount that is read/write.
I can imagine that these security measures might be a common occurrence in the
industry, so could be a nice improvement. Thank you for looking into it.
P.S. We have noticed the same script being used in the web console agent (we
used the one from GridGain, not sure if it is the case with the vanilla one as
well), just FYI.
> Apache Ignite Docker container does not run correctly if image is run in read
> only file system mode
> ---
>
> Key: IGNITE-17032
> URL: https://issues.apache.org/jira/browse/IGNITE-17032
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.13
>Reporter: Petar Tonkovic
>Priority: Major
>
> When following the Kubernetes deployment tutorials (online:
> https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment,
> youtube: [https://youtu.be/38YgdAOs038]), trying to run the official docker
> image () with the --read-only flag is causing errors:
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 52: cannot create
> temp file for here-document: Read-only file system
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 85: [: -lt: unary
> operator expected2022-05-25T14:27:34.504369604+02:00
>
> Since most managed company Kubernetes clusters enforce this read-only flag as
> a security requirement, it would be good to look into these errors.
>
> Later on, we get the following error on starting up:
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML
> application context (make sure all classes used in Spring configuration are
> present at CLASSPATH) [springUrl=file:/ignite/config/node-configuration.xml]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1135)
> at org.apache.ignite.Ignition.start(Ignition.java:356)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:365)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> instantiate Spring XML application context (make sure all classes used in
> Spring configuration are present at CLASSPATH)
> [springUrl=file:/ignite/config/node-configuration.xml]
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:364)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:102)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:96)
> at
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:729)2022-05-25T14:27:34.916588365+02:00
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:930)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:839)2022-05-25T14:27:34.916609431+02:00
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:709)2022-05-25T14:27:34.916622089+02:00
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)2022-05-25T14:27:34.916636146+02:00
> at
>
[jira] [Commented] (IGNITE-17032) Apache Ignite Docker container does not run correctly if image is run in read only file system mode
[
https://issues.apache.org/jira/browse/IGNITE-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563063#comment-17563063
]
Stanislav Lukyanov commented on IGNITE-17032:
-
Thanks for reporting [~tonkovic].
TLDR: this is fixable, and I think there is a workaround - see it at the end of
the comment.
My first read of this was - well, Ignite should normally be used with a
writable disk, so "Not an issue".
BUT reading the second time I realized that the problem is that we're trying to
write into the *root* volume. We shouldn't do that.
Apparently, the thing that doesn't work is the following line
```
version=$(awk -F[\"\.] '{print $2}' <<< ${version})
```
In particular, the `<<<` is at fault.
Turns out, in Bash the `<<<` ("here-string") is implemented via `<<`
("here-document") which is in turn implemented via temp files. The root file
system is read-only, hence `/tmp` is also read-only, hence `<<` and `<<<` can't
work. You learn something new everyday, don't you?
[This](https://stackoverflow.com/questions/2500436/how-does-cat-eof-work-in-bash)
explains it.
I'm quite surprised that basic Bash syntax can be unfriendly to cloud but here
we are.
Two things we should do (each of them will suffice, but I'd do both):
1. Get rid of the `<<<` and `<<` in the scripts, just in case.
2. Mount `/tmp` as tmpfs. It should always be tmpfs in all environments, for
many good reasons. I'm a bit surprised it's not tmpfs now, and I'd certainly
change that. The question is whether we can and should do this right in the
Dockerfile, or ask everyone to mount `/tmp` as tmpfs when running. The latter
requires at least docs changes.
As a workaround, I think running the container with an [explicit tmpfs
mount](https://stackoverflow.com/questions/34698620/docker-and-volatile-volumes-ala-tmp)
will do the trick:
```
docker run --tmpfs /tmp ...
```
Disclaimer: I haven't got my hands dirty yet, so all of the above needs to be
confirmed with tests.
> Apache Ignite Docker container does not run correctly if image is run in read
> only file system mode
> ---
>
> Key: IGNITE-17032
> URL: https://issues.apache.org/jira/browse/IGNITE-17032
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.13
>Reporter: Petar Tonkovic
>Priority: Major
>
> When following the Kubernetes deployment tutorials (online:
> https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment,
> youtube: [https://youtu.be/38YgdAOs038]), trying to run the official docker
> image () with the --read-only flag is causing errors:
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 52: cannot create
> temp file for here-document: Read-only file system
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 85: [: -lt: unary
> operator expected2022-05-25T14:27:34.504369604+02:00
>
> Since most managed company Kubernetes clusters enforce this read-only flag as
> a security requirement, it would be good to look into these errors.
>
> Later on, we get the following error on starting up:
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML
> application context (make sure all classes used in Spring configuration are
> present at CLASSPATH) [springUrl=file:/ignite/config/node-configuration.xml]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1135)
> at org.apache.ignite.Ignition.start(Ignition.java:356)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:365)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> instantiate Spring XML application context (make sure all classes used in
> Spring configuration are present at CLASSPATH)
> [springUrl=file:/ignite/config/node-configuration.xml]
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:364)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:102)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:96)
> at
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:729)2022-05-25T14:27:34.916588365+02:00
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:930)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:839)2022-05-25T14:27:34.916609431+02:00
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:709)2022-05-25T14:27:34.916622089+02:00
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)2022-05-25T14:27:34.916636146+02:00
> at
>
