Docker for Goose: Use Cases

[ZhenLian]

Docker is arguably one of the most powerful technologies in the current cloud environment, and users can greatly benefit from running a container with the Goose application. One clear advantage is security. As outlined in SECURITY.md, running Goose in a dedicated container with limited privileged capabilities can significantly reduce the risk of local system attacks or unintended access to critical system resources.

While working on this issue to create a Docker container for Goose, I've come to realize that users might need to use Docker in slightly different ways. I'm starting a new discussion topic here to gather ideas on how users can utilize these containers and to share my progress on the development work.

If you have a use case that hasn't been covered in previous examples, please feel free to share it!

[ZhenLian]

Use Case 1: As a Goose user, I want to run the latest release version of Goose in a container. This approach benefits me by significantly reducing the risk of local system attacks or unintended access to critical system resources.

[ZhenLian]

Use Case 2: As a Goose user and developer, I want to be able to build Goose from source within a container. This approach not only provides the security benefits mentioned in Use Case 1 but also enhances consistency and portability. For instance, if I'm troubleshooting a specific error that occurs on a platform I don't primarily work with (such as Ubuntu), I can easily debug it using Docker.

[ZhenLian]

I'm currently working on this use case and am nearing the point where I can submit a pull request to run Goose in a container with basic capabilities as a developer tool :)

[ZhenLian]

Use Case 3: As a Goose user, I want a centralized, cloud-hosted version of Goose that can handle inputs from multiple users and generate responses. For example, it could function as a feedback consolidation assistant, allowing multiple users to ask questions and enabling Goose to perform analyses using a LLM on a shared data set. This use case was inspired by an internal discussion.

[ZhenLian]

Use Case 3 is an interesting idea. We could explore the following approaches to build Goose in a way that accommodates multiple user inputs:

1. Using named pipes within Docker, allowing multiple users to interact with a centralized Goose container. For example, users can interact with goose instance in this way:

In one terminal (to write to Goose):
cat > pipes/input
In another terminal (to read from Goose):
cat pipes/output

2. Developing a REST API wrapper for Goose, effectively transforming it into a web application that can accept user inputs and return responses.

Before diving into these implementation details, an important consideration is whether a single web container running Goose is scalable enough to manage multiple user requests. Goose seems to be designed primarily for single-machine use, so scaling it to handle increased loads may require additional design work. There are also other nuances to consider, such as handling user inputs or outputs that exceed the pipe buffer or a single API request, and managing scenarios where one user's query consumes too much of the token quota provided by the LLM provider. These questions are not difficult to address, but we might need a separate medium-level design document to clarify the objectives and limitations of what we aim to support here.