Steeltoe developer tool collection
Home Page: https://steeltoe.io/
License: Apache License 2.0
Tools for Steeltoe Developers.
The goal of this project is to provide tools to assist Steeltoe Developers. The current focus is an API and CLI to help with deploying Steeltoe Applications locally to Docker.
Subsequent goals include:
a Visual Studio plugin leveraging the API
plugins for other IDES, such as Visual Studio Code and JetBrains Riser
Visual Studio/DotNET templates
See Steeltoe Tooling Documentation for more user and developer information.
For example, change
% steeltoe list-service-types
config-server
service-registry
to
% steeltoe list-service-types
config-server (Spring Cloud Config Server)
service-registry (Netflix Eureka Server)
Currently, if you have n services, you would deploy them:
deploy <service-1>
deploy <service-2>
...
deploy <service-n>
Adding support for an *-all variant would simplify above to:
deploy-all
Currently, deploy, undeploy, and status work on all defined services. Enhance the commands so that can can optionally work on an individual service.
$ st status
foo-config online
foo-dash online
foo-redis online
foo-mssql online
foo-zip online
foo-eureka online
$ st status foo-config
foo-config online
Factor the project into 2 projects, one for the CLI and another a library that can be used by other projects.
Example projects:
Steeltoe.Tooling
Steeltoe.Tooling.Cli
There is a dearth, as in non-existent, of API docs in the source code.
Currently, multi-service operations are run serially. E.g., when deploying services, each service is deployed before deploying the next one. Running the deployments in parallel will improve CLI response.
Many feature tests are failing on Windows due to the tests not expecting carriage returns (\r).
E.g., a test expecting "Steeltoe Developer Tools\n" will fail on Windows because the actual string is "Steeltoe Developer Tools\r\n".
Basically, migrate from:
add-service Add a service.
check-service Check the status of a service in the target environment.
list-service-types List available service types.
list-services List available services.
list-targets List available target environments.
remove-service Remove a service.
set-target Set the target environment.
start-service Start a service in the target environment.
stop-service Stop a service in the target environment.
to something like
add Add a service.
disable Disable a service.
enable Enable a service.
remove Remove a service.
status Show status and other information of a service in the target environment.
start Start enabled services in the target environment.
stop Stop running services in the target environment.
target View or set the target environment.
Change the order of the add command arguments.
$ st add foo config-server
becomes
$ st add config-server foo
Currently, the tooling look in the current directory for the file .steeltoe.tooling.yml.
Supporting something like:
$ steeltoe -C <myconfigpath> ...
would permit being to able to somethine like:
$ steeltoe -C my-test-services.yml ...
$ steeltoe -C my-demo-services.yml ...
CLI tests take on the order of minutes. If reduced to seconds, they could be added to CI builds.
Tests execute one or more dotnet commands. Looks like this could be replaced using something like this:
https://github.com/natemcmaster/CommandLineUtils/blob/ecfc8bc3992f9ee899115622dcb851d0274f3557/docs/samples/dependency-injection/custom/Program.cs
Need to impl service states as defined by IServiceBackend::GetServiceLifecleState
Something like:
steeltoe set-target docker
steeltoe add-service MyConfigServer -t cloud-foundry-config-server
steeltoe start-service MyConfigServer
Need to impl service states as defined by IServiceBackend::GetServiceLifecleState
For example, specifically to cloud foundry CLI cf:
As a .NET Developer, I would like to be able to retrieve the environment info (eg: VCAP_APPLICATION and VCAP_SERVICES) from an application instance running in Pivotal Cloud Foundry and apply it to my local instance in a non-static way.
Possibly implemented as an on-demand command like st mimic <app-name-on-pcf> or as an msbuild task -- either of which could populate a file that then needs to be included in app configuration
Currently, a service type maps to a single docker image name. That name is expected to resolve to a docker image for both Linux and Windows docker containers.
However, in some cases it'd be easier for docker image construction if a service type could map to different image names depending on the container OS.
A specific example are Steeltoe Redis Server docker images:
steeltoeoss/redis-server:4.0.11-linuxsteeltoeoss/redis-server:3.0.504-windowsWhen deploying service locally to docker, it'd be useful for a developer to see the output from the docker containers. The output could be obtained from per-container log files, or perhaps from per-container terms.
Creating a dockerfile for each project in the samples (MusicStore, FreddysBBQ...) will improve the deployment in a containerzed environment. As the others components (dabatase, configuration..) are docker images, the others ones will be very good.
Thus, e.g.,
steeltoe enable <service>
becomes
st enable <service>
Something like:
steeltoe set-target local
steeltoe add-service MyEurekaServer -t eureka-server
steeltoe start-service MyEurekaServer
Something like:
steeltoe set-target local
steeltoe add-service MyConfigServer -t cloud-foundry-config-server
steeltoe start-service MyConfigServer
Current impl only supports deploying apps to CF. Need similar support for docker.
E.g,:
% steeltoe start-service MyConfigServer
% docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a2dc22068d0a steeltoeoss/configserver "java -jar configser…" 6 seconds ago Up 6 seconds 8888/tcp MyConfigServer
% telnet localhost 8888
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host
something like:
steeltoe set-target docker
steeltoe add-service MyEurekaServer -t eureka-server
steeltoe start-service MyEurekaServer
Example:
$ list environments
cloud-foundry
docker
$list environments -v
NAME DESCRIPTION
cloud-foundry Cloud Foundry
docker Docker
Command should check development environment and report any potential problems. In addition, any other useful information such as tool versions should be reported.
If an environment is missing support for a service, the CLI reports unhelpful message:
$ st add trace zipkin
$ st target cloud-foundry
$ st deploy
Deploying service 'trace'
The given key 'zipkin' was not present in the dictionary.
A better message might be:
$ st deploy
Ignoring unsupported service 'trace'
In current impl, a service can be started/stopped regardless of service state. Need a state machine to better control state transitions, e.g., from 'stopped-started-stopped'.
If a service already has existing arguments, the user should be required to indicate intent to replacing them.
E.g. assume a SQL Server service named database with defined docker launch args:
$ st add database mssql-server
$ st args docker database -- -e ACCEPT_EULA=y
Set the 'docker' deployment environment argument(s) for service 'database' to '-e ACCEPT_EULA=y'
The following should fail, but currently it simply overwrites existing args:
$ st args docker database -- -e ACCEPT_EULA=n
Set the 'docker' deployment environment argument(s) for service 'database' to '-e ACCEPT_EULA=n'
A better behavior would be something like:
$ st args docker database -- -e ACCEPT_EULA=n
'docker' deployment environment argument(s) for service 'database' already exist.
Run with '--force' to replace.
$ st args docker database --force -- -e ACCEPT_EULA=n
Set the 'docker' deployment environment argument(s) for service 'database' to '-e ACCEPT_EULA=n'
list command should not require a configured target.
$ st list
Target not set
Something like:
steeltoe add-service MyEurekaService -t eureka-server
Before adding other Cloud Foundry services, there needs to be a mapping from the general service type (eg, cloud-foundry-config-server) to its Cloud Foundry type (eg, p-config-server).
sanity check passes when docker targeted ...
$ steeltoe target docker
checking docker ... Docker version 18.06.0-ce, build 0ffa825
Target deployment environment set to 'docker'.
however subsequent command will fail ...
$ steeltoe deploy config
docker error: error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.38/containers/json?filters=%7B%22name%22%3A%7B%22%5E%2Fconfig%24%22%3Atrue%7D%7D: open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.
To reproduce:
% steeltoe init
Project initialized for Steeltoe Developer Tools
% steeltoe add config config-server
Added config-server service 'config'
% steeltoe deploy
System.AggregateException: One or more errors occurred. (Object reference not set to an instance of an object.) ---> System.NullReferenceException: Object reference not set to an instance of an object.
at Steeltoe.Tooling.ServiceManager.GetServiceBackend() in ...
Using the verbose option (-v|_--verbose) includes underlying commands and their output. However without some context as to why the command is being run, the verbose output can be white noise.
E.g., when tooling is polling a backend to get the status of a service, it'd be useful is the verbose output included something like "getting status" or "waiting for service to come online".
When running steeltoe deploy, the tooling should deploy any apps/services implemented by the solution.
Currently environment and service type registries are hard coded. Move them into a config file that ships with the tool. This will help lay the ground work for post-tool install customizations of environments and service types.
Names should be unique in union of app and service names.
This should not be allowed:
$ st add app foo
$ st add redis foo
It'd be useful to see what st is doing on behalf of the developer. E.g., when deploying a service to Cloud Foundry, the command cf create-service ... is run when a service is deployed.
Example that uses a verbose switch:
$ st deploy
Deploying service 'myredis'
$ st undeploy
Undeploying service 'myredis'
$ st deploy -v
Deploying service 'myredis'
cf create-service p-redis shared-vm myredis
Creating service instance myredis in org pivot-ccheetham / space playground as [email protected]...
OK
$ st undeploy
Undeploying service 'myredis'
f delete-service myredis -f
Deleting service myredis in org pivot-ccheetham / space playground as [email protected]...
OK
After deploying a service to cloud foundry, the service appears to be OFFLINE until the service is created at which time it becomes ONLINE. After deploying a service, its state should be STARTING until it is created.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.