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
This tries to add some auto-detect magic to make common scenarios work
without any extra configuration, which avoiding doing obtuse stuff.
- We ignore the ports in launch settings (avoid conflict in the
hello world multi-project case)
- When we infer bindings based on launch settings we set them to
auto-select a port
- The user setting a port via tye.yaml will always win
- Bindings that are not inferred from launch settings still work
the same way (we don't auto-auto-select a port)
- When we deploy we ignore https
The HTTPS behavior might need discussion, but we haven't started looking
at a recipe for HTTPs inside the cluster in k8s, and it's not clear
whether we even want to.
One could also make the argument that we should skip TLS locally because
we're not doing it inside the cluster. Someone writing an app today that
assumes TLS in their code (using https URLs, or gRPC + TLS) will have
a non-trivial path to k8s for now anyway. So, skipping https bindings
for k8s really just makes us more honest.
We need --force to do proper cleanup. If you end up in a situation
where an image has multiple tags then you won't be able to remove it
without --force.
Instead of using the ports in launchSettings.json we'll now just ignore them.
This means that ports get auto-assigned when they are not specified in
tye.yaml. This avoid the conflict when multiple default asp.net core applications
are used - so as a result, tye.yaml isn't needed in as many situations.
We'll give you more info and choices if you're trying to deploy
something that would depend on k8s secrets you have haven't configured
yet.
Basically when we would use a secret we'll check k8s first, and then
if it's not found:
- Prompt for it
- Create it if you told us what to put there
- Otherwise print to the commandline the command you could use to
create it.
- We need to bump up the min threads to something reasonable so that the dashboard doesn't take forever
to serve requests. All console IO is blocking in .NET so capturing stdoutput and stderror results in blocking thread pool thread
The thread pool handles bursts poorly and HTTP requests end up getting stuck behind spinning up docker containers and processes.
* Implement single-phase docker workflow
This implements support for building docker images using a single-phase
workflow (publish then build docker). This is going to be faster in
almost every case since it avoids the slowest part of deployment
(running restore inside a container in the multi-phase process).
This additionally supports .NET constructs like p2ps and shared files
without any customization - you can just customize dotnet publish
and be done!
So, switching to single-phase by default because there are few drawbacks
for our target use cases.
* Just for you James!
This implements support for building docker images using a single-phase
workflow (publish then build docker). This is going to be faster in
almost every case since it avoids the slowest part of deployment
(running restore inside a container in the multi-phase process).
This additionally supports .NET constructs like p2ps and shared files
without any customization - you can just customize dotnet publish
and be done!
So, switching to single-phase by default because there are few drawbacks
for our target use cases.
- With 3.1.102 I need to list pipelines explicitly
- Copy test assets to a temp directory (arcade needs it)
- Use .dll on *nix instead of the executable. I'm not seeing the
the executable created on macos. Older versions of tye successful
use the .dll.
This isn't optimal, but right now it's easy to get into problems using
tye because we don't generate manifests with digests.
As an example, if you don't have any versioning in your project, right
now we will *just* tag everything with 1.0.0. This can lead to pods
getting deployed with stale images, even though you pushed!
A better solution is for us to use digests instead of tags.