Multiple questions about real-world usability

[JJWTimmer]

Hi all,

Tye is exactly what the devs in our organization are looking for. Local and remote run, abstraction from kubernetes, one place to define things like variables, debugging possibilities.

There are, however, a number of questions I (as R&D/DevOps support for the teams) cannot answer yet:

1. How do you work with multiple environments: specify different values for variables for every environment? local, acceptance, production for example?
2. If possible, how do you run a MySQL in local mode, and use a SaaS db in prod?
3. How does running tests fit in this proces?
4. What is a global flow for CI and CD based on Tye with multiple projects?
5. How to specify 2+ connection strings with a different DB for a single DB service?
6. How do you work with secret values?

Thanks!

[razvangoga]

Hi,

my team and I have been using it for a few months for a microservices based platform with 2 WebApis and 5 worker services, working together with AzureBlobs, Postgres, Azure Service Bus, KeyVault, App Insights. The services are .NetCore 3.1 and one NodeJs. The platform was designed to run in production in Kubernetes (Azure's AKS in our scenario) with multiple instances for some worker services (competing consumers).

Some random points from our experince (not all may apply to you / your mileage may vary):

• We use Tye only for local development to quickly spin up the entire platform (1 instance of each service) or just parts of it (we use the tags for this).
• We use all 3 service types (containers for dbs or Azurite blob emulator / projects for the .net parts / file for the nodejs service)
• We're not running tye directly but rather have a powershell wrapper which we use to do some before run actions (set some environemnt variables for the current user) and then call tye run
• We're not using the service discovery / nuget extensions for it (don't want to pollute the codebase with dev-time components + this only works for c# not for nodejs or others), instead we make use of an agreed naming convention for configs and we are loading them from environment variables defined in .env files. We have a common.env for the shared stuff and each service has a specific xxx_service.env for it's own configs. In Production, the same configs values would be coming aout of a KeyVault.
• We do have multiple DBs (Postgres) hosted on the same container. Works fine with 3 different connection string configs (which are mostly identical, except the DB name). Some DB specific stuff to note:
  • the DB container gets recreated on every tye run, so your apps will have to provision the DB structure on every startup (or use your own custom container with the Dbs already provisioned). We're using EF Core + migrations and the structure provisioning works fine but,
  • if the container is recreated you'll lose the state from the DB, so you should either have some fast way to recreate it (eg: a powershell that will reimport the data) or use volumes
  • tye does not have the option for one service to wait on the startup of another one (a la docker compose's dependes_on) so you should take this into account so you don't apply the migrations when the DB container is not up
• CI CD is handled in the clastic way (Azure Devops Pipelines) - in my view using tye for Docker / K8s deployments falls squarely under Hanselman's "friends don't let friends do right click deployments".
• Regarding secrets, we have a well known clientId / client secret that is allows access to a dev keyvault. These clientId / secret values are configured on startup as env variables (like here https://docs.microsoft.com/en-us/dotnet/api/overview/azure/identity-readme#environment-variables)
• Regarding testing: unit tests don't fit into the picture (since they should be contained to one service only) but you can run integration tests across multiple services (we're doing this) - just a matter of starting all the containers / services needed to test you specific scenario.

We've tweaked / geared the workflow specifically for local dev only, and it works quite well - one can iterate quite fast with it (much faster, in any case, than if the dev-builds should have been deployed somewhere).

Some things I wish it would have:

• for containers: some way to refresh / pull the image if you are using a moving tag like latest
• something like docker compose's depends_on or at least the option to add an arbitrary delay to service startup via the yaml definition
• better syntax highlighting for the logs in it's local dashboard (info vs warning vs error)
• maybe the ability to add some prerun / postrun scripts / hooks directly in the yaml definition

---

All in all, very usefull tool !!!

LE : the docs are not the best for local usage (eg: can't find where the tags are explained), they seem to be focused more on deploying rather that running, but at the time when i setup out workflow i found this guy's repo / sample very helpful : https://github.com/jongio/memealyzer/tree/main/pac/net/tye

[JJWTimmer]

Razvan, thanks! Very useful reaction. Helps to put things in perspective, and craft a workflow! Also the example you added at the end is helpful.

If I understand correctly you do not see a case for tye deploy? How are you handling deployments to k8s, with Helm, or patch manifests with new image versions or ... ? We were fantasizing about one place to define variables, and let them be generated into Helm or Manifest files automatically, so you don't need to maintain a local setup, a dev .env, a prod keyvault etc. Does that make any sense for you?

[razvangoga]

When i started investigating tye (knew about it from early 2020 but actually got to looking at it last Oct or Nov or so) all the resources i found were about how you can deploy from local via tye to K8s. Literally the definition of right click deployment. Even Jon Galand's video that led me to the repo linked above does this : https://www.youtube.com/watch?v=uL7F9u5gon4&list=WL&index=37

Looking at this now, because tye is a dotnet tool, i guess you could build an (Azure) Devops pipeline around it (eg: install tye in the pipline as a tool and use it to deploy to K8s). Maybe using some templated / environment specific .env files like he does in the video you could reach the one place to define variables.

[razvangoga]

Hi @JJWTimmer, if you ever end up using tye, would love to hear about the specifics 👍

[lucasmaj]

@razvangoga So can one debug "tyed" services (.net projects) from Visual Studio?

[razvangoga]

@lucasmaj I generally attach with the debugger from VS or Rider once the service is up.

There is also the --debug arg option but I have not used it that much. I'll take it for a spin this week and get back to you with an update if you're interested.

[lucasmaj]

Thank you for sharing @razvangoga. Manually finding and attaching to multiple processes every time I need to debug the multiproject system is just way too cumbersome. Maybe I don't have right toolset for that?

I have been using Visual Studio plugin SwitchStartupProject. It allows me to easily configure multiproject configurations where all select projects get started and attached to at once. The only downside being it will launch all the project consoles (10+ in my case). Tye was interesting alternative (although still too much for what I need and I doubt I will be deploying with Tye) but without automatic debugger attachment it is not solving any of my problems.

[razvangoga]

Well, tye is not really a replacement for the F5-debug-run experience from an IDE. It's more like a docker compose on steroids, in which you can use more than just containers