Docker compose

[Ben-Haslam]

No description provided.

[flofrie]

I just had a look at the dockerize documentation. Neat tool. Still, I am surprised there isn't some docker-native way to wait for some service to come up before starting something else. But no matter, for now, this clearly does the job. -- Found an interesting link in the documentation to discussion of this: docker/compose#374 (comment)

@ben-clearmatics , for clarification: neither the ENTRYPOINT directive, nor main.sh get changed here to actually use dockerize. You're literally just making sure dockerize exists within the container. I guess that's as intended, and for the purposes of our docker compose deployment strategy, another image is derived from this that then makes use of dockerize?

BTW, generally a word of caution to all of us: this is how at some point down the line, really significant hacks can happen. We're including here in a container running our nodes a tool from some guy's Git repo, most of which is 4 year old code, and we have no actual audit or knowledge what his code does, and don't really know what happens if he changes anything. (Or, if someone with access to his Github account changes anything ...) -- Over time, we must become more aware of the many times we're doing something like this, and think hard about solutions.

[Ben-Haslam]

I just had a look at the dockerize documentation. Neat tool. Still, I am surprised there isn't some docker-native way to wait for some service to come up before starting something else. But no matter, for now, this clearly does the job. -- Found an interesting link in the documentation to discussion of this: docker/compose#374 (comment)

@ben-clearmatics , for clarification: neither the ENTRYPOINT directive, nor main.sh get changed here to actually use dockerize. You're literally just making sure dockerize exists within the container. I guess that's as intended, and for the purposes of our docker compose deployment strategy, another image is derived from this that then makes use of dockerize?

BTW, generally a word of caution to all of us: this is how at some point down the line, really significant hacks can happen. We're including here in a container running our nodes a tool from some guy's Git repo, most of which is 4 year old code, and we have no actual audit or knowledge what his code does, and don't really know what happens if he changes anything. (Or, if someone with access to his Github account changes anything ...) -- Over time, we must become more aware of the many times we're doing something like this, and think hard about solutions.

Yes, all that is changed is the dockerfile. I agree that its not great it uses a repo that is not ours, but its the only solution I could find for this problem. A lot of people have asked for them to update compose to be able to do this natively so that may come soon. When compose runs this image it modifies the entrypoint, such that it uses dockerize to wait until the fluentd container is up and running before starting the container, so the container needs to have dockerize installed for that to work.