Side-car dev container features

[Chuxel]

This proposal is an enhancement idea to the current dev container features proposal.

---

While Features provide a useful way to encapsulate dev container metadata and an installation script into an easily referenced, atomic unit, using a script is not always the ideal way to make something available into a dev container. There are nuances in getting more complex software running in a container, and the current mechanism most used to deliver these best practices to customers is through a dedicated container image. Examples include databases, things like a Redis cache, and other related services a development environment relies on.

If we think about these kinds of services as potential "Features", they are a different class of feature than a runtime or SDK would be - they are standalone servers that you interact with "remotely" instead. Downloading container images can also be substantially faster than full installation steps for a typical Linux install if you were to add it into a container. Worse yet, these full installers can intermix with the OS in a way that prevents them from just being "untar'd" into a folder, which limits caching beyond built-in image layering (which only work if the parent layer has not been altered for the same image). Furthermore, this class of images is typically produced by the same team that maintains the software and is specifically optimized for use as a side-car - whether in dev using something like Docker Compose locally or in production via Kubernetes at deployment time. Thankfully, dev containers are well-suited to work with these types of side-car container images and many dev container definitions/templates encourage their use via Docker Compose.

However, particularly if you are not directly container deploying the application, what developers often expect is to be able to start working with these services as if they were spun up on their machine on localhost. Instructions and tutorials often use localhost as the host name, for example. Even when the application is container deployted, the containerization may happen later - either sometime later in a given project/app's lifetime or just automatically as a part of a later stage in the flow to production. Furthermore, even with side-car containers, you may still need or want utilities to be available in your primary container (e.g., a Mongo shell or Postgres command line tools) so that you can interact with the service from the command line. While these tools are a fast install, it separates out the configuration into two steps.

To address this issue, we could enhance the concept of a Dev Container Feature to not only provide scripts for a referneced container, but also optionally spin up a separate image pre-configured to operate on the same network. Orchestrator formats like Compose continue to be the core mechanism for general orchestration tasks, but developers can then add a side-car container with a single line reference. The combination of dev container metadata, a script, and a separate running container on the same network should then give a "local feel" but with substantially less Feature code and a faster overall install time.

This is a topic that has been raised in a few different spots and issue repos, so I'm raising this to track it as a possible addition to the spec.