#geodesic (2021-08)

atmos is just a wrapper that calls other binaries (it also parses all the variables from yaml config). Whatever terraform version you have installed and made default, it will be called

thanks man!

head’s up @Jeremy G (Cloud Posse) has a PR to deprecate this in favor of leapp

https://github.com/cloudposse/docs/pull/540

regarding the errors you’re getting, can you make sure you’ve pulled the latest image?

saw that! when’s it getting merged? also, i was able to get it running by building my own image. it only worked on my linux machine though

it should be very user friendly at this point. if not, please open issue on geodesic repo and we’ll have @Jeremy G (Cloud Posse) take a look.

and by user friendly, I mean it should error gracefully with instructions on what to do.

yeah no errors, if i didn’t pass the -ti flag it would fail silently

@Michael Dizon When I run

docker run cloudposse/geodesic:latest-debian | bash

I get a message printed out. (Too long to copy here.) If you do not get a message, that is worth investigating.

The case where you run

docker run -it cloudposse/geodesic:dev-alpine  | bash

is one I did not think of guarding against. I will fix that.

@Jeremy G (Cloud Posse) here’s the output when I run docker run cloudposse/geodesic:latest-debian | bash

########################################################################################
# Attach a terminal (docker run --rm --it ...) if you want to run a shell.
# Run the following to install the script that runs
# Geodesic with all its features (the recommended way to use Geodesic):
#   docker run --rm cloudposse/geodesic:latest-debian init | bash
# (On a Linux workstation, you might need to use "sudo bash" instead of just "bash")
########################################################################################

geodesic is not created in the /usr/local/bin dir

Yes, I thought that was made clear in the output message. How would you suggest I make it clearer?

sigh. i guess i glazed over the init part

thanks for the help

Thanks for showing another path we need to guard against.

yep! thanks for the feedback

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.

https://github.com/cloudposse/geodesic/blob/master/rootfs/etc/init.d/atlantis.sh

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

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

If I was running it as the installed binary then that would work. But that doesn’t jive with Spacelift being the docker runner.

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

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

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

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.

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

Docker images don’t run cloudinit. He’s talking about running something inside the Geodesic container.

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

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.