* changing sample project to use microsoft health checks library
* update probes recipe
* Update probes.md
* changing probes doc
* give more description in '/' of sample service
* sample app and beggining of recipe
* fix link
* sample, recipe and schema docs
* change http failures to debug logs
* add model validation to probes and http prober
* add deserialization and validation tests
* license
* format
* PR fixes
* remove some Console.WriteLine's
This is new command that can be used to delete everything running in a
cluster related to an application using the labels we use.
This currently uses a hardcoded set of resource types. It would be
possible to make this generic, which might become needed in the future.
See comments in the code.
---
The overall design for how to use the command:
```sh
tye undeploy
```
Will read a solution or tye.yaml to get the application name. It then
enumerates and deletes all resources in the cluster with
`app.kubernetes.io/part-of=application-name` (in the current namespace).
```sh
tye undeploy --what-if
```
Will do the same, but without actually doing the deletion.
```sh
tye undeploy -i
```
Will interactively give you a yes/no choice for whether to delete each
resource.
* Use environment variables for secrets
- Updating in place does not apply to connection strings specifically since they are usually configured at startup as singletons.
- This brings consistency with the development experience.
- Gets rid of AddTyeBindings
- "Less secure", sure but to be pedantic env variables are stored in virtual file on disk while the process is running. I'd argue if you want full security then use keyvault/vault/name your secret store.
Fixes#313
* Removed the last AddTyeSecrets call
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