dotnet/tye

Regular status updates from the Tye team

rynowak opened this issue · 4 comments

rynowak commented

This issue contains status updates from the Tye team to provide insight into future plans, what the team is working on, and highlight helpful work done by the community.

We'll post a new entry approximately every 2 weeks, and do a release of Tye approximately every 4 weeks. This means that each release should have a midpoint status update, and a release status update.

If you want a low-spam way of tracking what's going on with Tye, then you should subscribe to this issue.

More Information

The Tye team uses github projects to track and prioritize work for the current release. You can find our projects here: https://github.com/dotnet/tye/projects - There should always be one tracking the current release: example

These updates are an effort by the Tye team to communicate in advance about plans and work going on. There's always the possibility that plans will change, or that reality will fail to live up to our expectations 👍

Comments are disabled on this issue to reduce noise. If you have questions or want to discuss something, please open a new issue and tell us what's on your mind.

rynowak commented

March 29, 2020

What are we doing now?

We're working towards the 0.1 release

We open-sourced the repo approximately two weeks ago, and did a soft opening by announcing Tye through a few .NET-friendly channels. Our next release will still use the 0.1 version scheme but will go to nuget.org. We're targeting Apr 9 for the release date.

To fill out 0.1 we're working on:

  • Ingress for deployment
  • Better config validation and errors
  • Integration with Dapr
  • Support library for config/service discovery
  • Local dev with non-.NET workloads (sample/docs only)
  • Local dev with zipkin for distributed tracing (sample/docs)
  • VERY rudimentary metrics support in dashboard
  • CI/CD docs/samples (azdo & actions)
  • Any blocking issues that have been reported by users so far

There have also been a few substantial improvements added so far:

  • Run locally in containers with tye run --docker
  • Cleanup of abandoned processes on host crash (thanks @areller)

Community contributions

Since this is our first post, I'm going all of the way back to the beginning of the repo to mine these. Many of these are small tweaks to our docs, and those are important to us too!

rynowak commented

April 9, 2020

Tye 0.1 release notes

These are the release notes for the 0.1 release of Tye.

This is the first release uploaded to nuget.org. From here on, we'll be uploading stable builds of Tye to nuget.org approximately every 4 weeks. If you want to have a more stable experience with Tye, then using the builds on nuget.org will give you something that has documentation and has been tested.

The package version is: 0.1.0-alpha.20209.2

See getting started for installation instructions.

Documentation improvments

We've done some reorganization of our documentation, and started to fill out more reference material that describes how Tye works. You can find this in the docs folder.

We've added documentation about how to keep tye up to date with our CI builds as part of getting started.

Notable changes and features

Service discovery

Service discovery (getting URIs and connection strings for other services) has undergone some major revisions to become more consistent and easy to use.

There's new documentation for service discovery that describes the functionality in detail.

We have a new library Microsoft.Tye.Extensions.Configuration that builds on top of Microsoft.Extensions.Configuration to make service discovery easier. This library replaces the copy-pasted code that was previously in our samples and tutorials.

We now have different recommendations about when to use connection strings and when to use URIs for services. TLDR: use URIs for simple things that don't require credentials or parameters, use connection strings for things that are database-like. See the service discovery documentation.

Connection strings in bindings now support some basic templating to make them more useful in a broad array of scenarios. This improvement is meant to remove the need to build connection strings manually in code. Build them in config instead! Let us know what you think.

tye deploy now understands the difference between a URI and a connection string. Previously tye deploy would assume that all non-.NET-projects provide a connection string. Now service discovery will function in the same way between a local application and deployed application.

In the spirit of making local development and deployed applications more similar, we now use environment variables for service discovery in deployed applications.

Improved local development

We've made many improvements to local development - mostly focuses on seamless interop between .NET services running on the local machine and services running in containers.

We now set both ASPNETCORE_ENVIRONMENT and DOTNETCORE_ENVIRONMENT environment variables to Development when using tye run. This is needed for projects based on older versions of ASP.NET Core.

We now suppress console logging colors for .NET applications, resulting in cleaner console output in development.

tye run has the ability to run your .NET services in containers. Use tye run --docker to try it out. This functionality has been added so that you can test a step in-between local development and a deployed application.

Container images will now be pulled prior to starting any services. This gives better UI feedback when pull is taking a long time. This also prevents errors when a service needs all of its dependencies running to start.

Services running in containers now support using named volumes. This allows you to configure Tye to use an existing Docker volume - which is handy when you have persistent data to provide to a container.

name: volume-test
services:
- name: volume-test
  project: volume-test.csproj
  volumes:
   - name: data-vol
     target: /data

This example (from our tests) shows a .NET project using a named volume, and could be run using tye run --docker to run the .NET project in a container.

Named volumes are also available for container images running as services.

We've fixed an issue that was preventing services running in containers on linux from communicating with services running in the user's namespace (localhost). We now workaround docker/for-linux#264 on Linux so that the development experience is consistent with macOS and Windows.

tye.yaml now supports specifying a Docker network.

name: my-application
network: my-network
services:
...

When a network is specified, tye run will place all of the containers on that pre-existing network.

When multiple containers are running, Tye will now create a Docker network and place all of the containers inside it. If a network name was specified, that will be used instead of creating a new one.

