Test building Steeltoe sample apps

[sophiewigmore]

We currently support a few different types of apps with the .NET Core buildpack, but it would be good to try building some sample applications that might be more reflective of what users in the space are interested in.

This issue is to test building the apps from https://github.com/SteeltoeOSS/Samples and documenting which ones build correctly, and if any of them fail, filing new issues with the failure and link to the app, so we can discover ways to make the buildpack more robust.

[fg-j]

Here's a list of the samples in the repo to explore

• [ ] * Configuration - samples using the Spring Cloud Config Server and other Steeltoe configuration providers.
• [ ] * Discovery - sampless using Steeltoe Service Discovery microservices-based application.
• [ ] * Management - samples using the Steeltoe Management packages for adding Management REST endpoints to your application as well as adding Distributed Tracing support.
• [ ] * Connectors - samples using the Steeltoe Connectors for connecting to backing services. Steeltoe Connectors simplify the coding process of binding to and accessing Cloud Foundry based services.
• [ ] * CircuitBreaker - samples using the Steeltoe Circuit Breaker packages for building scalable and resilient microservices-based application.
• [ ] * Security - samples using the Steeltoe Security packages for Authentication and Authorization with Cloud Foundry auth services, using a Redis cache for DataProtection KeyRing storage and for interacting with CredHub.
• [x] * MusicStore - a sample that uses all of the Steeltoe components together in a microservices-based ASP.NET Core application. Adapted from the ASP.NET Core reference app: MusicStore by Microsoft.
• [ ] * FreddysBBQ - a polyglot (Java and .NET) microservices-based sample demonstrating interoperability between Java and .NET on CloudFoundry, secured with OAuth2 Security Services and using Spring Cloud Services.

[fg-j]

The MusicStore set of microservices work beautifully right out of the box.

In the docker-compose.yml that can be used to stand up the app with all its microservices, we see that there are 4 microservices whose source code live in the this samples directory:

• musicservice
• shoppingcartservice
• orderservice
• musicstore

We can pack build each of these by going into their respective directories in src/ and running

pack build <service-name> --builder paketobuildpacks/builder:base

Then, remove/comment out the build: portions of those services' definitions in the docker-compose.yml. Then, running docker-compose up will detect the buildpack-built images present on the daemon and use those as it stands up the microservices! They all seem to Just Work (TM) together. I can even use the admin UI to see that the health check endpoints are working as intended.