Implements two flavor of library support for service-discovery:
- GetConnectionString (arbitrary strings) augmenting existing
functionality already in asp.net core
- GetServiceUri (uris) can be combined
from a protocol/host/port triple
See the **extensive** doc `service_discovery.md` that is filled out in this PR. That documents pretty much everything about how this works now.
This removes the need to copy-paste code that reads a specific directory
in Program.cs.
Updated docs/samples and tests.
We need a workaround in tests to be able to use a P2P for the library. What
I did here is the same trick we do in Razor.
- Force everyone to use an MSBuild variable to locate the library
- Set that variable in a Directory.Build.props for the normal build
- Drop a special Directory.Build.props for testing
Updates a bunch of test code to use new helper methods for copying
stuff, so we can correctly do this.
* Add support for container networking
- This adds all containers in the tye.yaml to the same container network.
- Container networking only works with a single replica today since the containers are named after their replicas.
- Use the container host name and port when injecting env variables. This handles the replica case by falling back to the host ip and port.
- This cleans up container to container communication when migrating docker-compose files.
- Don't override assign container port if already set.
- Remove StopAsync from TyeHost and exposed DisposeAsync. This patterns removes common clean up and hanging issues that occur.
- Cleaned up run tests to use similar code to run, clean up and capture logs.
* Move where we handle errors while shutting down the host
* Fixed project -> container networking issue
- Only use service name as the host name if both target and source re containers
* Formatting...
* Add service definition to the logs
* Added env variables to disable console colors for process run
* Hit the backend before the frontend
* Small cleanup
- Update docs to use host name for redis cli
- Show docker network and network alias in the API
* Add Dapr integration to Tye
Adds a new `extensions` integration point. Currently all extensbility has
to be inside the Tye codebase. There's no functionality for loading or distributing
plugins.
Enable dapr for an application like:
```yaml
name: test_app
extensions:
- name: dapr
```
The dapr extension currently accepts and requires no additional options, and applies
to all services defined in the application.
What it does:
- In local run: starts a dapr sidecar for each project that does http
- In local run: sidecars start in the directory of tye.yaml, so dapr will look for
component manifests in ./components (relative to tye.yaml
- In deployment: adds required annotations to deployments
Some new features that were added to tye to enable this:
- Config: Ability to parse and conditionally run extensions
- Run: Ability to token replace env-vars into command line args
- Deploy: Ability to configure labels and annotations
* format
* Massage labesl:
* PR feedback
* Fix tests
* Renamed dockerImage to image
- Added a new image field and marked dockerImage as deprecated. Will remove in a future version.
- Fixes#122
* Removed dockerImage support
* Added dockerImage back to the docs
This adds a basic tutorial for getting started with tye.
There are a few gaps we need to follow on, specifically:
- Organization of documents
- Content of tye deploy instructions
- Any follow up tutorials