https://cloudposse.com logo
Join Slack
Powered by
<@UB90MG971> <@UB2EH889X> Any best practice or sug...
# geodesic
m
@Jeremy G (Cloud Posse) @Erik Osterman (Cloud Posse) Any best practice or suggestion on where to put a daemon initialization script that I always need to be executed on container start (regardless of the Docker CMD)? I have a daemon start script that I put in 
/rootfs/etc/profile.d/
, which works when the container starts via a login shell, but it does not work if the container starts from within Spacelift which I assume is due to the fact that they pass a separate 
docker run
command (makes sense).
This is just a small script to start the 
sdm listen --daemon
command, which is necessary to connect to SDM resources within the container.
I’m sure if my linux-fu was stronger I’d know the answer to this… but figured ya’ll would be able to easily point me in the right direction.
I’m moving forward with an entrypoint.sh script as that will definitively ensure it is always run. Appreciate if ya’ll have any geodesic specific suggestions though.
e
this is how we did something similar for atlantis
so 
profile.d
is meant for interactive login sessions
init.d
is meant for non-interactive sessions
m
Yeah I was checking that out and tried putting my script into 
init.d
. But it seems that didn’t do it either. I’m assuming because when the CMD is overwritten it then doesn’t call 
/usr/local/bin/init
which results in not looping over 
/etc/init.d
✅ 1
If I was running it as the installed binary then that would work. But that doesn’t jive with Spacelift being the docker runner.
e
yes, in the end 
init
is just our "entrypoint" script
and the only way for this to work is that some entrypoint needs to run it
j
Entrypoint is not a sure thing, either, since that can be overridden, too.
Our standard entrypoint is bash, our standard CMD is 
-c boot
. Boot detects whether or not there is a terminal attached, which is probably where you are seeing Spacelift diverge from running locally. This is part of implementing some magic that makes it possible to pipe the output of Geodesic into a shell and have that cause Geodesic to install itself on the host.
I don't know how Spacelift runs Geodesic. I will look into it, but if you know, @Matt Gowie, please share.
OK, @Matt Gowie I have confirmed that Spacelift overwrites both 
entrypoint
and 
cmd
so you cannot get a daemon init to run via Docker config. You need to configure Spacelift to run the daemon. You can do that by including the daemon initialization in the
Copy code
stack_defaults:
  before_init:
configuration block in the source repo's 
.spacelift/config.yml
. See https://docs.spacelift.io/concepts/configuration/runtime-configuration#before_-and-after_-hooks
m
Ah interesting. Great to know @Jeremy G (Cloud Posse) — Appreciate that. I had started down that path earlier in the day anyway, but that is a good thing to keep in mind regarding this.
e
ahhhh good point @Jeremy G (Cloud Posse) i forgot that it does that
are you using our spacelift component @Matt Gowie?
if so, I wouldn't do it this way at all
this belongs in cloudinit
j
Docker images don't run cloudinit. He's talking about running something inside the Geodesic container.
e
spacelift AMI
we run geodesic as the image that spacelift uses
strongdm probably should be install at the host-level and not at the individual container level
especially if spacelift containers are short lived
m
I am using the Spacelift component. I didn’t think about it being at the host level since then the connections need to be long lived and available to all Spacelift Stacks. But an interesting idea.
2 Views
Open in Slack
PreviousNext
Powered by