Shared Databases / Docker Network

[metaskills]

Our organization has a common bootstrap process that setups up a Docker based Oracle service container. So much of our local development takes advantage of that shared database, from a dozen or so repositories. Is it possible to do something similar when using Codespaces.

[tanmayeekamath]

Hey @metaskills, thanks for reaching out.

Can you share a bit more on where this shared database lives (on-prem VPN, cloud based)? And how do you currently access the database from your repos, what does that set up look like?

For Codespaces, we've received similar feedback and here's what we're currently exploring:

• Enabling creating codespaces on a fixed IP range that can then be allow-listed over your network so that the codespace can access resources on your network.
• Enable associating codespaces machines to a customer owned & configured Azure Virtual Network, so that it can access any resources that the VNET is configured to have access to.

Would love to hear your thoughts/feedback on the approaches above and better understand what would work best for you.

Thanks,
Tanmayee

[metaskills]

Thanks @tanmayeekamath for asking and talking here.

Can you share a bit more on where this shared database lives (on-prem VPN, cloud based)? And how do you currently access the database from your repos, what does that set up look like?

For a few of our applications the shared resource could be a database but for many it would be local or VPN-based services in our staging AWS account. There could be a few ways to address this. I think my favorites are at the top.

• Allow port forwarding to work the other way.
• Re: Allow List of IPs - Sounds neat, but I'm sure at some point our network folks will like that. But feels too low level.
• Re: Host Your own Runners - Yes, this sounds neat too. Hopefully we could do that at AWS, but feels too big.

[metaskills]

Perhaps the idea of the devcontainer CLI would be a solution here. See these links:

• Ability to launch .devcontainer project from command line microsoft/vscode-remote-release#2133
• Please create a CLI and spec for .devcontainer use outside of VSCode  microsoft/vscode-remote-release#4771
• Add devcontainer run command microsoft/vscode-remote-release#5416

Basically I am thinking of a scenario where a developer (or team) could have a Codespace myorg/codespaces-user-or-team repo, likely using the universal image. Assume that projects (A), (B), and (C) are all setup to work individually with Codespaces. And project (A) can have downstream service (B) and/or (C) being deveIoped locally too. In the myorg/codespaces-user-or-team Codespace we can checkout each project into /workspace/a, /workspace/b, and /workspace/c. As part of the parent Codespaces' postCreateCommand, we could go into each of those directories after they are cloned and run devcontainer build and hopefully devcontainer open. I'm wondering if I can then have project (A) hit project (B) and (C) which are both running locally.

So maybe CLI tools to compose Codespaces might help?

[Sammie8805]

Definitely

[Chuxel]

Right now you cannot directly attach to multiple dev containers at once within Codespaces, and unfortunately the dev container CLI you mention would only open something in local VS Code.

This sample is a hack to use Remote - Containers with Codespaces to spin up multiple dev containers and connect to them.

For a multi-repo variation of this, the developer specific or "boostrap" repository you are describing could even contain all of the dev container configuration as is shown in this sample. A postCreateCommand for the boostrap container then does an automated clone into sub folders (e.g. git clone <repository> container-1-src) which then makes it available to the appropriate dev container - so upstream repos wouldn't need the config. The first time a window is opened for this other dev container (container-1 in the sample), all of the post/start commands for it would then run as usual and have access to the source tree.

There is also an existing pattern in Remote - Containers for multi-container scenarios that we could bring to Codespaces. An adapted version of this could end up being similar to what you are describing. Specifically:

1. There is a docker-compose.yaml file that is set up to spin up multiple dev containers (along with other side-cars as needed like postgres).
2. One of these containers is a "boostrap" container much like the primary one you are describing that can see everything while other containers focus on a specific scenario tied to a particular sub-folder or other repository.
3. When the Codespace is started, all of these containers spin up and you are connected to this "boostrap" container by default.
4. We could then have a gesture to open up these other containers with their own unique devcontainer.json config in a separate window.

This sample repository hacks in this general model using Remote - Containers and Codespaces in combination. We don't have first class support here yet unfortunately, but it illustrates the idea.

Any support layered in to better support multi-repo cloning in Codespaces then just makes this process easier.

Out of curiosity, would something along these lines meet your needs or is there something else you'd need as well?

[metaskills]

and unfortunately the dev container CLI you mention would only open something in local VS Code.

Odd, I was sure when I tested this a few weeks ago that I was able to code /workspaces/projectb in a new VS Code window connected to the same Codespace.

For a multi-repo variation of this, the developer specific or "boostrap" repository you are describing could even contain all of the dev container configuration as is shown in this sample...

