Docker example doesn't work well with uids != 1000 #156
Assignees
Labels
bug
Something isn't working
Comments
|
During tech sync we have discussed the option of using a copy on start up, as opposed to a shared volume. In this way, the host folder would be copied into the container at start up (which only needs read permissions) and then the runtime Synthetics Agent uses that folder inside the container (not as a shared volume). It will of course be ephemeral and do the same during the next launch. The Remote Zip URL support feature will still provide a mechanism for the suites to be updated without needing a shared volume. Similarly, hot reloading would still be supported in that it would just periodically copy the host folder(s) to the running container at the given interval. |
andrewvc
added a commit
to andrewvc/beats
that referenced
this issue
Jan 4, 2021
The rationale here is that doing so resolves any file permissions issues that may be present due to the suite directory being shared to the container as read only OR due to incompatible UIDs between the docker container and the host. Fixes elastic/synthetics#156
6 tasks
6 tasks
andrewvc
added a commit
to elastic/beats
that referenced
this issue
Feb 17, 2021
* Refactors the config for synthetics suites to act as regular monitors under `heartbeat.monitors` rather than have the new top-level `synthetic.suites` syntax we've been using so far.
* Changes the behavior of local suites to copy their data into the container rather than run directly off the shared docker volume
* Adds a first-class notion of aliasing to monitor types, so that `synthetics/http` monitors show up as `http`, and not as a distinct type (applies to all monitor types)
* Simplifies the types associated with monitor plugins into a new `plugin.Plugin{}` struct, rather than passing around multiple values everywhere.
* See https://github.com/elastic/beats/pull/23467/files#diff-7f1e5387c4757cca1e98483a5678e377a28ca5f9d77b267a4121a14249c96b82R7 for an example of the new config syntax
#### More on the change to copying local tests into the container
The rationale here is that doing so resolves any file permissions issues that may be present due to the suite directory being shared to the container as read only OR due to incompatible UIDs between the docker container and the host.
Fixes elastic/synthetics#156
Fixes #23823
As a note, no tests are added here due to the complexity of testing this small amount of I/O functionality, however, any issues should be caught by our E2E tests in https://github.com/elastic/synthetics/tree/master/__tests__/e2e . I've opened an issue to improve this situation here: #23346
6 tasks
andrewvc
added a commit
to andrewvc/beats
that referenced
this issue
Feb 17, 2021
* Refactors the config for synthetics suites to act as regular monitors under `heartbeat.monitors` rather than have the new top-level `synthetic.suites` syntax we've been using so far.
* Changes the behavior of local suites to copy their data into the container rather than run directly off the shared docker volume
* Adds a first-class notion of aliasing to monitor types, so that `synthetics/http` monitors show up as `http`, and not as a distinct type (applies to all monitor types)
* Simplifies the types associated with monitor plugins into a new `plugin.Plugin{}` struct, rather than passing around multiple values everywhere.
* See https://github.com/elastic/beats/pull/23467/files#diff-7f1e5387c4757cca1e98483a5678e377a28ca5f9d77b267a4121a14249c96b82R7 for an example of the new config syntax
#### More on the change to copying local tests into the container
The rationale here is that doing so resolves any file permissions issues that may be present due to the suite directory being shared to the container as read only OR due to incompatible UIDs between the docker container and the host.
Fixes elastic/synthetics#156
Fixes elastic#23823
As a note, no tests are added here due to the complexity of testing this small amount of I/O functionality, however, any issues should be caught by our E2E tests in https://github.com/elastic/synthetics/tree/master/__tests__/e2e . I've opened an issue to improve this situation here: elastic#23346
(cherry picked from commit fb25ded)
andrewvc
added a commit
to elastic/beats
that referenced
this issue
Feb 17, 2021
* Refactors the config for synthetics suites to act as regular monitors under `heartbeat.monitors` rather than have the new top-level `synthetic.suites` syntax we've been using so far.
* Changes the behavior of local suites to copy their data into the container rather than run directly off the shared docker volume
* Adds a first-class notion of aliasing to monitor types, so that `synthetics/http` monitors show up as `http`, and not as a distinct type (applies to all monitor types)
* Simplifies the types associated with monitor plugins into a new `plugin.Plugin{}` struct, rather than passing around multiple values everywhere.
* See https://github.com/elastic/beats/pull/23467/files#diff-7f1e5387c4757cca1e98483a5678e377a28ca5f9d77b267a4121a14249c96b82R7 for an example of the new config syntax
#### More on the change to copying local tests into the container
The rationale here is that doing so resolves any file permissions issues that may be present due to the suite directory being shared to the container as read only OR due to incompatible UIDs between the docker container and the host.
Fixes elastic/synthetics#156
Fixes #23823
As a note, no tests are added here due to the complexity of testing this small amount of I/O functionality, however, any issues should be caught by our E2E tests in https://github.com/elastic/synthetics/tree/master/__tests__/e2e . I've opened an issue to improve this situation here: #23346
(cherry picked from commit fb25ded)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #153 @paulb-elastic discovered that the docs only work in the rather common scenario where the your user on the host machine is 1000 which matches the heartbeat user in the container. The issue, essentially, is that the
heartbeatuser in docker has a uid of1000, and if this doesn't match up with the uids of the shared mounts you'll get perms issues.Possible solutions:
The text was updated successfully, but these errors were encountered: