Automatically use container if volumes are mounted on project based service

[Kralizek]

Describe the bug

By default Tye loads C# projects directly on the host unless there is a need for a container. If another service uses replicas or uses a dockerfile or a docker image, Tye mounts the projects as a volume to a container used as proxy.

Unfortunately, if the Tye configuration file specifies an additional mount, that is ignored when the project is executed on the proxy.

The volume is correctly loaded when specifying --docker.

I noticed the issue because I am doing local development and I saw that my local override to AWS keys is being ignored and my project couldn't find my fake keys (required to access the local installation of DynamoDB).

To Reproduce

Here is a simple example:

name: my-secret-project

services:

- name: api
  project: src/API/API.csproj
  bindings:
    - protocol: http
      port: 5001
  volumes:
    - source: ./.fakeawscredentials
      target: /root/.aws/credentials
  tags:
    - api

- name: dynamodb
  image: amazon/dynamodb-local
  args: -jar DynamoDBLocal.jar -sharedDb -dbPath /home/dynamodblocal/data/
  bindings:
    - containerPort: 8000
      port: 5021
      protocol: http
  volumes:
    - source: ./data/dynamodb
      target: /home/dynamodblocal/data
  tags:
    - dynamodb

The configuration file has a simple ASP.NET Core application. In the root of the solution I have the fake AWS profile that I want to use to use fake AWS credentials.

[Dev]
aws_access_key_id=************
aws_secret_access_key=************
region=eu-north-1

Here are the commands I ran to validate the faulty behavior.

# no need for proxy
$ dotnet tye run --tags api

# proxy needed
$ dotnet tye run
$ docker exec <container id> ls -al /root
total 24
drwx------ 1 root root 4096 Aug 23 16:29 .
drwxr-xr-x 1 root root 4096 Dec 12 15:35 ..
-rw-r--r-- 1 root root  571 Apr 10  2021 .bashrc
drwxr-xr-x 1 root root 4096 Aug 23 16:28 .dotnet
drwxr-xr-x 3 root root 4096 Aug 23 16:29 .nuget
-rw-r--r-- 1 root root  161 Jul  9  2019 .profile

# project loaded in a container
$ dotnet tye run --docker
$ docker exec <container id> ls -al /root
total 28
drwx------ 1 root root 4096 Dec 12 15:41 .
drwxr-xr-x 1 root root 4096 Dec 12 15:41 ..
drwxr-xr-x 3 root root 4096 Dec 12 15:41 .aspnet
drwxr-xr-x 3 root root 4096 Dec 12 15:41 .aws
-rw-r--r-- 1 root root  571 Apr 10  2021 .bashrc
drwxr-xr-x 3 root root 4096 Dec 12 15:41 .microsoft
-rw-r--r-- 1 root root  161 Jul  9  2019 .profile

Further technical details

$ tye --version
0.11.0-alpha.22111.1+3edef5428949c518c078844d6438e5ba86fce600

[davidfowl]

Just so I'm clear, are you expecting tye to detect the volume mount and switch to a container for the service?

[Kralizek]

That would be the icing on the cake.

The intent of my issue is that once The had detected the need for a proxy, it should mount the specified volumes to the proxy like it does with the project folder.

[Kralizek]

I realized the description of the bug wasn't clear enough so I reformulated as follows

By default Tye loads C# projects directly on the host unless there is a need for a container. If another service uses replicas or uses a dockerfile or a docker image, Tye mounts the projects as a volume to a container used as proxy.

[davidfowl]

Yea, this has nothing do with proxy containers. Tye should detect the volume mount and treat this like a container scenario.

[Kralizek]

Can you still attach the debugger to a project ran into a container? (Never tried myself)

[davidfowl]

Not easily. I haven’t looked into what it would take to make that easy

[davidfowl]

In this specific case, I think it would be easier to express those as secrets that flow into the project service. Today your only option is environment variables expressed in tye yaml.