* Add buildArgs to service configuration and capture build configuration as global property to setup msbuild project
* Fix format
* Fix - Error CS8600: Converting null literal or possible null value to non-nullable type.
* Improve configuration format for build arguments
* Fix whitespace format
* Fix error CS8618: Non-nullable property 'Properties' is uninitialized. Consider declaring the property as nullable.
* Fix error CS8601: Possible null reference assignment.
* Translate non first class properties as /p:{Key}={Value} into the build command
* Fix property translation
* All properties are used to create the msbuild project
* Change the name (to BuildProperties) and the type (to List<BuildProperty>) of ConfigService property to load build properties
* Add support of build properties when tye run with --docker option
* Fix ComprehensionalTest
* Add tests to verify the output directory for the corresponding build configuration
* Fix whitespace format
* Override the correct CreateTestCasesForTheory to fix error CS0618
* Remove the usage of BuildPropertiesToOptionsMap and fix the code format
* Add support to deserialize network key at HandleConfigApplication method of ConfigApplicationParser
* Fix whitespace format
* Add network deserialization test
* 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
Fixes: #206
This change only applies to the logic that we use to look at solution
files. This adds a heuristic that we only include projects with a
launchSettings.json for these operations (when considering a solution).
This will exclude unit test projects and class libraries.
In this case where the user has a `tye.yaml` then whatever's in there
will win. Likewise if a user passes a path to a project directly then
we'll try to run it without asking questions.
I chose `launchSettings.json` for this because it's a decision we can
make really quickly without having to run any MSBuild code. When we
think about operating on a solution with 50 projects with `tye run` we
really really don't want to have to evaluate each project with MSBuild
to figure out what kind of project it is (500ms).
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.
* Added container proxy for talking to the host
- This change introduces a container proxy which makes it possible for docker containers can talk to host services using container networking. These proxies will not show up in the dashboard as they are "infrastructure" containers.
- Added Private and NetworkAlias to DockerRunInfo but did not expose these configuration.
- All container communication is done using host names.
- Fix host shutdown again
- Bind to all interfaces on linux
* Add configuration option to enable the containers usage of an existing network
* Use IsNullOrEmpty instead IsNullOrWhiteSpace to check the value of Application.Network
* Add tests for network assignment
* Remove network-test assent and use frontend-backend for network tests
* Improve logs in DockerRunner
* Fix whitespaces
* Fix whitespace formatting
* Fix format with dotnet format
* Add assertions to make sure the app working on network tests
* Add test for container -> host communication.
* Small tweaks
- Modify frontend-backend app to print backend url
- Fix log in docker runner
- Rename test to use docker instead of container
* More clean up
- Don't set container port if the service isn't a container
* Bind to all interfaces on linux only
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
* Purge hanging replicas
* Use dictionary for event serialization
* Subscribing to replica events instead of waiting for arbitrary time in tests
* Only return list of running containers from DockerAssert
* use IDictionary instead of deserializing to ReplicaStatus when removing stale replicas
* Exit logs loop in DockerRunner if container is killed
* Created a object graph visitor to ignore also empty collections on serialization. Unify creation of serilizer/deserialization objects with specified configuration
* Update OmitDefaultAndEmptyArrayObjectGraphVisitor.cs
* Update YamlSerializer.cs
* Fix tests with EOL issues on different SO #235
Co-authored-by: Justin Kotalik <jkotalik12@gmail.com>
Fixes: #189Fixes: #153
This change rejiggers the docker build infrastructure to publish the project
and generate a Dockerfile in the same directory. This way they can't be on
separate drives!
Also added some focused tests for single-phase docker build.
Merged the data model we use for m8s features with the features
that come from rynowak/opulence. The `ApplicationBuilder` type (and related
types) now capture all of the details we use for everything.
There's a lot of just moving stuff around in this change - the goal
is to have a separate data model for:
- The config we read
- The representation we mutate
- The data model used by Tye.Hosting
So in this PR there's a lot of righthand/lefthand.
* Add support for running local containers
- This support builds the application locally then volume mounts the application into the container when the --docker flag is specified. Added support for volume mounts and working directory to the DockerRunner.
- Add simple test for tye run --docker
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.
Justin Kotalik
Ryan Nowak
Igr Alexánder Fernández Saúco
David Fowler
Thang Chung
Justin Kotalik
SimonCropp
areller
Unai Zorrilla