https://cloudposse.com logo
Join Slack
Powered by
Curious if anyone's used <#CB84E9V54|> with <dev c...
# geodesic
e
Curious if anyone's used #CB84E9V54 with dev containers? It feels like this could be a good match for SweetOps-style repos!
h
Current geodesic is constructed in such a way it cannot be used properly for dev containers (mainly the profile scripts relying on bash instead of sh)
We currently add some geodesic magic on top of our tooling container, using build stages this allows for a nice combo
j
I am not familiar with dev containers, but can confirm that Geodesic relies heavily on 
bash
and its specific features and we have no plans to make it work under the POSIX Bourne shell.
e
Possibly it could be a different release of geodesic without the interactive elements. E.g. a 
dev-contiainer
release.
It's interesting though, I need to read up on it. Thanks for the suggestion @E-Love
👍 1
e
@Hans D, can you provide a bit more context around your Bash vs sh comment? I haven't run into that limitation yet and regularly use Bash as the primary shell in dev containers, but I fear I'm misunderstanding the limitation you're referencing!
FWIW, I mostly use dev containers with Docker locally and Coder remotely, and not regularly with Codespaces.
h
I've been using it with jetbrains, so it could be implementation specific. Bash itself is not an issue, but the various commands - with jetbrains - arer executed using sh as main shell. The profile scripts will be executed, but in the case of Geodesic these are very bash specific (mainly arrays in variables), which makes it not working. (normally profile scripts are sh compatible).
👍 1
Main difference I see is that the geodesic env is more operational focused, while the dev container is more ... eh ... dev focused. There is some overlap, but the whole wrapping that geodesic does for mounting etc. is handled differently with devcontainers.
e
We'll have @Jeremy White (Cloud Posse) do a quick PoC, and see what we learn from it.
h
he can contact me as well if hee needs more info / my experience
e
same! I currently use dev containers for TF and Helm dev but my team is intrigued by the SweetOps approach and Geodesic feels like it has many of the "batteries included".
j
I assume that, ideally, I would fork the devcontainers-contrib/templates repo
e
Yea, I like the idea of aligning with conventions like this.
e
The Terraform stuff in there uses "features", which are quite different from the common (and Geodesic) way of building images. Features are a way to work around the single inheritance limitation of container images. I would recommend using their base image and keeping the existing Dockerfile as similar as possible, instead of trying to replicate it using features. Alternatively, there could be a "Geodesic feature" that could be applied to any image with proper prereqs, but that sounds like a bigger lift.
h
My experience so far: features are a nice start, but i prefer to roll my own layers. Way more control that way. (and that's why the tooling container we are using is not build on top of Geodesic, but we import the bits we need). Allowed us to be running Bookworm way earlier 😉 (sorry Erik)
👍 1
j
@E-Love Would you please educate me as to what makes dev containers attractive? What do you get with them that you don't get with Docker or Nix? This would help me understand how we can best meet your needs.
I confess I still do not understand the use case, but it looks to me like you can get a good start on using Geodesic with dev containers with this configuration (Contents of 
devcontainer.json
)
Copy code
{
  "name": "Geodesic Dev Container",
  "image": "cloudposse/geodesic:2.9.0-debian",
  "mounts": [
    "source=${localEnv:HOME},target=/localhost,type=bind",
  ],
  "appPort": ["12345:12345"],
  "containerEnv": {
    "SHELL": "/bin/bash",
    "GEODESIC_PORT": "12345",
    "GEODESIC_HOST_CWD": "${localWorkspaceFolder}",
    "GEODESIC_WORKDIR": "${containerWorkspaceFolder}",
    "LOCAL_HOME": "${localEnv:HOME}",
  },
  "remoteEnv": {
    "LOGIN_SHELL": "/bin/bash"
  },
  "settings": {
    "terminal.integrated.defaultProfile.linux": "/bin/bash"
  },
}
Please let me know how it goes, or if you have other feedback. NOTE: the mount of 
"source=${localEnv:HOME},target=/localhost
is overkill and may cause performance issues, but it is what we currently do in Geodesic for the convenience of mounting all the dotfiles and dotdirectories in $HOME, so we can share configuration. You could pare it down to just the ones you want to use, but my personal list is kind of long:
Copy code
.aws .bashrc.d .config .emacs.d .geodesic .kube .ssh .terraform.d
This also does not solve the problem for files like 
.bashrc
or 
.inputrc
e
@Jeremy G (Cloud Posse), are you saying you don't understand why the spec exists and why so many companies are buying into it? Do you want me to make the case for that?
j
@E-Love I am not saying it is not worthwhile, I'm just saying I don't understand its value because it does not seem to be an improvement in my specific workflow. I don't like using the terminal from within the IDE. For 
go
development, a container with 
go
is not that helpful because it doesn't persist all the downloaded modules. None of this is to say that dev containers are not helpful to somebody for something, I am only saying that I don't really get it yet. Because I don't get it yet, I cannot confidently evaluate whether or not Geodesic's support of dev containers is good or not. So, I'm asking you to try it out and let me know if it works well for you, and if not, why not. I'm not really asking you to make the case for dev containers. For example, the configuration I posted does not forward the SSH agent on the host. Do you care, or is that adequately handled by your IDE, or do you just not need it? For another example, the configuration assume that 
${localEnv:HOME}/
contains configuration directories like 
.aws
and 
.config
. Does that work with remote workspaces? If not, what is the right way to import such configuration?
e
thanks for clarifying and I'm definitely down to try this out 🙂 your last question is easiest to answer 🙂 unfortunately, dotfiles support isn't built into the spec. However, many of the remote environments like Codespaces and Coder have built-in support for them, as do editors like VSCode. For terminal-based dev tools and JetBrains IDEs, I typically use the CLI's 
exec
command to execute chezmoi (my dotfiles manager of choice), but I've been thinking there could be a way to build a 
postCreateCommand
lifecycle script to do something similar.
for SSH, there are a number of approaches, but they're unfortunately host-specific. For local dev, it's relatively easy. For remote tools, every provider has their own mechanism for accessing exposed ports or, in Codespaces's case, the 
gh
CLI's command.
j
Yes about SSH, that's why I punted on that.
👍 1
Looks like 
chezmoi
has a Debian package, but not published in the Debian package repo. Maybe you can lobby them for that, then you can easily install it in Geodesic using 
apt-get
.
e
I suspect installing from the 
.deb
would work in the meantime
I'll block off some time on Friday to try this out
j
I appreciate your effort. To keep things simpler here, please just focus on Geodesic in this thread. I think the above configuration will work for the use case where you are running the IDE and hosting the code on your local machine. I will look into making it easier to run remotely.
👍 1
e
I'm happy to help with the same. My intent with this thread was to start a convo around feasibility, not create a feature request 😉
j
With the above configuration, I was able to use Geodesic as a dev container with IntelliJ EAP. So it's feasible. TBD is how useful it is and what would make it more useful.
e
I'll happily provide feedback as I (and hopefully my team soon) work with it. Thanks a bunch!
h
The benefit if having devcontainers is that you can ship the minimal required bits together with the repo. Shipping geodesic as the base for that devcontainer could be done, but given its size might not the option, but multiple devcontainers can be used. Having the container minimal: fast pull, no interference because of special magic, keeping out personal preferences,... (could be added via Chezmoi Dotfile Manager / https://containers.dev/features).
j
@Hans D the special magic is a big part of Geodesic. Customized prompt, handling multiple AWS profiles, easy Kubernetes access, etc. If you don't want that, then you can probably get away with just installing 
atmos
and 
terraform
(and maybe 
kubectl
if you're using Kubernetes) on your choice of Linux.
h
I know. And we use some of that special magic as well (we inject that from geodesic into our tooling container). But for some dev situation that might be a bit too much or too magical.
Open in Slack
PreviousNext
Powered by