Tye now creates a proxy for each service running in the user's namespace and places it in the docker network with all container image services. This makes it possible to use hostnames to route traffic outside of the docker network - and makes development similar to deployed applications.

Improvements to Tye dashboard

We've made some UX improvements to the Tye dashboard. We have a new color scheme.

We also now have a basic metrics display as part of the dashboard. This is similar to dotnet counters but its for all of your services, and it's got a UI. Click on the name of a .NET service to see.

We've changed the message shown when dashboard server is disconnected. Previously this was the default Blazor-server message, now we've made it more clear.

Ingress for local development

tye run now supports ingress for local development. We were hoping to add support for ingress in deployed applications in this release, but it didn't make the cut.

name: apps-with-ingress
ingress:
  - name: ingress
    bindings:
      - port: 8080
    rules:
      - path: /A
        service: appA
      - path: /B
        service: appB
      - host: a.example.com
        service: appA
      - host: b.example.com
        service: appB  

services:
- name: appA
  project: ApplicationA/ApplicationA.csproj
  replicas: 2
- name: appB
  project: ApplicationB/ApplicationB.csproj
  replicas: 2

In this example we'll run nginx in a container and use it as a proxy for services appA and appB. The proxy will listen on localhost:8080 and route traffic based on the rules defined here.

Misc changes

We've added cleanup functionality to tye run. If the tye host process crashes, we'll keep a record in a local folder ./tye of what was running at the time. Any dangling processes will be cleaned up if you do tye run again.

The code for reading tye.yaml has undergone an extensive rewrite. We now validate many more things from tye.yaml for correctness.

As part of this change the name: property at the top level is now officially optional in the schema and documentation. Tye would previously tolerate omitting it, but we've now officially documented that it's optional. The directory name (converted to lowercase) will be used instead.

tye init and other tye ... commands that operate on a solution file have different logic for including and excluding projects. We now consider all projects that have a launchSettings.json to be runnable - which exludes unit test projects and class libraries.

Tye now uses MSBuild to read some information from each .NET project as part of tye run. This fixed many bugs that were due to hardcoded assumptions about target frameworks, output paths, etc. As part of this change we now support .NET project settings that affect running in IDEs like <RunArguments>.

We've added integration between tye and Dapr for local development and deployment. Tye makes it easy to do development with multiple applications using Dapr. Find docs here.

We've added dtye aliases to make it easier to contribue to the repo.

Example:

# sourcing activate.sh puts dotnet on the path and adds `dtye` as an alias
. ./activate.sh

# find a sample
cd samples/multi-project

# runs the `tye run` command but using the local source code for tye
dtye run

Equivalent scripts are provided for powershell/Windows.

Community contributions

rynowak commented

April 29, 2020

What are we doing now?

For the next release (planned May 7) we're working on some exciting new things:

  • Deployment for Ingress
  • Multi-tye.yaml support
  • More diagnostics integrations

See the sections below for more details on these...

Alongside that we've seen a few notable improvements make their way in so far. Some highlights:

  • Specifying properties in tye.yaml to be used by build/publish. #383
  • Specifying a namespace for deployment (in command line and tye.yaml) #400
  • Support for Dapr configuration #298
  • tye push #365
  • tye undeploy docs

We'd appreciate you trying these things out and giving feedback using the CI builds. These features will be on nuget.org soon!

Deployment for Ingress

We have a new recipe guide for ingress: here.

Ingress allows you to create path-based and hostname-based routing rules for your services.

name: apps-with-ingress
ingress:
  - name: ingress
    bindings:
      - port: 8080
    rules:
      - host: a.example.com
        service: app-a
      - host: b.example.com
        service: app-b 

services:
- name: app-a
  project: ApplicationA/ApplicationA.csproj
  replicas: 2
- name: app-b
  project: ApplicationB/ApplicationB.csproj
  replicas: 2

For a while now we've had the ability to configure ingress rules for local development, but now we support it for deployment.

Tye can deploy (or detect) the ingress-nginx ingress controller in Kubernetes. We also know how to automatically create or delete Kubernetes Ingress resources that work the same way as our local development proxy.

We support a very small number of features and have gotten some feedback so far about what other things are needed. We'd appreciate hearing more 👍.

Multi-tye.yaml Support

We're working on the early stages of multi-repo and distribution for tye.yaml definitions. We know that many users organize code as one-service-per-repo and Tye doesn't currently support that kind of strategy.

What's going to land in this release will be the ability to reference services from another tye.yaml as a URI or a file on disk.

name: VotingSample
services:
- name: vote
  project: vote.csproj
- name: worker
  include: ../worker/tye.yaml
- name: redis
  image: redis
  bindings:
    - port: 6379
      connectionString: ${host}:${port}

This doesn't solve the scenarios that we're targeting yet, but it's a step on the path to where we're headed.

Diagnostics Improvements

We're trying to put together some recipes for using common diagnostics services in this release:

  • Distributed Tracing (Zipkin, Jaeger, etc)
  • Log Aggregation (ELK)
  • Metrics (Prometheus + Grafana)

We're going to provide recipes for easily using these kinds of services both in development and in deployed applications.

Community contributions

Below is a list of all the community contributions between April 09, 2020 and April 29, 2020 (UTC time). Thanks to all our contributors for their enthusiasm and support!

jkotalik commented

Closing as we aren't using this for updates.