Yes, it takes care of some cross repo baselines. A good example for us would be ensuring SSH is working for git+ssh in our Bundler files.

... A postCreateCommand for the boostrap container then does an automated clone into sub folders (e.g. git clone container-1-src) which then makes it available to the appropriate dev container...

Yup, we are both on the same page.

...so upstream repos wouldn't need the config. The first time a window is opened for this other dev container (container-1 in the sample), all of the post/start commands for it would then run as usual and have access to the source tree...

So I think this is the pain point I am talking about. Lets assume that project (A) is Ruby 2.7 and projects (B) and (C) are each setup individually to work with Codespaces. One is written in Node 14, the other Ruby 2.5. Let's also assume that all projects use an image and/or Dockerfile to resolve all their dev dependencies. I'd like to avoid using a universal image and re-tool a wrapper project/Codespaces to all the work done in each other Codespace. Additionally, I'd also like to not enforce that every project use Docker-in-Docker via compose so that my wrapper project/Codespace can compose these other projects. Am I correct that that is what you are proposing?

There is also an existing pattern in Remote - Containers for multi-container scenarios (https://code.visualstudio.com/remote/advancedcontainers/connect-multiple-containers) that we could bring to Codespaces. An adapted version of this could end up being similar to what you are describing...

Out of curiosity, would something along these lines meet your needs or is there something else you'd need as well?

OMG! This just may be it!!! Give me a few days (maybe longer) to investigate and get back to you.

[Chuxel]

Odd, I was sure when I tested this a few weeks ago that I was able to code /workspaces/projectb in a new VS Code window connected to the same Codespace.

Yep! It will open a new window, but it won't connect to a different dev container. That's a new window and folder in the same dev container. The workaround I mention sets up multiple dev containers. It's not optimized but gets and the general idea. Unfortunately, there's not official support for it yet, but you can see what we'd be able to do.

[metaskills]

Thanks! These were informative to read and learn, however, I'm not sure it will work for us since it seems to create a kitchen sink that would encompass all the dependencies needed for each project. Our organization has > 100 applications/repositories that are mostly HTTP services. Most of these projects are developed in isolation, meaning each can implement Codespaces and their devcontainer implementation in an isolated fashion.

In some cases, a single service (A) may need work to one or more (B) and (C) HTTP services. If these projects were local, that would be easy to do. Simply change a config in service (A) to point to the local version of (B) and (C). See illustration of what we would need from Codespaces to make this work. Basically, can the SSH tunnel (or whatever mechanics are at play) facilitate port requests back to the Local OS?

[metaskills]

For example, I noticed a few months ago that Gitpod partnered (https://www.gitpod.io/blog/tailscale) with Tailscale (https://tailscale.com) and wrote up docs on how to use this tool (https://www.gitpod.io/docs/configure/tailscale) to achieve what I am looking for. Is this on the Codespaces team radar?

[Chuxel]

FYI - Tailscale also has an article on Codespaces FWIW - https://tailscale.com/kb/1160/github-codespaces/

Just to be clear, the model I described above does not require you to use a kitchen sink image. In the illustration you have above, replace "GitHub" with "Codespace host" and "Codespace (A), (B), (C)" with "Dev container (A), (B), (C)" that's essentially what is happening. A Codespace can consist of multiple containers today. The missing bit is being able to attach to something other than the primary one. The advantage of this is you'd just pay for the compute for a single codespace (verses multiple), and communication between containers wouldn't need to go out over the internet.

With that in mind, in an ideal world, would networking multiple actual Codespaces together be preferrable for your scenario given the sheer volume of them, or would being able to spin up and interact with multiple containers in a Codespace be preferrable?

[shellerci]

Just noticed that they've actually got a demo codespace showing how to get it working https://github.com/tailscale/codespace

[metaskills]

With that in mind, in an ideal world, would networking multiple actual Codespaces together be preferrable for your scenario given the sheer volume of them.

@Chuxel 💯% yes. In my head this is ideal because each repo can focus on it's dev application component in isolation. Since there is no way to run Codespaces locally and compose that work locally (or on a kitchen sink) and we want to avoid duplication not only in each docker/compose file... but also in the lifecycle hooks, etc. It would be ideal if we can have this. In our case, we have > 100 HTTP based applications. Under development, it is common to work more than two at the same time and point your primary change application to 1 or more downstream under development services. Does that help outline the point.

@sam-heller-customink That is cool thanks for sharing! It would be nice if we did not have to add that to each project's boiler plate just in case the scenario popped up that I described above. That said, that solution looks really nice and clean and easy to implement. Maybe even with a custom third-party "feature"... 🤔