Persistent containers using container tunnel
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 189
- Forks
- 24
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 18
Description
In the current implementation, a Container that needs to be persistent cannot depend on the container tunnel to reach endpoints on the host network. The reason is that the tunnel itself is not persistent.
The tunnel consists of 2 proxies actually:
1. The container proxy that handles connection requests coming from other containers on the same container network
2. The server proxy that proxies traffic from container proxy to desired host services (back-ends) that serve it.
The server proxy is a regular process (`dcp tunnel-server`). To enable tunnel persistence, we need support for [persistent Executables](https://github.com/microsoft/dcp/issues/13), and then make the tunnel persistent (on demand) too.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the dcp tunnel-server process and the persistent Executables proposal in issue #13. Trace how the container proxy reaches the server proxy and define the persistence requirements and on-demand lifecycle for the tunnel. Done means a persistent container can reliably reach host-network endpoints through a persistent tunnel.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100